Управление данными в базе данных каталога

Управление данными в базе данных каталога

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение относится к телекоммуникации, в частности к способам управления данными в базе данных каталога, более конкретно, к Механизму Взаимного Исключения LDAP, принудительно обеспечиваемому на стороне Сервера Каталогов. Оно дополнительно относится к базе данных каталога, компьютерной программе, компьютерному программному продукту, клиенту и системе связи.

УРОВЕНЬ ТЕХНИКИ

В настоящее время стандартизируется Конвергенция Данных Пользователя (UDC, по терминологии 3GPP) Проекта Партнерства 3-го Поколения для предстоящей 3GPP Версии 9. Предлагается проиллюстрированная на Фиг. 1 новая архитектура Базовой Сети (CN) 100, где разделяются данные, связанные с абонентской услугой, и бизнес логика разных сетевых элементов. Таким образом, Хранилище 102 Данных Пользователя (UDR, по терминологии 3GPP) используется в качестве централизованной базы данных так, что разные интерфейсные части 106-110 приложений могут получать доступ к данным пользователя (через новую опорную точку 112 «Ud»). При этом требуется минимизировать влияние на существующую сеть при внедрении UDC.

Функциональные объекты, такие как Регистр Домашних Местоположений (HLR)/Сервер Домашних Абонентов (HSS), Центр Аутентификации (AuC), Серверы Приложений, система Инициализации и т.д., при применении архитектуры UDC, сохраняют логику приложений, но они не хранят локально данные пользователя постоянно. Эти лишенные данных функциональные объекты вместе называются в архитектуре UDC интерфейсными частями 106-110 (FE) приложений.

Упрощенный Протокол Доступа к Каталогам (LDAP, стандарт Комитета по Инженерным Вопросам Интернет (IETF)) в настоящее время был согласован (проходит этап-3 деятельности) в качестве протокола доступа к данным, который будет использоваться в интерфейсе Ud для операций CRUD (Создания, Чтения, Обновления, Удаления).

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

Например, один абонент мобильной сети 3G перемещается в Домашней сети (так что внутри Базовой Сети задается процедура «Обновления Местоположения» для обновления местоположения абонента) и в то же время, тот же абонент задействует «абонентскую процедуру» по смене номера переадресации в отношении (ранее активированной) Дополнительной Услуги «Переадресации Вызова При Отсутствии Ответа».

В предыдущем примере два разных экземпляра HLR-FE (один, управляющий выданной процедурой «Обновления Местоположения Прикладной Подсистемы Мобильной Связи (MAP, пакет SS7)» и один, управляющий задействованной абонентской процедурой) пытаются получить доступ и изменить один и тот же элемент данных в UDR в один и тот же/близкий момент времени.

Существует множество других случаев сетевого использования, при которых могут произойти подобные ситуации. В соответствии с первым примером, объект FE Инициализации может пытаться обновить профиль абонента (в результате предписания инициализации, принятого от Системы Управления Абонентами (CAS)), когда в то же время FE приложения пытается обновить тот же элемент данных (или некую общую часть). В соответствии со вторым примером, два разных экземпляра FE двух разных приложений могут пытаться изменить некие общие (для обоих приложений) данные применительно к одному и тому же профилю абонента.

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

Во всех такого рода ситуациях могут возникнуть проблемы обеспечения «непротиворечивости данных», если в UDR не гарантировано использование некоего механизма взаимного исключения, что лучше показано на схеме последовательности операций на Фиг. 2 (которая приведена в качестве графического примера):

В частности, такая проблематичная ситуация может возникнуть в результате того, что два клиента, такие как HLR-FE 206 и FE 208 Инициализации, оба запрашивают изменение записи данных в базе данных каталога, такой как UDR 202. Этапы примерной схемы последовательности операций на Фиг. 2 происходят в следующем порядке:

На первом этапе 216, HLR-FE 206 принимает Обновление Местоположения MAP, в частности, от абонента. На дальнейшем этапе 218, HLR-FE 206 запрашивает считывание профиля абонента, ассоциированного с абонентом, и HLR-FE 206, отправляет UDR 202 соответствующий Запрос на Поиск LDAP. Соответственно, UDR 202 отправляет соответствующие данные профиля запрашивающему HLR-FE 206. Вслед за этим, на последующем этапе 220, HLR-FE 206 выполняет логику, ассоциированную с приложением, и, в частности, может обработать принятые данные профиля абонента.

На следующем этапе 222, FE 208 Инициализации принимает предписание Инициализации в частности от CAS. На следующем этапе 224, FE 208 Инициализации запрашивает считывание профиля абонента, ассоциированного с абонентом, и отправляет UDR 202 соответствующий запрос на Поиск LDAP. Соответственно, UDR 202 отправляет соответствующие данные профиля запрашивающему FE 206 Инициализации. Вслед за тем, на этапе 226, FE 206 Инициализации выполняет логику, ассоциированную с приложением, и, в частности, может обработать принятые данные профиля абонента.

На этапе 228, FE 208 Инициализации запрашивает обновление профиля абонента, хранящегося в UDR 202, посредством отправки соответствующего Запроса на Изменение LDAP. Соответственно, UDR 202 обновляет профиль абонента, и отправляет информацию о выполнении обновления, в частности обновленный профиль абонента, к FE 208 Инициализации.

На этапе 230, HLR-FE 206 также запрашивает обновление профиля абонента, хранящегося в UDR 202, посредством отправки соответствующего Запроса на Изменение LDAP. Соответственно, UDR 202 также обновляет профиль абонента и отправляет информацию о выполнении обновления, в частности обновленный профиль абонента, к FE 208 Инициализации.

Таким образом, на этапе 228 на Фиг. 2 профиль абонента обновлен (при помощи FE 208 Инициализации), так что профиль, которым управляет экземпляр 206 HLR-FE (считанный на этапе 216), является с этого момента «старым». Заключительная операция обновления, выполняемая HLR-FE 206 на этапе 230, не принимает в расчет изменения, внесенные на этапе 228, так что существует риск нарушения непротиворечивости данных (например, некие значения атрибутов, внесенные на этапе 228, могут быть переписаны на этапе 230; в качестве альтернативы или в дополнение, на этапах 228 и 230 могут обновляться разные данные, но, тем не менее, ассоциированные между собой, так что может быть «разрушена» непротиворечивость данных на уровне приложений).

Чтобы предотвратить такие ситуации применительно к LDAP, на сегодняшний день были предложены некоторые решения, которые, однако, страдают общим недостатком, так как все они требуют определенного поведения от клиентов LDAP, чтобы помочь Серверу Каталогов LDAP (т.е. UDR) обнаружить конфликт обновлений (чтобы алгоритм взаимного исключения, ассоциированный с каждым из этих решений, мог быть инициирован). Во всех этих решениях сервер LDAP (т.е. тот, что должен гарантировать свойства непротиворечивости данных для данных, которые он хранит) не является объектом, принимающим решение о том, когда должен быть инициирован механизм взаимного исключения; в конечном счете, объектом, принимающим данное решение, является FE приложения (так же предоставляющий требуемые данные для исполнения соответствующего алгоритма взаимного исключения). Недостаток может заключаться в том, что эти решения могут действовать только в отгороженных (walled-garden) средах, т.е., в тех, в которых как сервер каталогов LDAP, так и клиент LDAP принадлежат к одному и тому же домену оператора, из-за строго управления поведением клиента LDAP, которое требуется со стороны «владельца решения». Дополнительный недостаток может заключаться в том, что эти решения являются решениями, подверженными ошибкам, поскольку они зависят от правильного поведения каждого отдельного клиента LDAP. Впрочем, еще один недостаток может заключаться в том, что внедрение FE приложений в развернутую многоуровневую архитектуру может быть затруднительным, дорогим и трудоемким, так как клиенты LDAP, включенные в эти FE, должны быть выполнены с возможностью следовать требуемому правильному поведению. Кроме того, эти решения могут сопровождаться нерешенными вопросами функциональной совместимости поставщиков и дополнительными препятствиями, при попытке объединения развернутого UDR с FE 3PP приложений.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

Варианты осуществления изобретения будут описаны далее более подробно со ссылкой на примеры, которыми, однако, объем изобретения не ограничивается.

Фиг. 1 является структурной схемой, иллюстрирующей архитектуру связи, используемую в Конвергенции Данных Пользователя 3GPP.

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

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

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

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

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

Фиг. 7 иллюстрирует структурную схему, иллюстрирующую устройство базы данных каталога в соответствии с примерным вариантом осуществления изобретения.

Фиг. 8 иллюстрирует структурную схему, иллюстрирующую устройство клиента, в соответствии с примерным вариантом осуществления изобретения.

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

Иллюстрации на чертежах схематические. На разных чертежах, аналогичные или идентичные элементы обозначены одинаковыми ссылочными обозначениями.

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

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

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

Примеры и объяснения для лучшей иллюстрации описываются следующим:

- Примерами базы данных каталога могут быть сервер UDR или LDAP.

- Под «базой данных каталога» может пониматься особая технология хранилища, которая организует управляемые объекты данных (включая свои собственные - ассоциированные - экземпляры атрибутов) в логическом и иерархическом виде. 3GPP UDC Rel.9 определяет функциональный элемент UDR как «Базу Данных Каталога» общую для всех экземпляров интерфейсной части (FE) приложения.

- Примером записи данных может быть профиль абонента.

- Отметим, что запись данных может быть обозначена как запись каталога в некоторой примерной базе данных каталога.

- Отметим, что единственный профиль абонента может быть определен и управляться (в DB Каталога) как единственная «запись каталога» или как набор записей каталога (поскольку DB Каталога не накладывает каких-либо семантических ограничений на то, чем является «запись каталога»).

- Примером информации, представляющей текущий статус хранения для записи данных (например, для конкретной «записи каталога») в базе данных каталога, является значение entryDigest (краткого описания записи)

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

- Примером запроса на изменение может быть запрос на Изменение LDAP.

- Примером совпадения может быть то, если определяется, что первая и вторая информация о текущем статусе идентичны, что является типичным случаем, однако, для определения совпадения могут применяться прочие условия. Например, первая информация о текущем статусе может представлять интервал, в который укладывается вторая информация о текущем статусе, т.е. определяется, что вторая информация о текущем статусе попадает в упомянутый интервал. Однако чтобы упростить реализацию и по причинам обеспечения безопасности, может быть предпочтительным «совпадение по равенству», поскольку это очень подходящее условие для проверки того, была ли запись каталога обновлена - любым другим клиентом - с момента выполнения последней операции считывания. Пример проверки совпадения изображен в частности в виде блока 562 проверки на Фиг. 5, т.е. «равно ли текущее значение, хранящееся в атрибуте «entryDigest» (в записи «e») <значению> принятому в фильтре утверждений?». Если условие оценивается как ДА, т.е. определяется совпадение, тогда запись данных изменяется, т.е. «выполняют операцию принятого запроса на изменение LDAP», в частности, как проиллюстрировано блоком 564 на Фиг. 5. Если условие оценивается как НЕТ, не определяется совпадение, то операция принятого запроса на изменения отклоняется, в частности как проиллюстрировано блоком 576 на Фиг. 5 (см. также представленный ниже пункт 3 формулы изобретения и в частности описание Фиг. 5).

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

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

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

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

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

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

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

Примером может быть проверка, подобная тому «должен ли механизм взаимного исключения применяться к клиенту «c» LDAP?», в частности как проиллюстрировано блоком 556 проверки на Фиг. 5. База данных каталога может принять идентификационные данные клиента и/или нового клиента с тем, чтобы выполнить этап проверки, например, с тем, чтобы определить, является ли клиент «c» действительно «c», или принадлежит ли клиент «c» к группе клиентов, имеющих право на данные операции.

В частности, механизм взаимного исключения так же может обозначаться как механизм управления (ctrl) взаимным исключением.

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

Запись данных может быть ассоциирована с идентификатором, указывающим на то, что данная проверка должна выполняться до фактической обработки или перед этапом определения совпадения, и в зависимости от результатов данной проверки, база данных каталога переходит либо к изменению записи данных, либо к отклонению запроса. Примером такого идентификатора может быть всего лишь наличие любой информации о статусе, представляющей любой текущий статус хранения, ассоциированный с записью данных, в качестве альтернативы может существовать специальный идентификатор, например, флаг, который имеет заранее определенное (например, постоянное) значение, указывающее необходимость проверки. Примером может служить проверка подобная «должен ли применяться механизм взаимного исключения к записи «e»?», в частности как иллюстрируется блоком 558 проверки на Фиг. 5. Идентификатор может создаваться в момент создания записи данных и ассоциироваться к записи данных. Кроме того, он может конфигурироваться в любой момент (сколь запись данных уже существует) с тем, чтобы указывать на то, должна или нет применяться упомянутая операция.

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

В частности, база данных каталога может определять, были ли «внесены некие изменения в запись «e»?», и может соответственно обновить значение entryDigest в записи «e» и может сохранить обновленное значение, как проиллюстрировано в блоке 566 проверки и блоке 568 на Фиг. 5.

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

Например, на этапах 684 или 690 на Фиг. 6, информация свертки записи, как пример информации о статусе, отправляется HLR-FE и FE инициализации, которые являются примерами нового клиента и клиента, соответственно.

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

В способе запрос на изменение и/или новый запрос на изменение могут содержать управление Утверждениями LDAP, содержащее вторую информацию о статусе или соответственно четвертую информацию о статусе. В контексте применения, понятие «управление Утверждениями LDAP» может использоваться как синоним понятию «расширенного управления Утверждениями LDAP».

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

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

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

Компьютерный программный продукт может содержать компьютерную программу, в соответствии с тем, что описано выше.

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

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

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

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

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

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

Изобретение в решении Консолидации Данных Пользователя (UDC) может быть реализовано в Центральной Базе Данных Пользователей (CUDB), хранящей ассоциированные с приложением данные пользователя для приложений (например, HLR, AuC, HSS и т.д.). В коммерческом решении UDC, и соответственно CUDB, может играть роль UDR (3GPP стандарт).

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

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

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

На последующих этапах 332 и 334, база 302 данных каталога отправляет первую информацию о статусе для записи данных клиенту 306 и новому клиенту 308, соответственно. Клиент 306 и соответственно новый клиент 308 могут сохранить принятую первую информацию о статусе в модуле хранения клиента 306 и соответственно нового клиента 308.

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

На следующем этапе 338, база 302 данных каталога выполняет определение совпадения первой информации о статусе в базе 302 данных каталога с принятой второй информацией о статусе (в частности принятой) от клиента 306. В соответствии с данным вариантом осуществления, если вторая информация о статусе равна первой информации о статусе, то определение совпадения дает положительный результат. В частности, данное определение может быть оценено как «ДА». Затем база 302 данных каталога выполняет изменение записи данных в базе 302 данных каталога, и в частности обновляет соответствующие данные, например, значение, хранящееся в записи данных. Это приводит к изменению записи данных в базе 302 данных каталога. Дополнительно, база 302 данных каталога выполняет изменение первой информации о статусе, ассоциированной с записью данных, что приводит к третьей информации о статусе, ассоциированной с измененной записью данных.

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

На следующем этапе 344, база 302 данных каталога выполняет определение несовпадения третьей информации о статусе в базе 302 данных каталога с принятой четвертой информацией о статусе (в частности принятой) о