Способ инициируемой сервером синхронизации в системе синхронизации, где сообщение запроса от сервера имеет максимальный размер

Способ инициируемой сервером синхронизации в системе синхронизации, где сообщение запроса от сервера имеет максимальный размер

Иллюстрации

Показать все

Реферат

Предшествующий уровень техники

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

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

Фигура 1 иллюстрирует пример синхронизации, где мобильная станция MS действует как устройство клиента SyncML и сетевой сервер S действует как сервер SyncML. Служба синхронизации SyncML предусматривает сначала инициализацию сеанса синхронизации (инициализацию сеанса SyncML), во время которой, например, выбирается база данных, подлежащая синхронизации. Агент клиента MS посылает серверу S сообщение SyncML (модификации клиента), содержащее по меньшей мере данные, которые должны быть синхронизированы в мобильной станции MS и изменились со времени последней синхронизации. Сервер S синхронизирует наборы данных, то есть анализирует изменения, сделанные над наборами данных, и гармонизирует эти данные (делает необходимые модификации, замены, удаления и дополнения). После этого сервер S посылает модификации, выполненные сервером, обратно к устройству TE клиента, которое делает необходимые изменения в его базе данных.

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

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

Согласно протоколу SyncML устройство клиента обычно запускает сеанс синхронизации. Однако, особенно в контексте управления устройством, есть случаи, в которых сервер имеет необходимость запустить синхронизацию. Для этого случая спецификация SyncML «SyncML Sync Protocol, version 1.0.1», май 2001 г., глава 8 (стр. 49-50) описывает инициализацию сеанса синхронизации, вызванную сервером (синхронизация с предупреждением от сервера): сервер может послать сообщение запроса (предупреждение о синхронизации), в котором он запрашивает устройство клиента запустить сеанс SyncML. После этого устройство клиента запускает инициализацию сеанса SyncML посредством передачи стандартного пакета (пакета инициализации клиента). Когда устройством клиента является мобильная станция, возникают проблемы из-за тех фактов, что устройство клиента не может быть доступно, когда мобильная станция отключена, или что нет непрерывного соединения для передачи данных между терминалом и сервером. Вот почему выгодно использовать службу, которая сохраняет сообщение, когда запрос передан. Одной из таких служб является SMS (служба коротких сообщений), которая сохраняет текстовое сообщение в центре текстовых сообщений и посылает их, когда мобильная станция подключена к сети и может быть доступной. Как и другие сообщения SyncML, запрос для запуска сеанса имеет формат XML и содержит поле заголовка, которое определено в элементе [SyncHdr], и часть, относящуюся к телу (внутренней части информационного объекта), которая определена в элементе [SyncBody]:

Этот запрос является относительно большим и требует гораздо большей емкости, чем 140 октетов, обеспеченных текстовым сообщением (которое достаточно для кодирования 160 ASCII символов из 7 битов). Этот запрос может быть разделен на несколько текстовых сообщений, но возможно, что одно из текстовых сообщений исчезает, сообщения приходят в неправильном порядке или что устройство клиента не может обработать сцепленные текстовые сообщения. Если служба транспортного уровня обеспечена WAP (протоколом беспроводного доступа), например, то сообщения SyncML могут быть кодированы в двоичный формат WBXML (беспроводной двоичный XML), и требуется меньшая емкость передачи данных. Даже при использовании WBXML запрос все же требует нескольких текстовых сообщений.

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

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

Изобретение основано на выборе только наиболее существенной информации, которая далее кодируется таким образом, что требуется меньшее пространство по сравнению с ситуацией, в которой информация передавалась бы открытым текстом. Способ содержит конфигурирование сервера синхронизации для определения, для запроса, указывающего необходимость в запуске сеанса и подлежащего передаче к мобильной станции, идентификатора сервера синхронизации, идентификатора версии протокола синхронизации, поддерживаемой сервером синхронизации, и идентификатора запрашиваемого сеанса синхронизации. Максимальный размер сообщения, которое должно быть послано от сервера синхронизации к мобильной станции для запроса, и команды кодирования, посредством которых по меньшей мере один из этих идентификаторов может быть кодирован в последовательность битов, требующую существенно меньше битов, чем его представление ASCII (посредством американского стандартного кода для обмена информацией), определены в сервере синхронизации. Команды декодирования, посредством которых первоначальный идентификатор получают из последовательности битов, определены в мобильной станции. Когда целью является передача по меньшей мере к одной мобильной станции запроса, указывающего необходимость запуска сеанса связи, формируется сообщение, длина которого меньше или равна упомянутому максимальному размеру и которое содержит по меньшей мере упомянутые идентификаторы, по меньшей мере один из которых представлен как последовательность битов, определенная согласно командам кодирования. Это сообщение передается к мобильной станции посредством использования службы передачи сообщений. Мобильная станция формирует сообщение инициализации сеанса связи на основе информации, включенной в принятое сообщение, причем по меньшей мере часть информации определяется из принятой битовой последовательности согласно упомянутым командам декодирования. Сообщение инициализации сеанса связи передается от мобильной станции к серверу синхронизации. Кодирование использует информацию, касающуюся различных значений, которые могут получить различные поля. Соответствие между этими значениями и различными битовыми последовательностями хранится в командах кодирования и командах декодирования, подлежащих использованию сервером и клиентом.

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

Это решение согласно изобретению обеспечивает то преимущество, что по запросу сервера сеанс связи может быть также запущен в устройствах, которые не поддерживают прием сцепленных сообщений. Когда может быть использована служба переноса сообщений, такая как SMS, обеспеченная мобильной сетью, сообщение всегда может быть доставлено по его назначению (когда устройство включено) также в устройствах, которые не допускают службы проталкивания, активируемые сетью. Решение, соответствующее изобретению, также помогает избежать проблем, которые возникают в сети с коммутацией пакетов, возможно доставляющей сообщения к клиенту в порядке, отличающемся от порядка, в котором сервер передал их, или некоторые сообщения возможно даже теряются. Кроме того, поскольку передача запроса требует меньшего объема, также могут быть сэкономлены ресурсы передачи данных, и в результате имеются меньшие издержки. Эта экономия может быть очень значительной в случаях, когда сервер должен передать запрос к большому числу устройств клиентов.

Перечень фигур чертежей

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

фигура 1 - иллюстрация синхронизации согласно протоколу синхронизации SyncML;

фигура 2 - иллюстрация управления устройством посредством сервера;

фигура 3а - иллюстрация системы синхронизации;

фигура 3b - иллюстрация сервера синхронизации и устройства клиента;

фигура 4 - иллюстрация способа согласно предпочтительному варианту осуществления изобретения;

фигура 5 - возможные элементы сообщения, подлежащего посылке для запуска сеанса управления устройством; и

фигура 6 - схема сигнализации сеанса управления согласно предпочтительному варианту осуществления изобретения.

Подробное описание изобретения

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

Фигура 3а иллюстрирует сетевую систему, в которой данные баз данных могут быть синхронизированы между серверами синхронизации S и мобильными станциями MS. При синхронизации MS может действовать как устройство клиента и, таким образом, содержать базу данных, подлежащую синхронизации. Сервер S может обслуживать несколько устройств клиентов MS. Также возможно то, что мобильная станция действует как сервер для другого устройства. MS осуществляет связь с сервером S через мобильную сеть MNW (мобильную сеть). Также возможно то, что S реализован в мобильной сети MNW. Устройство клиента MS, которое присоединено к сети MNW, содержит функциональные возможности мобильной станции для осуществления беспроводной связи с сетью MNW. Вместо стандартной мобильной станции, MS может также быть любым электронным устройством, содержащим функциональные возможности передачи сообщений, таким как портативный компьютер или устройство PDA (персональное цифровое информационное устройство), или альтернативно, например, вспомогательным устройством этих устройств, которое расположено в соединении с его главным устройством посредством его функциональных возможностей передачи сообщений таким образом, что используется, например, линия радиосвязи ближнего действия. В этом случае, главное устройство должно быть способно делать заключения на основе части информации, кодированной в сообщение, что сообщение предназначено для вспомогательного устройства. Мобильная сеть MNW содержит по меньшей мере блок MB, обеспечивающий службу сообщений. Между мобильной сетью MNW и сервером S также могут быть другие сети, такие как локальная сеть LAN. Мобильной сетью MNW может быть любая известная беспроводная сеть, такая как сеть, поддерживающая службу GSM (глобальной системы мобильной связи), сеть, поддерживающая службу GPRS (общая служба пакетной радиопередачи), мобильная сеть третьего поколения, такая как сеть UMTS (универсальная мобильная телекоммуникационная система), беспроводная локальная сеть WLAN или частная сеть.

Если MNW является сетью GSM, то блок МВ, обеспечивающий службу сообщений, содержит по меньшей мере центр службы коротких сообщений SMSC. Важной службой транспортного уровня в нескольких мобильных сетях является WAP, который содержит уровень WSP (беспроводного сеансового протокола), который может быть использован для обеспечения службы переноса для прикладного уровня синхронизации в устройстве клиента MS и в сервере S. WAP поддерживает несколько технологий передачи более низкого уровня, например, передачу, основанную на SMS. Также могут использоваться стандарты HTTP (протокол передачи гипертекста) или OBEX (протокол обмена объектами), например, и поддерживаемые ими технологии передачи более низкого уровня. Сам сервер S может содержать базу данных, которую он синхронизировал, или база данных, синхронизованная им, может быть расположена в другом устройстве, на фигуре 3а серверы S и базы данных DB ради ясности разделены.

Как показано на фигуре 3b, мобильные станции MS и серверы S содержат запоминающее устройство МЕМ; SMEM, пользовательский интерфейс UI; SUI, средства ввода-вывода I/O; SI/O для организации передачи данных, и центральный процессор CPU; SCPU, содержащий один или несколько процессоров. Запоминающее устройство МЕМ; SMEM имеет энергонезависимую часть для хранения приложений, управляющих центральным процессором CPU; SCPU и другими данными, подлежащими сохранению, и энергозависимую часть, подлежащую использованию для временной обработки данных. Данные приложений, которые являются объектом синхронизации, поддерживаются в запоминающем устройстве МЕМ из состава MS (которая в этом примере является базой данных, подлежащей синхронизации для синхронизации) и в памяти баз данных DB.

Устройство клиента MS содержит агент клиента CA, который отвечает за связанные с сеансом функции в устройстве клиента. Сервер S содержит агент сервера SA, управляющий сеансом и средством синхронизации SE. CA предпочтительно реализуется посредством CPU, выполняющего компьютерный программный код, хранимый в запоминающем устройстве МЕМ, а SA, SE реализуются посредством SCPU, выполняющего компьютерный программный код, хранимый в запоминающем устройстве SMEM. Эти средства могут быть также организованы для реализации сеанса управления устройством, или управление сеансом управления устройством может осуществляться отдельными объектами, которые не показаны на фигуре 3b. Посредством компьютерных программных кодов, выполняемых в центральных процессорах CPU и SCPU, устройство клиента MS и сервер синхронизации S также выполнены для реализации средств, соответствующих изобретению, варианты осуществления которых показаны на фигурах 4 и 6. Компьютерные программы могут быть получены через сеть и/или храниться в запоминающем устройстве, таком как дискета, ПЗУ на компакт-диске (CD-ROM) или другое внешнее запоминающее устройство, с которого они могут быть загружены в память МЕМ, SMEM. Также могут использоваться аппаратные решения или сочетание аппаратных и программных решений.

Фигура 4 иллюстрирует способ согласно предпочтительному варианту осуществления изобретения. Информация об идентификаторах, требуемых для запроса, указывающего необходимость в запуске сеанса (для синхронизации пользовательских данных или для управления устройством) установлена 401 в сервере синхронизации. Они включают в себя по меньшей мере идентификатор сервера синхронизации, идентификатор версии протокола синхронизации, поддерживаемой сервером синхронизации, и идентификатор запрашиваемого сеанса синхронизации. Команды кодирования и максимальный размер для сообщений, которые посылаются для указания необходимости запустить сеанс связи, определяются 402 в сервере синхронизации S. Максимальный размер может быть определен согласно используемой службе передачи сообщений, например, согласно максимальному размеру для текстового сообщения в службе SMS. Это определение может быть выполнено таким образом, что числовое значение для максимального размера непосредственно устанавливается для устройства, например, или устройство сконфигурировано для помещения полей в такие места в сообщении, что длина сообщения будет в пределах этого максимального размера. Максимальный размер может также быть определен посредством запрашивания сети об этой информации или он может быть доставлен к устройству в сеансе управления, например. Пользователь может также ввести максимальный размер. Система сообщений устройства по меньшей мере организована для извещения приложения, формирующего сообщение, когда размер сообщения является слишком большим. Команды декодирования определяются 402 в мобильной станции MS, действующей как устройство клиента. Посредством использования команд кодирования S может кодировать по меньшей мере один из идентификаторов, подлежащих передаче, в последовательность битов, требующую существенно меньше битов, чем представление ASCII или двоичное представление WBXML идентификатора. Посредством использования команд кодирования устройство клиента, или его часть, может определить первоначальный идентификатор из последовательности битов.

Когда запрос, указывающий необходимость в запуске сеанса, должен быть передан 403 от сервера по меньшей мере к одному устройству клиента, сервер S определяет 404, согласно командам кодирования, по меньшей мере одну последовательность битов по меньшей мере для части информации, запрашиваемой в сообщении. Сообщение запрашивает по меньшей мере идентификаторы, упомянутые ниже, но обычно оно также включает в себя другую информацию. Информация, подлежащая передаче, формируется 405 в одно сообщение. Сервер S также контролирует 405, чтобы сообщение не превышало заданный максимальный размер. Если оказывается, что сообщение превышает максимальный размер, то сервер S может удалить менее важные поля из него и/или, посредством использования команд кодирования, кодировать больше информации в форму, которая требует меньшего пространства. Сообщение передается 406 от сервера S к устройству клиента MS посредством использования службы передачи сообщений сети MNW. Согласно одному варианту осуществления, служба SMS, известная специалисту в данной области техники, может быть использована для передачи сообщения. В устройстве клиента MS, информация согласно последовательностям битов в принятом сообщении определяется 407 для сообщения инициализации посредством использования команд кодирования, хранимых в устройстве клиента. На основе по меньшей мере одного идентификатора, полученного таким образом, и другой информации, включенной в сообщение, MS формирует 408 сообщение инициализации сеанса и передает 409 его к серверу синхронизации S.

Сеанс связи может быть использован для функций управления устройством, посредством чего работа приложения синхронизации (СА) устройства клиента MS может быть адаптирована по инициативе сети. Например, если адрес сервера синхронизации (идентификатор URI (уникальный идентификатор ресурса) изменился, то важно сделать это известным для каждого устройства, которое синхронизируется с этим сервером. В SyncML этот запрос, передаваемый сервером для запуска сеанса управления устройством, может быть вызван [Пакет №0: предупреждение управления для клиента], так как пакет инициализации, подлежащий передаче, для инициализации на основе запроса таков [Пакет №1: инициализация клиента]. Можно также использовать сеанс связи для персонализации, выполняемой самим пользователем. Пользователь может адаптировать установки через интерфейс WWW, например, и по инициативе сервера синхронизации S эти изменения могут быть перенесены к устройству клиента MS во время сеанса связи.

Фигура 5 иллюстрирует возможные элементы сообщения, сформированного (405) для того, чтобы запустить сеанс управления устройством. Согласно предпочтительному варианту осуществления, служба проталкивания протокола WSP применяется посредством использования сообщений SMS, посредством чего сообщение содержит поле заголовка WSP. Поле заголовка WSP должно быть достаточно коротким (предпочтительно менее чем 30 битов), так что есть достаточно места для полезной нагрузки, предназначенной для действительного прикладного уровня (СА), обрабатывающего сообщение. Следует отметить, что в дополнение к полю WSP, сообщение может также содержать другие поля заголовков, такие как поля заголовков WSP. В этом случае, однако, пропорция полезной нагрузки SyncML уменьшается. Согласно одному варианту осуществления, сообщение может также обеспечивать указание приложения, к которому должно быть адресовано содержимое сообщения. На основе такого указания MS может направить полезную нагрузку сообщения к правильному объекту приложения, например, запрос для запуска сеанса управления к агенту клиента СА. Это указание может быть включено в поле заголовка WSP или WDP (беспроводного протокола дейтаграмм) сообщения. Устройство, поддерживающее протокол WAP, легко узнает эту информацию из сообщения, но не-WAP устройству должно быть предоставлено заранее заданное положение, из которого должно извлекаться указание приложения. Это положение может быть определено посредством использования заранее заданного положения от начала сообщения (сдвиг) или таким образом, что указание всегда имеет место после заранее определенного символа в поле заголовка. Например, в поле заголовка WSP указание может быть в идентификаторе «Идентификатор приложения» (х-wap-application-id), поле MIME (многоцелевых расширений электронной почты в сети Интернет) может также быть использовано вместо поля «Идентификатор приложения» или определять информацию поля «Идентификатор приложения».

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

Версия (VER). Содержит версию сообщения, подлежащую использованию, и таким образом, также версию протокола, так что устройство клиента может проверить, поддерживает ли сервер S ту же самую версию. Идентификатор версии может альтернативно указывать только версию сообщения или версию протокола. Устройству клиента не нужно запускать (408, 409) сеанс связи, если оно поддерживает другую версию. Идентификатор версии может быть кодирован согласно командам кодирования, установленным в сервере S, в более короткую последовательность битов, например, таким образом, что используются первые 10 битов после поля заголовка WSP: последнее число относится к меньшим номерам версии, второе от последнего относится к единицам, третье от последнего относится к десяткам и четвертое от последнего относится к сотням, и в этом случае наибольшей возможной версией является «102.3», и версия «1.0» кодируется в последовательность битов «0000001010». Как утверждалось ранее, MS содержит команды декодирования для определения (407) первоначального идентификатора из последовательности битов.

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

0000001010	Версия 1,0
0000001011	Версия 1,1
...	...
1111111111	Версия 102,3

Идентификатор сеанса (SID). Это поле определяет идентификатор сеанса, так что один и тот же сеанс не выполняется больше, чем один раз. Для этого идентификатора может быть использовано, например, 16 битов после идентификатора версии. Например, если устройство клиента выключено, то сервер S может послать несколько сообщений, посредством которых сервер пытается установить один конкретный сеанс управления. На основе идентификатора SID, устройство клиента может заключить, что следует запустить только одно соединение и не устанавливать соединения согласно каждому полученному сообщению. Сервер S может также назначить приоритеты сеансам управления устройством посредством поля SID, например, посредством определения специфического идентификатора SID для менее важных операций управления устройством. Когда устройство клиента устанавливает соединение для установления сеанса, сервер S может предотвратить установление сеанса, если у него есть более срочные устройства клиентов для обслуживания. Это может быть организовано таким образом, что сервер S хранит в своей памяти информацию о том, что сеанс, соответствующий переданному идентификатору SID, является менее важным. Это может быть организовано альтернативно таким образом, что идентификаторы SID, выбираемые из специфической группы, например, являются менее важными, что позволяет избежать хранения информации.

Режим взаимодействия с пользователем (UI). Посредством этого идентификатора сервер может рекомендовать, должен ли сеанс быть проведен в фоновом режиме или должен ли пользователь быть информирован о сеансе. Это поле может быть кодировано двумя битами согласно следующей таблице соответствия, например:

00	у сервера нет рекомендации
01	рекомендуется работа в фоновом режиме (не показана для пользователя)
10	показать информирующий идентификатор пользователю
11	спросить разрешения у пользователя

Инициатива действия управления (Init). Посредством этого идентификатора сервер S может осуществлять связь с устройством клиента независимо от того, вызвал ли он сам сеанс управления или вызвало ли его устройство клиента (его пользователь). Эта информация может формировать основу для составления счета за услуги связи, и таким образом пользователю устройства клиента может быть также выписан счет за запрос, переданный сервером, если пользователь вызвал, то есть заказал его. Эта информация может быть кодирована двумя битами согласно следующей таблице соответствия, например:

01	инициатива клиента
10	инициатива сервера

Будущее использование управления устройством (Fut). В этом поле возможная информация, которая будет определена позже, может быть перенесена от сервера S к устройству клиента MS для сеанса управления. Например, может быть зарезервирован объем в 30 битов. Одним возможным примером информации, подлежащей переносу в это поле, является момент, в который устройство клиента должно установить сеанс связи с сервером синхронизации S. MS может передать сообщение инициализации (409) во время, установленное сервером, и сервер S может, например, сбалансировать свою нагрузку путем установки различных устройств клиентов на установление соединения в различные моменты времени.

Длина совместно используемого секрета (числового значения, известного только действительным участникам криптографической системы) запуска аутентификации (Tlen). Это поле указывает длину поля TASS (совместно используемого секрета запуска аутентификации).

Длина источника (Ulen). Это поле указывает длину идентификатора (URI) сервера S. Посредством использования этого поля и поля Tlen, для поля URI может быть организовано наибольшее возможное пространство. Если бы использовались только поля конкретных длин, то в конце поля TASS часто имелось бы неиспользуемое пространство.

Совместно используемый секрет запуска аутентификации (TASS). Поле TASS содержит совместно используемый секрет, посредством которого препятствуют атакам DoS (отказ в обслуживании). Это поле может также использоваться для определения идентификатора сервера.

URI источника сервера управления (URI источника). Поле содержит идентификатор URI сервера, например, 'http://www.syncml.org/mgmt-server'. В определенных случаях, это поле может также быть укорочено посредством исключения идентификатора протокола, например, или передачи вместо адреса сервера только более короткого идентификатора в этом поле. Альтернативно, поле TASS может использоваться для передачи идентификатора сервера.

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

В вышеупомянутых полях полезная нагрузка планируется таким образом, что необходимо пространство настолько малое, насколько это возможно. Если все поля переданы как текст в формате XML, около 400 символов, то есть тысячи битов, были бы необходимы. Одно поле вмещает по меньшей мере несколько символов, то есть множество битов. Когда по меньшей мере некоторые из полей используют вышеупомянутые способы кодирования, каждый из которых получен на основе знания, касающегося различных значений, которые каждое поле может принять, можно значительно сэкономить место и приспособить (путем дополнительного удаления менее важных полей, если это необходимо) информацию для одного сообщения SMS. Приложение 1, которое является частью этого описания, показывает другой пример полей сообщения, насколько это касается только полезной нагрузки SyncML.

Фигура 6 показывает схему сигнализации сеанса управления устройством, который запускается по запросу сервера синхронизации (S). Когда сервер и устройство клиента (MS) могут осуществлять связь 601 (по меньшей мере так, что MS способна принимать сообщения, также были выполнены этапы 401-402 по фигуре 4), сервер принимает 602 команду запустить сеанс управления от пользователя сервера, извне по отношению к серверу или на основе заранее заданной установки. В ответ сервер собирает необходимые данные, проводит изменения согласно командам кодирования и передает 603 сообщение согласно запросу [пакет №0: предупреждение управления для клиента] к устройству клиента. На основании этого, устройство клиента и сервер могут установить сеанс 604 управления. Сервер S может передавать команды управления к устройству клиента, и устройство клиента изменяет свою конфигурацию на основе этих команд управления. После завершения 605 сеанса управления результат может быть представлен 606 для пользователя сервера.

Сеанс связи может использоваться для синхронизации стандартных данных пользователя, например, для обновления отметок календаря мобильной станции и приложения календаря сети. В этом случае, инициатива запустить синхронизацию (403) может иметь место, например, когда новая важная отметка календаря, которая нуждается в доставке в мобильную станцию настолько скоро, насколько это возможно, добавляется к сетевому календарю. Подобно сообщению, сформированному для сеанса управления устройством и иллюстрированному на фигуре 4, сообщение, которое формируется для того, чтобы запросить сеанс SyncML, содержит несколько соответствующих полей. По меньшей мере поля, отмеченные звездочкой, Версия (VER*), Идентификатор сеанса (SID*), Источник и URI сервера управления (URI*) также необходимы в сообщении, подлежащем формированию для запроса для запуска синхронизации. Информация по меньшей мере полей (UI), (VER*) и (Init) может быть преобразована в короткую последовательность битов способом, описанным выше. Это сообщение может также включать в себя информацию о сеансе синхронизации, который запрашивает сервер. Такая информация включает в себя, в частности, указание типа синхронизации, требуемого сервером S (например, двусторонняя, односторонняя синхронизация только от сервера, односторонняя синхронизация только от клиента, обновляемая синхронизация только от сервера). Эта информация может быть также кодирована (404) и декодирована (407) путем использования предварительно сохраняемой (402) таблицы соответствия, посредством чего количество требуемых битов может быть сэкономлено. Также может быть полезной передача идентификатора (URI) базы данных (в синхронизации которой нуждается сервер) в сообщении. После того, как устройство клиента MS, поддерживающее SyncML, принимает сообщение, оно может передать (409) пакет инициализации сеанса синхронизации (пакет инициализации синхронизации от клиента) согласно информации, включенной в сообщение, и сеанс синхронизации может быть инициализирован. Для более конкретного описания сеанса синхронизации протокола SyncML и информации, требуемой для этого, спецификация «SyncML Sync Protocol, version 1.0.1», май 2001 г., включена в заявку в качестве ссылки. Таким образом, такие же преимущества могут быть достигнуты, когда как сеанс управления, так и сеанс синхронизации данных пользователя запускаются по запросу сервера синхронизации.

Также возможно, что упомянутое сообщение сформировано 405 где-либо еще, а не в сервере S, который передает запрос. Ситуация, подобная этой, может иметь место, например, когда устройство клиента устанавливает связь со шлюзом WAP посредством стека протоколов WAP, и протокол HTTP используется между шлюзом WAP и сервером S. Шлюз WAP, например, может затем уплотнить запрос, переданный сервером, способом, описанным выше (путем использования команд кодирования) таким образом, что он может быть передан в одном сообщении к устройству клиента MS.

Для специалиста в данной области техники очевидно, что с развитием технологии, основной замысел изобретения может быть реализован множеством способов. Также нужно отметить, что сообщения не ограничиваются сообщениями службы SMS, но также могут быть использованы другие типы служб передачи сообщений, такие как служба MMS (служба мультимедийных сообщений). Изобретение и варианты его осуществления, таким образом, не ограничены примерами, описанными выше, но могут быть модифицированы в рамках объема, определяемого формулой изобретения.

Приложение 1. Пример информации, включенной в сообщение

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