ES2264554T3 - Metodo de control de entrega completa de un servicio, con gestion de un identificador opaco de usuario, utilizando un conjunto de servidores. - Google Patents
Metodo de control de entrega completa de un servicio, con gestion de un identificador opaco de usuario, utilizando un conjunto de servidores.Info
- Publication number
- ES2264554T3 ES2264554T3 ES04290596T ES04290596T ES2264554T3 ES 2264554 T3 ES2264554 T3 ES 2264554T3 ES 04290596 T ES04290596 T ES 04290596T ES 04290596 T ES04290596 T ES 04290596T ES 2264554 T3 ES2264554 T3 ES 2264554T3
- Authority
- ES
- Spain
- Prior art keywords
- transaction
- server
- service
- gidt
- identifier
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 94
- 238000007726 management method Methods 0.000 title claims description 25
- 238000004891 communication Methods 0.000 claims description 26
- 238000004458 analytical method Methods 0.000 claims description 13
- 238000011161 development Methods 0.000 claims description 11
- 238000013475 authorization Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 7
- 230000004044 response Effects 0.000 claims description 4
- 238000012360 testing method Methods 0.000 claims description 4
- 239000004248 saffron Substances 0.000 claims 1
- 230000008569 process Effects 0.000 description 8
- 102100021164 Vasodilator-stimulated phosphoprotein Human genes 0.000 description 6
- 108010054220 vasodilator-stimulated phosphoprotein Proteins 0.000 description 6
- 238000001341 grazing-angle X-ray diffraction Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 241000282836 Camelus dromedarius Species 0.000 description 2
- 230000000873 masking effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
- G06Q20/145—Payments according to the detected use or quantity
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/49—Connection to several service providers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/53—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP using mediation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/68—Payment of value-added services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/0172—Mediation, i.e. device or program to reformat CDRS from one or more switches in order to adapt to one or more billing programs formats
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/0196—Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/20—Technology dependant metering
- H04M2215/2026—Wireless network, e.g. GSM, PCS, TACS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/28—SMS billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/32—Involving wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/46—Connection to several service providers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Finance (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Debugging And Monitoring (AREA)
- Supports Or Holders For Household Use (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
Abstract
Método para control de la entrega completa de un servicio con gestión de un identificador opaco de usuario, utilizando al menos un servidor (31), caracterizado porque se realiza a través de un medio servidor de identificador de transacciones (GIDT) que almacena en una memoria (25) para cada usuario una descripción de una pluralidad de ofertas de servicio suscritas por el usuario con proveedores de servicios de valor añadido (33), incluyendo dicho medio servidor de identificador de transacciones (GIDT) un módulo de gestión (27) que permite asociar a un usuario o grupo de usuarios, y al menos a un servicio determinado, un identificador de transacciones opaco (trid), incluyendo dicho procedimiento las siguientes etapas: - emisión, mediante un servidor (31) que ha interceptado una petición de servicio enviada por un usuario o por uno de dichos proveedores de servicio (33), de una petición de apertura de transacción (1) de, al menos, un servicio que invoca al menos a un servidor determinado (31)que realiza una serie de sub-transacciones (R¿), estando descrita dicha petición (1) de forma secuencial con un lote de primitivas abiertas y dirigida a un interfaz de comunicaciones (21, 23) del medio servidor de identificador de transacciones (GIDT) y que notifica una identificación de usuario (UserID), - análisis (1¿) de la petición y generación de un identificador de transacciones opaco (trid) a través de los medios de gestión y de control (26, 27) del servidor de identificación de transacciones (GIDT), seguida de - una etapa de realización (R) de la transacción, utilizando el identificador de transacciones opaco (trid).
Description
Método de control de entrega completa de un
servicio, con gestión de un identificador opaco de usuario,
utilizando un conjunto de servidores.
La presente invención se circunscribe al ámbito
de las telecomunicaciones y la gestión de los servicios multimedia.
La presente invención se refiere más específicamente a un
procedimiento que permite controlar la entrega completa de un
servicio suministrado a través de un conjunto de servidores
"enablers" y la gestión de un identificador opaco de
usuario.
En los párrafos siguientes, se denominará
"enabler" o "service enabler" a cualquier elemento
servidor capaz de entregar un servicio. A continuación se facilitan
las definiciones de los términos técnicos de origen inglés
utilizados en los siguientes párrafos:
- -
- Commit: acción ejecutada sobre una transacción, que permite hacer pasar su estado al de definitivamente validado.
- -
- Rollback: acción ejecutada sobre una transacción fracasada, que permite notificar el abandono de la transacción en curso y volver a poner el sistema a su estado inicial.
- -
- Begin: acción que señala el inicio de una transacción.
- -
- TimeOut: fin del período de espera.
- -
- Mask: enmascarar
- -
- Unmask: desenmascarar
- -
- Start: iniciar
- -
- Completed: notificación de realización satisfactoria
- -
- Error: notificación de error.
- -
- Update: Actualización
- -
- Open Transaction: apertura de la transacción
- -
- Close Transaction: cierre de la transacción.
En la técnica anterior son conocidos los
gestores de identificadores (GID) en forma de sistemas informáticos
provistos de interfaces que permiten enmascarar y desenmascarar la
identidad de un usuario con ayuda de un identificador opaco. Estos
gestores GID proporcionan a los sistemas externos un medio de
comunicación con un usuario, sin que, no obstante, le comunique su
identidad. Los gestores de identificadores GID se implementan
debido a las limitaciones legales que tratan de garantizar la
confidencialidad de determinadas informaciones. Sin embargo, los
GID no están siempre adaptados para gestionar las nociones de sesión
o de transacción vinculadas simultáneamente a un servicio y a un
usuario o grupo de usuarios dado.
También se conocen los gestores de diálogo (GD)
formados por un sistema informático imbricado en un sistema de
gestión de la facturación de servicios. Los gestores de diálogo GD
garantizan por una parte el diálogo con el usuario para informar a
este del precio de un servicio y obtener su confirmación, y por
otra parte, el inicio de la facturación una vez finalizado un
servicio. El gestor de diálogo GD está orientado exclusivamente a
los problemas de facturación y las implementaciones de un gestor GD
dependen tecnológicamente del elemento servidor capaz de crear y de
suministrar los servicios, o "enabler".
También existen gestores de ofertas (GO) que
sirven para verificar el desarrollo adecuado de la oferta de
servicio. La mayor parte de los GO dependen tecnológicamente del
elemento servidor capaz de crear y de suministrar los servicios, o
"enabler". Por lo tanto, y con frecuencia, son "servidores
mono-elemento", es decir,
mono-petición. Por lo tanto, no son capaces de
procesar de principio a fin el desarrollo de un servicio
"multi-elementos servidores".
Por otra parte, también se conocen las
plataformas de software denominadas "frameworks" para el
desarrollo de servicios, que en general facilitan a los
beneficiarios del servicio un acceso controlado a los recursos de
la red del operador. Estos beneficiarios del servicio pueden ser
proveedores de servicios de valor añadido (VASP, o Value Added
Service Provider). Las plataformas OSA (Open Service Architecture) o
PARLAY constituyen ejemplos de este tipo de plataformas
"framework". La norma OSA permite de este modo definir un
interfaz con una red de radiotelefonía móvil que ofrezca
prestaciones estándar. PARLAY es comparable a OSA, pero para la red
de telefonía fija. Estas plataformas de desarrollo de servicios
funcionan:
- -
- Bien en modo proxy, lo que implica una integración técnica de la plataforma de software "framework" para los socios proveedores de servicios de valor añadido VASP y por otra parte, una actualización de la plataforma de software "framework" para integrar en ella nuevos elementos servidores "enablers" capaces de crear y suministrar servicios o simplemente nuevos interfaces sobre elementos servidores capaces de crear y suministrar unos servicios "existentes",
- -
- Bien en modo directorio, o "directory", lo que implica que una vez que se ha asignado la referencia al elemento servidor capaz de crear y de suministrar servicios o "enabler" por la plataforma de software "framework", deja de pasar por este cualquier información estadística.
De este modo se conoce, mediante el documento WO
02/102016, un sistema de acceso a servicios a través de la red
Internet, que permite entregar autorizaciones para un tipo de
servicios determinado, así como suministrar al terminal de usuario
unos servicios a través de uno o varios servidores específicos.
Este tipo de sistema permite evitar al usuario su autentificación
con cada servidor específico, pero difícilmente permite la
actualización de nuevos servicios accesibles, ni tener en cuenta las
nuevas necesidades del usuario.
Por lo tanto, no existe actualmente ninguna
solución susceptible de poder garantizar la gestión de una sesión
de servicio a un abonado que utiliza diversos elementos servidores,
o "enablers" de la red del operador de telecomunicaciones. Por
lo tanto, no es posible generar eventos relativos a la realización
completada (o no completada) del servicio.
Uno de los objetos de la presente invención
consiste en eliminar dichos inconvenientes de la técnica anterior.
De este modo, la invención descrita en este documento facilita una
solución que permite abordar los siguientes problemas:
- -
- Garantizar la debida entrega de un servicio que utiliza los elementos servidores o "enablers" de una red de un operador,
- -
- Garantizar la QoS (Calidad del Servicio) de principio a fin,
- -
- El control del acceso a los elementos servidores "enablers" para un usuario y servicio dados,
- -
- La obtención de las informaciones estadísticas relativas a la utilización y la realización de un servicio, tanto en modo Pull/MO (Mobile Originated) procedente de una petición del móvil como en modo Push/MT (Mobile Terminated) procedente de una petición de un elemento servidor destinada a un móvil,
- -
- La gestión de los identificadores opacos que permite al operador garantizar la confidencialidad del usuario frente a los proveedores de servicios.
A estos efectos, la invención se refiere a un
procedimiento de control, con gestión de un identificador opaco de
usuario, de la entrega completada de un servicio que utiliza al
menos un servidor, caracterizado porque se realiza a través de un
servidor de identificador de transacciones que almacena en una
memoria, para cada usuario, una descripción de una pluralidad de
ofertas de servicio a las que está suscrito el usuario con diversos
proveedores de servicios, incluyendo dicho servidor de identificador
de transacciones un módulo de gestión que permite asociar a un
usuario o grupo de usuarios y al menos a un servicio determinado un
identificador de transacciones opaco, incluyendo dicho procedimiento
las siguientes etapas:
- -
- Emisión a través de un elemento servidor "enabler" que haya interceptado una petición de servicio procedente de un usuario o a través de uno de dichos proveedores de servicios de una petición de apertura de transacción de al memos un servicio que efectúa un llamamiento al menos a un elemento servidor "enabler" determinado realizando unas sub-transacciones, describiéndose dicha petición de forma secuencial mediante un lote de primitivas abiertas, y dirigida a un interfaz de comunicaciones del medio servidor de identificador de transacciones y notificando una identificación del usuario,
- -
- Análisis de la petición y generación de un identificador de transacciones opaco mediante unos medios de gestión y de control del servidor de identificación de transacciones, seguido de
- -
- Una etapa de realización de la transacción, utilizando el identificador de transacciones opaco.
Por lo tanto, la invención permite acceder a la
oferta de un servicio, garantizando en cualquier caso la
confidencialidad del usuario frente a los proveedores del servicio,
mediante la utilización de un identificador opaco de sesión para un
usuario autorizado.
De acuerdo con otra particularidad de la
invención, la etapa de análisis incluye una verificación, efectuada
por el módulo de gestión, de la correspondencia de los elementos
servidores "enablers" determinados con una oferta de servicios
estructurada en directorios a la que puede acceder el usuario entre
la pluralidad de ofertas de servicio y un control de la autorización
de apertura de la transacción mediante unos medios de control del
medio servidor de identificador de transacciones, para el servicio
suministrado por los elementos servidores "enablers" y el
usuario especificado, concretamente en función de la identificación
del usuario.
De acuerdo con otra particularidad de la
invención, la etapa de realización de la transacción se inicia
mediante un proveedor de servicios de valor añadido que ha recibido
el identificador de transacciones opaco por parte del medio
servidor de identificador de transacciones, efectuando el proveedor
de ofertas de servicio una petición a un elemento servidor
"enabler" determinado, que tiene como parámetro el
identificador de transacciones opaco, de un servicio determinado
que constituye una sub-transacción, para iniciar en
respuesta al elemento servidor "enabler" determinado el envío
al servidor de identificación de transacciones una petición de
desenmascaramiento "unmask" que permite, a partir del
identificador opaco, suministrar un número de identificación no
opaco correspondiente al identificador de transacciones opaco
realizándose seguidamente un control mediante los medios de control
del medio servidor de identificador de transacciones, a fin de
verificar si el elemento servidor "enabler" determinado está
autorizado o no para este servicio y para este usuario, de tal forma
que, en caso de autorización, el número de identificación no opaco
(MS-ISDN) se transmite a través de un interfaz de
comunicaciones, denominado interfaz enabler, hacia el elemento
servidor determinado, a fin de permitir la realización de la
sub-transacción.
De acuerdo con otra particularidad de la
invención, el identificador de transacciones está formado por un
máximo de 15 dígitos, y de acuerdo con el plan de numeración
UIT-TE-164 y el número de
identificación no opaco es el número MSISDN (Mobile Station
Integrated Services Digital Network).
De acuerdo con otra particularidad de la
invención, el medio servidor de identificador de transacciones
(GIDT) incluye, por una parte, un motor de transacciones que genera
emisiones de eventos de transacciones formados por cualquiera de
los comandos siguientes: BEGIN, COMMIT, ROLLBACK, y por otra parte,
un motor de trazabilidad, que consigna en dicha memoria cada evento
del motor de transacciones y el conjunto de las informaciones
emitidas durante la utilización del medio servidor de identificación
de transacciones.
De acuerdo con otra particularidad de la
invención, el identificador de transacciones opaco se envía al
proveedor de ofertas de servicio tras la memorización, en la memoria
del medio servidor de identificador de transacciones, de un
contexto de transacciones, que indica, especialmente,
- -
- El número de identificación del usuario,
- -
- El identificador de transacciones,
- -
- La oferta asociada a la transacción,
- -
- El estado de avance de la transacción para la oferta asociada a esta (número de sub-transacciones conseguidas, sub-transacciones que faltan por ejecutar...).
De acuerdo con otra particularidad de la
invención, el envío del identificador de transacciones opaco al
proveedor de ofertas de servicio viene precedido de una generación
de un evento de transacciones que representa el inicio de una
transacción, dirigido al menos hacia un sistema externo, a través de
un segundo interfaz de comunicaciones del medio servidor de
identificador de transacciones, denominado interfaz de notificación
de transacciones.
De acuerdo con otra particularidad de la
invención, la generación de un evento de transacciones que
representa el inicio de una transacción dirigido al menos hacia un
sistema externo se efectúa mediante un comando BEGIN generado por
un motor de transacciones del medio servidor de identificador de
transacciones.
De acuerdo con otra particularidad de la
invención, el medio servidor de identificador de transacciones
transmite, desde el interfaz de notificación de transacciones al
menos a un sistema externo unos datos representativos de la
realización completa de la oferta mediante un comando COMMIT
generado por el motor de transacciones para indicar al sistema
externo, por ejemplo, de facturación, que la transacción se ha
realizado por completo.
De acuerdo con otra particularidad de la
invención, el medio servidor de identificador de transacciones
emite, a través del interfaz de notificación de transacciones, un
evento de transacción del tipo cancelación ROLLBACK para notificar
al menos a un sistema externo que se ha sobrepasado el número de
reintentos de la transacción en caso de error, y que la transacción
se ha cancelado para suministrar datos a un gestor de diálogo y
para facturar o no el servicio.
De acuerdo con otra particularidad de la
invención, los medios de gestión y de control del servidor de
identificador de transacciones efectúan el análisis de la petición
de apertura de la transacción, concretamente mediante la resolución
de una correspondencia entre una dirección técnica de servicio
notificada en la petición de apertura de la transacción y una
oferta de servicios estructurada en torno a directorios entre la
pluralidad de descripciones de ofertas de servicio almacenadas en la
memoria del medio servidor de identificador de transacciones.
De acuerdo con otra particularidad de la
invención, la memoria del medio servidor de identificador de
transacciones almacena descripciones de ofertas de servicio
validadas por dichos proveedores, seleccionados a través de un
tercer interfaz de comunicaciones denominado interfaz de suministro
de descripciones de servicio.
De acuerdo con otra particularidad de la
invención, la descripción de una oferta de servicio incluye unos
datos formulados en un metalenguaje o formato equivalente que
permita a los medios de control del medio servidor de identificador
de transacciones controlar el adecuado desarrollo del servicio,
detectando su inicio y su finalización.
De acuerdo con otra particularidad de la
invención, el medio servidor de identificador de transacciones
incluye un interfaz de comunicación suplementario destinado a los
proveedores de servicios de valor añadido, estando destinado el
primer interfaz a los elementos servidores.
De acuerdo con otra particularidad de la
invención, el medio servidor de identificador de transacciones
incluye una lógica interna que realiza los siguientes métodos:
Start, Completed, Error, Mask, Unmask, Update, Open Transaction,
Close Transaction.
De acuerdo con otra particularidad de la
invención, el método Start del medio servidor de identificador de
transacciones genera un identificador de la transacción, crea un
contexto de transacciones en la memoria, genera un evento de
transacciones del tipo BEGIN y devuelve el identificador de
transacciones al proveedor de ofertas de servicio.
De acuerdo con otra particularidad de la
invención, el método Completed del medio servidor de identificador
de transacciones determina mediante una prueba si se ha realizado
una sub-transacción de la transacción, modifica en
consecuencia el contexto de la transacción, determina, escrutando la
descripción de la oferta, si es necesario que el medio servidor de
identificador de transacciones espere un evento exterior, sitúa la
lógica en espera de que transcurra un período determinado
"TimeOut" o en el cierre de la transacción "Close
Transaction", verifica si la transacción se ha llevado a cabo y
genera un evento de transacción del tipo COMMIT.
De acuerdo con otra particularidad de la
invención, el método Error del medio servidor de identificador de
transacciones verifica si se hay sobrepasado el número de reintentos
en caso de error y en caso afirmativo genera un evento de
transacciones de tipo ROLLBACK.
De acuerdo con otra particularidad de la
invención, un elemento servidor "enabler" emite un método Mask
para recuperar las informaciones de la oferta objetivo a partir de
la dirección técnica y de dicha pluralidad de ofertas, así como
para controlar el acceso de un usuario abonado a la oferta de
servicio y emitir una denegación de acceso o iniciar el método
Start.
De acuerdo con otra particularidad de la
invención, un elemento servidor "enabler" emite el método
Unmask para recuperar las informaciones de la oferta objetivo a
partir de los datos representativos de la dirección técnica y el
identificador de la transacción (trid) y, a partir del catálogo de
ofertas, controlar el acceso de un proveedor asociado al elemento
servidor "enabler", verificar que la petición efectuada al
elemento servidor se corresponde con el actual estado de la
transacción y notificar al elemento servidor que medio servidor de
identificador de transacciones está en espera de una actualización,
devolver el MSISDN asociado al identificador de transacciones
opaco, ponerse en espera de actualización y, posteriormente,
verificar si la actualización recibida contiene las informaciones
necesarias para la realización de la oferta, a fin de emitir un
método Completed o un método Error.
De acuerdo con otra particularidad de la
invención, un elemento servidor "enabler" emite un método
Update, constituido por la puesta en estado de espera de
actualización relativo a la realización de la petición del servidor
de identificador de transacciones.
De acuerdo con otra particularidad de la
invención, un proveedor de servicios de valor añadido emite el
método Open Transaction para controlar el acceso de un asociado a un
abonado del operador, y generar una denegación de acceso o iniciar
un método Start.
De acuerdo con otra particularidad de la
invención, un proveedor de servicios de valor añadido emite el
método Close Transaction y genera un evento que permite desbloquear
el tiempo de espera TimeOut de la lógica del medio servidor de
identificador de transacciones.
La invención, junto con sus características y
ventajas, se apreciará más claramente mediante la lectura de la
descripción efectuada haciendo referencia a las figuras adjuntas,
facilitadas a título de ejemplos no limitativos, en las cuales:
- La figura 1 representa
esquemáticamente un ejemplo del proceso implementado en la
invención, en una variante en modo Push/MT.
- La figura 2 representa tres
elementos de lógica utilizados por el medio servidor de
identificador,
- La figura 3 representa unos
esquemas de lógicas de estados asociadas a las interacciones entre
los elementos servidores "enablers" de la red y el medio
servidor de identificador,
- La figura 4 representa unos
esquemas de lógicas de estados asociadas a las interacciones entre
los proveedores de servicio de valor añadido y el medio servidor de
identificador,
- La figura 5 representa
esquemáticamente un ejemplo del proceso implementado en la
invención, en una variante en modo Pull/MO. Además, en el anexo se
indican las abreviaturas utilizadas en la presente petición.
A continuación se va a describir la invención en
relación con las figuras 1 y 2.
El procedimiento de acuerdo con la invención se
realiza a través de un medio servidor de identificador de
transacciones, al que en adelante se denominará gestor de
identificación de transacciones (GIDT). Dicho gestor de
identificación de transacciones (GIDT) permite asociar un elemento
de identificación (UserId) correspondiente a un usuario (o grupo de
usuarios) para una transacción o sub-transacción a
través de un servicio dado. Este identificador de transacciones
(trid) se utiliza sustituyendo el número MS-ISDN
(Mobile Station - Integrated Services Digital Network) en la
comunicación con los proveedores de servicio asociados (33) como
los VASP, proveedores de aplicaciones y portales especializados u
otros asociados, que se caracteriza por estar de acuerdo con la
recomendación de un plan de numeración normalizado, como
UIT-TE 164, lo que implica una secuencia con un
máximo de 15 dígitos, una parte de cuya información puede permitir
identificar al operador susceptible de interpretar dicho
identificador de transacciones (trid). El gestor de identificación
de transacciones (GIDT) incluye un primer interfaz (21) de
comunicaciones para permitir la transmisión de datos con servidores
o enablers (31). Este gestor (GDIT) incluye asimismo un segundo
interfaz (22) de comunicación, denominado interfaz de notificación
de transacciones, que permite la generación de eventos de
transacciones que representan un inicio (ST), una finalización (CT)
o una anulación (ET) de la transacción hacia cualquier sistema
externo (40). Este interfaz (22) permite, por ejemplo, conectar el
gestor (GDIT) a uno o varios sistemas externos (40) de facturación,
y/o a un gestor de diálogo.
Como se muestra en la figura 1, el gestor de
identificación de transacciones (GIDT) incluye un módulo de gestión
(27) que permite asociar a un usuario o grupo de usuarios y al menos
a un servicio determinado un identificador, denominado de
transacciones (trid). El gestor (GDIT) puede, por ejemplo, gestionar
el abono de los usuarios a ofertas de servicio facilitadas por los
proveedores de servicios (33). Como variante, el gestor de
identificación de transacciones (GIDT) puede conectarse también a un
gestor de abonos. La memoria (25) del gestor (GIDT) permite,
concretamente, memorizar unas descripciones de ofertas de servicios
validadas por los proveedores (31) y almacenar una pluralidad de
contextos de transacciones relativos a un usuario o grupo de
usuarios para un servicio. Cada contexto de transacciones indica,
concretamente, el número de identificación (UserID) del usuario, el
identificador de la transacción (trid), la oferta asociada a la
transacción y el estado de realización de la transacción. Dicho
estado de realización puede ser descrito, por ejemplo, mediante el
número de sub-transacciones (R') efectuadas y de
sub-transacciones (R') que faltan por ejecutar. Las
descripciones de ofertas de servicio pueden ser seleccionadas por
un sistema de aprovisionamiento (32) con un tercer interfaz de
comunicaciones, denominado interfaz de suministro de las
descripciones de servicios (IFDS).
Como se representa en la figura 1, el gestor de
identificación de transacciones (GIDT) puede situarse en el núcleo
de una plataforma de software susceptible de:
- -
- Gestionar los identificadores de transacciones (trid),
- -
- Gestionar las informaciones estadísticas relativas a los accesos a las peticiones de desenmascaramiento por parte de los enablers (31) de la red,
- -
- Almacenar una representación del servicio, y más concretamente, su división en secuencias/desarrollo,
- -
- Controlar el desarrollo de un servicio y garantizar de ese modo su realización desde el comienzo hasta el final,
- -
- Emitir unos desencadenadores (triggers) de transacciones, por ejemplo BEGIN (ST) para comenzar, COMMIT (CT) para ejecutar, ROLLBACK (ET) para cancelar (Figura 2).
Para conseguir gestionar los identificadores de
transacciones (trid), el módulo de gestión (27) se encuentra
conectado a la memoria (25) y al interfaz de suministro de las
descripciones de servicio (IFDS). En un modo de realización de la
invención, la memoria (25) del gestor de identificación de
transacciones (GIDT) almacena descripciones de ofertas de servicio
transmitidas por el sistema de aprovisionamiento (32) en
descripciones de servicio utilizadas por el interfaz de suministro
(IFDS). Este sistema de aprovisionamiento (32), al que tienen en
cuenta los proveedores asociados, (33) permite suministrar una
descripción completa de un servicio. En un modo de realización de
la invención, la memoria (25) almacena descripciones que detallan
los servicios, concretamente el modo de comunicación con los
elementos enablers (LOC, SMS, MMS) que forman parte de la oferta.
Esta descripción podría definirse a partir de un metalenguaje,
expresión regular, esquema XML o DTD, por ejemplo, o mediante
cualquier otra forma que permita al gestor de identificación de
transacciones (GIDT) controlar el adecuado desarrollo de un
servicio, detectando su inicio y su finalización. Los proveedores
asociados (33) tienen conocimiento del modo de descripción de su
servicio, de tal forma que una oferta correspondiente a la
descripción esperada, que incluye uno o varios servicios, puede
realizarse efectivamente.
Por ejemplo, en el caso de una oferta de
servicio en la que interviene un enabler de localización (LOC), un
enabler de mensajes cortos (SMS) y un enabler de mensajes multimedia
(MMS), la descripción del servicio podría presentarse en la forma
siguiente: "(SMS_MO, LOC, MMS)", es decir, que el servicio
completo debe estar compuesto por un SMS_MO, por una petición de
localización y por el envío de un mensaje multimedia. En otro
ejemplo, la descripción puede formularse de la forma siguiente:
"(LOC, WAP-PUSH+,
[close-transaction|timeout(2 días)])", lo
que significa que el servicio debe estar compuesto por una petición
de localización, seguida de 1 a N push WAP. La finalización del
servicio se inicia mediante un intervalo de espera denominado
timeout, o bien por una orden de cierre de transacción, denominada
close-transaction explícita de un servidor enabler
(31) o del proveedor del servicio (33).
La descripción de servicio puede también
detallar el contenido de cada petición a un elemento servidor
enabler (31), como por ejemplo "SMS_MO: BLAGUE*, MMS)", lo que
significa que el servicio debe estar formado por un SMS_MO que
comience por BLAGUE y por un mensaje multimedia. En una variante de
realización de la invención, la descripción del servicio puede
incorporar eventualmente sub-partes transaccionales,
susceptibles, por ejemplo, de ser definidas como imbricadas. De
este modo, en el caso de una descripción XML, pueden utilizarse los
mecanismos de importación o de referencia. En este caso, la
realización de un servicio puede estar condicionada por la
realización de cinco sub-partes transaccionales.
Estas últimas se facturan eventualmente por separado a través de un
sistema externo (40) de facturación. Los servidores enablers (LOC,
SMS, MMS) de la figura 1 sólo se citan a título de ejemplo. No
importa qué otro elemento servidor enabler, como CAMEL,
WAP-server, etc. pueda ser utilizado en el proceso
implementado con el gestor de identificación de transacciones
(GIDT).
En un modo de realización de la invención, el
medio servidor de identificador de transacciones (GIDT) incluye un
interfaz de comunicación suplementario (23) destinado a los
proveedores de servicios de valor añadido (33) o equivalente,
estando destinado el primer interfaz (21) a los elementos servidores
(LOC, SMS, MMS) de la red. Este interfaz suplementario (23) permite
a un proveedor asociado (33) abrir una transacción para un usuario
dado sobre un tipo de servicio. Este interfaz (23) sólo es necesario
en el caso de que un proveedor de servicios (33) inicie el servicio
hacia el abonado, es decir, en modo PUSH, como en la forma de
realización de la figura 1, por ejemplo. En el caso de una
descripción de servicio abierta, el proveedor asociado (33) de tipo
VASP o similar puede tener a su disposición un método que le permita
indicar que el servicio, en su opinión, se ha realizado. Por otra
parte, al ser opcional este interfaz suplementario (23), el gestor
(GIDT) constituye, en la mayor parte de las ocasiones, un componente
transparente para los asociados VASP o asociados de un tipo
similar.
A continuación se describirá la invención
haciendo referencia a la figura 2.
La figura 2 presenta tres elementos de lógica de
una lógica interna utilizada por el módulo de gestión (27) para
gestionar con un identificador de transacciones (trid) opaco de
usuario la entrega completa del servicio, de acuerdo con el proceso
de la invención. Entre los tres métodos realizados por esta lógica
interna, el método normalmente denominado START (S) ejecuta
sucesivamente las siguientes transacciones, tras la previa
recuperación (S0) del número de identificación (UserID) MSISDN:
- -
- Generación (S1) de un identificador de transacciones a partir de los datos suministrados, y concretamente, el número MSISDN,
- -
- Creación (S2) de un contexto de transacciones que incluye el número de identificación (UserId) MSISDN, el identificador de transacciones (trid), la oferta asociada a la transacción y el estado de avance de la transacción,
- -
- Almacenamiento del contexto de la transacción en la memoria (25) del gestor (GIDT),
- -
- Generación de un evento de transacción BEGIN (ST) enviado hacia los sistemas externos (40) para notificar el inicio de la transacción, seguido de
- -
- El envío (3) por parte del gestor de identificación de transacciones (GIDT) al proveedor del servicio (31) del identificador de la transacción (trid) correspondiente al servicio.
El método normalmente denominado Completed (C)
del medio servidor de identificador de transacciones (GIDT)
determina mediante una prueba (C1) si una
sub-transacción de la transacción se ha realizado
por completo (C0), y a continuación modifica (C2) en consecuencia el
contexto de la transacción. Además, el método Completed (C)
determina, escrutando la descripción de la oferta (C3) si es
necesario que el medio servidor de identificador de transacciones
(GIDT) espere (C5) un evento exterior, y sitúe la lógica a la
espera de que transcurra un período de tiempo "TimeOut" o se
produzca el cierre de una transacción "CloseTransaction". Por
último, este método permite verificar (C4) si la transacción se ha
concluido, así como generar un evento de transacción de tipo COMMIT
(CT). Se comprende que el elemento de lógica correspondiente al
método COMPLETED (C) permite efectuar un control de la evolución de
la transacción. Pueden realizarse sucesivamente varias
sub-transacciones (R') en el seno de una misma
transacción con este método. En el modo de realización de la figura
2, el método COMPLETED (C) incluye las siguientes transacciones:
- -
- Eventualmente, una prueba de control (C1) de fin de realización (CO) de una sub-transacción (R') y modificación (C2) del estado de realización de la transacción memorizada en el contexto de transacciones integrando en él la sub-transacción (R') realizada.
- -
- Escrutinio de la descripción de la oferta (C3) para determinar si es necesario que el gestor (GIDT) espere un evento exterior,
- -
- En un primer caso, posicionamiento de la lógica en espera (C5) de un evento, efectuándose esta espera cuando se produce un período "TimeOut" o un cierre de transacción "Close Transaction" y en caso contrario, si no se ha esperado ningún evento específico, verificación (C4) del estado de realización de la transacción, seguido de
- -
- La generación de un evento de transacción COMMIT (CT) enviado a los sistemas externos (40) para notificar la finalización de la sub-transacción.
El gestor de identificación de transacciones
(GIDT) puede transmitir, desde el interfaz de notificación de
transacciones (22) hacia cualquier sistema externo (40) datos
representativos de la realización completa de un servicio por el
comando COMMIT (CT) generado por el motor de transacciones (28) para
indicar al sistema externo (40) por ejemplo, de facturación, que la
transacción ha sido completamente realizada. El gestor (GITD)
memoriza igualmente en la memoria (25) esta evolución del contexto
de transacciones. La etapa de verificación (C4) permite,
concretamente, establecer la diferencia entre la finalización de la
última sub-transacción (R') y la finalización de
una sub-transacción (R') intermedia. Por lo tanto,
puede determinarse el estado de realización de la transacción.
La lógica interna del medio servidor de
identificador de transacciones (GIDT) lleva igualmente a cabo un
método comúnmente denominado ERROR (E) que permite detectar e
indicar la presencia de errores con incidencia en el proceso de
acuerdo con la invención. Un código de error (E0) es recibido por
un medio de comparación que verifica el número de reintentos en caso
de error. Se efectúa una comparación (E1) entre el número de
reintentos en caso de error y un umbral predeterminado. Hasta que no
se alcanza dicho umbral, el error es rechazado (E2) y no implica
consecuencia alguna sobre el contexto de la transacción. De lo
contrario, se envía un evento de transacción ROLLBACK (ET) hacia los
sistemas externos (40) para anular el contexto de la transacción.
En un modo de realización de la invención, también se suprime el
identificador de la transacción (trid).
A continuación se describirá la invención
haciendo referencia a las figuras 1, 2 y 3.
El primer interfaz (21) de comunicación permite
inicializar una transacción para un servicio y un usuario dados.
Esta también facilita el acceso a la petición de desenmascaramiento
(5, 10) del identificador de la transacción (trid) iniciada por un
elemento enabler (31). Esta petición (5, 10) permite recuperar en
la mayor parte de las ocasiones el número de identificación (UserID)
constituido, por ejemplo, por el número de MSISDN. También es
posible efectuar una petición (301) de actualización del servicio o
Update, dirigida a este interfaz (21). Como se muestra en la figura
3, la petición (301) de actualización Update puede estar asociada a
la realización específica de la petición enabler (LOC, SMS, MMS)
hasta el usuario abonado a la oferta de servicio, con la finalidad
de garantizar la entrega adecuada del servicio. La petición Update
se asocia igualmente, por ejemplo, al contenido de la información
que transita desde el elemento enabler (31) al abonado, a fin de
permitir la verificación del contenido del servicio.
En un modo de realización de la invención, un
elemento servidor enabler (31) emite el método de actualización
Update. Este está constituido por la puesta en espera de
actualización relativa a la realización del servidor de
identificador de transacciones (GIDT). La actualización puede
realizarse de forma asíncrona a la realización de la petición a un
elemento enabler (31), pero puede condicionar el COMMIT (CT) de
transacciones del conjunto o de una parte de la oferta de servicios.
Por ejemplo, en el caso de un enabler (SMS) de mensajes cortos
pueden utilizarse mensajes asíncronos de notificación de entrega
para asegurarse de que el contenido ha sido entregado al
usuario.
El proceso de acuerdo con la invención puede
funcionar tanto en modo Push/MT como en modo Pull/MO, pudiendo
iniciarse la emisión de una petición de apertura de transacción (1)
de al menos un servicio determinado tanto a través de un usuario
como a través de un proveedor de servicio (33). En el ejemplo de la
figura 1, es el proveedor (33) quien solicita la apertura de una
transacción al gestor (GIDT) por cuenta de un usuario representado
en la petición mediante un identificador (UserID) del tipo número de
teléfono, o cualquier otro identificador del usuario. Esta petición
(1) se dirige en modo Push hacia el primer interfaz de comunicación
(21) del gestor (GIDT). Este último procede entonces al análisis
(1') de la petición (1) a través de unos medios de gestión y
control (26, 27) del gestor (GIDT) a fin de verificar la
correspondencia del servicio objeto de la petición con una oferta
de servicio estructurada en directorios entre la pluralidad de
ofertas de servicios almacenados en memoria (25). Estos medios de
gestión y de control (26, 27) que efectúan el análisis (1'),
concretamente mediante la resolución de una correspondencia entre
una dirección técnica de servicio notificada en la petición (1) de
apertura de la transacción y una oferta de servicio estructurada en
directorios entre la pluralidad de descripciones de ofertas de
servicio almacenadas en la memoria (25) del medio servidor de
identificador (GIDT). En el modo de realización de la figura 1, se
inserta una dirección técnica en la petición de apertura de
transacción (1) para describir el servicio suministrado por el
proveedor (31) en el origen de la petición (1). Esta dirección
técnica es "resuelta" por el gestor (GIDT), y este último
asocia a dicha dirección técnica un identificador de transacción
(trid).
En un modo de realización de la invención, la
etapa de análisis (1) incluye una verificación efectuada por el
módulo de gestión (27) de la correspondencia de los elementos
servidores "enablers" (31) designados en la dirección técnica
con una oferta de servicios estructurada en torno a directorios, a
la que puede acceder el usuario, de entre la pluralidad de ofertas
de servicio, y un control de la autorización de la apertura de la
transacción mediante unos medios de control (26) del medio servidor
de identificador de transacciones (GIDT) para el servicio
suministrado por estos elementos servidores "enablers" (31) y
el usuario especificado en función del identificador de usuario
(UserID). La etapa de realización (R) de la transacción, que
utiliza el identificador de transacción opaco (trid) se produce con
posterioridad a la etapa de análisis (1') de la petición (1).
En el modo de realización de la figura 1, la
petición de apertura de la transacción (1) emitida por el proveedor
de servicio (33) se refiere a un servicio que invoca tres elementos
servidores "enablers" (LOC, SMS, MMS) que realizan
sub-transacciones (R'). Esta petición (1), dirigida
al interfaz de comunicación (23) con los proveedores del gestor de
identificación de transacciones (GIDT) puede ser descrita de forma
secuencial con un lote de primitivas abiertas y notifica una
identificación del usuario (UserID). En otro modo de realización de
la invención, la petición (1) puede referirse al menos a un servicio
que invoca uno o varios elementos servidores "enablers"
(31).
La etapa de realización (R) de la transacción es
iniciada por el proveedor de servicio (33) tras la recepción del
identificador de transacción opaco (trid). El proveedor de servicio
(33) efectúa una petición a un servidor determinado (LOC, SMS, MMS)
de entre los elementos servidores enablers (31), utilizando como
parámetro el identificador de transacciones opaco (trid), de un
servicio determinado que constituye una
sub-transacción (R') como se muestra en la Figura 1.
En respuesta a esta petición, el elemento servidor enabler
determinado (LOC, SMS, MMS) envía hacia el gestor de identificación
de transacciones (GIDT) una petición (5, 10) de desenmascaramiento
"unmask" para autorizar a partir del identificador opaco (trid)
el suministro de un número de identificación (UserID) no opaco
correspondiente al identificador de la transacción opaco (trid). A
continuación, los medios de control (26) del medio servidor de
identificador de transacciones (GITD) llevan a cabo un control (5',
10') para verificar si el elemento servidor determinado
"enabler" (LOC, SMS, MMS) está autorizado o no para este
servicio y para este usuario, de tal forma que en caso de
autorización, el número de identificación (UserID) no opaco se
transmite (7, 12) a través del primer interfaz de comunicación (21)
hacia el elemento servidor determinado (LOC, SMS, MMS) para permitir
la realización de la sub-transacción (R').
En el ejemplo de la figura 1, la primera
sub-transacción (R') se refiere a un servicio de
localización que hace intervenir a un servidor de localización
(LOC). Esta primera sub-transacción (R') comienza
por una petición de localización (4) efectuada por el proveedor del
servicio (33) y dirigida al servidor de localización (LOC) con el
identificador de transacción (trid) como parámetro. Después de haber
recibido el número de identificación (UserID) no opaco transmitido
(7) por el gestor (GIDT), el servidor de localización (LOC)
transmite (8) las informaciones de localización solicitadas al
proveedor de ofertas de servicio (31).
En el modo de realización preferido de la
invención, el gestor del identificador de transacciones (GIDT)
incluye, por una parte, un motor de transacciones (28) que genera
emisiones de eventos de transacciones formados por cualquiera de
los siguientes comandos: BEGIN (ST), COMMIT (CT), ROLLBACK (ET), y
por otra parte, un motor de trazabilidad (29), que consigna en la
memoria (25) cada evento del motor de transacciones (28) y el
conjunto de las informaciones emitidas durante la utilización del
medio servidor de identificación de transacciones (GIDT). Como se
representa en la figura 1, la etapa de análisis (1') con control de
autorización para la apertura de la transacción es seguida
inmediatamente por el envío hacia al menos un sistema externo (40)
de un evento de inicio de transacción, en forma de un comando BEGIN
(ST) generado por el motor de transacciones (28). La generación del
evento de inicio de transacción se realiza a través del interfaz de
notificación de las transacciones (22) del gestor (GIDT).
El sistema externo (40) puede consistir, por
ejemplo, en un sistema de facturación para la reserva de un ticket
de facturación. La etapa de análisis (1') viene igualmente seguida
de una grabación efectuada por el motor de trazabilidad (29) de
estadísticas de apertura de servicio, realizada sensiblemente en el
mismo momento que la generación del comando BEGIN (ST). Desde el
momento del envío del evento de inicio de transacción hacia el
sistema externo (40), puede llevarse a cabo una
sub-transacción (R'). El motor de trazabilidad (29)
registra igualmente las estadísticas (6, 11) al finalizar cada una
de las sub-transacciones (R'). El contexto de las
transacciones se actualiza cuando se finaliza la realización de una
sub-transacción (R'). Naturalmente, pueden
trasplantarse sistemas de tipo gestión de diálogo, IHM, sistemas de
pago en efectivo o a tanto alzado y otros sistemas del mismo tipo
al motor de transacciones (28). En un modo de realización de la
invención, el motor de trazabilidad (29) dispone del conjunto de las
informaciones emitidas por la utilización del gestor de
identificador de transacciones (GIDT), por ejemplo, sobre el control
de acceso, tanto positivo como negativo, sobre la realización de la
oferta, tanto si se ha completado como si se encuentra en curso,
etc.
En el ejemplo de la figura 1, la segunda
sub-transacción (R') hace que intervenga un
servidor de mensajes cortos (SMS), efectuando el proveedor del
servicio (33) una petición (4) al servidor (SMS). El modo de
comunicación es análogo al caso mencionado anteriormente para la
sub-transacción (R') con el servidor de
localización (LOC). En esta ocasión, después de haber recibido el
número de identificación (UserID) no opaco transmitido (12) por el
gestor (GIDT), el servidor (SMS) transmite (13) las informaciones
de mensajes cortos solicitadas al proveedor de servicio (33). Una
tercera sub-transacción hace intervenir a un
servidor enabler de mensajes multimedia (MMS). En el ejemplo de esta
tercera sub-transacción, el gestor (GIDT) detecta
una incoherencia entre la descripción de servicio almacenada en la
memoria (25) y la petición de invocación del servidor enabler de
mensajes multimedia (MMS). Un error de este tipo puede ser
detectado, por ejemplo, cuando la descripción del servicio preve el
envío de un e-mail. Las dos primeras etapas (14,
15) son análogas a las dos primeras etapas (4, 5) de la primera
sub-transacción (R') relativa al servidor de
localización (LOC). Posteriormente se detecta la incoherencia en el
transcurso de la ejecución del método de desenmascaramiento, como
se muestra con el esquema correspondiente de la figura 3. El motor
de trazabilidad (29) registra informaciones estadísticas (16)
representativas de la cancelación de la transacción. A continuación,
el gestor de identificación de transacciones (GIDT) envía, a través
del primer interfaz de comunicaciones (21) una respuesta negativa
(17) al elemento servidor "enabler" (MMS). Este último (MMS)
notifica al proveedor de las ofertas de servicio (31) la denegación
de autorización (18) de envío de un mensaje corto multimedia. Para
finalizar, el gestor de identificación de transacciones (GIDT)
emite, a través del interfaz de notificación de transacciones (22)
un evento de transacciones de tipo fin de reintento ROLLBACK (ET)
para notificar al sistema externo (40) que el servicio de un
extremo a otro ha fracasado, al haberse sobrepasado el número de
reintentos de la transacción en caso de error. Este evento ROLLBACK
(ET) notifica que la transacción ha sido cancelada. En un modo de
realización de la invención, los datos facilitados con el evento de
transacciones ROLLBACK (ET) se transmiten a un gestor de diálogo y
permiten facturar o no el servicio.
A continuación se va a describir la invención de
acuerdo con las figuras 3 y 4.
La figura 3 representa los métodos con las
lógicas de estado asociadas a las interacciones entre los elementos
servidores "enablers" (31) y el gestor (GIDT). El método de
enmascaramiento denominado Mask del gestor de identificación de
transacciones (GIDT) recupera en un primer momento (202) las
informaciones de la oferta objetivo (203) correspondientes al
identificador (UserID) a partir de la dirección técnica (201) y de
la pluralidad de ofertas de servicio almacenadas en la memoria (25).
Posteriormente, el método Mask controla el acceso (204) de un
usuario abonado a la oferta de servicio (203) y emite una denegación
de acceso (R1) o inicia el método Start (S).
El método de desenmascaramiento denominado
Unmask del gestor de identificación de transacciones (GIDT)
recupera en un primer momento (205) las informaciones de la oferta
objetivo (206) a partir de datos representativos de la dirección
técnica y el identificador de la transacción (trid) y a partir de
dicha pluralidad de ofertas. A continuación, como se muestra en la
figura 3, el método Unmask controla el acceso (207) de un asociado
(33) al elemento servidor enabler (LOC, SMS, MMS) y verifica (208)
que la petición efectuada al elemento servidor (LOC, SMS, MMS) se
corresponde con el contexto actual de la transacción. Después, en el
caso de que sea necesaria una actualización, el método Unmask
continúa ejecutándose notificando al elemento servidor enabler
(LOC, SMS, MMS) que el gestor de identificación de transacciones
(GIDT) está a la espera de una actualización, devuelve (210) el
número MSIDSN o identificación (UserID) análogo asociado al
identificador de transacciones opaco (trid), se pone a la espera
(211) de la actualización Update y a continuación verifica (302) si
la actualización recibida contiene las informaciones necesarias
para la realización de la oferta, para emitir un método Completed
(C) o un método Error (E). Se notifica una denegación de acceso (R2)
cuando el acceso no ha sido autorizado por el control (207). En el
modo de realización de la figura 3, una etapa de control (209) de
actualización interviene tras la etapa de verificación (208) para
activar directamente la realización de la oferta con un método
Completed (C) en el caso de que la actualización no sea
necesaria.
La figura 4 presenta los métodos de comunicación
entre un proveedor de servicios (33) y el gestor de identificación
de transacciones (GIDT) que sirve para la apertura y el cierre de
una transacción. El método OpenTransaction es emitido por un
proveedor de servicios de valor añadido (33) hacia el interfaz de
proveedores (23) del gestor (GIDT) para controlar el acceso (100) de
un asociado (33) a un abonado del operador y obtener una denegación
de acceso (R3) o iniciar un método Start (S). El método Close
Transaction, emitido por un proveedor (33) al interfaz de
proveedores (23) del gestor (GIDT) genera un evento que permite
desbloquear la espera (TimeOut) de la lógica del gestor de
identificación de transacciones (GIDT).
A continuación va a describirse la invención de
acuerdo con la figura 5.
En modo Pull/MO, la cinemática de entrega de un
servicio presenta ciertas diferencias en relación con el
funcionamiento en modo Push. La figura 5 ilustra el caso de un
servicio descrito en la memoria (25) como compuesto por una
petición de localización, seguida del envío de un mensaje corto SMS.
Al igual que en el modo Push, el desarrollo del servicio, y
concretamente las llamadas a los enablers, se comunican en la
descripción del servicio y la dirección técnica del proveedor de
ofertas de servicio (31) es conocida por el gestor (GDIT).
Ante todo, debe enviarse una petición de
servicio de un usuario a un elemento servidor "enabler" para
los mensajes (SMS) a través de un mensaje MO transmitido a partir
del teléfono móvil del usuario. El elemento servidor "enabler"
(SMS) intercepta entonces la petición de servicio procedente del
usuario. Al estar asociada la cuenta del enabler (SMS) a una
dirección técnica del servicio, el enabler (SMS) solicita entonces
la apertura (O) de una transacción al gestor de identificación de
transacciones (GIDT) para el usuario y el servicio en cuestión.
Esta petición de apertura (O) dirigida al primer interfaz de
comunicaciones (21) del gestor (GDIT) se describe de forma
secuencial con un lote de primitivas abiertas, y notifica una
identificación de usuario (UserID). Se efectúa entonces un análisis
(1') de la petición (O) y, en caso de autorización por parte de los
medios de control (26) del gestor (GDIT), se genera un comando BEGIN
(ST) a través del motor de transacciones (28) para notificar un
evento de inicio de transacción al sistema externo (40).
Un identificador de transacción (trid)
correspondiente al servicio y al usuario se devuelve (3') al
enabler de la cuenta de mensajes cortos (SMS). A continuación, el
proveedor de servicios de valor añadido (33) recibe (3'') la
petición del usuario en forma de un mensaje corto enviado a partir
del enabler (SMS) sin conocer la identidad exacta de este, pues
sólo se le ha facilitado el identificador de la transacción (trid).
Las sub-transacciones (R') pueden entonces
realizarse de la misma forma que en el modo de comunicación en modo
Push (figura 1). Al finalizar la última
sub-transacción (R'), el gestor de identificación
de transacciones (GIDT) detecta la consecución de la realización (R)
de la transacción correspondiente al servicio. También notifica al
sistema externo (40) que el servicio ha sido entregado de principio
a fin al usuario en cuestión, mediante la generación de un evento
de transacciones COMMIT (CT).
Una de las ventajas del procedimiento según la
invención consiste en que permite gestionar una sesión de servicio
a un abonado utilizando diversos enablers de la red del operador,
generando eventos a lo largo de su realización, lo que permite, por
ejemplo, facturar un servicio en función del número de
sub-transacciones realmente efectuadas.
Otra de las ventajas de la invención, en
relación con las técnicas existentes, es que el operador puede
garantizar la confidencialidad de los datos del usuario frente a los
proveedores de servicios.
Debe ser evidente para las personas versadas en
la materia que la presente invención permite una serie de modos de
realización bajo otras numerosas formas específicas, sin salirse del
ámbito de aplicación de la invención, de acuerdo con lo
reivindicado. Por consiguiente, los presentes modos de realización
deben ser considerados a título ilustrativo, pero pueden modificarse
dentro del ámbito definido por el alcance de las reivindicaciones
adjuntas, y la invención no debe limitarse a los detalles
facilitados anteriormente.
Dirección técnica: cadena de caracteres que
describe, para un enabler, un servicio dado. Una dirección técnica
puede ser un mensaje corto o short-code en el caso
de los medios SMS y GD (por ejemplo, "2222"), o una dirección
URL, en el caso del medio WAP (por ejemplo,
http://wap.sfr.net). La cadena de caracteres que constituye
la dirección técnica puede también finalizar con el carácter *.
CAMEL: Customized Applications for Mobile
network Enhanced Logic (nombre genérico de aplicaciones para
móviles)
DTD: Definición de tipo de documento
GD: Gestor de diálogo
GID: Gestor de identificador
GIDT: Gestor de identificador de
transacciones
GO: Gestor de la oferta
LOC enabler: Plataforma de localización
SMS enabler: Plataforma que permite el envío de
mensajes cortos.
MMS enabler: Plataforma de envío de mensajes
multimedia.
IHM: Interfaz
hombre-máquina.
MO/MT: Mobile Originated/Mobile Terminated
MS-ISDN: Mobile
Station-Integrated Services Digital Network. Es el
número al que se llama al teléfono móvil.
OSA: Open Services Access (define un interfaz
con una red de radiotelefonía móvil)
PARLAY: Equivalente a OSA para la red fija.
UIT: Unión Internacional de las
Telecomunicaciones.
VASP: proveedor de servicios de valor
añadido
WAP: Protocolo inalámbrico de aplicaciones
(Wireless Application Protocol)
WAP-Server: Servidor WAP que
puede ser utilizado por los teléfonos móviles a través de una puerta
de enlace WAP (WAP Gateway) que traduce a un formato compatible con
Internet las informaciones transmitidas a través de una red móvil,
y que es capaz de efectuar la conversión inversa.
XML: eXtensible Mark-up
Language. Metalenguaje similar al HTML.
Claims (23)
1. Método para control de la entrega completa de
un servicio con gestión de un identificador opaco de usuario,
utilizando al menos un servidor (31), caracterizado porque se
realiza a través de un medio servidor de identificador de
transacciones (GIDT) que almacena en una memoria (25) para cada
usuario una descripción de una pluralidad de ofertas de servicio
suscritas por el usuario con proveedores de servicios de valor
añadido (33), incluyendo dicho medio servidor de identificador de
transacciones (GIDT) un módulo de gestión (27) que permite asociar
a un usuario o grupo de usuarios, y al menos a un servicio
determinado, un identificador de transacciones opaco (trid),
incluyendo dicho procedimiento las siguientes etapas:
- emisión, mediante un servidor (31) que ha
interceptado una petición de servicio enviada por un usuario o por
uno de dichos proveedores de servicio (33), de una petición de
apertura de transacción (1) de, al menos, un servicio que invoca al
menos a un servidor determinado (31) que realiza una serie de
sub-transacciones (R'), estando descrita dicha
petición (1) de forma secuencial con un lote de primitivas abiertas
y dirigida a un interfaz de comunicaciones (21, 23) del medio
servidor de identificador de transacciones (GIDT) y que notifica
una identificación de usuario (UserID),
- análisis (1') de la petición y generación de
un identificador de transacciones opaco (trid) a través de los
medios de gestión y de control (26, 27) del servidor de
identificación de transacciones (GIDT), seguida de
- una etapa de realización (R) de la
transacción, utilizando el identificador de transacciones opaco
(trid).
2. Procedimiento de acuerdo con la
reivindicación 1, caracterizado porque la etapa de análisis
(1') incluye una verificación efectuada por el módulo de gestión
(27) de la correspondencia de unos servidores determinados (31) con
una oferta de servicios estructurada en torno a directorios, a la
que puede acceder el usuario entre la pluralidad de ofertas de
servicio y un control de la autorización de apertura de la
transacción a través de los medios de control (26) del medio
servidor de identificador de transacciones (GIDT) para el servicio
suministrado por los proveedores determinados (LOC, SMS, MMS) y el
usuario especificado, en función de la identificación del
usuario
(userID).
(userID).
3. Procedimiento de acuerdo con las
reivindicaciones 1 o 2, caracterizado porque la etapa de
realización (R) de la transacción se inicia a través de un
proveedor de servicios de valor añadido (33) que ha recibido el
identificador de transacciones opaco (trid) por parte del medio
servidor de identificador de transacciones (GIDT), efectuando el
proveedor del servicio (33) una petición a un servidor determinado
(31), incluyendo como parámetro el identificador de transacciones
opaco (trid) de un servicio determinado que constituye una
sub-transacción, para iniciar como respuesta, a
través de dicho servidor determinado (LOC, SMS, MMS) el envío al
servidor del identificador de transacciones (GIDT) una petición (5)
de desenmascaramiento (Unmask) que permite, a partir del
identificador opaco (trid) el suministro de un número de
identificación (UserID) no opaco, correspondiente al identificador
de transacciones opaco (trid), realizándose a continuación un
control (5', 10') a través de los medios de control (26) del medio
servidor de identificador de transacciones (GIDT), para verificar,
sí el servidor determinado (LOC, SMS, MMS) está autorizado o no para
dicho servicio y para dicho usuario, de tal forma que, en caso de
autorización, el número de identificación (UserID) no opaco se
transmite (7, 12) al servidor determinado (31) a través de un
interfaz de comunicaciones denominado interfaz enabler (21), para
permitir la realización del la sub-transacción
(R').
4. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 3, caracterizado porque el
identificador de transacciones (trid), compuesto por un máximo de
15 dígitos, se ajusta al plan de numeración UIT-T
E-164, y porque el número de identificación
(UserID) no opaco es el número MSISDN.
5. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 4, en el que el medio servidor de
identificador de transacciones (GIDT) incluye, por una parte, un
motor de transacciones (28) que genera emisiones de eventos de
transacciones formados por uno de los siguientes comandos: BEGIN
(ST), COMMIT (CT), ROLLBACK (ET), y por otra parte, un motor de
trazabilidad (29), que consigna en la memoria (25) cada evento del
motor de transacciones (28) y el conjunto de las informaciones
emitidas durante la utilización del medio servidor de
identificación de transacciones (GIDT).
6. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 5, caracterizado porque el
identificador de transacciones opaco (trid) se envía (3) al
proveedor de servicios de valor añadido (33) tras almacenar en la
memoria (25) del medio servidor de identificador de transacciones
(GIDT) de un contexto de transacciones que indica,
específicamente:
- -
- un número de identificación (UserID) del usuario,
- -
- el identificador de transacciones (trid),
- -
- la oferta asociada a la transacción,
- -
- el estado de desarrollo de la transacción para la oferta asociada a esta.
7. Procedimiento de acuerdo con la
reivindicación 6, en el que el envío (3) del identificador de
transacciones opaco (trid) al proveedor de servicios de valor
añadido (33) viene precedido de una generación de un evento de
transacciones que representa el inicio de la transacción hacia al
menos un sistema externo (40) a través de un segundo interfaz de
comunicaciones del medio servidor de identificador, denominado
interfaz de notificación de transacciones (22).
8. Procedimiento de acuerdo con la
reivindicación 7, en el que la generación de un evento de
transacciones representativo del inicio de una transacción hacia al
menos un sistema externo (40) se efectúa a través de un comando
BEGIN (ST) generado por un motor de transacciones (28) del medio
servidor de identificador de transacciones
(GIDT).
(GIDT).
9. Procedimiento de acuerdo con la
reivindicación 7 u 8, en el que el medio servidor de identificador
de transacciones (GIDT) transmite, desde el interfaz de
notificación de transacciones (22), al menos, a un sistema externo
(40) unos datos representativos de la realización completa de la
oferta mediante un comando COMMIT (CT) generados por el motor de
transacciones (28) para indicar al sistema externo (40), por
ejemplo, de facturación, que la transacción se ha completado.
10. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 7 a 9, en el que el medio servidor de
identificador de transacciones emite, a través del interfaz de
notificación de transacciones (22) un evento de transacciones tipo
finalización de reintento ROLLBACK para notificar, al menos, a un
sistema externo (40) que se ha sobrepasado el número de reintentos
de transacción en caso de error y que la transacción se ha anulado
para suministrar datos a un gestor de diálogo y para facturar o no
el servicio.
11. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 10, en el que los medios de gestión y de
control (26, 27) del servidor de identificador de transacciones
(GIDT) efectúan el análisis (1') de la petición de apertura de
transacción, concretamente mediante la resolución de una
correspondencia entre una dirección técnica de servicio notificada
en la petición (1) de apertura de transacción y una oferta de
servicio estructurada en torno a directorios entre la pluralidad de
descripciones de ofertas de servicio almacenadas en la memoria (25)
del medio servidor de identificador de transacciones (GIDT).
12. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 11, en el que la memoria del medio
servidor de identificador de transacciones (GIDT) almacena
descripciones de ofertas de servicio validadas para dichos
proveedores (31), seleccionadas a través de un tercer interfaz de
comunicaciones denominado interfaz de suministro de descripciones
de servicio (IFDS).
13. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 12, en el que la descripción de una oferta
de servicio incluye datos formulados en un metalenguaje o formato
equivalente que permite a los medios de control del medio servidor
de identificador controlar el correcto desarrollo del servicio,
detectando su comienzo y su finalización.
14. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 13, en el que el medio servidor de
identificador de transacciones (GIDT) incluye un interfaz de
comunicación suplementario (23) destinado a los proveedores de
servicios de valor añadido (33), estando destinado el primer
interfaz (21) a unos servidores determinados (31).
15. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 1 a 14, en el que el medio servidor de
identificador de transacciones (GIDT) incluye una lógica interna que
realiza los métodos siguientes: Start (S),
Completed (C), Error (E), Mask, Unmask, Update, Open transaction, Close transaction.
Completed (C), Error (E), Mask, Unmask, Update, Open transaction, Close transaction.
16. Procedimiento de acuerdo con la
reivindicación 15, en el que el método Start (S) del medio servidor
de identificador de transacciones (GIDT) genera (S1) un
identificador de transacciones (trid), crea (S2) en la memoria un
contexto de transacciones, genera un evento de transacciones de tipo
BEGIN (ST) y devuelve el identificador de transacciones (trid) al
proveedor de servicios de valor añadido (33).
17. Procedimiento de acuerdo con las
reivindicaciones 15 o 16, en el que el método Completed (C) del
medio servidor de identificador de transacciones (GIDT) determina
mediante una prueba (C1) si se ha realizado una
sub-transacción (R') de la transacción (C0),
modifica (C2) en consecuencia el contexto de la transacción,
determina, escrutando la descripción de la oferta (C3), si es
necesario que el medio servidor de identificador de transacciones
(GIDT) espere (C5) un evento exterior, sitúa la lógica a la espera
de que transcurra un período "TimeOut" o un cierre de la
transacción "Close Transaction", verifica (C4) si se ha
conseguido efectuar la transacción y genera un evento de
transacción de tipo COMMIT (CT).
18. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 15 a 17, en el que el método Error (E) del
medio servidor de identificador de transacciones (GIDT) verifica si
se ha sobrepasado el número de reintentos en caso de error, y en
caso afirmativo, genera un evento de transacción de tipo ROLLBACK
(ET).
19. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 15 a 18, en el que un servidor determinado
(31) emite el método Mask para recuperar (202) las informaciones de
la oferta objetivo (203) a partir de la dirección técnica (201) y
de dicha pluralidad de ofertas, controlar el acceso (204) de un
usuario abonado a la oferta de servicio y emitir una denegación de
acceso (R1) o el inicio del método Start (S).
20. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 15 a 19, en el que un servidor determinado
(31) emite el método Unmask para recuperar (205) las informaciones
de la oferta objetivo (206) a partir de los datos representativos
de la dirección técnica y el identificador de transacciones (trid),
y a partir de dicha pluralidad de ofertas, controlar el acceso
(207) de un proveedor (33) asociado al servidor determinado (31),
verificar (208) que la petición efectuada a dicho servidor
determinado (31) se corresponde con el contexto actual de la
transacción, y notificar a dicho servidor determinado (31) que el
medio servidor de identificador de transacciones (GIDT) está a la
espera de una actualización, devolver (210) el número MSISDN
asociado al identificador de transacciones opaco (trid), ponerse a
la espera (211) de la actualización, y a continuación, verificar
(302) que la actualización recibida contiene las informaciones
necesarias para la realización de la oferta, para emitir un método
Completed (C) o un método
Error (E).
Error (E).
21. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 15 a 20, en el que un servidor determinado
(31) emite el método Update, constituido por la puesta en estado de
espera (211) de actualización relativa a la realización de la
petición del servidor de identificador de transacciones (GIDT).
22. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 15 a 21, en el que un proveedor de servicios
de valor añadido (33) emite el método Open Transaction para
controlar el acceso (100) de un asociado a un abonado del operador
y generar una denegación de acceso (R3) o iniciar un método Start
(S).
23. Procedimiento de acuerdo con cualquiera de
las reivindicaciones 17 a 22, en el que un proveedor de servicios
de valor añadido (33) emite el método Close Transaction y genera un
evento que permite desbloquear la espera "TimeOut" de la
lógica del medio servidor de identificador de transacciones
(GIDT).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0306898A FR2855924B1 (fr) | 2003-06-06 | 2003-06-06 | Procede de controle avec gestion d'un identifiant opaque d'utilisateur de la livraison complete d'un service utilisant un ensemble de serveurs |
| FR0306898 | 2003-06-06 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2264554T3 true ES2264554T3 (es) | 2007-01-01 |
Family
ID=33155673
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04290596T Expired - Lifetime ES2264554T3 (es) | 2003-06-06 | 2004-03-05 | Metodo de control de entrega completa de un servicio, con gestion de un identificador opaco de usuario, utilizando un conjunto de servidores. |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US20040260719A1 (es) |
| EP (1) | EP1484859B1 (es) |
| JP (1) | JP2004362591A (es) |
| KR (1) | KR20040105588A (es) |
| CN (1) | CN100388206C (es) |
| AT (1) | ATE328421T1 (es) |
| DE (1) | DE602004001016T2 (es) |
| DK (1) | DK1484859T3 (es) |
| ES (1) | ES2264554T3 (es) |
| FR (1) | FR2855924B1 (es) |
| PT (1) | PT1484859E (es) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8019362B2 (en) | 2003-02-07 | 2011-09-13 | Sybase 365, Inc. | Universal short code administration facility |
| CN1822687B (zh) * | 2006-03-31 | 2010-09-01 | 中兴通讯股份有限公司 | 一种多媒体消息签名业务的实现方法 |
| US8396929B2 (en) * | 2008-07-02 | 2013-03-12 | Sap Portals Israel Ltd. | Method and apparatus for distributed application context aware transaction processing |
| US8078582B2 (en) * | 2009-04-06 | 2011-12-13 | Microsoft Corporation | Data change ordering in multi-log based replication |
| US20110060627A1 (en) * | 2009-09-08 | 2011-03-10 | Piersol Kurt W | Multi-provider forms processing system with quality of service |
| US8671074B2 (en) | 2010-04-12 | 2014-03-11 | Microsoft Corporation | Logical replication in clustered database system with adaptive cloning |
| TWI418224B (zh) * | 2010-06-30 | 2013-12-01 | Htc Corp | 自動設定網路推播服務之語言種類的方法、用戶端及伺服器 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001222652A (ja) * | 2000-02-12 | 2001-08-17 | Toha Ri | コンピュータ通信網を通じ標準商品情報を利用した商品配達サービス装置及び方法 |
| WO2002011474A2 (en) * | 2000-07-31 | 2002-02-07 | Cellact Ltd. | System and method for anonymous but personalized provision of services |
| US7076467B1 (en) * | 2000-08-04 | 2006-07-11 | Sony Computer Entertainment America Inc. | Network-based method and system for transmitting digital data to a client computer and charging only for data that is used by the client computer user |
| EP2320620A1 (en) * | 2001-04-23 | 2011-05-11 | Koninklijke KPN N.V. | Service provider architecture and method for delivering content services to mobile communication customers |
| ATE343295T1 (de) * | 2001-04-23 | 2006-11-15 | Koninkl Kpn Nv | Architektur zur bereitstellung von internetdiensten |
| US8868659B2 (en) * | 2001-05-15 | 2014-10-21 | Avaya Inc. | Method and apparatus for automatic notification and response |
| US6898609B2 (en) * | 2002-05-10 | 2005-05-24 | Douglas W. Kerwin | Database scattering system |
-
2003
- 2003-06-06 FR FR0306898A patent/FR2855924B1/fr not_active Expired - Fee Related
-
2004
- 2004-03-05 PT PT04290596T patent/PT1484859E/pt unknown
- 2004-03-05 AT AT04290596T patent/ATE328421T1/de not_active IP Right Cessation
- 2004-03-05 EP EP04290596A patent/EP1484859B1/fr not_active Expired - Lifetime
- 2004-03-05 DE DE602004001016T patent/DE602004001016T2/de not_active Expired - Lifetime
- 2004-03-05 DK DK04290596T patent/DK1484859T3/da active
- 2004-03-05 ES ES04290596T patent/ES2264554T3/es not_active Expired - Lifetime
- 2004-04-14 US US10/823,904 patent/US20040260719A1/en not_active Abandoned
- 2004-05-25 CN CNB2004100458976A patent/CN100388206C/zh not_active Expired - Fee Related
- 2004-06-05 KR KR1020040041133A patent/KR20040105588A/ko not_active Application Discontinuation
- 2004-06-07 JP JP2004168070A patent/JP2004362591A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| US20040260719A1 (en) | 2004-12-23 |
| JP2004362591A (ja) | 2004-12-24 |
| DK1484859T3 (da) | 2006-10-02 |
| CN100388206C (zh) | 2008-05-14 |
| PT1484859E (pt) | 2006-09-29 |
| FR2855924B1 (fr) | 2005-07-15 |
| EP1484859A1 (fr) | 2004-12-08 |
| DE602004001016T2 (de) | 2006-12-14 |
| KR20040105588A (ko) | 2004-12-16 |
| CN1573699A (zh) | 2005-02-02 |
| DE602004001016D1 (de) | 2006-07-06 |
| EP1484859B1 (fr) | 2006-05-31 |
| FR2855924A1 (fr) | 2004-12-10 |
| ATE328421T1 (de) | 2006-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9578027B1 (en) | Multiple data store authentication | |
| US8064583B1 (en) | Multiple data store authentication | |
| EP2302523B1 (en) | Enhanced service platform with secure system and method for subscriber profile customization | |
| US8756126B2 (en) | Billing device and processing method | |
| US9571474B2 (en) | Method for providing a service based on tag information, and corresponding tag and tag reading device | |
| US20120066034A1 (en) | Online account to mobile device link | |
| US20090215489A1 (en) | Method and Device for Managing Applications of a Mobile Terminal | |
| CN110213217A (zh) | 数据访问方法、相关装置、网关和数据访问系统 | |
| US8312475B2 (en) | Remote control of computing devices via two disparate networks | |
| ES2264554T3 (es) | Metodo de control de entrega completa de un servicio, con gestion de un identificador opaco de usuario, utilizando un conjunto de servidores. | |
| ITTO20060773A1 (it) | Metodo di accesso a basi di dati tramite messaggi sms/mms | |
| CN107957871A (zh) | 一种基于jsr303的前后端同步正则校验方法 | |
| EP2224381A1 (en) | Method and apparatus for case-based service composition | |
| CN112187944B (zh) | 一种一号通业务报文的处理方法 | |
| CN112188009B (zh) | 一种一号通业务执行方法 | |
| KR20020042834A (ko) | 인터넷 도메인 이름 등록의 설립 및 유지를 위한 방법 및장치 | |
| CN110321380A (zh) | 一种数据交换方法、装置及系统 | |
| CN114999052A (zh) | 一种投票方法及系统 | |
| CN109901936A (zh) | 一种应用于分布式系统中的服务协作方法及其装置 | |
| EP2417564A1 (en) | Message management system |