Procedimiento para gestionar la capacidad de libreta de direcciones convergente.

Esta invención se refiere a un procedimiento para gestionar una capacidad de libreta de direcciones convergente de un usuario con una libreta de direcciones y suscrito a un servicio de libreta de direcciones convergente, caracterizado por definir una tupla de servicio en un documento de presencia almacenado en un servidor de presencia; ajustar un valor de capacidad de libreta de direcciones convergente en la tupla de servicio que indica si el usuario soporta el servicio de libreta de direcciones convergente; publicar la capacidad de libreta de direcciones convergente del usuario y un identificador de usuario en un servidor de libreta de direcciones convergente; recibir actualizaciones desde el servidor de presencia de capacidades de dirección convergente de los contactos de los usuarios; y actualizar una libreta de direcciones en red, almacenada en un servidor de gestión de documentos XML de libreta de direcciones convergente, con capacidades de dirección convergente de usuarios a los que se da servicio.

Procedimiento para gestionar la capacidad de libreta de direcciones convergente.

CAMPO TÉCNICO DE LA INVENCIÓN

La presente invención se refiere, en general, a libretas de direcciones y, más específicamente, a la gestión de la capacidad de libreta de direcciones convergente de un usuario y sus contactos.

ANTECEDENTES DE LA INVENCIÓN

Una libreta de direcciones es una base de datos usada para almacenar entradas denominadas contactos. Las actuales normas de telecomunicación definidas en la Open Mobile Alliance (OMA) , concretamente la especificación OMA CAB (Converged Address Book) Enabler (habilitador CAB) , proporcionan un marco para almacenar la libreta de direcciones del usuario en un depositario en red y mantenerla sincronizada con las listas de contactos de los diferentes dispositivos del usuario.

La mayoría de las personas tienen muchas libretas de direcciones diferentes: sus cuentas de correo electrónico, su teléfono móvil y las “listas de amigos” en sus redes sociales. Una libreta de direcciones en red les permite organizar y gestionar todas sus libretas de direcciones a través de una única interfaz y compartir sus contactos a través de sus diferentes libretas de direcciones y redes sociales.

Además, el habilitador CAB proporciona mecanismos para mantener siempre actualizada la información de contacto almacenada en la libreta de direcciones del usuario. Esto se consigue permitiendo que los usuarios definan un perfil personal (tarjeta de visita personal) con su información de contacto al que pueden suscribirse otros usuarios, de modo que reciban notificaciones cuando esta información cambie y puedan así tener la información de contacto más actualizada en sus libretas de direcciones.

El procedimiento para suscribirse a la tarjeta de visita personal (PCC) de otro usuario es como sigue:

• El usuario añade el nuevo contacto al que quiere suscribirse añadiendo su identificador CAB (XUI CAB) a la lista de suscripciones almacenada en el XDMS CAB.

• Después, el servidor CAB toma la lista de suscripciones y emite peticiones de suscripción hacia el XDMS PCC donde están almacenadas las PCC de los contactos en la lista de suscripciones.

• En caso de que haya una regla para tratar automáticamente estas peticiones, ya sea para aceptarlas o para rechazarlas, ésta se aplica,

• De lo contrario, se pide confirmación al usuario final, usando el mecanismo de autorización reactiva.

Este mecanismo sólo es válido cuando los contactos a los que se desea suscribirse están con habilitación CAB. Con el fin de facilitar la averiguación de qué contactos en la libreta de direcciones de un usuario son usuarios con habilitación CAB, el modelo de datos de información de contacto CAB incluye el elemento <contact-type> para codificar que se soporta la capacidad CAB. Por tanto, todos los contactos con este elemento ajustado a un valor apropiado (“CAB”) son de manera segura usuarios con habilitación CAB y por tanto son adecuados para recibir peticiones de suscripción PCC. Este elemento de información que indica la capacidad CAB está sincronizado entre el servidor CAB y el cliente como parte de la libreta de direcciones del usuario.

<address-book xmlns=“urn:oma:xml:cab:address-book”>

<contact>

<person-details id=“gt4fd890bu8”>

[...]

</person-details>

<contact-status>

<contact-type>CAB</contact-type>

<contact-subscription-status>active</contact-subscription-status>

</contact-status>

</contact> </address-book>

El habilitador CAB de OMA se basa en tecnologías y protocolos normalizados como SIP, XDM y OMA DS.

Además de las normas, la solicitud de patente US2010088276A1 describe un marco mediante el cual un usuario indica una lista de contactos en su libreta de direcciones para los que el usuario desea recibir actualizaciones automáticas. Una función de suscripción se encarga de la suscripción a la tarjeta de visita personal de ese conjunto de contactos y de aplicar las correspondientes reglas de personalización a la información de contacto actualizada antes de actualizar la libreta de direcciones del usuario. Esta solicitud de patente también propone el uso de un identificador de usuario unificado tanto para el servicio de presencia como para el servicio de libreta de direcciones convergente, de modo que la información de presencia y de contacto para cada entrada de la libreta de direcciones puedan fusionarse, sin embargo esto no puede considerarse una solución universal para transmitir a un usuario el identificador de sus contactos para el servicio CAB, ya que no puede asumirse que haya una correspondencia universal entre ambos identificadores en todos y cada uno de los sistemas.

La solicitud de patente WO2010033669A1 describe un sistema de libreta de direcciones convergente que permite a un usuario suscribirse a la información de contacto de otro usuario, permitiendo que ese usuario reciba actualizaciones automáticas de la información de tarjeta de visita personal (PCC) disponible de otro usuario de libreta de direcciones convergente. El sistema descrito también permite que un usuario de libreta de direcciones convergente comparta su información de contacto con otros usuarios a través de un esquema de envío de mensajes. Tal información puede incluir la tarjeta de visita personal del usuario, datos de la libreta de direcciones, o ambos en la libreta de direcciones del usuario. El sistema también permite que el usuario de libreta de direcciones convergente importe datos a la libreta de direcciones convergente desde otras fuentes de datos distintas a una libreta de direcciones (no CAB) . Otra característica del sistema descrito es un mecanismo para buscar información de contacto en el sistema de libreta de direcciones convergente anfitrión, el sistema de libreta de direcciones convergente remoto y/o bases de datos externas facilitadas por un proveedor de servicios.

La solicitud de patente WO2009154973A2 describe un sistema de libreta de direcciones convergente que comprende un cliente CAB que gestiona información de contacto y la mantiene sincronizada con un servidor CAB a través de una interfaz de sincronización. El sistema presenta una interfaz adicional entre el cliente CAB y el servidor CAB prevista para implementar una funcionalidad adicional tal como suscribirse a los contactos de un usuario en la libreta de direcciones, gestionar datos (por ejemplo, publicar información y gestionar cambios en la información) , interaccionar con sistemas legados (por ejemplo importación) , compartir, y buscar información de contacto.

Por otro lado, el servicio de presencia está previsto para diseminar información de presencia, con sujeción a los permisos concedidos por el propietario de esta información. El servicio de presencia ha sido definido por la OMA en la especificación OMA Presence Enabler (habilitador de presencia) , que se basa en múltiples RFC relacionadas, especificadas por la Internet Engineering Task Force (IETF) .

La información de presencia de un usuario del servicio de presencia (entidad de presencia o presentity) comprende datos acerca de:

• el propio usuario (<person>) , por ejemplo disposición general para cualquier tipo de comunicación, su apariencia física y estado de ánimo,

• las formas de comunicación que usa el usuario (<tuple>) , por ejemplo la disposición para comunicarse con el servicio A, la disponibilidad del servicio B en su terminal,

• los dispositivos que usa (<device>) , tal como teléfonos móviles, PC y PDA. Existe una correlación de varios a varios de servicios a dispositivos, ya que los mismos servicios pueden ejecutarse en múltiples dispositivos.

El modelo de datos de presencia de OMA es un documento XML que respeta el formato de datos de información de presencia definido por la IETF en RFC3863, con algunas otras extensiones definidas por OMA en la especificación Presence SIMPLE Data.

El servidor de presencia se encarga de aceptar publicaciones de presencia por las entidades de presencia, crear el documento de presencia...

1. Procedimiento para gestionar una capacidad de libreta de direcciones convergente de un usuario con una libreta de direcciones, estando dicho usuario suscrito a un servicio de libreta de direcciones convergente, y estando el procedimiento caracterizado porque comprende las siguientes etapas:

a) definir una tupla de servicio asociada a un habilitador de presencia en un documento de presencia almacenado en un servidor de presencia;

b) ajustar un valor de capacidad de libreta de direcciones convergente en la tupla de servicio indicando si el usuario soporta el servicio de libreta de direcciones convergente;

c) publicar la capacidad de libreta de direcciones convergente del usuario y un identificador de usuario en un servidor de libreta de direcciones convergente;

d) recibir actualizaciones desde el servidor de presencia de capacidades de dirección convergente de los contactos de los usuarios;

e) actualizar una libreta de direcciones en red, almacenada en un servidor de gestión de documentos XML de libreta de direcciones convergente, con capacidades de libreta de direcciones convergente de usuarios a los que se da servicio junto a la dirección de los contactos del servicio de libreta de direcciones convergente y una indicación de que esta información ha sido obtenida por medio del habilitador de presencia.

2. Procedimiento según la reivindicación 1, en el que las etapas a-e se realizan mediante un módulo de función de capacidad de libreta de direcciones convergente conectado con un servidor de libreta de direcciones convergente.

3. Procedimiento según la reivindicación 1, en el que las etapas a-e se realizan en un módulo de función de capacidad de libreta de direcciones convergente implementado en un servidor de libreta de direcciones convergente.

4. Procedimiento según la reivindicación 1, 2 ó 3, en el que la publicación de la capacidad de libreta de direcciones convergente del usuario y el identificador de usuario se consigue enviando una petición a un servidor de gestión de documentos XML de presencia para modificar un estado de presencia permanente.

5. Procedimiento según la reivindicación 1, 2 ó 3, en el que la publicación de una capacidad de libreta de direcciones convergente de un usuario y el identificador de usuario se consigue enviando una petición de “publicación sip” al servidor de presencia.

6. Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende además enviar el módulo de función de capacidad de libreta de direcciones convergente una petición de suscripción a cada uno de los nuevos contactos de la libreta de direcciones notificado por el servidor de libreta de direcciones convergente.

7. Procedimiento según la reivindicación 6, en el que la petición de suscripción es una petición de presencia anónima.

8. Procedimiento según la reivindicación 6 donde la petición de suscripción se trata como proveniente de un cliente de libreta de direcciones convergente, el cual almacena un contacto, cuya presencia está siendo solicitada, en la libreta de direcciones del usuario.

9. Procedimiento según la reivindicación 6 donde la petición de suscripción se trata como proveniente del module de función de capacidad de libreta de direcciones convergente.

10. Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende además analizar si la capacidad de libreta de direcciones convergente se ha obtenido mediante un habilitador de presencia.

11. Procedimiento según la reivindicación 10, que comprende además eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestión de documentos XML de libreta de direcciones convergente cuando una capacidad de libreta de direcciones convergente se obtuvo mediante un habilitador de presencia y se recibe una actualización de información de presencia sin tupla de servicio.

12. Procedimiento según la reivindicación 10, que comprende además eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestión de documentos XML de libreta de direcciones convergente cuando una capacidad de libreta de direcciones convergente se obtuvo mediante un habilitador de presencia y se recibe una actualización de información de presencia con un

valor de la tupla de servicio que indica que dicho usuario ya no soporta el servicio de libreta de direcciones convergente.

13. Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende además eliminar la

información de capacidad de libreta de direcciones convergente del documento de presencia cuando el 5 servidor de libreta de direcciones convergente ya no da servicio al usuario.

14. Programa informático que comprende medios de código de programa adaptados para realizar las etapas del procedimiento según cualquiera de las reivindicaciones 1 a 13, cuando dicho programa se ejecuta en un procesador de propósito general, un procesador de señal digital, una FPGA, un ASIC, un microprocesador, un microcontrolador, o cualquier otra forma de hardware programable.