ES2569732T3 - Procedimiento para la autorización de una transacción - Google Patents

Procedimiento para la autorización de una transacción Download PDF

Info

Publication number
ES2569732T3
ES2569732T3 ES13170677.2T ES13170677T ES2569732T3 ES 2569732 T3 ES2569732 T3 ES 2569732T3 ES 13170677 T ES13170677 T ES 13170677T ES 2569732 T3 ES2569732 T3 ES 2569732T3
Authority
ES
Spain
Prior art keywords
authorization
transaction
terminal
payment
sms
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.)
Active
Application number
ES13170677.2T
Other languages
English (en)
Inventor
Stefan Schwerdtfeger
Christian Dörfel
Michael Alexander Hengherr
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.)
TAGPAY GmbH
Original Assignee
TAGPAY GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by TAGPAY GmbH filed Critical TAGPAY GmbH
Application granted granted Critical
Publication of ES2569732T3 publication Critical patent/ES2569732T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • 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/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procedimiento para la realización de una autorización de una transacción por internet mediante un dispositivo de autorización (A), pudiendo realizarse la transacción en un primer terminal (E1), pudiendo iniciarse el proceso de autorización en un segundo terminal (E2), que es un terminal móvil, pudiendo acoplarse el primer terminal (E1) y el segundo terminal (E2) mediante una red de comunicaciones con el dispositivo de autorización (A) y comprendiendo la autorización mediante el dispositivo de autorización (A) las siguientes etapas: - la recepción de datos de transacción procedentes del segundo terminal (E2) por parte del dispositivo de autorización (A); - la determinación de un identificador que identifica el segundo terminal (E2) por parte del dispositivo de autorización (A); estando caracterizado el procedimiento por: - la determinación de una autorización de transacción, que puede ser asignada al identificador del segundo terminal (E2), dependiendo la autorización de transacción de los datos de transacción; - la habilitación de la realización de la transacción por internet en función de la autorización de transacción; y - la puesta a disposición de datos que son indicadores para la habilitación de la realización de la transacción por internet, para la salida en el primer terminal (E1) o en el segundo terminal (E2), permitiendo los datos la realización de la transacción por internet.

Description

DESCRIPCION
Procedimiento para la autorizacion de una transaccion.
5 La invencion se refiere a un procedimiento y un dispositivo para la autorizacion de una transaccion entre un proveedor de servicios y un usuario de servicios.
La autorizacion sirve para iniciar una o varias transacciones, que requieren una comprobacion de la autorizacion de las transacciones. Los procedimientos y dispositivos para la autorizacion son conocidos por el estado de la tecnica. 10 Por ejemplo, se conocen procedimientos, con los que puede autorizarse la carga de contenidos digitales en una pagina de internet. Para ello se facilita por ejemplo en una pagina de internet (que se visualiza en un navegador de internet de un ordenador) un enlace en forma de un URL (Uniform Resource Locator) al contenido digital. Un clic en este enlace hace que se cargue otra pagina de internet, en la que se muestran distintos datos de transaccion, informaciones para la realizacion de la transaccion y otro enlace para la carga del contenido digital. Los datos de 15 transaccion son aqui p.ej. un URL de transaccion.
El URL de transaccion puede introducirse por ejemplo en un telefono movil apto para WAP, para iniciar la autorizacion. El proveedor de servicios, que facilita los contenidos digitales, determina con ayuda del URL de transaccion y de los datos de protocolo del canal de datos WAP, mediante el cual se llama el URL de transaccion, un 20 identificador (p.ej. MSISDN) que puede ser asignado al telefono movil, para autorizar la transaccion (p.ej. la carga de los contenidos) y para facturar mediante este identificador por ejemplo la carga de los contenidos digitales, realizandose la facturacion propiamente dicha en la mayoria de los casos mediante el operador de red del abonado de telefonia movil (usuario). En el telefono movil, el usuario recibe a continuacion una pagina de internet movil con el aviso de que el contenido digital esta habilitado (y que por lo tanto se han realizado con exito la autorizacion y el 25 proceso de pago) y que ahora puede realizarse la carga del contenido digital en el navegador de internet del ordenador o en el navegador WAP del terminal movil (p.ej. telefono movil). A continuacion, el usuario puede hacer clic en otro enlace para ver el contenido digital.
El inconveniente del procedimiento es, por un lado, que requiere entradas manuales del usuario en el telefono movil 30 (entrada del URL de transaccion), lo que es susceptible a fallos (p.ej. entrada incorrecta del URL de transaccion) y que puede conducir por lo tanto a errores en la facturacion o puede conducir a que no se habiliten los contenidos requeridos. Tambien pueden producirse errores que impiden la realizacion completa del procedimiento, p.ej. entrada incorrecta al introducir el URL, al introducir la MSISDN / el identificador / el ID propios etc. Por otro lado, no puede garantizarse que puedan realizarse una autorizacion y, por lo tanto, una transaccion. Por ejemplo, no puede 35 realizarse una autorizacion cuando el proveedor de los contenidos digitales no puede determinar el identificador del telefono movil debido a deficiencias tecnicas del telefono movil, p.ej. cuando el telefono movil no puede transmitir su identificador. Esto es el caso, por ejemplo, cuando el canal de transmision usado, p.ej. el canal de datos WAP, no soporta la transmision del identificador del telefono movil. Si en lugar del canal de datos WAP se usa un canal de datos IP, tampoco puede garantizarse una determinacion del identificador del telefono movil.
40
Sin el identificador del telefono movil, en muchos casos no puede realizarse ni una autorizacion ni una transaccion de pago. Asi el usuario se vera privado del acceso a los contenidos digitales por limitaciones tecnicas.
El documento DE10243292-A1 describe un procedimiento de autorizacion de una transaccion por internet, como 45 esta resumido en el preambulo de la reivindicacion independiente 1 de la presente solicitud.
Por el documento US 2007/0107044 A1 se conoce un procedimiento para la realizacion de una autorizacion de una transaccion por internet mediante un dispositivo de autorizacion, pudiendo acoplarse un primer terminal y un segundo terminal mediante una red de comunicaciones con el dispositivo de autorizacion, pudiendo realizarse la 50 transaccion en uno de los dos terminales y pudiendo iniciarse la autorizacion en uno de los dos terminales. Un proceso de autorizacion conduce a una denegacion de la realizacion de la transaccion cuando falla una determinacion de un identificador del terminal. Los datos de transaccion para la transaccion son recibidos por el dispositivo de autorizacion a traves de un segundo canal de transmision.
55 El objetivo de la invencion es, por lo tanto, poner a disposicion un procedimiento y un dispositivo para la autorizacion de una transaccion que, por un lado, simplifique una autorizacion de la realizacion de la transaccion y que, por otro lado, permita una realizacion tambien en caso de que las circunstancias tecnicas no permitan una autorizacion convencional.
En un primer aspecto de la invencion se pone a disposicion un procedimiento para la realizacion de una autorizacion de una transaccion por internet mediante un dispositivo de autorizacion, pudiendo realizarse la transaccion en un primer terminal, pudiendo iniciarse el proceso de autorizacion en un segundo terminal y comprendiendo la autorizacion mediante el dispositivo de autorizacion las etapas:
5
- la recepcion de datos de transaccion procedentes del segundo terminal por parte del dispositivo de autorizacion;
- la determinacion de un identificador que identifica el segundo terminal por parte del dispositivo de autorizacion;
10 - la determinacion de una autorizacion de transaccion, que puede ser asignada al identificador del
segundo terminal, dependiendo la autorizacion de transaccion de los datos de transaccion;
- la habilitacion de la realizacion de la transaccion por internet en funcion de la autorizacion de transaccion; y
- la puesta a disposicion de datos que son indicadores para la habilitacion de la realizacion de la
15 transaccion por internet, para la salida en el primer terminal o en el segundo terminal, permitiendo los
datos la realizacion de la transaccion por internet.
La ventaja en comparacion con los procedimientos conocidos por el estado de la tecnica esta en que puede realizarse una autorizacion de una transaccion por internet incluso cuando el terminal o el canal de transmision 20 puesto a disposicion en primer lugar no permiten una autorizacion por limitaciones tecnicas. Cuando el dispositivo de autorizacion detecta que no puede determinarse el identificador del terminal en el que se ha iniciado el primer proceso de autorizacion, solicita automaticamente la autorizacion a traves de un segundo canal de transmision de un terminal. De este modo se aumenta claramente la probabilidad de que la autorizacion pueda finalizar con exito.
25 En caso de una eleccion adecuada del segundo canal de transmision, por ejemplo un canal de transmision que transmite siempre el identificador de un terminal, incluso puede garantizarse con una probabilidad muy elevada que la autorizacion pueda finalizar con exito.
El procedimiento tambien puede comprender la realizacion de una autorizacion de una transaccion por internet 30 mediante un dispositivo de autorizacion, pudiendo realizarse la transaccion en un primer terminal, pudiendo iniciarse la autorizacion en un segundo terminal, o pudiendo realizarse e iniciarse la transaccion y la autorizacion en el primer terminal o en el segundo terminal, pudiendo acoplarse el primer terminal y el segundo terminal mediante una red de comunicaciones con el dispositivo de autorizacion y cuando el proceso de autorizacion, que comprende las etapas
35 - la recepcion de datos de transaccion procedentes del segundo terminal por parte del dispositivo de
autorizacion, siendo recibidos los datos de transaccion a traves de un primer canal de transmision; y
- la determinacion de un identificador que identifica el segundo terminal mediante el dispositivo de autorizacion;
40 conduce a una denegacion de la realizacion de la transaccion por una determinacion fallida del identificador, generando el dispositivo de autorizacion por la denegacion datos para la transmision al primer terminal o al segundo terminal, conteniendo los datos los datos de transaccion y una instruccion para la inicializacion de un segundo proceso de autorizacion mediante el segundo terminal a traves de un segundo canal de transmision, siendo recibidos los datos de transaccion a traves del segundo canal de transmision del dispositivo de autorizacion y 45 comprendiendo la generacion de datos mediante el dispositivo de autorizacion una determinacion de las propiedades del hardware del primero o del segundo terminal y una adaptacion de los datos a las propiedades del hardware.
Cuando falla el primer proceso de autorizacion, porque no se puede determinar ningun identificador a traves del 50 primer canal de transmision para el segundo terminal, porque por ejemplo no se ha transmitido el identificador, se solicita un segundo proceso de autorizacion desde el segundo terminal a traves de un segundo canal de transmision. De este modo puede aumentarse claramente la probabilidad de poder determinar un identificador para el segundo terminal.
55 Otra ventaja esta en que el proveedor de servicios, que facilita por ejemplo un acceso a documentos electronicos (de pago) solo debe poner a disposicion un modo de autorizacion. Si no es posible la primera autorizacion mediante el modo facilitado de autorizacion (p.ej. autorizacion por IP mediante un telefono movil), el dispositivo de autorizacion solicita automaticamente una segunda autorizacion mediante un segundo procedimiento de autorizacion, que puede realizarse mediante el mismo terminal que la primera autorizacion fallida. Determinandose las propiedades del
hardware del terminal, la solicitud de una segunda autorizacion puede adaptarse correspondientemente a las propiedades del hardware del terminal.
El segundo proceso de autorizacion puede ser realizado por el dispositivo de autorizacion y puede comprender una 5 etapa para la determinacion de un segundo identificador, que esta asignado al terminal que inicia el segundo proceso de autorizacion y que identifica el terminal en cuestion.
El segundo proceso de autorizacion puede comprender preferentemente una etapa para la determinacion de una autorizacion de transaccion, pudiendo depender la autorizacion de transaccion del identificador del segundo 10 terminal.
La determinacion del segundo identificador puede comprender una consulta a un dispositivo servidor y una recepcion del segundo identificador por parte del dispositivo servidor. El dispositivo servidor tambien puede formar parte del dispositivo de autorizacion. Esto es especialmente ventajoso cuando el terminal comunica a traves del 15 segundo canal de transmision con un dispositivo servidor. El dispositivo de autorizacion puede determinar asi el segundo identificador, tambien sin acceso al segundo canal de transmision.
El segundo identificador puede ser recibido por el dispositivo de autorizacion a traves del segundo canal de transmision.
20
El segundo canal de transmision puede ser un canal de mensajes cortos de telefonia movil, es decir, un canal de datos de SMS y de senales. De este modo se garantiza que el segundo identificador pueda determinarse siempre, porque el canal de mensajes cortos de telefonia movil preve la transmision de un identificador.
25 El identificador del segundo terminal comprende al menos uno de los siguientes elementos: Mobile Subscriber Integrated Services Digital Network Number (MSISDN), titular e ID del titular.
En una forma de realizacion preferible, la instruccion para la inicializacion del segundo proceso de autorizacion puede comprender:
30
- datos para la generacion y el envio manuales de un mensaje corto (SMS); o
- datos para la generacion y el envio automaticos de un mensaje corto de un contenido predeterminado a un numero de telefono predeterminado; o
35
- un codigo grafico, en el que estan codificados los datos para una generacion y un envio automaticos de un mensaje corto de un contenido predeterminado a un numero de telefono predeterminado.
La determinacion de las propiedades del hardware comprende preferentemente una determinacion de las 40 propiedades del hardware del dispositivo de visualizacion del primer terminal o del segundo terminal. Determinandose las propiedades del hardware del dispositivo de visualizacion del terminal, puede adaptarse correspondientemente la solicitud de una segunda autorizacion segun el dispositivo de visualizacion. De este modo es posible hacer que la solicitud este disponible para cualquier terminal en funcion del terminal.
45 Otros detalles y caracteristicas de la invencion resultan de las reivindicaciones, asi como de la descripcion expuesta a continuacion en relacion con el dibujo. Muestran:
la Figura 1
la Figura 2 la Figura 3
la Figura 4
la Figura 5
la Figura 6
la Figura 7
una primera forma de realizacion del procedimiento segun la invencion (autorizacion por WAP);
otra forma de realizacion del procedimiento segun la invencion (autorizacion por SMS); otra forma de realizacion del procedimiento segun la invencion (autorizacion por PC- WAP);
otra forma de realizacion del procedimiento segun la invencion (autorizacion por PC- WAP-SMS);
otra forma de realizacion del procedimiento segun la invencion (autorizacion por PC-SMS Premium);
una parte del procedimiento segun la invencion para el uso con las formas de realizacion segun la Figura 3 y la Figura 4;
una parte del procedimiento segun la invencion para el uso con la forma de realizacion
segun la Figura 5;
la Figura 8 otra forma de realizacion del procedimiento segun la invencion estando combinadas las formas de realizacion segun la Figura 3 y la Figura 5 y; la Figura 9 otra forma de realizacion del procedimiento segun la invencion, estando combinadas las formas de realizacion segun la Figura 4 y la Figura 5.
A continuacion, se describira el procedimiento segun la invencion del proceso de autorizacion, partiendose de que a continuacion del proceso de autorizacion tiene lugar una transaccion de pago. En lugar de la transaccion de pago tambien pueden tener lugar otras transacciones.
5
Con “autorizacion” se designa la asignacion y la comprobacion de derechos de acceso a datos y servicios a usuarios. La autorizacion puede realizarse tras una autenticacion realizada con exito (comprobacion (verificacion) de una identidad afirmada, p.ej. de una persona). Una autorizacion realizada con exito permite p.ej. el acceso a llamados recursos (p.ej. a datos) en una red de ordenadores, como por ejemplo el internet.
10
1) Autorizacion por WAP
La Figura 1 muestra un proceso de autorizacion segun la invencion (autorizacion por WAP) con posterior transaccion de pago mediante el llamado WAP/IP-Payment o como puede realizarse una determinacion de un usuario o una 15 deteccion de equipo.
El punto de partida es un codigo grafico 1, que esta aplicado en un producto impreso o que se muestra por ejemplo en una pantalla. Como codigo grafico puede usarse por ejemplo un codigo de barras (barcode), un codigo 2D, como p.ej. codigo matricial (codigo QR, Data-Matrix, etc.) o un codigo de color, como p.ej. HCCB (High Capacity Color 20 Barcode). En los ejemplos de realizacion descritos a continuacion se usa siempre un codigo de barras. No obstante, tambien pueden estar previstos respectivamente los otros codigos graficos indicados.
No obstante, para la inicializacion de una transaccion tambien puede estar prevista la tecnologia de campo cercano, como p.ej. RFID. El producto impreso puede estar provisto de una etiqueta RFID, que almacena los datos 25 necesarios para la transaccion. Estos datos pueden ser leidos p.ej. con un terminal movil.
En el codigo de barras o en la etiqueta RFID puede estar codificada o almacenada por ejemplo un URL. La pagina de internet vinculada a este URL puede facilitar informacion adicional (p.ej. de pago) acerca del producto impreso.
30 El proceso de autorizacion para obtener acceso a la pagina de internet codificada en el URL se ejecuta mediante el terminal movil. En este ejemplo de realizacion y en los siguientes, el terminal movil puede ser un telefono movil, un PDA con funcionalidad de telefono movil (smartphone), un portatil con funcionalidad de telefono movil o similar. La funcionalidad de telefono movil puede estar basada p.ej. en las tecnicas de transmision GSM (Global System for Mobile Communication) o UMTS (Universal Mobile Telecommunications System). Un terminal estacionario puede ser 35 p.ej. un ordenador convencional. No obstante, un terminal estacionario puede ser tambien un PDA o un portatil, que sean adecuados para cargar por ejemplo contenidos digitales, p.ej. mediante internet.
El proceso de autorizacion comprende una o varias etapas, en las que se intenta en primer lugar identificar el equipo que pretende obtener acceso a los datos. El equipo puede ser identificable, por ejemplo, con ayuda del MSISDn o 40 una direccion IP. En otra etapa (en el marco de la autorizacion) se comprueba a continuacion si puede concederse al equipo identificado una autorizacion para el acceso. Si el equipo puede ser identificado y se puede asignar una autorizacion al equipo, el proceso de autorizacion ha finalizado con exito.
En cuanto haya finalizado el proceso de autorizacion, a continuacion del cual puede tener lugar una transaccion de 45 pago, mediante el terminal movil, en el terminal movil puede mostrarse o llamarse el contenido pagado. El proceso de autorizacion tambien puede permitir una serie de transacciones posteriores (esto tambien es valido para las siguientes formas de realizacion segun la Figura 2 a la Figura 9). Tras un proceso de autorizacion realizado con exito pueden realizarse, por ejemplo, varias compras en una tienda online.
50 En el codigo de barras 1 puede estar codificado p.ej. una direccion de internet. El terminal movil, por ejemplo un telefono movil, puede leer con ayuda de un software de lectura de codigos de barras (denominado en lo sucesivo lector de codigos de barras) el codigo de barras mediante la camara del telefono movil. El lector de codigos de barras detecta la direccion de internet codificada en el mismo y ofrece la opcion de llamar la direccion p.ej. en el navegador del telefono movil. Dado el caso, la llamada puede ser confirmada por el usuario. El navegador del
telefono movil llama a continuacion la pagina de internet que pertenece a la direccion de internet.
En el marco de una llamada identificacion, que comprende la autenticacion, la autorizacion y que determina las propiedades del hardware del equipo que hace la consulta, se realizan los siguientes procesos:
5
- El proceso “tsPayment” determina si pueden realizarse una autenticacion y una autorizacion (etapa 1b). tsPayment puede estar configurado de tal modo que mediante el mismo tambien puede ejecutarse un proceso de pago, que puede tener lugar tras una autorizacion realizada con exito.
10 - El proceso “tsContenido” determina en que forma ha de realizarse la representacion de la pagina de
internet en el terminal (etapa 1a). Segun el tipo de terminal, p.ej. telefono movil o pantalla de ordenador, la pagina de internet es procesada correspondientemente por tsContenido.
Los dos procesos pueden ejecutarse en un servidor web. No obstante, los procesos tambien pueden ejecutarse en 15 distintos servidor webs, comunicando los procesos entre si mediante una interfaz especial.
Las dos etapas 1a y 1b son respectivamente identicas para las formas de realizacion descritas a continuacion en la Figura 2 a la Figura 9. La unica excepcion es la forma de realizacion segun la Figura 5.
20 Etapa 1a:
El servidor web que suministra (tsContenido) detecta, p.ej. mediante una deteccion de Useragent (o una deteccion de equipo), que la pagina de internet debe suministrarse / emitirse para una pantalla pequena (que se usa habitualmente en terminales moviles).
25
Etapa 1b:
Mediante una interfaz se consulta al Payment-Provider (denominado en las Figuras respectivamente Pay Provid.) si para el terminal movil que realiza la consulta (que llama la pagina de internet) puede realizarse la determinacion del 30 Mobile Subscriber Integrated Services Digital Network Number (MSISDN) del terminal movil, del usuario, del titular o del User-ID (OK?). El tipo de la determinacion corresponde al Payment-Provider.
Con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) puede iniciarse una transaccion de pago correspondiente:
35
- WAP/IP movil (en caso de OK!) o
- internet movil (en caso de NoOK!), vease la Figura 2.
En caso de un acuse de recibo positivo (OK!) por parte del Payment-Provider, el servidor web (tsContenido) emite la 40 pagina de internet 2 al terminal movil con los siguientes elementos: enlace de pago, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. El enlace de pago tambien puede llamarse de otro modo. Esto significa que el proceso de autorizacion ha finalizado con exito.
En caso de un acuse de recibo negativo (NoOK!), es decir, cuando no puede determinarse el MSISDN, el servidor 45 web (tsPayment) ofrece automaticamente un metodo alternativo de autorizacion para terminar el proceso de autorizacion de forma segura y con exito. Aqui es ventajoso que el proceso de autorizacion, a diferencia de lo que ocurre en los procedimientos conocidos por el estado de la tecnica, no finalice simplemente tras un intento fallido, si no que el servidor web (tsPayment) intenta mediante una posibilidad alternativa de autorizacion, por ejemplo una autorizacion por SMS, finalizar el proceso de autorizacion con exito. Una descripcion detallada se hara en relacion 50 con la Figura 2.
Etapa 2a:
Con un clic en el enlace de pago, se consulta al servidor web (tsPayment) la posibilidad para realizar el pago 55 (Authorize / Payment!). El servidor web (tsPayment) consulta a su vez a traves de una interfaz al Payment-Provider si es posible la realizacion del pago (Payment OK?).
El Payment-Provider indica la realizacion de esta transaccion a su vez a los operadores de redes de telefonia movil. La asignacion del MSISDN, del usuario o del titular al operador de red correspondiente, asi como la consulta para la
realizacion de una transaccion de pago al operador de red (p.ej. la consulta de si hay suficiente saldo de prepago o si hay suficiente solvencia o si puede realizarse una transaccion segun las normas internas de los operadores de redes de telefonia movil) corresponde al Payment-Provider. Tambien es posible basarse en otras normas al realizar la consulta.
5
Etapa 2b:
Si puede realizarse la transaccion de pago, se envia un acuse de recibo positivo (Payment OK!) del Payment- Provider al servidor web que realiza la consulta (tsPayment).
10
El servidor web (tsContenido) suministra (Confirmacion*) a continuacion una pagina de internet 3 al terminal movil con una confirmacion asi como enlaces relacionados. Con ello puede llamarse o cargarse el contenido pagado. El proceso de autorizacion y el proceso de pago se han realizado con exito.
15 El proceso de pago o la representacion del proceso de pago puede realizarse mediante una o varias etapas. El numero de las etapas a realizar puede depender de los procesos y/o del protocolo entre el Payment-Provider y el operador de red de telefonia movil correspondiente, que esta integrado en el proceso de pago correspondiente.
En lugar de un operador de red de telefonia movil, tambien puede estar prevista otra instancia, que dispone de los 20 derechos necesarios para la autorizacion y realizacion de transacciones descritas en este contexto. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
25
2) Autorizacion por SMS
La Figura 2 muestra un proceso de autorizacion segun la invencion (autorizacion por SMS) con posterior transaccion de pago mediante el llamado SMS-Billing (facturacion por SMS) o como puede realizarse una determinacion de 30 usuario / deteccion de equipo cuando ha fallado un primer intento de autorizacion. En lugar de una transaccion de pago, a continuacion del proceso de autorizacion tambien pueden tener lugar otras transacciones.
En el marco de la invencion esta prevista la autorizacion por SMS, cuando el Payment-Provider emite un acuse de recibo negativo (NoOK!) en el marco de la autorizacion por WAP, como se ha descrito en relacion con la Figura 1. La 35 autorizacion por SMS se usa, por lo tanto, cuando no puede realizarse la determinacion del usuario, la deteccion del equipo o la autorizacion de una transaccion de pago segun la autorizacion por WAP.
De este modo aumenta de forma ventajosa claramente la probabilidad de poder finalizar con exito un proceso de autorizacion. Al cambiar a un proceso de autorizacion alternativo (p.ej. autorizacion por SMS), la autorizacion termina 40 con exito tambien cuando ha fallado un primer intento de autorizacion, por ejemplo por deficiencias tecnicas de un terminal. El proveedor de servicios ya no tiene que ofrecer varias variantes de autorizacion para permitir la autorizacion mediante distintos terminales. Para el proveedor de servicios basta con ofrecer una variante de autorizacion, puesto que el servidor web (tsPayment) ofrece automaticamente otra variante de autorizacion, mediante la que puede ejecutarse la autorizacion.
45
El punto de partida es tambien aqui un codigo de barras 1, que esta aplicado en un producto impreso o que se muestra por ejemplo en una pantalla. El proceso de autorizacion se ejecuta mediante el terminal movil.
En cuanto haya finalizado el proceso de autorizacion (preferentemente con posterior transaccion de pago) mediante 50 el terminal movil, en el terminal movil puede mostrarse o llamarse el contenido pagado.
La lectura del codigo de barras con el terminal movil, asi como la llamada de la pagina de internet que pertenece a la direccion de internet (desde el codigo de barras) se realiza de la forma que ya se ha descrito en relacion con la Figura 1.
55
Los procesos tsPayment (etapa 1b) y tsContenido (etapa 1a) en el marco de una identificacion se ejecutan en el servidor web (veanse la etapa 1a y la etapa 1b de la Figura 1).
Con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) se inicia una transaccion de pago
correspondiente:
- WAP/IP movil (en caso de OK!), vease la Figura 1, o
- internet movil (en caso de NoOK!).
5
En la descripcion de la forma de realizacion mostrada en la Figura 2, se parte de que la identificacion y, por lo tanto, la autorizacion no se han realizado con exito (NoOK!).
Etapa 2:
10
En caso de un acuse de recibo negativo por parte del Payment-Provider (NoOK!), el servidor web (tsContenido) emite la pagina de internet 2 al terminal movil con los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, enlace de SMS, asi como introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. y un enlace de continuar. El enlace de SMS o el enlace de continuar tambien pueden llamarse de 15 otra manera.
Etapa 3:
Segun la instruccion de SMS, que contiene el texto de SMS y el numero de SMS, mediante el terminal movil se 20 genera un SMS correspondiente, preferentemente automaticamente mediante un clic, etapa 3b, en la instruccion de SMS. Aqui se genera en funcion del terminal movil usado, la version y las funciones del software del navegador presente el SMS p.ej. mediante el navegador o mediante la aplicacion nativa de SMS. El texto del SMS puede contener datos de transaccion (p.ej. ID de transaccion), que son relevantes para la realizacion de una transaccion.
25 Aqui es especialmente ventajoso que una autorizacion mediante una segunda variante de autorizacion se facilita de tal modo que el usuario del terminal pueda realizar la autorizacion sin una entrada manual de datos. Solo es necesaria una confirmacion para iniciar la autorizacion. Asi se evitan de forma eficiente entradas incorrectas, que pueden conducir a asientos incorrectos, etc. De forma alternativa, la generacion del SMS tambien puede realizarse mediante una entrada manual, etapa 3a, en caso de que el terminal no soporte la generacion automatica de un 30 SMS.
Etapa 3c:
Mediante el envio del SMS se transmiten MSISDN, ID de transaccion, texto del SMS, caracteres del SMS etc. al
35 Payment-Provider (MSISDN User?). Por lo tanto, se usa otro canal de transmision (canal de datos SMS y canal de
senales) para la transmision de los datos de transaccion que en la transmision segun el procedimiento segun la Figura 1, en el que se usa el canal de datos WAP, de modo que se garantizan una determinacion del identificador del telefono movil y, por lo tanto, una autorizacion.
40 La cooperacion entre el Payment-Provider y el operador de red de telefonia movil puede realizarse de distintas maneras y no esta descrita aqui mas detalladamente.
Etapa 3d:
45 El Payment-Provider transmite al servidor web (tsPayment) a traves de una interfaz el MSISDN, el User, el titular, un ID especial (MSISDN User!) y/o detalles de la transaccion (p.ej. texto de SMS) o una combinacion de estos. A continuacion, el servidor web consulta al Payment-Provider si puede realizarse el pago (Payment OK?). El Payment- Provider indica a su vez la realizacion de esta transaccion de pago a los operadores de red de telefonia movil.
50 La asignacion del MSISDN, del User o del titular al operador de red correspondiente asi como la consulta para la
realizacion de la transaccion de pago al operador de red (p.ej. la consulta si hay suficiente saldo de prepago o si es
suficiente la solvencia o si puede realizarse una transaccion segun las normas internas de los operadores de red de telefonia movil) corresponde al Payment-Provider.
55 Etapa 2a:
Al hacer clic en el enlace de continuar, se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize / Payment?). La consulta tambien puede ser una consulta si la autorizacion se ha realizado con exito. En caso de un acuse de recibo negativo (porque por ejemplo no se ha realizado completamente la etapa 3), el servidor web
(tsContenido) vuelve a emitir la pagina de internet 2 al terminal movil con un aviso correspondiente.
Etapa 4:
5 En caso de un acuse de recibo positivo (Payment OK!) por parte del Payment-Provider, el servidor web (tsContenido) suministra una pagina de internet al terminal movil con una confirmacion asi como enlaces relacionados (confirmacion). Mediante estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse una nueva transaccion.
10 En lugar de la lectura de un codigo de barras, en una pagina web movil que se visualiza en el terminal movil, ya puede visualizarse una instruccion de SMS y un enlace de SMS, que contiene el texto del SMS y el numero del SMS o el numero del SMS y el texto del SMS. El enlace de SMS hace que el SMS se genere automaticamente. Aqui el SMS se genera mediante el navegador o la aplicacion nativa de SMS en funcion del terminal movil usado, la version y las funciones del software del navegador existente. El texto del SMS puede contener datos de transaccion (p.ej. ID 15 de la transaccion), que son relevantes para la realizacion de una transaccion.
Como alternativa, un SMS tambien puede enviarse manualmente con el texto del SMS representado al numero de SMS representado. Tras una autorizacion y, dado el caso, un pago realizados con exito se suministra una pagina de resultados al terminal movil, que contiene un enlace de continuar para cargar el contenido comprado. En lugar de la 20 pagina de resultados, el contenido comprado tambien puede suministrarse al terminal movil. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues del proceso de autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
25
3) Autorizacion por PC-WAP
La Figura 3 muestra una forma de la autorizacion (autorizacion por PC-WAP) con posterior transaccion de pago mediante el llamado WAP/IP-Payment o como puede realizarse una determinacion del usuario / deteccion del 30 equipo. Esta forma de realizacion esta basada en el procedimiento descrito en relacion con la Figura 1.
El acceso o la inicializacion de la autorizacion se realizan mediante un codigo de barras, que esta colocado en una pagina web. Esta pagina web se muestra en un dispositivo de visualizacion de un equipo estacionario (p.ej. ordenador).
35
Este procedimiento (segun la Figura 3) esta caracterizado porque el area accesible mediante el terminal estacionario esta vinculada al procedimiento de autorizacion realizado mediante el terminal movil. Esto significa, que en el terminal estacionario se indica el proceso de autorizacion. En cuanto este se haya realizado mediante el terminal movil, en el terminal estacionario puede mostrarse o llamarse el contenido pagado o pueden realizarse 40 transacciones posteriores (p.ej. otras compras).
Es decir, el procedimiento se realiza mediante dos terminales diferentes, determinandose las propiedades del hardware de los terminales. Las propiedades del hardware determinadas permiten al dispositivo de autorizacion
45 - adaptar u optimizar las pagina webs para la representacion en el terminal estacionario (p.ej. monitor
del PC) para realizar p.ej. una compra de contenidos o productos, y - adaptar u optimizar las pagina webs para la representacion en la pantalla de terminales moviles para
realizar la autorizacion (p.ej. la autorizacion de una compra).
50 Etapa 1:
En una pagina de internet hay un codigo de barras 2D. El servidor web que suministra la pagina (tsContenido o tercer proveedor) detecta mediante la deteccion del Useragent (o deteccion de equipo) que la pagina de internet debe suministrarse o emitirse para un terminal estacionario (monitor de PC, notebook, portatil o sim.).
En el codigo de barras esta codificada una direccion de internet. El codigo de barras se lee y evalua con el terminal movil. Esto se realiza de la forma descrita en relacion con la Figura 1. El navegador del terminal movil llama la pagina de internet que pertenece a la direccion de internet.
En el marco de la autorizacion se realizan ahora los procesos descritos en relacion con la Figura 1, tsPayment (etapa 1b) y tsContenido (etapa 1a).
Con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) se inicia una transaccion de pago 5 correspondiente:
- PC - WAP-Payment (OK!) o
- PC - SMS- Billing (NoOK!), vease la Figura 4.
10 Etapa 2:
En caso de un acuse de recibo positivo (OK!) por parte del Payment-Provider, es decir, cuando la autorizacion se ha realizado con exito, el servidor web (tsContenido) emite la pagina de internet 2 al terminal movil con los siguientes elementos: enlace de pago, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. 15 El enlace de pago tambien puede llamarse de otro modo.
Etapa 2a:
Con un clic en el enlace de pago en la pagina de internet 2, se consulta al servidor web (tsPayment) la posibilidad 20 para realizar el pago (Authorize / Payment!). El servidor web (tsPayment) consulta a su vez a traves de una interfaz al Payment-Provider si es posible la realizacion del pago (Payment OK?). La comunicacion entre el servidor web (tsPayment) y el Payment-Provider se realiza de la forma ya descrita en relacion con la Figura 1.
Etapa 2b:
25
En caso de un acuse de recibo positivo (Payment OK!) por parte del Payment-Provider al servidor web (tsPayment), se realiza la transaccion de pago o se autoriza la realizacion.
Etapa 3:
30
El servidor web (tsContenido) suministra a continuacion (Confirmacion*) una pagina de internet 3 al terminal movil con una confirmacion asi como con enlaces relacionados. El proceso de pago propiamente dicho puede realizarse mediante una o varias etapas. Esto depende entre otras cosas de los procesos o de los protocolos entre el Payment- Provider y el operador de red de telefonia movil correspondiente, que esta implicado en el proceso de pago 35 correspondiente.
Mediante los enlaces relacionados, puede llamarse o cargarse el contenido pagado o puede iniciarse una transaccion nueva.
40 No obstante, el acceso a los contenidos pagados puede realizarse segun la invencion tambien mediante la pagina web 1 en el terminal estacionario. Para ello se realiza la etapa 1c descrita a continuacion.
Etapa 1c:
45 Mediante un clic en el enlace de continuar, se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize Payment?). Esta consulta puede realizarse transmitiendo la consulta p.ej. un ID de la transaccion, que coincide con un ID de la transaccion durante el proceso de autorizacion.
En caso de un acuse de recibo negativo (por ejemplo porque aun no se ha realizado ninguna autorizacion mediante 50 el terminal movil), el servidor web (tsContenido) vuelve a emitir la pagina 1 optimizada para el terminal estacionario con un aviso correspondiente.
Etapa 4:
55 En caso de un acuse de recibo positivo, el servidor web (tsContenido) transmite una pagina de confirmacion 4 al terminal estacionario (confirmacion). Esta contiene enlaces relacionados, mediante los que puede llamarse o cargarse el contenido pagado o pueden realizarse otras transacciones.
Este control del proceso descrito en relacion con la Figura 3 puede implementarse en el marco de tsContenido o
puede integrarse mediante API en la oferta de paginas de internet de terceros proveedores. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente 5 indicados.
4) Autorizacion por PC-WAP-SMS
La Figura 4 muestra una forma de autorizacion (autorizacion por PC-WAP-SMS) con posterior transaccion de pago 10 mediante el llamado SMS-Billing o como puede realizarse una determinacion de usuario / deteccion de equipo cuando no es tecnicamente posible una autorizacion por WAP o una autorizacion por PC-WAP (como esta descrita en la Figura 3). Esta forma de realizacion esta basada en los procedimientos como estan descritos en relacion con la Figura 2 (autorizacion por SMS) y la Figura 3 (autorizacion por PC-WAP).
15 La autorizacion por PC-WAP-SMS se usa como variante alternativa, cuando no puede realizarse la determinacion del usuario, la deteccion de equipo o la autorizacion de transacciones de pago segun la autorizacion por WAP o la autorizacion por PC-WAP.
El acceso o la inicializacion de la autorizacion se realizan (como en la Figura 3) mediante un codigo de barras, que 20 esta colocado en una pagina web. Esta pagina web se muestra en un dispositivo de visualizacion de un equipo estacionario (p.ej. ordenador).
Este procedimiento (segun la Figura 4) esta caracterizado porque el area accesible mediante el terminal estacionario esta vinculada al procedimiento de autorizacion realizado mediante el terminal movil. Esto significa, que en el 25 terminal estacionario se indica el proceso de autorizacion. En cuanto este se haya realizado mediante el terminal movil, en el terminal estacionario puede mostrarse o llamarse el contenido pagado o pueden realizarse transacciones posteriores (p.ej. otras compras).
Es decir, se interactua entre areas 30
- que estan adaptadas u optimizadas para la representacion de paginas web en el terminal estacionario (p.ej. monitor del PC) para realizar p.ej. una compra de contenidos o productos, y
- que estan adaptadas u optimizadas para la representacion de paginas web en la pantalla de terminales moviles para realizar la autorizacion (p.ej. la autorizacion de una compra).
35
Etapas 1, 1a y 1b:
Las etapas 1, 1a y 1b corresponden sustancialmente a las etapas 1, 1a y 1b de la Figura 3.
40 Con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) se inicia una transaccion de pago correspondiente:
- PC - WAP-Payment (OK!), vease la Figura 3 o
- PC - SMS-Billing (NoOK!).
45
Etapa 2:
En caso de un acuse de recibo negativo (NoOK!) por parte del Payment-Provider, la pagina de internet 2 se transmite al terminal movil con los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, enlace 50 de SMS, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. asi como un enlace de continuar.
El enlace de SMS o el enlace de continuar tambien pueden llamarse de otro modo.
55 Las etapas 3, 3a, 3b, 3c, 3d, 2a y 4 posteriores corresponden sustancialmente a las etapas 3, 3a, 3b, 3c, 3d, 2a y 4 de la Figura 2. A este respecto puede remitirse a la descripcion de la Figura 2.
Etapa 1c:
Con un clic en el enlace de continuar en la pagina web 1 en el equipo estacionario, se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize / Payment?). En caso de un acuse de recibo negativo, el servidor web (tsContenido) vuelve a emitir la pagina 1 optimizada para el equipo estacionario con un aviso correspondiente.
5 Etapa 5:
En caso de un acuse de recibo positivo (Authorize / Payment?), el servidor web suministra una pagina de confirmacion 4 al equipo estacionario (confirmacion). Esta contiene enlaces relacionados. Mediante estos enlaces puede llamarse o cargarse el contenido pagado o pueden realizarse otras transacciones.
10
Este control del proceso descrito en relacion con la Figura 4 puede implementarse en el marco de tsContenido o puede integrarse mediante API en la oferta de paginas de internet de terceros proveedores. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una 15 confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
5) Autorizacion por PC-SMS Premium
20 La Figura 5 muestra una forma de la autorizacion (autorizacion por PC-SMS Premium) realizandose al mismo tiempo una transaccion de pago mediante el llamado SMS-Billing o como puede realizarse una determinacion de usuario / deteccion de equipo, cuando no pueden o no deben usarse autorizaciones como estan descritas en la Figura 1 a la Figura 4.
25 El punto de partida es aqui un codigo de barras, que se muestra en una pagina web en el equipo estacionario.
En cuanto haya finalizado la autorizacion o la transaccion de pago mediante el terminal movil (por SMS), en el equipo estacionario puede mostrarse o llamarse el contenido pagado o pueden realizarse otras transacciones.
30 Etapa 1:
En una pagina de internet 1 hay un codigo de barras 2D. El servidor web que suministra la pagina (tsContenido o tercer proveedor) detecta mediante la deteccion del Useragent (o deteccion de equipo) que la pagina de internet debe suministrarse o emitirse para un terminal estacionario (p.ej. monitor de PC, notebook, portatil o sim.). Ademas 35 del codigo de barras, la pagina de internet 1 contiene los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. y un enlace de continuar. En el codigo de barras esta codificada una instruccion de SMS.
Etapa 2:
40
A continuacion, se genera y envia un SMS.
Etapa 2a:
45 La generacion del SMS puede realizarse manualmente con ayuda de los datos emitidos.
Etapa 2b:
Como alternativa, la generacion del SMS puede realizarse automaticamente mediante fotografia o escaneado del 50 codigo de barras. El terminal movil puede leer el codigo de barras mediante la camara con ayuda de un software de lectura de codigos de barras. El lector de codigos de barras detecta los caracteres del SMS y ofrece la opcion de generar y, dado el caso, enviar el SMS. Tambien es posible generar el SMS mediante la aplicacion nativa de SMS.
Puede estar previsto que el usuario deba confirmar respectivamente la generacion y el envio del SMS.
55
Etapa 2c:
Mediante el envio del SMS se transmiten MSISDN, identificador de la transaccion, texto del SMS, caracteres del SMS etc. al Payment-Provider (MSISDN User?).
El Payment-Provider transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el usuario, el titular y/o 5 un ID especial (MSISDN User!), asf como dado el caso datos de transaccion (que pueden estar contenidos p.ej. en el texto del SMS). A continuacion, el servidor web consulta al Payment-Provider la realizacion del pago (Payment OK?).
El Payment-Provider indica la realizacion de esta transaccion de pago al operador de red de telefoma movil. La 10 asignacion del MSISDN, del usuario o del titular al operador de red correspondiente, asf como la consulta para la realizacion de una transaccion de pago al operador de red corresponden al Payment-Provider. Respecto al proceso posterior entre el operador de red y el Payment-Provider se remite a la etapa 2a de la Figura 1.
Etapa 1a:
15
Al hacer clic en el enlace de continuar en la pagina de internet 1, se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize / Payment?). En caso de un acuse de recibo negativo, el servidor web (tsContenido) vuelve a emitir la pagina de internet 2 optimizada para el terminal estacionario con un aviso correspondiente.
20 Etapa 3:
En caso de un acuse de recibo positivo (Authorize / Payment?), el servidor web (tsContenido) suministra una pagina de confirmacion 3 al terminal estacionario (confirmacion). Esta pagina contiene enlaces relacionados. Mediante estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse una nueva transaccion.
25
Este control del proceso descrito en relacion con la Figura 5 puede implementarse en el marco de tsContenido o puede integrarse mediante API en la oferta de paginas de internet de terceros proveedores. Aquf no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una 30 confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
6) Inicio del procedimiento para una autorizacion por PC-WAP o una autorizacion por PC-WAP-SMS
35 La Figura 6 muestra un procedimiento que puede realizarse opcionalmente antes de los procedimientos de autorizacion por PC-WAP (vease la Figura 3) y/o autorizacion por PC-WAP-SMS (Figura 4).
Etapa 1:
40 En una pagina de internet 1 (en un terminal estacionario) hay una introduccion del contenido y un enlace de continuar. La introduccion del contenido puede estar formada por textos, imagenes, indicaciones de precios, condiciones generales de contratacion etc. que describen el producto.
Etapa 1a:
45
Con un clic en el enlace de continuar, se consulta al servidor web (tsPayment) la posibilidad de realizar una autorizacion (o una transaccion de pago).
Etapa 1b:
50
Mediante una interfaz, se consulta al Payment-Provider (OK?) si para el equipo que realiza la consulta puede determinarse el MSISDN, el usuario o el titular. El tipo de la determinacion corresponde al Payment-Provider.
Etapa 1c:
55
Con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) se inicia el proceso de autorizacion (y dado el caso una posterior transaccion de pago) segun el procedimiento
- autorizacion por PC-WAP (vease la Figura 3) o
- autorizacion por PC-WAP-SMS (vease la Figura 4)
No se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede 5 transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
7) Inicio del procedimiento para una autorizacion por PC-SMS Premium
10 La Figura 7 muestra un procedimiento que puede realizarse opcionalmente antes del procedimiento de autorizacion por PC-SMS Premium (vease la Figura 5).
Etapa 1:
15 En una pagina de internet 1 de un terminal estacionario hay una introduccion de contenido y un enlace de continuar. La introduccion del contenido puede estar formada por textos, imagenes, indicaciones de precios, condiciones generales de contratacion etc. que describen el producto.
Etapas 1a, 1b y 1c:
Las etapas 1a, 1b y 1c corresponden sustancialmente a las etapas 1a, 1b y 1c de la Figura 6, iniciandose en la etapa 1c con ayuda del acuse de recibo del Payment-Provider (OK! o NoOK!) el proceso de autorizacion (y dado el caso una transaccion de pago posterior) segun el procedimiento de autorizacion por PC-SMS Premium (vease la Figura 5). Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
8) Autorizacion por PC-WAP combinada con autorizacion por PC-SMS Premium 30
La Figura 8 muestra una combinacion segun la invencion de la autorizacion por PC-WAP (vease la Figura 3) con la autorizacion por PC - SMS Premium (vease la Figura 5).
Etapa 1:
35
En una pagina de internet 1 que se muestra en un terminal estacionario hay un codigo de barras 2D. El servidor web que suministra la pagina (tsContenido o servidor web de un tercer proveedor) detecta p.ej. mediante la deteccion del Useragent (o deteccion de equipo) que la pagina de internet debe generarse y suministrarse o emitirse para un terminal estacionario (p.ej. monitor de PC, notebook, portatil o sim.).
40
En el codigo de barras esta codificada una direccion de internet (URL). El terminal movil puede leer el codigo de barras mediante la camara con ayuda de un software de lectura de codigos de barras. El lector de codigos de barras detecta la direccion de internet y ofrece la opcion de llamar la direccion en el navegador del terminal movil. Dado el caso, la llamada puede ser confirmada por el usuario. El navegador del terminal movil llama a continuacion la pagina 45 de internet que pertenece a la direccion de internet.
En el marco de la identificacion se realizan dos procesos:
- El proceso “tsPayment” determina si puede realizarse una transaccion de pago (etapa 1 b);
50 - El proceso “tsContenido” determina en que forma ha de realizarse la representacion de la pagina de
internet (etapa 1a).
Las dos etapas 1a y 1b corresponden a las etapas 1a y 1b que se han descrito en relacion con la Figura 1 y la Figura 3.
55
Con ayuda del acuse de recibo del proveedor (OK! o NoOK!) se inicia el proceso de autorizacion (y dado el caso una transaccion de pago posterior) segun los procedimientos:
- autorizacion por PC-WAP (vease la Figura 3) o
20
25
autorizacion por PC-SMS Premium (vease la Figura 5).
Etapa 2:
5 En caso de un acuse de recibo positivo (OK!) por parte del Payment-Provider, la pagina de internet 2 se emite al terminal movil con los siguientes elementos: enlace de pago, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. El enlace de pago tambien puede llamarse de otro modo.
Etapa 2a:
10
Mediante un clic en el enlace de pago (de la pagina de internet movil), se consulta al servidor web (tsPayment) la posibilidad de realizar el pago (Authorize / Payment!). El servidor web (tsPayment) consulta a traves de una interfaz al Payment-Provider la realizacion del pago (Payment OK?). El Payment-Provider indica la realizacion de esta transaccion de pago a su vez a los operadores de redes de telefonia movil. La asignacion del MSISDN, del usuario o 15 del titular al operador de red correspondiente, asi como la consulta para la realizacion de una transaccion de pago al operador de red corresponde al Payment-Provider.
Etapa 2b:
20 En caso de un acuse de recibo positivo (Payment OK!) por parte del Payment-Provider, se realiza la transaccion de pago o se autoriza la realizacion.
Etapa 3:
25 El servidor web (tsContenido) suministra a continuacion una pagina de internet al terminal movil con una confirmacion asi como con enlaces relacionados (confirmacion*). El proceso de pago o la representacion del proceso de pago puede realizarse mediante una o varias etapas. El numero de las etapas a realizar puede depender de los procesos entre el Payment-Provider y el operador de red de telefonia movil correspondiente, que esta implicado en el proceso de pago correspondiente. Mediante los enlaces puede llamarse o cargarse el contenido 30 pagado o puede iniciarse un nuevo proceso de pago u otra transaccion.
Etapa 1c:
Mediante un clic en el enlace de continuar (en el terminal estacionario), se consulta al servidor web (tsPayment) si se 35 ha realizado el pago (Authorize Payment?) o si ha finalizado con exito.
Etapa 4:
En caso de un acuse de recibo positivo (Authorize / Payment?), el servidor web (tsContenido) suministra una pagina 40 de confirmacion al terminal estacionario (confirmacion Payment). Esta contiene enlaces relacionados. Mediante estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse otra transaccion o un nuevo proceso de pago.
Las siguientes etapas son caracteristicas para la combinacion de los procedimientos de autorizacion por PC-WAP 45 con autorizacion por PC-SMS Premium.
Etapa 6:
En caso de un acuse de recibo negativo para el terminal estacionario (por ejemplo, porque aun no se han realizado 50 por completo las etapas 1a, 1b, 2, 2a, 2b, 3, etc.), el servidor web (tsContenido) vuelve a emitir una pagina nueva, optimizada para el terminal estacionario. Ademas de otro codigo de barras nuevamente generado, la pagina contiene los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. y un enlace de continuar. En el codigo de barras esta codificado un SMS.
55
Etapa 7:
Segun la instruccion de SMS, se genera un SMS correspondiente.
La generacion del SMS puede realizarse mediante entrada manual.
5 Etapa 7b:
La generacion del SMS puede realizarse automaticamente mediante escaneado o fotografia del codigo de barras. El terminal movil puede leer el codigo de barras mediante la camara con ayuda de un software de lectura de codigos de barras. El lector de codigos de barras detecta los caracteres del SMS y ofrece la opcion de generar el SMS. Dado el 10 caso, el usuario confirma la generacion. Aqui el SMS se genera mediante el navegador, mediante una aplicacion nativa de SMS o mediante el software del lector de codigos de barras en funcion del terminal movil usado, la version y las funciones del software del navegador existente.
Etapa 7c:
15
Mediante el envio del SMS se transmiten MSISDN, ID de transaccion, texto del SMS, caracteres del SMS, detalles de la transaccion etc. al Payment-Provider (MSISDN User?). Los detalles de la transaccion pueden formar parte del texto del SMS. El Payment-Provider transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el User, el titular y/o un ID especial (MSISDN User!). A continuacion, el servidor web consulta al Payment-Provider si 20 puede realizarse el pago (Payment OK?).
Etapa 6a:
Mediante clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago o si ha 25 finalizado con exito (Authorize / Payment?). En caso de un acuse de recibo negativo (p.ej. porque aun no se han realizado por completo las etapas 1 a 3 y 7 y siguientes), el servidor web (tsContenido) vuelve a emitir una nueva pagina 6, optimizada para el terminal estacionario. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion 30 autorizada puede finalizarse segun criterios no detalladamente indicados.
9) Autorizacion por PC-WAP-SMS combinada con autorizacion por PC-SMS Premium
La Figura 9 muestra una combinacion segun la invencion de la autorizacion por PC-WAP-SMS (vease la Figura 4) 35 con la autorizacion por PC - SMS Premium (vease la Figura 5).
Etapa 1:
En una pagina de internet del terminal estacionario hay un codigo de barras 2D. El servidor web que suministra la 40 pagina (tsContenido o el servidor web de un tercer proveedor) detecta mediante la deteccion del Useragent (o deteccion del equipo) que la pagina de internet debe suministrarse o emitirse para un terminal estacionario (p.ej. monitor de PC, notebook, portatil o sim.). En el codigo de barras esta codificada una direccion de internet. El terminal movil puede leer el codigo de barras mediante la camara con ayuda de un software de lectura de codigos de barras. El lector de codigos de barras detecta la direccion de internet y ofrece la opcion de llamar la direccion en el 45 navegador del terminal movil. Dado el caso, la llamada puede ser confirmada por el usuario.
En el marco de la identificacion se realizan dos procesos (vease la Figura 1):
- el proceso “tsPayment” determina si puede realizarse una transaccion de pago (etapa 1b);
50 - el proceso “tsContenido” determina en que forma ha de realizarse la representacion de la pagina de
internet (etapa 1a).
Las etapas 1a y 1b corresponden a las etapas 1a y 1b que se han descrito en relacion con la Figura 1 y la Figura 3.
55 Con ayuda del acuse de recibo del proveedor (OK! o NoOK!) se inicia el proceso de autorizacion (y dado el caso una transaccion de pago posterior) segun los procedimientos:
- 3) autorizacion por PC-WAP (vease la Figura 3) o
- 4) autorizacion por PC-WAP-SMS Premium (vease la Figura 4).
En caso de un acuse de recibo negativo (NoOK!) por parte del Payment-Provider, la pagina de internet se emite al 5 terminal movil con los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, enlace de SMS, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. y un enlace de continuar. El enlace de SMS o el enlace de continuar tambien pueden llamarse de otro modo.
Etapa 3:
10
Segun la instruccion de SMS, se genera un SMS correspondiente.
Etapa 3a:
15 La generacion del SMS puede realizarse mediante entrada manual.
Etapa 3b:
La generacion del SMS puede realizarse automaticamente mediante clic en el enlace de SMS. Aqui, el SMS se 20 genera mediante el navegador o mediante la aplicacion nativa de SMS en funcion del terminal movil usado, la version y las funciones del software del navegador existente.
Etapa 3c:
25 Mediante el envio del SMS se transmiten MSISDN, ID de transaccion, texto del SMS, caracteres del SMS, etc. al Payment-Provider (MSISDN User?).
Etapa 3d:
30 El Payment-Provider transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el User, el titular y/o un ID especial (MSISDN User!). A continuacion, el servidor web consulta al Payment-Provider si puede realizarse el pago (Payment OK?).
El Payment-Provider indica la realizacion de la transaccion de pago a su vez a los operadores de redes de telefonia 35 movil. La asignacion del MSISDN, del usuario o del titular al operador de red correspondiente, asi como la consulta para la realizacion de una transaccion de pago al operador de red corresponde al Payment-Provider. Respecto al posterior proceso entre el operador de red y el Payment-Provider se remite a la etapa 2a en relacion con la Figura 1.
Etapa 2a:
40
Mediante clic en el enlace de continuar, se consulta al servidor web (tsPayment) si se ha realizado el pago o si ha finalizado con exito (Authorize Payment?).
Etapa 4:
45
En caso de un acuse de recibo positivo (Payment OK!) por parte del Payment-Provider, el servidor web (tsContenido) suministra una pagina de internet al terminal movil con una confirmacion asi como enlaces relacionados (confirmacion Payment). Mediante los enlaces relacionados puede llamarse o cargarse el contenido pagado o puede iniciarse una nueva transaccion.
50
Etapa 1c:
Mediante clic en el enlace de continuar, se consulta al servidor web (tsPayment) si se ha realizado el pago o si ha finalizado con exito (Authorize / Payment?).
55
Etapa 5:
En caso de un acuse de recibo positivo (Authorize / Payment?), el servidor web (tsContenido) suministra una pagina de confirmacion al terminal estacionario (confirmacion Payment). Esta contiene enlaces relacionados. Mediante
estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse una nueva transaccion.
Las siguientes etapas son caracteristicas para la combinacion de los procedimientos de autorizacion por PC-WAP- SMS con la autorizacion por PC-SMS Premium.
5
Etapa 6:
En caso de un acuse de recibo negativo (porque p.ej. no se han realizado o no se han realizado por completo las etapas 1a, 1b, 2, 2a, 2b, 3), el servidor web (tsContenido) emite una pagina de internet nueva, optimizada para 10 terminales estacionarios. Ademas de otro codigo de barras nuevamente generado, la pagina de internet contiene los siguientes elementos: instruccion de SMS, texto de SMS, numero de SMS, introduccion del contenido, avisos, precios, condiciones generales de contratacion etc. y un enlace de continuar. En el codigo de barras esta codificado un SMS o una instruccion de SMS.
15 Etapa 3:
Segun la instruccion de SMS, se genera un SMS correspondiente.
Etapa 7a:
20
La generacion del SMS puede realizarse mediante entrada manual. La etapa 7a corresponde sustancialmente a la etapa 3a.
Etapa 7b:
25
La etapa 7b corresponde sustancialmente a la etapa 3b. La generacion del SMS puede realizarse automaticamente mediante escaneado del codigo de barras. El terminal movil puede leer el codigo de barras mediante la camara con ayuda de un software de lectura de codigos de barras. El lector de codigos de barras detecta los caracteres del SMS o la instruccion de SMS y ofrece la opcion de generar el SMS. Dado el caso, el usuario confirma la generacion. Aqui 30 el SMS se genera mediante el navegador, mediante una aplicacion nativa de SMS o mediante el software del lector de codigos de barras en funcion del terminal movil usado, la version y las funciones del software del navegador existente.
Etapa 3c:
35
Mediante el envio del SMS se transmiten MSISDN, ID de transaccion, texto del SMS, caracteres del SMS, etc. al Payment-Provider (MSISDN User?). El Payment-Provider transmite al servidor web (tsPayment) a traves de una interfaz el MSISDN, el User, el titular, un iD especial (MSISDN User!) y/o detalles de la transaccion (p.ej. texto de SMS). A continuacion, el servidor web consulta al Payment-Provider si puede realizarse el pago (Payment OK?).
40
Etapa 6a:
Mediante clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize / Payment?). En caso de un acuse de recibo negativo (p.ej. porque no se han realizado o no se han realizado por 45 completo las etapas 1 a 7), el servidor web (tsContenido) vuelve a emitir una nueva pagina 6, optimizada para terminales estacionarios. Aqui no se especificara detalladamente como finaliza o como se realiza una transaccion descrita en este contexto. Por ejemplo, puede iniciarse y finalizarse directamente despues de la autorizacion un proceso de pago o puede transmitirse una confirmacion, despues de la cual la transaccion autorizada puede finalizarse segun criterios no detalladamente indicados.
50
En un aspecto de la invencion se pone a disposicion un procedimiento para la realizacion de una autorizacion de una transaccion por internet mediante un dispositivo de autorizacion A, pudiendo acoplarse un primer terminal E1 y un segundo terminal E2 mediante una red de comunicaciones con el dispositivo de autorizacion A, pudiendo realizarse la transaccion en uno de los dos terminales E1, E2, pudiendo iniciarse la autorizacion en uno de los dos terminales 55 E1, E2, y cuando un primer proceso de autorizacion AV1, que comprende las etapas
- la recepcion de datos de transaccion procedentes de uno de los dos terminales E1, E2 por parte del
dispositivo de autorizacion A, recibiendose los datos de transaccion a traves de un primer canal de transmision K1 y;
- la determinacion de un primer identificador ID1 que identifica un terminal mediante el dispositivo de autorizacion A;
conduce a una denegacion de la realizacion de la transaccion por una determinacion fallida del primer identificador 5 ID1;
el dispositivo de autorizacion A genera por la denegacion datos para la transmision a uno de los dos terminales E1, E2, conteniendo los datos los datos de transaccion y una instruccion para la inicializacion de un segundo proceso de autorizacion AV2 por medio de uno de los dos terminales E1, E2 a traves de un segundo canal de transmision K2, siendo recibidos los datos de transaccion a traves del segundo canal de transmision K2 por parte del dispositivo de 10 autorizacion A y
comprendiendo la generacion de los datos por parte del dispositivo de autorizacion A una determinacion de propiedades del hardware del primero o del segundo terminal y una adaptacion de los datos a las propiedades del hardware determinadas.
15 El segundo proceso de autorizacion AV2 puede ser finalizado por el dispositivo de autorizacion A y puede comprender una etapa para la determinacion de un segundo identificador ID2, estando asignado el segundo identificador ID2 al terminal E2, que inicia el segundo proceso de autorizacion AV2, e identificando el segundo identificador ID2 el terminal E2 que inicia el segundo proceso de autorizacion AV2.
20 El segundo proceso de autorizacion AV2 puede comprender una etapa para la determinacion de una autorizacion de transaccion.
La autorizacion de transaccion puede depender del segundo identificador ID2.
25 La determinacion del segundo identificador ID2 puede comprender una consulta a un dispositivo servidor y una recepcion del segundo ID2 por parte del dispositivo servidor.
El segundo identificador ID2 puede ser recibido a traves del segundo canal de transmision por parte del dispositivo de autorizacion.
30
El segundo identificador ID2 puede ser el Mobile Subscriber Integrated Services Digital Network Number MSISDN.
La instruccion para la inicializacion del segundo proceso de autorizacion AV2 puede comprender al menos uno de los siguientes datos:
35
- datos para la generacion y el envio manuales de un mensaje corto;
- datos para la generacion y el envio automaticos de un mensaje corto de un contenido predeterminado a un numero de telefono predeterminado; y/o
- un codigo grafico, en el que estan codificados los datos para una generacion y un envio automaticos
40 de un mensaje corto de un contenido predeterminado a un numero de telefono predeterminado.
La determinacion de las propiedades del hardware puede comprender una determinacion de las propiedades del hardware del dispositivo de visualizacion del primero o del segundo terminal.
45 El segundo terminal puede ser un terminal movil, preferentemente un terminal movil con funcionalidad SMS y funcionalidad de telefonia.
El primer canal de transmision K1 puede ser diferente al segundo canal de transmision K2.
50 El primer canal de transmision K1 puede ser un canal de datos WAP o un canal de datos IP, siendo el segundo canal de transmision K2 un canal de mensajes cortos de telefonia movil.
La transaccion puede realizarse en el primer terminal E1, iniciandose el proceso de autorizacion en el segundo terminal E2.
55
En otro aspecto de la invencion se pone a disposicion un procedimiento para la realizacion de una autorizacion de una transaccion por internet mediante un dispositivo de autorizacion A, pudiendo realizarse la transaccion en un primer terminal E1, pudiendo iniciarse el proceso de autorizacion en un segundo terminal E2 y comprendiendo la autorizacion mediante el dispositivo de autorizacion A las etapas:
- la recepcion de datos de transaccion procedentes del segundo terminal E2 por parte del dispositivo de autorizacion A;
- la determinacion de un identificador que identifica el segundo terminal E2 mediante el dispositivo de
5 autorizacion A; la determinacion de una autorizacion de transaccion, que puede ser asignada al
identificador del segundo terminal E2, dependiendo la autorizacion de transaccion de los datos de transaccion;
- la habilitacion de la realizacion de la transaccion por internet en funcion de la autorizacion de transaccion; y
10 - la puesta a disposicion de datos que son indicadores para la habilitacion de la realizacion de la
transaccion por internet, para la salida en el primer terminal E1 o en el segundo terminal E2, permitiendo los datos la realizacion de la transaccion por internet.
La autorizacion puede comprender una etapa para la puesta a disposicion de los datos de transaccion para la salida 15 en el primer terminal E1 o para la salida en el segundo terminal E2.
La determinacion de la autorizacion de transaccion y/o la habilitacion de la realizacion de la transaccion puede depender adicionalmente del identificador del segundo terminal E2, realizandose la habilitacion de la realizacion de la transaccion cuando la determinacion del identificador del segundo terminal E2 finaliza con exito.
20
La determinacion del identificador del segundo terminal E2 puede comprender una consulta a un dispositivo servidor y una recepcion del identificador que identifica el segundo terminal E2, comprendiendo el identificador del segundo terminal E2 al menos uno de los siguientes elementos: Mobile Subscriber Integrated Services Digital Network Number (MSISDN), titular e ID del titular.
25
La puesta a disposicion de los datos para la salida en el primer terminal E1 o en el segundo terminal E2 puede comprender una determinacion de las propiedades del dispositivo de visualizacion del primero o del segundo terminal y una adaptacion de los datos a las propiedades del dispositivo de visualizacion.
30 En otro aspecto, la invencion comprende un dispositivo de autorizacion A para la realizacion de una autorizacion de una transaccion por internet, pudiendo acoplarse un primer terminal E1 y un segundo terminal E2 mediante una red de comunicaciones con el dispositivo de autorizacion A, pudiendo realizarse la transaccion en uno de los dos terminales E1, E2, pudiendo iniciarse la autorizacion en uno de los dos terminales E1, E2, y estando configurado el dispositivo de autorizacion para realizar un procedimiento que comprende al menos las siguientes etapas:
35
- la realizacion de un primer proceso de autorizacion AV1, que comprende:
- la recepcion de datos de transaccion de uno de los dos terminales E1, E2, recibiendose los datos de transaccion a traves de un primer canal de transmision K1; y
- la determinacion de un primer identificador ID1 que identifica un terminal;
40 y
- cuando el primer proceso de autorizacion AV1 conduce a una denegacion de la realizacion de la transaccion por una determinacion fallida del primer identificador ID1;
- la generacion de datos para la transmision a uno de los dos terminales E1, E2, conteniendo los datos los datos de transaccion y una instruccion para la inicializacion de un segundo proceso de
45 autorizacion AV2 por uno de los dos terminales a traves de un segundo canal de transmision K2,
siendo recibidos los datos de transaccion a traves del segundo canal de transmision K2 por parte del dispositivo de autorizacion A y comprendiendo la generacion de datos por el dispositivo de autorizacion A una determinacion de propiedades del hardware del primero o del segundo terminal y una adaptacion de los datos a las propiedades del hardware determinadas.
50
El segundo proceso de autorizacion AV2 puede comprender una etapa para la determinacion de un segundo identificador ID2, estando asignado el segundo identificador ID2 al terminal E2 que inicia el segundo proceso de autorizacion AV2 e identificado el segundo identificador ID2 el terminal E2 que inicia el segundo proceso de autorizacion AV2.
55
El segundo proceso de autorizacion AV2 puede comprender una etapa para la determinacion de una autorizacion de transaccion.
La autorizacion de transaccion puede depender del segundo identificador ID2.
La determinacion del segundo identificador ID2 puede comprender una consulta a un dispositivo servidor y una recepcion del segundo ID2 por parte del dispositivo servidor.
5 El segundo identificador ID2 puede ser recibido a traves del segundo canal de transmision por parte del dispositivo de autorizacion A.
El segundo identificador ID2 puede ser el Mobile Subscriber Integrated Services Digital Network Number MSISDN.
10 La instruccion para la inicializacion del segundo proceso de autorizacion AV2 puede comprender al menos uno de los siguientes datos:
- datos para la generacion y el envio manuales de un mensaje corto;
- datos para la generacion y el envio automaticos de un mensaje corto de un contenido predeterminado
15 a un numero de telefono predeterminado; o
- un codigo grafico, en el que estan codificados los datos para una generacion y un envio automaticos de un mensaje corto de un contenido predeterminado a un numero de telefono predeterminado.
La determinacion de las propiedades del hardware puede comprender una determinacion de las propiedades del 20 hardware del dispositivo de visualizacion del primero o del segundo terminal. El segundo terminal puede ser un terminal movil, preferentemente un terminal movil con funcionalidad SMS y funcionalidad de telefonia.
El primer canal de transmision K1 puede ser diferente al segundo canal de transmision K2.
25 El primer canal de transmision K1 puede ser un canal de datos WAP o un canal de datos IP, siendo el segundo canal de transmision K2 un canal de mensajes cortos de telefonia movil.

Claims (2)

  1. REIVINDICACIONES
    1. Procedimiento para la realizacion de una autorizacion de una transaccion por internet mediante un dispositivo de autorizacion (A), pudiendo realizarse la transaccion en un primer terminal (E1), pudiendo iniciarse el
    5 proceso de autorizacion en un segundo terminal (E2), que es un terminal movil, pudiendo acoplarse el primer terminal (E1) y el segundo terminal (E2) mediante una red de comunicaciones con el dispositivo de autorizacion (A) y comprendiendo la autorizacion mediante el dispositivo de autorizacion (A) las siguientes etapas:
    - la recepcion de datos de transaccion procedentes del segundo terminal (E2) por parte del dispositivo
    10 de autorizacion (A);
    - la determinacion de un identificador que identifica el segundo terminal (E2) por parte del dispositivo de autorizacion (A); estando caracterizado el procedimiento por:
    - la determinacion de una autorizacion de transaccion, que puede ser asignada al identificador del segundo terminal (E2), dependiendo la autorizacion de transaccion de los datos de transaccion;
    15 - la habilitacion de la realizacion de la transaccion por internet en funcion de la autorizacion de
    transaccion; y
    - la puesta a disposicion de datos que son indicadores para la habilitacion de la realizacion de la transaccion por internet, para la salida en el primer terminal (E1) o en el segundo terminal (E2), permitiendo los datos la realizacion de la transaccion por internet.
    20
  2. 2. Procedimiento segun la reivindicacion 1, comprendiendo la autorizacion una etapa para la puesta a disposicion de datos de transaccion para la salida en el primer terminal (E1) o para la salida en el segundo terminal (E2).
    25 3. Dispositivo segun las reivindicaciones 1 o 2, dependiendo la determinacion de la autorizacion de
    transaccion y/o la habilitacion de la realizacion de la transaccion adicionalmente del identificador del segundo terminal (E2) y realizandose la habilitacion de la realizacion de la transaccion cuando la determinacion del identificador del segundo terminal (E2) haya finalizado con exito.
    30 4. Dispositivo segun una de las reivindicaciones 1 a 3, comprendiendo la determinacion del identificador
    del segundo terminal (E2) una consulta a un dispositivo servidor y una recepcion del identificador que identifica el segundo terminal (E2), comprendiendo el identificador del segundo terminal (E2) al menos uno de los siguientes elementos: Mobile Subscriber Integrated Services Digital Network Number (MSISDN), titular e ID del titular.
    35 5. Dispositivo segun una de las reivindicaciones 1 a 4, comprendiendo la puesta a disposicion de los
    datos para la salida en el primer terminal (E1) o en el segundo terminal (E2) una determinacion de las propiedades del dispositivo de visualizacion del primero o del segundo terminal y una adaptacion de los datos a las propiedades del dispositivo de visualizacion.
ES13170677.2T 2008-12-01 2009-11-16 Procedimiento para la autorización de una transacción Active ES2569732T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059723 2008-12-01
DE102008059723 2008-12-01

Publications (1)

Publication Number Publication Date
ES2569732T3 true ES2569732T3 (es) 2016-05-12

Family

ID=42233663

Family Applications (2)

Application Number Title Priority Date Filing Date
ES09756471T Active ES2434743T3 (es) 2008-12-01 2009-11-16 Procedimiento para la autorización de una transacción por varios canales
ES13170677.2T Active ES2569732T3 (es) 2008-12-01 2009-11-16 Procedimiento para la autorización de una transacción

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES09756471T Active ES2434743T3 (es) 2008-12-01 2009-11-16 Procedimiento para la autorización de una transacción por varios canales

Country Status (4)

Country Link
EP (2) EP2371105B1 (es)
DE (1) DE102009056116B4 (es)
ES (2) ES2434743T3 (es)
WO (1) WO2010063563A2 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011120926A1 (de) * 2011-12-14 2013-06-20 Alexander Luchinskiy Verfahren und Einrichtung zur Präsentierung und Erhaltung der Information
DE102012004964A1 (de) * 2012-03-14 2013-09-19 Paade Gmbh Verfahren mit einer Auswerteeinheit und mit einer Bilddarstellung
DE102014206949A1 (de) * 2014-04-10 2015-10-29 Vodafone Gmbh Transaktionsverfahren

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2236037C2 (ru) * 2000-02-05 2004-09-10 Дайболд, Инкорпорейтед Система и способ выдачи цифровой информации через транзакционный автомат
US7337229B2 (en) * 2001-11-08 2008-02-26 Telefonktiebolaget Lm Ericsson (Publ) Method and apparatus for authorizing internet transactions using the public land mobile network (PLMN)
US6726092B2 (en) * 2001-12-28 2004-04-27 Interdigital Technology Corporation Portable device service payments by multiple means
DE10243292A1 (de) * 2002-09-18 2004-04-01 Contentlogic Interactive Media Gmbh Server zur Authorisierung von Mediendienstnutzungen per Mobiltelefon
WO2005008608A1 (de) * 2003-07-11 2005-01-27 Rene Lehmann Bezahlsystem, terminal für ein bezahlsystem und verfahren zum durchführen eines elektronischen bezahlvorgangs
WO2007044882A2 (en) * 2005-10-11 2007-04-19 Philip Yuen System and method for authorization of transactions
US8352376B2 (en) 2005-10-11 2013-01-08 Amazon Technologies, Inc. System and method for authorization of transactions
US20070136573A1 (en) * 2005-12-05 2007-06-14 Joseph Steinberg System and method of using two or more multi-factor authentication mechanisms to authenticate online parties
EP1865656A1 (en) * 2006-06-08 2007-12-12 BRITISH TELECOMMUNICATIONS public limited company Provision of secure communications connection using third party authentication
DE102007005427A1 (de) * 2007-01-30 2008-07-31 Hischam Telib Verfahren und Vorrichtung zur elektronischen Zahlung

Also Published As

Publication number Publication date
EP2637382B1 (de) 2016-02-24
WO2010063563A2 (de) 2010-06-10
EP2371105A2 (de) 2011-10-05
DE102009056116A1 (de) 2010-09-16
EP2371105B1 (de) 2013-08-14
EP2637382A2 (de) 2013-09-11
DE102009056116B4 (de) 2016-08-18
WO2010063563A3 (de) 2010-12-09
ES2434743T3 (es) 2013-12-17
EP2637382A3 (de) 2014-04-02

Similar Documents

Publication Publication Date Title
US10327141B2 (en) Methods and systems for validating mobile devices of customers via third parties
US8016187B2 (en) Mobile payment system using barcode capture
US9106665B2 (en) Automatic device authentication and account identification without user input when application is started on mobile station
US8499153B2 (en) System and method of authenticating a user to a service provider
US20050227669A1 (en) Security key management system and method in a mobile communication network
US20110217994A1 (en) Systems and Methods to Automate Transactions via Mobile Devices
DK1766847T3 (en) PROCEDURE FOR GENERATING AND VERIFYING AN ELECTRONIC SIGNATURE
US20080020738A1 (en) Mobile device service authorization system and method
CN106875177A (zh) 订单处理方法、装置及支付服务器
JP2006268641A (ja) 認証方法及び認証システム
KR20080101147A (ko) 이동통신 시스템에서 네트워크 파라미터 정보를 저장하기위한 장치 및 방법
ES2569732T3 (es) Procedimiento para la autorización de una transacción
US20100017884A1 (en) Method for allowing full version content embedded in mobile device and system thereof
DK2257096T3 (en) Procedure, system, server and computer program for services
KR20020045082A (ko) 이동 통신 시스템을 이용한 전자 상거래 서비스 인증 및제공 방법
KR101291492B1 (ko) 가입자식별모듈을 구비한 이동통신 단말의 개통 방법
CN101042764A (zh) 电子业务确认***及其实现方法
US20050108105A1 (en) Contract server
KR20050019454A (ko) 휴대폰 번호를 이용한 선물 배송 방법 및 이 방법을구현하기 위한 시스템
KR100721848B1 (ko) 발신번호 표시 서비스를 이용한 사용자 인증 방법
JP3902602B2 (ja) サーバ装置およびこれを用いる非同期電子決済のサービス方法
KR20150050298A (ko) 지문을 이용한 결제 방법, 사용자 단말기 및 결제 중계 서버
US20100255811A1 (en) Transmission of messages
KR101009955B1 (ko) 이동통신 단말을 이용한 사용자 인증 방법 및 이를 구현하는 시스템
KR20200087733A (ko) 엠엠에스를 이용한 이동통신 단말기에서의 팩스 시스템