Определение узлов управления в системе управления устройством

Иллюстрации

Показать все

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

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение касается определения узлов управления, которые используются в управлении устройством в системе управления устройством.

УРОВЕНЬ ТЕХНИКИ

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

Одним стандартом управления устройством является управление устройством OMA (открытый мобильный альянс), которое частично основано на протоколе SyncML. Управление устройством OMA также включает технологию инициализации клиента OMA CP, в котором конфигурация передается на клиентское устройство, используя технологию инициализации. Управление устройством (OMA DM), основанное на технологии SyncML, является, в свою очередь, двунаправленной технологией. PC (персональный компьютер), например, может служить сервером управления устройством, и мобильная станция может служить клиентом управления устройством. Функционирующее клиентское устройство, как клиент в сеансе, с точки зрения управления устройством, посылает информацию относительно себя на сервер управления, выполняющий управление устройством, в сообщении инициализации сеанса, и сервер управления отвечает ему, посылая свою собственную информацию, так же, как и команды управления сервером. Клиентское устройство отвечает им информацией состояния, после которой сервер может закончить сеанс или послать больше команд управления устройством. Если сервер посылает больше команд управления, клиентское устройство должно ответить им информацией состояния. После приема информации состояния сервер всегда может закончить сеанс, или это может продолжить сеанс, передавая больше команд управления устройством. Управление устройством может также быть осуществлено таким способом, что сначала пользователю посылают вопросы о том, что он желает обновить, а затем информацию относительно выбора пользователя посылают серверу. После этого сервер в следующем пакете может передать обновление/операции, которые желает пользователь.

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

В управлении устройством OMA объекты управления размещены в форме дерева, т.e. как дерево управления, проиллюстрированное на фиг.1. Дерево управления сформировано из узлов, и объект управления является поддеревом к дереву управления и может быть сформирован из одного или более узлов. После этого мы имеем дело с узлами, формирующими объект управления. Узлом может быть единственный параметр, поддерево или совокупность данных. Например, узел “Поставщик” является внутренним узлом, потому что он имеет дочерние узлы “Экранная заставка” и “Тоны звонка”. Узел “Экранная заставка” является краевым узлом, потому что он не имеет никаких дочерних узлов. Также узел “Тоны звонка” является внутренним узлом, потому что он имеет дочерние узлы. Содержание узла может также быть ссылкой, обращающейся к другому узлу. К каждому узлу можно обратиться по URI (унифицированный идентификатор ресурса). URI узла формируются, начинаясь с корня “/”, и при продвижении вперед по дереву каждый узел имеет имя, которое добавляется к предыдущим узлам, используя “/” как разделяющий признак. Например, к узлу “Тоны звонка” можно обратиться идентификатором URI “/Vendor/Ringing Tones/”. Узлы могут быть постоянными или динамическими. Динамические узлы можно добавить из клиентского устройства или сервера управления.

Имя (которое функционирует как адрес) должно быть распределено в дереве управления новому динамическому узлу для информации, содержавшейся в дереве управления, чтобы быть доступной и серверу управления, и клиентскому устройству. Если имя узла, который будет добавлен к дереву управления, выбрано в клиентском устройстве, то же самое имя не было установлено для узла в сервере управления, посредством чего команды управления, данные сервером управления, не могут быть осуществлены. В особенности в устройствах, использующих технологию инициализации клиента, узлы, содержавшиеся в сообщениях начальной загрузки, должны быть размещены, некоторым способом, в дереве управления, или узлы также не могут быть обязательно сохранены, но по меньшей мере имя узла должно, обычно, определяться в клиентском устройстве. Таким образом, в некоторых случаях клиентское устройство должно изменить дерево управления. Как представлено в спецификации OMA “SyncML Device Management Tree and Description”, версия 1.1.1; 2 октября 2002 г.; 48 страниц, глава 7, сервер управления может запросить часть дерева управления из клиентского устройства в случае, когда клиентское устройство отвечает с помощью передачи части дерева управления, которое требует сервер управления. Однако сервер управления не обязательно был способен затребовать дерево управления, даже если оно изменилось в клиентском устройстве. Это также может иметь место, если клиентское устройство изменило дерево управления таким способом, что на запрос сервера управления нельзя ответить, поскольку требуемая часть не существует или она имеет другое имя.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

фиг.1 иллюстрирует дерево управления;

фиг.2 иллюстрирует систему управления;

фиг.3 иллюстрирует сервер и клиентское устройство;

фиг.4a и 4b иллюстрируют способ согласно варианту осуществления изобретения;

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

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

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

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

Фиг.2 иллюстрирует два примера, в первом из которых клиентское устройство TE и серверы управления S связаны с локальной сетью LAN. Клиентское устройство TE, связанное с сетью LAN, включает функциональные возможности, например сетевую интерфейсную карту и программное обеспечение, которое управляет передачей данных, связанные с устройствами в сети LAN. Локальная сеть LAN может быть локальной сетью любого типа, и TE может также связываться с сервером S через сеть Интернет, обычно используя межсетевую защиту FW. Терминал TE может также быть связан с локальной сетью LAN беспроводным способом через точку доступа AP.

Во втором примере терминал TE связывается с сервером S через мобильную сеть MNW. Терминал TE, связанный с сетью MNW, включает мобильные функциональные возможности станции для связи с сетью MNW беспроводным способом. Дополнительно могут быть другие сети типа локальной сети LAN между мобильной сетью MNW и сервером S.

Мобильная сеть MNW может быть любой известной беспроводной сетью, например сетью, поддерживающей службу GSM, сетью, поддерживающей службу GPRS (служба пакетной радиосвязи общего назначения), мобильной сетью третьего поколения, т.е. сетью, соответствующей сетевым спецификациям 3GPP (3-е поколение проекта партнерства), беспроводной локальной сетью WLAN, частной сетью или комбинацией сетей. Во многих мобильных сетях важной службой транспортного уровня является WAP, который содержит уровень WSP (беспроводной сеансовый протокол), посредством которого уровень приложений административных устройств может быть обеспечен транспортной службой в клиентском устройстве TE и сервере S. В таком случае, система включает один по меньшей мере шлюз WAP и, возможно, один или несколько посредников WAP. WAP поддерживает несколько способов передачи нижнего уровня типа гипертекстового транспортного протокола или стандартов OBEX. Методы передачи нижнего уровня могут использоваться в случае, подобном передаче данных с коммутацией каналов или с коммутацией пакетов или передаче на основе SMS в соответствии со свойствами основной мобильной сети MNW. В дополнение к этому в вышеупомянутых примерах выполнимы также другие конфигурации управления устройством типа управляющего соединения между TE и сервером S с использованием проводного или беспроводного подключения непосредственно без других сетевых элементов.

Как показано на фиг.3, терминал TE и сервер S содержат память MEM, в терминале и в сервере (SMEM); интерфейс пользователя (ИП, UI) в терминале и в сервере (SUI); I/O, означающее ввод-вывод (В/В) в терминале и в сервере (SI/O) для упорядочивания передачи данных; и центральный процессорный модуль (ЦПМ, CPU), включающий один или более процессоров. Память MEM, SMEM включает энергонезависимую часть центрального процессорного модуля CPU в терминале и в сервере (SCPU) для сохранения приложений управления и других данных, необходимых для сохранения, и энергозависимую часть, которая используется для временной обработки данных. Объекты управления сохраняются в памяти MEM TE, и также поддерживается дерево управления с их структурой в памяти SMEM сервера S. TE, функционирующий как клиентское устройство согласно стандарту управления устройством OMA, содержит коммуникационный адаптер агента клиента, который является ответственным за функции, относящийся к сеансу управления в клиентском устройстве. Устройство S, функционирующее как сервер управления, содержит агент сервера (АС, SA) или управляющее устройство сервера (УУС, SM), обслуживающий сеанс управления. Агент клиента (АК, CA) может быть осуществлен с помощью выполнения в CPU кода компьютерной программы, сохраненной в памяти MEM, тогда как SA может быть осуществлен с помощью выполнения в SCPU кода компьютерной программы, сохраненной в памяти SMEM. Как отмечено ранее, TE и S могут функционировать как сервер управления и/или клиентское устройство. Таким образом, например, терминал TE может также содержать по меньшей мере часть функций агента сервера SA, в этом случае он может функционировать как сервер управления при синхронизации между терминалами TE. Соответственно, посредством кодов компьютерной программы, выполняемых в центральном процессорном модуле CPU, SCPU, терминал TE и сервер S могут быть вызваны для осуществления средств изобретения, связанных с определением узлов управления и информированием об этом. Некоторые варианты осуществления этих средств изобретения проиллюстрированы на фиг.4 и 5. Компьютерная программа может быть сохранена в любом средстве памяти, например на жестком диске персонального компьютера или CD-ROM, из которого она может быть загружена в память MEM, SMEM, выполняя ее. Компьютерная программа может также быть загружена через сеть, например, с использованием стека протокола TCP/IP. Также аппаратные решения или комбинации аппаратных и программных решений могут использоваться для осуществления средств изобретения. Структура данных, содержащая описание устройства, может быть передана в сервер S через сеть передачи данных и сохранена в памяти на сервере S.

Фиг.4a и 4b иллюстрируют способ согласно изобретению для обновления дерева управления устройством. Фиг.4a иллюстрирует функции, осуществленные в клиентском устройстве типа терминала TE и более подробно в агенте клиента CA, содержащегося в нем. На этапе 400 узел (управления) определен в клиентском устройстве, т.e. по меньшей мере часть свойств узла определена независимо в клиентском устройстве. Узлом может быть любой динамический узел в дереве управления. Этап 400 может быть введен, когда создается полностью новое дерево управления, новый узел добавляется к дереву управления или узел, уже содержащийся в дереве управления, изменяется. В соответствии с вариантом осуществления этап 400 выполняется немедленно после того, как сообщение, включающее в себя информацию управления устройством, было принято, когда клиентское устройство должно определить имя для по меньшей мере одного узла. Это сообщение может быть любым сообщением инициализации, которое содержит информацию управления устройством, например сообщение управления устройством OMA. Сообщение начальной загрузки также является одним из сообщений инициализации, используемых для начальной инициализации устройства. Также пользователь может определить свойства одного или более узлов. Пользователь может изменить дерево управления, например, изменяя структуру каталога или переименовывая файлы, которые содержат параметры настройки.

На этапе 401 дерево управления обновляется определенным узлом. Это означает изменение информации относительно любого узла или добавление структуры данных, определяющей новый внутренний узел или краевой узел и упорядочивающей управление доступом в нем. После этого клиентское устройство использует измененное дерево управления, например, в более позднем сеансе управления устройством. На этапе 402 по меньшей мере информация узла, определенная в клиентском устройстве, передается на по меньшей мере один сервер управления, и на эту информацию впоследствии ссылаются как на информацию свойства. Необходимо отметить, что информация свойства может быть передана на тот же самый сервер управления, от которого команда управления, касающаяся этого конкретного узла, была принята, и/или на один или несколько других серверов управления. В соответствии с одним вариантом осуществления информация относительно обновления узла передается на те серверы управления, которые определены в ACL (список контроля доступа) узла. Позже будут описаны различные альтернативы для передачи этой информации. Необходимо отметить, что клиентское устройство может быть выполнено с возможностью выполнения этапа 402 немедленно после того, как узел был создан, или изменился устройством клиента, или на основании проверки, выполненной на более поздней стадии, например, перед установлением сеанса управления устройством. На этапе 402 вся информация, касающаяся узла, определенного устройством клиента, или даже все узлы дерева управления могут быть переданы.

Фиг.4b, в свою очередь, иллюстрирует функции, выполняемые в сервере управления. На этапе 410 информацию свойства относительно по меньшей мере одного узла принимают от клиентского устройства, т.e. по меньшей мере информацию свойства узла, которую клиентское устройство определило. Сервер управления выполнен с возможностью определения обновлений и/или добавлений, сделанных к информации управления устройством клиента на основе сообщения, принятого от клиентского устройства в соответствии с информацией, содержащейся в сообщении. На этапе 411 сервер управления обновляет и/или добавляет определенную клиентом информацию управления (где определена информация, соответствующая дереву управления устройством клиента) на основе принятой информации свойства узла. Позже, когда клиентское устройство должно управляться и особенно, когда есть потребность обратиться к узлу, измененному на этапе 411, команды управления, которые будут переданы в клиентское устройство, формируются на этапе 412 в соответствии с обновленной информацией управления.

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

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

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

Клиентское устройство может быть выполнено с возможностью передачи любой информации свойства узла, когда сервер управления выполнен с возможностью обновления дерева управления, которое он поддерживает. Другие свойства узла, соответствующие управлению устройства OMA, описаны в спецификации OMA “SyncML Device Management Tree and Description”, версия 1.1.1; 2 октября 2002 г., 48 страниц.

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

Как представлено в вышеупомянутой спецификации управления устройством OMA “SyncML Device Management Tree and Description”, глава 8, различные поставщики могут создавать описание устройства для сервера управления, используя стандартизированный DTD (описание типа документа) для структуры описания устройства (DDF) или модели, где описание устройства содержит зависящую от устройства информацию свойства. Модель DTD описания устройства определяет XML элементы, для которых поставщик устройства может определить свойства типа устройства в вопросе и таким образом создать описание устройства. На основании описания устройства сервер управления выполнен с возможностью передачи команд управления на различные устройства, функционирующие как клиенты управления устройством. Описание устройства может, в частности, определять внешнюю программную структуру клиентского устройства для части управляемых объектов. В одном варианте осуществления одна или несколько частей информации в описании устройства могут измениться в клиентском устройстве, когда, например, обновление, отклоняющееся от текущего описания устройства, сделано для дерева управления. Информация относительно этого обновления может также быть передана на сервер управления, который обновляет описание устройства. Вместо вышеупомянутого могут использоваться другие структуры описания и/или модели описания, включая, например, RDF (структура описания ресурса), CC/PP (составные возможности/профили предпочтения), CIM (общая информационная модель), GUP (универсальный профиль пользователя), XML схема и UML (унифицированный язык моделирования).

В соответствии с одним вариантом осуществления по меньшей мере один узел определяется в первом устройстве вместе с процессом начальной загрузки. Процесс начальной загрузки может быть начат, например, на основе сообщения инициализации, переданного сервером управления, когда конфигурация, указанная в соответствии с сообщением, установлена в клиентском устройстве. Одним примером является простой профиль начальной загрузки управления устройством OMA, в котором параметры настройки, требуемые для запуска сеанс управления, предлагаются устройству клиента. Другой пример выполняет процесс начальной загрузки WAP управления устройством OMA. Общая проблема с однонаправленными сообщениями инициализации, касающимися управления устройством, состоит в том, что параметры настройки должны быть именованы или, иначе, изменяться в клиентском устройстве таким способом, чтобы было невозможно для сервера управления изменить их позже. Например, параметры настройки, переданные с технологией инициализации клиента OMA (OMA CP), непосредственно не ссылаются на дерево управления, но по меньшей мере часть дерева управления должна быть названа отдельно устройством клиента. Вышеупомянутым способом, однако, информация свойства по меньшей мере тех узлов, которые изменило клиентское устройство, может быть передана на сервер управления. Особенно, информация об именах, которую клиентское устройство изменило, может таким образом быть передана на сервер управления. Информация свойства относительно узлов, изменяемых в процессе начальной загрузки, может быть передана как ответ на принятое сообщение инициализации или позднее в сообщении, касающемся установки сеанса управления устройством в соответствии со спецификацией управления устройством OMA. После этого сервер управления и клиентское устройство могут перейти к использованию двунаправленного сеанса управления устройством. Таким образом, это позволяет, в общем случае, обычное использование однонаправленной технологии инициализации типа технологии инициализации OMA клиента OMA CP и двунаправленной технологии управления устройством, типа технологии управления OMA устройством OMA DM.

В соответствии с одним вариантом осуществления информация относительно по меньшей мере одного узла, определенного в первом устройстве, передается на второе устройство в сообщении установки сеанса управления устройством. Обратимся к фиг.5a, где функционирует терминал TE, поскольку клиентское устройство управления устройством OMA выполнено с возможностью передачи 501 пакета управления, включающего в себя по меньшей мере информацию узла, определенную для функционирования сервера S, поскольку сервер управления использует пакет № 1 инициализации клиента. Пакет инициализации клиента может содержать команду ALERT, когда сервер S выполнен с возможностью добавления к своей памяти информации, указанной для узлов в команде ALERT; или он может включать команду REPLACE, когда сервер S выполнен с возможностью замены информации относительно предыдущих узлов в пакете 501, на информацию, указанную в команде REPLACE. После этого сеанс управления может быть продолжен и сервер S может передать пакет 502 № 2 инициализации сервера, который может теперь содержать команды управления и данные управления. Далее, процесс может быть продолжен пакетами 503 № 3 и 504 № 4. Таким образом, механизмы протокола управления устройством и сообщения, указанные для этого, могут использоваться между сервером S и терминалом TE. Что касается более подробного описания протокола управления устройством OMA, спецификация OMA “SyncML Device Management Protocol”, версия 1.1.1; 2 октября 2002 г. (39 страниц), включена сюда в виде ссылки.

Следующее иллюстрирует примерный пакет № 1 инициализации клиента, для которого клиентское устройство определило команду ALERT, в элементе Item, имя которого, указанное для узла устройством клиента, определено. Другие элементы в примере описаны в спецификации OMA.

<SyncML xmlns='SYNCML:SYNCML1.1'>

<SyncHdr>

</SyncHdr>

<SyncBody>

<Alert>

<CmdID>2</CmdID>

<Data>1225</Data>

<Item>

<Data>7</Data> <!-Имя, данное динамическому узлу устройством клиента -->

</Item>

</Alert>

</SyncBody>

</SyncML>

Следующее иллюстрирует второй пример пакета № 1 инициализации клиента, для которого клиентское устройство определило команду REPLACE, в элементе Item, имя которого, указанное для узла устройством клиента, определено. В примере, новый параметр “SRVLND” добавился к элементу DevInfo, сообщая серверу управления, что новое имя (указанное устройством клиента) должно быть сохранено для динамического узла.

<SyncML xmlns='SYNCML:SYNCML1.1'>

<SyncHdr>

</SyncHdr>

<SyncBody>

<Replace>

<CmdID>3</CmdID>

<Item>

<Source>

<LocURI >./DevInfo/SrvInd</LocURI>

<!-- 'SrvInd' хранит имя для динамического узла-->

</Source>

<Meta>

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

<Type xmlns='syncml:metinf'>text/plain</Type>

</Meta>

<Data>7</Data> <!-имя, данное динамическому узлу устройством клиента -->

</Item>

</Replace>

</SyncBody>

</SyncML>

Следующее иллюстрирует еще один, третий пример, пакета № 1 инициализации клиента, для которого клиентское устройство определило команду REPLACE, в элементе LocURI, для которого “7” указывает имя, определенное для узла устройством клиента.

<SyncML xmlns='SYNCML:SYNCML1.1'>

<SyncHdr>

</SyncHdr>

<SyncBody>

<Replace>

<CmdID>3</CmdID>

<Item>

<Source>

<LocURI >./SyncML/DMAcc/7</LocURI> <!- '7' указывает имя, определенное для узла устройством клиента -->

</Source>

</Item>

</Replace>

</SyncBody>

</SyncML>

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

Фиг.5b иллюстрирует другой вариант осуществления, в котором клиентское устройство предназначено для создания сообщения 511 ответа (индикатор ответа) к сообщению 510 инициализации (инициализации клиента OMA), согласующийся со спецификацией OMA CP. В частности, клиентское устройство выполнено с возможностью создания сообщения ответа, если оно изменило по меньшей мере один узел, содержащийся в сообщении инициализации, или по меньшей мере один узел в дереве управления из-за сообщения 510 инициализации. Сообщение 511 может быть создано исключительно для того, чтобы передать информацию свойства, но также могут использоваться и элементы, уже указанные в протоколе управления устройством OMA. Сообщение 511 может также указать, что создание дерева управления было успешно, или идентифицировать возможную ошибку.

Сообщения, проиллюстрированные на фиг.5a и 5b, могут быть переданы с использованием любого механизма передачи, расположенного ниже в стеке протокола. Как проиллюстрировано на фиг.2, интерфейс между сервером управления и клиентским устройством может изменяться. В типичном случае оператор PLMN сети имеет сервер управления, посредством которого осуществляется передача данных между сервером управления и устройством клиента, используя PLMN сеть и службы передачи данных, предоставленные ей. Информация свойства может быть передана с использованием, например, коротких сообщений (SMS; служба коротких сообщений), которые хорошо приспособлены для передачи короткой, основанной на тексте, информации. В соответствии с другим вариантом осуществления клиентское устройство открывает соединение HTTP к заданному адресу, например к идентификатору URL, зарезервированному для клиентского устройства сервером управления, и информация свойства может быть передана через соединение HTTP. Здесь может использоваться, например, сценарий CGI (стандартный интерфейс обмена данных).

Необходимо отметить, что вышеупомянутые варианты осуществления могут также быть применены в виде комбинаций. Для примера, пакет 501 инициализации, представленный на фиг.5a и включающий информацию свойства, может быть передан как ответ на сообщение инициализации согласно спецификации OMA CP.

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

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

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