ES2434743T3 - Procedimiento para la autorización de una transacción por varios canales - Google Patents

Procedimiento para la autorización de una transacción por varios canales Download PDF

Info

Publication number
ES2434743T3
ES2434743T3 ES09756471T ES09756471T ES2434743T3 ES 2434743 T3 ES2434743 T3 ES 2434743T3 ES 09756471 T ES09756471 T ES 09756471T ES 09756471 T ES09756471 T ES 09756471T ES 2434743 T3 ES2434743 T3 ES 2434743T3
Authority
ES
Spain
Prior art keywords
authorization
transaction
terminal
data
identification
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
ES09756471T
Other languages
English (en)
Inventor
Stefan Schwerdtfeger
Christian Doerfel
Michael Liebwein
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 ES2434743T3 publication Critical patent/ES2434743T3/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 realizar una autorización de una transacción por Internet por un dispositivo deautorización (A), estando acoplado un primer terminal (E1) y un segundo terminal (E2) con el dispositivo deautorización (A) por una red de comunicación, pudiendo realizarse la transacción en uno de los 5 dos terminales (E1,E2), pudiendo iniciarse la autorización en uno de los dos terminales (E1, E2), caracterizado porque, cuando unprimer proceso de autorización (AV1), que comprende las etapas de - recepción de los datos de transacción por el dispositivo de autorización (A) de uno de los dos terminales(E1, E2), recibiéndose los datos de transacción por un primer canal de transmisión (K1); y - detección por el dispositivo de autorización (A) de una primera identificación (ID1) que identifica uno de losterminales; conduce a un rechazo de la realización de la transacción debido a una detección fallida de la primeraidentificación (ID1), el dispositivo de autorización (A) genera datos debido al rechazo para la transmisión a uno de los dos terminales (E1, E2), conteniendo los datos los datos de transacción y una instrucción para el inicio de un segundo proceso de autorización (AV2) por uno de los dos terminales (E1, E2) por un segundocanal de transmisión (K2), y recibiéndose los datos de transacción por el segundo canal de transmisión (K2)por el dispositivo de autorización (A) y comprendiendo la generación de los datos por el dispositivo deautorización (A) una detección de las propiedades del hardware del primer o del segundo terminal y unaadaptación de los datos a las propiedades del hardware detectadas.

Description

Procedimiento para la autorización de una transacción por varios canales.
5 La invención se refiere a un procedimiento y un dispositivo para la autorización de una transacción entre un proveedor de servicios y un usuario de servicios.
La autorización sirve para iniciar una o varias transacciones, que requieren una comprobación del derecho a realizar las transacciones. Por el estado de la técnica se conocen procedimientos y dispositivos para la autorización. Por 10 ejemplo, se conocen procedimientos con los que puede autorizarse la carga de contenidos digitales en una página de Internet. Para ello se pone a disposición, por ejemplo en una página 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 conduce a que se carga otra página de Internet, en la que se visualizan distintos datos de transacción, informaciones para la realización de la transacción y otro enlace para cargar el contenido digital. Los
15 datos de la transacción son aquí p. ej. un URL de la transacción.
El URL de la transacción puede introducirse a continuación por ejemplo en un teléfono móvil apto para WAP para iniciar la autorización. El proveedor de servicios que pone a disposición los contenidos digitales determina con ayuda del URL de la transacción y de los datos de protocolo del canal de datos WAP mediante el cual se llama el URL de 20 la transacción una identificación (p. ej. MSISDN) que puede asignarse al teléfono móvil para autorizar la transacción
(p. ej. la carga de los contenidos) y para facturar mediante este identificación por ejemplo la carga de los contenidos digitales, realizándose la facturación propiamente dicha en la mayoría de los casos mediante el operador de red del abonado de telefonía móvil (usuario).
25 En el teléfono móvil, el usuario recibe a continuación una página de Internet móvil con la indicación de que el contenido digital está habilitado (por lo que se han realizado con éxito la autorización y el proceso de pago) pudiendo realizarse ahora la carga del contenido digital en el navegador de Internet del ordenador o en el navegador WAP del terminal móvil (p. ej. teléfono móvil). A continuación, el usuario puede hacer clic en otro enlace para ver el contenido digital.
30 El inconveniente del procedimiento es, por un lado, que son necesarias entradas manuales del usuario en el teléfono móvil (entrada del URL de la transacción), lo cual es susceptible de cometerse errores (p. ej. entrada incorrecta del URL de la transacción), por lo que puede conducir a una facturación incorrecta o puede conducir a que no se habiliten los contenidos solicitados. También pueden producirse errores que impiden la realización completa del
35 procedimiento, p. ej. entrada incorrecta al introducir el URL, al introducir el MSISDN/la identificación/ID propios, etc. Por otro lado, no puede garantizarse que puedan realizarse una autorización y, por lo tanto, una transacción. Por ejemplo, no puede realizarse una autorización cuando el proveedor de los contenidos digitales no puede determinar la identificación del teléfono móvil por deficiencias técnicas del teléfono móvil, p. ej. cuando el teléfono móvil no puede transmitir su identificación. Esto es el caso, por ejemplo, cuando el canal de transmisión usado, p. ej. un canal
40 de datos WAP, no soporta la transmisión de la identificación del teléfono móvil. Cuando en lugar del canal de datos WAP se usa un canal de datos IP, tampoco puede garantizarse una detección de la identificación del terminal móvil.
En muchos casos, sin la identificación del teléfono móvil no puede realizarse ni una autorización ni una transacción de pago. De este modo, el usuario no consigue tener acceso a los contenidos digitales debido a restricciones
45 técnicas.
Por el documento US 2007/0107044 A1 se conoce un procedimiento para realizar una autorización de una transacción por Internet mediante un dispositivo de autorización, pudiendo acoplarse un primer terminal y un segundo terminal mediante una red de comunicación con el dispositivo de autorización, pudiendo realizarse la
50 transacción en uno de los dos terminales y pudiendo iniciarse la autorización en uno de los dos terminales. Un proceso de autorización conduce a un rechazo de la realización de la transacción cuando falla una detección de una identificación del terminal. Los datos de la transacción para la transacción se reciben mediante un segundo canal de transmisión desde el dispositivo de autorización.
55 El objetivo de la invención es, por lo tanto, poner a disposición un procedimiento y un dispositivo para la autorización de una transacción que, por un lado, simplifiquen una autorización para la realización de la transacción y que, por otro lado, permitan que pueda realizarse también en caso de que las condiciones técnicas no permitan una autorización convencional.
Por consiguiente, en un primer aspecto de la invención se pone a disposición un procedimiento para realizar una autorización de una transacción por Internet mediante un dispositivo de autorización, pudiendo acoplarse un primer terminal y un segundo terminal mediante una red de comunicación con el dispositivo de autorización, pudiendo realizarse la transacción en uno de los dos terminales, pudiendo iniciarse la autorización en uno de los dos
5 terminales, y cuando un primer proceso de autorización, que comprende las etapas de
-
recepción de datos de la transacción por el dispositivo de autorización de uno de los dos terminales, recibiéndose los datos de la transacción mediante un primer canal de transmisión; y
-
detección por el dispositivo de autorización de una identificación que identifica uno de los terminales;
10 conduce a un rechazo de la realización de la transacción por una detección fallida de la identificación, generando el dispositivo de autorización debido al rechazo datos para la transmisión a uno de los dos terminales, conteniendo los datos los datos de la transacción y una instrucción para el inicio de un segundo proceso de autorización por uno de los dos terminales por un segundo canal de transmisión, siendo recibidos los datos de la transacción por el segundo canal de transmisión por el dispositivo de autorización y comprendiendo la generación de los datos por el dispositivo
15 de autorización una detección de las propiedades del hardware del primer o del segundo terminal y una adaptación de los datos a las propiedades del hardware.
La ventaja en comparación con el procedimiento conocido por el estado de la técnica está en que una autorización para una transacción por Internet puede realizarse incluso cuando el terminal o el canal de transmisión puesto a
20 disposición en primer lugar no permiten una autorización debido a restricciones técnicas. Cuando el dispositivo de autorización determina que no puede detectarse la identificación del terminal en el que se ha iniciado el primer proceso de autorización, solicita automáticamente la autorización mediante un segundo canal de transmisión de un terminal. De este modo aumenta claramente la probabilidad de poder terminar con éxito la autorización.
25 En caso de una elección adecuada del segundo canal de transmisión, por ejemplo un canal de transmisión, que transmite siempre la identificación de un terminal, incluso puede garantizarse con una probabilidad muy elevada que la autorización pueda terminarse con éxito.
El procedimiento también puede comprender la realización de una autorización de una transacción por Internet por
30 un dispositivo de autorización, pudiendo realizarse la transacción en un primer terminal, pudiendo iniciarse la autorización en un segundo terminal, o pudiendo realizarse e iniciarse la transacción y la autorización en el primer terminal o en el segundo terminal, pudiendo acoplarse el primer terminal y el segundo terminal con el dispositivo de autorización por una red de comunicación y cuando el proceso de autorización, que comprende las etapas de
35 - recepción de datos de la transacción por el dispositivo de autorización del segundo terminal, recibiéndose los datos de la transacción por un primer canal de transmisión; y
- detección por el dispositivo de autorización de una identificación que identifica el segundo terminal; conduce a un rechazo de la realización de la transacción por una detección fallida de la identificación, generando el dispositivo de autorización debido al rechazo datos para la transmisión al primer terminal o al segundo terminal,
40 conteniendo los datos los datos de la transacción y una instrucción para el inicio de un segundo proceso de autorización por el segundo terminal por un segundo canal de transmisión, siendo recibidos los datos de la transacción por el segundo canal de transmisión por el dispositivo de autorización y comprendiendo la generación de los datos por el dispositivo de autorización una detección de las propiedades del hardware del primer o del segundo terminal y una adaptación de los datos a las propiedades del hardware.
45 Cuando falla el primer proceso de autorización, porque no puede detectarse ninguna identificación por el primer canal de transmisión para el segundo terminal, por ejemplo porque no se ha transmitido la identificación, se solicita un segundo proceso de autorización del segundo terminal por un segundo canal de transmisión. De este modo puede aumentarse claramente la probabilidad de poder detectar una identificación para el segundo terminal.
50 Otra ventaja está en que un proveedor de servicios, que pone a disposición por ejemplo un acceso a documentos electrónicos (sujetos a costes) sólo debe poner a disposición una forma de autorización. Si no es posible la primera autorización por la forma de autorización puesta a disposición (p. ej. autorización por IP por un teléfono móvil), el dispositivo de autorización solicita automáticamente una segunda autorización mediante un segundo procedimiento
55 de autorización, que puede realizarse mediante el mismo terminal que la primera autorización fallida.
Gracias a que pueden detectarse las propiedades del hardware del terminal, la solicitud para una segunda autorización puede adaptarse según las propiedades del hardware del terminal.
El segundo proceso de autorización puede ser realizado por el dispositivo de autorización y puede comprender una etapa para la detección de una segunda identificación, que está asignada a aquel terminal que inicia el segundo proceso de autorización y que identifica aquel terminal.
5 El segundo proceso de autorización puede comprender preferiblemente una etapa para la detección de un derecho a la transacción, pudiendo depender el derecho a la transacción de la identificación del segundo terminal.
La detección de la segunda identificación puede comprender una consulta a un dispositivo de servidor y una recepción de la segunda identificación del dispositivo de servidor. El dispositivo de servidor también puede formar
10 parte del dispositivo de autorización. Esto es especialmente ventajoso cuando el terminal comunica por el segundo canal de transmisión con un dispositivo de servidor. De este modo, el dispositivo de autorización puede detectar la segunda identificación, también sin acceso al segundo canal de transmisión.
La segunda identificación puede recibirse por el dispositivo de autorización por el segundo canal de transmisión.
15 El segundo canal de transmisión puede ser un canal de mensajes cortos de telefonía móvil, es decir un canal de datos de SMS y de señales. De este modo queda garantizado que pueda detectarse siempre la segunda identificación, porque el canal de mensajes cortos de telefonía móvil prevé la transmisión de una identificación.
20 La identificación del segundo terminal comprende al menos uno de número de red digital de servicios integrados de estación móvil (MSISDN, Mobile Subscriber Integrated Services Digital Network Number), propietario e ID de propietario.
En una forma de realización preferible, la instrucción para el inicio del segundo proceso de autorización puede 25 comprender:
-
datos para la generación y el envío manuales de un mensaje corto (SMS); o
-
datos para la generación y el envío automáticos de un mensaje corto de un contenido predeterminado a un número de teléfono predeterminado; o
30 - código gráfico en el que están codificados los datos para una generación y envío automáticos de un mensaje corto de un contenido predeterminado a un número de teléfono predeterminado.
La detección de las propiedades del hardware comprende preferiblemente una detección de las propiedades del hardware del dispositivo de visualización del primer o del segundo terminal. Gracias a la detección de las
35 propiedades del hardware del dispositivo de visualización del terminal, la solicitud para una segunda autorización puede adaptarse correspondientemente al dispositivo de visualización. De este modo es posible que la solicitud esté disponible para cualquier terminal en función del terminal.
En un segundo aspecto de la invención se pone a disposición un procedimiento para la realización de una
40 autorización de una transacción por Internet mediante un dispositivo de autorización, pudiendo realizarse la transacción en un primer terminal, pudiendo iniciarse el proceso de autorización en un segundo terminal y comprendiendo la autorización por el dispositivo de autorización las etapas de:
-
recepción de datos de transacción por un dispositivo de autorización del segundo terminal;
45 -detección por el dispositivo de autorización de una identificación que identifica el segundo terminal; -detección de una autorización de transacción que puede asignarse a la identificación del segundo terminal, dependiendo la autorización de la transacción de los datos de la transacción;
-
habilitación de la realización de la transacción por Internet en función de la autorización de la transacción; y
-
puesta a disposición de datos que indican la habilitación de la realización de la transacción por Internet para la
50 salida en el primer terminal o en el segundo terminal, permitiendo los datos la realización de la transacción por Internet.
Además, mediante la invención se pone a disposición un dispositivo de autorización para la realización de una autorización de una transacción por Internet que presenta:
-
medios para la recepción de datos de la transacción de un primer terminal, especificando los datos de la transacción la transacción por Internet;
-
medios para la detección de una identificación que identifican el primer terminal, pudiendo acoplarse los medios para la detección de la identificación mediante una interfaz con un dispositivo de servidor y estando configurada la
interfaz para transmitir una solicitud al dispositivo de servidor y para la recepción de la identificación del dispositivo de servidor;
-
medios para la detección de una autorización de transacción que puede asignarse al primer terminal; y
-
medios para la puesta a disposición de datos que indican una habilitación o un rechazo de la realización de la 5 transacción para la transmisión al primer terminal o a un segundo terminal.
Otros detalles y características de la invención resultan de las reivindicaciones, así como de la descripción expuesta a continuación en relación con el dibujo. Muestran:
10 la fig. 1 una primera forma de realización del procedimiento según la invención (autorización por WAP); la fig. 2 otra forma de realización del procedimiento según la invención (autorización por SMS); la fig. 3 otra forma de realización del procedimiento según la invención (autorización por WAP-PC); la fig. 4 otra forma de realización del procedimiento según la invención (autorización por PC-WAP-SMS); la fig. 5 otra forma de realización del procedimiento según la invención (autorización por PC-SMS Premium);
15 la fig. 6 una parte de procedimiento del procedimiento según la invención para el uso con las formas de realización según la fig. 3 y la fig. 4; la fig. 7 una parte de procedimiento del procedimiento según la invención para el uso con la forma de realización según la fig. 5; la fig. 8 otra forma de realización del procedimiento según la invención, estando combinadas las formas de
20 realización según la fig. 3 y la fig. 5; y la fig. 9 otra forma de realización del procedimiento según la invención, estando combinadas las formas de realización según la fig. 4 y la fig. 5.
A continuación, se describirá el procedimiento según la invención del proceso de autorización, partiéndose de que 25 tras el proceso de autorización tiene lugar una transacción de pago. En lugar de la transacción de pago también pueden seguir otras transacciones.
Con "autorización" se designa la asignación y comprobación de derechos de acceso a datos y servicios para usuarios. La autorización puede realizarse tras una autentificación realizada con éxito (comprobación/verificación de 30 una identidad declarada, p. ej. de una persona). Una autentificación realizada con éxito permite p. ej. el acceso a llamados recursos (p. ej. a datos) en una red de ordenadores, como por ejemplo el Internet.
1) Autorización por WAP
35 La fig. 1 muestra un proceso de autorización según la invención (autorización por WAP) con posterior transacción de pago mediante el llamado pago WAP/IP o como puede realizarse una detección de usuario o una detección de aparato.
El punto de partida es un código gráfico 1, que está aplicado en un producto impreso o que se visualiza por ejemplo
40 en una pantalla. Como código gráfico puede usarse por ejemplo un código de barras (ortocódigo), un código 2D, como p. ej. un código matrix (código QR, Datamatrix, etc.) o un código de color, como p. ej. HCCP (código de barras de color de alta capacidad, High Capacity Color Barcode). En los ejemplos de realización descritos a continuación se usa siempre un código de barras. No obstante, también pueden preverse respectivamente los otros códigos gráficos indicados.
45 No obstante, para el inicio de una transacción también puede estar prevista la tecnología de campo cercano, como
p. ej. RFID. El producto impreso puede estar provisto de una etiqueta RFID, que almacena los datos necesarios para la transacción. Estos datos pueden leerse p. ej. con un terminal móvil.
50 En el código de barras o la etiqueta RFID puede codificarse o almacenarse por ejemplo un URL. La página de Internet vinculada a este URL puede poner a disposición información adicional (p. ej. sujeta a costes) acerca del producto impreso.
El proceso de autorización para tener acceso a la página de Internet codificada en el URL se realiza mediante el
55 terminal móvil. En este ejemplo de realización y en los siguientes, el terminal móvil puede ser un teléfono móvil, un PDA con funcionalidad de telefonía móvil (smartphone), un ordenador portátil con funcionalidad de telefonía móvil o sim. La funcionalidad de teléfono móvil puede estar basada p. ej. en las técnicas de terminal móvil GSM (sistema global para comunicaciones móviles, Global System for mobile Communication) o UMTS (sistema universal de comunicaciones móviles, Universal Mobile Telecommunications System). Un terminal estacionario puede ser p. ej.
un ordenador convencional. No obstante, un terminal estacionario también puede ser un PDA o un ordenador portátil, que sean adecuados por ejemplo para cargar contenidos digitales, p. ej. por Internet.
El proceso de autorización comprende una o barias etapas en las que se intenta en primer lugar identificar el aparato
5 que pretende obtener acceso a los datos. El aparato puede ser identificable por ejemplo con ayuda del MSISDN o una dirección IP. En otra etapa (en el marco de la autorización) se comprueba a continuación si se puede conceder un derecho al acceso al aparato identificado. Si puede identificarse el aparato y puede asignarse un derecho al aparato, el proceso de autorización ha terminado con éxito
10 En cuanto esté terminado el proceso de autorización a continuación del cual puede tener lugar una transacción de pago mediante el terminal móvil, puede verse o llamarse en el terminal móvil el contenido pagado. El proceso de autorización también puede permitir una serie de transacciones posteriores (esto también es válido para las siguientes formas de realización según la fig. 2 a la fig. 9) Tras un proceso de autorización realizado con éxito pueden realizarse por ejemplo varias compras en una tienda online.
15 En el código de barras 1 puede estar codificado p. ej. una dirección de Internet. El terminal móvil, por ejemplo un teléfono móvil, puede leer con ayuda de un software de lector de códigos de barras (denominado a continuación lector de códigos de barras) el código de barras mediante la cámara del teléfono móvil. El lector de códigos de barras detecta la dirección de Internet codificada en el mismo y ofrece la opción de llamar la dirección p. ej. en el
20 navegador del teléfono móvil. La llamada puede ser confirmada, dado el caso, por el usuario. El navegador del terminal móvil llama a continuación la página de Internet que pertenece a la dirección de Internet.
En el marco de una llamada identificación, que detecta la autentificación, la autorización y las propiedades de aparato del aparato que realiza la solicitud, se realizan dos procesos:
25 - el proceso "tsPayment" detecta si pueden realizarse una autentificación y una autorización (etapa 1b). tsPayment puede estar configurado de tal modo que mediante el mismo también puede ejecutarse un proceso de pago, que puede tener lugar tras una autorización realizada con éxito.
-
El proceso "tsContenido" detecta en qué forma ha de realizarse la visualización de la página de Internet en el
terminal (etapa 1a). Según el tipo de terminal, p. ej. teléfono móvil o pantalla de ordenador, la página de Internet es 30 correspondientemente procesada en tsContenido.
Los dos procesos pueden ejecutarse en un servidor web. No obstante, los procesos también pueden ejecutarse en distintos servidores web, comunicando los procesos entre sí mediante una interfaz especial.
35 Las dos etapas 1a y 1b son respectivamente idénticas para las formas de realización descritas a continuación en la fig. 2 a la fig. 9. La única excepción es la forma de realización según la fig. 5.
Etapa 1a:
40 El servidor web que suministra (tsContenido) detecta p. ej. mediante una detección de agente de usuario (o detección de aparato) que la página de Internet debe suministrarse/emitirse para una pantalla pequeña (que se usa habitualmente en los aparatos móviles).
Etapa 1b:
45 Mediante una interfaz se consulta al proveedor de pago (designado en las figuras respectivamente con Pay Provid.) si para el terminal móvil que emite la consulta (que llama la página de Internet) puede realizarse la detección del número de red digital de servicios integrados de estación móvil (MSISDN, Mobile Subscriber Integrated Services Digital Network Number) del terminal móvil, del usuario, del propietario o del ID de usuario (OK?). El tipo de
50 detección depende del proveedor de pago.
Con ayuda del acuse de recibo del proveedor de pago (OK! o NoOK!) se inicia una transacción de pago correspondiente:
55 - WAP/IP móvil (en caso de OK!) o
-
Internet móvil (en caso de NoOK!), véase la fig. 2.
En caso de un acuse de recibo positivo (OK!) del proveedor de pago, el servidor web (tsContenido) emite la página de Internet 2 al terminal móvil con los siguientes elementos: enlace de pago, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. El enlace de pago también puede llamarse de otra manera. Esto representa la terminación realizada con éxito del proceso de autorización.
En caso de un acuse de recibo negativo (NoOK!), es decir, cuando no puede detectarse el MSISDN, el servidor web
5 (tsPayment) ofrece automáticamente un método de autorización alternativo, para terminar de forma segura y con éxito el proceso de autorización. Aquí es ventajoso que el proceso de autorización no se termine simplemente tras un intento fallido, a diferencia del procedimiento conocido por el estado de la técnica, sino que el servidor web (tsPayment) intenta mediante una posibilidad de autorización alternativa, por ejemplo autorización por SMS, terminar con éxito el proceso de autorización. En relación con la fig. 2 se ofrecerá una descripción detallada de ello.
10 Etapa 2a:
Con un clic en el enlace de pago se consulta al servidor web (tsPayment) la posibilidad de realizar el pago (Authorize/Payment!). El servidor web (tsPayment) consulta a su vez mediante una interfaz al proveedor de pago si
15 es posible la realización del pago (Payment OK?).
El proveedor de pago indica la realización de esta transacción a su vez a los operadores de red de telefonía móvil. La asignación del MSISDN, del usuario o del propietario al operador de red correspondiente, así como la consulta para la realización de una transacción de pago al operador de red (p. ej. la consulta de si hay suficiente saldo de
20 prepago o si hay suficiente solvencia o si puede realizarse una transacción según las directivas internas de los operadores de red de telefonía móvil), son tareas del proveedor de pago. También pueden aplicarse otras directivas al realizar la consulta.
Etapa 2b:
25 Si puede realizarse la transacción de pago, tiene lugar un acuse de recibo positivo (Payment OK!) del proveedor de pago al servidor web que realiza la consulta (tsPayment).
El servidor web (tsContenido) suministra (Confirmación*) a continuación una página de Internet 3 al terminal móvil
30 con una confirmación y enlaces de continuar. De este modo puede llamarse o cargarse el contenido pagado. El proceso de autorización y el proceso de pago se han realizado con éxito.
El proceso de pago o la realización del proceso de pago pueden tener lugar mediante una o varias etapas. El número de etapas a realizar puede depender de los procesos y/o del protocolo entre el proveedor de pago y el
35 operador de red de telefonía móvil correspondiente que participa en el proceso de pago correspondiente.
En lugar de un operador de red de telefonía móvil también puede estar prevista otra instancia, que dispone de los derechos necesarios para la autorización y realización de las transacciones descritas en este contexto. La terminación de una transacción descrita en este contexto o la configuración de una transacción de este tipo no se
40 especifican aquí de forma detallada. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
2) Autorización por SMS
45 La fig. 2 muestra un proceso de autorización según la invención (autorización por SMS) con posterior transacción de pago mediante la llamada facturación por SMS o como puede realizarse una detección de usuario/detección de aparato cuando ha fallado un primer interno de autorización. En lugar de una transacción de pago, a continuación del proceso de autorización también pueden realizarse otras transacciones.
50 La autorización por SMS está prevista en el marco de la invención cuando el proveedor de pago emite un acuse de recibo negativo (NoOK!) en el marco de la autorización por WAP, como se ha descrito haciéndose referencia a la fig.
1. Es decir, la autorización por SMS se usa cuando no puede realizarse la detección de usuario, la detección de aparato o la autorización de una transacción de pago según la autorización por WAP.
55 De este modo aumenta de forma ventajosa claramente la probabilidad de poder terminar con éxito un proceso de autorización. Gracias a pasar a un proceso de autorización alternativo (p. ej. autorización por SMS), la autorización termina con éxito también cuando ha fallado un primer interno de autorización, por ejemplo por deficiencias técnicas de un terminal. Un proveedor de servicios ya no debe ofrecer distintas variantes de autorización para permitir la autorización mediante distintos terminales. Para el proveedor de servicios basta con ofrecer una variante de autorización, puesto que el servidor web (tsPayment) ofrece automáticamente otra variante de autorización mediante la cual puede realizarse la autorización.
5 El punto de partida es también aquí un código de barras 1, que está aplicado en un producto impreso o que se visualiza por ejemplo en una pantalla. El proceso de autorización se realiza mediante el terminal móvil.
En cuanto haya terminado el proceso de autorización (preferiblemente con posterior transacción de pago) mediante el terminal móvil, en el terminal móvil puede visualizarse o llamarse el contenido pagado.
10 La lectura del código de barras con el terminal móvil, así como la llamada de la página de Internet que pertenece a la dirección de Internet (del código de barras) se realiza de la forma ya descrita en relación con la fig. 1.
Los procesos tsPayment (etapa 1b) y el tsContenido (etapa 1a) en el marco de una identificación se ejecutan en el 15 servidor web (véase la etapa 1a y la etapa 1b de la fig. 1).
Con ayuda del acuse de recibo del proveedor de pago (OK! o NoOK!) se inicia una transacción de pago correspondiente:
-
WAP/IP móvil (en caso de OK!), véase la fig. 1, o 20 - Internet móvil (en caso de NoOK!).
En la descripción de la forma de realización mostrada en la fig. 2 se parte de que la identificación y, por lo tanto, la autorización no se han realizado con éxito (NoOK!).
25 Etapa 2:
En caso de un acuse de recibo negativo del proveedor de pago (NoOK!), el servidor web (tsContenido) emite la página de Internet 2 al terminal móvil con los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, enlace de SMS, así como introducción al contenido, observaciones, precios, condiciones generales de
30 contrato etc. y un enlace de continuar. El enlace de SMS o el enlace de continuar también pueden llamarse de otra manera.
Etapa 3:
35 Según la instrucción de SMS, que contiene el texto del SMS y el número del SMS, se genera mediante el terminal móvil con preferencia automáticamente mediante clic, etapa 3b, un SMS correspondiente según la instrucción de SMS. Aquí, el SMS se genera p. ej. o mediante el navegador o mediante la aplicación nativa de SMS en función del terminal móvil usado, de la versión y de las funciones del software del navegador existente. El texto del SMS puede contener datos de la transacción (p. ej. ID de la transacción), que son relevantes para la realización de una
40 transacción.
Aquí es especialmente ventajoso que la puesta a disposición de una autorización mediante una segunda variante de autorización se realice de tal modo que el usuario del terminal pueda realizar la autorización sin entrada manual de datos. Sólo es necesaria una confirmación para el inicio de la autorización. De este modo se evitan eficientemente
45 entradas incorrectas, que pueden conducir a anotaciones incorrectas etc. Como alternativa, la generación del SMS también puede realizarse mediante entrada manual, etapa 3a, en caso de que el terminal no soporte la generación automática de un SMS.
Etapa 3c:
50 Gracias al envío del SMS se transmiten el MSISDN, la ID de la transacción, el texto del SMS, los caracteres del SMS etc. al proveedor de pago (MSISDN usuario?). Por lo tanto, se usa otro canal de transmisión (canal de datos SMS y canal de señales) para la transmisión de los datos de la transacción que en la transmisión según el procedimiento de la fig. 1, donde se usa el canal de datos WAP, de modo que queda garantizada una detección de la identificación del
55 teléfono móvil y, por lo tanto, una autorización.
La interacción entre el proveedor de pago y el operador de red de telefonía móvil puede realizarse de distintas formas y no se describe aquí detalladamente.
Etapa 3d:
El proveedor de pago transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el usuario, el propietario, una ID especial (MSISDN User!) y/o detalles de la transacción (p. ej. texto del SMS) o una combinación
5 de éstos. A continuación, el servidor web consulta al proveedor de pago si puede realizarse el pago (Payment OK?). El proveedor de pago indica la realización de esta transacción de pago a su vez a los operadores de red de telefonía móvil.
La asignación del MSISDN, del usuario o del propietario al operador de red correspondiente, así como la consulta
10 para la realización de una transacción 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 transacción según las directivas internas de los operadores de red de telefonía móvil) son tareas del proveedor de pago.
Etapa 2a:
15 Al hacer clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize/Payment?). La consulta también puede ser una consulta de si se ha realizado con éxito la autorización. En caso de un acuse de recibo negativo (por ejemplo, porque no se ha realizado completamente la etapa 3), el servidor web (tsContenido) emite la página de Internet 2 nuevamente al terminal móvil con una observación
20 correspondiente.
Etapa 4:
En caso de un acuse de recibo positivo (Payment OK!) por parte del proveedor de pago, el servidor web
25 (tsContenido) suministra una página de Internet al terminal móvil con una confirmación así como enlaces de continuar (confirmación). Mediante estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse una transacción nueva.
En lugar de la lectura de un código de barras, en una página web móvil que se visualiza en el terminal móvil ya 30 puede visualizarse una instrucción de SMS y un enlace de SMS, que contiene el texto de SMS y el número de SMS,
o el número de SMS y un texto de SMS. El enlace de SMS conduce a que el SMS se genere automáticamente. Aquí, el SMS se genera p. ej. o mediante el navegador o mediante la aplicación nativa de SMS en función del terminal móvil usado, de la versión y de las funciones del software del navegador existente. El texto del SMS puede contener datos de la transacción (p. ej. ID de la transacción), que son relevantes para la realización de una
35 transacción.
Como alternativa, un SMS también puede enviarse manualmente con el texto de SMS representado al número de SMS representado. Después de haberse realizado con éxito la autorización y dado el caso el pago se suministra una página de resultados al terminal móvil, que contiene un enlace de continuar para la carga del contenido comprado.
40 En lugar de esta página de resultados, también puede suministrarse el contenido comprado al terminal móvil. La terminación de una transacción descrita en este contexto o la configuración de una transacción de este tipo no se especifican aquí de forma detallada. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
45 3) Autorización por PC-WAP
La fig. 3 muestra una autorización (autorización por PC-WAP) con posterior transacción de pago mediante el llamado pago WAP/IP o muestra como puede realizarse una detección de usuario/detección de aparato. Esta forma
50 de realización está basada en el procedimiento como está descrito en relación con la fig. 1.
El acceso o el inicio de la autorización se realizan mediante un código de barras que está colocado en una página web. Esta página web se visualiza en un dispositivo de visualización de un aparato estacionario (p. ej. ordenador).
55 Este procedimiento (según la fig. 3) está caracterizado porque el área accesible mediante el terminal móvil está vinculada con el procedimiento de autorización realizado mediante el terminal móvil. Esto significa que en el terminal estacionario se indica el proceso de autorización. En cuanto éste se ha realizado mediante el terminal móvil, en el terminal estacionario puede visualizarse o llamarse el contenido pagado o pueden realizarse transacción posteriores
(p. ej. más compras).
Es decir, que el procedimiento se realiza mediante dos terminales distintos, detectándose las propiedades del hardware de los terminales. Las propiedades del hardware detectadas permiten al dispositivo de autorización
-
adaptar u optimizar las páginas web para la visualización en el terminal estacionario (p. ej. monitor del PC) para la 5 realización p. ej. de una compra de contenidos o de productos y
-
adaptar u optimizar las páginas web para la visualización en la pantalla de terminales móviles, para la realización de la autorización (p. ej. la autorización de una compra).
Etapa 1:
10 En una página de Internet hay un código de barras 2D. El servidor web que suministra la página (tsContenido o terceros proveedores) detecta mediante detección de agente de usuario (o detección de aparato) que la página de Internet debe suministrarse o emitirse para un terminal estacionario (monitor de PC, notebook, ordenador portátil o similar).
15 En el código de barras está codificada una dirección de Internet. El código de barras se lee y evalúa con el terminal móvil. Esto se realiza de la forma descrita en relación con la fig. 1. El navegador del terminal móvil llama la página de Internet que pertenece a la dirección de Internet.
20 Ahora se realizan en el marco de la autorización los procesos tsPayment (etapa 1b) y tsContenido (etapa 1a) descritos en relación con la fig. 1.
Con ayuda del acuse de recibo del proveedor de pago (OK! o NoOK!) se inicia una transacción de pago correspondiente: 25 - pago por PC - WAP (OK!), o
-
facturación por PC - SMS (NoOK!), véase la fig. 4.
Etapa 2:
30 En caso de un acuse de recibo positivo (OK!) por parte del proveedor de pago, es decir, cuando la autorización se ha realizado con éxito, el servidor web (tsContenido) emite la página de Internet 2 en el terminal móvil con los siguientes elementos: enlace de pago, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. El enlace de pago también puede llamarse de otra manera.
35 Etapa 2a:
Al hacer clic en el enlace de pago en la página de Internet 2, se consulta al servidor web (tsPayment) la posibilidad para realizar el pago (Authorize/Payment!). El servidor web (tsPayment) consulta a su vez mediante una interfaz al proveedor de pago acerca de la realización del pago (Payment OK?). La comunicación entre el servidor web
40 (tsPayment) y el proveedor de pago se realiza como ya se ha descrito en relación con la fig. 1.
Etapa 2b:
En caso de un acuse de recibo positivo (Payment OK!) por el proveedor de pago al servidor web (tsPayment), se 45 realiza la transacción de pago o se autoriza la realización.
Etapa 3:
El servidor web (tsContenido) suministra a continuación (confirmación*) una página de Internet 3 al terminal móvil
50 con una confirmación así como enlaces de continuar. El proceso de pago propiamente dicho puede realizarse mediante una o varias etapas. Esto depende entre otras cosas de los procesos o los protocolos entre el proveedor de pago y el operador de red de telefonía móvil correspondiente, que participan en el proceso de pago correspondiente.
55 Mediante los enlaces de continuar puede llamarse o cargarse el contenido pagado o puede iniciarse una transacción nueva.
Según la invención, el acceso a los contenidos pagados también puede realizarse mediante la página web 1 en el terminal estacionario. Para ello se realiza la etapa 1c que se describirá a continuación.
Etapa 1c:
Mediante un clic en el enlace de continuar se consulta al servidor web (ts Payment) si se ha realizado el pago 5 (Authorize Payment?). Esta consulta puede realizarse transmitiendo la consulta p. ej. una ID de transacción, que coincide con una ID de transacción durante el proceso de autorización.
En caso de un acuse de recibo negativo (por ejemplo porque aún no se ha realizado ninguna autorización mediante el teléfono móvil), el servidor web (tsContenido) vuelve a emitir la página 1 optimizada para el terminal estacionario 10 con una observación correspondiente.
Etapa 4:
En caso de un acuse de recibo positivo, el servidor web (tsContenido) transmitirá una página de confirmación al 15 terminal estacionario (confirmación). Ésta contiene enlaces de continuar, mediante los cuales puede llamarse o cargarse el contenido pagado o pueden realizarse otras transacciones.
Este control de la secuencia descrito con referencia a la fig. 3 puede implementarse en tsContenido o puede integrarse mediante API en la oferta de páginas de Internet de terceros proveedores. La terminación de una
20 transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
25 4) Autorización por PC-WAP-SMS
La fig. 4 muestra una forma de la autorización (autorización por PC-WAP-SMS) con posterior transacción de pago mediante la llamada facturación por SMS o como puede realizarse una detección de usuario/detección de aparato, cuando no es técnicamente posible una autorización por WAP o por PC-WAP (como está descrita en la fig. 3). Esta
30 forma de realización está basada en los procedimientos como están descritos con referencia a la fig. 2 (autorización por SMS) y la fig. 3 (autorización por PC-WAP).
La autorización por PC-WAP-SMS se usa en este caso como variante sustitutoria, cuando no puede realizarse la detección de usuario, la detección de aparato o la autorización de transacción de pagos según la autorización por 35 WAP o la autorización por PC-WAP.
El acceso o el inicio de la autorización se realiza (como en la fig. 3) mediante un código de barras que está colocado en una página de Internet. Esta página de Internet se visualiza en un dispositivo de visualización de un aparato estacionario (p. ej. ordenador).
40 Este procedimiento (según la fig. 4) está caracterizado porque el área accesible a través del terminal estacionario está vinculada con el procedimiento de autorización realizado mediante el terminal móvil. Esto significa que en el terminal estacionario se indica el proceso de autorización. En cuanto éste se haya realizado mediante el terminal móvil, el contenido pagado puede visualizarse o llamarse en el terminal estacionario o pueden realizarse
45 transacciones posteriores (p. ej. otras compras).
Es decir, se interactúa entre áreas,
-
que están adaptadas u optimizadas para la visualización de páginas web en el terminal estacionario (p. ej. monitor del PC) para la realización p. ej. de una compra de contenidos o productos y
50 - que están adaptadas u optimizadas para la visualización de páginas web en la pantalla de terminal móviles, para la realización de la autorización (p. ej. autorización de una compra).
Etapas 1, 1a y 1b:
55 Las etapas 1, 1a y 1b corresponden sustancialmente a las etapas 1, 1a y 1b de la fig. 3.
Con ayuda del acuse de recibo del proveedor de pago (OK! o NoOK!) se inicia una transacción de pago correspondiente:
-
pago por PC - WAP (OK!), véase la fig. 3, o
-
facturación por PC - SMS (NoOK!).
Etapa 2:
5 En caso de una acuse de recibo negativo (NoOK!) del proveedor de pago, se transmite la página de Internet 2 al terminal móvil con los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, enlace de SMS, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. así como un enlace de continuar.
10 El enlace de SMS o el enlace de continuar también pueden llamarse de otra manera.
Las etapas posteriores 3, 3a, 3b, 3c, 3d, 2a y 4 corresponden sustancialmente a las etapas 3, 3a, 3b, 3c, 3d, 2a y 4 de la fig. 2. En este sentido puede remitirse a la descripción de la fig. 2.
15 Etapa 12c:
Mediante un clic en el enlace de continuar en la página web 1 en el terminal estacionario, se consulta al servidor web (tsPayment) (Authorize Payment?), si se ha realizado el pago. En caso de un acuse de recibo negativo, el servidor
20 web (tsContenido) vuelve a emitir la página 1 optimizada para el terminal estacionario nuevamente con una observación correspondiente.
Etapa 5:
25 En caso de un acuse de recibo positivo (Authorize/Payment?), el servidor web suministra una página de confirmación al terminal estacionario (confirmación). Ésta contiene enlaces de continuar. Mediante estos enlaces puede llamarse o cargarse el contenido pagado o pueden realizarse otras transacciones.
Este control de la secuencia descrito con referencia a la fig. 4 puede implementarse en tsContenido o puede
30 integrarse mediante API en la oferta de páginas de Internet de terceros proveedores. La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
35 5) Autorización por PC - SMS Premium
La fig. 5 muestra una forma de la autorización (autorización por PC-SMS Premium) con transacción de pago simultánea mediante la llamada facturación por SMS o una detección de usuario /detección de aparato, cuando no
40 puede o debe usarse una autorización como se ha descrito en las fig. 1 a la fig. 4.
El punto de partida es aquí un código de barras, que se visualiza en una página web en el terminal estacionario.
En cuanto se haya realizado la autorización o la transacción de pago mediante el terminal móvil (por SMS), en el 45 terminal estacionario puede visualizarse o llamarse el contenido pagado o pueden realizarse otras transacciones.
Etapa 1:
En una página de Internet 1 hay un código de barras 2D. El servidor web que suministra la página (tsContenido o un
50 tercero proveedor) detecta mediante detección de agente de usuario (o detección de aparato) que la página de Internet debe suministrarse/emitirse para un terminal estacionario (p. ej. monitor del PC, notebook, ordenador portátil, o similar). La página de Internet 1 contiene además del código de barras los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. y un enlace de continuar. En el código de barras está codificada una instrucción de SMS.
55 Etapa 2:
A continuación, se genera y envía un SMS.
Etapa 2a:
La generación del SMS puede realizarse manualmente con ayuda de los datos emitidos.
5 Etapa 2b:
Como alternativa puede realizarse la generación del SMS automáticamente mediante una fotografía o escaneo del código de barras. El terminal móvil puede leer el código de barras con ayuda de un lector de códigos de barras mediante la cámara. El lector de códigos de barras detecta los caracteres del SMS y ofrece la opción de generar y,
10 dado el caso, enviar el SMS. También es posible que el SMS sea generado por la aplicación nativa de SMS del aparato móvil.
Puede estar previsto que la generación y el envío del SMS deban ser confirmados respectivamente por el usuario.
15 Etapa 2c:
Mediante el envío del SMS se transmiten MSISDN, ID de transacción, texto de SMS, caracteres del SMS etc. al proveedor de pago (MSISDN User?).
20 Etapa 2d:
El proveedor de pago transmite al servidor web (ts Payment) mediante una interfaz el MSISDN, el usuario, el propietario y/o una ID especial (MSISDN User!), así como dado el caso datos de transacción (que pueden estar contenidos p. ej. en el texto del SMS). A continuación, el servidor web consulta al proveedor de pago si se ha
25 realizado el pago (Payment OK?).
El proveedor de pago indica al operador de red de telefonía móvil la realización de esta transacción de pago. La asignación del MSISDN, del usuario o del propietario al operador de red correspondiente, así como la consulta de si se ha realizado una transacción de pago al operador de red son tareas del proveedor de pago. Respecto a la
30 posterior secuencia entre el operador de red y el proveedor de pago se remite a la etapa 2a de la fig. 1.
Etapa 1a:
Mediante un clic en el enlace de continuar en la página de Internet 1, se consulta al servidor web (tsPayment) si se
35 ha realizado el pago (Authorize/Payment?). En caso de un acuse de recibo negativo, el servidor web (tsContenido) vuelve a emitir la página de Internet 1 optimizada para el terminal estacionario con una observación correspondiente.
Etapa 3:
40 En caso de un acuse de recibo positivo (Authorize/Payment?), el servidor web (tsContenido) suministra una página de confirmación 3 al terminal estacionario (confirmación). Ésta página contiene enlaces de continuar. Mediante estos enlaces puede llamarse o cargarse el contenido pagado o pueden realizarse otras transacciones.
Este control de la secuencia descrito con referencia a la fig. 5 puede implementarse en tsContenido o puede
45 integrarse mediante API en la oferta de página de Internet de terceros proveedores. La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
50 6) Inicio de procedimiento para autorización por PC-WAP o autorización por PC-WAP-SMS
La fig. 6 muestra un procedimiento que puede tener lugar opcionalmente antes de los procedimientos de autorización por PC-WAP (véase la fig. 3) y/o de autorización por PC-WAP-SMS (fig. 4).
55 Etapa 1:
En una página de Internet 1 (en un terminal estacionario) hay una introducción al contenido y un enlace de continuar. La introducción al contenido puede estar formada por textos, imágenes, indicaciones de precios, condiciones generales de contrato etc. que describen el producto.
Etapa 1a:
5 Mediante un clic en el enlace de continuar se consulta al servidor web (tsPayment) la posibilidad de realizar una autorización (o una transacción de pago).
Etapa 1b:
10 Mediante una interfaz se consulta al proveedor de pago (OK?), si puede detectarse para el aparato que emite la consulta el MSISDN, el usuario o el propietario. El tipo de detección depende del proveedor de pago.
Etapa 1c:
15 Con ayuda del acuse de recibo del proveedor (OK! o NoOK!) se inicia el proceso de autorización (y dado el caso una transacción de pago posterior) según los procedimientos
-
autorización por PC-WAP (véase la fig. 3) o
-
autorización por PC-WAP-SMS (véase la fig. 4)
20 La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
25 7) Inicio de procedimiento para la autorización por PC-SMS Premium
La fig. 7 muestra un procedimiento que puede tener lugar opcionalmente antes del procedimiento de autorización por PC-SMS Premium) (véase la fig. 5). 30 Etapa 1:
En una página de Internet 1 de un terminal estacionario hay una introducción al contenido y un enlace de continuar. La introducción al contenido puede estar formada por textos, imágenes, indicaciones de precios, condiciones 35 generales de contrato etc. que describen el producto.
Etapas 1a, 1b y 1c:
Las etapas 1a, 1b y 1c corresponden a las etapas 1a, 1b y 1c de la fig. 6, iniciándose en la etapa 1c con ayuda del
40 acuse de recibo del proveedor de pago (OK! o NoOK!) el proceso de autorización (y dado el caso una posterior transacción de pago) según el procedimiento autorización por PC-SMS Premium (véase la fig. 5). La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago
o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según 45 criterios no detalladamente indicados.
8) Autorización por PC-WAP combinada con autorización por PC-SMS Premium
La fig. 8 muestra una combinación según la invención de la autorización por PC-WAP (véase la fig. 3) con la 50 autorización por PC-SMS Premium (véase la fig. 5).
Etapa 1:
En una página de Internet que se visualiza en un terminal estacionario hay un código de barras 2D. El servidor web
55 que suministra la página (tsContenido o el servidor web de un tercero proveedor) detecta p. ej. mediante detección de agente de usuario (o detección de aparato) que la página de Internet debe suministrarse/emitirse para un terminal estacionario (p. ej. monitor del PC, notebook, ordenador portátil, o similar).
En el código de barras está codificada p. ej. una dirección de Internet (URL). El terminal móvil puede leer con ayuda de un software de lector de códigos de barras el código de barras mediante la cámara. El lector de códigos de barras detecta la dirección de Internet y ofrece la opción de llamar la dirección en el navegador del terminal móvil. La llamada puede ser confirmada, dado el caso, por el usuario. El navegador del terminal móvil llama a continuación la página de Internet que pertenece a la dirección de Internet.
5 En el marco de la identificación se realizan dos procesos:
-
el proceso "tsPayment" detecta si puede realizarse una transacción de pago (etapa 1b);
-
el proceso "tsContenido" detecta en qué forma ha de realizarse la visualización de la página de Internet (etapa 1a).
10 Las etapas 1a y 1b corresponden a las etapas 1a y 1b descritas en relación con la fig. 1 y la fig. 3.
Con ayuda del acuse de recibo del proveedor (OK! o NoOK!) se inicia el proceso de autorización (y dado el caso una posterior transacción de pago) según los procedimientos
-
autorización por PC-WAP (véase la fig. 3) o 15 - autorización por PC-SMS Premium (véase la fig. 5).
Etapa 2:
En caso de un acuse de recibo positivo (OK!) del proveedor de pago, la página de Internet se emitirá en el terminal
20 móvil con los siguientes elementos: enlace de pago, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. El enlace de pago también puede llamarse de otra manera.
Etapa 2a:
25 Mediante un clic en el enlace de pago (de la página de Internet móvil) se consulta al servidor web (tsPayment) la posibilidad de realizar el pago (Authorize Payment). El servidor web (tsPayment) consulta mediante una interfaz al proveedor de pago si se ha realizado el pago (Payment OK?). El proveedor de pago indica la realización de esta transacción de pago nuevamente a los operadores de red de telefonía móvil. La asignación del MSISDN, del usuario
o del propietario al operador de red de telefonía móvil correspondiente, así como la consulta para la realización de 30 una transacción de pago en el operador de red son tareas del proveedor de pago.
Etapa 2b:
En caso de un acuse de recibo positivo (Payment OK!) el proveedor de pago realiza la transacción de pago o 35 autoriza la realización.
Etapa 3:
A continuación, el servidor web (tsContenido) suministra una página de Internet al terminal móvil con una
40 confirmación así como con enlaces de continuar (confirmación*). El proveedor de pago o la visualización del proceso de pago puede realizarse mediante una o varias etapas. El número de las etapas a realizar puede depender de los procesos entre el proveedor de pago y el operador de red de telefonía móvil correspondiente que participa en el proceso de pago correspondiente. Mediante los enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse un nuevo proceso de pago u otra transacción.
45 Etapa 1c:
Mediante un clic en el enlace de continuar (en el terminal estacionario) se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize Payment?) o si se ha realizado con éxito.
50 Etapa 4:
En caso de un acuse de recibo positivo (Authorize/Payment?), el servidor web (tsContenido) suministra una página de confirmación al terminal estacionario (confirmación de pago). Esta página contiene enlaces de continuar.
55 Mediante estos enlaces puede llamarse o cargarse el contenido pagado o puede iniciarse otra transacción o un nuevo proceso de pago.
Las siguientes etapas son características para la combinación de los procedimientos autorización por PC-WAP con la autorización por PC-SMS Premium.
Etapa 6:
En caso de un acuse de recibo negativo para el terminal estacionario (por ejemplo porque no sean realizado
5 completamente las etapas 1a, 1b, 2, 2a, 2b, 3, etc.), el servidor web (tsContenido) emite una nueva página optimizada para el terminal estacionario. La página contiene además de otro código de barras nuevamente generado los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. y un enlace de continuar. En el código de barras está codificado un SMS
10 Etapa 16:
Según la instrucción de SMS se genera un SMS correspondiente.
15 Etapa 7a:
La generación del SMS puede realizarse mediante entrada manual.
Etapa 7b:
20 La generación del SMS puede realizarse automáticamente mediante escaneo o una fotografía del código de barras. El terminal móvil puede leer el código de barras con ayuda de un software de lector de códigos de barras mediante la cámara. El lector de BCA detecta los caracteres del SMS y ofrece la opción de generar el SMS. Dado el caso, la generación es confirmada por el usuario. Aquí, el SMS se genera en función del terminal móvil usado, de la versión y
25 de las funciones del software del navegador existente o mediante el navegador, mediante la aplicación nativa de SMS o mediante el software de lector de códigos de barras.
Etapa 7c:
30 Mediante el envío del SMS se transmiten MSISDN, ID de transacción, texto de SMS, caracteres del SMS, detalles de la transacción etc. al proveedor de pago (MSISDN User?). Los detalles de la transacción pueden ser parte del texto del SMS. El proveedor de pago transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el usuario, el propietario y/o una ID especial (MSISDN User!). A continuación, el servidor web consulta al proveedor de pago si se ha realizado el pago (Payment OK?).
35 Etapa 6a:
Mediante un clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago o si se ha realizado con éxito (Authorize/Payment?). En caso de un acuse de recibo negativo (p. ej. porque no se han
40 realizado completamente las etapas 1 - 3 y 7 y siguientes), el servidor web (tsContenido) emite una nueva página 6 optimizada para el terminal estacionario. La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.
45 9) Autorización por PC-WAP-SMS combinada con autorización por PC-SMS Premium
La fig. 9 muestra una combinación según la invención de la autorización por PC-WAP-SMS (véase la fig. 4) con la autorización por PC-SMS Premium (véase la fig. 5).
50 Etapa 1:
En una página de Internet del terminal estacionario hay un código de barras 2D. El servidor web que suministra la página de Internet (tsContenido o el servidor web de un tercero proveedor) detecta mediante detección de agente de
55 usuario (o detección de aparato) que la página de Internet debe suministrarse/emitirse para un terminal estacionario
(p. ej. monitor del PC, notebook, ordenador portátil, o similar). En el código de barras está codificado una dirección de Internet. El terminal móvil puede leer con ayuda de un software de lector de códigos de barras el código de barras mediante la cámara. El lector de códigos de barras detecta la dirección de Internet y ofrece la opción de llamar la dirección en el navegador del terminal móvil. La llamada es confirmada, dado el caso, por el usuario.
En el marco de la identificación se realizan dos procesos (véase la fig. 1):
-
el proceso "tsPayment" detecta si puede realizarse una transacción de pago (etapa 1b);
-
el proceso "tsContenido" detecta en qué forma ha de realizarse la visualización de la página de Internet (etapa 1a).
5 Las etapas 1a y 1b corresponden a las etapas 1a y 1b descritas en relación con la fig. 1 y la fig. 3.
Con ayuda del acuse de recibo del proveedor (OK! o NoOK!) se inicia el proceso de autorización (y dado el caso una posterior transacción de pago) según los procedimientos
10 - 3) autorización por PC-WAP (véase la fig. 3) o
-
4) autorización por PC-SMS Premium (véase la fig. 4)
Etapa 2:
15 En caso de un acuse de recibo negativo (NoOK!) del proveedor de pago, la página de Internet se emite al terminal móvil con los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, enlace de SMS, introducción al contenido, observaciones, precios, condiciones generales de contrato y un enlace de continuar. El enlace de SMS o el enlace de continuar también pueden llamarse de otra manera.
20 Etapa 3:
Según la instrucción de SMS se genera un SMS correspondiente.
Etapa 17a:
25 La generación del SMS puede realizarse mediante entrada manual.
Etapa 3b:
30 La generación puede realizarse automáticamente mediante un clic en el enlace de SMS. Aquí, el SMS se genera en función del terminal móvil usado, de la versión y de las funciones del software del navegador existente o mediante el navegador o mediante la aplicación nativa de SMS.
Etapa 3c:
35 Mediante el envío del SMS se transmiten MSISDN, ID de transacción, texto de SMS, caracteres del SMS, etc. al proveedor de pago (MSISDN User?).
Etapa 3d:
40 El proveedor de pago transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el usuario, el propietario y/o una ID especial (MSISDN User!). A continuación, el servidor web consulta al proveedor de pago si se ha realizado el pago (Payment OK?).
45 El proveedor de pago indica la realización de la transacción de pago a su vez a los operadores de red de telefonía móvil. La asignación del MSISDN, del usuario o del propietario al operador de red correspondiente, así como la consulta para la realización de una transacción de pago al operador de red son tareas del proveedor de pago. Respecto a la secuencia restante entre el operador de red y el proveedor de pago se remite a la etapa 2a de la fig. 1.
50 Etapa 2a:
Mediante un clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize Payment?) o si se ha realizado con éxito.
55 Etapa 4:
En caso de un acuse de recibo positivo (Payment OK!) del proveedor de pago, el servidor web (tsContenido) suministra una página de Internet al terminal móvil con una confirmación, así como con enlaces de continuar (confirmación de pago). Mediante estos enlaces de continuar puede llamarse o cargarse el contenido pagado o puede iniciarse otra transacción.
Etapa 1c:
5 Mediante un clic en el enlace de continuar se consulta al servidor web (tsPayment) si se ha realizado el pago (Authorize Payment?) o si se ha realizado con éxito.
Etapa 5:
10 En caso de un acuse de recibo positivo (Authorize/ Payment?), el servidor web (tsContenido) suministra una páginade confirmación al terminal estacionario (confirmación de pago). Ésta contiene enlaces de continuar. Mediante estos enlaces de continuar puede llamarse o cargarse el contenido pagado o puede iniciarse otra transacción.
Las siguientes etapas son características para la combinación de los procedimientos autorización por PC-WAP-SMS 15 con la autorización por PC-SMS Premium.
Etapa 6:
En caso de un acuse de recibo negativo para el terminal estacionario (por ejemplo porque no sean realizado
20 completamente las etapas 1a, 1b, 2, 2a, 2b, 3, etc.), el servidor web (tsContenido) emite una nueva página optimizada para el terminal estacionario. Esta página de Internet contiene además de otro código de barras nuevamente generado los siguientes elementos: instrucción de SMS, texto de SMS, número de SMS, introducción al contenido, observaciones, precios, condiciones generales de contrato etc. y un enlace de continuar. En el código de barras está codificado un SMS o una instrucción de SMS.
25 Etapa 3:
Según la instrucción de SMS se genera un SMS correspondiente.
30 Etapa 7a:
La generación del SMS puede realizarse mediante entrada manual. La etapa 7a corresponde sustancialmente a la etapa 3a.
35 Etapa 7b:
La etapa 7b corresponde sustancialmente a la etapa 3b. La generación del SMS puede realizarse automáticamente mediante escaneo del código de barras. El terminal móvil puede leer el código de barras con ayuda de un software de lector de códigos de barras mediante la cámara. El lector de códigos de barras detecta los caracteres del SMS o
40 la instrucción de SMS y ofrece la opción de generar el SMS. Dado el caso, la generación es confirmada por el usuario. Aquí, el SMS se genera en función del terminal móvil usado, de la versión y de las funciones del software del navegador existente o mediante el navegador o mediante la aplicación nativa de SMS o mediante el software de lector de códigos de barras.
45 Etapa 3c:
Mediante el envío del SMS se transmiten MSISDN, ID de transacción, texto de SMS, caracteres del SMS, etc. al proveedor de pago (MSISDN User?). El proveedor de pago transmite al servidor web (tsPayment) mediante una interfaz el MSISDN, el usuario, el propietario y/o una ID especial (MSISDN User!) y/o detalles de la transacción (p. ej.
50 texto de SMS). A continuación, el servidor web consulta al proveedor de pago si se ha realizado el pago (Payment OK?).
Etapa 6a:
55 Mediante un 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 completamente las etapas 1 a 7), el servidor web (tsContenido) emite una nueva página 6 optimizada para el terminal estacionario. La terminación de una transacción descrita en este contexto o de una configuración de una transacción no se especifica aquí con detalle. Puede iniciarse o terminarse por ejemplo directamente a continuación de la autorización un proceso de pago o puede transmitirse una confirmación, después de la cual puede terminarse la transacción autorizada según criterios no detalladamente indicados.

Claims (13)

  1. REIVINDICACIONES
    1. Procedimiento para realizar una autorización de una transacción por Internet por un dispositivo de autorización (A), estando acoplado un primer terminal (E1) y un segundo terminal (E2) con el dispositivo de
    5 autorización (A) por una red de comunicación, pudiendo realizarse la transacción en uno de los dos terminales (E1, E2), pudiendo iniciarse la autorización en uno de los dos terminales (E1, E2), caracterizado porque, cuando un primer proceso de autorización (AV1), que comprende las etapas de
    -
    recepción de los datos de transacción por el dispositivo de autorización (A) de uno de los dos terminales 10 (E1, E2), recibiéndose los datos de transacción por un primer canal de transmisión (K1); y
    -
    detección por el dispositivo de autorización (A) de una primera identificación (ID1) que identifica uno de los terminales; conduce a un rechazo de la realización de la transacción debido a una detección fallida de la primera identificación (ID1), el dispositivo de autorización (A) genera datos debido al rechazo para la transmisión a
    15 uno de los dos terminales (E1, E2), conteniendo los datos los datos de transacción y una instrucción para el inicio de un segundo proceso de autorización (AV2) por uno de los dos terminales (E1, E2) por un segundo canal de transmisión (K2), y recibiéndose los datos de transacción por el segundo canal de transmisión (K2) por el dispositivo de autorización (A) y comprendiendo la generación de los datos por el dispositivo de autorización (A) una detección de las propiedades del hardware del primer o del segundo terminal y una
    20 adaptación de los datos a las propiedades del hardware detectadas.
  2. 2. Procedimiento de acuerdo con la reivindicación 1, siendo terminado el segundo proceso de autorización (AV2) por el dispositivo de autorización (A) y comprendiendo una etapa para la detección de una segunda identificación (ID2), estando asignada la segunda identificación (ID2) al terminal (E2) que inicia el segundo
    25 proceso de autorización (AV2) e identificando la segunda identificación (ID2) el terminal (E2) que inicia el segundo proceso de autorización (AV2).
  3. 3. Procedimiento de acuerdo con la reivindicación 1 ó 2, comprendiendo el segundo proceso de
    autorización (AV2) una etapa para la detección de una autorización de transacción, dependiendo la autorización de 30 transacción de la segunda identificación (ID2).
  4. 4. Procedimiento de acuerdo con una de las reivindicaciones 2 a 3, comprendiendo la detección de la segunda identificación (ID2) una consulta a un dispositivo de servidor y una recepción de la segunda identificación (ID2) desde el dispositivo de servidor, siendo recibida la segunda identificación (ID2) por el dispositivo de
    35 autorización (A) por el segundo canal de transmisión.
  5. 5. Procedimiento de acuerdo con una de las reivindicaciones anteriores, comprendiendo la instrucción para el inicio del segundo proceso de autorización (AV2) al menos uno de los siguientes datos:
    40 - datos para la generación y el envío manuales de un mensaje corto;
    -
    datos para la generación y el envío automáticos de un mensaje corto de un contenido predeterminado a un número de teléfono predeterminado;
    -
    código gráfico en el que están codificados los datos para una generación y envío automáticos de un
    mensaje corto de un contenido predeterminado a un número de teléfono predeterminado. 45
  6. 6. Procedimiento de acuerdo con una de las reivindicaciones anteriores, comprendiendo la detección de las propiedades del hardware una detección de las propiedades del hardware del dispositivo de visualización del primer o del segundo terminal, siendo el segundo terminal un terminal móvil, preferiblemente un terminal móvil con funcionalidad SMS y funcionalidad de telefonía.
  7. 7. Procedimiento de acuerdo con una de las reivindicaciones anteriores, siendo el primer canal de transmisión (K1) un canal de datos WAP o un canal de datos IP y siendo el segundo canal de transmisión (K2) un canal de mensajes cortos de telefonía móvil.
    55 8. Procedimiento de acuerdo con una de las reivindicaciones anteriores, realizándose la transacción en el primer terminal (E1) e iniciándose el proceso de autorización en el segundo terminal (E2).
  8. 9. Dispositivo de autorización (A) para realizar una autorización de una transacción por Internet, pudiendo acoplarse un primer terminal (E1) y un segundo terminal (E2) con el dispositivo de autorización (A) por una red de comunicación, pudiendo realizarse la transacción en uno de los dos terminales (E1, E2), pudiendo iniciarse la autorización en uno de los dos terminales (E1, E2) y estando configurado el dispositivo de autorización para realizar un procedimiento que comprende al menos las siguientes etapas:
    5 - realización de un primer proceso de autorización (AV1) que comprende:
    -
    recepción de datos de transacción de uno de los dos terminales (E1, E2), recibiéndose los datos de transacción por un primer canal de transmisión (K1), y
    -
    detección de una primera identificación (ID1) que identifica uno de los terminales, y
    -
    cuando el primer proceso de autorización (AV1) conduce a un rechazo de la realización de la transacción 10 debido a una detección fallida de la primera identificación (ID1)
    -
    generación de datos para la transmisión a uno de los dos terminales (E1, E2), conteniendo los datos los datos de transacción y una instrucción para el inicio de un segundo proceso de autorización (AV2) por uno de los dos terminales (E1, E2) por un segundo canal de transmisión (K2), siendo recibidos los datos de la transacción por el segundo canal de transmisión (K2) mediante el dispositivo de autorización y
    15 comprendiendo la generación de los datos por el dispositivo de autorización (A) una detección de las propiedades del hardware del primer o del segundo terminal y una adaptación de los datos a las propiedades del hardware detectadas.
  9. 10. Dispositivo de autorización de acuerdo con la reivindicación 9, comprendiendo el segundo proceso de
    20 autorización (AV2) una etapa para la detección de una segunda identificación (ID2), estando asignada la segunda identificación (ID2) al terminal (E2) que inicia el segundo proceso de autorización (AV2), e identificando la segunda identificación (ID2) el terminal (E2) que inicia el segundo proceso de autorización (AV2).
  10. 11. Dispositivo de autorización de acuerdo con la reivindicación 9 ó 10, comprendiendo el segundo
    25 proceso de autorización (AV2) una etapa para la detección de una autorización de transacción, dependiendo la autorización de transacción de la segunda identificación (ID2).
  11. 12. Dispositivo de autorización de acuerdo con una de las reivindicaciones 9 a 11, comprendiendo la detección de la segunda identificación (ID2) una consulta a un dispositivo de servidor y una recepción de la segunda
    30 identificación (ID2) desde el dispositivo de servidor, siendo recibida la segunda identificación (ID2) por el dispositivo de autorización (A) por el segundo canal de transmisión.
  12. 13. Dispositivo de autorización de acuerdo con una de las reivindicaciones 9 a 12, comprendiendo la detección de las propiedades del hardware una detección de las propiedades del hardware del dispositivo de
    35 visualización del primer o del segundo terminal, siendo el segundo terminal un terminal móvil, preferiblemente un terminal móvil con funcionalidad SMS y funcionalidad de telefonía.
  13. 14. Dispositivo de autorización de acuerdo con una de las reivindicaciones 9 a 13, difiriendo el primer canal de transmisión (K1) del segundo canal de transmisión (K2), siendo el primer canal de transmisión (K1) un
    40 canal de datos WAP o un canal de datos IP y siendo el segundo canal de transmisión (K2) un canal de mensajes cortos de telefonía móvil.
ES09756471T 2008-12-01 2009-11-16 Procedimiento para la autorización de una transacción por varios canales Active ES2434743T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102008059723 2008-12-01
DE102008059723 2008-12-01
PCT/EP2009/065260 WO2010063563A2 (de) 2008-12-01 2009-11-16 Verfahren und einrichtung zur autorisierung einer transaktion

Publications (1)

Publication Number Publication Date
ES2434743T3 true ES2434743T3 (es) 2013-12-17

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 After (1)

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

Country Status (4)

Country Link
EP (2) EP2637382B1 (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
MXPA02006941A (es) * 2000-02-05 2002-11-29 Diebold Inc Sistema y metodo para surtir informacion digital desde una maquina de transaccion automatizada.
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
EP2371105A2 (de) 2011-10-05
EP2637382B1 (de) 2016-02-24
WO2010063563A3 (de) 2010-12-09
EP2637382A2 (de) 2013-09-11
EP2371105B1 (de) 2013-08-14
EP2637382A3 (de) 2014-04-02
ES2569732T3 (es) 2016-05-12
DE102009056116B4 (de) 2016-08-18
DE102009056116A1 (de) 2010-09-16
WO2010063563A2 (de) 2010-06-10

Similar Documents

Publication Publication Date Title
US10911951B2 (en) Methods and systems for validating mobile devices of customers via third parties
US8494958B2 (en) Method and system to process payment using URL shortening and/or QR codes
CN102754116B (zh) 基于令牌的交易认证
US9264880B2 (en) Payment authentication systems
US10230727B2 (en) Method and system for authenticating a user
US20180114221A1 (en) Secure payment
US20110217994A1 (en) Systems and Methods to Automate Transactions via Mobile Devices
US20120089521A1 (en) Method and apparatus for billing purchases from a mobile phone application
US10212154B2 (en) Method and system for authenticating a user
CN106875177A (zh) 订单处理方法、装置及支付服务器
US8751389B2 (en) Method and system to process payment using SMS messaging and a mobile-optimized web form
US20150100483A1 (en) Method and system of using smartlinks for constituent/consumer data updating
KR20110046989A (ko) 모바일단말기를 이용한 본인인증 처리방법
ES2434743T3 (es) Procedimiento para la autorización de una transacción por varios canales
JP2006268641A (ja) 認証方法及び認証システム
US20140372303A1 (en) Online Authentication and Payment Service
KR101291492B1 (ko) 가입자식별모듈을 구비한 이동통신 단말의 개통 방법
US11257063B2 (en) Telephone call purchase with payment using mobile payment device
KR20090012904A (ko) Ｒｆｉｄ 태그를 이용한 컨텐츠 제공 시스템 및 방법
EP3220335A1 (en) Method, first, second server and system for accessing a service
KR20110036481A (ko) 메시징 기반 무선 결제 방법
CN114140110A (zh) 支付方法、装置、电子设备和存储介质
KR20110036341A (ko) 메시징 기반 무선 결제 방법 및 시스템
KR20050005384A (ko) 디지털 컨텐츠 고유번호 부여를 통한 결제 방법
WO2015162188A1 (en) Secure service activation