СПОСОБ КОНФИГУРИРОВАНИЯ ЭЛЕКТРОННОГО УСТРОЙСТВА Российский патент 2010 года по МПК H04W8/02 

ОБЛАСТЬ ТЕХНИКИ

Варианты осуществления настоящего изобретения относятся к конфигурированию электронного устройства. Частные варианты осуществления относятся к стандартному процессу конфигурирования мобильных сотовых телефонов, к примеру, на месте продажи.

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

В настоящее время наблюдается тенденция повышения многофункциональности электронных устройств. Вследствие этого конфигурирование таких электронных устройств может представлять известную трудность.

Пользователь устройства может потратить значительное время на конфигурирование настроек устройства только лишь для того, чтобы заставить его работать правильно и/или так, как нужно пользователю. Поэтому возможна даже такая ситуация, когда пользователи будут воздерживаться от покупки новых устройств из-за трудности их последующей настройки.

Описанные выше тенденции особенно характерны для мобильных сотовых телефонов. Мобильные телефоны обычно спроектированы таким образом, что могут быть настроены на работу в любой из множества сотовых радиотелефонных сетей различных операторов. Однако для правильной работы телефона или для реализации определенных функциональных возможностей каждый оператор предъявляет свои требования к настройкам телефона. Поэтому у оператора (поставщика услуг) может возникнуть необходимость настроить определенные параметры мобильного телефона. Кроме того, мобильный телефон является персональным устройством, и зачастую пользователи устанавливают на нем свои любимые мелодии в качестве мелодий звонков, закладки для Интернет-сайтов, заставки и т.д.

Отсюда возникает необходимость в разработке способа автоматической настройки электронных устройств и, в частности, мобильных сотовых телефонов.

Предпочтительно, чтобы этот способ настройки был универсальным и мог использоваться на многих электронных устройствах без каких-либо изменений под конкретное устройство. Например, предпочтительно, чтобы указанный способ настройки мог использоваться для начального конфигурирования всех или большинства мобильных сотовых телефонов.

Изобретателями была рассмотрена возможность автоматической настройки при помощи сообщений SyncML, используемых для передачи данных целевому устройству и для обработки на указанном целевом устройстве переданных данных при помощи исполняемых файлов.

SyncML™ Device Management (DM) является открытым, универсальным промышленным стандартом. Посредством него третьим лицам, например, поставщикам услуг и отделам управления корпоративной информацией предоставляется возможность создавать и управлять древом иерархии, хранящимся в мобильном устройстве. Более подробно создание и обслуживание древа иерархии описано в документе "Древо иерархии устройства SyncML и его описание", v1.1.1, от 10^ого февраля 2003, (www.syncml.org). На древе иерархии имеются узлы, которые соединены с ним ветвями. Каждому узлу может быть присвоен уникальный URI (Uniform Resource Identifier, универсальный идентификатор ресурса). Узел может являться либо внутренним узлом, который может иметь любое количество узлов-потомков (подчиненных узлов), но не может хранить какие-либо данные, либо может быть краевым узлом, который не может иметь узлов-потомков (подчиненных узлов), но может хранить некоторые данные. Под упомянутыми выше данными подразумевают последовательность символов, файл, число и т.д. Таким образом, SyncML DM является механизмом для оперативной передачи данных мобильному устройству.

Протокол SyncML Representation Protocol, v1.1, от 15^ого февраля 2002, (www.svncml.org) описывает общий синтаксис и семантику расширяемого языка разметки (Extensible Markup Language, XML), используемые всеми протоколами SyncML, включая протокол управления данными (Data Management, DM). В протоколе предусмотрены следующие команды: Add, Copy, Delete, Exec, Get, Replace. При поступлении от инициатора команды Ехес получатель запускает указанный командой исполняемый файл.

Более подробно применение команды Add для создания древа иерархии описано в документе "Древо иерархии устройства SyncML и его описание", v1.1.1, от 10^ого февраля 2003, (www.syncml.org). При этом стандарт SyncML DM не определяет, как исполняемый файл может обрабатывать конкретные данные при помощи SyncML DM. Команда ехес содержит элемент item, в котором находится элемент target, который в свою очередь содержит элемент LocURI. Элемент LocURI указывает расположение в устройстве указанного исполняемого файла. Следовательно, команда ехес не допускает конкретно указывать данные, которые должны быть использованы исполняемым файлом.

Более того, команда ехес требует идентификации подходящего исполняемого файла на целевом устройстве. Следовательно, необходимо заранее идентифицировать указанный исполняемый файл на целевом устройстве, что определяется элементом LocURI в составе команды ехес. Такая схема чрезмерно сложна и неудобна и, кроме того, не позволяет использовать единое сообщение или пакет SyncML на нескольких мобильных устройствах.

Итак, необходимо создать код SyncML, обеспечивающий выполнение одного процесса на множестве целевых устройств и при этом не требующий адаптации под каждое конкретное устройство.

Также необходимо разработать исполняемый файл, которым обрабатывались бы конкретные данные при помощи кода SyncML и который допускал бы повторное использование на других устройствах.

КРАТКОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Согласно одному из вариантов осуществления изобретения разработан способ автоматического конфигурирования электронных устройств, включающий прием электронным устройством команды, идентифицирующей первые данные; автоматическое определение свойства идентифицированных первых данных; автоматическую идентификацию исполняемого файла, исходя из указанного определенного свойства; и обработку указанных идентифицированных первых данных указанным идентифицированным исполняемым файлом.

Согласно другому варианту осуществления изобретения разработан способ конфигурирования мобильных сотовых телефонов, включающий передачу на мобильный сотовый телефон кода, содержащего команду, причем указанная команда идентифицирует первый краевой узел иерархической узловой структуры данных; определение свойства указанного идентифицированного первого краевого узла; идентификацию исполняемого файла, исходя из указанного определенного свойства; и обработку данных, хранящихся в указанном идентифицированном первом краевом узле, при помощи идентифицированного исполняемого файла.

Согласно еще одному варианту осуществления изобретения разработан способ конфигурирования мобильных сотовых телефонов, включающий:

передачу допускающего многократное использование кода на мобильный сотовый телефон, при этом указанный код содержит команды для создания на указанном электронном устройстве иерархической узловой структуры данных, включающей краевые узлы и внутренние узлы, которая включает первые данные, хранящиеся в первом краевом узле, и первую команду, идентифицирующую указанный первый краевой узел;

определение свойства указанного идентифицированного первого краевого узла;

идентификацию исполняемого файла, исходя из определенного свойства;

и обработку указанных первых данных, хранящихся в указанном первом краевом узле, при помощи идентифицированного исполняемого файла.

Согласно еще одному варианту осуществления изобретения разработан мобильный сотовый телефон, обеспечивающий автоматическое конфигурирование и включающий средства для хранения первых данных; средства для приема команды, идентифицирующей указанные первые данные; средства для определения свойства идентифицированных первых данных; средства идентификации исполняемого файла, исходя из указанного определенного свойства; и средства обработки указанных идентифицированных первых данных при помощи указанного идентифицированного исполняемого файла.

Согласно еще одному варианту осуществления изобретения разработана структура данных с возможностью повторного использования при конфигурировании различных мобильных сотовых телефонов, содержащая код, идентифицирующий первые данные и задающий выполнение неидентифицированного исполняемого файла на указанных первых данных.

Согласно еще одному варианту осуществления изобретения разработана структура данных с возможностью повторного использования при конфигурировании различных электронных устройств, содержащая команды для создания на электронном устройстве иерархической узловой структуры данных, имеющей краевые и внутренние узлы, которая содержит первые данные, хранящиеся в первом краевом узле; первую команду, идентифицирующую первый краевой узел, которая задает выполнение неидентифицированного исполняемого файла на указанных первых данных, находящихся в указанном первом краевом узле.

Варианты осуществления настоящего изобретения могут обеспечить возможность выполнения резидентного исполняемого файла на целевом устройстве без идентификации такого исполняемого файла. Поскольку резидентные исполняемые файлы, находящиеся на разных устройствах, могут отличаться друг от друга, таким образом обеспечивается возможность повторного использования кода SyncML для выполнения одного и тоже процесса на различных целевых устройствах.

Варианты осуществления настоящего изобретения позволяют обрабатывать заданные данные резидентным исполняемым файлом, находящимся на целевом устройстве.

Согласно еще одному варианту осуществления изобретения разработана система для создания структуры данных с возможностью повторного использования при конфигурировании различных электронных устройств, содержащая средства для связывания каждой из множества удобных для пользователя команд с различными частями кода, каждая из которых содержит одну или более команду.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Для облегчения понимания настоящего изобретения далее, только в качестве примеров, будут приведены ссылки на прилагающиеся чертежи, на которых:

Фиг.1 изображает систему клиент - сервер, содержащую мобильное устройство, которое обменивается информацией с сервером 20;

Фиг.2 изображает структуру данных древа иерархии;

Фиг.3 изображает сигнальную диаграмму для загрузки кода конфигурирования; и

Фиг.4 схематично изображает содержание кода 50 конфигурирования.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Фиг.1 изображает систему 2 клиент-сервер, содержащую мобильное устройство 10, обменивающееся данными через сотовую сеть 18 радиосвязи с сервером 20. Мобильное устройство 10, в данном варианте осуществления изобретения мобильный сотовый телефон, содержит процессор 11, приемопередатчик 12 системы сотовой радиосвязи, память 13, устройство 14 ввода, например, кнопочный номеронабиратель, дисплей 15, смарт-карту 16 и устройство 17 вывода звука.

Процессор 11 управляет мобильным телефоном 10 и способен считывать и записывать данные в память 13. Также он получает данные ввода с кнопочного номеронабирателя 14 и передает данные вывода на дисплей 15 и устройство 17 вывода звука. Кроме этого, он управляет приемопередатчиком системы сотовой радиосвязи, благодаря чему последний способен обмениваться данными с сетью 18 радиосвязи, которая может, например, представлять собой сеть GSM или WCDMA. Процессор также соединен со смарт-картой 16, которая по меньшей мере служит для передачи процессору идентификационной пользовательской информации, например, номера телефона пользователя или IMSI. Работой процессора 11 управляет программное обеспечение, хранящееся в памяти 13 и загруженное в упомянутый процессор. В ходе работы процессор получает и передает данные через приемопередатчик 12, и записывает, и считывает данные из памяти 13.

Следует также понимать, что в других вариантах осуществления изобретения указанный мобильный сотовый телефон может не иметь смарт-карты 16 и/или может иметь несколько процессоров.

Сервер 20 содержит интерфейс 21 ввода/вывода, подключенный к сотовой сети 18 радиосвязи напрямую или опосредованно, процессор 22 и память 23. Сервер 20 представляет собой сервер SyncML DM. Он отправляет команды SyncML DM мобильному телефону 10 через интерфейс 21 ввода/вывода и надлежащим образом интерпретирует ответные сигналы указанного телефона 10.

Процессор 11 телефона 10 выполняет функции клиента управления (МС, management client) и способен поддерживать в памяти 13 структуру 100 данных древа управления, клиент управления (МС) надлежащим образом интерпретирует команды SyncML DM, полученные от указанного сервера, и выполняет соответствующие действия на телефоне 10, а также отсылает соответствующие ответные сигналы серверу управления через приемопередатчик 12.

Древо управления представляет собой иерархическую узловую структуру данных, посредством которой указанный клиент управления взаимодействует с мобильным телефоном 10. Клиент управления (МС) может хранить или извлекать данные из древа и управлять свойствами древа. На указанном древе иерархии имеются узлы, которые соединены ветвями. Каждому узлу может быть присвоен уникальный URI (Uniform Resource Identifier, универсальный идентификатор ресурса). Узел может являться либо внутренним узлом, который может иметь любое количество узлов-потомков (подчиненных узлов), но не может хранить какие-либо данные, либо может быть краевым узлом, который не может иметь узлов-потомков (подчиненных узлов), но может хранить данные. Под данными подразумевается строка символов, файл, число и т.д.

Как уже было сказано, древом управляет клиент управления (МС). Им могут быть созданы новые узлы или же могут быть изменены данные, хранящиеся в определенных краевых узлах. К краевым и внутренним узлам осуществляется синхронный доступ в режиме реального времени.

Как будет более подробно описано далее, клиент управления (МС) в ответ на получение от сервера 20 кода конфигурирования создает объект управления "оператора", и этот объект является частью автоматического процесса конфигурирования (настройки). Как показано на фиг.3, этот объект 102 управления "оператора" может представлять собой, как в данном примере, поддрево, зависимое от корневого каталога 104 древа 100 управления, и используется в ходе процесса конфигурирования.

Автоматический процесс конфигурирования может быть инициирован, например, путем установки смарт-карты 16 в сотовый мобильный телефон 10. Смарт-карта 16 содержит информацию, необходимую для самозагрузки автоматического процесса конфигурирования. Далее мобильное устройство 10 отправляет серверу 20 сообщение 60 об инициировании загрузки, как показано на фиг.3.

Указанный сервер 20 хранит в памяти 23 код 50 конфигурирования, который может использоваться с различными устройствами без адаптации. Далее сервер 20 в ответ на сообщение об инициировании загрузки инициирует сессию 62 управления данными SyncML Data Management (DM). Указанная сессия 62 DM используется для передачи хранящего в памяти кода 50 на мобильное устройство 10.

Сообщение 60 об инициировании загрузки может быть отправлено через любые подходящие средства, например, как сообщение службы коротких сообщений (Short Message Service, SMS) или, если указанное устройство представляет собой КПК без мобильной телефонии, через инфракрасный порт, Bluetooth или через последовательное соединение, например, USB.

Упомянутый выше код конфигурирования может быть также отправлен через любые подходящие средства, например сообщение службы коротких сообщений (Short Message Service, SMS) или, если указанное устройство представляет собой КПК без мобильной телефонии, через инфракрасный порт, Bluetooth или через последовательное соединение, например, USB.

На фиг.4 схематично показан код 50 конфигурирования. Код 50 представляет собой структуру данных, предназначенную для повторного использования при настройке различных мобильных устройств.

Код 50 в данном примере включает две части, которые логически разделены, но при этом могут перемежаться. Имеется первая часть 52 для создания древа управления или обновления существующего древа управления. Вторая часть 54 предназначена для выполнения исполняемых файлов.

Указанная первая часть 52, предназначенная для обновления существующего древа управления, содержит подраздел для создания внутренних узлов древа управления, и еще один подраздел для создания краевых узлов древа управления.

Например, при помощи XML-кода, аналогичного приведенному ниже, может быть создан внутренний узел 'оператор' 106, зависимый от корневого каталога 104:

<Add>

<CmdlD> 1</CmdlD> <Item>

<Meta>

<Format xmlns='syncml:metinf'> node /<Format>

<Type xmlns='syncml:metinf'> interior/<Type>

</Meta>

<Target>

<LocURI> /Operator </LocURI> </Target>

</Item>

</Add>

Далее, например, при помощи еще одного XML-кода, аналогичного приведенному ниже, может быть создан внутренний узел 'оператор' 108, зависимый от узла "оператор" 106:

<Add>

<CmdlD> 2</CmdlD>

<Item>

<Meta>

<Format xmlns='syncml:metinf'> node /<Format>

<Type xmlns='syncml:metinf'> interior /<Type>

</Meta>

<Target>

<LocURI> /Operator/ring_tones</LocURI>

</Target>

</Item>

</Add>

Также, например, при помощи XML-кода, аналогичного приведенному ниже, может быть создан краевой узел 110, зависимый от узла 108:

<Add>

<CmdlD> 3</CmdlD>

<Item>

<Meta>

<Format xmlns='syncml:metinf'> format /<Format>

<Type xmlns='syncml:metinf'> MIDI ringing tone /<Type> </Meta>

<Target>

<LocURI> /Operator/ring_tones/smashhit#1 </LocURI> </Target>

<Data> the data </Data>

</Item>

</Add>

где the data представляют собой данные для создания мелодии звонка smashhit#1 в формате, определенном командой format.

Вторая часть 54, предназначенная для выполнения исполняемых файлов, содержит несколько подразделов, каждый из которых предназначен для выполнения какого-либо исполняемого файла. Порядок расположения подразделов определяет порядок выполнения исполняемых файлов. При этом по меньшей мере некоторые из этих подразделов указывают, что исполняемый файл выполняется с использование определенных данных. Например, XML-код такого подраздела может выглядеть аналогично приведенному ниже:

<Ехес>

<CmdID> 3</CmdID>

<Item>

<Source>

<LocURI>/Operator/ring_tones/smashhit#1 </LocURI>

</Source>

</Item>

</Add>

Данная команда ехес запускает выполнение неидентифицированного исполняемого файла на данных, находящихся в 'source', то есть для мелодии звонка smashhit#1. Следует отметить, что команда Ехес не указывает, какой исполняемый файл должен использоваться при этом, и значение команды зависит от типа содержимого указанных данных, на которые она указывает.

Клиент DM мобильного сотового телефона обрабатывает принятый код 50 конфигурирования. Далее, согласно спецификациям SyncML DM, обрабатывается часть 52. Таким образом, клиент DM создает, согласно приведенному примеру, зависимое от корневого каталога поддерево 102, как показано на фиг.2.

Далее изложено, как обрабатывается часть 54, предназначенная для выполнения исполняемых файлов. Сначала проводят синтаксический анализ кода для идентификации первого подраздела. Указанный первый подраздел анализируют далее для нахождения URI, заданного элементом LocURI, находящимся в элементе source. Указанный элемент LocURI идентифицирует краевой узел на созданном поддереве древа управления.

Клиент DM осуществляет доступ к идентифицированному краевому узлу, которым в приведенном примере является Operator/ring_tones/smashhit#1. Далее клиент считывает свойства указанного идентифицированного краевого узла и, в частности, свойства, находящиеся в элементе meta.

Для идентификации типа содержимого, хранящегося в данных в идентифицированном краевом узле, клиент DM использует содержимое элемента Format и/или содержимое элемента Type.

Указанный клиент DM осуществляет привязку возможных элементов Format и Type к различным резидентным исполняемым файлам в памяти мобильного телефона при помощи, например, таблицы соответствия. Таким образом, клиент DM при помощи элементов Format и/или Type краевого узла может ставить в соответствие указанному идентифицированному краевому узлу некий исполняемый файл. Таким образом, если в краевом узле хранится звуковой файл, ему ставится в соответствие аудиопроигрыватель, если в краевом узле хранится видеофайл, ему ставится в соответствие видеопроигрыватель, если файл с изображением, то программа просмотра изображений, если Java Midlet, то виртуальная машина Java (Java Virtual Machine, JVM), если в узле хранится информация о контакте, то ему ставится в соответствие исполняемый файл, который добавляет эту информацию в список контактов телефона, и, наконец, если в узле хранится закладка, то ей ставится в соответствие исполняемый файл, при помощи которого указанную закладку добавляют в список закладок (избранное), и т.д.

В SyncML DM используют ряд команд, включая следующие:

Add: При отправке этой команды отправителем к данным, доступным получателю, добавляется элемент данных или элементы данных, указанные командой. Например, при отправке такой команды с сервера на мобильное оконечное устройство она может добавить к древу DM новый узел.

Copy: При отправке этой команды отправителем выполняется копирование элемента данных или элементов данных, указанных командой и доступных получателю.

Delete: При отправке этой команды отправителем удаляется элемент данных или элементы данных, указанные командой и доступные получателю. Например, при отправке такой команды с сервера на мобильное оконечное устройство она может удалить из древа DM какой-либо узел.

Ехес: При поступлении от отправителя команды Ехес получатель запускает указанный командой или прилагающийся исполняемый файл.

Get: При подаче этой команды отправителем выполняется запрос элемента или элементов данных у получателя. Например, при отправке такой команды с мобильного оконечного устройства на сервер он может получить содержимое определенного узла древа DM.

Replace: При подаче такой команды отправителем выполняется замена элемента (ов) данных, доступного получателю.

Следует отметить, что каждая команда SyncML DM имеет определенный синтаксис. Оператору желательно иметь возможность создавать соответствующий код 50, не обладая глубокими знаниями команд SyncML DM и их синтаксиса. Для этого может быть предусмотрена специальная компьютерная программа, находящаяся на сервере 20. Указанная компьютерная программа фактически создает макрос, который превращает удобные для пользователя команды в соответствующие команды SyncML DM, при этом обеспечивая правильность синтаксиса.

Указанная компьютерная программа может, например, предоставлять оператору следующие опции:

a) Установить Х

b) Предпросмотр Х (с установкой)

c) Предпросмотр Х (без установки)

d) Выполнение Х (при условии установки)

При помощи упомянутой компьютерной программы эти варианты действий превращаются в следующие команды SyncML соответственно:

a) Add

b) Add, а затем Ехес

c) Add, Ехес и затем Delete.

d) Ехес

Хотя варианты осуществления настоящего изобретения были описаны выше со ссылками на различные примеры, следует понимать, что возможно внесение изменений в приведенные примеры в объеме изобретения, который определяется формулой изобретения. Например, хотя изобретение было описано на примере мобильного телефона, следует понимать, что возможно его применение в любом другом настраиваемом пользователем электронном устройстве. То есть одним из частных вариантов применения изобретения являются мобильные устройства, такие как мобильные телефоны и КПК, но также оно может применяться, к примеру, в персональных компьютерах.

Хотя в приведенном выше описании изобретения была сделана попытка обратить внимание на те особенности настоящего изобретения, которые считались наиболее важными, следует понимать, что в объем изобретения входят любые патентоспособные особенности, на которые даны ссылки в приведенном выше описании и/или которые были показаны на чертежах, вне зависимости от того, были они выделены особо или нет.

Изобретение относится к способу и системе автоматического конфигурирования электронного устройства, в частности мобильного сотового телефона. Техническим результатом является расширение функциональных возможностей. Способ включает прием электронным устройством команды, задающей выполнение неидентифицированного исполняемого файла на первых данных; автоматическое определение типа содержимого первых данных; автоматическую идентификацию исполняемого файла, исходя из указанного определенного типа, и обработку идентифицированных первых данных с использованием идентифицированного исполняемого файла. Система реализует операции способа. 18 н. и 21 з.п. ф-лы, 4 ил.

1. Способ конфигурирования электронного устройства, включающий:
прием электронным устройством команды, задающей выполнение неидентифицированного исполняемого файла на первых данных;
автоматическое определение типа содержимого первых данных по метаданным первых данных;
автоматическую идентификацию исполняемого файла с использованием типа содержимого, определенного по указанным метаданным; и
обработку первых данных с использованием идентифицированного исполняемого файла.

2. Способ по п.1, в котором упомянутая команда содержит идентификатор первых данных.

3. Способ по п.2, в котором указанный идентификатор определяет узел иерархической узловой структуры данных.

4. Способ по п.3, в котором указанная команда представляет собой команду ехес, а указанный идентификатор представляет собой универсальный идентификатор ресурса (URI), находящийся в элементе source, который содержится в команде ехес.

5. Способ по п.1, в котором указанную команду принимают как XML-код.

6. Способ по п.5, в котором указанная команда является командой SyncML.

7. Способ по п.1, в котором указанные первые данные хранят в мобильном устройстве.

8. Способ по п.5, в котором первые данные хранят в первом краевом узле иерархической узловой структуры данных.

9. Способ по п.8, в котором метаданные связаны с первым краевым узлом и идентифицируют тип содержимого первых данных, хранимых в первом краевом узле иерархической структуры данных.

10. Способ по п.1, в котором на этапе определения типа содержимого используют по меньшей мере одно из значений элемента Format и/или значение элемента Type, связанные с первыми данными.

11. Способ по п.1, включающий привязку различных исполняемых файлов к каждому из различных типов содержимого.

12. Способ по п.11, в котором этап автоматической идентификации исполняемого файла по типу содержимого включает идентификацию исполняемого файла, связанного с типом содержимого, который определен по метаданным.

13. Способ по п.12, в котором в указанном электронном устройстве хранят множество различных исполняемых файлов.

14. Способ по п.1, также включающий, перед приемом команды задающей выполнение неидентифицированного исполняемого файла на первых данных, прием команд для создания иерархической узловой структуры данных, включающей указанные первые данные в электронном устройстве.

15. Способ конфигурирования электронного устройства, включающий:
передачу кода, содержащего команду, в электронное устройство, при этом указанная команда задает выполнение неидентифицированного исполняемого файла на первых данных, хранимых в первом краевом узле иерархической узловой структуры данных;
определение типа содержимого идентифицированных первых данных по метаданным идентифицированного первого краевого узла;
идентификацию исполняемого файла с использованием типа содержимого, определенного по метаданным идентифицированного первого краевого узла; и
обработку первых данных, хранящихся в указанном первом краевом узле, при помощи идентифицированного исполняемого файла.

16. Способ конфигурирования электронного устройства, включающий:
прием электронным устройством кода, допускающего многократное использование, причем указанный код содержит:
команды для создания в электронном устройстве иерархической узловой структуры данных, имеющей краевые и внутренние узлы, которая содержит первые данные, хранящиеся в первом краевом узле; и
дополнительную команду, задающую выполнение неидентифицированного исполняемого файла на первых данных, хранимых в первом краевом узле;
определение типа содержимого первых данных, хранимых в первом краевом узле, по метаданным, хранимым в первом краевом узле;
идентификацию исполняемого файла с использованием типа содержимого, определенного по метаданным, хранимым в первом краевом узле; и
обработку указанных первых данных, хранимых в указанном первом краевом узле, при помощи идентифицированного исполняемого файла.

17. Приемное электронное устройство, содержащее:
память для хранения первых данных и их метаданных;
приемник для приема команды, задающей выполнение неидентифицированного исполняемого файла на первых данных; и процессор, способный определять тип содержимого первых данных по их метаданным, идентифицировать исполняемый файл с использованием типа содержимого, определенного по метаданным, и обрабатывать первые данные при помощи идентифицированного исполняемого файла.

18. Электронное устройство по п.17, в котором приемник выполнен с возможностью приема кода конфигурирования, а процессор способен интерпретировать принятый код конфигурирования для создания иерархической узловой структуры данных, имеющей краевые и внутренние узлы, которая содержит первый краевой узел, в котором хранятся упомянутые первые данные.

19. Электронное устройство по п.18, в котором процессор способен принимать команду в коде конфигурирования и интерпретировать команду для определения типа содержимого первых данных по их метаданным.

20. Электронное устройство по п.17, которое представляет собой мобильный телефон.

21. Память, хранящая структуру данных, включающую:
код, идентифицирующий первые данные и задающий выполнение неидентифицированного исполняемого файла на первых данных.

22. Память по п.21, в которой указанный код также задает передачу упомянутых первых данных в электронное устройство.

23. Память, хранящая структуру данных, включающую:
команды для создания в электронном устройстве иерархической узловой структуры данных, имеющей краевые узлы и внутренние узлы, которая содержит первые данные, которые хранятся в первом краевом узле; и
дополнительную команду, идентифицирующую указанный первый краевой узел, задающую выполнение неидентифицированного исполняемого файла на первых данных, хранящихся в указанном первом краевом узле.

24. Способ конфигурирования электронного устройства, включающий использование структуры данных по п.21, или 22, или 23.

25. Способ настройки электронного устройства, включающий настройку электронного устройства с использованием структуры данных по п.21, или 22, или 23.

26. Способ настройки множества электронных устройств, включающий повторное использование указанной структуры данных по п.21, или 22, или 23 для конфигурирования различных электронных устройств.

27. Сервер для хранения и передачи структуры данных по п.21, или 22, или 23.

28. Приемное электронное устройство, содержащее:
средства для хранения первых данных;
средства для приема команды, задающей выполнение неидентифицированного исполняемого файла на первых данных;
средства для определения типа содержимого указанных идентифицированных первых данных по метаданным;
средства для идентификации исполняемого файла с использованием типа содержимого, определенного по метаданным; и
средства для обработки идентифицированных данных при помощи идентифицированного исполняемого файла.

29. Приемное электронное устройство по п.28, которое представляет собой мобильный телефон.

30. Способ конфигурирования электронного устройства, включающий:
передачу кода, идентифицирующего первые данные и задающего выполнение неидентифицированного исполняемого файла на указанных первых данных.

31. Способ настройки электронного устройства, включающий:
передачу команд для создания иерархической узловой структуры данных, имеющей краевые узлы и внутренние узлы, которая содержит первые данные, которые хранятся в первом краевом узле; и
передачу дополнительной команды, задающей выполнение неидентифицированного исполняемого файла на первых данных, хранящихся в указанном первом краевом узле.

32. Сервер, содержащий:
память для хранения кода, идентифицирующего первые данные и задающего выполнение неидентифицированного исполняемого файла на указанных первых данных.

33. Сервер по п.32, в котором указанный код предназначен для настройки электронного устройства.

34. Сервер по п.32 или 33, в котором указанный код предназначен для повторного использования при настройке различных электронных устройств.

35. Сервер, содержащий: память для хранения команд, предназначенных для создания в электронном устройстве иерархической узловой структуры данных, имеющей краевые и внутренние узлы, которая содержит первые данные, хранящиеся в первом краевом узле, и для хранения первой команды, идентифицирующей первый краевой узел, которая запускает выполнение неидентифицированного исполняемого файла на первых данных, хранящихся в указанном первом краевом узле.

36. Память, хранящая программное обеспечение, содержащее:
средства для автоматического определения типа содержимого первых данных по их метаданным;
средства для автоматической идентификации исполняемого файла с использованием типа содержимого, определенного по метаданным; и
средства для обеспечения возможности обработки указанных первых данных при помощи указанного идентифицированного исполняемого файла.

37. Способ конфигурирования электронного устройства, включающий:
прием электронным устройством первой команды, которая задает создание краевого узла в иерархической структуре данных, идентифицирует первые данные, предназначенные для хранения в этом краевом узле, и метаданные, указывающие тип содержимого первых данных;
создание краевого узла в электронном устройстве;
прием электронным устройством второй команды, которая задает выполнение неидентифицируемого исполняемого файла на первых данных, хранимых в созданном краевом узле;
определение типа содержимого данных по метаданным;
идентификацию исполняемого файла с использованием типа содержимого, определенного по метаданным; и
обработку первых данных при помощи идентифицируемого исполняемого файла.

38. Приемное электронное устройство, содержащее:
приемник, конфигурированный для приема электронным устройством первой команды, которая задает создание краевого узла в иерархической структуре данных и идентифицирует первые данные, предназначенные для хранения в этом краевом узле, и метаданные, указывающие тип содержимого первых данных; и
процессор, конфигурированный для создания краевого узла в электронном устройстве;
при этом приемник также конфигурирован для приема второй команды, которая задает выполнение неидентифицированного исполняемого файла на первых данных, хранимых в созданном краевом узле;
а процессор также конфигурирован для определения типа содержимого первых данных по метаданным, для идентификации исполняемого файла с использованием типа содержимого, определенного по метаданным, и для обработки первых данных при помощи идентифицированного исполняемого файла.

39. Приемное электронное устройство по п.28, которое представляет собой мобильный телефон.