МЕТОДИКИ УПРАВЛЕНИЯ ФУНКЦИОНАЛЬНЫМИ ВОЗМОЖНОСТЯМИ ШЛЮЗА ДЛЯ ПОДДЕРЖКИ УПРАВЛЕНИЯ УСТРОЙСТВАМИ В СИСТЕМЕ СВЯЗИ
TECHNIQUES FOR CONTROLLING GATEWAY FUNCTIONALITY TO SUPPORT DEVICE MANAGEMENT IN COMMUNICATION SYSTEM

Область техники, к которой относится изобретение
Настоящее изобретение относится к управлению устройствами (DM) в системе связи. Более конкретно, настоящее изобретение относится к методикам управления функциональными возможностями шлюзов для поддержки DM в системе связи.
Уровень техники
С повсеместным ростом технологий и систем связи увеличиваются функциональные возможности и сложность устройств. Однако с увеличением функциональных возможностей и сложности устройств проявляется потребность в управлении этими устройствами. В ответ на такую потребность открытый союз связи с мобильными объектами (ОМА) установил Рабочую группу управления устройствами (DM), чтобы определить протоколы и механизмы, которые осуществляют управление устройствами. Рабочая группа DM ОМА разработала спецификацию OMA-DM, которая определяет двухсторонний протокол между сервером DM и программой-клиентом DM, связанной с устройством, который используется для дистанционного управления устройством. Пример связи между сервером DM и программой-клиентом DM упоминается как сеанс связи DM и может инициироваться либо программой-клиентом DM, либо сервером DM. Программа-клиент DM постоянно находится в устройстве, и сервер DM управляет устройством, активизируя команды в программе-клиенте DM. Программа-клиент DM обрабатывает команду и отсылает ответ обратно на сервер DM. Установление связи между сервером и программой-клиентом содержит обмен сообщениями маркировочного языка синхронизации (SyncML). Исторически устройства были беспроводными устройствами, но в последнее время OMA-DM также начал обращаться к потребностям дистанционного управления проводных устройств. Примеры OMA-DM включают в себя установку информации о начальной конфигурации в устройствах, последующую инсталляцию и обновление перманентной информации в устройствах, извлечение информации управления из устройств и обработку событий и аварийных сигналов, генерируемых устройствами.
Пример архитектуры OMA-DM описывается ниже со ссылкой на фиг.1.
Фиг.1 иллюстрирует архитектуру OMA-DM в соответствии с предшествующим уровнем техники.
Что касается фиг.1, то на ней архитектура OMA-DM включает в себя сервер 140 DM, программу-клиента 110 DM и объекты управления (MO) 120 стандарта DM. Программа-клиент 110 DM и объекты MO 120 стандарта DM совместно размещены в устройстве 100. Архитектура OMA-DM может включать в себя дополнительные структурные элементы. Однако описание дополнительных структурных элементов архитектуры OMA-DM для краткости опущено.
Сервер 140 DM и программа-клиент 110 DM, которые были описаны выше, осуществляют связь через сопряжения DM-1 130 и DM-2 132. Программа-клиент 110 DM осуществляет связь через сопряжение DM-5 134 с объектами MO 120 стандарта DM.
Протокол DM определяет три объекта управления (MO) 120 стандарта DM, которые должны поддерживать все реализации программы-клиента 110 DM. Эти объекты MO 120 стандарта DM включают в себя MO 122 учетной записи (Acc) DM (DMACC MO), MO 124 информации об устройстве (DevInfo) и MO 126 деталей устройства (DevDetail).
MO 122 Acc DM используется для управления информацией, имеющей отношение к серверам 140 DM с самозагрузкой. Для каждого сервера 140 DM, который был успешно загружен для устройства 100 DM, MO 122 Acc DM поддерживает информацию об идентификаторе сервера DM (ID), информацию о возможности соединения, адрес сервера, верительные данные сервера и программы-клиента и т.д. MO 124 DevInfo обеспечивает основную информацию об устройстве 100, связанном с программой-клиентом 110 DM. Основная информация включает в себя ID устройства, ID изготовителя устройства, ID модели и настройки языков. MO 126 DevDetail обеспечивает дополнительную информацию об устройстве 100, связанном с программой-клиентом 110 DM. Дополнительная информация включает в себя тип устройства, производителя оригинального оборудования (OEM), модификацию аппаратного обеспечения, модификацию микропрограммного обеспечения, модификацию программного обеспечения, индикацию относительно того, поддерживает ли устройство 100 дополнительные функции (например, возможность манипулирования большими объектами), максимальную глубину дерева управления, максимальную полную длину любого унифицированного идентификатора ресурса (URI) и максимальную полную длину любого сегмента URI.
Пример системы связи, применяющей OMA-DM, описывается ниже в отношении фиг.2.
Фиг.2 иллюстрирует примерную систему связи, применяющую OMA-DM в соответствии с предшествующим уровнем техники.
Что касается фиг.2, то на ней примерная система связи, применяющая OMA-DM, может включать в себя проводную сеть 200, беспроводную сеть 202, проводное устройство 210, беспроводное устройство 212, сервер 220 DM и орган 230 управления DM. Каждое из проводного устройства 210 и беспроводного устройства 212 связано с программой-клиентом DM (не показано). Кроме того, орган 230 управления DM может быть системой поддержки операций (OSS). На фиг.2 сплошные линии представляют возможность физического соединения, а пунктирные линии представляют возможность логического соединения.
Примерная система связи, применяющая OMA-DM, которая иллюстрируется на фиг.2, является просто одной из многих возможных реализаций. Например, одна из проводной сети 200 и беспроводной сети 202 может быть опущена. В качестве альтернативы, проводная сеть 200 и беспроводная сеть 202 могут быть объединены. Кроме того, хотя сервер 220 DM и орган 230 управления DM показаны подсоединенными к проводной сети 200, в качестве альтернативы один или оба из сервера 220 DM и органа 230 управления DM могут быть подсоединены к беспроводной сети 202.
Чтобы способствовать выполнению OMA-DM в системе связи, иллюстрируемой на фиг.2, между сервером 220 DM и программой-клиентом DM, связанной с беспроводным устройством 212, и между сервером 220 DM и программой-клиентом DM, связанной с проводным устройством 210, используется двухсторонний протокол, основанный на спецификации OMA-DM. Орган 230 управления DM может направлять операции DM программы-клиента DM, связанной с каждым из проводного устройства 210 и беспроводного устройства 212, через сервер 220 DM. В рамках спецификации OMA-DM находится только взаимодействие между сервером 220 DM и программой-клиентом DM, связанной с каждым из проводного устройства 210 и беспроводного устройства 212.
Пример инициируемого сервером DM сеанса связи DM с программой-клиентом DM описывается ниже в отношении фиг.3.
Фиг.3 представляет схему прохождения сигнала для инициируемого сервером DM сеанса связи DM с программой-клиентом DM в системе связи в соответствии с предшествующим уровнем техники.
Что касается фиг.3, то на ней инициируемый сервером DM сеанс связи DM между сервером 302 DM и программой-клиентом 304 DM включает в себя две фазы. Первая фаза представляет собой фазу 310 настройки, а вторая фаза представляет собой фазу 320 управления. Фаза 310 настройки включает в себя обмен информацией для аутентификации и информацией об устройстве. Обмен информацией в фазе 310 настройки включает в себя три пакета, каждый из которых может содержать множество сообщений, а именно Пакет 0 (312), Пакет 1 (314) и Пакет 2 (316). Пакет 0 (312) отправляется от сервера 302 DM программе-клиенту 304 DM и упоминается как уведомляющее сообщение. Пакет 1 (314) отправляется от программы-клиента 304 DM на сервер 302 DM. Пакет 1 (314) включает в себя информацию об инициализации программы-клиента и информацию об устройстве. Информация об инициализации программы-клиента включает в себя верительные данные программы-клиента. Пакет 2 (316) отправляется от сервера 302 DM программе-клиенту 304 DM. Пакет 2 (316) включает в себя информацию об инициализации сервера и начальную операцию управления. Информация об инициализации сервера включает в себя одно или более верительных данных сервера.
Фаза 320 управления включает в себя обмен двумя пакетами, а именно Пакетом 3 (322) и Пакетом 4 (324). Пакет 3 (322) отправляется от программы-клиента 304 DM на сервер 302 DM. Пакет 3 (322) включает в себя ответную информацию программы-клиента на операцию управления, инициированную Пакетом 2 (316). Пакет 4 (324) отправляется от сервера 302 DM программе-клиенту 304 DM. Пакет 4 (324) включает в себя по меньшей мере одну из дополнительной операции управления и одну или более дополнительных команд взаимодействия с пользователем, если сеанс связи DM продолжается вне сообщения 316 Пакета 2. Дополнительные циклы сообщения 322 Пакета 3 и сообщения 324 Пакета 4 могут передаваться между сервером 302 DM и программой-клиентом 304 DM до тех пор, пока сеанс связи DM не завершится.
Применяемая в настоящее время версия стандарта OMA-DM представляет собой версию 1.2.1. Рабочая группа OMA-DM в настоящее время разрабатывает две новые версии протокола DM, а именно версию 1.3 OMA-DM и версию 2.0 OMA-DM. Версия 1.3 OMA-DM разрабатывается для того, чтобы рассматривать некоторые из слабых мест в системе безопасности в версии 1.2.1 OMA-DM.
Раскрытие сущности изобретения
Техническая проблема
Однако разработка более новых версий OMA-DM ставит некоторые новые проблемы, которые должна рассматривать Рабочая группа DM. Например, в отличие от версии 1.2.1 OMA-DM, устройства, которыми управляют с помощью новых версий OMA-DM, могут не иметь глобально маршрутизируемого адреса. Главная причина для этого состоит в том, что по соображениям безопасности многие из устройств, являющихся целевым объектом в новых версиях OMA-DM, могут быть размещены после устройства, которое обеспечивает функциональные возможности трансляции сетевых адресов (NAT) и/или брандмауэра. Дополнительно, многие из устройств могут быть кочующими, и их адрес контролируется сетью, в которой они размещены. Другая проблема, которую ставят новые версии OMA-DM, состоит в том, что некоторые из устройств могут не иметь встроенной программы-клиента OMA-DM.
Для рассмотрения некоторых из описанных выше проблем проводится исследование шлюзового устройства. Шлюзовое устройство представляет собой объект, который облегчает взаимодействие между сервером DM и программой-клиентом DM, по меньшей мере один из которых выполняет OMA-DM, в ситуациях, в которых невозможно прямое и лишенное помощи взаимодействие между сервером DM и программой-клиентом DM.
В отличие от этого, в современной концепции OMA-DM шлюзовое устройство, как ожидают, будет играть главную роль в управлении устройствами в новых версиях OMA-DM. Соответственно, разрабатывается механизм реализации MO шлюза (GwMO) для использования с новыми версиями OMA-DM.
Поэтому существует потребность в методиках управления функциональными возможностями шлюза для поддержки DM в системе связи.
Решение проблемы
Аспект настоящего изобретения заключается в том, чтобы рассмотреть по меньшей мере вышеупомянутые проблемы и/или недостатки и обеспечить по меньшей мере преимущества, описанные ниже. Соответственно, аспект настоящего изобретения должен обеспечить методики для управления функциональными возможностями шлюза для поддержки управления устройствами (DM) в системе связи.
В соответствии с аспектом настоящего изобретения обеспечен способ функционирования шлюза DM в системе связи, включающей в себя шлюз DM, сервер DM и устройство. Способ включает в себя выявление шлюзом DM нового управляемого устройства, определение шлюзом DM одной или более характеристик устройства и активизирование шлюзом DM алгоритма на основании определяемых одной или более характеристик устройства, при этом шлюз DM функционирует в соответствии с активизированным алгоритмом так, чтобы сервер DM впоследствии мог управлять устройством, отправляя команды управления на устройство, через шлюз DM, и обрабатывая предупреждения, принятые от устройства, через шлюз DM.
В соответствии с другим аспектом настоящего изобретения обеспечен способ функционирования шлюза DM в системе связи, включающей в себя шлюз DM, сервер DM и устройство. Способ включает в себя прием шлюзом DM информационного сообщения об услугах/возможностях от устройства, определение шлюзом DM, поддерживает ли устройство протокол DM, используемый сервером DM, основываясь на информационном сообщении об услугах/возможностях, если определено, что устройство не поддерживает протокол DM, используемый сервером DM, определение, установлен ли флаг информирования сервера DM для устройства на истину в объекте управления (MO) конфигурации (Config) шлюза, и если определено, что флаг информирования сервера DM для устройства установлен на истину, попытку установления связи с сервером DM от имени устройства и обновление атрибута возможности соединения сервера DM для устройства в MO учетной записи устройств локальной сети (LAN).
В соответствии с еще одним аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обновления информации начальной загрузки для некоторого класса устройств. Способ включает в себя прием шлюзом DM обновленной информации начальной загрузки для некоторого класса устройств, обновление шлюзом DM информации начальной загрузки для некоторого класса устройств и поиск шлюзом DM MO учетной записи устройств LAN для устройств, тип устройства которых согласуется с типом устройства в обновленном сообщении начальной загрузки.
В соответствии с еще одним аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обрабатывания команды DM. Способ включает в себя прием шлюзом DM команды DM для устройства от сервера DM, определение шлюзом DM, имеется ли запись для устройства в MO учетной записи устройств LAN, если определено, что запись для устройства в MO учетной записи устройств LAN имеется, передачу шлюзом DM команды DM на устройство и ожидание ответа в пределах предварительно определенного времени, и если ответ в пределах предварительно определенного времени принят, передачу шлюзом DM ответа на сервер DM.
В соответствии с другим аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обрабатывания сообщений о прерывании. Способ включает в себя прием шлюзом DM сообщения о прерывании от устройства, определение шлюзом DM, имеется ли запись для устройства в MO учетной записи устройств LAN, если определено, что для устройства в MO учетной записи устройств LAN записи нет, активизирование шлюзом DM одной из роли прокси-сервера и роли адаптации протокола и определение шлюзом DM, имеется ли информация о пункте назначения, идентифицирующая сервер DM в принятом сообщении прерывания, если определено, что для устройства в MO учетной записи устройств LAN запись имеется, определение шлюзом DM, имеется ли информация о пункте назначения, идентифицирующая сервер DM в принятом сообщении прерывания, и если определено, что информация о пункте назначения в принятом сообщении прерывания, идентифицирующем сервер DM, имеется, передачу сообщения о прерывании на сервер DM, идентифицированный в информации о пункте назначения.
В соответствии с еще одним аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обрабатывания периодического информационного сообщения об услугах/возможностях. Способ включает в себя прием шлюзом DM периодического информационного сообщения об услугах/возможностях от устройства и возврат в исходное состояние шлюзом DM времени допустимости для устройства в MO учетной записи устройств LAN.
В соответствии с еще одним аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обрабатывания окончания интервала контроля времени. Способ включает в себя определение шлюзом DM, что время таймера интервала контроля времени истекло, и когда определено, что время таймера интервала контроля времени истекло, удаление шлюзом DM записей устройств в MO учетной записи устройств LAN, имеющих время допустимости, которое истекло.
Другие аспекты, преимущества и характерные признаки изобретения специалистам в данной области техники станут очевидными из последующего подробного описания, приведенного в связи с прилагаемыми чертежами, которое раскрывает примерные варианты осуществления изобретения.
Выгодные эффекты от изобретения
Аспект настоящего изобретения заключается в том, чтобы обеспечить методики управления функциональными возможностями шлюза для поддержки управления устройствами (DM) в системе связи.
Краткое описание чертежей
Вышеупомянутые и другие аспекты, функции и преимущества некоторых примерных вариантов осуществления настоящего изобретения станут более очевидными из последующего описания при рассмотрении его вместе с прилагаемыми чертежами, на которых:
фиг.1 иллюстрирует архитектуру открытого союза связи с мобильными объектами (ОМА) - управления устройствами (DM) в соответствии с предшествующим уровнем техники;
фиг.2 иллюстрирует примерную систему связи, применяющую OMA-DM в соответствии с предшествующим уровнем техники;
фиг.3 представляет схему прохождения сигнала для сервера DM, инициируемого сеансом связи DM с программой-клиентом DM в системе связи, в соответствии с предшествующим уровнем техники;
фиг.4 представляет блок-схему процесса для начальной обработки информационного сообщения об услугах/возможностях в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.5 представляет блок-схему процесса для алгоритма роли сервера начальной загрузки в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.6 представляет блок-схему процесса для алгоритма роли прокси-сервера в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.7 представляет блок-схему процесса функциональных возможностей, выполняемых на шлюзе DM для реализации алгоритма роли адаптации протокола, в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.8 представляет блок-схему процесса для обновления информации начальной загрузки для некоторого типа устройств в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.9 представляет блок-схему процесса для обработки команд DM в шлюзе DM, которые предназначаются для устройств конечного пользователя, в случае, в котором шлюз DM находится в роли прокси-сервера или в роли адаптации протокола, в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.10 представляет блок-схему процесса для обработки сообщений о прерывании в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.11 представляет блок-схему процесса для обработки периодического сообщения об услугах/возможностях в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.12 представляет блок-схему процесса для обработки сообщения об окончании интервала контроля времени в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;
фиг.13 представляет блок-схему шлюза DM в соответствии с примерным вариантом осуществления настоящего изобретения.
На всех чертежах подобные позиционные обозначения, как можно понять, относятся к подобным частям, компонентам и структурам.
Способ выполнения изобретения
Последующее описание в отношении прилагаемых чертежей обеспечено для того, чтобы помочь во всестороннем понимании примерных вариантов осуществления изобретения, как определено пунктами формулы изобретения и их эквивалентами. Оно включает в себя различные определенные детали, чтобы помочь в этом понимании, но их следует расценивать, как просто примерные. Соответственно, специалистам в данной области техники должно быть понятно, что могут быть сделаны различные видоизменения и модификации вариантов осуществления, описанных в данном описании, не выходя при этом за рамки объема и сущности изобретения. Кроме того, описания известных функций и конструкций опущены для ясности и краткости.
Термины и слова, используемые в последующем описании и формуле изобретения, не ограничиваются библиографическими значениями, но просто используются автором изобретения для того, чтобы обеспечить возможность ясного и непротиворечивого понимания изобретения. Соответственно, специалистам в данной области техники должно быть очевидно, что последующее описание примерных вариантов осуществления настоящего изобретения обеспечено только для целей иллюстрирования, а не с целью ограничения изобретения, как определено прилагаемыми пунктами формулы изобретения и их эквивалентами.
Должно быть понятно, что формы единственного числа "a", "an" и "the" включают в себя множественные ссылки, если контекст ясно не диктует иначе. Таким образом, например, ссылка на "компонентную поверхность" включает в себя ссылку на одну или более таких поверхностей.
Под термином "по существу" подразумевается, что упоминаемая характеристика, параметр или значение не должны быть точно достигнуты, но что отклонения или вариации, включающие в себя, например, допуски, погрешность измерения, ограничения точности измерения и другие факторы, известные специалистам в данной области техники, могут встречаться в количествах, которые не препятствуют эффекту, для обеспечения которого была предназначена эта характеристика.
Описанные ниже примерные варианты осуществления настоящего изобретения относятся к методикам управления устройствами (DM) в системе связи. Более конкретно, описанные ниже примерные варианты осуществления настоящего изобретения относятся к методикам управления функциональными возможностями шлюза для поддержки DM в системе связи. Хотя методики управления функциональными возможностями шлюза для поддержки DM в системе связи могут быть описаны ниже в контексте версии 2.0 открытого союза связи с мобильными объектами (OMA)-DM (в дальнейшем именуемой как DM 2.0) и/или механизма реализации объекта функционирования шлюза (GwMO), настоящее изобретение также применимо к другому DM или другим версиям OMA-DM и механизмам реализации. Ниже, шлюзовое устройство, предназначенное для поддержки DM в системе связи, упоминается как шлюз DM.
Следует отметить, что когда упоминается термин "устройство", этот термин "устройство" может быть включающим в себя связанную программу-клиента DM, выполняющуюся на устройстве. Дополнительно следует отметить, что хотя примерные варианты осуществления настоящего изобретения описываются в контексте единственного сервера DM и единственного устройства для данного шлюза DM, с данным шлюзом DM может быть использовано любое количество серверов DM и/или устройств. Хотя шлюз DM может быть физически расположен где-либо в системе связи, предпочтительно, чтобы шлюз DM логически располагался между сервером DM и устройством.
Должно быть понятно, что последующее описание может ссылаться на термины, используемые в различных стандартах, только для простоты объяснения. Например, последующее описание может ссылаться на термины, используемые в одном из стандартов ОМА, таких как стандарт OMA-DM. Однако это описание не должно интерпретироваться как ограничиваемое такими стандартами. Независимо от механизма, используемого для управления функциональными возможностями шлюза для поддержки DM в системе связи, для такой возможности выгодно соответствовать стандартизированному механизму.
Ниже описаны различные роли шлюза DM и функциональные возможности новых объектов управления (MO) в соответствии с примерными вариантами осуществления настоящего изобретения.
Роли шлюза DM
Шлюз DM может играть любую из некоторого количества ролей, включающих в себя роль сервера начальной загрузки, роль прокси-сервера и роль адаптации протокола. В роли сервера начальной загрузки шлюз DM отвечает за начальную загрузку программы-клиента DM в устройстве (то есть за установление соединения между сервером DM и программой-клиентом DM, связанной с устройством). Помимо всего прочего, роль сервера начальной загрузки может вызывать отображение локального транспортного адреса устройства в его адрес глобальной сети (WAN). Здесь следует отметить, что адрес локальной сети (LAN) устройства может быть не маршрутизируемым в WAN. Как только соединение между сервером DM и программой-клиентом DM, связанной с устройством, установлено, шлюз DM не играет дальнейшую роль в управлении устройством.
В роли прокси-сервера все установление связи между устройством конечного пользователя и сервером DM происходит через шлюз DM. В этот момент шлюз DM функционирует как сервер DM для устройства, и шлюз DM осуществляет связь с внешними серверами DM от имени устройства.
В роли адаптации протокола шлюз DM обеспечивает функциональные возможности прокси-сервера, описанные выше. Дополнительно, шлюз DM выполняет адаптацию между собственным протоколом управления устройства и протоколом OMA-DM, который используется сервером DM.
В примерных вариантах осуществления настоящего изобретения предполагается, что устройство выпускает информационное сообщение об услугах/возможностях, которое принимается шлюзом DM. В данном описании термин "информационное сообщение об услугах/возможностях" предназначается для того, чтобы содержать какое-либо сообщение, отправляемое устройством, которое информирует об услугах и/или возможностях, или какое-либо сообщение, которое выполняет подобную функцию. Информационное сообщение об услугах/возможностях может быть выпущено после включения питания устройства и/или выпускаться периодически. Детали механизма для выявления устройства или услуги выходят за пределы этого раскрытия и, таким образом, опускаются для краткости.
Новые функциональные возможности MO
Чтобы учесть различные роли, в которых может функционировать шлюз DM, обеспечены новые функциональные возможности MO в соответствии с примерными вариантами осуществления настоящего изобретения. Новые функциональные возможности MO иллюстрируются в данном описании с помощью новых объектов MO, которые включают в себя MO конфигурации (Config) шлюза и MO учетной записи устройств LAN. Термины "MO Config" и "MO учетной записи устройств LAN" используются просто для удобства в объяснении и могут изменяться в зависимости от системы условных обозначений, принятой основной частью стандартизации. Кроме того, хотя для удобства в объяснении MO Config и MO учетной записи устройств LAN описываются в данном описании как отдельные объекты MO, их совместные функциональные возможности могут быть распределены среди различного количества объектов MO, и/или все или часть их совместных функциональных возможностей могут быть включены в другие объекты MO. Эти новые объекты MO сосредотачиваются на функциональных возможностях, которые должен поддерживать шлюз DM, в то же время оставляя множество деталей, таких как выявление устройств, отображение адресов LAN/WAN, адаптация протокола управления и т.д., для конкретной реализации.
Функциональные возможности MO Config шлюза заключаются в том, чтобы поддерживать профили учетной записи (Acc) DM для различных типов устройств. Каждый профиль Acc DM включает в себя информацию, которая подобна той, что включена в соответствующий MO Acc DM. Информация включает в себя идентификатор (ID) сервера DM, адрес сервера DM и верительные данные. Каждый профиль Acc DM имеет уникальный ID, и множество устройств могут совместно использовать один и тот же профиль Acc DM. Каждый профиль Acc DM может быть определенным для некоторого типа устройств. Для каждого типа устройств, MO Config шлюза может включать в себя Булев флаг, чтобы указывать, нужно ли с сервером (серверами) DM осуществлять связь после выявления нового устройства указанного типа. У сервера DM имеется доступ чтения-записи к MO Config шлюза.
Функциональные возможности MO учетной записи устройств LAN заключаются в том, чтобы поддерживать перечень устройств, которые находятся в LAN и которые обнаруживаются шлюзом DM. Как упомянуто выше, механизм для выявления устройств шлюзом DM оставляется для конкретной реализации. В отличие от MO Config шлюза, сервер DM может иметь доступ только для чтения к MO учетной записи устройств LAN. MO учетной записи устройств LAN заполняется программой-клиентом DM, выполняемой в шлюзе DM, когда шлюз DM обнаруживает новые устройства в LAN. Примеры информации, которую MO учетной записи устройств LAN может поддерживать относительно каждого устройства, обнаруживаемого в LAN, включают в себя один или больше из следующих элементов:
- Тип устройства и/или подтип устройства
- Аппаратный адрес устройства (то есть адрес управления доступом к среде передачи данных (MAC), международный идентификационный номер оборудования подвижной станции (IMEI), ID аппаратуры мобильной связи (MEID) и т.д.)
- ID профиля Acc DM
- Роль, которую играет шлюз DM для этого устройства (то есть сервер начальной загрузки, прокси-сервер или адаптация протокола)
- Время истечения срока допустимости (то есть время, после которого запись устройства из учетной записи будет удалена, если новое сообщение окончания интервала контроля времени не будет принято шлюзом DM)
- Отображение между адресами сторон WAN и LAN устройства (только для роли сервера начальной загрузки)
- Состояние возможности соединения сервера DM (то есть установлено ли успешно соединение с сервером (серверами) DM)
- Информация о приостановленной транзакции DM.
Функциональные возможности шлюза DM с использованием примерных новых объектов MO
В дальнейшем примерные варианты осуществления настоящего изобретения, которые включают в себя функциональные возможности шлюза DM, использующие функциональные возможности примерных новых объектов MO, описанных выше, будут описаны ниже. Контекст для различных ролей, которые играет шлюзовое устройство DM, будет описан ниже в отношении фиг.4.
Фиг.4 представляет блок-схему процесса для начальной обработки информационного сообщения об услугах/возможностях в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.4, то на ней на этапе 402 шлюз DM принимает информационное сообщение об услугах/возможностях от устройства. Следует отметить, что информационные сообщения об услугах/возможностях могут выпускаться устройствами периодически. В данном описании предполагается, что информационное сообщение об услугах/возможностях, принятое на этапе 402, является первым информационным сообщением об услугах/возможностях.
На этапе 404 шлюз DM определяет, соединено ли устройство непосредственно с сервером DM и, таким образом, обходит шлюз DM. В этот момент шлюз DM может определить, соединено ли устройство непосредственно с сервером DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Дополнительно следует отметить, что устройства, которые непосредственно соединяются с сервером DM (то есть устройства, который обходят шлюз DM), могут не выпускать информационное сообщение об услугах/возможностях. Кроме того, для устройств, которые непосредственно соединяются с сервером DM, шлюз DM может быть не осведомлен о таких устройствах в LAN. Если шлюз DM определяет, что устройство непосредственно соединено с сервером DM и, таким образом, обходит шлюз DM, процесс завершается. В противоположность этому, если шлюз DM определяет, что устройство непосредственно не соединено с сервером DM и, таким образом, не обходит шлюз DM, процесс переходит к этапу 406.
На этапе 406 шлюз DM определяет, поддерживает ли устройство OMA-DM. В этот момент шлюз DM может определить, поддерживает ли устройство OMA-DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Если шлюз DM определяет, что устройство не поддерживает OMA-DM, на этапе 408 шлюз DM активизирует алгоритм роли адаптации протокола. После этого процесс завершается. Алгоритм роли адаптации протокола описывается более подробно ниже в отношении фиг.7. В противоположность этому, если шлюз DM определяет, что устройство поддерживает OMA-DM, процесс переходит к этапу 410.
На этапе 410 шлюз DM определяет, выполнено ли устройство с возможностью прокси-соединения с сервером DM. В этот момент шлюз DM может определять, выполнено ли устройство с возможностью прокси-соединения с сервером DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Если шлюз DM определяет, что устройство не выполнено с возможностью прокси-соединения с сервером DM, на этапе 412 шлюз DM активизирует алгоритм роли сервера начальной загрузки. После этого процесс завершается. Алгоритм роли сервера начальной загрузки описывается более подробно ниже в отношении фиг.5. В противоположность этому, если шлюз DM определяет, что устройство выполнено с возможностью прокси-соединения с сервером DM, на этапе 414 шлюз DM активизирует алгоритм роли прокси-сервера. После этого процесс завершается. Алгоритм роли прокси-сервера описывается более подробно ниже в отношении фиг.6.
Здесь следует отметить, что этапы блок-схемы фиг.4 могут быть активизированы в любом порядке. Роль сервера начальной загрузки шлюза DM будет описана ниже в отношении фиг.5.
Фиг.5 представляет блок-схему процесса для алгоритма роли сервера начальной загрузки в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.5, то на ней шлюз DM на этапе 502 получает адрес стороны WAN для устройства. Шлюз DM может обратиться к любой известной схеме прохождения преобразования сетевых адресов (NAT), такой как простое прохождение протокола пользовательских дейтаграмм через преобразования NAT (STUN), прохождение с использованием NAT ретрансляции (TURN) и т.д., или может использовать для этой цели собственную схему.
На этапе 504 шлюз DM добавляет информацию, имеющую отношение к устройству, к MO учетной записи устройств LAN. На этапе 506 шлюз DM определяет, имеет ли MO Config шлюза информацию начальной загрузки для этого типа устройства. Если шлюз DM определяет, что MO Config шлюза имеет информацию начальной загрузки для этого типа устройства, процесс переходит к этапу 508. На этапе 508 шлюз DM пересылает информацию начальной загрузки на устройство. На этапе 510 шлюз DM может пересылать адрес стороны WAN устройства на устройство. После этого процесс завершается. В противоположность этому, если шлюз DM определяет, что MO Config шлюза не имеет информации начальной загрузки для этого типа устройства, процесс переходит к этапу 512. На этапе 512 шлюз DM может пересылать на устройство только адрес стороны WAN. После этого процесс завершается.
В данном описании этапы 510 и 512 являются необязательными, и, таким образом, один или более из этапов 510 и 512 могут быть опущены. Когда один или больше из этапов 510 и 512 опущены, процесс переходит к следующему этапу.
Роль прокси-сервера шлюза DM будет описана ниже в отношении фиг.6.
Фиг.6 представляет блок-схему процесса для алгоритма роли прокси-сервера в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.6, то на ней на этапе 602 шлюз DM добавляет информацию, имеющую отношение к устройству, в MO учетной записи устройств LAN. На этапе 604 шлюз DM переходит к начальной загрузке DM устройства собственным адресом шлюза DM. На этапе 606 шлюз DM определяет, содержит ли информационное сообщение об услугах/возможностях, выпущенное устройством, какую-либо информацию начальной загрузки. Если шлюз DM определяет, что информационное сообщение об услугах/возможностях, выпущенное устройством, не содержит какую-либо информацию начальной загрузки, процесс переходит к этапу 608.
На этапе 608 шлюз DM определяет, имеется ли информация начальной загрузки DM для этого типа устройства в MO Config шлюза. Если шлюз DM определяет, что информации начальной загрузки DM для этого типа устройства в MO Config шлюза не имеется, процесс завершается. В противоположность этому, если шлюз DM определяет, что информация начальной загрузки DM для этого типа устройства в MO Config шлюза имеется, процесс переходит к этапу 610. На этапе 610 шлюз DM может обновлять запись для устройства в MO учетной записи устройств LAN со скорректированным ID профиля Acc DM в соответствии с MO Config шлюза. После этого процесс переходит к этапу 616, который дополнительно описывается ниже.
Возвращаясь к этапу 606, отметим, если шлюз DM определяет, что информационное сообщение об услугах/возможностях, выпущенное устройством, содержит информацию начальной загрузки, процесс переходит к этапу 612. На этапе 612 шлюз DM может создавать новый профиль Acc DM в MO Config шлюза. На этапе 614 шлюз DM может обновлять запись устройства в MO учетной записи устройств LAN с новым ID профиля Acc DM. После этого процесс переходит к этапу 616.
На этапе 616 шлюз DM определяет, является ли флаг "информирования сервера DM" для рассматриваемого типа устройства истинным. Если шлюз DM определяет, что флаг не установлен на истину, процесс завершается. В противоположность этому, если шлюз DM определяет, что флаг установлен на истину, на этапе 618 шлюз DM пытается установить связь с сервером (серверами) DM от имени устройства, используя надлежащие верительные данные. На этапе 620 шлюз DM может обновлять атрибут возможности соединения сервера DM для этого устройства в MO учетной записи устройств LAN, основываясь на состоянии попытки установления связи с сервером (серверами) DM, на этапе 610. После этого процесс завершается.
В данном описании этапы 610-614 и 620 являются необязательными, и, таким образом, один или более из этапов 610-614 и 620 могут быть опущены. Когда один или более из этапов 610-614 и 620 опущены, процесс переходит к следующему этапу.
Роль адаптации протокола шлюза DM будет описана ниже в отношении фиг.7.
Фиг.7 представляет блок-схему процесса функциональных возможностей, выполняемых на шлюзе DM для реализации алгоритма роли адаптации протокола, в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.7, то на ней на этапе 702 шлюз DM добавляет информацию, имеющую отношение к устройству, в MO учетной записи устройств LAN. На этапе 704 шлюз DM определяет, имеется ли информация начальной загрузки DM для этого типа устройства в MO Config шлюза. Если шлюз DM определяет, что информации начальной загрузки DM для этого типа устройства в MO конфигурации шлюза не имеется, процесс завершается. В противоположность этому, если шлюз DM определяет, что информация начальной загрузки DM для этого типа устройства в MO конфигурации шлюза имеется, процесс переходит к этапу 706. На этапе 706 шлюз DM может обновлять запись для устройства в MO учетной записи устройств LAN со скорректированным ID профиля Acc DM в соответствии с MO Config шлюза. На этапе 708 шлюз определяет, является ли флаг "информирования сервера DM" для рассматриваемого типа устройства истинным. Если шлюз DM определяет, что флаг не установлен на истину, процесс завершается. В противоположность этому, если шлюз DM определяет, что флаг установлен на истину, процесс переходит к этапу 710. На этапе 710 шлюз DM пытается установить связь с сервером (серверами) DM от имени устройства, используя надлежащие верительные данные. На этапе 712 шлюз DM может обновлять атрибут возможности соединения сервера DM для этого устройства в MO учетной записи устройств LAN, основываясь на состоянии попытки установления связи с сервером (серверами) DM. После этого процесс завершается.
В данном описании этапы 706 и 712 являются необязательными, и, таким образом, один или более из этапов 706 и 712 могут быть опущены. Когда один или более из этапов 706 и 712 опущены, процесс переходит к следующему этапу.
Как обсуждалось выше, профили Acc DM сохраняются одним или более объектами MO для различных типов устройства. Алгоритм для обновления профиля Acc DM в MO Config шлюза описывается ниже в отношении фиг.8.
Фиг.8 представляет блок-схему процесса для обновления информации начальной загрузки для некоторого типа устройств в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.8, то на ней на этапе 802 шлюз DM принимает сообщение об обновлении начальной загрузки для некоторого устройства. На этапе 804 шлюз DM обновляет информацию начальной загрузки для типа устройства, определяемого в сообщении об обновлении начальной загрузки. На этапе 806 шлюз DM выбирает следующую запись в MO учетной записи устройств LAN. В данном описании, если непосредственно предшествующим этапом является этап 804, то выбранная запись в MO учетной записи устройств LAN представляет собой первую запись.
На этапе 808 шлюз DM просматривает MO учетной записи устройств LAN, определяет, имеется ли соответствие между типом устройства для устройства в MO учетной записи LAN и типом устройства, указанным в сообщении об обновлении начальной загрузки. Если шлюз DM определяет, что там нет соответствия, процесс переходит к этапу 816, который дополнительно описывается ниже. В противоположность этому, если шлюз DM определяет, что имеется соответствие, процесс переходит к этапу 810.
На этапе 810 шлюз DM определяет, находится ли он в роли сервера начальной загрузки для устройства. Если шлюз DM определяет, что он не находится в роли сервера начальной загрузки для устройства, процесс переходит к этапу 814, который дополнительно описывается ниже. В противоположность этому, если шлюз DM определяет, что он находится в роли сервера начальной загрузки для устройства, процесс переходит к этапу 812. На этапе 812 шлюз DM перемещает обновленную информацию начальной загрузки DM в устройство. На этапе 814 шлюз DM может обновлять записи для затрагиваемых устройств в MO учетной записи устройств LAN. В данном описании этап 814 является необязательным, и, таким образом, этап 814 может быть опущен. Когда этап 814 опущен, процесс переходит к этапу 816. На этапе 816 шлюз DM определяет, имеется ли другая запись. Если шлюз DM определяет, что имеется другая запись, процесс возвращается к этапу 806, в противном случае процесс завершается.
Алгоритм для обработки команд DM, предназначенный для устройств конечного пользователя, в случае, в котором шлюз DM находится в роли прокси-сервера или в роли адаптации протокола, описывается ниже в отношении фиг.9.
Фиг.9 представляет блок-схему процесса для обработки команд DM в шлюзе DM, которые предназначаются для устройств конечного пользователя, в случае, в котором шлюз DM находится в роли прокси-сервера или в роли адаптации протокола, в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.9, то на ней на этапе 902 шлюз DM принимает команду DM, предназначенную для устройства LAN, от сервера DM. На этапе 904 шлюз DM определяет, имеется ли целевое устройство в MO учетной записи устройств LAN. Если шлюз DM определяет, что целевого устройства в MO учетной записи устройств LAN нет, на этапе 906 на сервер DM отправляется ответ с отказом. После этого процесс завершается. В противоположность этому, если шлюз DM определяет, что целевое устройство в MO учетной записи устройств LAN имеется, процесс переходит к этапу 908.
На этапе 908 шлюз DM определяет, находится ли он в роли адаптации протокола. Если шлюз DM определяет, что он не находится в роли адаптации протокола, процесс переходит к этапу 912, который дополнительно описывается ниже. В противоположность этому, если шлюз DM определяет, что он находится в роли адаптации протокола, на этапе 910 шлюз DM адаптирует команду DM к протоколу управления, естественно поддерживаемому устройством, и затем переходит к этапу 912. На этапе 912 команда пересылается в устройство. На этапе 914 шлюз DM ожидает ответ на пересылаемую команду и определяет, принят ли ответ. Если ответ не принят в пределах предварительно определенного периода времени, на этапе 916 шлюз DM отправляет на сервер DM ответ с отказом. После этого процесс завершается. В противоположность этому, если ответ принят в пределах предварительно определенного периода времени, шлюз DM переходит к этапу 918.
На этапе 918 шлюз DM определяет, находится ли он в роли адаптации протокола. Шлюз DM может быть в роли адаптации протокола, когда устройство не поддерживает OMA-DM. Если шлюз DM определяет, что он не находится в роли адаптации протокола, шлюз DM переходит к этапу 922, который описывается ниже. В противоположность этому, если шлюз DM определяет, что он находится в роли адаптации протокола, на этапе 920 шлюз DM адаптирует ответ к OMA-DM и переходит к этапу 922. На этапе 922 шлюз DM пересылает ответ обратно на сервер DM. После этого процесс завершается.
Обработка незапрашиваемых сообщений (или прерываний) описывается ниже на фиг.10.
Фиг.10 представляет блок-схему процесса для обработки сообщений о прерывании в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.10, то на ней на этапе 1002 шлюз DM принимает сообщение о прерывании (незапрашиваемое сообщение) для устройства. На этапе 1004 шлюз DM определяет, имеется ли устройство в настоящий момент в MO учетной записи устройств LAN. Если шлюз DM определяет, что устройство в настоящий момент в MO учетной записи устройств LAN имеется, процесс переходит к этапу 1012, который дополнительно описывается ниже. В противоположность этому, если шлюз DM определяет, что устройства в настоящий момент в MO учетной записи устройств LAN не имеется, процесс переходит к этапу 1006. На этапе 1006 шлюз DM определяет, является ли сообщение о прерывании сообщением OMA-DM. Если шлюз DM определяет, что сообщение о прерывании представляет собой сообщение OMA-DM, шлюз DM добавляет устройство к MO учетной записи устройств LAN и на этапе 1008 активизирует шлюз DM в алгоритме роли прокси-сервера, и переходит к этапу 1012. В противоположность этому, если шлюз DM определяет, что сообщение о прерывании не является сообщением OMA-DM, шлюз DM добавляет устройство к MO учетной записи устройств LAN и на этапе 1010 активизирует шлюз DM в алгоритме роли адаптации протокола, и переходит к этапу 1012.
На этапе 1012 шлюз DM определяет, имеется ли информация о пункте назначения (то есть для сервера DM) в сообщении прерывания от устройства. Если шлюз DM определяет, что в сообщении прерывания от устройства нет информации о пункте назначения, процесс переходит к этапу 1014. На этапе 1014 шлюз DM пытается определить местоположение информации о пункте назначения для прерывания. Если шлюз DM не может определить информацию о пункте назначения, процесс завершается. В противоположность этому, если шлюз DM может определить информацию о пункте назначения прерывания, на этапе 1016 шлюз DM может считывать соответствующую информацию о сервере DM из MO конфигурации шлюза, и затем процесс переходит к этапу 1022, который дополнительно описывается ниже. В данном описании этап 1016 является необязательным, и, таким образом, этап 1016 может быть опущен. Когда этап 1016 опущен, процесс переходит к этапу 1022.
Возвращаясь к этапу 1012, отметим, если шлюз DM определяет, что информация о пункте назначения в сообщении прерывания от устройства имеется, процесс переходит к этапу 1018. На этапе 1018 шлюз DM определяет, находится ли он в роли адаптации протокола. Если шлюз DM определяет, что он не находится в роли адаптации протокола, процесс переходит к этапу 1022. В противоположность этому, если шлюз DM определяет, что он находится в роли адаптации протокола, на этапе 1020 шлюз DM адаптирует сообщение от устройства в формат OMA-DM, и процесс переходит к этапу 1022. На этапе 1022 шлюз DM пересылает сообщение на соответствующий сервер DM. После этого процесс завершается.
Как идентифицировано выше, устройства могут выпускать информационные сообщения об услугах/возможностях периодически, а не только после включения питания. Пример приема периодического информационного сообщения об услугах/возможностях описывается ниже в отношении фиг.11.
Фиг.11 представляет блок-схему процесса для обработки периодического сообщения об услугах/возможностях в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.11, то на ней на этапе 1102 шлюз DM принимает периодическое сообщение об услугах/возможностях от устройства. На этапе 1104 шлюз DM возвращает в исходное состояние "время допустимости" для устройства в MO учетной записи устройств LAN. Этот механизм исключает продолжительные записи в MO, когда устройства выходят из строя, заканчивается заряд батареи или они просто удаляются за пределы сферы полномочий шлюза DM. После этого процесс завершается.
Пример обработки сообщения окончания интервала контроля времени в шлюзе DM описывается ниже в отношении фиг.12.
Фиг.12 представляет блок-схему процесса для обработки сообщения окончания интервала контроля времени в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.12, то на ней на этапе 1202 время таймера интервала контроля времени истекло. На этапе 1204 шлюз DM выбирает следующую запись устройства в MO учетной записи LAN. В данном описании, если никакое устройство еще не выбрано, выбирается первое устройство. На этапе 1206 шлюз DM определяет, истекло ли "время допустимости" для выбранного устройства. Если шлюз DM определяет, что "время допустимости" для выбранного устройства не истекло, процесс переходит к этапу 1210, который дополнительно описывается ниже. В противоположность этому, если шлюз DM определяет, что "время допустимости" для выбранного устройства истекло, процесс переходит к этапу 1208. На этапе 1208 шлюз DM удаляет запись выбранного устройства из MO учетной записи LAN, и процесс переходит к этапу 1210. На этапе 1210 шлюз DM определяет, имеются ли еще записи в MO учетной записи LAN. Если шлюз DM определяет, что имеются еще записи в MO учетной записи LAN, процесс возвращается к этапу 1204. В противоположность этому, если шлюз DM определяет, что в MO учетной записи LAN нет больше записей, процесс возвращается к этапу 1202.
Структура шлюзового устройства DM в соответствии с примерным вариантом осуществления настоящего изобретения будет описана ниже в отношении фиг.13.
Фиг.13 представляет блок-схему шлюза DM в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается фиг.13, то на ней шлюз 1302 DM включает в себя процессор 1304, запоминающее устройство 1306 и блок 1308 связи. Шлюз 1302 DM может включать в себя любое количество дополнительных структурных элементов. Однако описание дополнительных структурных элементов шлюза 1302 DM опущено для краткости.
Процессор 1304 используется для обрабатывания общих операций шлюза 1302 DM и может использоваться для выполнения кода, чтобы выполнять любые из функций/операций/алгоритмов/ролей, явно или неявно описываемых в данном описании, как выполняемые шлюзом DM. Дополнительно, процессор 1304 может осуществлять связь с запоминающим устройством 1306 и/или блоком 1308 связи и/или управлять ими. Термин "код" может использоваться в данном описании для того, чтобы представлять одну или более выполняемых команд, данных операнда, параметров конфигурации и другую информацию, хранящуюся в запоминающем устройстве 1306.
Запоминающее устройство 1306 может сохранять код, который обрабатывается процессором 1304, чтобы выполнять любую из функций/операций/алгоритмов/ролей, явно или неявно описываемых в данном описании, как выполняемые шлюзом DM. Кроме того, одна или более из других выполняемых команд, данных операнда, параметров конфигурации и другой информации могут быть сохранены в запоминающем устройстве 1306. В зависимости от точной конфигурации шлюза 1302 DM, запоминающее устройство 1306 может быть энергозависимым (таким как оперативное запоминающее устройство (RAM, ОЗУ)), энергонезависимым (таким как постоянное запоминающее устройство (ROM, ПЗУ), флэш-память и т.д.) или некоторой комбинацией и того, и другого.
Блок 1308 связи передает и принимает данные между одним или более из устройства, сервера DM и других объектов. Блок 1308 связи может включать в себя любое количество приемопередатчиков, приемников и передатчиков любого количества типов, таких как проводные, беспроводные и т.д.
Некоторые аспекты настоящего изобретения также могут быть воплощены в виде компьютерно-читаемого кода на компьютерно-читаемом носителе записи. Компьютерно-читаемый носитель записи представляет собой любое устройство для хранения данных, которое может сохранять данные, которые могут после этого считываться компьютерной системой. Примеры компьютерно-читаемого носителя записи включают в себя ROM, RAM, компакт-диск (CD) - устройства ROM, магнитные ленты, гибкие диски, оптические устройства хранения данных и несущие (такие как передача данных через Интернет). Компьютерно-читаемый носитель записи также может быть распределен по связанным сетью компьютерным системам так, чтобы компьютерно-читаемый код сохранялся и выполнялся распределенным способом. Также, функциональные программы, код и сегменты кода, предназначенные для выполнения настоящего изобретения, легко могут быть истолкованы программистами, являющимися специалистами в данной области техники, к которой принадлежит настоящее изобретение.
Хотя изобретение показано и описано в отношении его некоторых примерных вариантов осуществления, специалистам в данной области техники должно быть понятно, что там могут быть сделаны различные изменения в форме и деталях, не выходя при этом за рамки объема и сущности изобретения, как определено прилагаемыми пунктами формулы изобретения и их эквивалентами.