нацеленные запросы, использующие ома dm-протокол

Формула изобретения

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

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

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

2. Считываемый компьютером носитель информации по п.1, при этом критерии фильтрации узлов включены в запрос как часть команды получения (Get) ОМА DM.

3. Считываемый компьютером носитель информации по п.2, при этом команда получения (Get) задана в синтаксисе XML.

4. Считываемый компьютером носитель информации по п.3, при этом критерии фильтрации узлов заданы в поле LocURI в синтаксисе XML.

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

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

7. Считываемый компьютером носитель информации по п.6, при этом синтаксис языка выбирается из группы, состоящей из SQL и Xpath.

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

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

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

11. Способ извлечения подмножеств данных для целевого узла, используя протокол управления устройствами (DM) Открытого альянса мобильной связи (ОМА) (ОМА DM протокол), содержащий этапы, на которых:

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

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

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

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

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

15. Способ по п.14, в котором параметр в целевом URI задает синтаксис языка, который необходимо использовать для критериев фильтрации.

16. Способ по п.14, в котором в отдельный раздел команды получения (Get) включен фактический запрос, который задает критерии фильтрации узлов, причем этот фактический запрос записывается в синтаксисе языка, заданном в параметре в целевом URL.

17. Способ по п.14, в котором отдельный раздел является разделом данных команды получения (Get).

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

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

структуру управления устройствами (DM) Открытого альянса мобильной связи (ОМА), которая включает в себя стандартные объекты управления ОМА DM, ассоциированные с ОМА DM протоколом, для управления данными управления устройством на мобильном устройстве, при этом ОМА DM протокол позволяет серверу отправить команду получения (Get) в целевой узел на мобильном устройстве для извлечения данных управления устройством, ассоциированных с целевым узлом; и

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

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

Описание изобретения к патенту

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

В современном мире технологий, множество мобильных устройств может использоваться занятыми людьми. Некоторые примеры мобильных устройств включают в себя персональные цифровые помощники (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 вывода, например, дисплей, динамики, принтер и т.д. могут также включаться. Эти устройства широко известны в данной области техники и не обязательно должны детально описываться в данном документе.

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

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