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

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

Иллюстрации

Показать все

Реферат

Область, к которой относится изобретение

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

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

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

Для синхронизации таких хранилищ данных разрабатываются средства на основании того, что называется SyncML (synchronization markup language) (язык разметки синхронизации), разрабатываемый по так называемой Инициативе SyncML (информацию о SyncML, в том числе стандарты и описания для SyncML, и об Инициативе SyncML, специально включающей в себя Протокол представления SyncML и Протокол синхронизации SyncML, см. http:// www.syncml.org/). SyncML представляет собой открытый промышленный стандарт для общего языка для универсальной синхронизации удаленных данных (т.е. групп данных, хранящихся в различном оборудовании и, следовательно, в различных хранилищах данных) и личной информации по множеству сетей, платформ и устройств. С помощью SyncML группы данных - но все же не структура данных - могут быть синхронизированы на различных устройствах, соединенных через одну или более взаимосвязанных сетей, включающих, к примеру, универсальную систему мобильной связи (УСМС) (UMTS), сеть радиодоступа (СРД) (UTRAN) и Интернет, где связь может быть беспроводной в целом или частично, либо проводной. Таким образом, устройства могут осуществлять связь через, например, фиксированные сети (в том числе беспроводные сети), инфракрасные, кабельные или Bluetooth.

Помимо использования для синхронизации хранилищ данных, SyncML (т.е. язык) можно использовать для управления устройствами и более точно, для переноса управляющих действий между клиентом и управляющим сервером для клиента. Описание Протокола управления устройствами SyncML см. http://ww.syncml.org. Протокол управления устройствами SyncML позволяет управляющим командам выполняться в управляемых объектах, и он использует формат пакетов, аналогичный Протоколу синхронизации SyncML и Протоколу представления SyncML. Управляемый объект может отражать набор параметров конфигурации для устройства. Действия, которые можно предпринимать по отношению к этому объекту, могут включать в себя считывание и установку ключей и значений параметров. Другим управляемым объектом может быть среда выполнения реального времени для программных приложений в устройстве. Действия, которые можно предпринимать в отношении этого типа объекта, включают в себя инсталляцию, обновление или деинсталляцию программных элементов. Действия представляются командами Протокола управления устройствами SyncML, которые описываются в Протоколе представления SyncML, Пользование управлением устройствами. Используемые команды и структура сообщений идентичны тем, что содержатся в Протоколе синхронизации SyncML. (Таким образом, так называемое определение типа документа для Протокола управления представляет собой определение типа документа из Протокола синхронизации SyncML).

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

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

SyncML использует синтаксис так называемого расширяемого языка разметки (XML), как установлено в документе Extensible Markup Language (XML) 1.0, продукт учреждения XML в консорциуме World Wide Web Consortium (W3C), имеющего вебсайт по адресу http://www.w3.org. За информацией о XML следует обращаться по адресу http://www.w3.org/XML.

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

Выражение структура директории или структура данных и выражение папка следует понимать широко. Во-первых, папку следует понимать как любое вместилище блоков данных. Таким образом, к примеру, то, что называется папка в разных операционных системах (таких как Windows, доступная от Microsoft Corporation), нужно понимать под термином папка, как он используется в настоящем описании, но это и запись в таблице реляционной базы данных, поскольку запись в такой таблице включает в себя поля, которые являются блоками данных. Каждое такое поле можно рассматривать как папку, поскольку поле содержит знаки, числа или иные элементы, которые можно рассматривать как блоки данных, а тем самым каждое поле является папкой.

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

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

Сообщение SyncML представляет собой вложенную структуру, и одно или более сообщений SyncML могут связываться с тем, что называется пакет SyncML. Сообщение SyncML является отдельным документом XML, состоящим из одного или более типов элементов. Этот документ состоит из заголовка, определяемого типом элемента ЗаголСинхр (SyncHdr), и тела, определяемого типом элемента ТелоСинхр (SyncBody). Заголовок SyncML конкретизирует информацию маршрутизации и контроля версий о сообщении SyncML. Тело SyncML представляет собой вместилище для одной или более команд SyncML. Команды SyncML конкретизируются отдельными типами элементов. Команды SyncML действуют как вместилища для других типов элементов, которые описывают подробности команды SyncML, в том числе любые данные или мета-информацию.

SyncML определяет команды запроса и команды ответа. Команды запроса включают в себя, например, команды: добавить (команда, которая позволяет отправителю просить, чтобы один или более блоков данных были добавлены к данным, доступным для получателя); уведомить (позволяющая отправителю известить получателя о состоянии); копировать (позволяющая отправителю просить, чтобы копировались один или более блоков данных, доступных для получателя); удалить (позволяющая отправителю просить, чтобы были удалены или архивированы один или более блоков данных, доступных для получателя); получить (позволяющая отправителю просить один или более блоков данных от получателя) и искать (позволяющая отправителю просить, чтобы выполнялся введенный запрос относительно одного или более блоков данных, доступных для получателя). Единственными командами ответа в настоящее время являются: статус (указывающая статус завершения операции или тот факт, что произошла ошибка при обработке предыдущего запроса) и результат (используемая для возвращения результатов данных на команду SyncML либо Получить, либо Искать).

SyncML использует идентификаторы, чтобы идентифицировать блоки данных или папки. Идентификаторы включаются в то, что называется типами Исходных и Целевых элементов, и могут быть комбинациями, унифицированными идентификаторами ресурсов (УИР) (URIs), унифицированными названиями ресурсов (УНР) (URNs) и текстовыми названиями. (Чтобы указать международный идентификатор мобильного оборудования (МИМО) (IMEI), SyncML использует тип УНР МИМО. Это УНР МИМО определяет достоверный 15-разрядный МИМО. Вдобавок, SyncML использует тип УНР SyncML, чтобы идентифицировать в SyncML конкретные пространства названий и уникальные названия. Иные типы УНР также могут использоваться в типе элемента МестнУИР (LocUPI)).

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

Элементы общего пользования представляют собой типы элементов, используемые другими типами элементов SyncML, и включают в себя, например, «архивировать» для указания того, что данные, конкретизированные в команде «удалить», должны архивироваться получателем команды «удалить», а не просто удаляться. Тем самым команда «удалить» может использовать элемент общего пользования «архивировать», а потому называется родительским элементом для типа элемента общего пользования «архивировать» в этом контексте. Другим типом команды общего пользования является тип элемента Кмд (Cmd), который используется для конкретизации команды SyncML, на которую ссылается тип элемента Статус (а потому тип элемента Статус является родительским элементом в этом контексте). Другим является тип элемента ИДКмд (CmdID), который используется для конкретизации идентификатора уникальной для сообщения команды SyncML и может иметь разные родительские элементы, в том числе: Добавить, Уведомить, Элементарный, Копировать, Удалить, Исполнять, Получить, Отображать, Поместить, Заменить, Результаты, Искать, Последовательность, Статус и Синхронизировать.

В отношении изобретения особо отметим типы общих элементов МестнНазвание, МестнУИР, Исходный и Целевой. МестнНазвание используется для конкретизации названия дисплея для целевого или исходного адреса, а потому может иметь в качестве родительских элементов Целевой или Исходный. МестнУИР конкретизирует целевой или исходный конкретный адрес и также может иметь в качестве родительских элементов Целевой или Исходный. Тип общего элемента Исходный используется для конкретизации исходной информации маршрутизации или отображения; его родительские элементы включают в себя: Элемент, Отображение, ЭлемОтображения, Искать, Синхронизировать и ЗаголСинхр. Целевой используется для конкретизации целевой информации маршрутизации или отображения, и его родительские элементы включают в себя: Элемент, Отображение, ЭлемОтображения, Искать, Синхронизировать и ЗаголСинхр.

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

Элементы описания данных используются в качестве элементов вместилища для данных, обмениваемых в сообщении SyncML; элементы описания данных включают в себя следующие типы элементов: Данные, для конкретизации дискретных данных SyncML, используемый (родительскими элементами) типами элементов Уведомить, Полномоч., Элемент, Статус и Искать; Элемент, для конкретизации вместилища для групп данных, используемый (родительскими элементами) типами элементов Добавить, Уведомить, Копировать, Исполнять, Получать, Поместить, Заменить, Результаты и Статус; и Мета, для конкретизации мета-информации о типе родительских элементов, используемый (родительскими элементами) типами элементов Добавить, Элементарный, Запросить, Копировать, Полномоч., Удалить, Получить, Элемент, Отображать, Поместить, Заменить, Результаты, Искать, Последовательность и Синхронизировать.

Элементы руководства протоколом включают в себя в настоящее время только тип элемента Статус, для конкретизации кода статуса требования на указанную команду SyncML, используемый (родительским элементом) ТелоСинхр.

Наконец, имеются элементы команд протокола. Они включают в себя уже упомянутые элементы команд, т.е., к примеру, Добавить, для конкретизации того, что данные подлежат добавлению к набору данных, используемый (родительскими элементами) Элементарный, Последовательность, Синхронизировать, ТелоСинхр, Удалить, Заменить и т.д.

Все об этих типах элементов установлено в стандарте, протоколе представления SyncML, доступном в Интернете по адресу:

http://www.syncml.org/docs/syncml_represent_v11_20020215.pdf.

Сообщение об изменениях в структуре директории не является проблематичным, если одно и то же приложение заботится о манипулировании данными и о манипулировании связью согласно протоколу синхронизации. Но в случае более общей задачи, в котором на каждом устройстве несколько приложений совместно используют хранилище данных, организованный как структура директории, сохраняя свои соответствующие блоки данных в одной или более папок в этой структуре директории, неясно, как лучше построить протокол синхронизации для этого. Согласно открытому стандарту - протоколу синхронизации SyncML, продукту Инициативы SyncML, - каждое из двух удаленных устройств, имеющих соответствующие хранилища данных, подлежащие синхронизации (в любом отношении), включает в себя агент синхронизации (sync) (один на устройство, а потому обслуживающий, возможно, много различных приложений) и один или более прикладных объектов, а нижеследующий протокол синхронизации (т.е. обеспечение связи согласно этому протоколу синхронизации, установленному в стандарте) несет ответственность не за эти приложения, а за агентов синхронизации. (Только агент синхронизации, а не приложения, понимает SyncML.) Но только приложения знают, заменен ли блок данных после самой свежей уже выполненной синхронизации. Имеется несколько опций, относящихся к расширению протокола синхронизации SyncML, которые требуют включить в каждое из приложений знание SyncML наподобие того, что кодируется в агенте синхронизации, и некоторые опции, которые требуют, чтобы агент синхронизации был способен интерпретировать блоки данных таким образом, как это делают различные приложения.

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1 является блок-схемой/схемой сигналов клиента (такого как мобильный телефон) и сервера (такого как сетевой сервер или ПК), обменивающихся сообщениями SyncML для синхронизации их соответствующих хранилищ данных согласно изобретению;

Фиг. 2 представляет собой схему сообщения SyncML согласно изобретению;

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

Фиг.4 представляет собой схему структуры директории (согласно прототипу).

Наилучший режим осуществления изобретения

На фиг.1 клиент 11 показан синхронизирующим клиентское хранилище 11с данных с серверным хранилищем 12с данных в сервере 12. (Эти хранилища данных могут использоваться либо в руководстве устройствами, либо для хранения пользовательских данных, таких, к примеру, как электронная почта). Хранилище данных в общем случае может включать в себя одну (или даже больше) структуру системной директории и возможно также одну или более структур внутренней директории (т.е. структура внутренней директории является структурой, поддерживаемой одним или более приложениями в противоположность операционной системе) с любой структурой директории, способной быть представленной, как проиллюстрировано на фиг.4, чтобы структура директории представляла собой древовидную структуру папок, а каждая папка способна включать в себя один или более блоков данных (таких как файлы, т.е. блоки данных, поддерживаемые в структуре системной директории, или блоки либо данные, поддерживаемые приложениями во внутренней директории, такими как электронная почта, поддерживаемая приложением электронной почты) и одну или более других папок древовидной структуры. Синхронизация происходит через обмен сообщениями SyncML, хотя могут также использоваться сообщения согласно любому, подобным же образом структурированному или аналогичному языку. Некоторые из обмениваемых сообщений SyncML включают в себя команды для синхронизации хранилищ 11с 12с данных в отношении блоков данных, а некоторые - для синхронизации хранилищ данных в отношении организации данных, т.е. чтобы оба хранилища данных имели эквивалентную структуру в терминах папок, по меньшей мере постольку, поскольку приложения касаются того, в чью пользу выполняется синхронизация. Клиент 11 представляет собой любое устройство, которое играет роль клиента в модели клиент-сервер, и согласно протоколу SyncML клиент (обычно носимый компьютер, или портативный телефон, или иной беспроводный терминал) посылает все изменения в своем хранилище 11с данных на сервер 12с - устройству (обычно, к примеру, настольный компьютер), играющему роль сервера в модели клиент-сервер. (Обычно предполагается, что из двух устройств, синхронизирующих свои соответствующие хранилища данных, устройство с наибольшей вычислительной способностью будет играть роль сервера).

Клиент 11 и сервер 12 включают в себя один или более соответствующих прикладных объектов 11а 12а, и они также включают в себя (родительские, т.е. не конкретизированные для конкретного приложения) соответствующие агенты 11b 12b синхронизации. Прикладной объект 12а сервера отличается от прикладного объекта 11а клиента в том, что он не только взаимодействует с серверным агентом синхронизации, но также взаимодействует с серверным процессором 12f синхронизации, который не имеет аналога в клиенте 11. Аналогично, серверный агент 12с синхронизации отличается от клиентского агента 11с синхронизации в том, что он также взаимодействует с серверным процессором 12f синхронизации. Прикладной объект 11а-12а клиента-сервера представляет собой, к примеру, приложение календаря, используемое для отслеживания встреч для торговца. Если встреча назначена на клиентском устройстве 11, то информация о встрече сохраняется в клиентском хранилище 11с данных в качестве нового файла. Позже, либо по запросу клиента 11, либо по подсказке сервера 12, хранилище 12с данных синхронизируется с клиентским хранилищем 11с данных в отношении новых данных (т.е. нового файла). Кроме этого, если изменение сделано в структуре директории в клиентском хранилище 11с данных, то опять клиентское хранилище 11с данных и серверное хранилище 12с данных должны синхронизироваться в этом случае в отношении структуры директории, т.е. по отношению к тому, что для хранения блоков данных для приложения используются папки. Также любое изменение, сделанное в серверном хранилище 12с данных, в том числе изменения либо в папках, либо в блоках данных для приложений 11а 12а, потребуют синхронизации клиентского хранилища 11с данных и серверного хранилища 12с данных путем обмена сообщениями SyncML.

Также на фиг. 1 сообщения SyncML могут передаваться согласно разным транспортным соединениям 14, в том числе, например, гипертекстовый транспортный протокол (НТТР), беспроводной сеансовый протокол (WSP) и протокол обмена объектами (ОВЕХ). (Транспортные соединения могут обеспечиваться с помощью любого вида соединения физического уровня, в том числе либо беспроводное соединение, либо проводное соединение). Как показано, когда сервер 12 передает сообщение SyncML клиенту 11 (и наоборот), серверный агент 12b использует интерфейс 12d синхронизации, чтобы предоставить сообщение на серверный адаптер 12е синхронизации, который, в свою очередь, предоставляет это сообщение SyncML клиенту 11 по транспортному соединению 14. На принимающем конце клиентский адаптер 11е синхронизации принимает сообщение SyncML и пропускает его на клиентский интерфейс 11d синхронизации, который, в свою очередь, предоставляет его клиентскому агенту 11b синхронизации.

Теперь, чтобы обеспечить синхронизацию хранилищ 11с 12с данных по отношению к изменениям в папках, равно как и в блоках данных (чтобы одни и те же блоки данных находились в одних и тех же или эквивалентных папках каждого устройства и содержимое каждого соответствующего блока данных было тем же самым), изобретение имеет SyncML, использующий те же самые команды для изменения папок, которые используются для изменения блоков данных; тем самым, изменения в папки делаются путем отправки сообщений, передающих операционные элементы (командные элементы протокола), такие как Синхронизировать, Добавить, Заменить и Удалить, в которых на затронутые папки делаются ссылки внутри того, что называется Элементы идентификации данных, означающие либо Целевые, либо Исходные элементы, внешние к Элементам данных. Чтобы внести изменение в блок данных, SyncML согласно прототипу вызывает сообщение, ссылаясь на блок данных внутри Элемента данных, вложенного в операционный элемент. Как раз использование ссылки на затронутые папки, внешней к Элементу данных (т.е. элемент описания данных), и дает изобретению преимущество над остальными возможными компоновками для ссылки на затронутые папки (а именно, отсутствие необходимости дублировать код, позволяющий SyncML делать синтаксический разбор каждого приложения, и отсутствие необходимости включать в каждый агент синхронизации код для интерпретации блоков данных каждого отличающегося приложения).

На фиг. 2, таким образом, согласно изобретению, папки (а тем самым и организация данных в терминах директорий), затронутые в ходе синхронизации хранилищ 11с 12с данных, идентифицируются или индицируются в элементах 26а 27а МестнУИР Исходного элемента 26 и Целевого элемента 27 в командном элементе 25 протокола (таком как Заменить), внешним для элемента 28 29 данных, т.е. не содержащимся в этом элементе данных (т.е. особый тип элемента описания данных). Как Целевой, так и Исходный элементы называются здесь Элементами идентификации данных, чтобы противопоставить их элементам данных 28 29, которые содержатся в блоках данных. Элементы идентификации данных согласно изобретению обычно внедрены во вместилище элементов не-данных (такое как элемент группы), которое, в свою очередь, внедрено в командный элемент 24 протокола. Командный элемент 24 протокола передается как часть элемента 23 вместилища ТелоСинхр вместе с элементом 22 вместилища ЗаголСинхр, которые оба включены в элемент вместилища SyncML, т.е. сообщение 21 SyncML.

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