СПОСОБ И УСТРОЙСТВО ДЛЯ ЕДИНОГО УПРАВЛЕНИЯ МОБИЛЬНЫМИ УСТРОЙСТВАМИ И СЕРВИСАМИ Российский патент 2009 года по МПК H04W80/00 

Область техники

Предпочтительные на данный момент варианты осуществления этого изобретения относятся к области беспроводных систем связи, а более конкретно, касаются процедур управления устройствами посредством беспроводной связи (Over-The-Air, OTA) для передачи информации на мобильные устройства, такие как сотовые телефоны и другие.

Уровень техники

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

Другим примером является обеспечение мобильных устройств новыми сервисами OTA и управление этими сервисами. Передовые мобильные сервисы, такие как просмотр веб-страниц, отправка мультимедийных сообщений, использование электронной почты в сети мобильной связи и синхронизация календарей, требуют настроек мобильных устройств. Процесс дистанционного управления настройками устройств и приложениями называется управлением устройствами (Device Management, DM).

Управление устройствами посредством OTA определено в стандарте 3GPP2 OTASP/OTAPA, стандарте ОМА DM (стандарт управления устройствами Открытого мобильного альянса (ОМА)), а также в стандарте 3GPP2 IOTA-DM (IOTA-DM означает "IP based over-the-air device management" - беспроводное управление устройствами на базе протокола IP).

Также в настоящее время существуют способы дистанционного управления мобильными устройствами, не основанные на Интернет-протоколе. Например, стандарт IS-683 (TIA/EIA-683-C, Over-The-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems (Обеспечение сервиса ОТА в системах с расширенным спектром)), March, 2003, определяет протокол, который использует сигнализацию по радиоинтерфейсу для дистанционного управления мобильными станциями. Другой пример использования не-IP протоколов включает использование частных протоколов на основе SMS (службы коротких сообщений).

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

В июне 2003 Открытый мобильный альянс опубликовал стандарт Управления устройствами ОМА DM версии 1.1.2, основанный на SyncML DM (управление устройствами с использованием языка разметки для синхронизации (SyncML - Synchronisation Markup Language)). Справочную информацию относительно этого стандарта можно получить из следующих ссылок: ОМА SyncML HTTP Binding, Version 1.1.2, ОМА, June 12, 2003; ОМА SyncML OBEX Binding, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML Device Management Protocol, version 1.1.2, ОМА, June 12, 2003. http://www.openmobilealliance.org/release_program/enabler_releases.html: ОМА SyncML, Representation Protocol, Device Management usage, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML Device Management Bootstrap, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML DM DDF DTD (SyncML_dm_ddf__v111_20021002.dtd), version 1.1.2, ОМА, June 12, 2003; ОМА SyncML Device Management Tree and Descriptions, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML Device Management Notification Initiated Session, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML Device Management Security, version 1.1.2, ОМА, June 12, 2003; ОМА SyncML WSP Binding, version 1.1.1, ОМА, June 12, 2003.

Стандарт ОМА DM предоставляет единую и расширяемую структуру для нужд управления посредством ОТА мобильными устройствами 3-го поколения и устройствами других поколений. Этот стандарт включает спецификацию протокола ОМА DM, который основан на протоколе SyncML DM. Этот протокол оптимизирован для управления посредством беспроводной связи, при этом основное внимание обращено на ограничения ресурсов и ширины полосы мобильных устройств.

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

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

К настоящему моменту не существует универсального способа управления мобильными устройствами посредством беспроводной связи. Необходим, но не был доступен до появления настоящего изобретения единый способ, предоставляющий провайдерам сетевого сервиса возможности управления мобильными устройствами и сервисами с использованием единого механизма. В настоящее время существуют разные стандарты для управления устройствами посредством беспроводной связи, например, ОМА DV, IOTA-HCM, IS-683, частные стандарты ОТА, телесервисы ОТА и так далее, которые не удовлетворяют в надлежащей степени упомянутой выше потребности.

Сущность изобретения

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

Предлагаются способ, система и компьютерная программа, выполняемая процессором или процессорами, для поддержки не-IP протокола ОТА с использованием сквозного IP-протокола. Это способ включает прием сообщения от не-IP объекта, использование языка разметки для представления сообщения и контента, где в сообщении на языке разметки не-IP контент идентифицируется с использованием элемента МЕТА, описывающего тип контента как "наименование не-IP протокола", и отправку этого сообщения на языке разметки. Использование языка разметки предпочтительно включает инкапсулирование принятого контента в сообщение на языке разметки и использование элемента МЕТА, чтобы дать возможность получателю сообщения на языке разметки извлечь этот контент. Сообщение, принятое от не-IP объекта, может быть сообщением стандарта IS-683, но не только им.

Один из аспектов этого изобретения включает узел сети, способный поддерживать не-IP протокол ОТА с использованием сквозного IP-протокола. Этот узел сети включает приемник для приема сообщения, которое включает не-IP контент, а также процессор, способный работать с языком разметки, например, XML, для представления сообщения и контента, чтобы инкапсулировать в XML-сообщение не-IP контент, который идентифицируется для потенциального получателя XML-сообщения как такового путем использования элемента МЕТА языка XML. Этот элемент МЕТА описывает тип метаконтента как "наименование не-IP протокола". Узел сети дополнительно включает передатчик для передачи XML-сообщения с не-IP контентом получателю и через беспроводную сеть связи.

Другим аспектом этого изобретения является мобильная станция с не-IP клиентом и приемником, который принимает сообщение на языке разметки, содержащее не-IP контент, с использованием сквозного IP-протокола. Мобильная станция дополнительно включает процессор, способный работать с языком разметки для представления сообщения и контента, чтобы извлекать сообщение с не-IP контентом из принятого сообщения в ответ на наличие элемента МЕТА, который описывает тип метаконтента как "наименование не-IP протокола".

Еще один аспект этого изобретения - это узел сети связи, который способен поддерживать не-IP протокол ОТА с использованием сквозного IP-протокола. Этот узел сети включает средства приема сообщения с не-IP контентом, соединенные с процессором обработки данных, способным работать с языком разметки, например, с расширяемым языком разметки (XML), для представления сообщения и контента для включения в XML-сообщение не-IP контента, который идентифицируется для потенциального получателя XML-сообщения как такового путем использования XML элемента МЕТА. Элемент МЕТА описывает тип метаконтента как "наименование не-IP протокола". Этот узел сети связи также включает средства передачи, соединенные со средствами обработки данных, для передачи XML-сообщения, включающего не-IP контент, получателю и через беспроводную сеть связи.

Еще один аспект этого изобретения предлагает способ поддержки не-IP протокола ОТА с использованием сквозного IP-протокола, который включает прием сообщения от не-IP объекта; использование языка разметки для представления сообщения и контента, где не-IP контент идентифицируется в сообщении с использованием элемента МЕТА, а элемент МЕТА описывает тип контента как "наименование не-IP протокола", и отправку сообщения с этим элементом МЕТА.

Краткое описание чертежей

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

На фиг.1 изображена упрощенная блок-схема архитектуры сети управления устройствами на основе CDMA.

На фиг.2 показана архитектура сквозной передачи для IOTA-DM.

На фиг.3 показан поток сообщений для обработки типичного не-IP DM сообщения, здесь, исключительно в качестве примера, используется сообщение IS-683 DM.

На фиг.4 показано представление формата сообщения сквозной передачи в соответствии с примером, приведенным на фиг.3.

Подробное описание предпочтительных вариантов осуществления изобретения

Предваряя обсуждение, можно сказать, что варианты осуществления изобретения могут быть использованы для объединения различных протоколов ОТА, что приводит к единому способу управления мобильными устройствами и службами. Более конкретно, варианты осуществления изобретения позволяют оперировать с протоколами управления, не являющимися Интернет-протоколом ("не-IP"), используя протокол на основе IP.

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

Предпочтительные варианты осуществления изобретения применяют специальный тип МЕТА, а также определенный способ использования протокола управления устройствами, для достижения полной совместимости с предыдущими версиями не-IP протоколов, используемых в унаследованных системах. Это позволяет использовать протокол управления устройствами на основе языка разметки (например, на основе языка XML) в различных сетях связи для управления мобильными устройствами с разнообразными функциями.

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

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

Предпочтительные варианты осуществления изобретения могут быть реализованы в мобильных устройствах. Существующие компоненты программного обеспечения могут быть повторно использованы для разработки единого объекта в таком мобильном устройстве, чтобы поддерживать унаследованные функции. Затем в эту систему могут быть встроены новые функции 3-го и следующего поколения. Тем самым предпочтительные варианты осуществления изобретения могут поддерживать как унаследованные функции, так и новые функции, предоставляя единый механизм для осуществления обоих видов функций. Для мобильных устройств стандарта CDMA могут быть повторно использованы компоненты OTASP/OTAPA.

Для описания вариантов осуществления изобретения в надлежащем техническом контексте обратимся к фиг.1, где показана архитектура сети связи для управления устройствами на примере сети CDMA. Несмотря на то, что на чертеже представлен интерфейс CDMA, спецификации управления устройствами ОМА DM также поддерживают управление устройствами посредством технологий локального доступа, например, на радиочастотах при малой мощности (например, Bluetooth™) и посредством инфракрасной связи (например, IrDM). Также обратимся к фиг.2, где приведена архитектура сквозной передачи для IOTA-DM, которая включает мобильную станцию 1 (MS), такую как сотовый телефон, также называемую мобильным оборудованием, сервер 2 управления устройствами (сервер 2 DM), соединенный с мобильной станцией 1 посредством беспроводной сети 22 связи, такой как сотовая (например, CDMA) беспроводная сеть связи.

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

На этих чертежах подразумевается, что мобильная станция 1 включает клиента 10 управления устройствами, который обрабатывает сообщения и команды управления устройствами, выполняет авторизацию и обрабатывает доступ к дереву управления. Объекты 12 управления включают параметры, объекты программ, блоки данных конфигурации и прочее, что имеет отношение к приложениям и сервисам. Объекты 12 управления организованы как логически связанные группы (или поддеревья) в иерархическом дереве. Также подразумевается, что мобильная станция 1 включает приложения 14.

Сервер 2 DM является объектом в сети для управления сервисами и приложениями в мобильной станции 1. Сервер 2 DM отдает команды управления устройствами и корректно интерпретирует отклики от клиента 10 управления устройствами. Сервер 2 DM включает базу данных 2А управления устройствами, в которой хранятся документы 16 структуры описания устройств (DDF). В предпочтительных вариантах осуществления изобретения документ 16 структуры описания устройств является, но не ограничивается этим, XML-документом (язык XML версии 1.0 (второе издание), Рекомендация консорциума WWW (W3C), версии 6-October-2000), который описывает свойства объектов управления в этом устройстве. Протокол управления устройствами посредством беспроводной связи (Протокол управления устройствами ОМА SyncML версии 1.1.2, ОМА, June 12, 2003) определяет структуру управления и набор сообщений, которыми обмениваются мобильная станция 1 и объект сети, обозначенный как сервер 2 управления устройствами.

Для полноты описания на фиг.1 показаны различные сети (N/W), представленные в качестве примеров сетью 30 ANSI-41 и сетью 32 с Интернет-протоколом (IP). К сети 30 ANSI-41 подключен центр 34 передачи сообщений (МС), опорный регистр 36 местонахождения (HLR), функция 38 ОТА (OTAF) и пара 40 MSC/VLR, центр коммутации сети мобильной связи (MSC) / визитный регистр местонахождения (VLR). Центр 34 передачи сообщений соединяется с сервером 2 DM, тогда как пара 40 MSC/VLR соединяется с контроллером базовой станции (ВSС)/функцией управления пакетами (PCF) 42, как и узел 44 поддержки пакетов данных (PDSN), связанный с сетью 32 связи по протоколу IP. Кроме того, с сетью 32 связи по протоколу IP связаны разнообразные функции 46, 48 (ААА) идентификации, авторизации и расчетов, а также домашний агент 50 (НА). Домашний агент 50 связывает сеть 32 связи по протоколу IP с сервером 2 DM. Над сервером 2 DM показаны типичные функции 60 управления, включая управление 60А конфигурацией, управление 60В сервисами, управление 60С предоставлением услуг ОТА в сети CDMA (OTASP) и администрированием параметров ОТА (ОТАРА), управление 60D предприятием и управление 60Е программным обеспечением.

Кроме того, на фиг.2 между мобильной станцией 1 и сетью 22 беспроводной связи, а также между сервером 2 DM и сетью 22 беспроводной связи изображены интерфейсы 70А и 70В протокола передачи гипертекста (HTTP), протокола обмена объектами (ОВЕХ) и службы коротких сообщений (SMS).

Один аспект этого изобретения относится к поддержке не-IP протоколов управления с использованием протоколов на основе IP. В одном из примеров, который не является ограничением, не-IP протоколы управления описываются в содержании сообщений протокола IS-683 (IS-683 - это протокол TIA/EIA и 3GPP для обеспечения ОТА и администрирования параметров ОТА в системах cdma2000, также известный как C.S0016 в 3GPP).

На фиг.3 показан поток сообщений между по меньшей мере одним не-IP клиентом 20, DM клиентом 10, сетью 23 беспроводной связи (например, сетью CDMA или сетью Bluetooth™), сервером 24 на основе IP и по меньшей мере одним объектом 26 не-IP сети при обработке типичного сообщения IS-683.

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

В соответствии с аспектом изобретения не-IP ОТА протоколы могут быть обработаны с использованием IP протоколов сквозной передачи, которые используют XML для представления сообщения и контента. В XML-сообщении не-IP контент идентифицируется с использованием элемента МЕТА языка XML.

На фиг.3 показан вариант осуществления способа в соответствии с изобретением, где элемент МЕТА описывает тип контента как "наименование не-IP протокола". Например, если используемый XML-протокол является протоколом на основе SyncML, a не-IP протокол является протоколом IS-683, то тип контента может быть представлен в виде: "syncml-dm:cdma-is683". Тип контента частного протокола, с известным названием, например, протокола Nokia-Ericsson ОТА, приведенного здесь исключительно в качестве примера, (см., например, http://www.forum.nokis.com/main/1,6566,1_47_50,00.html), может быть записан в виде: "syncml-dm:nokia-ota".

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

Шаг А. Сервер 24, основанный на IP, перехватывает сообщение не-IP протокола, например сообщение запроса по протоколу IS-683, и инкапсулирует это сообщение не-IP протокола в XML-сообщение, используя, как описано выше, элемент МЕТА.

Шаг В. XML-сообщение с инкапсулированным сообщением не-IP протокола отсылается в виде DM сообщения DM клиенту 10 через беспроводную сеть 22.

Шаг С. DM клиент 10, способный к приему XML-сообщений, принимает это DM сообщение, определяет тип МЕТА как контент сообщения не-IP протокола и извлекает этот метаконтент. Кодирование контента может быть задано в элементе МЕТА с использованием элемента формата.

Шаг D. DM клиент 10, способный к приему XML-сообщений, запускает не-IP клиента 20 на мобильной станции 1 и передает метаконтент не-IP клиенту 20 в формате не-IP протокола. Необходимо заметить, что в обычном случае мобильная станция 1 может содержать несколько не-IP клиентов 20. В этом случае DM клиент 10 должен определить из принятого сообщения целевого не-IP клиента 20 и маршрутизировать ему метаданные. Также отметим, что, как правило, может быть несколько объектов 26 не-IP сетей, которые отправляют сообщения (сообщения по протоколу IS-683 и другие типы сообщений), которые перехватываются и обрабатываются сервером 24 IP, как было описано выше.

Шаг Е. He-IP клиент 20 обрабатывает сообщение с метаконтентом и может отправить ответ. Ответ проходит ту же последовательность шагов А, В, С и D. То есть, на шаге F DM клиент 10 инкапсулирует этот не-IP ответ в XML-сообщение, используя элемент МЕТА, как было описано выше. На шаге G DM сообщение отсылается на сервер 24 IP, который извлекает метаконтент (шаг Н), форматирует и отсылает соответствующее сообщение IS-683 с ответом обратно объекту 26 не-IP сети (шаг I).

На упомянутом выше шаге С, при использовании SyncML DM для XML представления, не-IP клиент 20 может быть запущен заданием команды "Ехес" в XML-сообщении, а также определением цели команды Ехес как узла в дереве управления для не-IP протокола.

Если не-IP протокол является протоколом 3GPP2 IS-683, то имя узла может быть IS-683. Например, универсальный идентификатор ресурса (URI) этого узла может иметь вид: "./root/…cmda/is-683".

На фиг.4 показано представление примера сообщения сквозной передачи в соответствии со способом и системой, описанными выше.

Разные шаги способа, показанные на фиг.3, могут быть реализованы процессорами обработки данных, запрограммированными соответствующим образом и расположенными в требуемых узлах схемы, показанной на фиг.3, например в мобильной станции 1, сервере 24 IP и DM клиенте 20.

В вариантах осуществления изобретения сообщение, принятое от не-IP объекта 26, может включать сообщение по протоколу IS-683 и может содержать разные версии протокола IS-683.

В вариантах осуществления изобретения XML-сообщение может включать дополнительную информацию для обработки метаконтента, например, URI и/или "команды", например одну или несколько команд для запуска процесса в приемнике XML-сообщения для обработки метаконтента, где метаданные могут кодироваться кодом Base-64, или в ином формате, согласно тому, как указано элементом "Format".

Кроме того, в вариантах осуществления изобретения сообщение, принятое от не-IP объекта 26, может включать, например, сообщение по протоколу Nokia-Ericsson OTA (см. приведенный ранее пример).

Кроме того, XML-сообщение может включать в себя сообщение по протоколу SyncML или ОМА DM, a XML-протокол может содержать сообщение 3GPP2 IOTA-DM.

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

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

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

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

Изобретение относится к системам беспроводной связи. Технический результат заключается в усовершенствовании механизма управления мобильными устройствами. Способ включает прием сообщения от не-IР объекта; использование языка разметки, такого как XML, для представления сообщения и контента, при этом не-IР контент в XML-сообщении идентифицируется путем использования элемента МЕТА языка XML, где элемент МЕТА описывает тип контента как "наименование не-IР протокола", и отправку XML-сообщения. Использование XML предпочтительно включает инкапсулирование принятого контента в XML-сообщение и использование элемента МЕТА языка XML, чтобы позволить получателю XML-сообщения извлечь этот контент. Сообщение, принимаемое от не-IР объекта, может быть сообщением стандарта IS-683. 7 н. и 39 з.п. ф-лы, 4 ил.

1. Способ поддержки не-IP протокола беспроводной связи (ОТА) с использованием сквозного IP-протокола, включающий:
прием сообщения от не-IР объекта;
использование языка разметки для представления сообщения и контента, при этом не-IР контент в сообщении идентифицируют с использованием элемента МЕТА, который описывает тип контента как "наименование не-IР протокола"; и
отправку сообщения с этим элементом МЕТА.

2. Способ по п.1, в котором указанное использование языка разметки включает инкапсулирование принятого контента в сообщение на языке разметки путем использования элемента МЕТА.

3. Способ по п.1, в котором сообщение, принятое от не-IР-объекта, содержит сообщение по протоколу IS-683, включая различные версии протокола IS-683.

4. Способ по п.1, в котором сообщение на языке разметки включает дополнительную информацию для обработки метаконтента, состоящего по меньшей мере из одного URI (универсального идентификатора ресурса) и одной или более команды, где по меньшей мере одна команда запускает процесс обработки метаконтента в приемнике сообщения на языке разметки.

5. Способ по п.1, в котором метаданные кодируют с помощью формата, заданного элементом формата.

6. Способ по п.5, в котором формат является кодом Base-64.

7. Способ по п.1, в котором сообщение, принятое от не-IР объекта, включает сообщение по протоколу Nokia-Ericsson OTA.

8. Способ по п.1, в котором сообщение, принятое от не-IР объекта, включает сообщение по протоколу SyncML DM.

9. Способ по п.1, в котором сообщение, принятое от не-IР объекта, включает сообщение по протоколу ОМА OTA.

10. Способ по п.1, в котором сообщение, принятое от не-IР объекта, включает сообщение по протоколу 3GPP2 IOTA-DM.

11. Узел сети, способный поддерживать не-IР протокол беспроводной связи (OTA) с использованием сквозного IP-протокола и содержащий приемник для приема сообщения, которое включает не-IР контент, и процессор, способный работать с языком разметки для представления сообщения и контента для инкапсулирования в сообщение на языке разметки не-IР контента, который идентифицируется для потенциального получателя сообщения на языке разметки, как такового, путем использования элемента МЕТА, описывающего тип метаконтента как: "наименование не-IР протокола", указанный узел сети также содержит передатчик для передачи сообщения на языке разметки, содержащего не-IР контент, получателю и через беспроводную сеть связи.

12. Узел сети по п.11, в котором принятое сообщение включает сообщение по протоколу IS-683.

13. Узел сети по п.11, в котором сообщение на языке разметки включает дополнительную информацию, относящуюся к обработке метаконтента.

14. Узел сети по п.13, в котором дополнительная информация включает URI.

15. Узел сети по п.13, в котором дополнительная информация включает по меньшей мере одну команду для запуска процесса обработки метаконтента в приемнике сообщения на языке разметки.

16. Узел сети по п.11, в котором метаконтент кодируется кодом Base-64.

17. Узел сети по п.11, в котором кодирование метаконтента задается элементом "Format" (Формат), который является частью сообщения на языке разметки.

18. Узел сети по п.11, в котором принимаемое сообщение включает сообщение по протоколу Nokia-Ericsson OTA.

19. Узел сети по п.11, в котором принимаемое сообщение включает сообщение по протоколу SyncML DM.

20. Узел сети по п.11, в котором принимаемое сообщение включает сообщение по протоколу ОМА DM.

21. Узел сети по п.11, в котором принимаемое сообщение включает сообщение по протоколу 3GPP2 IOTA-DM.

22. Мобильная станция, содержащая не-IР клиента и приемник для приема сообщения на языке разметки, которое содержит сообщение с не-IР контентом протокола беспроводной связи (OTA) с использованием сквозного IP-протокола, и процессор, способный оперировать языком разметки для представления сообщения и контента для извлечения сообщение с не-IР контентом из принятого сообщения на языке разметки в ответ на наличие элемента МЕТА языка разметки, который описывает тип метаконтента как "наименование не-IР протокола".

23. Мобильная станция по п.22, которая включает передатчик, соединенный с процессором, для передачи сообщения на языке разметки, содержащего ответное сообщение с не-IР контентом, отправителю сообщения с не-IР контентом.

24. Мобильная станция по п.23, в которой упомянутый процессор также способен направлять извлеченное сообщение с не-IР контентом указанному не-IР клиенту, при этом ответное сообщение с не-IР контентом формируется не-IР клиентом.

25. Мобильная станция по п.22, в которой сообщение с не-IР контентом включает сообщение по протоколу IS-683.

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

27. Мобильная станция по п.26, в которой дополнительная информация включает URI.

28. Мобильная станция по п.26, в которой дополнительная информация включает по меньшей мере одну команду для запуска процесса обработки метаконтента.

29. Мобильная станция по п.22, в которой метаконтент кодируется кодом Base-64.

30. Мобильная станция по п.22, в которой кодирование метаконтента определяется элементом "Format" (Формат), который образует часть сообщения на языке разметки.

31. Мобильная станция по п.22, в которой сообщение с не-IР контентом включает сообщение по протоколу Nokia-Ericsson OTA.

32. Мобильная станция по п.22, в которой сообщение с не-IР контентом включает сообщение по протоколу SyncML DM.

33. Мобильная станция по п.22, в которой сообщение с не-IР контентом включает сообщение по протоколу ОМА DM.

34. Мобильная станция по п.22, в которой сообщение с не-IР контентом включает сообщение по протоколу 3GPP2 IOTA-DM.

35. Машиночитаемый носитель для хранения данных, хранящий команды компьютерной программы, заставляющие компьютер, который образует часть узла сети, поддерживать не-IР протокол беспроводной связи (OTA) с использованием сквозного IР-протокола путем выполнения операций приема сообщения, которое содержит не-IР контент; инкапсулирования в сообщение на языке разметки не-IР контента, который идентифицируется для потенциального получателя сообщения на языке разметки, как такового, путем использования элемента МЕТА языка разметки, где элемент МЕТА описывает тип метаконтента как "наименование не-IР протокола", и передачи сообщения на языке разметки, включающего не-IР контент, получателю.

36. Машиночитаемый носитель для хранения данных, хранящий команды компьютерной программы, заставляющие компьютер, который образует часть мобильной станции, имеющей не-IР клиента, выполнять операцию приема сообщения на языке разметки, которое включает сообщение с не-IР контентом по протоколу беспроводной связи (ОТА); а также операцию извлечения сообщения с не-IР контентом из принятого сообщения на языке разметки в ответ на наличие элемента МЕТА языка разметки, который описывает тип метаконтента как "наименование не-IР протокола".

37. Машиночитаемый носитель по п.36, который дополнительно включает операцию передачи сообщения на языке разметки, включающего инкапсулированное ответное сообщение с не-IP контентом, отправителю сообщения с не-IР контентом.

38. Машиночитаемый носитель по п.37, который дополнительно включает операцию направления извлеченного сообщения с не-IР контентом указанному не-IР клиенту, при этом ответное сообщение с не-IР контентом создается не-IР клиентом.

39. Узел сети, способный поддерживать не-IР протокол беспроводной связи (ОТА) с использованием сквозного IP-протокола и включающий средства для приема сообщения, содержащего не-IР контент, соединенные со средствами обработки данных, способными работать с языком разметки для представления сообщения и контента для включения в сообщение на языке разметки не-IР контента, который идентифицируется для потенциального получателя сообщения на языке разметки, как такового, путем использования элемента МЕТА языка разметки, где указанный элемент МЕТА описывает тип метаконтента как "наименование не-IР протокола", указанный узел сети также содержит средства передачи, соединенные с упомянутыми средствами обработки данных, для передачи сообщения на языке разметки, содержащего не-IР контент, получателю и через беспроводную сеть связи.

40. Узел сети по п.39, в котором принятое сообщение включает сообщение по протоколу IS-683.

41. Узел сети по п.39, в котором сообщение на языке разметки включает дополнительную информацию относительно обработки метаконтента.

42. Узел сети по п.41, в котором указанная дополнительная информация включает по меньшей мере один URI и по меньшей мере одну команду для запуска процесса обработки метаконтента в приемнике сообщения на языке разметки.

43. Способ поддержки не-IР протокола беспроводной связи (ОТА) с использованием сквозного IP-протокола, включающий:
прием сообщения от не-IР объекта;
использование языка разметки для представления сообщения и контента, при этом не-IР контент в сообщении идентифицируется путем использования элемента МЕТА, описывающего тип контента как "наименование не-IР протокола"; и отправку сообщения с указанным элементом МЕТА.

44. Способ по п.43, в котором при приеме сообщения принимают сообщение по протоколу IS-683.

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

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