ES2644267T3 - Procedimiento de gestión de la capacidad de libreta de direcciones convergente - Google Patents

Procedimiento de gestión de la capacidad de libreta de direcciones convergente Download PDF

Info

Publication number
ES2644267T3
ES2644267T3 ES12700808.4T ES12700808T ES2644267T3 ES 2644267 T3 ES2644267 T3 ES 2644267T3 ES 12700808 T ES12700808 T ES 12700808T ES 2644267 T3 ES2644267 T3 ES 2644267T3
Authority
ES
Spain
Prior art keywords
address book
convergent
user
cab
capacity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12700808.4T
Other languages
English (en)
Inventor
Eduardo Fullea Carrera
Laura Garcia Garcia
Jose Juan SANCHEZ DASI
Jose Luis NUÑEZ DIAZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2644267T3 publication Critical patent/ES2644267T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42365—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Description

DESCRIPCION
Procedimiento de gestion de la capacidad de libreta de direcciones convergente Campo tecnico de la invencion
La presente invencion se refiere, en general, a libretas de direcciones y, mas espedficamente, a la gestion de la 5 capacidad de libreta de direcciones convergente de un usuario y sus contactos.
Antecedentes de la invencion
Una libreta de direcciones es una base de datos usada para almacenar entradas denominadas contactos. Las actuales normas de telecomunicacion definidas en la Open Mobile Alliance (OMA), concretamente la especificacion OMA CAB (Converged Address Book) Enabler (habilitador CAB), proporcionan un marco para almacenar la libreta 10 de direcciones del usuario en un depositario en red y mantenerla sincronizada con las listas de contactos de los diferentes dispositivos del usuario.
La mayona de las personas tienen muchas libretas de direcciones diferentes: sus cuentas de correo electronico, su telefono movil 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 traves de una unica interfaz y compartir sus contactos a traves de sus 15 diferentes libretas de direcciones y redes sociales.
Ademas, el habilitador CAB proporciona mecanismos para mantener siempre actualizada la informacion 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 informacion de contacto al que pueden suscribirse otros usuarios, de modo que reciban notificaciones cuando esta informacion cambie y puedan asf tener la informacion de contacto mas 20 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 anade el nuevo contacto al que quiere suscribirse anadiendo su identificador CAB (XUI CAB) a la lista de suscripciones almacenada en el XDMS CAB.
• Despues, el servidor CAB recupera la lista de suscripciones y emite peticiones de suscripcion hacia el 25 XDMS PCC donde estan almacenadas las PCC de los contactos en la lista de suscripciones.
• En caso de que haya una regla para tratar automaticamente estas peticiones, ya sea para aceptarlas o para rechazarlas, esta se aplica,
• De lo contrario, se pide confirmacion al usuario final, usando el mecanismo de autorizacion reactiva.
Este mecanismo solo es valido cuando los contactos a los que se desea suscribirse estan con habilitacion CAB. Con 30 el fin de facilitar la averiguacion de que contactos en la libreta de direcciones de un usuario son usuarios con habilitacion CAB, el modelo de datos de informacion 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 habilitacion CAB y por tanto son adecuados para recibir peticiones de suscripcion PCC. Este elemento de informacion que indica la capacidad CAB esta sincronizado entre 35 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”>
40 </person-details>
<contact-status>
<contact-type>CAB</contact-type>
<contact-subscription-status>active</contact-subscription-status>
</contact-status>
45 </contact>
</address-book>
5
10
15
20
25
30
35
40
45
50
El habilitador CAB de OMA se basa en tecnologfas y protocolos normalizados como SIP, XDM y OMA DS.
Ademas 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 automaticas. Una funcion de suscripcion se encarga de la suscripcion a la tarjeta de visita personal de ese conjunto de contactos y de aplicar las correspondientes reglas de personalizacion a la informacion de contacto actualizada antes de actualizar la libreta de direcciones del usuario. Esta solicitud de patente tambien 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 informacion de presencia y de contacto para cada entrada de la libreta de direcciones puedan fusionarse, sin embargo esto no puede considerarse una solucion 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 informacion de contacto de otro usuario, permitiendo que ese usuario reciba actualizaciones automaticas de la informacion de tarjeta de visita personal (PCC) disponible de otro usuario de libreta de direcciones convergente. El sistema descrito tambien permite que un usuario de libreta de direcciones convergente comparta su informacion de contacto con otros usuarios a traves de un esquema de envfo de mensajes. Tal informacion 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 tambien 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 caractenstica del sistema descrito es un mecanismo para buscar informacion de contacto en el sistema de libreta de direcciones convergente anfitrion, 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 informacion de contacto y la mantiene sincronizada con un servidor CAB a traves de una interfaz de sincronizacion. 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 informacion y gestionar cambios en la informacion), interaccionar con sistemas legados (por ejemplo importacion), compartir, y buscar informacion de contacto.
Por otro lado, el servicio de presencia esta previsto para diseminar informacion de presencia, con sujecion a los permisos concedidos por el propietario de esta informacion. El servicio de presencia ha sido definido por la OMA en la especificacion OMA Presence Enabler (habilitador de presencia OMA), que se basa en multiples RFC relacionadas, especificadas por la Internet Engineering Task Force (IETF).
La informacion de presencia de un usuario del servicio de presencia (entidad de presencia o presentity) comprende datos acerca de:
• el propio usuario (<person>), por ejemplo disposicion general para cualquier tipo de comunicacion, su apariencia ffsica y estado de animo,
• las formas de comunicacion que usa el usuario (<tuple>), por ejemplo la disposicion para comunicarse con el servicio A, la disponibilidad del servicio B en su terminal,
• los dispositivos que usa (<device>), tal como telefonos moviles, PC y PDA. Existe una correlacion de varios a varios de servicios a dispositivos, ya que los mismos servicios pueden ejecutarse en multiples dispositivos.
El modelo de datos de presencia de OMA es un documento XML que respeta el formato de datos de informacion de presencia definido por la IETF en RFC3863, con algunas otras extensiones definidas por OMA en la especificacion Presence SIMPLE Data.
El servidor de presencia se encarga de aceptar publicaciones de presencia por las entidades de presencia, crear el documento de presencia y entregar la informacion de presencia a los observadores segun los permisos concedidos por las entidades de presencia.
La informacion de presencia puede proporcionarla una entidad de presencia mediante uno de estos mecanismos, o ambos:
• Publicacion de informacion de presencia al servidor de presencia mediante SIP
• Manipulacion del estado de presencia permanente, almacenado en el XDMS de presencia mediante XCAP
El primero se adecua muy bien para publicar informacion de presencia bastante dinamica y que por tanto cambia a lo largo del tiempo. Por otro lado, el segundo es el mas adecuado para informacion de presencia que no cambia con mucha frecuencia.
5
10
15
20
25
30
35
40
45
50
El servidor de presencia crea el documento de presencia de un usuario tomando como fuente el estado de presencia permanente, as^ como la informacion de presencia publicada en el servidor de presencia desde los diferentes dispositivos de un usuario.
El habilitador de presencia de OMA se basa en tecnologfas y protocolos normalizados tales como SIP y XDM.
Si bien el habilitador CAB describe la forma de codificar la capacidad CAB de los diferentes contactos en la libreta de direcciones del usuario, queda fuera del alcance del habilitador CAB la especificacion de un procedimiento para realmente determinar si esta capacidad existe para los diferentes contactos. Esto puede ser bastante sencillo para aquellos contactos que pertenezcan al mismo dominio. Sin embargo, se necesita una solucion para comprobar la capacidad CAB de aquellos contactos que pertenezcan a otros dominios. Si no hay un mecanismo estandar para que un servidor CAB determine si los contactos en la libreta de direcciones de un usuario que pertenecen a diferentes dominios tienen habilitacion CAB, no sera posible establecer el correspondiente indicador en la libreta de direcciones y por tanto el usuario no sabra que contactos tienen habilitacion CAB.
Ademas de la cuestion anterior, se necesita un mecanismo para determinar la direccion espedfica entre las diferentes direcciones en una entrada de la libreta de direcciones que identifica al usuario para los fines del servicio CAB.
Sumario de la invencion
La presente invencion sirve para resolver el problema anteriormente mencionado proporcionando un procedimiento para gestionar una capacidad de libreta de direcciones convergente de un usuario con una libreta de direcciones. El usuario esta suscrito a un servicio de libreta de direcciones convergente y el procedimiento le permite indicar su propia capacidad CAB a otros usuarios y conocer la capacidad de libreta de direcciones convergente de sus contactos, es decir si soportan un servicio de libreta de direcciones convergente. A su vez, se proporciona un identificador de usuario a otros usuarios que les permite suscribirse a su tarjeta de visita personal.
Un primer aspecto de la invencion se refiere al procedimiento que comprende las siguientes etapas:
- definir una tupla de servicio asociada a un habilitador CAB en un documento de presencia almacenado en un servidor de presencia. La inclusion de esta tupla de servicio en el documento de presencia del usuario con el estatus ajustado a “open” (abierto) indica la capacidad del usuario para el servicio CAB, y proporciona el XUI del usuario en el campo de direccion de contacto, permitiendo asf a otros usuarios suscribirse a su pCC;
- 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 el servicio de libreta de direcciones convergente;
- recibir en un modulo de funcion de capacidad de libreta de direcciones convergente actualizaciones desde el servidor de presencia de capacidades de direccion convergente de los contactos de los usuarios;
- actualizar una libreta de direcciones en red, almacenada en un servidor de gestion de documentos XML de libreta de direcciones convergente, con las capacidades de libreta de direcciones convergente y la direccion de servicio de libreta de direcciones convergente de la pluralidad de contactos y una indicacion de que esta informacion se obtuvo mediante el habilitador de presencia.
Estas etapas pueden formarse mediante un modulo de funcion de capacidad de libreta de direcciones convergente, encargado de crear, publicar y actualizar esta informacion, conectado a un servidor de libreta de direcciones convergente o directamente implementado en el servidor de libreta de direcciones convergente. Por tanto, esta disponible para otros clientes cAb.
Se proponen dos formas de publicar la capacidad de libreta de direcciones convergente del usuario, puede conseguirse enviando una peticion “sip publish” (publicacion sip) al servidor de presencia o directamente modificando un estado de presencia permanente almacenado en un servidor de gestion de documentos XML.
Ademas, el procedimiento de la invencion envfa una peticion de suscripcion a cada uno de los nuevos contactos de la libreta de direcciones notificados por el servidor de libreta de direcciones convergente. La peticion es preferiblemente una peticion anonima.
Opcionalmente, el procedimiento emite las peticiones de suscripcion como provenientes de un cliente de libreta de direcciones convergente, el cual almacena un contacto, cuya presencia esta siendo solicitada, en la libreta de direcciones del usuario.
Opcionalmente, el procedimiento emite las peticiones de suscripcion como provenientes de la funcion de capacidad de libreta de direcciones convergente
5
10
15
20
25
30
35
40
45
50
Un segundo aspecto de la invencion se refiere a como el procedimiento gestiona las actualizaciones de informacion de presencia. Cuando se recibe una actualizacion de informacion de presencia, el procedimiento analiza si la capacidad de libreta de direcciones convergente se ha obtenido mediante un habilitador de presencia.
El procedimiento puede eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestion de documentos XML de libreta de direcciones convergente, cuando una capacidad de libreta de direcciones convergente se ha obtenido mediante un habilitador de presencia y se recibe una actualizacion de informacion de presencia sin tupla de servicio.
El procedimiento puede eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestion 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 actualizacion de informacion de presencia con un valor de la tupla de servicio que indica que dicho usuario deja de soportar el servicio de libreta de direcciones convergente.
El procedimiento puede eliminar la informacion de capacidad de libreta de direcciones convergente del documento de presencia cuando el servidor de libreta de direcciones convergente deja de dar servicio al usuario.
Ademas se proporciona un programa informatico para realizar las etapas del procedimiento que se ejecuta en un procesador de proposito general, un procesador de senal digital, una FPGA, un ASIC, un microprocesador, un microcontrolador, o cualquier otra forma de hardware programable.
Las caractensticas y ventajas anteriores no limitan la presente invencion, y los expertos en la tecnica reconoceran caractensticas y ventajas adicionales tras la lectura de la siguiente descripcion detallada, y en vista de los dibujos adjuntos.
Descripcion de los dibujos
Para completar la descripcion que esta realizandose y con objeto de ayudar a una mejor comprension de las caractensticas de la invencion, segun un ejemplo preferido de realizacion practica de la misma, se adjunta a la descripcion como parte integrante de la misma un juego de dibujos en los que, a modo de ilustracion y de manera no restrictiva, se ha representado lo siguiente:
La figura 1 representa una arquitectura simplificada de los elementos implicados en el sistema, en el que se aplica el procedimiento, incluyendo un modulo de funcion de capacidad CAB.
La figura 2 muestra un diagrama de flujo que representa como se gestiona la publicacion de una capacidad de libreta de direcciones convergente de nuevos usuarios en un servidor CAB.
La figura 3 muestra un diagrama de flujo que representa como se gestionan las suscripciones de presencia para nuevos contactos.
La figura 4 muestra un diagrama de flujo que representa como se gestionan las actualizaciones de informacion de presencia mediante la funcion de capacidad CAB.
DESCRIPCION DETALLADA DE LA INVENCION
Esta invencion proporciona un mecanismo para indicar la capacidad CAB de un usuario a otros usuarios, basandose en la especificacion OMA Presence SIMPLE Enabler. La descripcion de las realizaciones comprende la presentacion de un sistema y el procedimiento necesario para gestionar y permitir la publicacion de la informacion acerca de la capacidad CAB de usuarios, asf como una tupla de servicio en el documento de presencia que almacena esta informacion y permite la integracion con el habilitador de presencia.
Se define un modulo en esta invencion, concretamente la funcion de capacidad CAB, que puede formar parte del servidor CAB. La funcion de capacidad CAB se encarga de la interaccion con el XDMS de presencia, el servidor de presencia y el XDMS CAB con el fin de llevar a cabo las siguientes funciones:
• publicar la capacidad CAB de nuevos usuarios como una tupla de servicio en el correspondiente documento de presencia, cada vez que se introduce un nuevo usuario en el servidor CAB.
• actualizar el correspondiente documento de presencia para eliminar la informacion de capacidad CAB cuando el servidor CAB ya no da servicio a un usuario (baja en el servidor, denegacion temporal de servicios...).
• recibir actualizaciones relativas a la capacidad CAB de los contactos de usuarios a los que se da servicio
• realizar las correspondientes actualizaciones en la libreta de direcciones en red para reflejar las capacidades de los diferentes usuarios, y una indicacion de que esta informacion se obtuvo por medio del habilitador de presencia.
5
10
15
20
25
30
35
40
La tupla de servicio para la capacidad CAB definida por esta invencion incluye un identificador del habilitador CAB en el elemento <tuple><op:service-description><op:service-id>. El valor preferido para este elemento es org.openmobilealliance:CAB, pero la presente invencion no se limita a esto.
Tambien incluye el identificador de usuario de protocolo de acceso de configuracion XML (XUI) para el servicio CAB en el elemento <tuple><contact>, es decir el SIP URI o TEL URI que identifica al usuario.
Este es un ejemplo de una tupla valida para el servicio CAB:
<tuple id=“a1232”>
<status>
<basic>open</basic>
</status>
<op:willingness>
<op:basic>open</op:basic>
</op:willingness>
<op:service-description>
<op:service-id>org.openmobilealliance:CAB</op:service-id>
<op:version>1.0</op:version>
<op:description>This is the OMA Converged Address Book service</op:description> </op:service-description>
<contact>sip:someone@example.com</contact>
</tuple>
La figura 1 representa una arquitectura simplificada de los elementos implicados en los mecanismos definidos por la presente invencion y que incluye el modulo de funcion de capacidad CAB. El resto de elementos se conocen ampliamente en el estado de la tecnica.
Estos son los elementos ubicados en el lado del equipo de usuario (1) (UE):
• Cliente CAB (2): Este elemento implementa la logica del habilitador CAB en el lado del UE, por ejemplo sincronizacion de la libreta de direcciones con el servidor CAB, gestion de la informacion PCC o interacciones de suscripcion de contactos.
• Observador de presencia (3): este elemento se encarga de la suscripcion a informacion de presencia de entidades de presencia y de la gestion de las actualizaciones de presencia recibidas para su presentacion al usuario.
Estos son asimismo los elementos ubicados en el lado del servidor:
• Servidor CAB (4): este elemento implementa la logica del habilitador CAB en el lado del servidor, por ejemplo sincronizacion de la libreta de direcciones con el cliente CAB y realizacion de las correspondientes actualizaciones en el XDMS CAB, gestion de la suscripcion a PCC.
• XDMS CAB (5): un repositorio de documentos XML que almacena informacion relativa al servicio CAB (por ejemplo la libreta de direcciones de los usuarios, las preferencias de usuario, etc.).
• Funcion de capacidad CAB (6): el nuevo elemento definido por esta invencion construido preferiblemente, aunque no necesariamente, como parte del servidor CAB. Este elemento soporta toda la logica relacionada con la publicacion de la capacidad CAB como estado de presencia permanente en el XDMS de presencia, o como una publicacion SIP regular en el servidor de presencia. Tambien realiza la suscripcion a informacion de presencia de los contactos de los usuarios a los que da servicio con el fin de recibir su capacidad CAB como parte de las actualizaciones de informacion de presencia.
5
10
15
20
25
30
35
40
45
50
• Servidor de presencia (7): este elemento es responsable de gestionar las peticiones de suscripcion que recibe, aplicando las reglas de autorizacion definidas por los propietarios de la informacion de presencia, crear el documento de presencia, y proporcionar las actualizaciones de presencia de vuelta a los observadores.
• XDMS de presencia (8): este elemento almacena el estado de presencia permanente, las reglas de suscripcion de presencia y las reglas de publicacion de presencia.
Esta invencion comprende dos etapas, siendo la primera la publicacion, mediante la funcion de capacidad CAB, en el servidor de presencia de la capacidad CAB cuando un usuario obtiene capacidad CAB. La segunda etapa es la introduccion de este indicador “cAB-enabled” (con capacidad CAB) en la libreta de direcciones de los usuarios CAB que tienen el nuevo usuario CAB como contacto.
En una realizacion preferida, la funcion de capacidad CAB publica la correspondiente capacidad CAB en el documento de estado de presencia de un usuario que obtiene capacidad CAB.
La figura 2 detalla las etapas para gestionar la publicacion de la capacidad CAB de un usuario que, en un momento espedfico, obtiene capacidad CAB (10) (por ejemplo adquiere un dispositivo con esta capacidad, se registra en el servicio, etc.) en el servidor CAB, realizada por la funcion de capacidad CAB:
• Se activa un evento “new user” (nuevo usuario) (11) en el servidor CAB, lanzando un proceso de introduccion del nuevo usuario en el habilitador CAB. La funcion de capacidad CAB se encuentra de manera continua a la escucha de nuevos eventos de introduccion, por tanto cuando se introduce un nuevo usuario en el sistema obtiene la informacion necesaria y lanza un proceso para actualizar la publicacion de capacidad CAB en el servidor de presencia.
• (12) La funcion de capacidad CAB obtiene la informacion (9) del nuevo usuario necesaria para actualizar correctamente la informacion en el documento de presencia, espedficamente el identificador de usuario XCAP (XUI) para el servidor XDM CAB, que fue asociado por el servidor CAB durante la introduccion del usuario.
• (13) La funcion de capacidad CAB obtiene la informacion (9) necesaria acerca del XDMS de presencia para poder enviar la peticion de actualizacion en la siguiente etapa. Esta informacion se proporciona en la fase de configuracion de la funcion de capacidad CAB, y se usa despues para cada publicacion de capacidad CAB.
• (14) La funcion de capacidad CAB envfa una peticion al XDMS de presencia para modificar el estado de presencia permanente asociado a ese usuario, que esta almacenado en el XDMS de presencia, para que incluya la nueva tupla de servicio CAB. Esta tupla tiene el estatus ajustado a “open” e incluye el XUI del usuario para el servicio CAB que permite que otros usuarios se suscriban a su PCC.
La funcion de capacidad CAB puede, segun las polfticas del proveedor del servicio, no publicar la capacidad CAB hasta que el usuario cree realmente la correspondiente PCC, ya que este es el momento en el que otros usuarios pueden empezar a beneficiarse completamente del hecho de que este usuario se haya suscrito al servicio (es decir otros usuarios pueden suscribirse a su PCC).
La figura 3 representa el proceso mediante el cual la funcion de capacidad CAB se suscribe a los contactos de los usuarios a los que da servicio con el fin de determinar cual de ellos tiene capacidad CAB y para anadir esta informacion a la libreta de direcciones del usuario:
• El estatus regular para la funcion de capacidad CAB es el modo de espera (20) de actualizaciones de informacion de presencia o adicion de nuevos contactos a la libreta de direcciones.
• En un momento espedfico, el servidor CAB identifica (21) que hay nuevas direcciones en la libreta de direcciones de un usuario (por ejemplo se sincronizan nuevos contactos anadidos al dispositivo con el servidor CAB, o la libreta de direcciones se sincroniza por primera vez).
• Entonces el servidor CAB lo notifica a la funcion de capacidad CAB que emite una peticion de suscripcion de presencia para cada una de las nuevas direcciones (22). La suscripcion sera preferiblemente una peticion de presencia anonima o alternativamente una suscripcion en nombre del usuario o la propia funcion de capacidad CAB. La suscripcion puede ser una operacion puntual (suscripcion con el atributo de expiracion ajustado a cero) que recibe una unica notificacion, o alternativamente una suscripcion real que dura un determinado periodo de tiempo o permanente.
• Entonces, la funcion de capacidad CAB vuelve (23) al modo de espera de actualizaciones de informacion de presencia o adicion de nuevos contactos a la libreta de direcciones.
La figura 4 representa el proceso mediante el cual el modulo de funcion de capacidad CAB recibe una actualizacion de informacion de presencia y como procede con respecto a la capacidad CAB:
• El modulo de funcion de capacidad CAB se encuentra en el modo de espera de actualizaciones de
7
5
10
15
20
25
30
35
40
informacion de presencia o adicion de nuevos contactos a la libreta de direcciones.
• Cuando se recibe una actualizacion de informacion de presencia (30), el modulo de funcion de capacidad CAB comprueba (31) si el documento de presencia recibido incluye la tupla de servicio CAB:
o Si incluye el servicio CAB con el estatus ajustado a “open” (32), entonces comprueba (33) si el usuario ya
estaba identificado como con capacidad CAB.
■ En caso afirmativo (34) vuelve al modo de espera.
■ En caso negativo (35), el modulo de funcion de capacidad CAB modifica (36) la entrada de la libreta de direcciones correspondiente a esa actualizacion de presencia en el XDMS CAB de la siguiente manera antes de volver al modo de espera:
• Ajustar el tipo de contacto a tipo de usuario CAB ajustando el elemento “contact-type” a “CAB”
• Ajustar la fuente la informacion anterior a “Presence” modificando el atributo “source” (fuente), definido por primera vez en esta invencion, del elemento “contact-type”
• Anadir el XUI como el XUI CAB del usuario, ajustando el atributo “xui-type” (tipo de xui) de la correspondiente direccion que va a usarse como XUI cAb al valor “CAB”
o Si por el contrario el servicio CAB no esta presente (40) o tiene el estatus ajustado a “closed” (cerrado) (41),
entonces comprueba (42) si el usuario ya estaba definido como con capacidad CAB.
■ En caso negativo (43) vuelve al modo de espera
■ En caso afirmativo (44) comprueba adicionalmente (45) si la capacidad CAB se obtuvo por medio del habilitador de presencia, es decir el atributo “source” recien definido del elemento “contact-type” ajustado a “Presence”.
• En caso negativo (46) vuelve al modo de espera
• En caso afirmativo (47) el modulo de funcion de capacidad CAB modifica (48) la entrada de la libreta de direcciones correspondiente a esa actualizacion de presencia en el XDMS CAB de la siguiente manera antes de volver al modo de espera:
o Eliminar totalmente el elemento “contact-type”
o Eliminar el atributo “xui-type” con valor “CAB”
• El modulo de funcion de capacidad CAB sigue a la espera de actualizaciones de informacion de presencia.
A continuacion se da un ejemplo de una entrada de contacto que se ha actualizado para reflejar la capacidad CAB de ese contacto:
<address-book xmlns="urn:oma:xml:cab:address-book"> <contact>
<person-details id=”gt4fd890bu8”>
<comm-addr xml:lang=“en”>
<tel tel-type=”Mobile” xui-type=”CAB”>
<tel-nb>
<tel-str>3341234567<tel-str>
</tel-nb>
</comm-addr>
</person-details>
<contact-status>
<contact-type source=”Presence”>CAB</contact-type>
<contact-subscription-status>active</contact-subscription-status>
</contact-status>
</contact>
5 </address-book>
En cualquier punto durante el flujo anterior, puede realizarse la sincronizacion de la libreta de direcciones segun la polftica habitual del habilitador CAB y las preferencias de usuario. Cuando se produce, todos los cambios realizados en el XDMS CAB se introducen en el cliente CAB y el usuario sabra que algunos de sus contactos tienen capacidad 10 CAB.
Observese que en este texto, el termino “comprende” y sus derivaciones (tal como “comprendiendo”, etc.) no han de entenderse en un sentido excluyente, es decir, estas expresiones no deben interpretarse como que excluyen la posibilidad de que lo que se describe y define pueda incluir otros elementos, etapas, etc.
15

Claims (14)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    REIVINDICACIONES
    1. Procedimiento de gestion de una capacidad de libreta de direcciones convergente de un usuario con una libreta de direcciones que incluye una pluralidad de contactos, estando dicho usuario suscrito a un servicio de libreta de direcciones convergente, en el que se define una tupla de servicio asociada a un habilitador de presencia en un documento de presencia almacenado en un servidor de presencia y comprendiendo el procedimiento las siguientes etapas:
    a) 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 (14);
    b) publicar (14) en el servidor de presencia la capacidad de libreta de direcciones convergente del usuario y un identificador de usuario en el servicio de libreta de direcciones convergente;
    c) recibir en un modulo de funcion de capacidad de libreta de direcciones convergente actualizaciones (30) desde el servidor de presencia de capacidades de direccion convergente de la pluralidad de contactos del usuario;
    d) actualizar (36, 48) una libreta de direcciones en red, almacenada en un servidor de gestion de documentos XML de libreta de direcciones convergente, con capacidades de libreta de direcciones convergente y direccion de servicio de libreta de direcciones convergente de la pluralidad de contactos y una indicacion de que esta informacion ha sido obtenida por medio del habilitador de presencia.
  2. 2. Procedimiento segun la reivindicacion 1, en el que las etapas a-d se realizan mediante un modulo de funcion de capacidad de libreta de direcciones convergente conectado con el servidor de libreta de direcciones convergente.
  3. 3. Procedimiento segun la reivindicacion 1, en el que las etapas a-d se realizan en el modulo de funcion de capacidad de libreta de direcciones convergente implementado en el servidor de libreta de direcciones convergente.
  4. 4. Procedimiento segun la reivindicacion 1, 2 o 3, en el que la publicacion de la capacidad de libreta de direcciones convergente del usuario y el identificador de usuario se consigue enviando una peticion a un servidor de gestion de documentos XML de presencia para modificar un estado de presencia permanente.
  5. 5. Procedimiento segun la reivindicacion 1, 2 o 3, en el que la publicacion de una capacidad de libreta de direcciones convergente de un usuario y el identificador de usuario se consigue enviando una peticion de “publicacion sip” al servidor de presencia.
  6. 6. Procedimiento segun una cualquiera de las reivindicaciones anteriores, que comprende ademas el envfo por el modulo de funcion de capacidad de libreta de direcciones convergente de una peticion de suscripcion a cada uno de los nuevos contactos de la libreta de direcciones notificado por el servidor de libreta de direcciones convergente.
  7. 7. Procedimiento segun la reivindicacion 6, en el que la peticion de suscripcion es una peticion de presencia anonima.
  8. 8. Procedimiento segun la reivindicacion 6, en el que la peticion de suscripcion se emite como proveniente de un cliente de libreta de direcciones convergente, el cual almacena un contacto, cuya presencia esta siendo solicitada, en la libreta de direcciones del usuario.
  9. 9. Procedimiento segun la reivindicacion 6, en el que la peticion de suscripcion se emite como proveniente del modulo de funcion de capacidad de libreta de direcciones convergente.
  10. 10. Procedimiento segun una cualquiera de las reivindicaciones anteriores, que comprende ademas analizar si la capacidad de libreta de direcciones convergente se ha obtenido mediante un habilitador de presencia.
  11. 11. Procedimiento segun la reivindicacion 10, que comprende ademas eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestion 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 actualizacion de informacion de presencia sin tupla de servicio.
  12. 12. Procedimiento segun la reivindicacion 10, que comprende ademas eliminar la capacidad de libreta de direcciones convergente y el identificador de usuario del servidor de gestion 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 actualizacion de informacion de presencia con un valor de la tupla de servicio que indica que dicho usuario deja de soportar el servicio de libreta de direcciones convergente.
  13. 13. Procedimiento segun una cualquiera de las reivindicaciones anteriores, que comprende ademas eliminar la informacion de capacidad de libreta de direcciones convergente del documento de presencia cuando el servidor de
    10
    libreta de direcciones convergente deja de dar servicio al usuario.
  14. 14. Un programa informatico que comprende medios de codigo de programa adaptados para realizar las etapas del procedimiento segun cualquiera de las reivindicaciones 1 a 13, cuando dicho programa se ejecuta en un procesador de proposito general, un procesador de senal digital, una FPGA, un ASIC, un microprocesador, un 5 microcontrolador, o cualquier otra forma de hardware programable.
ES12700808.4T 2011-01-14 2012-01-13 Procedimiento de gestión de la capacidad de libreta de direcciones convergente Active ES2644267T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
ES201130039A ES2388389B1 (es) 2011-01-14 2011-01-14 Procedimiento para gestionar la capacidad de libreta de direcciones convergente.
ES201130039P 2011-01-14
PCT/EP2012/050493 WO2012095518A1 (en) 2011-01-14 2012-01-13 Method for managing converged address book capability

Publications (1)

Publication Number Publication Date
ES2644267T3 true ES2644267T3 (es) 2017-11-28

Family

ID=45524526

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201130039A Expired - Fee Related ES2388389B1 (es) 2011-01-14 2011-01-14 Procedimiento para gestionar la capacidad de libreta de direcciones convergente.
ES12700808.4T Active ES2644267T3 (es) 2011-01-14 2012-01-13 Procedimiento de gestión de la capacidad de libreta de direcciones convergente

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES201130039A Expired - Fee Related ES2388389B1 (es) 2011-01-14 2011-01-14 Procedimiento para gestionar la capacidad de libreta de direcciones convergente.

Country Status (7)

Country Link
US (1) US20140082075A1 (es)
EP (1) EP2664128B1 (es)
KR (1) KR20140040111A (es)
CN (1) CN103460681B (es)
BR (1) BR112013018048A2 (es)
ES (2) ES2388389B1 (es)
WO (1) WO2012095518A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101906413B1 (ko) * 2012-08-02 2018-10-11 삼성전자주식회사 통신 시스템에서 개인 정보를 갱신하는 방법 및 장치
KR101954101B1 (ko) * 2012-08-02 2019-03-06 삼성전자주식회사 통신 시스템에서 개인 정보를 갱신하는 방법 및 장치
US9246959B2 (en) * 2012-10-10 2016-01-26 Salesforce.Com, Inc. System and method for location-based social network feeds
US9723075B2 (en) * 2013-09-13 2017-08-01 Incontact, Inc. Systems and methods for data synchronization management between call centers and CRM systems

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0409949D0 (en) * 2004-05-04 2004-06-09 Nokia Corp A communciation system for handling subscriber requests
US7706521B2 (en) * 2007-02-28 2010-04-27 International Business Machines Corproation Standards based agent desktop for use with an open contact center solution
US20080205625A1 (en) * 2007-02-28 2008-08-28 International Business Machines Corporation Extending a standardized presence document to include contact center specific elements
US20090150488A1 (en) * 2007-12-07 2009-06-11 Martin-Cocher Gaelle System and method for managing multiple external identities of users with local or network based address book
KR101414373B1 (ko) * 2008-02-13 2014-08-06 삼성전자주식회사 통합 메시징 서비스의 인터워킹 방법
CN101557409B (zh) * 2008-04-09 2013-04-17 华为技术有限公司 一种地址簿信息融合管理的方法及装置
WO2009154973A2 (en) 2008-05-27 2009-12-23 Research In Motion Limited System and method for a converged network-based address book
CN102171690B (zh) * 2008-08-13 2014-11-05 诺基亚公司 用于在基于网络的地址簿中实现个性化和映射的系统与方法
US9130966B2 (en) 2008-09-17 2015-09-08 Blackberry Limited System and method for access and communication between a converged network-based address book system and a user device
WO2010066038A1 (en) * 2008-12-12 2010-06-17 Research In Motion Limited System and method for encapsulation of application aspects within an application information data format message
CA2750960A1 (en) * 2009-02-05 2010-08-12 Research In Motion Limited System and method for aggregating multiple contact information sources in a network-based address book system
CN101800657B (zh) * 2009-02-10 2013-09-11 中兴通讯股份有限公司 一种融合地址簿系统及其联系视图管理方法
US20110252091A1 (en) * 2009-10-15 2011-10-13 Suresh Chitturi Methods and apparatus to exchange converged address book events among multiple network domains

Also Published As

Publication number Publication date
EP2664128A1 (en) 2013-11-20
US20140082075A1 (en) 2014-03-20
ES2388389A1 (es) 2012-10-15
BR112013018048A2 (pt) 2020-10-27
CN103460681B (zh) 2016-02-03
WO2012095518A1 (en) 2012-07-19
KR20140040111A (ko) 2014-04-02
CN103460681A (zh) 2013-12-18
ES2388389B1 (es) 2013-09-03
EP2664128B1 (en) 2017-07-26

Similar Documents

Publication Publication Date Title
US9922205B2 (en) Managing personal privacy settings
ES2386564B1 (es) Método para gestionar información de presencia.
US9432381B2 (en) Managed dissemination of location data
US20170251344A1 (en) Method and System for Connecting People in a Social Network
ES2285149T3 (es) Sistema y metodo para proporcionar notificaciones parciales de presencia.
ES2804773T3 (es) Método, aparato, entidad de red, sistema y producto de programa informático para compartir contenido
US9565155B2 (en) System and method for openly sharing and synchronizing information across a plurality of mobile client application computers
US20170118165A1 (en) System and method for controlled sharing and synchronizing information across a plurality of mobile client application computers
CN102047251A (zh) 用于基于汇聚网络的地址簿的系统和方法
US9661092B2 (en) Method and apparatus for providing presence information
US8645484B2 (en) Messaging service using different text messaging channels
WO2014043152A1 (en) Selective content disclosure in an ad-hoc network based on social cohesion
WO2011138473A1 (es) Sistema y método de sincronización entre el perfil de un usuario en redes sociales y su tarjeta de contacto personal pcc
KR20120059594A (ko) 증강 소셜 네트워킹 메시징을 위한 방법 및 장치
ES2644267T3 (es) Procedimiento de gestión de la capacidad de libreta de direcciones convergente
US8275365B1 (en) Method and system for providing presence information
ES2400642B1 (es) Método para proporcionar información de presencia social en redes de telecomunicación.
Ayoola et al. Do CHANGE platform: A service-based architecture for secure aggregation and distribution of health and wellbeing data
Fressancourt et al. NFCSocial: Social networking in mobility through IMS and NFC
EP2712148A1 (en) Method and system for providing presence information
CA3041022A1 (en) Universal tracking system for vendor- customer communication
Ravindran et al. Campus Push, Location, Context, Policy Driven Push Notification Application for Mobile Devices
KR20090001719A (ko) 프레즌스 관리 시스템 및 그 방법
KR101724019B1 (ko) 장기 입원환자를 위한 상생형 재능기부 어플 제공시스템
AU2013231020B2 (en) Messaging service using different text messaging channels