ES2274980T3 - Arquitectura para proveer servicios en interneet. - Google Patents

Arquitectura para proveer servicios en interneet. Download PDF

Info

Publication number
ES2274980T3
ES2274980T3 ES02745259T ES02745259T ES2274980T3 ES 2274980 T3 ES2274980 T3 ES 2274980T3 ES 02745259 T ES02745259 T ES 02745259T ES 02745259 T ES02745259 T ES 02745259T ES 2274980 T3 ES2274980 T3 ES 2274980T3
Authority
ES
Spain
Prior art keywords
user
service
provider
access
terminal
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
Application number
ES02745259T
Other languages
English (en)
Inventor
Siegried Ergezinger
Keisinger
Heiko Thierbach
Alexander Herzlinger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke KPN NV
Original Assignee
Koninklijke KPN NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP01201460A external-priority patent/EP1253760A1/en
Priority claimed from DE10154546A external-priority patent/DE10154546B4/de
Application filed by Koninklijke KPN NV filed Critical Koninklijke KPN NV
Application granted granted Critical
Publication of ES2274980T3 publication Critical patent/ES2274980T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/75—Account location specifications
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/765—Linked or grouped accounts, e.g. of users or devices
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/765—Linked or grouped accounts, e.g. of users or devices
    • H04M15/7655—Linked or grouped accounts, e.g. of users or devices shared by technologies
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • H04M15/772—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user per service, e.g. prepay or post-pay
    • 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/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • H04M15/773—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user per technology, e.g. PSTN or wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/725—Shared by technologies, e.g. one account for different access technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H04M2215/7263—Multiple accounts per user per service, e.g. prepay and post-pay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H04M2215/7268—Multiple accounts per user per technology, e.g. PSTN or wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access

Abstract

Un sistema para proveer servicios a un terminal de usuario (150, 160); incluyendo el sistema: al menos un subsistema proveedor de servicios/contenido (110, 120, 130), en lo sucesivo "proveedor de servicios", para proveer servicios por medio de una red de área amplia (140), en particular Internet, que incluye una interfaz de comunicación para comunicarse a la red de área amplia; al menos un subsistema proveedor de acceso a servicios (100), en lo sucesivo "proveedor de acceso", que incluye una interfaz de comunicación (210, 220) para comunicarse al al menos un proveedor de servicios por medio de la red de área amplia (140) y para comunicarse a al menos un terminal de usuario por medio de un sistema de comunicación adicional (170, 180); y al menos un terminal de usuario (150, 160) que incluye una interfaz de comunicación para comunicarse al proveedor de acceso por medio del sistema de comunicación adicional y, a través del proveedor de acceso, solicitar servicios de al menos un proveedor de servicios; en el que el proveedor de acceso incluye un administrador de acceso a servicios (230) para verificar si un terminal de usuario o un usuario de un terminal de usuario, en lo sucesivo "usuario/terminal", está autorizado a solicitar un servicio de un proveedor de servicios y tras verificación positiva permitir al terminal de usuario acceder al proveedor de servicios, liberando así al proveedor de servicios de tener que autorizar al usuario/terminal.

Description

Arquitectura para proveer servicios en Internet.
Campo de la invención
La invención se refiere a un sistema y un procedimiento para proveer servicios a través de una red de área amplia, en particular Internet, a terminales de usuario. La invención se refiere especialmente, pero no se limita, a proveer tales servicios a terminales móviles que obtienen acceso a la red a través de un proveedor de acceso de telecomunicaciones.
Antecedentes de la invención
Normalmente se accede a los servicios en redes de área amplia, especialmente en Internet, por medio de un proveedor de acceso, que ofrece al usuario acceso a toda la Internet incluyendo cada proveedor de servicios seleccionado por un usuario. El terminal de usuario se comunica con el proveedor de acceso por medio de una conexión/red de acceso. Normalmente, tal conexión de acceso consta de una conexión telefónica directa (fija o, cada vez más, móvil) o una conexión de acceso compartido de banda ancha (como por cable o por satélite). El proveedor de acceso pasa mensajes del terminal de usuario, como una solicitud de servicio, al proveedor de servicios implicado y pasa mensajes del proveedor de servicios al terminal de usuario. El servicio puede ser entregado en forma de contenido digital, como audio MP3, vídeo MPEG4, o software a través de Internet, pero también puede resultar en la entrega de un producto físico (por ejemplo, el producto/servicio pedido a través de compra por Internet u obtenido a través de una participación exitosa en una subasta por Internet), o cualquier otra forma. En aquellos casos en que no todo el servicio se provee a través de Internet, el término "proveer servicios" en el contexto de Internet quiere decir la interacción que hace que se entregue el servicio/producto. El usuario tiene que suscribirse al proveedor de acceso (aunque la suscripción en sí misma puede ser gratuita, o pagada a través de acuerdo de reembolso del proveedor de acceso con el proveedor de telecomunicación de la conexión de acceso). El usuario, por medio del terminal de usuario, tiene que registrarse en el sistema de acceso del proveedor de acceso que comprueba si el nombre de cuenta y la contraseña corresponden a una suscripción registrada. Si es así, el proveedor de acceso normalmente provee acceso total a Internet. Muchos proveedores de servicio requieren que el usuario también se registre y que se identifique cada vez que el usuario desea usar un servicio proporcionado por el proveedor de servicios. Este es particularmente el caso si el usuario desea usar un servicio de pago, como compras por Internet.
Con la llegada de un número y diversidad crecientes de terminales de usuario, que incluyen ordenadores personales de escritorio, ordenadores personales portátiles, teléfonos móviles, asistentes digitales personales, de los cuales algunos son menos sofisticados que los terminales convencionales basados en ordenador, y el aumento del número de servicios de pago la arquitectura tradicional como la descrita anteriormente no da más de sí. Las áreas particulares de interés son la seguridad con respecto a privacidad y facturación, así como la facilidad de uso.
Resumen de la invención
Un objeto de la invención es proveer una arquitectura mejorada para proveer servicios a través de una red de área amplia, en particular Internet.
Para satisfacer este objeto de la invención, el sistema para proveer servicios a un terminal de usuario incluye al menos un subsistema proveedor de acceso a servicios (en lo sucesivo "proveedor de acceso") que incluye una interfaz de comunicación para comunicarse a al menos un subsistema proveedor de servicios/contenido (en lo sucesivo "proveedor de servicios") por medio de una red de área amplia, en particular Internet, y para comunicarse a al menos un terminal de usuario por medio de un sistema de comunicación adicional; en el que el proveedor de acceso incluye un administrador de acceso a servicios (230) para verificar si un terminal de usuario o un usuario de un terminal de usuario (en lo sucesivo "(terminal de) usuario") está autorizado a solicitar un servicio de un proveedor de servicios y tras verificación positiva permitir al terminal de usuario acceder al proveedor de servicios, liberando así al proveedor de servicios de tener que autorizar al (terminal de) usuario; y opcionalmente al menos un proveedor de servicios para proveer servicios por medio de la red de área amplia que incluye una interfaz de comunicación para comunicarse a la red de área amplia; y opcionalmente al menos un terminal de usuario que incluye una interfaz de comunicación para comunicarse al proveedor de acceso por medio del sistema de comunicación adicional y, a través del proveedor de acceso, solicitar servicios de al menos un proveedor de servicios.
El proveedor de acceso puede incluir un administrador de acceso a servicios que verifica si un usuario está autorizado a usar el servicio del proveedor de servicio implicado (o de todos los proveedores de servicios). Esto libera a los proveedores de servicios de tener que realizar tal autorización individualmente. Se apreciará que la autorización también puede basarse en autorizar al terminal de usuario usado por el usuario en lugar de autorizar al usuario. Por ejemplo, cualquiera que use un teléfono móvil autorizado puede acceder a ciertos servicios (o a todos). Este nivel de acceso puede depender del tipo de cliente (por ejemplo, de prepago o de pospago) o el tipo de suscripción. En el resto del documento, se hará referencia a "(terminal de) usuario" donde pude concederse acceso a un usuario de un terminal de usuario o al propio terminal de usuario. Usando un administrador de acceso central para controlar el acceso a los servicios, el control de acceso puede hacerse más sofisticado (por ejemplo, optimizado para diferentes tipos de terminales o usuarios) y puede hacerse mejor uso de información disponible en la red de acceso sin complicar a los proveedores de servicios y sin aumentar los costes para los proveedores de servicios. Esto mantiene bajo el límite para que los proveedores de servicios provean servicios de pago o personalizados. Preferentemente, la red de acceso es una res de telecomunicaciones móviles que puede proveer información sofisticada al proveedor de acceso. La arquitectura según la invención provee al usuario el beneficio de sólo tener que registrarse/suscribirse a y ser autorizado por un proveedor de acceso con quien el usuario puede mantener una relación a largo plazo. Libera al usuario de tener que proveer detalles confidenciales a muchos proveedores de servicios, de quienes el usuario no sabe si puede fiarse.
El servicio puede ser cualquier clase de servicio existente o futuro que pueda obtenerse por medio de un terminal de usuario, como un teléfono móvil. Esto incluye SMS, Hi site SMS, WAP, servicios bancarios, servicios de crédito, pago de servicios in situ (por ejemplo, aparcamiento) o productos (por ejemplo, dispensador de bebidas). El servicio puede incluir además información acerca del pronóstico del tiempo, información de tráfico, predicciones del horóscopo, información de apuestas, información de vuelos, información financiera y cambiaria, acontecimientos culturales y sociales, vida nocturna en una ciudad, etc. El sistema proveedor de servicios de la invención puede usarse en combinación de cualquier forma de red de acceso, pero preferentemente una tecnología de comunicaciones móviles como UMTS, GSM, WAP, GPRS, o cualquier tecnología futura de comunicaciones móviles, y el sistema puede usar cualquier protocolo como XML o html móvil o UCP u otros protocolos. Un usuario puede solicitar un servicio, que puede ser entregado en forma de una página, preferentemente una página XML o HTML o similar. Donde se requiera, el servicio puede ser entregado por el proveedor de servicios al cliente sin una solicitud del cliente o puede ser entregado sobre una base regular ("suscripción") basada en una primera solicitud de contenido procedente del cliente.
En una realización según la invención, el administrador de acceso está dispuesto para ejecutar una operación de identificación del usuario del terminal de usuario y, tras la finalización exitosa de la operación de identificación, comenzar una sesión de comunicación que permite el acceso verificado del terminal de usuario al proveedor de servicios durante la sesión. Después de la finalización exitosa de la operación de identificación, el (terminal de) usuario ha obtenido en principio acceso autorizado a al menos uno, pero preferentemente todos los proveedores de servicios que cooperan en el sistema. Se apreciará que ciertos servicios no requieren autorización/identificación (por ejemplo, el servicio es gratuito y no personalizado). El administrador de acceso puede proveer acceso a esta categoría de proveedores de servicios sin más autorización/identificación. Preferentemente, el procedimiento de identificación estándar ejecutado por los proveedores de servicios para conceder a un terminal acceso a la res de área amplia está adaptado para cubrir también el procedimiento para conceder acceso a los proveedores de servicios. De esta manera, un procedimiento de autorización da a un usuario acceso a la red en general (por ejemplo, para recibir correos electrónicos, y usar servicios gratuitos basados en Web) así como a usar servicios personalizados o de pago. Ya no se requiere registrarse/suscribirse en los diversos proveedores de servicios. Por otra parte, el único procedimiento de suscripción y autorización en el proveedor de acceso físico es suficiente para cubrir también conseguir acceso al nivel de servicio. El procedimiento adaptado puede tener que ser más seguro que el procedimiento convencional realizado por proveedores de acceso que proveen acceso general. El nivel de seguridad puede, por ejemplo, escogerse dependiendo del nivel de detalles personales implicados (proteger la privacidad del usuario) o los costes de los servicios. Con este fin, el procedimiento de identificación puede tener que ser ejecutado por medio de una conexión segura o ser usando hardware autorizado (por ejemplo, basado en técnicas de cifrado) en el terminal y el proveedor de acceso.
En una realización según la invención, la primera interfaz de comunicación del proveedor de acceso y la interfaz de comunicación del proveedor de servicios están dispuestas para asegurar al menos parte de la comunicación entre el proveedor de acceso y el proveedor de servicios. La conexión segura se usa preferentemente para informar al proveedor de servicios de que un (terminal de) usuario que desea usar el proveedor de servicios ha sido autorizado. Esto aumenta la seguridad de transferencia de la autorización desde el proveedor de servicios hasta el administrador de acceso central.
En una realización según la invención, un servicio puede comprender objetos que se pueden descargar. Los objetos pueden ser imágenes gráficas, ilustraciones, películas, sonidos o textos. Algunos de estos objetos pueden facturarse al usuario mientras que otros pueden ser gratuitos. Estos objetos pueden estar insertados en una página HTML solicitada, que puede contener objetos facturables y gratuitos. En este documento, tanto los objetos que se pueden descargar como las páginas que los contienen se denominan servicios.
En una realización según la invención, el administrador de acceso está dispuesto para verificar una solvencia asociada con el (terminal de) usuario con respecto a costes asociados con la obtención del servicio y sólo tras la verificación de solvencia positiva permitir el acceso al proveedor de servicios. La administración convencional del proveedor de acceso físico para comprobar suscripciones para conseguir acceso a Internet ahora también puede usarse ventajosamente para verificar la solvencia de un usuario para acceder a servicios, en particular servicios de pago (servicios que sólo se proveen con la condición de que se haga un pago antes de que tenga lugar la entrega real así como servicios que pueden implicar el pago en una etapa posterior).
En otra realización según la invención, el administrador de acceso está dispuesto para verificar una solvencia después de la entrega del servicio al administrador de acceso, pero antes de la entrega al terminal de usuario. La ventaja de esta realización es que puede encargarse más rápido de una solicitud de servicio.
En una realización según la invención, el administrador de acceso está dispuesto para generar un registro de facturación para facturar los costes tras la verificación positiva de la solvencia. El administrador de acceso garantiza que tiene lugar la facturación real en nombre de los proveedores de servicios. Con este fin, el administrador de acceso puede tener un acuerdo con el usuario o cobrar el dinero a través de instituciones financieras intermedias, como compañías de tarjetas de crédito. Los registros de facturación pueden ser remitidos a tales instituciones o compañías. Tradicionalmente, el proveedor de acceso sólo hacía la facturación para la red de acceso (normalmente basada en una cuota de suscripción y/o el uso de la línea telefónica). Los costes implicados en los servicios que realmente se usan en Internet no estaban muy claros para un usuario. En la arquitectura según la invención, la facturación por todos los servicios puede ser combinada por el proveedor de acceso a servicios. Preferentemente, la facturación por los servicios también se combina con la facturación por proveer el acceso físico, proveyendo al usuario una imagen muy clara de todos los costes implicados al usar Internet. Ventajosamente, el saldo por usar Internet es acordado por medio del proveedor de servicios de telecomunicación que provee la red de acceso, como una red móvil. Esto reduce sustancialmente el número de cuentas que necesita tener un usuario, y reduce, por tanto, la posibilidad de mal uso del sistema.
Preferentemente, la facturación se realiza usando un servidor de pago/facturación dispuesto para realizar la validación de la solicitud del cliente y el pago y/o facturación por el servicio de contenido. El servidor de pago/facturación está usando preferentemente una base de datos, que comprende datos del cliente como tipo de cliente (de pospago o de prepago); cuentas de suscriptor: información de facturación (para clientes de pospago) e información de cuenta de prepago (para clientes de prepago). Por lo tanto, debe entenderse que el término datos de facturación comprende datos acerca del tipo de cliente (de pospago o de prepago) y acerca del saldo de prepago real o la información de cuenta del cliente.
En una realización según la invención, el administrador de acceso está dispuesto para verificar si el servicio solicitado o los objetos que se pueden descargar asociados con ese servicio han sido proporcionados por el proveedor de servicios al (terminal de) usuario y para realizar la facturación sólo tras la confirmación de la entrega. Para servicios/contenido entregado electrónicamente a través del proveedor de acceso, el proveedor de acceso puede simplemente comprobar que todo el contenido electrónico ha sido entregado al (terminal de) usuario. Si el servicio no se entrega a través del proveedor de servicios, el proveedor de servicios puede tener que confirmar la entrega al proveedor de acceso. Preferentemente, en el periodo entre la solicitud del servicio y la confirmación de la entrega, el administrador de acceso dispone que el dinero implicado se reserve en nombre del proveedor de servicios.
En una realización según la invención, el proveedor de acceso incluye un espacio de almacenamiento para almacenar contenido electrónico proporcionado por un proveedor de servicios en respuesta a una solicitud de servicio de un (terminal de) usuario para suministro adelantado al (terminal de) usuario; estando dispuesto el administrador de acceso para repetir la entrega al usuario tras un fallo en la recuperación del contenido electrónico por el (terminal de) usuario en un primer intento. Para aumentar la fiabilidad de entrega de contenido electrónico, el proveedor de acceso almacena el contenido entregado por el proveedor de servicios para recuperación posterior por el (terminal de) usuario. Esto reduce la posibilidad de que el usuario haya pagado por un servicio entregado por el proveedor de servicios pero realmente nunca recibido por el usuario, debido a fallos en el proveedor de acceso o la red de acceso.
En una realización según la invención, el administrador de acceso está dispuesto para verificar una solvencia asociada con el (terminal de) usuario dependiendo de un tipo de usuario, cada uno con diferentes datos de facturación. En el administrador de acceso pueden operar diferentes operadores de red al mismo tiempo, teniendo cada operador sus propios tipos de usuarios y datos de facturación asociados con ellos. Esto permite proveer servicios orientados al cliente, donde el usuario puede escoger una forma de pago que mejor le convenga. Preferentemente, se hace una distinción entre clientes de suscripción y no de suscripción. Para clientes no de suscripción, preferentemente se hace una distinción más entre clientes de prepago y de pospago. Los datos de facturación del cliente incluyen datos acerca del tipo de cliente (prepago o pospago), y/o datos acerca de la cuenta de dicho cliente, y/o datos acerca de la cuenta de suscriptor de dicho cliente. Los datos de facturación son proporcionados por el (terminal de) usuario en una solicitud de servicio o son almacenados en el proveedor de acceso en asociación con el (terminal de) usuario. Para clientes de prepago, la facturación real del cliente puede incluir retirada de la sume requerida de la cuenta del cliente. Para un cliente de pospago la facturación puede incluir retirada de la suma requerida de una cuenta de "m-commerce" (comercio móvil). Preferentemente, la facturación también cubre los costes del transporte del contenido.
En una realización según la invención, el (terminal de) usuario está asociado con información de identificación que está incluida en al menos un mensaje de solicitud a un proveedor de servicios para permitir al proveedor de servicios proporcionar el servicio al (terminal de) usuario; incluyendo el proveedor de acceso: un espacio de almacenamiento (240) para almacenar información de identificación ficticia asociada para cada (terminal de) usuario; y un convertidor de identidad (260) para sustituir en un mensaje de solicitud de servicio procedente del terminal de usuario la información de identificación con una información de identificación ficticia correspondiente remitida al proveedor de servicios y para sustituir en un mensaje de respuesta de servicio procedente del proveedor de servicios la información de identificación ficticia por la información de identificación de (terminal de) usuario correspondiente. La identidad del (terminal de) usuario que solicita el servicio es ocultada al proveedor de servicios por el proveedor de acceso que sustituye la identidad con una identidad ficticia. Esto reduce significativamente la posibilidad de que se haga mal uso de información confidencial de privacidad por parte de proveedores de servicios. Como ya no es necesario pasar muchos detalles personales por Internet, se reduce significativamente la posibilidad de intercepción de tal información por terceros no autorizados. El uso de información ficticia hace posible el uso de menos comunicación segura entre el proveedor de acceso y el proveedor de servicios para muchas partes de la comunicación, garantizando al mismo tiempo un alto nivel de privacidad.
En una realización según la invención, la información de identificación de (terminal de) usuario incluye una dirección de red real, como una dirección IP o MSISDN, que identifica de manera única el terminal de usuario con respecto a la red de área amplia y/o al sistema de telecomunicación adicional, y en la que la información de identificación ficticia correspondiente incluye una dirección de red única diferente no usada como una dirección de red real por ninguno de los terminales de usuario. La dirección de comunicación del terminal de usuario está protegida. De esta manera se hace menos fácil enviar mensajes no deseados al terminal de usuario, como mensajes no solicitados (anuncios) o ataques de virus. Todos esos mensajes tienen que pasar a través del proveedor de acceso que puede usar criterios predeterminados para decidir cuándo permitir que pase un mensaje, convirtiendo la dirección ficticia en una dirección real para el (terminal de) usuario. Un criterio estricto podría ser sólo permitir la remisión de mensajes a un terminal de usuario que se refieran a solicitudes de servicios extraordinarios. Preferentemente, el usuario puede configurar el proveedor de acceso para controlar lo que se está pasando. Se apreciará que mientras que desde la perspectiva del proveedor de acceso la dirección del terminal de usuario se considera como la dirección real del terminal, en realidad puede que este no sea el caso. Por ejemplo, el usuario puede tener un sistema con varios terminales que se comunican en una red de área local, donde se provee acceso al sistema local a través de uno de los ordenadores (y usando su dirección), posiblemente en combinación con un cortafuego. En tal caso, la dirección real puede no ser la dirección del terminal que solicita el servicio sino que típicamente es una dirección de un dispositivo real en la misma ubicación y, como tal, provee información relevante a partes maliciosas.
En una realización según la invención, el proveedor de servicios está dispuesto para: generar un mensaje (en lo sucesivo una "cookie") con datos relacionados con un acceso previo al proveedor de servicios por parte de un terminal de usuario; enviar la cookie al terminal de usuario, y para una solicitud de servicio posterior, obtener la cookie del terminal de usuario para proveer un nuevo servicio personalizado; incluyendo el proveedor de acceso un espacio de almacenamiento para almacenar cookies enviadas por un proveedor de servicios en asociación con un (terminal de) usuario y para una solicitud procedente de un (terminal de) usuario de un servicio de un proveedor de servicios que proporciona la cookie del (terminal de) usuario al proveedor de servicios. El proveedor de acceso se usa para almacenar cookies (que son bien conocidas en Internet). Almacenando las cookies centralmente en o en asociación con el proveedor de acceso, se libera a los terminales de tener que almacenarlas. Esto permite el uso de terminales menos sofisticados, con menos capacidades de almacenamiento y procesamiento. También permite la administración centralizada de las cookies, como reglas para aceptar y desechar cookies.
En una realización según la invención, la cookie se almacena en asociación con la información de identificación ficticia asociada con un terminal (de usuario). La relación fijada entre la identidad real y ficticia de un usuario permite a los proveedores de servicios continuar entregando servicios personalizados, sin conocer la identidad real. La cookie todavía puede almacenar información específica del usuario, como partes del sitio Web que ha visitado el usuario en una etapa anterior, para permitir mejor acceso una próxima vez.
En una realización según la invención, la cookie se almacena en asociación con una identidad de usuario para permitir a un usuario asociado con la identidad de usuario obtener servicios personalizados iguales independientes de un terminal de usuario usado por el usuario. Almacenar las cookies centralmente permite al usuario usar la misma cookie para obtener servicio personalizado independientemente del terminal de usuario real usado por el usuario. En la arquitectura de Internet convencional, la cookie se almacena en el terminal de usuario. Como consecuencia, cuando un usuario usa un terminal diferente, la cookie no está presente allí o no está actualizada con las últimas actividades de un usuario. Este inconveniente se supera usando un espacio de almacenamiento central para la cookie. La cookie puede almacenarse en asociación con la identidad de usuario real o la identidad de usuario ficticia.
En una realización según la invención, el servicio está asociado con información de identificación de servicio virtual, como un URL, que está incluida en al menos un mensaje de solicitud de un terminal de usuario a un proveedor de servicios para identificar el servicio; incluyendo el proveedor de acceso: un espacio de almacenamiento para almacenar, para cada proveedor de servicios, una información asociada de identificación de servicio real para identificar el servicio con respecto a la red de área amplia; y un reescritor de URL para sustituir en el mensaje de solicitud procedente del terminal de usuario la información de identificación de servicio virtual con la información de identificación de servicio real correspondiente para remitir al proveedor de servicios y para sustituir en un mensaje del proveedor de servicios al terminal de usuario la información de identificación de servicio real por la información de identificación de servicio virtual correspondiente. La identidad del proveedor de servicios y el servicio están ocultos al (terminal de) usuario. Con este fin, el proveedor de acceso traduce una identidad de servicio virtual, tal como la ve el terminal, en una identidad real usada en Internet, y viceversa. Esto protege a los proveedores de servicios y sus servicios de los usuarios y, por tanto, reduce la posibilidad de ataques al servidor del proveedor de servicios. Por otra parte, dificulta al usuario sortear al proveedor de acceso y acercarse directamente al proveedor de servicios o sus servicios, posiblemente sin estar autorizado.
En una realización según la invención, el proveedor de acceso está dispuesto para identificar mensajes de solicitud de servicios asociados con información de identificación de servicio virtual a o desde un proveedor de servicios, y dirigir esos mensajes a través del reescritor de URL. El proveedor de acceso permite acceso directo a ciertos proveedores de servicios (por ejemplo, aquellos que no proveen servicios de pago o personalizados) sin ocultar esos proveedores de servicios. La protección de identidad sólo se produce para aquellos proveedores de servicios que lo requieren. Para hacer una distinción entre los dos grupos, el proveedor de acceso puede tener una lista de proveedores de servicios que requieren protección y, para cada solicitud de servicio por un terminal, comprobar esa lista. Preferentemente, el proveedor de servicios hace una primera distinción basada en un patrón predeterminado en la solicitud de servicio procedente del (terminal de) usuario. Si el patrón no está presente, se provee acceso sin protección. Si el patrón está presente, el proveedor de acceso intenta proteger la identidad sustituyéndola.
En una realización según la invención, el reescritor de URL está dispuesto para añadir parámetros en el mensaje de solicitud del terminal de usuario al proveedor de servicios para permitir al proveedor de servicios optimizar el servicio para el (terminal de) usuario. Durante la protección de la identidad del proveedor de servicios, se añade información adicional a la solicitud de servicio para permitir una mejor provisión del servicio. En una realización preferida, el proveedor de acceso añade información de ubicación como un parámetro en una solicitud de servicio. Se apreciará que la información de ubicación también puede proporcionarse al proveedor de servicios de otras maneras, por ejemplo usando mensajes separados. Añadir la información de ubicación como parámetros garantiza un procesamiento rápido y fiable por el proveedor de servicios. Como ejemplo de un servicio específico de ubicación, un cliente puede solicitar a un proveedor de contenido, mediante su terminal móvil, información acerca del tráfico o acerca de la ubicación de un restaurante en la misma área (o incluso región). A través del servicio de ubicación del operador de telecomunicaciones móviles se remite la ubicación del cliente a la compañía de servicios de contenido, y basándose en esa información de ubicación, el proveedor de servicios de contenido remite los datos específicos de ubicación o área o región, como el tráfico dependiente de la ubicación específica o información de restaurantes. Preferentemente, el proveedor de acceso reúne centralmente la información de ubicación en nombre de los proveedores de servicios. La determinación de la ubicación de un cliente puede hacerse mediante un módulo adicional que está conectado a o parte del proveedor de acceso y que está enlazado además a un sistema de comunicación que provee acceso como un sistema de telecomunicación móvil, por ejemplo una red GSM o GPRS o UMTS o cualquier red celular que pueda proveer información de ubicación basada en la estructura de celdas de la red. Donde se requiera, pueden usarse maneras más precisas de localizar a un usuario, como un sistema GPS/GLONASS. El servicio de ubicación de la posición puede ser tomado de o provisto por un tercero y ser remitido por el proveedor de acceso. Si se requiere, también pueden enviarse datos de ubicación desde el cliente al proveedor de contenido de terceros a través del proveedor de acceso. Tal información puede usarse entonces para más de un proveedor de servicios. Como ejemplo, la información para un terminal de usuario fijo tiene que ser proporcionada sólo una vez por el usuario y puede reutilizarse a partir de ese momento.
Para satisfacer este objeto de la invención, el proveedor de acceso a servicios para uso en un sistema incluye una interfaz de comunicación para comunicarse a al menos un proveedor de servicios por medio de una red de área amplia, en particular Internet, y para comunicarse a al menos un terminal de usuario por medio de un sistema de comunicación adicional, en el que el proveedor de acceso incluye un administrador de acceso a servicios para verificar si un terminal de usuario o un usuario de un terminal de usuario está autorizado para solicitar un servicio de un proveedor de servicios y tras verificación positiva permitir al terminal de usuario acceder al proveedor de servicios, liberando así al proveedor de servicios de tener que autorizar al (terminal de) usuario.
Para satisfacer este objeto de la invención, el procedimiento de proveer servicios a un terminal de usuario por medio de la red de área amplia, en particular Internet, incluye recibir, por medio de un sistema de comunicación adicional, desde un terminal de usuario un mensaje solicitando un servicio de un proveedor de servicios; verificar si el terminal de usuario o un usuario del terminal de usuario (en lo sucesivo "(terminal de) usuario") está autorizado para solicitar un servicio del proveedor de servicios, y tras verificación positiva, permitir al terminal de usuario acceder al proveedor de servicios a través de la red de área amplia, liberando así al proveedor de servicios de tener que autorizar al (terminal de) usuario.
Preferentemente, el sistema y el proveedor de acceso según la presente invención están implementados al menos en parte en un entorno informático. Ventajosamente, el procedimiento es llevado a cabo por un procesador, donde un producto de programa informático programado adecuadamente hace que el procesador lleve a cabo las etapas del procedimiento.
Resumiendo, la arquitectura según la invención provee, entre otras cosas:
-
acceso centralizado a los proveedores de servicios, que cubre identificación/autorización de (terminales de) usuario;
-
facturación centralizada para servicios de los proveedores de servicios;
-
protección/ocultación de la identidad de los (terminales de) usuario;
-
protección de los proveedores de servicios;
-
entrega de contenido centralizada de tipo almacenar y remitir; y
-
personalización de servicio, incluyendo dependencia de ubicación y almacenamiento de centralizado de cookies.
Todos estos aspectos pueden emplearse independientemente. Preferentemente, algunas o todas estas funciones están combinadas en el mismo subsistema. Ventajosamente, las funciones se proveen en combinación con ofrecimiento de acceso a Internet en el nivel físico, es decir, en o en cooperación con el dispositivo que conecta la red de acceso a Internet.
Estos y otros aspectos de la invención resultan evidentes y serán aclarados con referencia a las realizaciones descritas en lo sucesivo.
Breve descripción de los dibujos
En los dibujos:
La Fig. 1 muestra un diagrama del sistema según la invención,
La Fig. 2 muestra un diagrama de bloques del proveedor de acceso a servicios según la invención,
Las Figs. 3 y 4 representan un ejemplo de facturación centralizada según la presente invención;
La Fig. 5 muestra un diagrama de bloques de una realización preferida con terminales móviles de doble pila;
Las Figs. 6 a 8 muestran un organigrama de una realización preferida del procedimiento;
La Fig. 9 muestra un organigrama de facturación según la invención;
La Fig. 10 muestra una realización preferida más para terminales móviles; y
La Fig. 11 muestra el uso de información de ubicación.
Descripción detallada
La Fig. 1 muestra un diagrama del sistema según la invención. El sistema incluye un proveedor de acceso 100 que provee acceso a servicios provistos por proveedores de servicios (se muestran proveedores de servicios 110, 120 y 130), donde al menos parte de la invocación o entrega del servicio tiene lugar por medio de una red de área amplia 140. En el resto del documento, la red de área amplia se denominará Internet, siendo la red de área amplia preferida para el sistema. Se muestran dos terminales de usuario 150 y 160. El terminal 150 es un terminal móvil que se comunica con el proveedor de acceso al menos en parte por medio de una red de telecomunicaciones inalámbricas 170. El terminal 160 es un terminal fijo convencional, como un ordenador personal, que se comunica al proveedor de acceso 100 por medio de una red de acceso convencional 180, como una línea telefónica y conmutadores de telecomunicación o una red de cable (y líneas de telecomunicación fijas). Según la invención, un proveedor de acceso centralizado 100 controla el acceso a los proveedores de servicios 110 a 130. Como se describirá más detalladamente más adelante, el proveedor de acceso 100 puede dar soporte a los proveedores de servicios de muchas maneras diferentes. La centralización permite ahorro de costes, mayor seguridad, y uso simplificado por el usuario. Como ejemplo, el proveedor de acceso lleva a cabo las siguientes funciones:
a)
identificación del usuario (autenticación)
b)
concesión de acceso (autorización)
c)
enrutamiento seguro a los sistemas objetivo relevantes (enrutador de acceso)
d)
proveer datos de facturación (activador de facturación)
e)
comprobar crédito (comprobación de crédito) o comprueba la solvencia y la coherencia de solicitudes sucesivas
f)
proveer gestión adaptada (personalización)
g)
proveer un almacén de cookies
h)
proveer entrega segura de contenido digital.
El proveedor de acceso 100 se ocupa del acceso a nivel de servicio. Preferentemente, este papel se combina con proveer acceso a Internet a nivel físico. Si se desea, pueden mantenerse separados los dos tipos de provisión de acceso, donde el proveedor de acceso a servicios 100 se comunica con el proveedor de acceso físico (no mostrado por separado en la Fig. 1) por medio de alguna forma de comunicación, como conexión directa o por Internet. En el resto del documento, se asume que proveer acceso al nivel físico y a nivel de servicio se realiza mediante el mismo subsistema 100.
La Fig. 2 muestra un diagrama de bloques del proveedor de acceso a servicios 100 según la invención. En el ejemplo, el proveedor de acceso a servicios también provee acceso al nivel físico a Internet. As_such, el proveedor de acceso tiene una primera interfaz de comunicación 210 para comunicación hacia Internet (es decir, con los proveedores de servicios) y una segunda interfaz de comunicación 220 para comunicarse a los terminales de usuario por medio de una red de acceso. Como se apreciará, pueden estar implicadas más de dos interfaces. El proveedor de acceso 100 puede estar conectado directamente o integrado con un centro de conmutación/enrutamiento de telecomunicación. Tales aspectos no son relevantes para la invención y por tanto no se analizan más. El proveedor de acceso está implementado preferentemente en una plataforma informática equipada con uno o más procesadores que, programados adecuadamente, realizan las funciones según la invención. La plataforma se escoge preferentemente de las plataformas disponibles en general optimizadas para funciones de telecomunicación o funciones de Internet. La plataforma incluye un espacio de almacenamiento de segundo plano 240, implementado típicamente en discos duros, como un sistema RAID, una memoria principal, una interfaz de usuario para permitir el control y respuesta por parte del operador, y cualquier hardware corriente usado en tales sistemas informáticos, como interfaces de entrada/salida y lógica de control.
El proveedor de acceso incluye un administrador de acceso 230. El administrador de acceso verifica si un usuario o terminal de usuario está autorizado a acceder a servicios provistos por los proveedores de servicios 110 a 130. La autorización puede implicar identificar el terminal, por ejemplo basándose en una identificación electrónica del terminal como se usa en la red de acceso. Un ejemplo de tal identificación es MSISDN (número de estación móvil de la red digital de servicios integrados) u otra identificación adecuada provista por la red de acceso 170, 180. También puede añadirse un esquema de identificación de terminal específico (en hardware o software seguro) en el terminal para generar tal identificación independiente de la red de acceso. Para ciertos servicios (por ejemplo, servicios costosos) puede no requerirse o no ser suficiente la identificación del terminal, pero puede requerirse identificación del usuario. Esto puede ser realizado por el usuario introduciendo una identificación de usuario (por ejemplo, nombre de usuario o nombre de cuenta) o, para aplicaciones muy seguras, puede ser reunida por el terminal y provista al administrador de acceso 230 información más fiable, como datos biométricos, como una huella dactilar o una huella vocálica. Además de la identificación, pueden requerirse datos de autorización explícita, por ejemplo, introduciendo el usuario una contraseña. Si la identificación fue suficientemente fiable (por ejemplo, usando datos biométricos), los datos de autorización pueden estar implícitos en los datos de identificación. Para aplicaciones de alta seguridad, los datos de identificación y/o autorización pueden ser autenticados usando cualquier esquema (cifrado) de autenticación conocido en la técnica. El administrador de acceso comprueba si el terminal o usuario identificado está autorizado a acceder a servicios comprobando los datos almacenados en el espacio de almacenamiento 240 para el (terminal de) usuario identificado. Si el resultado es positivo, se permite el acceso al servicio. Si el proveedor de acceso a servicios también es el proveedor de acceso físico, la autorización puede tener lugar permitiendo al usuario acceder a Internet en general. Entonces se autoriza cualquier acceso a Internet a través de este proveedor de acceso. Si el proveedor de servicios no es el proveedor de acceso físico, el proveedor de acceso a nivel de servicio puede ordenar al proveedor de acceso a nivel físico que provea acceso, o comunicar la autorización del (terminal de) usuario a los proveedores de servicios.
Preferentemente, una autorización satisfactoria permite al usuario acceder a servicios del proveedor de servicios implicado (o preferentemente todos los proveedores de servicios, siempre que los créditos no hayan expirado) durante la misma sesión de comunicación que comenzó por la identificación del usuario (de cualquier forma adecuada, como nombre de usuario convencional, introducción de contraseña o por medio de identificación electrónica). El administrador de acceso usa una "Comprobación de suscripción" para determinar si el usuario se ha suscrito al servicio solicitado (o a servicios en general). Si el resultado es positivo, se concede acceso. Si no, la solicitud de servicio es remitida a una aplicación especial para suscripción a servicios. Esta aplicación lleva al usuario a través de un procedimiento de suscripción, que culmina en una suscripción para el usuario. En este punto, el administrador de acceso remite entonces la solicitud del usuario al servicio suscrito. Esto significa que el proveedor de contenido ya no tiene que preocuparse de la administración de usuarios.
En una realización preferida, la comunicación entre el proveedor de acceso a servicios 100 y los proveedores de servicios 110-150 se realiza de manera segura. En particular, se asegura la información sobre autorización de un (terminal de) usuario. Puede usarse cualquier técnica adecuada para asegurar la comunicación, por ejemplo usando las técnicas ya usadas para enlaces seguros por Internet (por ejemplo, SSL o VPN).
En una realización preferida, la facturación en el sistema para provisión de los servicios se provee centralmente mediante un administrador de facturación. La Fig. 2 muestra que el administrador de facturación 250 también es parte del proveedor de acceso 100. Para integración óptima, el administrador de facturación 250 puede ser parte del administrador de acceso 230. Se apreciará que el administrador de facturación central pues también estar separado del administrador de acceso a nivel de servicio central y separado del administrador de acceso a nivel físico. El administrador de facturación 250 comprueba la solvencia del usuario asociado con el terminal de usuario. El administrador de acceso 230 provee acceso a los servicios sólo con un resultado positivo. Las comprobaciones de solvencia pueden ser sólo para un servicio específico, o para todos los servicios, posiblemente hasta un nivel de crédito acordado. El administrador de facturación puede realizar las comprobaciones de solvencia verificando datos de solvencia (por ejemplo, nivel de crédito acordado, facturas extraordinarias, etc.) disponibles en el espacio de almacenamiento 240 en asociación con el usuario o terminal de usuario. La comprobación de solvencia real también puede ser realizada por un tercero, donde el administrador de facturación provee al tercero la información relevante, como identificación de usuario y nivel de crédito que ha de verificarse. La función de comprobación de solvencia comprueba en una base de datos, que está almacenada preferentemente en el espacio de almacenamiento 240, si el usuario tiene suficiente crédito para poder usar el servicio solicitado. Si el usuario es suficientemente solvente, la solicitud es procesada y remitida al proveedor de contenido pertinente. Si el usuario no tiene suficiente crédito, el usuario es informado de que su crédito ha vencido y no puede usar el servicio solicitado. De esta manera, al administrador de acceso garantiza que sólo pueden usarse aquellos servicios para los que el usuario solicitante dispone de crédito suficiente.
Preferentemente, el administrador de facturación genera registros de facturación necesarios para la facturación real. Esto puede hacerse añadiendo los costes relacionados con el servicio a los costes implicados en la obtención de acceso a Internet, o al usar la red de acceso como tal. Esos costes son facturados normalmente por el proveedor (de acceso físico) de telecomunicaciones. En particular, si el administrador de facturación es parte de o está relacionado con el sistema que provee acceso a nivel físico, la integración ambos tipos de facturación puede lograrse fácilmente. Si el administrador de facturación está separado, el administrador de facturación puede realizar facturación centralizada para los propios servicios, o puede usar terceros (por ejemplo, una compañía de tarjeta de crédito, una institución bancaria, o un operador de telecomunicaciones).
La facturación puede realizarse dependiendo del tipo de cliente. Con los nuevos servicios emergentes existentes, como Hi site SMS, servicios WAP y comercio móvil, a todos los cuales se accede usando teléfonos celulares, la facturación de los servicios se vuelve más y más compleja. Además, algunos servicios sólo están disponibles para clientes llamados de pospago, es decir, clientes de suscripción, y las tarifas para un servicio específico pueden ser específicas de la suscripción (por ejemplo, gratis para suscriptores de mayor categoría, de pago para suscriptores de menor categoría). Esto conduce normalmente al desarrollo de una arquitectura diferente por servicio para hacer frente a estas diferencias, ya que el proveedor de contenido normalmente no está al tanto de los privilegios del cliente. Actualmente se están introduciendo nuevas maneras de pagar productos y servicios a través de medios de telecomunicación móvil. Los productos incluyen, por ejemplo, bebidas obtenibles de un distribuidor en un lugar público, mientras que los servicios pueden ser, por ejemplo, espacio de aparcamiento o entradas de cine. Dentro de poco se dispondrá también de la llamada banca móvil. Estos sistemas se basan en una cuenta de suscriptor, que puede usarse para pagar productos y/o servicios usando un teléfono celular. Para liberar a los proveedores de servicios (proveedores de contenido) de tener que ocuparse de todos los tipos de clientes diferentes, donde cada tipo tiene un conjunto asociado de datos de facturación, según la arquitectura de la invención, de esto se hace cargo el administrador de facturación centralizada 250.
En una realización preferida, sólo se produce facturación para bienes/servicios que han sido provistos. Donde se provee contenido digital, el proveedor de acceso físico simplemente puede comprobar que tal contenido ha sido provisto al (terminal de) usuario a través de la red de acceso e informar en consecuencia al administrador de facturación 250. Para entrega de bienes o servicios de otra manera, el proveedor de servicios puede proveer tal información al administrador de facturación 250, preferentemente de una manera segura. Una función de comprobación de entrega del administrador de acceso comprueba si una respuesta del proveedor de servicios de contenido incluye un código de error http. Si se recibe un código de error, se genera un mensaje de error para el (terminal de) usuario y no tiene lugar facturación real. Si no hay error, la respuesta del proveedor de contenido es devuelta al dispositivo terminal y se activa la facturación en paralelo a esto. Una función de "facturación" del proveedor de acceso notifica al administrador de facturación 250 la entrega satisfactoria de contenido, y proporciona los datos de facturación.
Ventajosamente, el contenido electrónico es entregado a través del administrador de acceso en modo de almacenar y remitir. Esto significa que el proveedor de servicios entrega el contenido al proveedor de acceso 100, que lo almacena temporalmente en él en el espacio de almacenamiento 240, antes de pasarlo al terminal de usuario. De esta manera, puede superarse cualquier alteración en la red de acceso que pueda pasar desapercibida para el proveedor de servicios. Para datos de reproducción simultánea a la descarga, el proveedor de acceso 100 puede almacenar en memoria intermedia sólo una cantidad relativamente pequeña de datos (por ejemplo, en el intervalo de segundos a unos pocos minutos) para evitar requerir demasiado espacio de almacenamiento. Tal periodo debe escogerse de manera que el usuario pueda reanudar normalmente el consumo de los datos dentro de ese periodo de tiempo y que el proveedor de servicios pueda terminar de manera fiable la entrega para reanudación en un momento posterior. Se apreciará que la entrega de contenido en tiempo real (por ejemplo un acontecimiento deportivo) no puede detenerse de tal manera. Para tal contenido se prefiere que el proveedor de acceso almacene más datos. El mecanismo de almacenar y remitir permite al sistema determinar con exactitud qué contenido ha sido entregado realmente para que sólo tal contenido se cargue realmente al usuario.
Ejemplo 1 Facturación de contenido de SMS por UCP
La Figura 3 ilustra la facturación para el caso específico de facturación de SMS. Un cliente 320 envía una solicitud de un servicio de contenido, en este caso un mensaje SMS (1). Este mensaje es enviado por el proveedor de servicios de telecomunicación 322 a un proveedor de contenido 323. El proveedor de servicios de telecomunicación actúa entonces como el proveedor de acceso según la invención. El proveedor de contenido 323 reacciona al mensaje enviando el contenido deseado al administrador de facturación 324 por medio del mensaje 302. El administrador de facturación 324 comprueba si el cliente tiene derecho al servicio de contenido. Si se permite, el contenido es enviado al cliente usando enlaces 304 y 305. El servidor de pago/facturación 327 se ocupa de cargar la cuenta de prepago del cliente, o envía un SDR (registro de detalle de servicio) a los servicios de facturación del proveedor de servicios de telecomunicación para incluir el servicio de contenido en la siguiente factura para el cliente de pospago. Es preferible incluir los convertidores 325 y 326 que transforman mensajes UCP en mensajes XML y viceversa dentro del módulo proveedor de acceso, ya que esto permite un lenguaje unificado estándar como XML dentro del módulo proveedor de acceso/de pago/servidor de facturación, y también es útil para ocuparse de solicitudes en diferentes idiomas, ya que estas solicitudes serán traducidas por los convertidores 325 y 326.
Ejemplo 2 Facturación de contenido de WAP
La Figura 4 ilustra la facturación para el caso específico de servicios WAP. Aquí de nuevo la solicitud de un servicio de contenido, en este caso una solicitud WAP, es enviada a un sitio del proveedor de contenido (sitio de CP) 423 por medio del enlace de mensaje WML 406. Estas solicitudes son directas y el cliente 420 puede seleccionar la información que necesita navegando por el sitio del proveedor de contenido 423, o cambiar el proveedor de contenido 423 cuando no encuentra la información que necesita. Una solicitud de un servicio de contenido de pago transferirá al cliente 420 a un sitio del portal de pago 428 usando el enlace de mensaje WML 407. El sitio del portal de pago 428 recibe datos del proveedor de contenido 423 (por ejemplo cantidad, número de identificación de transacción y código de proveedor de contenido) por medio del enlace de mensaje WML 408. El cliente 420 será autenticado en el sitio de portal de pago 428 y se le solicita que confirme el pago. Cuando el cliente está de acuerdo, se inquirirá al servidor de pago/facturación que compruebe si el cliente tiene derecho al servicio por medio del enlace XML 409, el convertidor 426 y el enlace XML al administrador de facturación 424. Si la respuesta es afirmativa, el pago se efectuará como se describió más arriba y el proveedor de contenido 423 recibirá una confirmación del pago por medio del enlace de mensaje WML 410. El cliente será redirigido al sitio del proveedor de contenido para recibir los servicios de contenido solicitados por medio del enlace de mensaje WML 406.
A partir de los ejemplos quedará claro que la facturación de la presente invención puede adaptarse fácilmente a servicios de contenido distintos a los ilustrados por las figuras y ejemplos. Más particularmente, usando una sola arquitectura puede implementarse fácilmente SMS, Hi site SMS, UMTS, WAP, servicios bancarios, servicios de crédito, pago in situ de servicios (por ejemplo, aparcamiento) o productos (por ejemplo, dispensador de bebidas). También pueden cargarse las cuentas de suscriptores usando el procedimiento de la invención, cuentas internas (es decir, cuentas que residen en el proveedor de servicios de telecomunicación) así como cuentas externas (por ejemplo, compañías de tarjetas de crédito).
El proveedor de acceso tiene como objetivo ocuparse de proveer el servicio de contenido al cliente y de los temas de pago. El servidor de pago/facturación 27 permite inquirir datos del cliente y efectúa el pago. Preferentemente, los costes de transporte de telecomunicación por proveer el servicio se facturan por separado. Esto puede implementarse fácilmente usando un servidor de tarificación. Esto es necesario porque no todo el tráfico generado por la solicitud de contenido será tráfico normal, facturable por el proveedor de servicios de telecomunicación, sino que puede ser, por ejemplo, tráfico de Internet.
Como se describió anteriormente, después de la identificación satisfactoria, el dispositivo terminal puede ser reconocido y el usuario autorizado. En el sistema según la invención, el proveedor de acceso incluye un convertidor de identidad 260. En una solicitud procedente de un (terminal de) usuario, el convertidor de identidad 260 sustituye la información de identificación del (terminal de) usuario con información de identificación ficticia asociada. La información ficticia se almacena en el espacio de almacenamiento 240 en asociación con el usuario o el terminal de usuario. En la respuesta del proveedor de servicios, la información ficticia es sustituida por la información real. La información de identificación incluye la dirección del terminal con respecto a Internet (es decir, la dirección IP). Preferentemente, el convertidor de identidad 260 también sustituye otra información de identificación, como el nombre y dirección del usuario. Por tanto, se asigna al usuario una ID de usuario anónimo (en los sucesivo también "XID"). Esta ID de usuario es válida para todo el procesamiento posterior y también es transmitida al proveedor de servicios de contenido. De este modo nunca se transmite información personal del administrador de acceso a los servicios posteriores y se mantiene el anonimato del usuario. Esta ID de usuario anónimo es escrita dentro de la cabecera http por el convertidor de identidad 260 del administrador de acceso 230. El administrador de acceso extrae toda la información personal de la cabecera http y la sustituye añadiendo la ID de usuario anónimo. Una vez que ha tenido lugar esta modificación, la solicitud es anónima. El administrador de acceso puede poner la información de identificación ficticia a disposición de ciertos proveedores de contenido, de manera que el proveedor de contenido puede compilar el historial de un usuario específico u ofrecer una variedad de usuarios específicos sobre una base anónima.
Preferentemente, los datos personales del usuario ficticio son independientes del terminal real usado por el usuario. De esta manera, puede asignarse la misma identidad ficticia a un mismo usuario para más de un terminal. De esta manera, pueden proveerse servicios personalizados independientemente del terminal real que se use. Con este fin, el espacio de almacenamiento 240 puede almacenar los datos personales ficticios en asociación con más de un terminal. Tal asociación puede lograrse de muchas maneras, como es sabido por los expertos en la materia, por ejemplo asociando datos personales ficticios a datos de identificación de terminal por medio de punteros.
En una realización preferida, el proveedor de acceso incluye un espacio de almacenamiento (por ejemplo, el espacio de almacenamiento 240) para almacenar cookies en nombre del dispositivo terminal. El proveedor de servicios genera la cookie en respuesta al acceso por parte del usuario. La cookie contiene información que permite al proveedor de servicios optimizar el servicio para el usuario (por ejemplo, la cookie indica áreas de preferencia del usuario, como partes del sitio Web visitadas por el usuario). Las cookies son conocidas en sí mismas. Según la invención, el proveedor de acceso 100 extrae la cookie de la cabecera de respuesta del mensaje de respuesta de proveedor de servicios (en respuesta a una solicitud por parte del (terminal de) usuario y almacena la cookie en un almacén denominado de cookies. Este almacén de cookies guarda la cookie recibida hasta que expira su validez. Si se hace una solicitud de un URL de un proveedor de servicios que ha enviado una cookie previamente, se añade la cookie para ese URL específico. Si la siguiente solicitud se recibe de ese dispositivo terminal, el proveedor de acceso añade la cookie a la cabecera de solicitud y después envía la solicitud, incluyendo identificación de sesión, al sistema de destino como contexto de cookie.
Ventajosamente, la cookie se almacena en asociación con la identidad de usuario ficticia. Preferentemente, el proveedor de acceso usa la misma cookie independientemente del terminal real que es usado por el usuario. Con este fin, pueden usarse técnicas de punteros para almacenar la cookie en asociación con la identidad de usuario (ficticia) independiente de la ID de terminal real.
En una realización más, el proveedor de acceso 100 está dispuesto para proteger a los proveedores de servicios hacia los usuarios. Cada servicio está asociado con información de identificación de servicio virtual. En Internet se usa normalmente un URL (Localizador universal de recursos) para identificación. El URL virtual se incluye en el mensaje de solicitud de un terminal de usuario a un proveedor de servicios para identificar al proveedor de servicios y al servicio. El espacio de almacenamiento 240 almacena para cada servicio una información de identificación de servicio real asociado (por ejemplo su URL real) para identificar al servicio con respecto a la red de área amplia. El proveedor de acceso 100 incluye un reescritor de URL 270 que sustituye en el mensaje de solicitud procedente del terminal de usuario el URL virtual con el URL real correspondiente para remitir al proveedor de servicios. El reescritor de URL también sustituye en un mensaje del proveedor de servicios al terminal de usuario el URL real por el URL virtual correspondiente. Se apreciará que en lugar de URLs también puede usarse otra información de identificación, según prescriban los protocolos que se empleen.
Preferentemente, el proveedor de acceso puede distinguir rápidamente entre mensajes de/a proveedores de servicios protegidos y no protegidos. Los mensajes que tienen que ser protegidos son dirigidos a través del reescritor de URL, otros mensajes se pasan sin modificar con respecto al URL del proveedor de servicios. Puede hacerse una distinción rápida basada en un patrón predeterminado en el URL protegido. El patrón debe escogerse de manera que normalmente no se produzca en URLs, por ejemplo una secuencia razonablemente larga de caracteres usados rara vez.
En una realización preferida, el reescritor de URL añade parámetros en el mensaje de solicitud al proveedor de servicios para permitir que el proveedor de servicios optimice el servicio para el (terminal de) usuario. Este parámetro puede ser, por ejemplo, información de identificación de usuario real o ficticia. Preferentemente, el reescritor de URL también añade datos de ubicación, que identifican la ubicación del usuario. Con este fin, el sistema incluye un localizador 280 para recuperar información sobre una ubicación de un (terminal de) usuario para permitir al proveedor de servicios proveer un servicio dependiente de la ubicación a un (terminal de) usuario. Los datos de ubicación real pueden ser provistos por terceros, como una red de acceso móvil o un sistema GPS.
Como apreciarán las personas expertas en la materia, preferentemente las mejoras indicadas anteriormente están todas combinadas en un proveedor de acceso. Si se desea, las mejoras también pueden usarse por aislado, ya sea en o en cooperación con el proveedor de acceso físico. A continuación se ofrece una descripción de un mejor modo de operación. En esta realización, como también se muestra en la Figura 5, se usa un terminal móvil 500 que soporta tanto una pila WAP 502 como una pila i-mode 504 para acceder a proveedores de servicios a través de Internet 520. La figura ofrece una visión general de la arquitectura. Muestra un proveedor de acceso de doble pila 530 (también denominado pasarela) lógicamente con dos partes principales -la doble pila-, que contienen una pila i-mode y una pila WAP, y también los módulos de servicio que se necesitan para proveer diversos servicios tanto para i-mode como para WAP. La pasarela de doble pila está conectada a la red de acceso móvil 540 así como a Internet 520 y atiende a solicitudes WAP e i-mode de los proveedores de servicios que usan el sistema/pasarela de acceso centralizado. Las Figs. 6 a 8 muestran detalles del procedimiento según la invención como el descrito más detalladamente a continuación. Las Figs. 6 y 7 muestran el flujo desde el terminal hasta el proveedor de servicios. La Fig. 8 muestra el flujo inverso.
En la pasarela, un gestor de autenticación de función es responsable de verificar si el usuario está autorizado a acceder al contenido solicitado. Para este propósito se llevan a cabo varas comprobaciones adicionales:
- Identificación/autenticación de usuario (610)
- Comprobación de sesión (630, 640)
- Comprobación de estado de usuario (650)
- Comprobación de URL (700)
- Comprobación de suscripción (710)
- Comprobación de crédito, facturación (730, 820).
Identificación/autenticación de usuario
El proveedor de acceso (pasarela) provee un mecanismo para autenticar usuarios al inicio de una sesión. Si la sesión se inicia desde un terminal móvil, por ejemplo una sesión WAP o i-mode, esto se hace comprobando el MSISDN, o una combinación de MSISDN con un nombre de usuario y contraseña (son posibles contraseñas global y personal). La información es extraída de la cabecera en la etapa 620 de la Fig. 6. Un terminal de usuario preferido soporta tanto i-mode como WAP. Después, los usuarios de i-mode son autenticados de la misma manera que los usuarios de WAP, con su MSISDN (o un número o formato equivalente). El usuario no tiene que realizar diferentes tareas para acceder a servicios WAP que para acceder a servicios i-mode. La pasarela adquiere el MSISDN y la dirección IP del usuario de la red durante la fase de establecimiento de sesión, tanto para solicitudes i-mode como WAP, es decir mediante contabilización Radius. Como se ha descrito anteriormente, la identidad del usuario también puede ocultarse sustituyéndola con una identidad de usuario ficticia. Esto se muestra en la etapa 610.
Gestor de sesión
El gestor de sesión es una parte del módulo de autenticación (administrador de acceso) y responsable de comprobar si una solicitud pertenece a una solicitud llevada a cabo durante un periodo de tiempo muy específico. Con este fin, en la etapa 630 de la Fig. 6 el gestor de sesión analiza la cabecera de solicitud para una cookie de objeto de sesión interna, por ejemplo, que contiene la identificación de sesión generada por el gestor de sesión. Si no se dispone de información de sesión en un dispositivo terminal particular, el gestor de sesión genera un número aleatorio y reúne información extraída de la cabecera de solicitud. La siguiente información es provista por la cabecera de solicitud: URL, Agente de usuario, Cookie, XID (es decir, la identidad de usuario ficticia), Idioma y Marca de fecha y hora. Estos datos se almacenan y siguen siendo válidos durante un periodo de tiempo específico. Si no llegan nuevos datos durante este periodo de tiempo, los datos se borran.
El gestor de sesión recibe ahora una solicitud que incluye una identificación de sesión (SID). Para comprobar si la sesión es válida, el gestor de sesión examina los datos almacenados para la sesión mientras estaba siendo creada la sesión de identificación previa. Si existe información de sesión y los datos se corresponden con los datos proporcionados por la cabecera http, se considera que la sesión es válida. Si hay una discrepancia, la sesión y la solicitud se consideran no válidas, y son tratadas como una solicitud sin identificación de sesión. La pasarela puede realizar gestión de sesión para solicitudes i-mode, procedentes del terminal de usuario. Las sesiones se establecerán del terminal a la pasarela y de la pasarela al proveedor de servicios.
Gestor de situación
Si la sesión es válida, el estado del usuario se verifica en la etapa 650 de la Fig. 6. Son posibles los siguientes estados: registrado, potencial, o bloqueado. El estado "potencial" se aplica donde un dispositivo terminal no ha tenido previamente contacto con el administrador de acceso y por lo tanto no se le ha concedido ningún derecho. Si el administrador de acceso recibe una solicitud, que lleva el estado de usuario "potencial", la solicitud será redirigida a una aplicación, que captura los datos de usuario relevantes y posteriormente actualiza el estado a "registrado". Si al cliente se le deniega el acceso al propio administrador de acceso o a servicios posteriores, el estado es "bloqueado". El mensaje de error aparece en el idioma usado por el usuario para introducir sus datos (estado potencial). Si el estado es "registrado", la solicitud se presenta a la función "Identificación".
Gestor de servicio
El gestor de servicio comprueba si hay una cadena coincidente dentro del URL (solicitud http) en la etapa 700 de la Fig. 7. Esta cadena es ajustable, y se lee por ejemplo portalmmm.i-mode. Si no puede encontrarse la cadena coincidente en el URL de solicitud, la función "Identificación de servicio" decide que esta solicitud no está dirigida a los proveedores de contenido que usan los servicios del administrador de acceso. Es más probable que sea una solicitud que debe pasarse a Internet sin más examen. Si se encuentra la cadena coincidente dentro del URL de solicitud, el gestor de servicio decidirá ahora si debe pasarse la solicitud a un proveedor de contenido que usa los servicios del administrador de acceso, o si debe pasarse a una aplicación para capturar más datos de usuario. Esto es lo que ocurre por ejemplo cuando se detecta el estado "potencial", o el usuario desea suscribirse a nuevos servicios o cancelar antiguos servicios. Si el gestor de servicio reconoce la cadena coincidente, usará el URL correspondiente para que el sistema de destino cree una conexión entre él y el proveedor de contenido. El URL de solicitud con la cadena coincidente será reescrito por consiguiente en el URL de destino del proveedor de contenido (reescritura de URL) en la etapa 730. Esto tiene una ventaja de que el URL del proveedor de contenido no es visible en ningún momento -ni a través de la solicitud, ni a la recepción- ya que la respuesta del proveedor de contenido también es modificada de una manera que el URL devuelto al dispositivo terminal contiene la cadena coincidente. Desde un punto de vista de la seguridad, este comportamiento divide la solicitud del usuario y la solicitud final en dos tareas independientes. La función "Reescritura de URL" impide que el URL del proveedor de contenido sea publicado en ningún momento, ya que sólo es conocido por el administrador de acceso y el proveedor de contenido. Por consiguiente, este procedimiento de operación impide ataques directos, por ejemplo ataques directos sobre el proveedor de contenido. Aparte de eso, la reescritura de URL aumenta la velocidad del procedimiento bastante considerablemente, ya que el procedimiento de comprobar si una solicitud se refiere a Internet o a un proveedor de contenido sólo implica comprobar la cadena coincidente y no calificar el URL completo. Como parte de la reescritura del URL, la pasarela soporta mecanismos para permitir la personalización de páginas de usuario. Con este fin, la función Reescritura de URL agrega parámetros a la solicitud de URL (es decir, MSISDN, UID, etc.). Preferentemente, la pasarela recupera información sobre la ubicación del usuario o terminal de usuario y añade esta como un parámetro. La información de cabecera superflua es eliminada (especialmente si la solicitud ha de ser transmitida por medio de una conexión no segura a Internet). La función Reescritura de URL también neutraliza la respuesta del proveedor de servicios como se muestra en la etapa 830 de la Fig. 8 retraduciendo el URL real a un URL virtual.
Enrutador de acceso
La función "Enrutador de acceso" modifica el URL y la cabecera según los resultados de comprobaciones precedentes y envía la solicitud al proveedor de servicios deseado o a la aplicación necesaria. La conexión al proveedor de servicios puede asegurarse criptográficamente, por ejemplo usando un túnel SSL (capa de conexión segura) o una red privada virtual (VPN).
Control de acceso
El sistema almacena una "lista negra" de proveedores de servicios, que son proveedores de servicios que por diversas razones no son accesibles a través del sistema. También se almacena una "lista blanca" de sitios (WAP o i-mode). Puede concederse acceso a esos sitios si se cumplen todas las demás condiciones. Igualmente, se mantiene una lista negra de usuarios (por ejemplo, los que no pagaron o hicieron mal uso del sistema) y una lista blanca de usuarios (los que en principio pueden obtener acceso).
Servidor intermedio de contenido proporcionado por un proveedor de servicios
La pasarela recibe solicitudes de usuarios de WAP e i-mode. Interpreta estas solicitudes y en nombre del terminal de usuario solicita el contenido del proveedor de servicios. Hace esto estableciendo una conexión HTTP o HTTPS al proveedor de servicios para recuperar el contenido. Después el contenido será traducido a formato WAP binario para usuarios de WAP o a i-html para usuarios de i-mode y proporcionado al terminal. Preferentemente, la pasarela también soporta protocolos de envío WAP estándar (PAP, POTAP) donde el SMS puede usarse como un portador. Preferentemente, la pasarela también se encarga de solicitudes de correo electrónico i-html procedentes de usuarios de i-mode. Ventajosamente, la pasarela debe proveer una interfaz a un SMSC (Centro de servicios de mensajes cortos) para enviar y recibir mensajes a/desde un SMSC. Hacer de servidor intermedio permite la comprobación fácil de la entrega como se muestra en la etapa 810 de la Fig. 8. La confirmación de la entrega activa la facturación 820.
Facturación
Para facturar, la pasarela diferencia entre usuarios con perfiles de servicios diferentes, es decir, para prepago y pospago. La activación real para la facturación ocurre en la etapa 820 de la Fig. 8. La Fig. 9 muestra un diagrama de flujo de una realización del presente procedimiento implementado para entrega de mensajes SMS por un proveedor de contenido 23. El flujo puede dividirse en dos partes interrelacionadas, la Función de conmutación de servicio (SSF) y la Función de control de servicio (SCF). La parte de SSF recibe un mensaje del proveedor en el bloque 40 y busca los datos que son necesarios para procesar correctamente el mensaje de una manera administrativa. Estos datos se envían a la SCF. La función de control de conmutación comprueba primero si el cliente es un suscriptor de prepago en el bloque de decisión 50. Si el cliente es un suscriptor de prepago, se busca el valor del saldo en el bloque 51 y en el bloque de decisión 52 se comprueba si el saldo es suficiente. Si hay saldo suficiente, se envía un mensaje "SEGUIR" a la SSF (bloque 54). Si no hay saldo suficiente, se envía un mensaje "NO SEGUIR" a la SSF (bloque 53) y se finaliza el flujo de la SCF. Entretanto, la función SSF ha esperado una respuesta de la SCF en el bloque 41. En el bloque de decisión 42, se comprueba la respuesta. Cuando es negativa (NO SEGUIR), se envía un acuse de recibo negativo (NACK) al proveedor en el bloque 43 y finaliza el flujo de la SSF. Cuando la respuesta es positiva, el mensaje es convertido y enviado a un centro de SMS en el bloque 44. Después de eso, la función SSF esperará una respuesta del centro de SMS en el bloque 45, y después de recibir la respuesta, esta respuesta del centro de SMS se envía a la SCF en el bloque 46. Cuando la respuesta del centro de SMS es positiva (comprobación en el bloque de decisión 47), se envía un acuse de recibo positivo (ACK) al proveedor en el bloque 48 después del cual finaliza el flujo. Cuando la respuesta del centro de SMS es negativa (comprobación en el bloque de decisión 47), se envía un acuse de recibo negativo (NACK) al proveedor en el bloque 49 después del cual finaliza el flujo. Cuando la SCF recibe la respuesta del centro de SMS (después de esperar en el bloque 55) comprueba en el bloque de decisión 56 si la respuesta en positiva. Si la respuesta es negativa, finaliza el flujo de la SCF. Si la respuesta es positiva, se comprueba de nuevo en el bloque de decisión 57 si el cliente es un cliente de prepago. Si este es el caso, se reduce el saldo la cantidad apropiada en el bloque 58. Cuando el cliente es un suscriptor de pospago, el flujo continúa directamente al bloque 59, en el que se escribe un registro detallado de llamadas (CDR) en la SMI, después de lo cual finaliza el flujo. Por lo tanto, la cantidad por el servicio sólo será cargada cuando la transacción del mensaje ha tenido lugar realmente.
La Fig. 10 muestra una realización de la invención, con un proveedor de acceso (sistema mediador de servicios) que está implementado para un operador de telecomunicaciones móviles y que se describe sobre la base de un módulo de software Intermediario de mensajes. En la situación existente, el proveedor de contenido/servicios 23 se comunica directamente con el cliente 20 por medio del centro de SMS 23, como se indica por la flecha 30. El intermediario de mensajes puede ser uno cualquiera de los productos intermediarios de mensajes disponibles comercialmente de las principales compañías de software. Un ejemplo puede ser el producto destacado de la compañía Sybase (NEON). El intermediario de mensajes está dividido en una capa de protocolo 31 y una capa intermediaria de mensajes 33. La capa intermediaria de mensajes 32 está conectada a un módulo SMSc 33 y a la Memoria de datos operacionales de la base de datos de clientes (ODS) 34, y al Sistema de facturación de prepago 35. La capa de protocolo 31 está dispuesta para comunicación con un sistema proveedor de contenido 23 y puede comunicarse con él por medio de un protocolo UCP y un protocolo XML. La capa de protocolo 31 y la capa intermediaria de mensajes 32 pueden comunicarse entre sí por medio de un protocolo rápido interno. La capa intermediaria de mensajes 32 puede comunicarse con el módulo SMSc 33 por medio de protocolo UCP y a la Memoria de datos operacionales de la base de datos de clientes (ODS) 34 por medio del protocolo LDAP (Protocolo ligero de acceso a datos), y al Sistema de facturación de prepago 35 por medio del protocolo UCP y el protocolo XML. En una realización más, la capa intermediaria de mensajes 32 también puede comunicarse con un servidor base de ubicación 36 usando un protocolo adecuado. El centro de SMS 33, la Memoria de datos operacionales de la base de datos de clientes (ODS) 34, el sistema de facturación de prepago 35, y el servidor base de ubicación 36 también pueden comunicarse con un servidor de segundo plano 37 del proveedor de servicios de telecomunicación. El servidor de segundo plano 37 está dispuesto entre otras cosas para controlar y actualizar los otros elementos del presente sistema.
El mediador de servicios 24 puede comprobar el estado del cliente preguntando a la Memoria de datos operacionales 34. Usando como entrada el número MSISDN del cliente 20 (código de país, código de proveedor de telecomunicación y número de serie, por ejemplo 31653123456), la Memoria de datos operacionales responderá con el estado del cliente (marcas de prepago, pospago, ninguno, o bloqueado). Cuando la memoria de datos operacionales 34 responde con el estado "ninguno", ese cliente particular no es un suscriptor del proveedor de telecomunicaciones que opera el mediador de servicios 24. También es posible que a un suscriptor conocido le serán bloqueados ciertos servicios por varias razones. Esta situación será indicada por la Memoria de datos operacionales 34 usando las marcas boqueadas.
Información de ubicación
En la Fig. 11 se muestra un diagrama esquemático en el que se usa información de ubicación del cliente para proveer información por un proveedor de contenido 23. Un cliente 20, usando un teléfono celular, contacta con un proveedor de contenido/servicios 23 para indicar que se necesita información localizada. El proveedor de contenido 23 remite esta solicitud al proveedor de acceso (mediador de servicios) 24, como se analizó anteriormente. Alternativamente, el proveedor de acceso 24 ha interceptado la solicitud y obra en consecuencia automáticamente. El mediador de servicios 24 puede enviar una solicitud de información de ubicación de un cliente a un servidor base de ubicación 36, por ejemplo usando el número MSISDN del cliente como referencia. El servidor base de ubicación (LBS) 36 recibe información sobre la ubicación actual del cliente 20, por ejemplo usando información de la red celular (transceptores 38, base de datos de ubicación 39). A continuación, el mediador de servicios 24 recibe las coordenadas (X, Y) del cliente asociado y remite esta al proveedor de contenido 23. Cuando se comprueba que el cliente está en el área geográfica correcta, el proveedor de contenido 23 enviará la información al cliente 20. Cuando el mediador de servicios 24 reciba un acuse de recibo del proveedor de contenido 23, se encargará de la facturación de la manera descrita anteriormente.
La información provista por el proveedor de contenido 23 puede incluir información solicitada instantáneamente por el cliente 20, información periódica, como información de tráfico, o información generada por acontecimientos, como que un valor de acciones cruce un umbral preestablecido.
Como se describió con referencia a la Fig. 9, el mediador de servicios 24 puede proveer una interfaz UCP para los proveedores de contenido 23. Esta interfaz está dispuesta preferentemente sólo para aceptar mensajes del tipo UCP51. Se responderá a otros mensajes con un mensaje de error (otros tipos definidos de mensajes UCP) o serán ignorados (mensajes desconocidos).
En el mensaje de tipo UCP51, puede incluirse un campo de tarifa (preferentemente en el campo XSER) que indica la tarifa que el proveedor de contenido 23 quiere cargar por ese servicio específico al cliente 20. El mediador de servicios 24 analizará sintácticamente los mensajes recibidos, comprobando el tipo de mensaje, el campo LEN en la cabecera y la suma de control del mensaje UCP. Después de esto, el mediador de servicios 24 quitará el campo tarifa del mensaje UCP y enviará hacia adelante el mensaje UCP (por ejemplo al centro de SMS 33). De esta manera, el mediador de servicios 24 es un sistema transparente para el proveedor de contenido 23 con respecto a mensajes UCP (con la excepción del campo de tarifa).
El mediador de servicios 24 administrará un archivo de perfil de proveedor, en el que se indica qué acciones se permiten para un proveedor de contenido específico 23. Esto puede referirse a una interfaz específica que puede ser usada por un proveedor de contenido específico 23 (como UCP, destino único XML o destino múltiple XML), o a una función específica provista por el mediador de servicios. El número de funciones permitidas para un proveedor de contenido 23 puede ser igual a cero, bloqueando así eficazmente ese proveedor de contenido 23.
El mediador de servicios puede notificar a un suscriptor (cliente) cuándo no puede entregarse un mensaje por alguna razón, como muy pocos fondos en la cuenta de prepago. Preferentemente, el texto que se envía al cliente depende del proveedor de contenido de procedencia. Esta función del mediador de servicios 24 también puede deshabilitarse para un proveedor de contenido específico 23. En ese caso, se supone que el propio proveedor de contenido 23 informará al cliente.
También, en el perfil del proveedor puede establecerse para cada proveedor una cantidad máxima por un servicio. Cuando el mediador de servicios 24 recibe un mensaje en el que la tarifa como se indica es superior a la cantidad máxima para ese proveedor de contenido, el mediador de servicios 24 no aceptará el mensaje (e informará al remitente del mensaje usando un código de error en el mensaje de respuesta).
El mediador de servicios 24 también comprobará la longitud de un mensaje. En caso de un mensaje alfanumérico, el número máximo de caracteres en el mensaje es 160. Cuando sea mayor, el mensaje no será aceptado. Los mensajes transparentes ya están limitados a 140 caracteres y esto no está reñido con otros requisitos del sistema. Para mensajes transparentes, no es necesaria comprobación de longitud.
La tasa de transferencia para cada proveedor de contenido 23 es medida por el mediador de servicios 23. Cuando se cruza un máximo preestablecido para un cierto proveedor de contenido 23 (como está almacenado en el perfil del proveedor) la tasa de transferencia de ese proveedor de contenido se limitará retrasando la respuesta a un mensaje (ACK/NACK). La tasa de transferencia máxima se define como X mensajes en Y segundos.
Para poder controlar picos de carga más eficazmente, el mediador de servicios 23 puede definir una o más franjas de tiempo, en las que un proveedor de contenido predeterminado 23 tiene acceso o no tiene acceso al sistema. Esta función de ventana de tiempo de acceso es relevante para un número limitado de proveedores de contenido 23 que tienen altos valores de tasa de transferencia. Para proveedores de contenido "pequeños" 23 esta función no es relevante, y esto puede indicarse en el perfil del proveedor. La función de ventana de tiempo puede estar implementada en el nivel de conexión TCP/IP. En ese caso, el mediador de servicios 24 debe poder desconectar la conexión TCP/IP al proveedor de contenido específico 23.
Para poder controlar la tasa de transferencia de un proveedor de contenido 23 también es posible establecer en el perfil del proveedor el número máximo de conexiones paralelas para cada proveedor de contenido 23. Cuando un proveedor de contenido 23 quiera abrir sesiones adicionales, el mediador de servicios 24 ignorará estos mensajes y enviará un código de error al proveedor de contenido 23.
El mediador de servicios 24 registrará diversos datos acerca del procesamiento de las transacciones en archivos de registro. Se establecen varios requisitos genéricos para los archivos de registro, es decir hora de comienzo, tiempo máximo que está abierto el archivo, tamaño máximo del archivo de registro y cierre manual de un archivo de registro para permitir a un operador revisar el archivo de registro. Como el mediador de servicios 24 puede implementarse de manera paralela, es decir, varios servidores puede ejecutar la funcionalidad de mediador de servicios, los archivos de registro de cada servidor pueden copiare periódicamente en un servidor de registro central. También es posible procesar posteriormente los archivos de registro, por ejemplo para reducción de datos o análisis del sistema.
Según la invención, se desvela un procedimiento para simplificar el acceso a servicios en redes de telecomunicaciones, por ejemplo en Internet, mediante uno o más proveedores de contenido o servidores Web de Internet, e incluye al menos una red de telecomunicaciones, donde cada solicitud de URL procedente de un usuario de la red de telecomunicaciones (MU) tiene que pasar por un administrador de acceso, que lleva a cabo al menos uno de: autenticación, autorización, enrutamiento de acceso, facturación y comprobaciones de crédito; para lo cual el administrador de acceso elimina del URL cualquier información personal relacionada con el usuario de telecomunicaciones y sustituye esta con una ID XID ficticia, de manera que la solicitud es anónima después de las modificación exitosa.
Debe observarse que las realizaciones mencionadas anteriormente ilustran más que limitan la invención, y que los expertos en la materia podrán diseñar muchas realizaciones alternativas sin apartarse del alcance de las reivindicaciones adjuntas. En las reivindicaciones, cualquier señal de referencia colocada entre paréntesis no debe interpretarse como limitadora de la reivindicación. Las palabras "comprendiendo" e "incluyendo" no excluyen la presencia de elementos o etapas distintos a los enumerados en una reivindicación. La invención puede implementarse por medio de hardware que comprende varios elementos distintos, y por medio de un ordenador programado adecuadamente. Donde las reivindicaciones del sistema/dispositivo/aparato enumeran varios medios, varios de estos medios pueden ser plasmados por un mismo elemento de hardware. El producto de programa informático puede ser almacenado/distribuido en un medio adecuado, como espacio de almacenamiento óptico, pero también puede ser distribuido de otras formas, como ser distribuido a través de Internet o sistemas de telecomunicación inalámbrica.

Claims (27)

1. Un sistema para proveer servicios a un terminal de usuario (150, 160); incluyendo el sistema:
al menos un subsistema proveedor de servicios/contenido (110, 120, 130), en lo sucesivo "proveedor de servicios", para proveer servicios por medio de una red de área amplia (140), en particular Internet, que incluye una interfaz de comunicación para comunicarse a la red de área amplia;
al menos un subsistema proveedor de acceso a servicios (100), en lo sucesivo "proveedor de acceso", que incluye una interfaz de comunicación (210, 220) para comunicarse al al menos un proveedor de servicios por medio de la red de área amplia (140) y para comunicarse a al menos un terminal de usuario por medio de un sistema de comunicación adicional (170, 180); y
al menos un terminal de usuario (150, 160) que incluye una interfaz de comunicación para comunicarse al proveedor de acceso por medio del sistema de comunicación adicional y, a través del proveedor de acceso, solicitar servicios de al menos un proveedor de servicios;
en el que el proveedor de acceso incluye un administrador de acceso a servicios (230) para verificar si un terminal de usuario o un usuario de un terminal de usuario, en lo sucesivo "usuario/terminal", está autorizado a solicitar un servicio de un proveedor de servicios y tras verificación positiva permitir al terminal de usuario acceder al proveedor de servicios, liberando así al proveedor de servicios de tener que autorizar al usuario/terminal.
2. Un sistema según la reivindicación 1, en el que el administrador de acceso está dispuesto para ejecutar una operación de identificación del usuario del terminal de usuario y, tras la finalización exitosa de la operación de identificación, comenzar una sesión de comunicación que permite el acceso verificado del terminal de usuario al proveedor de servicios durante la sesión.
3. Un sistema según la reivindicación 1 ó 2, en el que la primera interfaz de comunicación del proveedor de acceso y la interfaz de comunicación del proveedor de servicios están dispuestas para asegurar al menos parte de la comunicación entre el proveedor de acceso y el proveedor de servicios.
4. Un sistema según una cualquiera de las reivindicaciones 1 a 3, en el que el servicio comprende objetos facturables que se pueden descargar.
5. Un sistema según la reivindicación 4, en el que el administrador de acceso está dispuesto para verificar una solvencia asociada con el usuario/terminal con respecto a costes asociados con la obtención del servicio o los objetos cobraderos que se pueden descargar o una combinación de ambos y sólo tras la verificación de solvencia positiva permitir el acceso al proveedor de servicios.
6. Un sistema según la reivindicación 4, en el que el administrador de acceso está dispuesto para recibir un servicio u objetos cobraderos que se pueden descargar o una combinación de ambos desde un proveedor de servicios y para verificar una solvencia asociada con el usuario/terminal con respecto a costes asociados con la recepción del servicio o los objetos cobraderos que se pueden descargar o una combinación de ambos y sólo tras la verificación de solvencia positiva pasar el contenido al terminal de usuario.
7. Un sistema según la reivindicación 5 ó 6, en el que el administrador de acceso está dispuesto para generar un registro de facturación para facturar los costes tras la verificación positiva de la solvencia asociada con el usuario.
8. Un sistema según la reivindicación 7, en el que el administrador de acceso está dispuesto para verificar si el servicio solicitado o los objetos cobraderos que se pueden descargar o una combinación de ambos han sido proporcionados por el proveedor de servicios al administrador de acceso o al usuario/terminal y para generar el registro de facturación sólo tras la confirmación de la entrega.
9. Un sistema según la reivindicación 8, en el que el proveedor de acceso incluye un espacio de almacenamiento (240) para almacenar contenido electrónico proporcionado por un proveedor de servicios en respuesta a una solicitud de servicio de un usuario/terminal para suministro adelantado al usuario/terminal; estando dispuesto el administrador de acceso para repetir la entrega al usuario tras un fallo en la recuperación del contenido electrónico por el usuario/terminal en un primer intento.
10. Un sistema según la reivindicación 4-9, en el que el administrador de acceso está dispuesto para verificar una solvencia asociada con el usuario/terminal dependiendo de un tipo de usuario cada uno asociado con diferentes datos de facturación o un operador de red o una combinación de ambos.
11. Un sistema según la reivindicación 10, en el que el tipo de cliente incluye al menos un cliente de prepago y un cliente de pospago.
\newpage
12. Un sistema según una cualquiera de las reivindicaciones precedentes, en el que el usuario/terminal está asociado con información de identificación que está incluida en al menos un mensaje de solicitud a un proveedor de servicios para permitir al proveedor de servicios proporcionar el servicio al usuario/terminal; incluyendo el proveedor de servicios:
un espacio de almacenamiento (240) para almacenar información de identificación ficticia asociada para cada usuario/terminal; y
un convertidor de identidad (260) para sustituir en un mensaje de solicitud de servicio procedente del terminal de usuario la información de identificación con una información de identificación ficticia correspondiente remitida al proveedor de servicios y para sustituir en un mensaje de respuesta de servicio procedente del proveedor de servicios la información de identificación ficticia por la información de identificación de usuario/terminal correspondiente.
13. Un sistema según la reivindicación 12, en el que la información de identificación de usuario/terminal incluye o se deriva de al menos una dirección de red real, como una dirección IP o MSISDN, que identifica de manera única el terminal de usuario con respecto a la red de área amplia (140) y/o al sistema de comunicación adicional (170, 180), y en el que la información de identificación ficticia correspondiente incluye una dirección de red única diferente no usada como una dirección de red real por ninguno de los terminales de usuario.
14. Un sistema según una cualquiera de las reivindicaciones precedentes, en el que el proveedor de servicios está dispuesto para:
generar un mensaje, en los sucesivo "cookie", con datos relacionados con un acceso previo al proveedor de servicios por parte de un terminal de usuario;
enviar la cookie al terminal de usuario, y
para una solicitud de servicio posterior, obtener la cookie del terminal de usuario para proveer un nuevo servicio personalizado;
incluyendo el proveedor de acceso un espacio de almacenamiento (240) para almacenar cookies enviadas por un proveedor de servicios en asociación con un usuario/terminal y para una solicitud procedente de un usuario/terminal de un servicio de un proveedor de servicios que proporciona la cookie del usuario/terminal al proveedor de servicios.
15. Un sistema según las reivindicaciones 10 y 14, en el que la cookie se almacena en asociación con la información de identificación ficticia asociada con un usuario/terminal.
16. Un sistema según la reivindicación 14 y 13, en el que la cookie se almacena en asociación con una identidad de usuario para permitir a un usuario asociado con la identidad de usuario obtener servicios personalizados iguales independientes de un terminal de usuario usado por el usuario.
17. Un sistema según una cualquiera de las reivindicaciones precedentes, en el que el servicio está asociado con información de identificación de servicio virtual, como un URL, que está incluida en al menos un mensaje de solicitud de un terminal de usuario a un proveedor de servicios para identificar el servicio; incluyendo el proveedor de acceso:
un espacio de almacenamiento para almacenar, para cada servicio, una información asociada de identificación de servicio real para identificar el servicio con respecto a la red de área amplia; y
un reescritor de URL (270) para sustituir en el mensaje de solicitud procedente del terminal de usuario la información de identificación de servicio virtual con la información de identificación de servicio real correspondiente para remitir al proveedor de servicios y para sustituir en un mensaje del proveedor de servicios al terminal de usuario la información de identificación de servicio real por la información de identificación de servicio virtual correspondiente.
18. Un sistema según la reivindicación 17, en el que el proveedor de acceso está dispuesto para identificar mensajes de solicitud de servicios asociados con información de identificación de servicio virtual a o desde un proveedor de servicios, y dirigir esos mensajes a través del reescritor de URL.
19. Un sistema según la reivindicación 18, en el que el proveedor de acceso está dispuesto para hacer la distinción sobre un patrón predeterminado en la información de identificación de servicio virtual.
20. Un sistema según la reivindicación 17, 18 ó 19, en el que el reescritor de URL está dispuesto para añadir parámetros en el mensaje de solicitud del terminal de usuario al proveedor de servicios para permitir al proveedor de servicios optimizar el servicio para el usuario/terminal.
21. Un sistema según una cualquiera de las reivindicaciones precedentes, en el que el sistema incluye un localizador para recuperar información sobre una ubicación de un usuario/terminal para permitir al proveedor de servicios proveer un servicio dependiente de la ubicación a un usuario/terminal.
22. Un sistema según la reivindicación 21, en el que el proveedor de acceso incluye el localizador.
23. Un sistema según las reivindicaciones 20 y 21, en el que el reescritor de URL está dispuesto para añadir información de ubicación como parámetros en el mensaje de solicitud del terminal de usuario al proveedor de servicios.
24. Un subsistema proveedor de acceso a servicios que incluye una interfaz de comunicación (210, 220) para comunicarse a al menos un proveedor de servicios (110, 120, 130) por medio de una red de área amplia (140), en particular Internet, y para comunicarse a al menos un terminal de usuario (150, 160) por medio de un sistema de comunicación adicional (170, 180), en el que el subsistema proveedor de acceso a servicios incluye un administrador de acceso a servicios (230) adaptado para verificar si un terminal de usuario o un usuario de un terminal de usuario está autorizado a solicitar un servicio de un proveedor de servicios y tras verificación positiva permitir al terminal de usuario acceder al proveedor de servicios, liberando así al proveedor de servicios de tener que autorizar al usuario/terminal.
25. Un subsistema proveedor de acceso a servicios según la reivindicación 24 para uso en un sistema según una cualquiera de las reivindicaciones 1 a 23.
26. Un procedimiento de proveer servicios a un terminal de usuario por medio de una red de área amplia, en particular Internet, que incluye:
recibir en un subsistema proveedor de acceso a servicios, por medio de un sistema de comunicación adicional, desde el terminal de usuario un mensaje solicitando un servicio de un proveedor de servicios;
verificar por dicho subsistema proveedor de acceso a servicios si el terminal de usuario o un usuario del terminal de usuario está autorizado para solicitar un servicio del proveedor de servicios; y
tras verificación positiva, permitir al terminal de usuario acceder al proveedor de servicios a través de la red de área amplia, liberando así al proveedor de servicios de tener que autorizar al usuario/terminal.
27. Un producto de programa informático cuando se ejecuta en un ordenador para hacer que un procesador realice las etapas de la reivindicación 26.
ES02745259T 2001-04-23 2002-04-23 Arquitectura para proveer servicios en interneet. Expired - Lifetime ES2274980T3 (es)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
EP01201460A EP1253760A1 (en) 2001-04-23 2001-04-23 Service provider architecture for delivering services to mobile communication customers
EP01201460 2001-04-23
US29707801P 2001-06-08 2001-06-08
US297078P 2001-06-08
EP10154546 2001-11-07
DE10154546A DE10154546B4 (de) 2001-11-07 2001-11-07 Verfahren zum Zugänglichmachen von Diensten in Telekommunikationsnetzen, zum Beispiel im Internet
EP01204327 2001-11-13
EP01204327 2001-11-13
EP02076008 2002-03-13
EP02076008 2002-03-13
PCT/EP2002/004518 WO2002102016A2 (en) 2001-04-23 2002-04-23 Architecture for providing services in the internet

Publications (1)

Publication Number Publication Date
ES2274980T3 true ES2274980T3 (es) 2007-06-01

Family

ID=27512433

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02745259T Expired - Lifetime ES2274980T3 (es) 2001-04-23 2002-04-23 Arquitectura para proveer servicios en interneet.

Country Status (7)

Country Link
EP (1) EP1386470B1 (es)
AT (1) ATE343295T1 (es)
DE (1) DE60215482T2 (es)
DK (1) DK1386470T3 (es)
ES (1) ES2274980T3 (es)
PT (1) PT1386470E (es)
WO (1) WO2002102016A2 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10213072A1 (de) * 2002-03-18 2003-10-09 Siemens Ag Verfahren zum Betrieb eines einem Mobilfunknetz zugeordneten Abrechnungssystems zur Abrechnung einer kostenpflichtigen Benutzung von Daten und Datenübertragungsnetz
EP1764969A1 (de) * 2003-02-20 2007-03-21 Siemens Aktiengesellschaft Verfahren zur anonymisierten Kommunikation zwischen einem mobilen Kommunikationsendgerät und einem WAP-Server für die Nutzung des WAP-Service
FR2852756B1 (fr) * 2003-03-18 2005-04-29 France Telecom Procede de transmission de donnees entre au moins deux entites distinctes
SE0301967D0 (sv) 2003-03-27 2003-07-03 Ericsson Telefon Ab L M A method and apparatus for supporting content purchases over a public communication network
KR100555949B1 (ko) 2003-04-11 2006-03-03 삼성전자주식회사 홈 디바이스의 인증시스템 및 그의 인증방법
US7239617B2 (en) * 2003-05-07 2007-07-03 Lucent Technologies Inc. Per call interactive high speed packet data activation
FR2855924B1 (fr) * 2003-06-06 2005-07-15 Radiotelephone Sfr Procede de controle avec gestion d'un identifiant opaque d'utilisateur de la livraison complete d'un service utilisant un ensemble de serveurs
AU2004246547B2 (en) * 2003-06-09 2008-10-30 Toku Pte Ltd System and method for providing a service
ES2242499B1 (es) * 2003-06-26 2006-10-01 Vodafone España, S.A. Sistema y metodo para acceso anonimo a un servicio ofrecido en una direccion de internet (url) determinada y modulo para el sistema.
US8051472B2 (en) * 2003-12-17 2011-11-01 Oracle International Corporation Method and apparatus for personalization and identity management
JP4873852B2 (ja) * 2004-02-26 2012-02-08 株式会社リコー 第一の通信装置、情報処理装置、情報処理プログラム、記録媒体
DE102004063688A1 (de) 2004-12-28 2006-07-13 Vodafone Holding Gmbh System und Verfahren zur Vermittlung von Daten zwischen einem Datenanbieter und einem Mobilfunkteilnehmer
US20070104186A1 (en) 2005-11-04 2007-05-10 Bea Systems, Inc. System and method for a gatekeeper in a communications network
ES2284362A1 (es) * 2005-11-28 2007-11-01 France Telecom España, S.A. Metodo para la deteccion de configuraciones incorrectas de acceso a servicios en terminales moviles y su correccion posterior.
EP2569965A1 (en) * 2010-05-12 2013-03-20 Modeva Interactive A method of authenticating subscription to a mobile content service

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6188752B1 (en) * 1996-11-12 2001-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for providing prepaid telecommunications services
CA2313388C (en) * 1997-12-15 2009-08-04 British Telecommunications Public Limited Company Data communications

Also Published As

Publication number Publication date
PT1386470E (pt) 2007-01-31
DE60215482T2 (de) 2007-05-03
WO2002102016A3 (en) 2003-09-25
EP1386470A2 (en) 2004-02-04
EP1386470B1 (en) 2006-10-18
ATE343295T1 (de) 2006-11-15
WO2002102016A2 (en) 2002-12-19
DK1386470T3 (da) 2007-02-19
DE60215482D1 (de) 2006-11-30

Similar Documents

Publication Publication Date Title
US20040139204A1 (en) Architecture for providing services in the internet
US6430407B1 (en) Method, apparatus, and arrangement for authenticating a user to an application in a first communications network by means of a mobile station communicating with the application through a second communications network
FI108813B (fi) Menetelmä ja järjestelmä tietoliikennejärjestelmässä
ES2274980T3 (es) Arquitectura para proveer servicios en interneet.
JP5144514B2 (ja) モバイル口座管理
US20080249938A1 (en) System and method for merchant discovery and transfer of payment data
DK2582115T3 (en) Qualified electronic signature system, associated method and mobile phone to qualified, electronic signature
US20080046988A1 (en) Authentication Method
CN104112196A (zh) 用于提供银行服务的电子系统
CN101189616A (zh) 帮助实现和认证事务
US20110173105A1 (en) Utilizing AAA/HLR infrastructure for Web-SSO service charging
JP2005158066A (ja) ベンダサービス用の自動化された顧客資格付与システム
US20070270124A1 (en) Systems and methods for adding credit to a wireless telecommunications account
US20090171837A1 (en) Systems and methods for mobile payment
KR20060107737A (ko) 원격 통신 네트워크를 통해 전송된 콘텐츠를 사용하는비용들을 청구하기 위한 방법 및 시스템
US20020165783A1 (en) Accounting in peer-to-peer data communication networks
US20040143521A1 (en) Method and device for paying for services in networks with a single sign-on
US20040029570A1 (en) Method and apparatus for electronic payment through mobile communication devices
US20210090087A1 (en) Methods for access point systems and payment systems therefor
ES2257874T3 (es) Procedimiento y sistema para producir un servicio en un sistema de telecomunicaciones.
US20230245085A1 (en) Laterpay 5G Secondary Authentication
TW201236432A (en) Automatically-triggered one time password authentication system with remote authentication dial-in user service
KR20120010756A (ko) Ｏｔｐ 서명을 이용한 ｉｄ 기반의 소액 결제 시스템 및 그 방법
Panduranga Simplifying mobile commerce through a trusted transaction broker
JP2003263598A (ja) サービスの課金をサポートする制御サーバ