WO2011073462A1 - Método y sistema de gestión de notificaciones sociales para dispositivos móviles - Google Patents

Método y sistema de gestión de notificaciones sociales para dispositivos móviles Download PDF

Info

Publication number
WO2011073462A1
WO2011073462A1 PCT/ES2009/070597 ES2009070597W WO2011073462A1 WO 2011073462 A1 WO2011073462 A1 WO 2011073462A1 ES 2009070597 W ES2009070597 W ES 2009070597W WO 2011073462 A1 WO2011073462 A1 WO 2011073462A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
social
notifications
notification
service
Prior art date
Application number
PCT/ES2009/070597
Other languages
English (en)
French (fr)
Inventor
Francisco Oteiza Lacalle
Jordi ROVIRA SIMÓN
Original Assignee
Telefonica, S.A.
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, S.A. filed Critical Telefonica, S.A.
Priority to CN2009801633155A priority Critical patent/CN102741836A/zh
Priority to US13/516,360 priority patent/US20130173734A1/en
Priority to MX2012006975A priority patent/MX2012006975A/es
Priority to BR112012014914A priority patent/BR112012014914A2/pt
Priority to PCT/ES2009/070597 priority patent/WO2011073462A1/es
Priority to EP09852214A priority patent/EP2515243A1/en
Publication of WO2011073462A1 publication Critical patent/WO2011073462A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • 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/55—Push-based network services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/52—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail for supporting social networking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H04W4/21—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel for social networking applications
    • 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/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers

Definitions

  • the following invention aims to contribute to current social aggregators.
  • the main objective is to ensure that social services are used in a massive way and that they are perfectly integrated into the social networks that already exist on the internet. Therefore, the main objective of the invention is to offer social capabilities integrated in mobile devices. STATE OF THE TECHNIQUE
  • This portal has become a universal reference in the world of social networks and has become the forefront of this new social technology.
  • OMA is responsible for standardizing mobile technology, the work groups that are related to social networks are:
  • LWG Location Working Group
  • the mobile client -figure 1 (1) - consists; in a resident software or a web service in charge of managing user interaction. Present the information and collect the events that occur on the phone. For the communication of social events use the basic communications support offered by the phone's operating system but it must be responsible for the management of social notifications. This includes information formatting, social session maintenance, temporary storage of information, control of redundant information and instant notifications.
  • the services use a server platform - Figure 1 (2) - which is in charge of communications with social networks and mobile customers. Communications do not follow a standard; In the case of social networks, they use an interface defined by each social network - Figure 1 (4) -. In the case of data exchange between client and platform, this is done with a single format associated with each aggregator service -figure 1 (3) -.
  • the platform is at the same time in charge of managing all the accounts associated with each user, storing the information in a temporary file and almost immediate notification of the changes or news of each social network to which the user belongs. This condition implies that communication between aggregators is impossible.
  • the technology used to notify these events is usually http. Customers initiate a "time-to-time" or "on-demand” communication to see if there are updates. This means that sometimes notifications are not made immediately but when the user asks for them.
  • the main functions that aggregators offer users are:
  • mobile applications In the absence of a unified architecture that defines a global mode of operation, mobile applications have difficulty receiving social notifications in real time. They are forced to implement their particular methods to know what is happening in the social life of the user distributed among: social networks and the network architecture of the operator. They cannot register to a module that notifies them of what is happening and thus download this task since it does not exist in the implementations of the phone's operating system.
  • the fundamental problem is that the approach that has been given to social mobile customers has been only at the level of the mobile phone's application layer. This again implies communication problems, in this case among all those social-related applications that are deployed on a mobile phone. This is due to the absence of a specifically designed module responsible for managing social notifications in the operating system layer and allowing other applications to access your data. It is significant that there is no group in OMA that is exclusively intended to develop a specification on social activity for mobile phones. In this way the application layer could have a support in the operating system layer for everything related to the social that occurs in a mobile phone.
  • Figure 2 (1) shows the current architecture available on mobile phones.
  • SC Social clients
  • OS operating system
  • FIG. 1 shows the current architecture available on mobile phones.
  • SC uses the communications module of the operating system (OS) to interact with their server platform. They cannot exchange social data using a generic module. It could be the case that they did it directly without involving the operating system layer, but only if both implement a complicated system of mutual recognition.
  • Security is also compromised. There is no single point where information is centralized or managed by a trusted entity such as a network operator.
  • the invention consists of an enabler device (enabler) that allows the user of mobile applications to make use of all the data generated by the user's social events.
  • This enabling device will be used either by the manufacturer's applications or by the applications developed by third parties.
  • This invention allows an exclusively social service to be integrated into the operating system of mobile phones (for example, contact book, instant email service).
  • This enabling device will allow all the user's social activity to be accessible as a source of information for client applications that make use of the mobile phone application environment.
  • This enabler is supported by the mobile device and the network operator architecture. Therefore a double intervention is necessary.
  • the present invention has as its first object a method of managing SOCIAL NOTIFICATIONS FOR MOBILE DEVICES (SMNS, Social Mobile Notification Service), which comprises the following phases: - having at least one service module integrated in the operating system of a mobile device, equipped with means of processing, updating and storing notifications of social events,
  • SMNS Social Mobile Notification Service
  • platform module integrated in a server of the architecture of a mobile network operator equipped with storage, processing and distribution of social event notifications, establish communication between the platform and service modules through a protocol designed using http technology (XML, REST API, Web services) and that is transparent to the application layers above the operating system layer,
  • http technology XML, REST API, Web services
  • a notification originates in the service module, it comprises the following phases in the platform module: receiving the notification in a REST (Representational State Transfer) module through a pul ⁇ request,
  • connection module that connects with external social networks and operator services, returning a response to the operation performed to the REST module through the internal services module, adapt the response in the REST module to a format required by the service module included in the mobile device
  • SMSC short message service center
  • the notification originates from external social networks and operator services, it comprises the following phases in the platform module, receiving the notification from a connection module,
  • the notification originates in the WEB clients or native applications, it comprises the following phases in the service module, receiving, decomposing and redirecting the notification in an API management module (Application Programming Interface) towards an internal services module, which includes managing the logic of social requests and the negotiation of data between clients deployed on the mobile device and additionally comprising means for checking information and updating social events,
  • API management module Application Programming Interface
  • internal services module which includes managing the logic of social requests and the negotiation of data between clients deployed on the mobile device and additionally comprising means for checking information and updating social events
  • the notifications originate in the platform module, it comprises the following phases in the service module, - receiving the notification from the notification service module by means of push-type requests,
  • the integration of the platform module through a connection module with social networks is done in two ways:
  • This connection module is an implementation of the platform which is connected using the APIs provided by social networks.
  • the platform module itself is in charge of making the requests and conforms to the standards of social networks to extract information of a social nature -figure 4 (6) -.
  • Normally communication with social networks is done using http technology, but it depends on each case. The detailed information of each API should be consulted.
  • the platform module offers a public API so that other networks that are not connected using the method described above can include their information in that module.
  • the social aggregator will define a public API to exchange data with social networks -figure 4 (7) -. To handle this communication, it deploys a series of web services accessible via http. These web services include the basic primitives to consult and update social events and the added contact list.
  • the platform module when the platform module communicates through the public API, it can be done through accessible web services via http which include basic functions of asking and updating social events and the contact list aggregator.
  • the platform module can also provide network operator services other than the social notification service. These operator services may be selected from location services, added calendar services, calls and messages but there may be more such as presence service.
  • Communication between the invented modules is done through a simple standard protocol that uses http connections - Figure 4 (3) -.
  • the protocol includes push and press requests - Figure 5-.
  • Pul ⁇ requests consist of: requests for information that are made from the mobile device to the server. They are requests originated at the mobile application level, as a response to the user's activity to social networks. "Pul ⁇ ” requests include information on global social events, event search, event updates and management of the added contact list. These requests are only made in those cases in which the SMNS service does not contain the information that is being requested.
  • Push requests consist of: requests for information regarding notifications of events that occur or in social networks or operator services that has to do with the user. They are originated by external entities and the communication begins on the server ending with the client. It can involve the user in two ways: direct mode, the event is related to him; We speak indirectly when the person involved is a friend of the user's agenda.
  • These "push" requests inform about what is happening in the user's social networks, through real-time notifications, preferably using the SMS system that connects to the Short Message Service Center (SMSC) by sending an SMS with the notification to the service module SMNS -figure 6 (1) -.
  • SMSSC Short Message Service Center
  • other systems can be used to send push requests.
  • a notification system developed specifically by the operator to perform this task or a two-way communication system between the mobile device and the platform module using TCP-IP technology.
  • the method of the present invention comprises performing one or more of the following functions:
  • the present invention has as an additional object a management system of SOCIAL NOTIFICATIONS FOR MOBILE DEVICES comprising at least the following modules, shown in Figure 3:
  • the basis of the invention of the SMNS platform module rests on the concept of social aggregator that gathers and integrates all the social information of the user made from any source.
  • This aggregator platform is in charge of channeling the social information from the internet to the mobile network by integrating it with the user information extracted from the mobile operator network.
  • the platform module also integrates connectors with other operator services - Figure 4 (5) -.
  • REST module http interface integrated in a web server that allows access to the functions of the aggregator and is used by the SMNS service module. Using a REST syntax facilitates the identification of the source that wants to be used.
  • Internal services module The REST layer is only used as a wrapper, this module manages the internal services.
  • a service includes one or more functionalities grouped by subject.
  • Asynchronous queues module composed of asynchronous queues used to communicate with the connector modules that send and receive information from external networks.
  • Demon processing module demons that run periodically and are responsible for importing user data that has been created or updated on external networks. It is also responsible for alerting the notification server of status changes so that they can be sent in real time to the SMNS service module.
  • Notification module This is done by connecting to the Short Message Service Center (SMSC) deployed in the operator's network to send the notifications received by the demons using the SMNS service.
  • SMSC Short Message Service Center
  • Connection module with external social networks and operator services, which in turn is composed of: o
  • a REST SN connector module REST interface used for social networks to send their information to the SMNS aggregator platform.
  • An AD HOC connector module processes that connect to external networks. When they receive a signal in the form of an asynchronous message, it is sent to the platform through the queue module.
  • An operator connector module module that connects with operator services to extract social information from them.
  • Data access module common interface between the operator connector module and an access layer database.
  • SMNS Service Module - Figure 4 (1) - is integrated into the operating system layer of the mobile device.
  • the main objectives of these services are: to allow the application layer, which is located above the OS layer - Figure 4 (1) -, the information query, update and registration of social events together with the access to the contact list added.
  • the connection of the SMNS service with its platform is completely transparent to the application layers above. For this reason they will not notice its existence nor will specific modules be implemented for its management.
  • the service will behave as another operating system resource (such as access to the phonebook or access to the SMS container).
  • the module is in turn made up of the following modules -figure 8-:
  • API management module includes a public interface definition so that social clients that are deployed in the application layer (application environment, AE) can use all the functionalities.
  • the basic orders will consist mainly of updating and deleting user social events. They will also include orders for handling the user's contacts calendar.
  • the technical characteristics of this module will depend on the development platforms that are integrated in the mobile phone. The set of functionalities they offer is described in Figure 9.
  • Notifications module The module will receive real-time social notifications. This will avoid the need for social customers to have to update the information in the platform module from time to time. The process is performed using an internal application registration service deployed in the SMNS service module, so that the application will be enabled at the time the notification occurs. Previously, to perform this functionality, it must be mapped in the mobile operating system that all SMS coming from the platform are routed to the SMNS service module so that it is responsible for managing them.
  • the notification module is responsible for notifying all registered applications through the API management module.
  • Internal services module module that manages the logic of social requests through the API management module. Handles requests and analyzes which data source (temporary database or SMNS platform) carries out the order. It is also responsible for the negotiation of social data between the social clients deployed on the mobile.
  • SMNS platform connector module module used to contact the SMNS platform using an http client.
  • Data access module common interface between the operator connector module and an access layer database.
  • Temporary database stores the most up-to-date social information to limit the number of requests to the platform. This database could be implemented in the operating system memory and therefore outside the service module if the manufacturer's implementation requires it.
  • the invention has the following advantages with respect to prior art: a. A new standardized component will be available on mobile phones that will provide social information of the user of the mobile device. b. Upon integration of the applications with the social service within the mobile terminal, security is increased, since only those applications that the user has installed and given them express permission to access the SMNS service could access the data.
  • Mobile social applications have a faster response, since recent events are stored in the mobile terminal, without the need for external servers.
  • Real-time notification services such as SMS or call services.
  • g. It includes a social aggregation system based on an open protocol that allows any social network on the Internet to integrate with the platform. In this way, the aggregator can be included immediately without having to change its architecture.
  • the user can access all their social information in a simple way. You will have a global vision of all your social activity and a more immediate relationship with the virtual identities of your acquaintances.
  • the invention can contribute to current WCO standards.
  • the main objective of the invention is then to generate a standard service shared by all mobile devices.
  • Each manufacturer should implement in the operating systems of their devices a module that conforms to the requirements of the communication standards (SMNS protocol), to the aggregator platform (SMNS platform module) and to the battery of rules previously defined for customers of mobile.
  • SMNS protocol the requirements of the communication standards
  • SMNS platform module the aggregator platform
  • SMNS platform module the battery of rules previously defined for customers of mobile.
  • mobile social client developers will be given a generic API to watch and modify social activities.
  • With the integration of the SMNS service module we managed to reduce the standardization problems that the developers of these services had until now.
  • the fact that the The same module with the same API is implemented in any operating system will make the migration of clients from one terminal to another much simpler.
  • This standardization also affects the communication of social clients using the SMNS service since now social clients can exchange information even if they have been developed by different companies.
  • SMS are real-time notifications made from personal events and is a service integrated into the operating system. Thanks to that, third parties can develop applications that use this messaging system.
  • this invention it is intended to integrate notifications of immediate events between the digital social network and the user.
  • the digital social network can be conceived as a collection of all the people with whom the user is related and of all the people who have a virtual identity.
  • service module and “SMNS service module” have been used interchangeably herein, and similarly for cases of platform module and SMNS platform module and for the case of SMNS protocol and protocol.
  • Figure 1 usual architecture of social aggregators.
  • Figure 2 the architecture of the conventional mobile is represented.
  • Figure 3 represents a global version of this invention.
  • the operating system that should implement the standard SMNS service.
  • the social platform which is deployed in the network operator's architecture.
  • Figure 4 detailed architecture of the SMNS system.
  • Figure 5 shows the detailed description of the architecture of the SMNS platform.
  • Figure 6 shows the detailed description of the architecture of the SMNS service module.
  • Figure 7 Shows in detail the modules that make up the SMNS platform module.
  • Figure 8 Shows in detail the modules that make up the SMNS service module.
  • Figure 9 shows the set of functionalities offered by the API management module.
  • Figure 10 example of a notification of a client registration event.
  • Figure 11 Example of request for information on recent events.
  • Figure 12 example of an insertion of an event in the system.
  • the first example, -figure 10- shows an event notification for any social client installed on a mobile phone.
  • the client will register with the SMNS service that is available in the mobile operating system at the time (1). From that moment, all social events received by the service will be sent to the client.
  • a user named Bob who is included in the list of added friends is performing an activity (2) that is being recorded on the social network. The activity is quickly notified to the aggregation platform available in the operator architecture (3).
  • the SMNS platform searches the list of friends for those who can see the event to send notifications to each of them to their mobile phones (4).
  • Once the client is installed then it will register said service.
  • the SMNS service deployed in the mobile operating service will notify social clients about the events that have arrived (5). Clients will act based on the events received and the specifications implemented. This method of action corresponds to push requests because the server is responsible for notifying new events to mobile phones and customers.
  • Figure 11 describes the process in the case where the client is the one who makes a request for information. This information resides in the mobile's SMNS service. This avoids additional requests to the server and at the same time does not generate traffic on the network. Customers intend to get the latest mobile user events. This operation is called pul ⁇ .
  • Figure 12 shows the case in which the user carries out an activity that has been registered by a social mobile client. This notifies the SMNS service of the OS through a public API call (1). This activity is then inserted in the SMNS platform (2). From this moment on, any social network subscribed to the SMNS platform can access the information of this user (3) (4) (5).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Stored Programmes (AREA)

Abstract

La invención comprende un sistema compuesto por al menos 2 módulos, mostrados en la figura 3. El primero se encuentra en la capa del sistema operativo del dispositivo móvil (módulo de servicio SMNS), y el otro módulo estará desplegado en un servidor el cual pertenece a la arquitectura de operado de red del móvil (módulo de plataforma SMNS). El objetivo principal de la invención consiste en generar un servicio estándar compartido por todos los dispositivos móviles. Con la integración del módulo de servicio SMNS conseguimos reducir los problemas de estandarización que hasta ahora tenían los fabricantes de esta tecnología. El hecho de que el mismo módulo con la misma API esté implementado en cualquier sistema operativo hará mucho más simple la migración de los clientes sociales de un terminal a otro. Esta estandarización también afecta a la comunicación de clientes sociales usando el servicio SMNS ya que desde ahora los clientes sociales (SC) pueden intercambiar información incluso si ellos han sido desarrollados por diferentes compañías de software móvil.

Description

MÉTODO Y SISTEMA DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES
INTRODUCCIÓN
Se presenta la siguiente invención la cual pretende contribuir a los actuales agregadores sociales. El objetivo central es el de conseguir que los servicios sociales sean usados de un modo masivo y que estén perfectamente integrados dentro de las redes sociales que ya existen en internet. Por lo que el objetivo principal de la invención es ofrecer capacidades sociales integradas en dispositivos móviles. ESTADO DE LA TÉCNICA
Durante los últimos tiempos ha habido un importante incremento del uso de las redes sociales por el mundo.
Estos servicios de internet se han convertido en los sitios más visitados y exitosos para millones de usuarios. Este proceso ha tenido lugar a nivel global.
Facebook se ha convertido en la red social favorita en todos los países gracias a su popularidad y su diseño.
Este portal se ha convertido en un referente universal en el mundo de las redes sociales y se ha convertido en la vanguardia de esta nueva tecnología social.
Hay solo 2 o 3 redes sociales que dominan el mercado de cada país. En estos momentos, el esfuerzo que supone estar en una posición privilegiada de mercado con un producto no merece en muchos casos la pena debido a la saturación del mismo. Actualmente hay un hueco limitado en lo que se refiere a nuevas propuestas porque habitualmente los usuarios no manejan más de dos redes sociales al mismo tiempo. Los usuarios son fieles a las redes sociales a las que están conectados porque en ellas ya están sus amigos y parientes. Ésta es la razón por la que el mercado está apuntando hacia los servicios de agregadores sociales. Estos presentan la información que unifican todas las redes sociales a las cuales el usuario está conectado.
En el dominio móvil se han hecho diversos avances pero es aún necesaria algún tipo de evolución si se quiere que sea la experiencia en los móviles, tan satisfactoria como lo es en pc's. Este éxito dependerá de donde son estandarizados los servicios. OMA es la encargada de estandarizar la tecnología móvil, los grupos de trabajo que están relacionado con las redes sociales son:
Grupo de trabajo de mensajeo (OMA) .
Grupo de trabajo de presencia y viabilidad (OMA) .
Grupo de trabajo de localización (LWG) . Los agregadores convencionales de redes sociales permiten al usuario manejar toda su actividad social proveniente de internet usando un único cliente de móvil. Estos tipos de servicios están conectados con las redes sociales más populares para extraer de ellas los eventos sociales. Este proceso se lleva a cabo usando los API's dados por cada red social. No existe un estándar unificado.
Estos servicios están compuestos por 2 partes, el cliente del móvil y la plataforma del servidor. El cliente del móvil -figura 1(1)- consiste; en un software residente o un servicio web a cargo del manejo de la interacción de usuario. Presenta la información y recoge los eventos que ocurren en el teléfono. Para la comunicación de los eventos sociales utiliza el soporte de comunicaciones básico que le ofrece el sistema operativo del teléfono pero debe encargarse el mismo de la gestión de las notificaciones sociales. Esto incluye, el formateo de la información, el mantenimiento de la sesión social, el almacenamiento temporal de la información, el control de la información redundante y las notificaciones instantáneas
Los servicios usan una plataforma servidora -figura 1(2)- la cual está al cargo de las comunicaciones con las redes sociales y con los clientes de móvil. Las comunicaciones no siguen un estándar; en el caso de las redes sociales, éstas usan un interfaz definido por cada red social - figura 1(4)-. En el caso de intercambio de datos entre cliente y plataforma, éste es realizado con un único formato asociado a cada servicio de agregador -figura 1(3)-. La plataforma está al mismo tiempo al cargo del manejo de todas las cuentas asociadas a cada usuario, almacenaje de la información en un archivo temporal y notificación casi inmediata de los cambios o noticias de cada red social a la que el usuario pertenece. Esta condición implica que la comunicación entre agregadores sea imposible. La tecnología empleada para notificar estos eventos es normalmente http. Los clientes inician una comunicación "time-to-time" o "on-demand" para saber si hay actualizaciones. Esto significa que a veces las notificaciones no se realizan inmediatamente sino cuando el usuario las pide.
Las funciones principales que los agregadores ofrecen a los usuarios son:
- Combinar las diferentes cuentas de usuario de cada red social en las que el usuario está inscrito.
Visualizar los eventos de las redes sociales más populares. - Cambiar el estado.
- Visualizar a todos los amigos.
- Contactar con amigos.
- Buscar álbumes de fotos y etiquetarlas.
- Subida instantánea de fotos geolocalizadas .
Muestras de esta arquitectura pueden ser encontradas en el agregador social para móviles KETEKE (red social de telefónica), descripción detallada en NEMOS : Working towards the social mobile, ICME 2009. También una arquitectura similar es empleada por Xumii.com y Jibe . com.
La actual generación de agregadores sociales para móviles está enfrentándose a problemas relacionados con el manejo de la actividad social a través del móvil. Esto es principalmente una consecuencia de la ausencia de estándares de comunicación. Las conexiones con cada red social se realizan de manera diferente -figura 1(4)-. Se hacen usando los interfaces de las redes sociales que son ofrecidos a terceros los cuales son habitualmente empresas que necesitan estos datos. Este hecho supone un problema cuando añadimos nuevos servicios para cada red social. Otro problema de estandarización aparece cuando intentamos comunicar los diferentes agregadores. La actual situación sin un estándar común hace que el producto quede incompleto.
Al no existir una arquitectura unificada que defina un modo de funcionamiento global, las aplicaciones móviles tienen dificultades para recibir notificaciones sociales en tiempo real. Se ven obligados a implementar sus métodos particulares para conocer lo que está sucediendo en la vida social del usuario distribuida entre: las redes sociales y la arquitectura de la red del operador. No pueden registrarse a un módulo que les notifique de lo que está sucediendo y asi descargarse de esta tarea ya que no existe en las implementaciones del sistema operativo del teléfono.
El problema fundamental es que el enfoque que se ha dado a los clientes móviles sociales ha sido únicamente en el nivel de la capa de aplicación del teléfono móvil. Esto implica de nuevo problemas de comunicación, en este caso entre todas aquellas aplicaciones relacionadas con lo social que están desplegadas en un teléfono móvil. Esto se debe a la inexistencia de un módulo específicamente diseñado encargado de gestionar las notificaciones sociales en la capa de sistema operativo y que permita a otras aplicaciones acceder a sus datos. Es significativo que no existe un grupo en OMA que esté exclusivamente destinado a desarrollar una especificación sobre la actividad social para teléfonos móviles. De este modo la capa de aplicación podría tener un apoyo en la capa de sistema operativo para todo lo referente con lo social que ocurra en un teléfono móvil.
En la figura 2(1) se muestra la actual arquitectura disponible en los móviles. Los clientes sociales (SC) utilizan el módulo de comunicaciones del sistema operativo (OS) para relacionarse con su plataforma servidora. No pueden intercambiar datos sociales utilizando un modulo genérico. Se podría dar el caso que lo hicieran directamente sin implicar a la capa del sistema operativo, pero sólo si ambos implementan un complicado sistema de reconocimiento mutuo.
La inexistencia de un módulo específico ni en el sistema operativo ni en la arquitectura de operador de red, capaz de proveer servicios sociales, hace necesaria la implementación de esta plataforma servidora. De otro modo cada empresa que quiera distribuir sus aplicaciones sociales está obligada a invertir un tiempo considerable en el desarrollo de su propia plataforma la cual será solo útil para sus propios clientes. Además, también se incrementaría la cantidad de transacciones lo cual podría derivar en retrasos en las comunicaciones.
La seguridad está también comprometida. No existe un único punto donde la información sea centralizada o manejada por una entidad de confianza como un operador de red .
Las soluciones existentes no son capaces de integrar estas actividades sociales en la vida diaria de los usuarios. Los usuarios realizan varias actividades diariamente que podrían ser fácilmente registradas a través de sus móviles. De este modo podría ser posible mantener una experiencia continua usando los diferentes canales tecnológicos (móvil, ordenador, tv) . Finalmente todos los aspectos de la vida social podrían ser incluidos .
La invención consiste en un dispositivo habilitador (enabler) que permita al usuario de aplicaciones de móvil hacer uso de la totalidad de los datos generados por los eventos sociales del usuario. Este dispositivo habilitador será usado o bien por las aplicaciones de fabricante o bien por las aplicaciones desarrolladas por terceras partes. Esta invención permite integrar un servicio exclusivamente social dentro del sistema operativo de los teléfonos móviles (por ejemplo, agenda de contactos, servicio de email instantáneo) . Este dispositivo habilitador permitirá que toda la actividad social del usuario sea accesible como una fuente de información para las aplicaciones clientes que hagan uso del entorno de aplicaciones en teléfonos móviles. Este enabler se apoya en el dispositivo móvil y en la arquitectura del operador de red. Por lo tanto es necesaria una doble intervención.
DESCRIPCIÓN DE LA INVENCIÓN La presente invención tiene como primer objeto un método de gestión de NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES (SMNS, Social Mobile Notification Service), que comprende las siguientes fases: - disponer al menos un módulo de servicio integrado en el sistema operativo de un dispositivo móvil, dotado de medios de tratamiento, actualización y almacenamiento de notificaciones de eventos sociales,
disponer al menos un módulo de plataforma integrado en un servidor de la arquitectura de un operador de red móvil dotado de medios de almacenamiento, tratamiento y distribución de notificaciones de eventos sociales, establecer una comunicación entre los módulos de plataforma y servicio a través de un protocolo diseñado mediante tecnología http (XML, API REST, Web services) y que es transparente a las capas de aplicación por encima de la capa de sistema operativo,
intercambiar información con las redes sociales mediante un API,
- realizar peticiones de tipo push y pulí, siendo originadas las de tipo push por entidades externas al usuario y las de tipo pulí originadas por el propio usuario siempre que el módulo de servicio desplegado en el dispositivo móvil no contenga una información que sea requerida, gestionar las notificaciones recibidas provenientes de entidades externas,
gestionar las notificaciones de respuesta a las peticiones de tipo pulí y push realizadas.
Además, durante las fases de gestión de las notificaciones recibidas y originadas como respuesta a las peticiones push y pulí y dependiendo del origen del flujo de la comunicación podemos diferenciar varios métodos en los diferentes módulos que componen el sistema objeto de la invención:
1 . Cuando una notificación tiene origen en el módulo de servicio, comprende las siguientes fases en el módulo de plataforma: recibir la notificación en un módulo REST (Representational State Transfer) a través de una petición de tipo pulí,
descomponer la notificación en el módulo REST, encaminar la notificación hacia un módulo de servicios internos que gestiona los servicios internos del módulo de plataforma incluyendo cada uno de ellos al menos una funcionalidad agrupada por materia,
analizar y tratar la notificación en el módulo de servicios internos,
solicitar datos relativos a la notificación a un elemento seleccionado entre,
• una base de datos a la que se accede a través de un módulo de acceso de datos,
• un módulo de conexión que conecta con las redes sociales externas y los servicios de operador, devolver una respuesta a la operación realizada al módulo REST a través del módulo de servicios internos , adaptar la respuesta en el módulo REST a un formato requerido por el módulo de servicio incluido en el dispositivo móvil,
enviar dicha respuesta al módulo de servicio de notificaciones, que comprende recibir notificaciones del modulo de procesado de demonios y las trasmite al módulo de servicio usando un centro de servicios de mensajes cortos (SMSC) , del módulo de servicio mediante el empleo de una petición de tipo push.
2. Cuando la notificación tiene origen en las redes sociales externas y servicios de operador, comprende las siguientes fases en el módulo de plataforma, recibir la notificación por parte de un módulo de conexión,
almacenar dicha notificación en unas colas de un módulo de colas asincronas,
revisar y tratar el contenido de las colas en un módulo de procesado de demonios,
almacenar y actualizar la notificación en un módulo seleccionado entre,
• una base de datos,
• el módulo de servicio a través de un módulo de notificaciones que la envia mediante peticiones de tipo push.
3 . Cuando la notificación tiene origen en los clientes WEB o aplicaciones nativas, comprende las siguientes fases en el módulo de servicio, recibir, descomponer y redirigir la notificación en un módulo de gestión de API (Application Programming Interface) hacia un módulo de servicios internos, que comprende manejar la lógica de las peticiones sociales y la negociación de datos entre los clientes desplegados en el dispositivo móvil y adicionalmente que comprende medios de comprobación de información y actualización de eventos sociales,
tratar la notificación por parte del módulo de servicios internos mediante una opción seleccionada entre :
• el uso de la base de datos temporal,
• el envió de una solicitud al módulo de plataforma a través de un módulo de conectores de plataforma .
4. Cuando las notificaciones tienen origen en el módulo de plataforma, comprende las siguientes fases en el modulo de servicio, - recibir la notificación por parte del módulo de servicio de notificaciones mediante peticiones de tipo push,
gestionar la notificación por parte del modulo de servicio de notificaciones,
- notificar a los clientes previamente registrados a través del módulo de gestión de API,
tratar la notificación mediante la base de datos temporal a través de un módulo de acceso de datos siempre que la información requerida se encuentre en la base de datos o la operación de intercambio de información se dé entre clientes sociales desplegados en el mismo terminal móvil y sólo les involucre a ellos. Además, una vez se han dado todas las fases anteriormente mencionadas para establecer la comunicación, puede darse una fase adicional en la que los clientes sociales que comparten un módulo que pertenece al sistema operativo pueden compartir la información de un modo más directo sin hacer uso del módulo de plataforma. Esto implica una respuesta más corta en tiempo y un uso más optimizado de los recursos de red. Asi pues, haciendo uso únicamente del modulo de servicio se puede llevar a cabo el intercambio de información entre clientes sociales.
La integración del módulo de plataforma mediante un módulo de conexión con las redes sociales se realiza de dos maneras:
• Este módulo de conexión es una implementación de la plataforma la cual está conectada usando los API's que proveen las redes sociales. En este caso, el módulo de plataforma por si mismo está al cargo de realizar las peticiones y se ajusta a los estándares de las redes sociales para extraer la información de carácter social -figura 4(6)-. Normalmente la comunicación con las redes sociales se realiza mediante tecnología http, pero depende de cada caso. Se debería consultar la información detallada de cada API .
Por otro lado, el módulo de plataforma ofrece un API público para que otras redes que no están conectadas usando el método arriba descrito, puedan incluir su información en dicho módulo. El agregador social definirá un API público para intercambiar datos con las redes sociales -figura 4(7)-. Para manejar esta comunicación despliega una serie de servicios web accesibles vía http. Estos servicios web incluyen las primitivas básicas de consultar y actualizar los eventos sociales y la lista de contactos agregada.
Además, cuando el módulo de plataforma realiza la comunicación por medio del API público lo puede hacer mediante servicios web accesibles via http los cuales incluyen funciones básicas de preguntar y actualizar los eventos sociales y el agregador de la lista de contactos. El módulo de plataforma puede también proporcionar servicios de operador de red distintos del servicio de notificaciones sociales. Dichos servicios de operador pueden estar seleccionados entre servicios de localización, servicios de agenda agregada, llamadas y mensajes pero puede haber más como por ejemplo el servicio de presencia.
La comunicación entre los módulos inventados (servicio y plataforma) se realiza a través de un simple protocolo estándar que usa conexiones http -figura 4(3)-. El protocolo incluye peticiones push y pulí -figura 5-.
Peticiones "pulí" consisten en: peticiones de información que son hechas desde el dispositivo móvil al servidor. Son peticiones originadas a nivel de aplicación del móvil, como una respuesta a la actividad del usuario a las redes sociales. Las peticiones "pulí" incluyen información sobre eventos globales sociales, búsqueda de eventos, actualizaciones de eventos y gestión de la lista de contactos agregada. Estas peticiones son solo hechas en aquellos casos en los que el servicio SMNS no contiene la información que se está solicitando.
Peticiones "push" consisten en: peticiones de información relativas a notificaciones de eventos que ocurren o en redes sociales o en servicios de operador que tiene que ver con el usuario. Son originados por entidades externas y la comunicación comienza en el servidor finalizando en el cliente. Puede implicar al usuario de dos maneras: modo directo, el evento está relacionado con él; hablamos de modo indirecto cuando el implicado es un amigo de la agenda del usuario. Estas peticiones "push" informan sobre qué está ocurriendo en las redes sociales del usuario, mediante notificaciones en tiempo real empleando preferentemente el sistema SMS que conecta con el Centro de Servicio de Mensajes Cortos (SMSC) enviando un SMS con la notificación al módulo de servicio SMNS -figura 6(1)-. Sin embargo se pueden usar otros sistemas para el envió de peticiones push. Por ejemplo un sistema de notificación desarrollado ex profeso por el operador para realizar esta tarea o un sistema de comunicación bidireccional entre el dispositivo móvil y el módulo de plataforma mediante tecnología TCP-IP. Según realizaciones particulares adicionales el método de la presente invención comprende realizar una o varias de las siguientes funciones:
registrar una aplicación de cliente para recibir notificaciones,
- insertar un evento social previamente grabado por el cliente social,
actualizar el estado del usuario así como los detalles del perfil,
activar aplicaciones del cliente,
- mandar notificaciones sociales desde el servicio SMNS al cliente social,
mediante un módulo de gestión de API que incluye un interfaz público que hace que aplicaciones de capas por encima usen todas las funcionalidades. La presente invención tiene como un objeto adicional un sistema de gestión de NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES compuesto por al menos los siguientes módulos, mostrados en la figura 3:
Módulo de plataforma SMNS -figura 4(4)- integrado en un servidor el cual pertenece a la arquitectura de un operador de red móvil y que está dotado de medios de almacenamiento, tratamiento y distribución de notificaciones de eventos sociales. Toda esta actividad social nace de la actividad generada dentro de las redes sociales. Puede ser extraída e insertada en la red del operador (localización, contactos de agenda, características de dispositivo...) -figura 4(5)-. También incluye funciones de agregación de contactos donde los perfiles de la gente conocida por el usuario son almacenados en todas las redes sociales. Esta información es extraída de la agenda de contactos del móvil. Toda esta información está disponible para los servicios SMNS -figura 4(2)- por lo que también puede ser accesible para un API Rest público.
Las bases de la invención del módulo de plataforma SMNS recaen sobre el concepto de agregador social que reúne e integra toda la información social del usuario hecha desde cualquier fuente. Esta plataforma de agregador está al cargo de canalizar la información social proveniente de internet a la red móvil integrándolo con la información de usuario extraída de la red de operador móvil.
El módulo de plataforma también integra conectores con otros servicios de operador -figura 4(5)-. Hay plataformas dentro de la red del operador que almacenan información social. Ésta es: localización, agenda agregada, llamadas y mensajes. Así el agregador tiene una mayor información del usuario.
Los módulos que a su vez integran el módulo de plataforma SMNS y que se describen en la figura 7, son:
• Módulo REST: Interfaz http integrado en un servidor web que permite el acceso a las funcionalidades del agregador y que es usado por el módulo de servicio SMNS. Usando una sintaxis REST facilita la identificación de la fuente que quiere ser usada.
• Módulo de servicios internos: La capa REST es sólo empleada como envoltorio, este módulo gestiona los servicios internos. Un servicio incluye una o más funcionalidades agrupadas por materia.
• Módulo de colas asincronas: compuesto de colas asincronas empleadas para comunicarse con los módulos de conectores que envían y reciben información de redes externas.
• Módulo de procesado de demonios: demonios que se ejecutan de forma periódica y son responsables de importar datos de usuario que han sido creados o actualizados en las redes externas. También es responsable de alertar al servidor de notificaciones de los cambios de estado para poder mandarlos en tiempo real al módulo de servicio SMNS.
• Módulo de notificaciones: Lo hace conectando con el Centro de Servicio de Mensajes Cortos (SMSC) desplegado en la red del operador para que envíe las notificaciones recibidas por los demonios usando el servicio SMNS.
• Módulo de conexión: con las redes sociales externas y los servicios de operador, que a su vez está integrado por: o Un módulo de conectores REST SN: Interfaz REST usado para que las redes sociales envíen su información a la plataforma de agregador SMNS. o Un módulo de conectores AD HOC : procesos que conectan a las redes externas. Cuando reciben una señal en forma de mensaje asincrono se envía hasta la plataforma a través del módulo de colas.
o Un módulo de conectores de operador: módulo que conecta con servicios de operador para extraer información social de ellos.
Módulo de acceso de datos: interfaz común entre el módulo de conectores de operador y una base de datos de la capa de acceso.
· Base de datos: almacena los datos de usuario, su identificador , contraseña de las cuentas en las redes sociales y los eventos sociales recogidos de las redes sociales. Módulo de Servicio SMNS -figura 4(1)- está integrado en la capa del sistema operativo del dispositivo móvil. Los objetivos centrales de esos servicios son: permitir a la capa de aplicación, que se encuentra por encima de la capa del SO -figura 4(1)-, la consulta de información, actualización y registro de eventos sociales junto con la el acceso a la lista de contactos agregada. La conexión del servicio SMNS con su plataforma es completamente transparente para las capas de aplicación que están por encima. Por esta razón no notarán su existencia ni se implementarán módulos específicos para su manejo. El servicio se comportará como otro recurso del sistema operativo (como puede ser el acceso a la agenda o el acceso al contenedor de SMS) . El módulo se compone a su vez de los siguientes módulos -figura 8-: Módulo de gestión de API : incluye una definición de interfaz público de modo que los clientes sociales que se despliegan en la capa de aplicación (entorno de aplicación, AE) puedan usar todas las funcionalidades. Las órdenes básicas consistirán principalmente en actualizar y borrar eventos sociales de usuario. Incluirán también órdenes para el manejo de la agenda de contactos del usuario. Las características técnicas de este módulo dependerán de las plataformas de desarrollo que estén integradas en el teléfono móvil. El conjunto de funcionalidades que ofrecen está descrito en la figura 9.
Módulo de notificaciones: El módulo recibirá en tiempo real notificaciones sociales. Esto evitará la necesidad de que los clientes sociales tengan que actualizar cada cierto tiempo la información en el módulo de plataforma. El proceso se realiza usando un servicio interno de registro de aplicaciones desplegado en el modulo de servicio SMNS, de modo que la aplicación será habilitada en el momento que la notificación ocurra. Previamente, para realizar esta funcionalidad, se deberá mapear en el sistema operativo del móvil que todos los SMS provenientes de la plataforma sean encaminados hacia el módulo de servicio SMNS para que él se encargue de gestionarlos. El módulo de notificaciones es el encargado de avisar a todas las aplicaciones registradas a través del módulo de gestión de API. Módulo de servicios internos: módulo que maneja la lógica de las peticiones sociales a través del módulo de gestión de API. Maneja las peticiones y analiza que fuente de datos (base de datos temporal o plataforma SMNS) lleva acabo la orden. También es responsable de la negociación de datos sociales entre los clientes sociales desplegados en el móvil. Módulo de conectores de la plataforma SMNS : módulo usado para contactar con la plataforma SMNS usando un cliente http.
Módulo de acceso de datos: interfaz común entre el módulo de conectores de operador y una base de datos de la capa de acceso.
Base de datos temporal: almacena la información social más actualizada para limitar la cantidad de peticiones a la plataforma. Esta base de datos podría estar implementada en la memoria del sistema operativo y por tanto fuera del módulo de servicio si la implementación del fabricante lo requiriese. invención tiene las siguientes ventajas con respecto estado de la técnica: a. Un nuevo componente estandarizado estará disponible en los móviles que proveerá de información de carácter social del usuario del dispositivo móvil. b. Al realizarse la integración de las aplicaciones con el servicio social dentro del terminal móvil la seguridad se incrementa, ya que sólo podrían acceder a los datos aquellas aplicaciones que el usuario ha instalado y les ha dado un permiso expreso para acceder al servicio SMNS..
c. Esta es una solución estándar que trata de paliar la disgregación responsable del escaso desarrollo del mercado de redes sociales móviles. Existe un único punto de acceso a la información para las aplicaciones sociales móviles.
d. Se reduce el tiempo empleado en el desarrollo de aplicaciones sociales móviles, ya que no tienen que implementar un sistema cliente-servidor complejo para obtener los datos. Para ello disponen de las primitivas que el servidor SMNS les proporciona.
e. Las aplicaciones sociales móviles tienen una respuesta más rápida, ya que los eventos recientes están almacenados en el terminal móvil, sin necesidad de recurrir a servidores externos.
f . Servicios de notificación en tiempo real como los SMS o servicios de llamada.
g. Incluye un sistema de agregación social basado en un protocolo abierto que permite a cualquier red social de Internet integrarse con la plataforma. De este modo se pueden incluir al agregador de una forma inmediata sin tener que cambiar su arquitectura.
h. El usuario puede acceder a toda su información social de una manera sencilla. Tendrá una visión global de toda su actividad social y una relación más inmediata con las identidades virtuales de sus conocidos .
La invención puede contribuir a los actuales estándares de la OMA.
El objetivo principal de la invención consiste entonces, en generar un servicio estándar compartido por todos los dispositivos móviles. Cada fabricante debería implementar en los sistemas operativos de sus dispositivos un módulo que se ajuste a los requerimientos de los estándares de comunicación (protocolo SMNS) , a la plataforma agregadora (módulo de plataforma SMNS) y a la batería de reglas previamente definidas para los clientes de móvil. De este modo a los desarrolladores de clientes sociales móviles se les dará un API genérico donde mirar y modificar actividades sociales. Con la integración del módulo de servicio SMNS conseguimos reducir los problemas de estandarización que hasta ahora tenían los desarrolladores de estos servicios. El hecho de que el mismo módulo con la misma API esté implementado en cualquier sistema operativo hará mucho más simple la migración de los clientes de un terminal a otro. Esta estandarización también afecta a la comunicación de clientes sociales usando el servicio SMNS ya que desde ahora los clientes sociales pueden intercambiar información incluso si ellos han sido desarrollados por diferentes compañías. Una analogía puede ser establecida entre la invención y el servicio de mensajería instantánea de los móviles. Los SMS son notificaciones en tiempo real hechas a partir de eventos personales y es un servicio integrado en el sistema operativo. Gracias a eso, terceras partes pueden desarrollar aplicaciones que usan este sistema de mensajería. Cuando hablamos de esta invención, se pretende integrar notificaciones de eventos inmediatas entre la red social digital y el usuario. De este modo, la red social digital puede ser concebida como una colección de todas las personas con las que el usuario esta relacionado y de todas las personas que tienen una identidad virtual.
Nótese que en la presente memoria se han usado indistintamente los términos módulo de servicio y módulo de servicio SMNS y análogamente para los casos de módulo de plataforma y módulo de plataforma SMNS y para el caso de protocolo y protocolo SMNS. Breve descripción de las figuras
Figura 1: arquitectura habitual de agregadores sociales. Figura 2: se representa la arquitectura del móvil convencional . Figura 3: representa una versión global de esta invención. En la parte superior está el sistema operativo el que debería implementar el servicio estándar SMNS. En la parte inferior está la plataforma social la cual está desplegada en la arquitectura del operador de red.
Figura 4: arquitectura detallada del sistema SMNS.
Figura 5: muestra la descripción detallada de la arquitectura de la plataforma SMNS.
Figura 6: muestra la descripción detallada de la arquitectura del módulo de servicio SMNS.
Figura 7: Muestra en detalle los módulos que componen el módulo de plataforma SMNS.
Figura 8: Muestra en detalle los módulos que componen el módulo de servicio SMNS.
Figura 9: muestra el conjunto de funcionalidades que ofrece el módulo de gestión de API .
Figura 10: ejemplo de una notificación de un evento de registro de un cliente.
Figura 11: ejemplo de petición de información de eventos recientes.
Figura 12: ejemplo de una inserción de un evento en el sistema .
Ejemplos de las funcionalidades principales del método y sistema de notificaciones sociales para dispositivos móviles
El primer ejemplo, -figura 10-, muestra una notificación de evento para cualquier cliente social instalado en un teléfono móvil. Una vez ha sido instalado, el cliente se registrará en el servicio SMNS que esta disponible en el sistema operativo del móvil en el momento (1) . Desde ese instante, todos los eventos sociales recibidos por el servicio serán enviados al cliente. Un usuario llamado Bob que es incluido en la lista de amigos agregados está realizando una actividad (2) que está siendo grabada en la red social. La actividad es rápidamente notificada a la plataforma de agregación disponible en la arquitectura del operador (3) . La plataforma SMNS busca en la lista de amigos a aquellos que pueden ver el evento para mandarles las notificaciones a cada uno de ellos a sus teléfonos móviles (4) . Una vez el cliente está instalado entonces registrará dicho servicio. El servicio SMNS desplegado en el servicio operativo del móvil notificará a los clientes sociales sobre los eventos que hayan llegado (5) . Los clientes actuarán en función de los eventos recibidos y de las especificaciones implementadas . Este método de actuar corresponde con peticiones push porque el servidor es responsable de notificar nuevos eventos a los móviles y a los clientes.
La figura 11 describe el proceso en el caso en que el cliente es quien realiza una petición de información. Esta información reside en el servicio SMNS del móvil. Esto evita peticiones adicionales al servidor y al mismo tiempo no genera tráfico en la red. Los clientes pretenden obtener los últimos eventos del usuario del móvil. Esta operación es llamada pulí. La figura 12 muestra el caso en la que el usuario lleva a cabo una actividad que ha sido registrada por un cliente móvil social. Esto lo notifica al servicio SMNS del SO mediante una llamada API pública (1) . Esta actividad es entonces insertada en la plataforma SMNS (2) . Desde este momento cualquier red social suscrita a la plataforma SMNS puede acceder a la información de este usuario (3) (4) (5) .

Claims

REIVINDICACIONES
1. MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, caracterizado porque comprende las siguientes fases: implementar al menos un módulo de servicio integrado en el sistema operativo de un dispositivo móvil, dotado de medios de tratamiento, actualización y almacenamiento de notificaciones de eventos sociales, implementar al menos un módulo de plataforma integrado en un servidor de la arquitectura de un operador de red móvil dotado de medios de almacenamiento, tratamiento y distribución de notificaciones de eventos sociales,
establecer una comunicación entre los módulos de plataforma y servicio a través de un protocolo diseñado mediante tecnología http y que es transparente a las capas de aplicación por encima de la capa de sistema operativo,
intercambiar información con las redes sociales mediante un API,
realizar peticiones de tipo push y pulí, siendo originadas las de tipo push por entidades externas al usuario y las de tipo pulí originadas por el propio usuario siempre que el módulo de servicio desplegado en el dispositivo móvil no contenga una información que sea requerida,
gestionar las notificaciones recibidas provenientes de entidades externas,
gestionar las notificaciones de respuesta a las peticiones de tipo pulí y push realizadas.
2. MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque en las fases de gestión de las notificaciones recibidas y de respuesta cuando una notificación tiene origen en el módulo de servicio, comprende las siguientes fases en el módulo de plataforma: recibir la notificación en un módulo REST a través de una petición de tipo pulí,
descomponer la notificación en el módulo REST,
- encaminar la notificación hacia un módulo de servicios internos que gestiona los servicios internos del módulo de plataforma incluyendo cada uno de ellos al menos una funcionalidad agrupada por materia,
analizar y tratar la notificación en el módulo de servicios internos,
solicitar datos relativos a la notificación a un elemento seleccionado entre,
• una base de datos a la que se accede a través de un módulo de acceso de datos,
· un módulo de conexión que conecta con las redes sociales externas y los servicios de operador, devolver una respuesta a la operación realizada al módulo REST a través del módulo de servicios internos, adaptar la respuesta en el módulo REST a un formato requerido por el módulo de servicio incluido en el dispositivo móvil,
enviar dicha respuesta al módulo de servicio de notificaciones, que comprende recibir notificaciones del modulo de procesado de demonios y las trasmite al módulo de servicio usando un centro de servicios de mensajes cortos (SMSC) , del módulo de servicio mediante el empleo de una petición de tipo push.
3.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque en las fases de gestión de las notificaciones recibidas y de respuesta cuando la notificación tiene origen en las redes sociales externas y servicios de operador, comprende las siguientes fases en el módulo de plataforma, recibir la notificación por parte de un módulo de conexión,
almacenar dicha notificación en unas colas de un módulo de colas asincronas,
revisar y tratar el contenido de las colas en un módulo de procesado de demonios,
almacenar y actualizar la notificación en un módulo seleccionado entre,
· una base de datos,
• el módulo de servicio a través de un módulo de notificaciones que la envia mediante peticiones de tipo push.
4.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA
DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque en las fases de gestión de las notificaciones recibidas y de respuesta cuando la notificación tiene origen en los clientes WEB o aplicaciones nativas, comprende las siguientes fases en el módulo de servicio, recibir, descomponer y redirigir la notificación en un módulo de gestión de API hacia un módulo de servicios internos, que comprende manejar la lógica de las peticiones sociales y la negociación de datos entre los clientes desplegados en el dispositivo móvil y adicionalmente que comprende medios de comprobación de información y actualización de eventos sociales, tratar la notificación por parte del módulo de servicios internos mediante una opción seleccionada entre :
• el uso de la base de datos temporal,
• el envió de una solicitud al módulo de plataforma a través de un módulo de conectores de plataforma .
5.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque en las fases de gestión de las notificaciones recibidas y de respuesta cuando las notificaciones tienen origen en el módulo de plataforma, comprende las siguientes fases en el modulo de servicio, recibir la notificación por parte del módulo de servicio de notificaciones mediante peticiones de tipo push,
gestionar la notificación por parte del modulo de servicio de notificaciones,
notificar a los clientes previamente registrados a través del módulo de gestión de API,
tratar la notificación mediante la base de datos temporal a través de un módulo de acceso de datos siempre que la información requerida se encuentre en la base de datos o la operación de intercambio de información se dé entre clientes sociales desplegados en el mismo terminal móvil y sólo les involucre a ellos .
6.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque realiza un intercambio de información entre el módulo de plataforma y las redes sociales mediante un módulo de conexión que se conecta con las redes a través de API's seleccionados entre: i. API's provistos por cada una de las redes sociales siendo el módulo de plataforma el que realiza las peticiones de información de carácter social, y i. un API público generado por dicho módulo de plataforma para que cada red social que no se conecte por el método expuesto en i. pueda realizar el intercambio de información con el dispositivo móvil a través del mencionado API público.
7. - MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque las peticiones "pulí" comprenden información sobre eventos globales sociales, búsqueda de eventos, actualizaciones de eventos, información sobre la fuente que los ha originado y tratamiento de la lista de contactos agregada.
8. - MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque las peticiones "push" comprenden información de qué está ocurriendo en las redes sociales del usuario, mediante notificaciones en tiempo real empleando un sistema seleccionado entre:
sistema SMS que conecta con el Centro de Servicio de
Mensajes Cortos, SMSC, enviando un SMS con la notificación al módulo de servicio,
- sistema de notificación desarrollado ex profeso por el operador para realizar esta tarea,
sistema de comunicación bidireccional entre el dispositivo móvil y el módulo de plataforma mediante tecnología TCP-IP.
9.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque el módulo de servicio de notificaciones como fase previa a la recepción de notificaciones, mapea el sistema operativo del dispositivo móvil haciendo que todos los SMS provenientes del módulo de plataforma sean encaminados hacia el módulo de servicio para que él se encargue de gestionarlos y adicionalmente se encarga de avisar a todas las aplicaciones registradas a través de un módulo de gestión de API.
10. - METODO DE GESTION DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque el módulo de plataforma proporciona servicios de operador de red distintos del servicio de notificaciones sociales.
11. - MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 10, caracterizado porque dichos servicios de operador están seleccionados entre servicios de localización, servicios de agenda agregada, llamadas y mensajes.
12.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA
DISPOSITIVOS MÓVILES, según la reivindicación 1, caracterizado porque el módulo de gestión de API comprende realizar una o varias de las siguientes funciones : registrar una aplicación de cliente para recibir notificaciones,
insertar un evento social previamente grabado por un cliente social, actualizar el estado de un usuario asi como los detalles de su perfil,
activar aplicaciones de un cliente,
enviar notificaciones sociales desde el módulo de servicio al cliente social,
13.- MÉTODO DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, en el que una vez se han llevado a cabo las fases descritas en la reivindicación 1, comprende una fase adicional en la que se establece un intercambio de información entre unos clientes sociales que comparten el módulo de servicio que pertenece al sistema operativo, sin hacer uso del módulo de plataforma .
14.- SISTEMA DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES caracterizado porque comprende al menos los siguientes módulos: un módulo de servicio, integrado en el sistema operativo de un dispositivo móvil, dotado de medios de tratamiento, actualización y almacenamiento de notificaciones de eventos sociales, y a través del que los clientes sociales desplegados en la capa de aplicación por encima de la capa del SO tienen acceso a dicha información, un módulo de plataforma, integrado en un servidor de la arquitectura de un operador de red móvil dotado de medios de almacenamiento, tratamiento y distribución de notificaciones de eventos sociales.
15.- SISTEMA DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 14, caracterizado porque el módulo de plataforma comprende al menos los siguientes módulos: un módulo REST, que comprende hacer accesibles las funcionalidades del módulo de plataforma,
un módulo de servicios internos, que comprende gestionar los servicios internos,
un módulo de colas asincronas, que comprende comunicarse con un módulo de conexión que envia y recibe información de las diferentes redes sociales externas y que comprende medios de distribución de la actividad social de usuario,
un módulo de procesado de demonios, que comprende importar información de usuario que ha sido creada en las redes sociales externas asi como alertar al servidor de notificaciones sobre cambios de estado a el módulo de servicio para su envió en tiempo real,
un módulo de notificaciones, que comprende recibir notificaciones del módulo de procesado de demonios y las trasmite al módulo de servicio mediante un centro de servicios de mensajes cortos (SMSC) .
un módulo de conexión, con las redes sociales externas y los servicios de operador,
un módulo de acceso de datos que es la base de datos de la capa de acceso,
una base de datos, que almacena los datos de usuario, su identificador, contraseña de las cuentas en las redes sociales y los eventos sociales recogidos de las redes sociales.
16.- SISTEMA DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 14, caracterizado porque el módulo de servicio comprende al menos los siguientes módulos: un módulo de gestión de API, comprende un interfaz público al que acceden los clientes sociales para usar todas las funcionalidades del sistema.
un módulo de servicio de notificaciones, que comprende recibir notificaciones en tiempo real usando un servicio interno que incluye un registro de aplicaciones .
un módulo de servicios internos, que comprende gestionar la lógica de las peticiones sociales a través del módulo de gestión de API y la negociación de datos entre los clientes desplegados en el dispositivo móvil un módulo de conectores de plataforma, que contacta con el módulo de plataforma mediante una aplicación informática (cliente) http.
un módulo de acceso de datos que es la base de datos de la capa de acceso.
una base de datos temporal, que almacena la información social más actual limitando la cantidad de peticiones a la plataforma y que comprende medios para el registro de eventos sociales.
17.- SISTEMA DE GESTIÓN DE NOTIFICACIONES SOCIALES PARA DISPOSITIVOS MÓVILES, según la reivindicación 15, caracterizado porque el módulo de conexión consta a su vez de los siguientes módulos: un módulo de conectores REST SN, que comprende enviar información desde las redes sociales al módulo de plataforma.
un módulo de conectores AD HOC, que comprende enviar mensajes asincronos desde el módulo de colas asincronas hasta el módulo de plataforma. un módulo de conectores de operador, que comprende realizar una conexión con un operador de servicios para extraer la información social de él.
PCT/ES2009/070597 2009-12-17 2009-12-17 Método y sistema de gestión de notificaciones sociales para dispositivos móviles WO2011073462A1 (es)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN2009801633155A CN102741836A (zh) 2009-12-17 2009-12-17 用于管理移动设备的社交通知的方法和系统
US13/516,360 US20130173734A1 (en) 2009-12-17 2009-12-17 Method and system for managing social notifications for mobile devices
MX2012006975A MX2012006975A (es) 2009-12-17 2009-12-17 Metodo y sistema de gestion de notificaciones sociales para dispositivos moviles.
BR112012014914A BR112012014914A2 (pt) 2009-12-17 2009-12-17 método e sistema de gerenciamento de notificações sociais para dispositivos móveis.
PCT/ES2009/070597 WO2011073462A1 (es) 2009-12-17 2009-12-17 Método y sistema de gestión de notificaciones sociales para dispositivos móviles
EP09852214A EP2515243A1 (en) 2009-12-17 2009-12-17 Method and system for managing social notifications for mobile devices

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2009/070597 WO2011073462A1 (es) 2009-12-17 2009-12-17 Método y sistema de gestión de notificaciones sociales para dispositivos móviles

Publications (1)

Publication Number Publication Date
WO2011073462A1 true WO2011073462A1 (es) 2011-06-23

Family

ID=44166777

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2009/070597 WO2011073462A1 (es) 2009-12-17 2009-12-17 Método y sistema de gestión de notificaciones sociales para dispositivos móviles

Country Status (6)

Country Link
US (1) US20130173734A1 (es)
EP (1) EP2515243A1 (es)
CN (1) CN102741836A (es)
BR (1) BR112012014914A2 (es)
MX (1) MX2012006975A (es)
WO (1) WO2011073462A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160014227A1 (en) * 2012-04-20 2016-01-14 Facebook, Inc. Personalizing an application with content from a social networking system

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9619834B2 (en) * 2010-11-22 2017-04-11 Dell Products L.P. Social commerce relationship management system
US20120150971A1 (en) * 2010-12-13 2012-06-14 Microsoft Corporation Presenting notifications of content items shared by social network contacts
US9153000B2 (en) * 2010-12-13 2015-10-06 Microsoft Technology Licensing, Llc Presenting content items shared within social networks
US20130117374A1 (en) * 2011-11-07 2013-05-09 Dms Network Llc Social Network with Blocked Network Users and Accessible Network Users
US20130290879A1 (en) * 2012-04-30 2013-10-31 Research In Motion Tat Ab Displaying notification messages and messages on a portable electronic device
US9426209B2 (en) * 2012-11-12 2016-08-23 Sap Se Upload/download of mobile applications using a MIME repository
US9009354B2 (en) * 2012-12-20 2015-04-14 Sap Se Services and management layer for diverse data connections
KR20220018629A (ko) * 2016-11-03 2022-02-15 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 네트워크-기반 다운로드/스트리밍 개념
US10698715B2 (en) * 2017-06-07 2020-06-30 Amzetta Technologies, Llc Alert mechanism for VDI system based on social networks

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7584244B2 (en) * 2004-06-04 2009-09-01 Nokia Corporation System, method and computer program product for providing content to a terminal
GB0615840D0 (en) * 2006-08-09 2006-09-20 Intuwave Ltd Mobile Telephone Programmed With Message Logging Capability
US7693953B2 (en) * 2007-01-12 2010-04-06 Microsoft Corporation Providing Web services for wireless communication devices
US8364123B2 (en) * 2009-02-25 2013-01-29 Apple Inc. Managing notification messages
US8135392B2 (en) * 2008-06-06 2012-03-13 Apple Inc. Managing notification service connections and displaying icon badges
US8670748B2 (en) * 2009-05-01 2014-03-11 Apple Inc. Remotely locating and commanding a mobile device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SIMO J.R. ET AL: "NEMOS: TOWARDS THE "SOCIAL" MOBILE PHONE..", IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA AND EXPO, 2009. ICME 2009, 28 June 2009 (2009-06-28) - 3 July 2009 (2009-07-03), pages 1784 - 1788, XP002629268 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160014227A1 (en) * 2012-04-20 2016-01-14 Facebook, Inc. Personalizing an application with content from a social networking system

Also Published As

Publication number Publication date
EP2515243A1 (en) 2012-10-24
US20130173734A1 (en) 2013-07-04
CN102741836A (zh) 2012-10-17
MX2012006975A (es) 2013-05-30
BR112012014914A2 (pt) 2017-03-01

Similar Documents

Publication Publication Date Title
WO2011073462A1 (es) Método y sistema de gestión de notificaciones sociales para dispositivos móviles
FI117586B (fi) Menetelmä SIM-toiminteen järjestämiseksi digitaaliseen langattomaan päätelaitteeseen sekä vastaava päätelaite ja palvelin
CN102027764B (zh) 使用订户身份访问网络服务的方法、系统、和装置
US9154524B2 (en) System and method for exchanging cryptographic protocol capabilities
WO2017152492A1 (zh) 实现多个终端共享用户身份识别卡的方法和装置、存储介质
EP1207707A1 (en) Transmission of carry-on objects using a wireless ad-hoc networking environment
KR20210030266A (ko) 서비스 가입자의 프라이버시를 위한 데이터 익명화
CN106031119B (zh) 一种安全域管理方法、装置及系统
CN106416208A (zh) 通过主机使用客户端接听呼叫
AU2012352157A1 (en) Integrated mobile trusted service manager
CN102415067A (zh) 用于基于内容的呈现服务的订购管理
CN102334316A (zh) 在通信装置之间创建虚拟关系以发布个人数据的方法和配置
ES2310123A1 (es) Acceso remoto desde una extension de un navegador web a la informacion de un terminal movil.
FR3087988A1 (fr) Gestion de profils d'abonne simultanement actifs dans une carte euicc en utilisant plusieurs liaisons distinctes
US11558320B2 (en) Method and system for providing interoperability for rich communication suite (RCS) messaging with local and remote applications
US20130166322A1 (en) Systems and methods for communicating information
Silva et al. eSIM suitability for 5G and B5G enabled IoT verticals
Ajami et al. Privacy issues in mobile social networks
EP2701371B1 (en) Constructing a Contact Sharing History
ES2902350T3 (es) Procedimiento de gestión de perfiles de suscripción, servidor de gestión de suscripciones y UICC
US10798047B2 (en) Systems, devices and methods for text message communication
KR20080005882A (ko) 사용자 의료 기록을 공유하기 위한 방법 및 시스템
US10231116B2 (en) Communication access services for mobile phones
EP2661107B1 (en) Telecommuncations system and method
Fressancourt et al. NFCSocial: Social networking in mobility through IMS and NFC

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980163315.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09852214

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012001615

Country of ref document: CL

Ref document number: 000837-2012

Country of ref document: PE

Ref document number: MX/A/2012/006975

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009852214

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13516360

Country of ref document: US

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112012014914

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112012014914

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20120618