11 Número de publicación: Int. Cl. 7 : H04L 29/ Inventor/es: Lilge, Manfred. 74 Agente: Zuazo Araluze, Alexander

Transcripción

1 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: Int. Cl. 7 : H04L 29/06 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: Fecha de presentación : Número de publicación de la solicitud: Fecha de publicación de la solicitud: Título: Procedimiento y sistema para la tarificación en redes de comunicaciones. Prioridad: DE Titular/es: SIEMENS AKTIENGESELLSCHAFT Wittelsbacherplatz München, DE 4 Fecha de publicación de la mención BOPI: Inventor/es: Lilge, Manfred 4 Fecha de la publicación del folleto de la patente: Agente: Zuazo Araluze, Alexander ES T3 Aviso: En el plazo de nueve meses a contar desde la fecha de publicación en el Boletín europeo de patentes, de la mención de concesión de la patente europea, cualquier persona podrá oponerse ante la Oficina Europea de Patentes a la patente concedida. La oposición deberá formularse por escrito y estar motivada; sólo se considerará como formulada una vez que se haya realizado el pago de la tasa de oposición (art del Convenio sobre concesión de Patentes Europeas). Venta de fascículos: Oficina Española de Patentes y Marcas. C/Panamá, Madrid

2 DESCRIPCIÓN Procedimiento y sistema para la tarificación en redes de comunicaciones Campo especializado de la invención En redes de comunicaciones ponen a disposición cada vez más ofertantes de informaciones, los llamados Content Provider (proveedores de contenido), informaciones (contenidos de datos) en sus servidores, informaciones que son solicitadas por abonados de la red de comunicaciones y que se descargan en su aparato terminal. Al respecto puede tratarse de datos de cualquier naturaleza, por ejemplo programas de cine, informaciones sobre itinerarios de viaje, y muchos más. Estos se encuentran, en tanto en cuanto se trate de internet, a menudo como páginas HTML, WML y crecientemente también como páginas XML (denominadas en lo que sigue sólo paginas WML). Para pequeños aparatos terminales móviles (por ejemplo teléfonos móviles, ordenadores de bolsillo o con formato de calculadoras, paginadores,...) hay exigencias especiales debido a las limitaciones en cuanto a espacio de memoria y a visualización. Para los correspondientes Microbrowser (microbuscadores), que corren bajo WAP (Wireless Application Protocol), estas informaciones están preparadas como páginas WML: El Wireless Markup Language es un lenguaje que se ha desarrollado especialmente para aparatos terminales móviles con dispositivos visualizadores pequeños y limitados en cuanto a capacidad. Los usuarios de aparatos terminales móviles susceptibles de WAP pueden llamar igualmente a estas informaciones indicando la correspondiente dirección (URL). La instalación, mantenimiento, gestión y puesta a disposición de las páginas de datos (en particular en cuanto a la actualidad de las informaciones archivadas) origina costes, en los cuales han de participar los abonados que acceden a estos datos. Estado de la técnica En general es conocido que los mecanismos actuales tarifican la duración de un enlace de datos establecido con un servidor. Sistemas más modernos tarifican el volumen de datos transmitidos. Los ofertantes de informaciones (Content Provider) en internet, cubren a menudo los costes que se les producen financiados por publicidad. Sus páginas HTML contienen una serie de banners de publicidad y logos que, cliqueando, conducen a las HomePages de los correspondientes ofertantes de productos. Los usuarios que acceden a las páginas del proveedor de contenidos, ven junto a la información deseada esta publicidad. Esta solución no puede emplearse debido a las limitadas posibilidades de los aparatos terminales WAP, en particular para contenidos WML. Actualmente no se conoce ninguna solución a este problema. En el folleto WO 98/62 se describe ya un procedimiento para la tarificación de la transmisión de mensajes breves en una red de comunicaciones a través de una interfaz. El importe de la tarificación depende entonces del contenido de la información a transmitir, conteniendo el propio mensaje breve una recomendación de tarificación que es evaluada por el centro de mensajes breves. La tarificación se realiza no obstante sólo tras la transmisión de las informaciones. En la WO 99/2906 se tratan informaciones para la tarificación de distintos servicios, especialmente en una red orientada a paquetes. La tarificación del servicio se realiza de la manera tradicional, registrándose el usuario en un servicio y realizándose el cálculo de los cargos en función del volumen, del momento y de la duración y calidad del servicio. La facturación de distintos servicios se realiza de la manera tradicional pero a través de un banco de datos central. Es tarea de la invención indicar un procedimiento y un sistema para la tarificación de la transmisión de informaciones que evite los inconvenientes antes citados. Representación de la invención Esta tarea se resuelve mediante un procedimiento según la reivindicación 1 y un sistema según la reivindicación. El concepto se basa en tres elementos que han de separarse entre sí: a) los criterios para el emplazamiento de una página WML en un concepto de tarifas o la determinación de un precio, se encuentran en el ofertante de información (Content Provider). Este sabe qué informaciones puestas a disposición son caras y cuáles baratas. Es tarea del proveedor de contenidos caracterizar las páginas que pueden ser llamadas de un servidor mediante informaciones adicionales sobre tarifas o precios. Esta información está escondida en una forma constructiva de la invención en la página WML (p.e. como un WML-Tag propio) o bien en la cabecera del correspondiente mensaje HTTP (Header) y se transmite a la vez al abonado cuando realiza la llamada. 2

3 Una puerta GateWay WAP constituye la interfaz entre abonado y el universo de datos WAP o bien el universo de datos internet. Todo el contenido WML/HTML llamado por el usuario pasa por una puerta GateWay WAP (las páginas de datos HTML pueden traducirse aquí a WML). La puerta WAP tiene la tarea adicional de buscar en las páginas de datos las informaciones de tarifas allí memorizadas. Las páginas libres de cargo no contienen tarifa alguna y pueden atravesar la puerta (GateWay). Si se encuentran informaciones tarificadas, entonces formula la puerta (GateWay) un Charging Request (solicitud de cargo) a una unidad de red, que responde a las consultas sobre tarificación para abonados. Si se acusa positivamente recibo a la Charging Request, entonces paga el abonado por el contenido en datos y la puerta deja pasar la página. Si el acuse de recibo es negativo, se rechaza el contenido y se informa al abonado al respecto. Como alternativa a ello puede estar archivada en la puerta WAP una base de datos sobre las páginas WML con cargo. Respecto a estas páginas está archivada su URL así como una información sobre tarifas o precios. Cuando accede un abonado a una tal página WML, formula la puerta WAP en base a las informaciones memorizadas la correspondiente solicitud de cargo (Charging Request)... Las URLs respecto a las cuales no hay inscripción alguna en el banco de datos son libres de tarifas y pueden atravesar la puerta WAP. b) Hay una unidad de red que contesta a las consultas sobre tarificación para abonados (denominada también a continuación PaymentBroker ). Para cada abonado está preparado un perfil individual. Este contiene informaciones sobre: - Informaciones sobre cuentas a través de las que pueden ser facturadas las consultas sobre tarificación (tarjeta de crédito, enlace bancario, cuenta telefónica, cuenta de prepago,...). - Reglas sobre cómo deben ser contestadas las consultas sobre tarificación. Estas reglas pueden depender de varios criterios (importe de la consulta sobre tarifas, estado de la cuenta, ofertante de la información, suma de todas las consultas sobre tarifas dentro de un periodo de tiempo,...). En función de estas reglas, puede contestar el PaymentBroker autónomamente la consulta sobre tarifas o bien él mismo consulta, en una forma de perfeccionamiento preferente de la invención, previamente al abonado sobre si está dispuesto a pagar por la página WML. - Tablas de conversión de informaciones abstractas sobre tarifas a importes monetarios concretos teniendo en cuenta por ejemplo rebajas personales, ofertas especiales, rebajas por cantidad. - Si el PaymentBroker responde a la consulta sobre tarifas positivamente, entonces está asegurado el pago del contenido WML. El operador del PaymentBroker introduce las tarifas y las conduce al proveedor de contenidos Content Provider. Para cada ofertante de información (Content Provider) puede estar establecido igualmente un perfil. Este contiene informaciones sobre: Procedimiento de pago preferido (p.e.: los clientes sólo pueden pagar mediante tarjeta de crédito). El procedimiento de cobro acordado entre el operador del PaymentBroker y el Content Provider (p.e. el momento de presentación de la factura). Limitaciones que impone el operador del PaymentBroker al Content Provider (exclusión temporal del procedimiento de pago, límite superior para procesos de pagos individuales,...). El concepto prevé una clara repartición de las tareas: - El ofertante de información debe ocuparse sólo de la puesta a disposición de los contenidos así como de su escalonamiento de tarifas o precios. Él queda liberado de la confección de la factura y del recaudo de los importes. - La puerta de acceso (gateway) WAP conserva el acceso al contenido de los datos transmitidos y controla su transporte. - El PaymentBroker se ocupa exclusivamente de los aspectos de tarificación en una consideración general del abonado. Un perfil de abonado preparado en el PaymentBroker puede utilizarse para otros casos de aplicación. Los datos sensibles de la cuenta deben ser archivados sólo una vez por parte del abonado en el PaymentBroker y no son retransmitidos a terceros. Otras mejoras y perfeccionamientos ventajosos se indican en las reivindicaciones secundarias. 6 El procedimiento correspondiente a la invención es especialmente ventajoso para los aparatos terminales descritos, ya que no son transmitidas informaciones no deseadas por el abonado como banners de publicidad. 3

4 El ofertante de información puede realizar una tarificación de su oferta que se corresponda con el gasto efectivo, independientemente del aparato terminal utilizado por el usuario. Breve descripción de los dibujos A continuación se describirá la invención en base a ejemplos de ejecución. Al respecto muestran fig. 1 la tarificación controlada por un agente de tarificación ( URL based Charging ), 1 fig. 2 la tarificación controlada por información de tarificación suministrada juntamente con la información tarificada ( etiqueta con el precio, Tag based Charging ), fig. 3 la tarificación controlada por un perfil de abonado así como una consulta opcional sobre el acuerdo por parte del abonado ( Automatic Charge Processing, Manual Charge Confirmation ; Proceso automático de cargo, confirmación de cargo manual ). Descripción de las formas de perfeccionamiento preferentes Se propone a continuación una realización basada en IN de la solución correspondiente a la invención para este problema: El sistema IN asume el papel del PaymentBroker. La puerta de acceso WAP pone todas las solicitudes de cargo (charging requests) a disposición del sistema IN a través de una interfaz aún por definir La figura 1 muestra la tarificación controlada por un agente de tarificación ( URL based Charging ). La red de comunicaciones contiene una central de conmutación, MSC, aquí especialmente adecuada para el uso en redes de telefonía móvil. A través de esta central de conmutación solicita un abonado mediante su aparato terminal móvil, MT, informaciones de un llamado proveedor de contenidos (content provider). Éstas se encuentran en forma de páginas de datos, por ejemplo en el lenguaje HTML ó WML, que fue desarrollado especialmente para aparatos terminales móviles con pequeña memoria y pequeña capacidad de visualización. De qué manera y en qué lugar se almacenan estás páginas de datos HTML, WML y mediante qué vía física se accede a ello (por ejemplo a través de Intranet o Internet, IP, y aseguramientos de acceso como firewalls, FW) carece de importancia para el procedimiento correspondiente a la invención. Para traducir los datos de una red de voz a una red de paquetes y viceversa, hay un dispositivo RAS que se corresponde con la forma de funcionamiento de un módem. En el ejemplo de ejecución se describe la realización técnica de la invención mediante una red inteligente (ver también al respecto las normas ITU Q.10 y siguientes). El control del servicio SCP que para ello se necesita, puede contener un convertidor de protocolo MGW, que no obstante no es esencial para la invención. Además, la central de servicios es apoyada por instancia(s) de gestión SMP, StWh, que permiten al operador de servicios y al proveedor de contenidos un acceso al sistema. Aquí se evalúan datos estadísticos y se gestionan los datos de tarificación para el operador. Las páginas de datos a tarificar están memorizadas de forma accesible para la puerta de acceso WAP, 1. La puerta de acceso WAP recibe todas las solicitudes de información 2 introducidas por el abonado (por ejemplo en forma de dirección bajo la que se pueden encontrar las informaciones buscadas, como un llamado Unified Resource Locator dirección URL). La puerta de acceso WAP comprueba las direcciones 3 solicitadas: mientras éstas no tienen tarificación, las consultas (y las páginas de datos suministradas de retorno) pueden atravesar sin obstáculos la puerta de acceso WAP. Si no obstante se prevé para la transmisión de la información una tarificación, entonces se describe aquí una primera forma de ejecución del procedimiento correspondiente a la invención. A partir de la solicitud de información del abonado 1 y de las informaciones propias memorizadas, se genera una consulta ChrgReq a la central de servicios SCP. Esta contiene: - un distintivo de abonado (Subscriber ID), - el distintivo del proveedor de información (Content Provider ID), 6 - un distintivo del contenido a tarificar (Content ID), - evento de tarificación (Charge Event). 4

5 1 2 La central de servicios calcula en base a la llamada ChrgReq y de los datos que conoce una respuesta ChrgResp, así como datos estadísticos y los tickets de cargos que eventualmente se produzcan para abonados, que hayan acordado prepago (prepaid),. La respuesta contiene ahora la solicitud relativa al tratamiento subsiguiente (aceptación o rechazo) y eventualmente una argumentación. - Rechazo - Aceptación la puerta de acceso WAP genera una información de rechazo ( access denied, acceso denegado ) 7 para el abonado. Ésta puede contener a su vez cualesquiera informaciones, por ejemplo la razón del rechazo. la puerta de acceso WAP deja pasar la solicitud al proveedor de contenidos (content provider) 8, siendo suministrada la información solicitada (página de datos) al abonado 9,. Para todos los abonados que no han acordado un prepago (ver antes) (Postpaid Subscriber, abonado postpago), se realiza ahora la tarificación, generándose los tickets de cargo (Call Data Records, 11). La figura 2 muestra la información de tarificación suministrada con la información de cargo ( Etiqueta con el precio, Tag based Charging ). La red de comunicaciones representada se corresponde en sus elementos con la de la figura 1. El proveedor de contenidos (Content Provider) debe determinar para cada unidad de información que puede transmitirse (páginas de datos) el importe con los cargos de transmisión calculados al respecto por él. El mismo puede entonces asignarse, como una etiqueta de precios, a la correspondiente unidad de información (en el banco de datos WML ó HTML). Estas informaciones sobre cargos pueden entonces estar definidas por ejemplo igualmente en HTML ó WML. Si ahora consulta el abonado MT mediante su interfaz de acceso (WAP - GW) una página de datos, 1, entonces se busca, 2, en ésta una información sobre tarifas allí contenida. Una consulta (ChrgReq) se envía a la central de servicios (SCP), que por ejemplo consulta las siguientes informaciones: - abonado (Subscriber) ID, 3 - proveedor de contenidos (Content Provider) ID, - descripción de contenidos (Content Description), evento con cargo (Charge Event). La central de servicios puede comprobar ahora si el abonado está dispuesto y/o en condiciones de aceptar la información sometida a costes, 4: por ejemplo, el mismo puede haber pagado de antemano (Prepaid Account) y no existir en la cuenta del abonado suficiente dinero. Además, la central de servicios puede reunir datos estadísticos (con y para una instancia de gestión SMP). Finalmente se genera una respuesta (ChrgResp) que contiene el resultado de la comprobación, así como dado el caso una argumentación. En función de la respuesta, se genera un aviso al abonado: Si el resultado de la comprobación es negativo, se libera la página de datos inicialmente solicitada ya por parte de la interfaz de acceso y se retransmite la correspondiente información al abonado, por ejemplo con el contenido access denied ( acceso denegado ), 6. Si el resultado de la comprobación es positivo, entonces puede opcionalmente retirarse, 6a, la información sobre cargos antes de la transmisión de la página de datos al abonado a través de la interfaz de acceso. En ambas soluciones el SCP elabora y contesta en base al perfil de abonado memorizado, 1, el Charge Request, ver figura 3. Pueden ser criterios de evaluación: - importe de la cuenta de prepago 6 - importe del cargo individual/suma de los cargos - contenido

6 - proveedor de contenidos. Opcionalmente, puede ahora iniciarse una consulta en el abonado. Para ello solicita la central de servicios SCP a la interfaz, SubInq, que genere una información (por ejemplo en forma de una página de datos) que contiene la información sobre tarifas y que la envíe al abonado 4. El abonado puede contestar esta consulta,, por ejemplo activando un botón sobre la página de datos enviada, y con ello confirmar o también interrumpir la transmisión de las informaciones deseadas. 1 La respuesta del abonado se transmite entonces a la central de servicios, SCP, SubResp. La cuenta del abonado de prepago (PrePaid) puede ser cargada directamente y para abonados de pago aplazado (PostPaid) se escribe un ticket (en terminología IN CDR: Call Data Record), que es elaborado por el centro de facturación (Billing Center) ABC del operador para la factura telefónica mensual. Las interfaces con institutos de tarjetas bancarias y de crédito permiten el cargo en las correspondientes cuentas. La realización concreta puede tener lugar por ejemplo mediante el INXpress elaborado por Siemens. Relación de abreviaturas ABC Administration & Billing Center (Centro de Administración y Facturación) CDR DB FW HTML HTTP IP MGW MSC MT RAS SCP SMAP SMP StWH URL WAP WAP XML Call Data Record (Registro de datos de llamada) DataBase (Base de datos) FireWall HyperText Markup Language (Lenguaje de Marcadores de Hipertexto) HyperText Transport Protocol (Protocolo de Transporte Hipertexto) Intranet Messaging Gate Way (Puerta de acceso de mensajes) Mobile Switching Center (Centro de conmutación Móvil) Mobile Terminal (Terminal móvil) Remote Access Server (Servidor de Acceso Remoto) Service Control Point (Punto de Control de Servicio) Service Management Access Point (Punto de Acceso de Gestión de Servicio) Service Management Point (Punto de Gestión de Servicio) Statistic WareHouse (Almacen Estadístico) Unified Resource Locator (Localizador de Recursos Unificado) Wireless Application Protocol (Protocolo de Aplicación sin hilos) Wireless Markup Language (Lenguaje de Marcadores sin hilos) Extended Markup Language (Lenguaje de Marcadores Extendido). 6 6

7 REIVINDICACIONES 1 1. Procedimiento para la tarificación de la transmisión de informaciones en redes de comunicaciones a través de una interfaz (WAP-GW), que controla el acceso a las informaciones deseadas y el transporte de las mismas, en el que el importe de la tarificación depende del contenido de las informaciones a transmitir, caracterizado porque - la interfaz (WAP-GW) genera una consulta (ChrgReq) a una instancia central (SCP), que factura los cargos del abonado (MT) en la red de comunicaciones, y - la instancia central (SCP) decide, en función de las indicaciones contenidas en la consulta y de las informaciones de las que dispone acerca del abonado y del ofertante de informaciones, en cuanto a aceptar o rechazar la transmisión con cargo de las informaciones, y - envía un aviso de retorno (ChrgRes) al respecto a la interfaz Procedimiento según la reivindicación 1, caracterizado porque la transmisión de informaciones, en función de la información sobre cargos, se permite o se impide a través de la interfaz (WAP-GW). 3. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la información a transmitir contiene el importe de los cargos para la transmisión, pudiendo ser éstos también iguales a cero. 4. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la interfaz (WAP-GW) utiliza informaciones sobre tarificación adicionales memorizadas relativas a la información a transmitir, pudiendo también contener esta información el importe del cargo.. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la elección de las informaciones deseadas tiene lugar mediante indicación de una dirección (URL). 6. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque las informaciones se encuentran en un idioma especial de descripción (WML, HTML, XML). 7. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque - cuando el abonado (MT) llama a una información y - la instancia central permite la transmisión, entonces - al abonado se le transmite una información sobre tarifas antes de la transmisión de la información, y 6 - él puede estar de acuerdo o rechazar la transmisión de la información. 8. Sistema para la tarificación de la transmisión de informaciones en redes de comunicaciones con - al menos una fuente para la información a transmitir (HTML,WML, XML), - una instancia de tarificación (SCP) en la red de comunicaciones, que pone a disposición informaciones sobre las facturaciones de cargos a los abonados de comunicaciones, y - una instancia de interfaz (WAP-GW) que recibe la solicitud de información de un abonado (MT), y genera (ChrgReq) una consulta a la instancia de tarificación relativa a los datos del abonado de la consulta de información, y datos de cargos que son función del contenido de las informaciones consultadas, y 7

8 en función de la respuesta de la instancia de tarificación (ChrgRes) controla la transmisión de la información de la fuente al abonado Sistema según la reivindicación 8, caracterizado porque los datos de tarificación dependientes del contenido están contenidos en la información (HTML, WML, XML).. Sistema según la reivindicación 8, caracterizado porque los datos del cargo dependientes del contenido están memorizados en la instancia de interfaz (WAP-GW). 11. Sistema según una de las reivindicaciones 8 a, caracterizado porque, cuando la respuesta de la instancia de tarificación es negativa se envía desde la instancia de interfaz (WAP-GW), (ChrgRes), una información de rechazo al abonado (MT)

9 9

10

11 11