ES2388389A1 - Procedimiento para gestionar la capacidad de libreta de direcciones convergente. - Google Patents

Procedimiento para gestionar la capacidad de libreta de direcciones convergente. Download PDF

Info

Publication number
ES2388389A1
ES2388389A1 ES201130039A ES201130039A ES2388389A1 ES 2388389 A1 ES2388389 A1 ES 2388389A1 ES 201130039 A ES201130039 A ES 201130039A ES 201130039 A ES201130039 A ES 201130039A ES 2388389 A1 ES2388389 A1 ES 2388389A1
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.)
Granted
Application number
ES201130039A
Other languages
English (en)
Other versions
ES2388389B1 (es
Inventor
Eduardo Fullea Carrera
Laura García García
José Juan Sánchez Dasi
José Luis Núñez Díaz
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
Priority to ES201130039A priority Critical patent/ES2388389B1/es
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to PCT/EP2012/050493 priority patent/WO2012095518A1/en
Priority to US13/979,620 priority patent/US20140082075A1/en
Priority to EP12700808.4A priority patent/EP2664128B1/en
Priority to KR1020137021277A priority patent/KR20140040111A/ko
Priority to CN201280005759.8A priority patent/CN103460681B/zh
Priority to ES12700808.4T priority patent/ES2644267T3/es
Priority to BR112013018048-0A priority patent/BR112013018048A2/pt
Publication of ES2388389A1 publication Critical patent/ES2388389A1/es
Application granted granted Critical
Publication of ES2388389B1 publication Critical patent/ES2388389B1/es
Expired - Fee Related 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)

Abstract

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.

Description

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 y entregar la información de presencia a los observadores según los permisos concedidos por las entidades de presencia.
La información de presencia puede proporcionarla una entidad de presencia mediante uno de estos mecanismos, o ambos:
•
Publicación de información de presencia al servidor de presencia mediante SIP
•
Manipulación del estado de presencia permanente, almacenado en el XDMS de presencia mediante XCAP
El primero se adecua muy bien para publicar información de presencia bastante dinámica y que por tanto cambia a lo largo del tiempo. Por otro lado, el segundo es el más adecuado para información de presencia que no cambia con mucha frecuencia.
El servidor de presencia crea el documento de presencia de un usuario tomando como fuente el estado de presencia permanente, así como la información de presencia publicada en el servidor de presencia desde los diferentes dispositivos de un usuario.
El habilitador de presencia de OMA se basa en tecnologías 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 especificación 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 solución para comprobar la capacidad CAB de aquellos contactos que pertenezcan a otros dominios. Si no hay un mecanismo estándar para que un servidor CAB determine si los contactos en la libreta de direcciones de un usuario que pertenecen a diferentes dominios tienen habilitación CAB, no será posible establecer el correspondiente indicador en la libreta de direcciones y por tanto el usuario no sabrá qué contactos tienen habilitación CAB.
Además de la cuestión anterior, se necesita un mecanismo para determinar la dirección específica 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 INVENCIÓN
La presente invención 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 está 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 invención 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 inclusión 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 dirección de contacto, permitiendo así 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 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;
-
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;
Estas etapas pueden formarse mediante un módulo de función de capacidad de libreta de direcciones convergente, encargado de crear, publicar y actualizar esta información, conectado a un servidor de libreta de direcciones convergente o directamente implementado en el servidor de libreta de direcciones convergente. Por tanto, está disponible para otros clientes CAB.
Se proponen dos formas de publicar la capacidad de libreta de direcciones convergente del usuario, puede conseguirse enviando una petición “sip publish” (publicación sip) al servidor de presencia o directamente modificando un estado de presencia permanente almacenado en un servidor de gestión de documentos XML.
Además, el procedimiento de la invención envía una petición de suscripción a cada uno de los nuevos contactos de la libreta de direcciones notificados por el servidor de libreta de direcciones convergente. La petición es preferiblemente una petición anónima.
Opcionalmente, el procedimiento trata las peticiones de suscripción como provenientes 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.
Opcionalmente, el procedimiento trata las peticiones de suscripción como provenientes del módulo de función de capacidad de libreta de direcciones convergente
Un segundo aspecto de la invención se refiere a cómo el procedimiento gestiona las actualizaciones de información de presencia. Cuando se recibe una actualización de información 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 gestión 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 actualización de información 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 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.
El procedimiento puede eliminar la información de capacidad de libreta de direcciones convergente del documento de presencia cuando el servidor de libreta de direcciones convergente ya no da servicio al usuario.
Además se proporciona un programa informático para realizar las etapas del procedimiento que 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.
Las características y ventajas anteriores no limitan la presente invención, y los expertos en la técnica reconocerán características y ventajas adicionales tras la lectura de la siguiente descripción detallada, y en vista de los dibujos adjuntos.
DESCRIPCIÓN DE LOS DIBUJOS
Para completar la descripción que está realizándose y con objeto de ayudar a una mejor comprensión de las características de la invención, según un ejemplo preferido de realización práctica de la misma, se adjunta a la descripción como parte integrante de la misma un juego de dibujos en los que, a modo de ilustración 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 módulo de función de capacidad CAB.
La figura 2 muestra un diagrama de flujo que representa cómo se gestiona la publicación 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 cómo se gestionan las suscripciones de presencia para nuevos contactos.
La figura 4 muestra un diagrama de flujo que representa cómo se gestionan las actualizaciones de información de presencia mediante la función de capacidad CAB.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
Esta invención proporciona un mecanismo para indicar la capacidad CAB de un usuario a otros usuarios, basándose en la especificación OMA Presence SIMPLE Enabler. La descripción de las realizaciones comprende la presentación de un sistema y el procedimiento necesario para gestionar y permitir la publicación de la información acerca de la capacidad CAB de usuarios, así como una tupla de servicio en el documento de presencia que almacena esta información y permite la integración con el habilitador de presencia.
Se define un módulo en esta invención, concretamente la función de capacidad CAB, que puede formar parte del servidor CAB. La función de capacidad CAB se encarga de la interacción 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 información de capacidad
CAB cuando el servidor CAB ya no da servicio a un usuario (baja en el servidor, denegación
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 indicación de que esta información se obtuvo por medio del habilitador de presencia.
La tupla de servicio para la capacidad CAB definida por esta invención 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 invención no se limita a esto.
También incluye el identificador de usuario de protocolo de acceso de configuración XML (XUI) para el servicio CAB en el elemento <tuple><contact>, es decir el SIP URI o TEL URI que identifica al usuario. Éste es un ejemplo de una tupla válida 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 invención y que incluye el módulo de función de capacidad CAB. El resto de elementos se conocen ampliamente en el estado de la técnica.
Estos son los elementos ubicados en el lado del equipo de usuario (1) (UE):
•
Cliente CAB (2): Este elemento implementa la lógica del habilitador CAB en el lado del UE, por ejemplo sincronización de la libreta de direcciones con el servidor CAB, gestión de la información PCC o interacciones de suscripción de contactos.
•
Observador de presencia (3): este elemento se encarga de la suscripción a información de presencia de entidades de presencia y de la gestión de las actualizaciones de presencia recibidas para su presentación al usuario.
Estos son asimismo los elementos ubicados en el lado del servidor:
•
Servidor CAB (4): este elemento implementa la lógica del habilitador CAB en el lado del servidor, por ejemplo sincronización de la libreta de direcciones con el cliente CAB y realización de las correspondientes actualizaciones en el XDMS CAB, gestión de la suscripción a PCC.
•
XDMS CAB (5): un repositorio de documentos XML que almacena información relativa al servicio CAB (por ejemplo la libreta de direcciones de los usuarios, las preferencias de usuario, etc.).
•
Función de capacidad CAB (6): el nuevo elemento definido por esta invención construido preferiblemente, aunque no necesariamente, como parte del servidor CAB. Este elemento soporta toda la lógica relacionada con la publicación de la capacidad CAB como estado de presencia
permanente en el XDMS de presencia, o como una publicación SIP regular en el servidor de presencia. También realiza la suscripción a información 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 información de presencia.
•
Servidor de presencia (7): este elemento es responsable de gestionar las peticiones de suscripción que recibe, aplicando las reglas de autorización definidas por los propietarios de la información 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 suscripción de presencia y las reglas de publicación de presencia.
Esta invención comprende dos etapas, siendo la primera la publicación, mediante la función de capacidad CAB, en el servidor de presencia de la capacidad CAB cuando un usuario obtiene capacidad CAB. La segunda etapa es la introducción 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 realización preferida, la función 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 publicación de la capacidad CAB de un usuario que, en un momento específico, 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 función de capacidad CAB:
•
Se activa un evento “new user” (nuevo usuario) (11) en el servidor CAB, lanzando un proceso de introducción del nuevo usuario en el habilitador CAB. La función de capacidad CAB se encuentra de manera continua a la escucha de nuevos eventos de introducción, por tanto cuando se introduce un nuevo usuario en el sistema obtiene la información necesaria y lanza un proceso para actualizar la publicación de capacidad CAB en el servidor de presencia.
•
(12)La función de capacidad CAB obtiene la información (9) del nuevo usuario necesaria para actualizar correctamente la información en el documento de presencia, específicamente el identificador de usuario XCAP (XUI) para el servidor XDM CAB, que fue asociado por el servidor CAB durante la introducción del usuario.
•
(13) La función de capacidad CAB obtiene la información (9) necesaria acerca del XDMS de presencia para poder enviar la petición de actualización en la siguiente etapa. Esta información se proporciona en la fase de configuración de la función de capacidad CAB, y se usa después para cada publicación de capacidad CAB.
•
(14) La función de capacidad CAB envía una petición al XDMS de presencia para modificar el estado de presencia permanente asociado a ese usuario, que está 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 función de capacidad CAB puede, según las políticas del proveedor del servicio, no publicar la capacidad CAB hasta que el usuario cree realmente la correspondiente PCC, ya que éste 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 función de capacidad CAB se suscribe a los contactos de los usuarios a los que da servicio con el fin de determinar cuál de ellos tiene capacidad CAB y para añadir esta información a la libreta de direcciones del usuario:
•
El estatus regular para la función de capacidad CAB es el modo de espera (20) de actualizaciones de información de presencia o adición de nuevos contactos a la libreta de direcciones.
•
En un momento específico, el servidor CAB identifica (21) que hay nuevas direcciones en la libreta de direcciones de un usuario (por ejemplo se sincronizan nuevos contactos añadidos al dispositivo con el servidor CAB, o la libreta de direcciones se sincroniza por primera vez).
•
Entonces el servidor CAB lo notifica a la función de capacidad CAB que emite una petición de suscripción de presencia para cada una de las nuevas direcciones (22). La suscripción será preferiblemente una petición de presencia anónima o alternativamente una suscripción en nombre del usuario o la propia función de capacidad CAB. La suscripción puede ser una operación
puntual (suscripción con el atributo de expiración ajustado a cero) que recibe una única notificación, o alternativamente una suscripción real que dura un determinado periodo de tiempo o permanente.
•
Entonces, la función de capacidad CAB vuelve (23) al modo de espera de actualizaciones de información de presencia o adición de nuevos contactos a la libreta de direcciones.
La figura 4 representa el proceso mediante el cual el módulo de función de capacidad CAB recibe una actualización de información de presencia y cómo procede con respecto a la capacidad CAB:
•
El módulo de función de capacidad CAB se encuentra en el modo de espera de actualizaciones de información de presencia o adición de nuevos contactos a la libreta de direcciones.
•
Cuando se recibe una actualización de información de presencia (30), el módulo de función 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 función de capacidad CAB modifica (36) la entrada de la libreta de direcciones correspondiente a esa actualización 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 información anterior a “Presence” modificando el atributo “source” (fuente), definido por primera vez en esta invención, del elemento “contact-type”
•
Añadir el XUI como el XUI CAB del usuario, ajustando el atributo “xuitype” (tipo de xui) de la correspondiente dirección que va a usarse como XUI CAB al valor “CAB”
o Si por el contrario el servicio CAB no está 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” recién definido del elemento “contact-type” ajustado a “Presence”.
•
En caso negativo (46) vuelve al modo de espera
•
En caso afirmativo (47) el modulo de función de capacidad CAB modifica (48) la entrada de la libreta de direcciones correspondiente a esa actualización 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 módulo de función de capacidad CAB sigue a la espera de actualizaciones de información de presencia.
A continuación 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> 5 <tel-str>3341234567<tel-str> </tel-nb>
</comm-addr>
</person-details>
<contact-status>
10 <contact-type source=”Presence”>CAB</contact-type>
<contact-subscription-status>active</contact-subscription-status>
</contact-status>
</contact>
</address-book>
15 En cualquier punto durante el flujo anterior, puede realizarse la sincronización de la libreta de direcciones según la política 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 sabrá que algunos de sus contactos tienen capacidad CAB.
Obsérvese que en este texto, el término “comprende” y sus derivaciones (tal como “comprendiendo”, etc.) 20 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.

Claims (15)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
    OFICINA ESPAÑOLA DE PATENTES Y MARCAS
    N.º solicitud: 201130039
    ESPAÑA
    Fecha de presentación de la solicitud: 14.01.2011
    Fecha de prioridad:
    INFORME SOBRE EL ESTADO DE LA TECNICA
    51 Int. Cl. : H04M3/42 (2006.01) H04L29/08 (2006.01)
    DOCUMENTOS RELEVANTES
    Categoría
    56 Documentos citados Reivindicaciones afectadas
    A
    US 2008205625 A1 (MANDALIA et al.) 28.08.2008, 1-14
    párrafos [0021-0022],[0026-0038].
    A
    US 2010154036 A1 (MCCOLGAN et al.) 17.06.2010, 1-14
    párrafos [0003],[0033-0064].
    A
    US 2010088276 A1 (MOSTAFA) 08.04.2010, 1-14
    párrafos [0022-0024],[0033-0035],[0038].
    A
    US 2009298489 A1 (CHITTURI et al.) 03.12.2009, 1-14
    párrafos [0019-0141].
    A
    US 2009150488 A1 (MARTIN-COCHER et al.) 11.06.2009, 1-14
    párrafos [0022-0137].
    A
    US 2010198854 A1 (CHITTURI et al.) 05.08.2010, 1-14
    párrafos [0003-0073].
    Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud
    El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:
    Fecha de realización del informe 27.09.2012
    Examinador M. L. Alvarez Moreno Página 1/4
    INFORME DEL ESTADO DE LA TÉCNICA
    Nº de solicitud: 201130039
    Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04L, H04M Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de
    búsqueda utilizados) INVENES, EPODOC
    Informe del Estado de la Técnica Página 2/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201130039
    Fecha de Realización de la Opinión Escrita: 27.09.2012
    Declaración
    Novedad (Art. 6.1 LP 11/1986)
    Reivindicaciones Reivindicaciones 1-14 SI NO
    Actividad inventiva (Art. 8.1 LP11/1986)
    Reivindicaciones Reivindicaciones 1-14 SI NO
    Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).
    Base de la Opinión.-
    La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.
    Informe del Estado de la Técnica Página 3/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201130039
    1. Documentos considerados.-
    A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.
    Documento
    Número Publicación o Identificación Fecha Publicación
    D01
    US 2008205625 A1 (MANDALIA et al.) 28.08.2008
    D02
    US 2010154036 A1 (MCCOLGAN et al.) 17.06.2010
    D03
    US 2010088276 A1 (MOSTAFA) 08.04.2010
    D04
    US 2009298489 A1 (CHITTURI et al.) 03.12.2009
    D05
    US 2009150488 A1 (MARTIN-COCHER et al.) 11.06.2009
    US 2010198854 A1 (CHITTURI et al.)
    05.08.2010
  15. 2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración
    Los documentos D01 [párrafos 0021-0022;0026-0038] y D02 [párrafos 0003;0033-0064] muestran que el estándar PIDF (utilizado para publicar información de presencia) utiliza tuplas para representar la información de presencia. Dichas tuplas contienen de forma obligatoria un identificador y un status; de forma opcional pueden contener extensiones (información adicional) como por ejemplo un contacto o notas. Estas extensiones adicionales permiten definir capacidades extras. Ninguno de los documentos encontrados relaciona dicha posibilidad de ampliación de información con el uso indicado en la solicitud en estudio de mostrar la capacidad CAB de un contacto concreto a contactos que pertenezcan a otros dominios. Los documentos D03 [párrafos 0022-0024; 0033-0035; 0038], D04 [párrafos 0019-0141], D05 [párrafos 0022 -0137] y D06 [párrafos 0003-0073] muestran diversas formas de gestionar una libreta de direcciones, en ninguno de los casos se plantea el problema de mostrar a otros contactos la disponibilidad de capacidad CAB utilizando tuplas de servicio particulares en el habilitador de presencia correspondiente. Ninguno de los documentos encontrados relaciona la capacidad CAB de un usuario con el habilitador de presencia del mismo mediante la incorporación de tuplas personalizadas. A la vista de los documentos D01 a D06 las reivindicaciones 1 a 14 tienen actividad inventiva según el artículo 8 de la Ley de Patentes.
    Informe del Estado de la Técnica Página 4/4
ES201130039A 2011-01-14 2011-01-14 Procedimiento para gestionar la capacidad de libreta de direcciones convergente. Expired - Fee Related ES2388389B1 (es)

Priority Applications (8)

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.
US13/979,620 US20140082075A1 (en) 2011-01-14 2012-01-13 Method for managing converged address book capability
EP12700808.4A EP2664128B1 (en) 2011-01-14 2012-01-13 Method for managing converged address book capability
KR1020137021277A KR20140040111A (ko) 2011-01-14 2012-01-13 통합 주소록 기능 관리 방법
PCT/EP2012/050493 WO2012095518A1 (en) 2011-01-14 2012-01-13 Method for managing converged address book capability
CN201280005759.8A CN103460681B (zh) 2011-01-14 2012-01-13 融合地址薄能力的管理方法
ES12700808.4T ES2644267T3 (es) 2011-01-14 2012-01-13 Procedimiento de gestión de la capacidad de libreta de direcciones convergente
BR112013018048-0A BR112013018048A2 (pt) 2011-01-14 2012-01-13 método para gerenciar a capacidade de conversão de agenda de endereços

Applications Claiming Priority (1)

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.

Publications (2)

Publication Number Publication Date
ES2388389A1 true ES2388389A1 (es) 2012-10-15
ES2388389B1 ES2388389B1 (es) 2013-09-03

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 After (1)

Application Number Title Priority Date Filing Date
ES12700808.4T Active ES2644267T3 (es) 2011-01-14 2012-01-13 Procedimiento de gestión de 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

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20090298489A1 (en) * 2008-05-27 2009-12-03 Research In Motion Limited System and method for a converged network-based address book
US20100088276A1 (en) * 2008-08-13 2010-04-08 Nokia Corporation System and method for implementing personalization and mapping in a network-based address book
US20100154036A1 (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
US20100198854A1 (en) * 2009-02-05 2010-08-05 Research In Motion Limited System and method for searching multiple contact information sources in a network-based address book system

Family Cites Families (7)

* 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
KR101414373B1 (ko) * 2008-02-13 2014-08-06 삼성전자주식회사 통합 메시징 서비스의 인터워킹 방법
CN101557409B (zh) * 2008-04-09 2013-04-17 华为技术有限公司 一种地址簿信息融合管理的方法及装置
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
CN101800657B (zh) * 2009-02-10 2013-09-11 中兴通讯股份有限公司 一种融合地址簿系统及其联系视图管理方法
WO2011047050A2 (en) * 2009-10-15 2011-04-21 Reseach In Motion Limited Methods and apparatus to exchange converged address book events among multiple network domains

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20090298489A1 (en) * 2008-05-27 2009-12-03 Research In Motion Limited System and method for a converged network-based address book
US20100088276A1 (en) * 2008-08-13 2010-04-08 Nokia Corporation System and method for implementing personalization and mapping in a network-based address book
US20100154036A1 (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
US20100198854A1 (en) * 2009-02-05 2010-08-05 Research In Motion Limited System and method for searching multiple contact information sources in a network-based address book system

Also Published As

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

Similar Documents

Publication Publication Date Title
ES2523124T3 (es) Un método para la gestión de información de presencia
ES2804773T3 (es) Método, aparato, entidad de red, sistema y producto de programa informático para compartir contenido
CN102047251A (zh) 用于基于汇聚网络的地址簿的系统和方法
US9338186B2 (en) Systems and methods for implementing custom privacy settings
CN105706042B (zh) 聚集和呈现事件信息的方法和系统
US20170251344A1 (en) Method and System for Connecting People in a Social Network
US20140074923A1 (en) Selective content disclosure in an ad-hoc network based on social cohesion
US20100082247A1 (en) Methods, apparatuses, and computer program products for providing user location information
LaRue et al. Assessing mobile phone communication utility preferences in a social support network
AU2012203673B2 (en) Messaging service using different text messaging channels
ES2767097T3 (es) Método, aparatos y aplicaciones para los atributos de oscurecimiento contextual de un perfil de usuario
ES2644267T3 (es) Procedimiento de gestión de la capacidad de libreta de direcciones convergente
BRPI0820975B1 (pt) método executado por um servidor, meio que pode ser lido em computador e dispositivo de rede para especificação, aplicação e extensão de aspectos relacionados a aplicativo referência cruzada a pedidos relacionados
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.
Fressancourt et al. NFCSocial: Social networking in mobility through IMS and NFC
KR20180035350A (ko) 부고알림 및 조문감사인사 서비스방법
US20130290432A1 (en) Apparatus and method for setting disposition with respect to document share
WO2018073843A2 (en) Universal tracking system for vendor- customer communication
JP2011076478A (ja) Ｓｎｓサーバ、プロパティ情報管理方法およびそのプログラム
KR20090013030A (ko) 이동통신의 메시징 서비스에 있어서, 주소록 관리방법 및그 장치
Ravindran et al. Campus Push, Location, Context, Policy Driven Push Notification Application for Mobile Devices
Chen When You Should (and Shouldn't) Share Your Location Using a Smartphone.
Rahman et al. User privacy protection in pervasive social networking applications using PCO
US20110161415A1 (en) Presence Information Management

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2388389

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20130903

FD2A Announcement of lapse in spain

Effective date: 20210915