НАЦЕЛЕННЫЕ ЗАПРОСЫ, ИСПОЛЬЗУЮЩИЕ ОМА DM-ПРОТОКОЛ

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

Раскрыты различные технологии и методики для расширения функциональных возможностей ОМА (открытый альянс мобильной связи) DM-протокола (управление устройствами). Дополнение сделано к ОМА DM-протоколу, который позволяет серверу определять критерии фильтрации узлов как часть запроса для целевого узла по мобильному устройству, чтобы обозначить подмножество данных управления устройством для целевого узла, которые должны вернуться. Сервер отсылает запрос в мобильное устройство. Когда запрос успешно обработан на мобильном устройстве, ответ принимается от мобильного устройства, которое включает в себя только подмножество данных управления устройством, которые выполняют критерии фильтрации узлов.

В другом варианте осуществления выполнена модификации для ОМА DM-протокола, который позволяет серверу определять, какие атрибуты должны быть выбраны на мобильном устройстве в одном параметре целевого URI команды получения (Get), и какой формат данных управления устройством должен вернуться как другой параметр целевого URI команды получения (Get).

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

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

Фиг.1 является схематичным представлением ОМА DM-структуры одного варианта реализации.

Фиг.2 является схематичным представлением некоторого примерного исходного кода для определения критериев фильтрации узла в многочисленных местах команды (Get), используя SQL-синтаксис.

Фиг.3 является схематичным представлением некоторого примерного исходного кода для определения критериев фильтрации узлов в параметре фильтрации узлов ОМА DM-запроса, используя синтаксис SQL-запроса.

Фиг.4 является схематичным представлением некоторого примерного исходного кода для определения критериев фильтрации узлов в параметре фильтрации узлов и в отдельном параметре данных ОМА DM-запроса, используя синтаксис запроса Xpath.

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

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

Фиг.7 является схематичным представлением вычислительной системы одного варианта реализации.

ПОДРОБНОЕ ОПИСАНИЕ

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

Как упомянуто ранее, ОМА DM-стандарт выгодно использует WAP-протокол (протокол беспроводных приложений), предоставляя схему, расположенную рядом с ее собственными структурами управления устройствами для предоставления устройств с информацией осуществления доступа к приложениям и информацией об определенных устройствах. Эти структуры управления устройствами показаны на ОМА DM-структуре 100 фиг.1 как объекты 102 управления ОМА DM. Стандарт ОМА DM определяет, что возможности мобильного устройства должны быть представлены как дерево именованных узлов, с корнем в узле, названным ".". Пример этой структуры предоставлен кратко. В сеансе управления ОМА DM сервер и мобильное устройство взаимодействуют через протокол стандартов, названный ОМА DM-протокол. Во время подобного сеанса ОМА DM-сервер отсылает в мобильное устройство некоторые команды в XML-формате (расширяемый язык разметки), который запрашивает или модифицирует узлы, либо по структуре, либо по значению. ОМА DM-протокол разрешает серверу запрашивать данные у целевого узла на мобильном устройстве. Термин "целевой узел" как используется в данном документе, обозначает ссылку на узел в дереве управления устройством ОМА DM, которое является объектом определенной команды ОМА DM-сервера (например, команды получения (Get)). Целевой узел может включать в себя нулевые или более узлов потомков.

Как показано на фиг.1, в одном варианте осуществления, сделано расширение для ОМА DM-протокола 104 для добавления одного или более критериев 108 фильтрации узлов для определения 106 запроса целевых узлов. Критерии 108 фильтрации узлов разрешают серверу определять подмножество данных управления устройством, которые необходимо вернуть от мобильного устройства. Термин "критерии фильтрации узлов", как используется в данном документе, означает включение одного или более параметров, критериев или других значений, которые определяют, как данные управления устройством должны фильтроваться. Как описано дополнительно подробно на фиг.2-5 в данном документе, в одном варианте осуществления, по меньшей мере, часть критериев фильтрации узлов включена в новый параметр, добавляемый к целевому URI, включенному в команду получения (Get). Другие варианты осуществления также описаны дополнительно подробно.

Альтернативно или дополнительно к критериям 108 фильтрации узлов другие критерии 110 могут также быть модифицированы и/или включены в ОМА DM-протокол 104. В качестве одного неограничивающего примера, может быть сделана модификация для ОМА DM-протокола, из условия, чтобы один параметр использовался для обозначения, какие атрибуты должны быть выбраны на мобильном устройстве и другой параметр используется для обозначения, в каком формате данные управления устройством должны быть возвращены. Этот неограничивающий пример описан дополнительно подробно на фиг.6. Некоторые примеры теперь предусмотрены на фиг.2-6 для дополнительной иллюстрации критериев фильтрации узлов и других идей.

Возвращаясь теперь к фиг.2-6, некоторый примерный исходный код и процессы для реализации одного или более вариантов осуществления ОМА DM-протокола 104 описаны дополнительно подробно. В некоторых вариантах осуществления процессы, описанные при рассмотрении фиг.2-6, по меньшей мере, частично реализованы в функционирующей логике вычислительного устройства 300 (фиг.7).

Фиг.2 является схематичным представлением 130 некоторого примерного исходного кода для определения критериев фильтрации узла в многочисленных местах в команде получения (Get), используя SQL-синтаксис. До рассмотрения подробностей синтаксиса примерного исходного кода, показанного на фиг.2, сначала описан пример для дополнительной иллюстрации идеи фильтрации узлов.

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

x

y

b (value=1)

с (value=2)

d

e (value=51)

y2

b (value=3)

с (value=4)

d

e (value=28)

y3

b (value=5)

с (value=6)

d

e (value=51)

Предположим, что серверу лишь необходимо извлечь значения всех узлов {./x/y/b,./x/y/c}, где соответствующее./x/y/d/e.value ==51. Запрос, такой как показанный на фиг.2, может быть запущен из сервера в мобильное устройство, которое вскоре описывается дополнительно подробно. После обработки результатов на мобильном устройстве, сервер затем принимает результаты обратно, которые аналогичны следующему:

./x/y/b (value=1)

./x/y/c (value=2)

./х/у3/b (value=5)

.x/y3/c (value=6)

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

<MgmtTree xmlns="syncml:dmddfl.2">

<VerDTD> 1.2</VerDTD>

<Node>

<NodeName>b</NodeName>

<Path>./x/y</Path>

<RTProperties>

<Value>l</Value>

</RTProperties>

</Node>

<Node>

<NodeName>c</NodeName>

<Path>./x/y</Path>

<RTProperties>

<Value>2</Value>

</RTProperties>

</Node>

<Node>

<NodeName>b</NodeName>

<Path>./x/y3</Path>

<RTProperties>

<Value>5</Value>

</RTProperties>

</Node>

<Node>

<NodeName>c</NodeName>

<Path>./x/y3</Path>

<RTProperties>

<Value>6</Value>

</RTProperties>

</Node>

</MgmtTree>

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

Возвращаясь теперь к примеру исходного кода фиг.2, один способ для реализации критериев фильтрации узлов, использующих ОМА DM-протокол, существует для добавления критериев фильтрации узлов к команде получения (Get). Команда получения (Get) поддерживается в ОМА DM-протоколе, чтобы разрешить серверу получать данные управления устройством от мобильного устройства. В примерном исходном коде, показанном на фиг.2, параметр 132 LocURI команды получения (Get) модифицирован для включения параметра 134 фильтра узлов, который определяет язык 136 запросов, который используется для выражения критериев фильтрации узлов. В этом примере фактический критерий фильтрации узлов затем действительно выражается где-либо в команде получения (Get), например, в разделе 138 данных, используя синтаксис языка запросов, который был задан в параметре 134 фильтра узлов. В этом примере параметр 134 фильтра узлов определяет, что синтаксис 136 языка запросов используется в SQL. SQL-запрос 140 затем включается в раздел 138 данных. SQL-запрос содержит те же самые критерии, которые использовались в более раннем примере, который ограничивал записи записями "b" и "c" для узлов, которые имеют значения, равные 51.

Пример, показанный на фиг.2, является лишь одним примером многочисленных возможных способов, которым ОМА DM-протокол может быть модифицирован, чтобы включать в себя критерии фильтрации узлов. Например, в других вариантах осуществления определенные критерии фильтрации узлов могут быть просто включенными непосредственно в параметр 132 LocURI, в некоторый другой раздел команды получения (Get) или в некоторое внешнее расположение, доступное для команды получения (Get).

Фиг.3 является разновидностью фиг.2, которая иллюстрирует, как те же самые критерии 156 фильтрации SQL-узлов могут альтернативно включаться непосредственно в параметр 152 LocURI как часть параметра 154 фильтра узлов. Другими словами, формулировка фактического запроса, который обозначает критерии, которые должны использоваться для выбора подмножества данных управления устройством, могут быть внедрены непосредственно в параметр 152 LocURI, как другая возможная разновидность.

Фиг.4 является схематичным представлением 170 некоторого примерного исходного кода для определения критериев фильтрации узлов в параметре фильтрации узлов и в отдельном параметре данных ОМА DM-запроса, используя синтаксис запроса Xpath. Примерный исходный код фиг.4 показывает разновидность фиг.2, где синтаксис запроса Xpath используется для гипотетического запроса вместо SQL-синтаксиса. В этом примере, параметр 172 LocURI команды получения (Get) содержит параметр 174 фильтра узлов, который обозначает значение Xpath для синтаксиса 176 языка запросов. Раздел 178 данных команды получения (Get) затем включает в себя запрос с фактическими критериями фильтрации узлов в синтаксисе языка запросов Xpath. Критерии, заданные в синтаксисе Xpath, являются теми же самыми критериями фильтрации, представленные ранее, но вместо этого использующие синтаксис Xpath для иллюстрации. Хотя запрос показан в разделе данных в примерах фиг.2 и 4, и непосредственно в параметре LocURI на фиг.3, принято во внимание, что запрос для выражения критериев фильтрации узлов может быть задан любым из многочисленных способов, как происходит для специалиста в области компьютерного программного обеспечения. Любая соответствующая разновидность для представления критериев фильтрации узлов непосредственно в или доступная для команды получения (Get) ОМА DM-протокола может использоваться в других вариантах осуществления.

Возвращаясь теперь к фиг.5, показана блок-схема 200 процесса для одного варианта осуществления, который иллюстрирует этапы, включенные в отправку запроса, который имеет критерии фильтрации узлов для мобильного устройства, использующего ОМА DM-протокол. Запрос дополнительно принимается от мобильного устройства, которое приглашает сервер начать сеанс управления устройством (этап 202). В качестве одного неограничивающего примера мобильное устройство может установить соединение с сервером (через HTTP или другие протоколы) и запросить обновления. При любом событии, сервер каким-либо образом определяет, что настало время взаимодействовать с мобильным устройством для извлечения и/или обновления данных управления устройством. Сервер отсылает запрос в мобильное устройство, который включает в себя команду получения (Get) с критериями фильтрации узлов для извлечения данных управления устройством (этап 204).

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

Возвращаясь теперь к фиг.6, описана другая модификация для ОМА DM-протокола, чтобы проиллюстрировать, как выбор атрибутов может быть включен в отдельный параметр из выбора формата данных и выбора установки узлов в параметре LocURI команды получения (Get). Примерный исходный код 240 имеет параметр 242 LocURI с параметром 244 списка, который описывает формат, в котором данные управления устройством должны быть возвращены. В одном варианте осуществления, если значение списка равно "StructData", тогда все узлы возвращаются в отдельных элементах в результатах, со статичным набором данных для каждого узла. Если значение для параметра 244 списка равно "TNDS", XML-блоб (большой двоичный объект) возвращается, описывая для каждого узла набор данных для всех узлов; этот выбор атрибутов является настраиваемым, но настройка сама внедряется в значение списка TNDS. Параметр 246 свойств, тем не менее, освобождается от выбора атрибутов из других частей синтаксиса запроса, например, выбор установки узлов и выбор формата данных, и поэтому параметр 246 свойств может быть задан в связи с любой другой возможностью для определения выбора установки узлов или выбора формата данных. Этот параметр 246 свойств сам по себе обозначает, какие атрибуты должны быть выбраны из установки адресуемых узлов мобильного устройства. Атрибуты, заданные в параметре 246 свойств, могут включать в себя свойства узлов, а также значения узлов, и многочисленные атрибуты могут быть заданы в один момент времени. Следует заметить, что эти параметры могут быть названы по-разному, чем описано на фиг.6, но являются лишь одним примером.

Как показано на фиг.7, одна примерная вычислительная система для использования реализации одной или более частей системы включает в себя вычислительное устройство, такое как вычислительное устройство 300. В наиболее общей базовой конфигурации вычислительное устройство 300 типично включает в себя по меньшей мере один блок 302 обработки и память 304. В зависимости от точной конфигурации и типа вычислительного устройства память 304 может быть энергозависимой (такой как RAM), энергонезависимой (такой как ROM, флэш-память и т.д.) или некоторой комбинацией обеих. Эта наиболее общая базовая конфигурация проиллюстрирована на фиг.7 с помощью пунктирной линии 306.

Кроме того, устройство 300 может также иметь дополнительные признаки/функциональные возможности. Например, устройство 300 может также включать в себя дополнительное запоминающее устройство (съемное и/или несъемное), которое включает в себя, но не ограничено магнитными или оптическими дисками или магнитной лентой. Такое дополнительное запоминающее устройство проиллюстрировано на фиг.7 съемным запоминающим устройством 308 и несъемным запоминающим устройством 310. Запоминающие носители вычислительной машины включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные по любому способу или технологии для хранения такой информации, как машиночитаемые команды, структуры данных, программные модули и др. данные. Память 304, съемный запоминающий носитель 308 и несъемный запоминающий носитель 310 - все являются примерами запоминающих носителей вычислительной машины. Компьютерные запоминающие носители включают в себя, но не в качестве ограничения, ОЗУ (оперативное запоминающее устройство, RAM), ПЗУ (постоянное запоминающее устройство, ROM), EEPROM (электрически стираемое и программируемое ПЗУ), флэш-память или память другой технологии, CD-ROM (ПЗУ на компакт-диске), универсальные цифровые диски (DVD) или другое оптическое дисковое запоминающее устройство, магнитные кассеты, магнитную ленту, магнитное дисковое запоминающее устройство или другие магнитные запоминающие устройства, или любой другой носитель, который может быть использован, чтобы хранить желаемую информацию и к которому может быть осуществлен доступ устройством 300. Любой подобный запоминающий носитель вычислительной машины может быть частью устройства 300.

Вычислительное устройство 300 включает в себя одно или более соединений 314 связи, которые разрешают вычислительному устройству 300 взаимодействовать с другими компьютерами/приложениями 315. Устройство 300 может также иметь устройство(а) 312 ввода, например, клавиатуру, мышь, перо, устройство речевого ввода, устройство сенсорного ввода и т.д. Устройство(а) 311 вывода, например, дисплей, динамики, принтер и т.д. могут также включаться. Эти устройства широко известны в данной области техники и не обязательно должны детально описываться в данном документе.

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

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