ES2951585T3 - Autenticación de transacciones usando un identificador de dispositivo móvil - Google Patents

Autenticación de transacciones usando un identificador de dispositivo móvil Download PDF

Info

Publication number
ES2951585T3
ES2951585T3 ES11849728T ES11849728T ES2951585T3 ES 2951585 T3 ES2951585 T3 ES 2951585T3 ES 11849728 T ES11849728 T ES 11849728T ES 11849728 T ES11849728 T ES 11849728T ES 2951585 T3 ES2951585 T3 ES 2951585T3
Authority
ES
Spain
Prior art keywords
mobile device
payment
transaction
complementary
payment gateway
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
ES11849728T
Other languages
English (en)
Inventor
Simon Law
Dennis Poon
Richard Burnison
Jerry Bokser
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.)
Salt Tech Inc
Original Assignee
Salt Tech Inc
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 Salt Tech Inc filed Critical Salt Tech Inc
Application granted granted Critical
Publication of ES2951585T3 publication Critical patent/ES2951585T3/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/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • 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/407—Cancellation of a transaction
    • 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Landscapes

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

Abstract

Se proporcionan sistemas y métodos para autenticar una transacción a través de un dispositivo móvil. Durante el registro, el dispositivo móvil recibe una ID de pago de una cuenta de pago y una ID suplementaria para verificar la ID de pago, y la transmite a una pasarela de pago. La pasarela de pago envía la identificación de pago y la identificación complementaria a un módulo de verificación para verificar las identificaciones. Después de que la pasarela de pago recibe un resultado de verificación, se genera una ID de dispositivo móvil y se almacena en el dispositivo móvil y se almacena en la pasarela de pago en asociación con la ID de pago. En una transacción, un usuario solo necesita ingresar la ID suplementaria en el dispositivo móvil, ya que la ID suplementaria y la ID del dispositivo móvil se pueden enviar a la pasarela de pago para recuperar la ID de pago asociada. Esta información es suficiente para autenticar y ejecutar la transacción. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Autenticación de transacciones usando un identificador de dispositivo móvil
Campo técnico:
Lo siguiente se refiere en general a la realización de transacciones a través de un dispositivo móvil.
Descripción de la técnica relacionada
Se reconoce que la experiencia de usuario para llegar a un sitio web de pago o página web de pago puede ser engorrosa y que la experiencia de usuario puede implicar muchas entradas de usuario para hacer una transacción.
A diferencia de los ordenadores personales, que permiten la finalización rápida de transacciones basadas en sitios web multietapa a través de diversos dispositivos de entrada humana, tal como un ratón de ordenador y un teclado, dispositivos móviles (por ejemplo, teléfonos móviles, asistentes digitales personales, ordenadores portátiles, ordenadores de tipo tableta, y otros dispositivos inalámbricos), que a menudo tienen solo un dispositivo de entrada, ofrecen una experiencia lenta y frustrante al completar transacciones basadas en sitios web. Además, tener que proporcionar datos a numerosos vendedores o proveedores de servicios múltiples veces es inconveniente, propenso a errores, y en última instancia es menos seguro.
Algunos enfoques han intentado resolver este problema haciendo que la transacción se complete en un solo “clic” almacenando los datos relevantes en el sistema de servidor. Aunque tal enfoque puede aliviar a los usuarios de tener que proporcionar datos múltiples veces, un usuario de dispositivo móvil puede indicar accidentalmente una intención de completar una transacción. Tales accidentes pueden ser altamente inconvenientes y costosos, ya que la transacción puede ser irreversible o de otro modo no puede cancelarse. Como mínimo, es frustrante y lento intentar revertir la transacción accidental.
Otros enfoques, tales como “asistentes de formulario” y almacenamientos de contraseñas, intentan resolver el problema almacenando datos relevantes guardando valores introducidos previamente en un almacenamiento persistente. Desafortunadamente, algunos almacenamientos de contraseñas y asistentes de formulario son inseguros, quizás almacenando contraseñas en texto sin formato o usando cifrado débil, estando mal programadas y exponiendo diversas vulnerabilidades, o sin requerir una contraseña. Tales características inseguras pueden permitir a usuarios no autorizados del dispositivo tener acceso sin restricciones a los valores almacenados. Adicionalmente, este mecanismo puede no funcionar a través de múltiples vendedores o proveedores de servicios, ya que cada vendedor o proveedor de servicios puede requerir diferentes representaciones o formularios de datos.
A menudo, las transacciones basadas en sitios web se autentican usando solo un factor de autenticación, tal como un nombre de usuario y una contraseña. Además, algunas transacciones basadas en sitios web enmascaran la autenticación de factor único como autenticación de múltiples factores solicitando múltiples elementos de información del mismo factor de autenticación, tal como solicitar tanto un número de tarjeta de crédito como una contraseña. En tal escenario, proporcionar un número de tarjeta de crédito no es prueba suficiente de tener posesión de una tarjeta de crédito específica; más bien, simplemente se conoce el número de tarjeta de crédito. Un elemento testigo de tipo token compartido, tal como un número de tarjeta de crédito, que se proporciona a cualquier número de terceros, no tiene acceso controlado razonablemente; por lo tanto, un número de tarjeta de crédito no es un factor razonable de autenticación.
También se reconoce que el diseño tradicional y la implementación de sistemas de comercio electrónico y comercio desde teléfono móvil a menudo se componen de servidores y partes separados, y tal separación carece de mecanismos para indicar y propagar una alerta de que se ha producido un ataque, poniendo potencialmente a todas las partes en riesgo.
También hay sistemas de cliente no seguros y dispositivos móviles, tales como aquellos con defectos de seguridad en navegadores de cliente o bibliotecas de sistemas relacionados o aquellos infectados con virus, troyanos, registradores de teclas, o malware similar, que puede permitir que un adversario intercepte, u obtenga de otro modo, información sensible o identificable personalmente, tales como números de tarjeta de crédito, números de tarjeta de salud, números de licencia de conductor, etc. Tal información robada puede dar como resultado una pérdida financiera o de reputación, puede usarse para cometer otros crímenes, o puede usarsejunto con cualquier número de actividades no autorizadas, potencialmente ilegales. Tal información también puede ser robada mediante el robo físico de un dispositivo móvil.
De manera similar, sistemas de servidor no seguros, tales como aquellos con controles de acceso físico inadecuados, servidores, aplicaciones, y/o cortafuegos mal configurados, almacenamiento de datos no seguro, períodos de retención prolongados innecesarios, y/o cifrado débil o inexistente, etc., ponen los datos del titular de tarjeta en riesgo de compromiso. En un intento por eliminar tales prácticas inseguras, algunos compradores y procesadores de compra requieren, antes de otorgar a un comerciante una licencia de procesamiento de tarjeta de crédito, que los comerciantes sean certificados por PCI-DSS (Estándares de Seguridad de Datos para la Industria de Tarjeta de Pago). Aunque tanto los comerciantes como los titulares de tarjeta obtienen los beneficios de la certificación PCI-DSS, algunos comerciantes pueden no ser capaces o no estar dispuestos a pagar los fondos asociados involucrados en el proceso de certificación de PCI-DSS (tales como costes para pruebas de penetración, compra o renovación de certificados SSL, implementación de controles de acceso físico adecuados, cambio de los sistemas existentes para el cumplimiento, etc.).
Desde la perspectiva de un usuario, cuando se suscribe a, o hace negocios con, muchos sitios web diferentes, un usuario recopilará rápidamente numerosas cuentas, que consisten habitualmente en una identidad (a menudo denominada “nombre de usuario”) y una contraseña. Aunque esto podría dar como resultado favorablemente una fuerte compartimentación (dado que cada cuenta podría tener una fuerte, contraseña única), algunos usuarios se ven sobrecargados con el número de contraseñas que necesitan recordar. En efecto, algunos usuarios eligen contraseñas simples para adivinar o reutilizar la misma contraseña para múltiples cuentas. Desafortunadamente, esto puede dar como resultado que la cuenta del usuario se vea comprometida, lo que puede provocar robo de identidad, pérdidas económicas, u otras consecuencias desfavorables similares.
Desde otra perspectiva, comerciantes, también, al aceptar tarjetas de crédito, pueden ser víctima de actividades fraudulentas, lo que puede dar como resultado una pérdida financiera, pérdida de reputación, o una revocación de su licencia de procesamiento. Típicamente, los comerciantes que eligen aceptar transacciones de tarjetas de crédito desde su sitio web son en última instancia susceptibles económicamente de aceptar transacciones fraudulentas. Para frustrar tales transacciones fraudulentas, los comerciantes tienen la opción de usar un método llamado 3D Secure (algunas implementaciones bien conocidas están disponibles bajo las marcas comerciales VISA verificadas por Visa, MasterCard SecureCode de MasterCard, y J/Secure de JCB International). Este método, que se describe en el artículo “3-D Secure? Mobile Autentication Scenarios”, VISA, 30 de junio de 2002 (30-06-2002), cambia de manera efectiva la responsabilidad financiera al emisor del titular de tarjeta de crédito, y posiblemente al titular de tarjeta de crédito. Aunque esto reduce los riesgos financieros asumidos por comerciantes, algunos comerciantes pueden haber elegido no hacer uso de 3D Secure debido a un componente ampliamente criticado de algunas implementaciones de 3D Secure.
Un componente en gran parte criticado de 3D Secure ha sido la aparición de restricciones de implementación relajadas, empeoradas aún más por las decisiones de implementación de emisor. El protocolo 3D Secure permite a cada comerciante decidir cómo presentar la página web de autenticación de emisor del titular de tarjeta de crédito (en particular, mediante el uso de cuadros en línea (“iframe”), ventanas emergentes, o redireccionamientos del navegador). Como consecuencia, “phishing", o la recolección o recogida sin escrúpulos de datos sensibles de usuarios desprevenidos, se convierte en un riesgo para el titular de tarjeta de crédito.
El documento WO 2008/103882 A2 describe métodos y sistemas para registrar un dispositivo móvil para su uso en un sistema de comercio desde teléfono móvil. El método puede comprender recibir en un sistema de proveedor de servicios una solicitud de registro de un usuario del dispositivo móvil. Se puede determinar con el sistema de proveedor de servicios si permitir el registro del dispositivo móvil. En respuesta a la determinación de permitir el registro del dispositivo móvil, la solicitud de registro puede enviarse desde el sistema de proveedor de servicios a un sistema adquirente.
El documento CA 2730175 A1 describe un sistema y un método para registrar un dispositivo inalámbrico y ejecutar una transacción de fondos desde una cuenta de terceros a una cuenta de prepago. El dispositivo inalámbrico está en comunicación segura con un servidor de administración a través de una red. El servidor de administración está en comunicación con la entidad de terceros, a través de un servidor de entidad de terceros, así como con un servidor de prepago. En el proceso de registro inicial, el usuario proporciona las credenciales para acceder a la cuenta de terceros usando el dispositivo inalámbrico. Las credenciales se almacenan en el dispositivo inalámbrico, servidor de administración, o ambos.
A partir de lo anterior se puede entender que los métodos y sistemas para aumentar la seguridad durante transacciones de comercio electrónico y comercio desde teléfono móvil son altamente deseables.
Breve descripción de los dibujos
Realizaciones de la invención o invenciones se describirán ahora a modo de ejemplo solo con referencia a los dibujos adjuntos en los que:
La figura 1 es un diagrama esquemático de una realización de ejemplo de un sistema para autenticar una transacción iniciada por un dispositivo móvil.
La figura 2 es un diagrama esquemático de una realización de ejemplo del sistema de la figura 1 que muestra qué componentes de datos están almacenados en el dispositivo móvil, la pasarela de pago, el servidor complementario, y el servidor de pago, y el movimiento de datos entre los mismos.
La figura 3 es un diagrama esquemático de una realización de ejemplo que muestra la transferencia de información entre la pasarela de pago, el servidor complementario y el servidor de pago, para autenticar una transacción.
La figura 4 es un diagrama esquemático de otra realización de ejemplo que muestra la transferencia de información entre la pasarela de pago, el servidor complementario y el servidor de pago, para autenticar una transacción.
La figura 5 es un diagrama esquemático de otra realización de ejemplo que muestra la transferencia de información entre la pasarela de pago, el servidor complementario y el servidor de pago, para autenticar una transacción.
La figura 6 es un diagrama esquemático de otra realización de ejemplo que muestra la transferencia de información entre la pasarela de pago, el servidor complementario y el servidor de pago, para autenticar una transacción.
La figura 7 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para registrar un dispositivo móvil en asociación con una ID de pago.
La figura 8 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción después del registro que se muestra en la figura 7.
La figura 9 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para registrar un dispositivo móvil en asociación con una ID de pago usando un valor de número de un solo uso.
La figura 10 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción después del registro que se muestra en la figura 9.
La figura 11 es una captura de pantalla de una GUI de ejemplo para un dispositivo móvil que recibe información de registro de un usuario.
La figura 12 es una captura de pantalla de una GUI de ejemplo para un dispositivo móvil que recibe una ID complementaria que comprende un número CVV durante un proceso de transacción.
La figura 13 es una captura de pantalla de un ejemplo de GUI para un dispositivo móvil que recibe una ID complementaria que comprende una contraseña para 3D Secure durante un proceso de transacción.
La figura 14 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para registrar un dispositivo móvil en asociación con una ID de pago.
La figura 15 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción después del registro que se muestra en la figura 14.
La figura 16 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para generar una firma digital.
La figura 17 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para usar la firma digital de la figura 16 para liquidar una disputa de devolución de cargos con respecto a una transacción.
La figura 18 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo de otra realización de ejemplo para generar una firma digital y usarla para liquidar una disputa de devolución de cargos.
La figura 19 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo de una realización de ejemplo para generar códigos de autenticación de mensajes (MAC) y usar los MAC para liquidar una disputa de devolución de cargos.
La figura 20 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para registrar una ID de dispositivo móvil y generar una clave privada.
La figura 21 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción usando una firma digital firmada por la clave privada, después del registro que se muestra en la figura 20.
La figura 22 es un diagrama de flujo que ilustra otro conjunto de instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción usando una firma digital firmada por la clave privada, después del registro que se muestra en la figura 20.
La figura 23 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para verificar una ID de pago y una ID complementaria durante un proceso de registro, con un dispositivo móvil que envía la ID complementaria directamente a un módulo de verificación.
La figura 24 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción con el dispositivo móvil que envía la ID complementaria directamente al módulo de verificación, después del registro que se muestra en la figura 23.
La figura 25 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción y almacenar una ID complementaria para una transacción posterior.
La figura 26 es un diagrama esquemático de otra realización de ejemplo de un sistema para autenticar una transacción iniciada por un dispositivo móvil.
La figura 27 es un diagrama esquemático que ilustra componentes de ejemplo de un dispositivo móvil.
La figura 28 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para adquirir datos para iniciar un sitio web de pago.
La figura 29 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para adquirir datos para iniciar un sitio web con respecto a la selección de parámetros para un producto o servicio, antes de iniciar un sitio web de pago para el mismo.
La figura 30 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para adquirir datos relacionados con uno o más productos o servicios, obtener una dirección de red relacionada con los datos adquiridos, e iniciar el sitio web de pago para el pago de uno o más productos o servicios.
La figura 31 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para usar datos de código de barras para iniciar un sitio web de pago.
La figura 32 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para usar datos de imagen para iniciar un sitio web de pago.
La figura 33 es un diagrama de flujo que ilustra instrucciones ejecutables por ordenador de ejemplo para usar datos de audio para iniciar un sitio web de pago.
Descripción detallada
Se apreciará que, por simplicidad y claridad de ilustración, cuando se considere apropiado, los números de referencia pueden repetirse entre las figuras para indicar elementos correspondientes o análogos. Además, se exponen numerosos detalles específicos para proporcionar una comprensión exhaustiva de las realizaciones de ejemplo descritas en el presente documento. Sin embargo, los expertos en la técnica entenderán que las realizaciones de ejemplo descritas en el presente documento pueden ponerse en práctica sin estos detalles específicos. En otros casos, métodos bien conocidos, procedimientos y componentes no se han descrito en detalle para no complicar las realizaciones de ejemplo descritas en el presente documento. Además, la descripción no debe considerarse como limitante del alcance de las realizaciones de ejemplo descritas en el presente documento.
Los sistemas y métodos propuestos autentican una transacción de comercio desde teléfono móvil o comercio electrónico que se origina desde un dispositivo móvil. El comercio desde teléfono móvil o el comercio móvil en el presente documento se refieren a cualquier transacción, implican la transferencia de propiedad o derechos para usar bienes y servicios, que se inicia o se completa, o ambos, mediante el uso de acceso móvil a redes mediadas por ordenador con la ayuda de un dispositivo electrónico. El e-comercio, o el comercio electrónico, en el presente documento se refiere a la compra y venta de productos o servicios a través de sistemas electrónicos tales como Internet y otras redes informáticas.
Generalmente, una transacción, como se describe en el presente documento, incluye un proceso de autenticación y un proceso de liquidación. El proceso de autenticación se usa para autenticar información de pago. Al autenticar la información de pago, en el proceso de liquidación, una cantidad de valor (por ejemplo, dinero, puntos, crédito, etc.) se mueve de una cuenta de valor a otra. Existen múltiples métodos y sistemas de liquidación, que pueden usarse en combinación con los principios descritos en el presente documento. Los sistemas y métodos propuestos se refieren a autenticar la información de pago como parte de la transacción.
Los sistemas y métodos propuestos también proporcionan una experiencia de compra más fluida usando un dispositivo móvil. El dispositivo móvil adquiere datos, tal imagen de código de barras, una imagen de un objeto o texto, o datos de audio. Un ejemplo no limitante de un código de barras es un código de barras de respuesta rápida (QR). Los datos adquiridos se usan a continuación para obtener una dirección de red de un sitio web o página web de pago, lo que permite a un usuario hacer una compra para un producto o servicio dado. A continuación, el dispositivo móvil inicia el sitio web o página web de pago. Tales sistemas y métodos pueden combinarse con otros principios descritos en el presente documento.
En los sistemas y métodos propuestos, el dispositivo móvil experimenta un proceso de registro y un proceso de transacción. El proceso de registro implica una identificación asociada de manera única con el dispositivo móvil que se está registrando y almacenando en un sistema de servidor y almacenando, ya sea de forma activa o inherente, en el propio dispositivo móvil. La identificación del dispositivo móvil se denomina en el presente documento ID de dispositivo móvil. La ID de dispositivo móvil puede o no generarse basándose en características del dispositivo móvil. El proceso de registro también implica verificar la información de pago y asociar la ID de dispositivo móvil con la información de pago. La información de pago incluye, por ejemplo, un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, un número de tarjeta de débito, una ID de tarjeta de regalo, una ID de tarjeta de prepago, número de cuenta de puntos, etc. En general, cualquier información de este tipo usada por el vendedor para identificar una cuenta de pago puede denominarse en el presente documento ID de pago. La información de pago, o ID de pago, se verifica usando información complementaria. Ejemplos no limitantes de tal información complementaria incluyen un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), o una verificación de código de tarjeta (CCV). Otros ejemplos no limitantes de información complementaria para verificar adicionalmente una ID de pago también incluyen pines o contraseñas asociados con los protocolos 3D Secure. La información complementaria también puede ser un pin de tarjeta de débito, un pin de EMV, una contraseña bancaria en línea, o similares. La información complementaria también puede derivarse de, o ser un formulario de, datos biométricos (por ejemplo, datos de voz, huellas dactilares, escaneo ocular, etc.).
En una realización de ejemplo, información complementaria puede incluir que un usuario diga una contraseña o diga algunos sonidos. El reconocimiento de voz, o en ambos casos, a continuación, se usa para determinar que se dicen la palabra o palabras correctas. En otra realización, el reconocimiento de la persona que habla o el reconocimiento de voz se utilizan para analizar las características de la voz del usuario (por ejemplo, frecuencia) para garantizar que el usuario es el verdadero usuario autorizado de la ID de pago.
Otra información complementaria para verificar la ID de pago se puede aplicar a los principios descritos en el presente documento, y tal información complementaria se denomina en el presente documento ID complementaria.
En una realización de ejemplo, la ID complementaria y la ID de pago no se almacenan de manera permanente en el dispositivo móvil, dada la sensibilidad y el alto valor de seguridad de tales datos. El sistema de servidor, sin embargo, almacena al menos la ID de pago y la ID de dispositivo móvil en asociación entre sí.
En otra realización de ejemplo, la ID complementaria o la ID de pago pueden almacenarse en el dispositivo móvil. Puede haber, por ejemplo, condiciones que determinan cómo se almacenan la ID complementaria y la ID de pago.
Se puede apreciar que la ID de dispositivo móvil no es necesario que se almacene activamente en el dispositivo móvil, si la ID de dispositivo móvil se genera a partir de características inherentes del dispositivo móvil. Por lo tanto, la ID de dispositivo móvil puede recuperarse del dispositivo móvil simplemente identificando los valores de las características inherentes del dispositivo móvil.
Tras completar el proceso de registro, (por ejemplo, registrar la ID de dispositivo móvil y verificar la ID de pago y la ID complementaria), se puede iniciar una transacción usando el dispositivo móvil. Después de que el dispositivo móvil recibe la ID complementaria de un usuario, el dispositivo móvil envía la ID de dispositivo móvil (almacenada en el dispositivo móvil) y la ID complementaria al sistema de servidor. En otras palabras, solo se requiere la ID complementaria como datos de entrada de usuario para iniciar y verificar una transacción. El sistema de servidor, basándose en la ID de dispositivo móvil, recupera la ID de pago asociada, y luego, usando la combinación de la ID de pago y la ID complementaria, es capaz de iniciar la verificación de la ID de pago. Si la ID de pago se verifica con éxito, se ejecuta la transacción (por ejemplo, se liquida la transacción). A continuación se describen detalles adicionales con respecto a los procesos de registro y transacción.
Se puede apreciar que una transacción inicial se puede combinar con el proceso de registro, mediante lo cual la información suministrada en el registro también se usa para ejecutar la transacción inicial. Sin embargo, transacciones adicionales posteriores al registro combinado y la transacción inicial pueden usar los métodos y sistemas propuestos descritos en el presente documento (por ejemplo, un usuario que solo suministra una ID complementaria).
Aunque los siguientes ejemplos se presentan en el contexto de dispositivos de comunicación móviles, los principios pueden aplicarse igualmente a otros dispositivos tales como aplicaciones que se ejecutan en ordenadores personales y similares cuando sea apropiado.
Para mayor claridad en la discusión a continuación, los dispositivos de comunicación se denominarán comúnmente “dispositivos móviles”. Ejemplos de dispositivos móviles aplicables incluyen buscapersonas, teléfonos celulares, teléfonos inteligentes celulares, organizadores inalámbricos, asistentes digitales personales, ordenadores, ordenadores portátiles, ordenadores de tipo tableta, dispositivos de comunicación inalámbrica de mano, ordenadores portátiles con capacidad inalámbrica y similares.
En una realización típica, el dispositivo móvil es un dispositivo de comunicación bidireccional con capacidades de comunicación de datos avanzadas que incluyen la capacidad de comunicarse con otros dispositivos móviles o sistemas informáticos a través de una red de estaciones transceptoras. El dispositivo móvil también puede tener la capacidad de permitir la comunicación de voz. Dependiendo de la funcionalidad proporcionada por el dispositivo móvil, puede denominarse dispositivo de mensajería de datos, un buscapersonas bidireccional, un teléfono móvil con capacidades de mensajería de datos, un aparato inalámbrico con acceso a Internet, o un dispositivo de comunicación de datos (con o sin capacidades de telefonía).
Además, el uso de los términos “servidor”, “sistema de servidor”, y similares, se refieren a dispositivos informáticos que pueden comprender uno o más servidores que están conectados en red entre sí. Adicionalmente, las funciones de diversos servidores como se describe en el presente documento pueden combinarse en un único servidor o sistema de servidor. Se aprecia que los servidores y dispositivos móviles tienen memoria para almacenar datos e instrucciones ejecutables por ordenador y procesadores para ejecutar las mismas.
Volviendo a la figura 1, se proporciona una realización de ejemplo del sistema de transacción. Un dispositivo móvil 10 se muestra en comunicación con un sistema de servidor 8, por ejemplo, a través de una conexión de red 2 y una pasarela inalámbrica 4. Ejemplos no limitantes de una pasarela inalámbrica 4 incluyen un rúter inalámbrico 802.11, GGSN (pasarela de nodo de soporte GPRS), PDSN (nodo de servicio de datos en paquetes), u otro componente similar que sirve como punto de acceso a otra red. La pasarela inalámbrica 4 permite que el dispositivo móvil 10 interactúe, ya sea directa o indirectamente, con el sistema de servidor 8. La pasarela inalámbrica 4 interactúa con el sistema de servidor 8 a través de la conexión de red 6. El sistema de servidor 8 se denomina en el presente documento pasarela de pago o servidor de comerciante, ya que opera en una cadena entre una interfaz de consumidor (por ejemplo, el dispositivo móvil 10) y una entidad de pago, representada por el servidor de pago 20. En una realización de ejemplo, la pasarela de pago 8 facilita la autorización de pagos, facilita el acceso a los comerciantes, y llama a funciones de un servidor de pago 20. Se puede apreciar que los términos “pasarela de pago” y “servidor de comerciante” se usan en el presente documento de manera intercambiable. Como se discutirá con más detalle a continuación, la pasarela de pago o servidor de comerciante 8 tiene bases de datos 12 y 14 para almacenar información sobre dispositivos móviles y cuentas de pago, respectivamente. Sin embargo, la organización y el número de bases de datos pueden variar. Una realización de ejemplo de tal pasarela de pago o servidor de comerciante 8 se proporciona por Xtreme Mobility Inc. o Admeris Payment Systems Inc.
Continuando con la figura 1, la pasarela de pago 8 está en comunicación con un servidor de pago 20 a través de una conexión de red 16. El servidor de pago 20 está asociado con una entidad de pago (no mostrada) que sirve para procesar un pago o transacción usando métodos de comercio desde teléfono móvil y comercio electrónico. En un aspecto, el servidor de pago 20 transfiere una cantidad de valor (por ejemplo, dinero, puntos, crédito, etc.) de la cuenta de valor de un usuario (identificada por una ID de pago) a otra entidad (por ejemplo, a cambio de bienes, productos, servicios, etc.). Ejemplos no limitantes de entidades de pago incluyen servicios de tarjeta de crédito (por ejemplo, Visa, MasterCard, American Express, etc.), organizaciones bancarias, y servicios bancarios de terceros (por ejemplo, Moneris, First Data). En otra realización, el servidor de pago 20 es el propio banco adquirente, que recibe el pago del valor de la cuenta de valor del usuario. Más generalmente, un servidor de pago 20 carga la cuenta de valor del usuario a cambio de un servicio o bien. Por lo tanto, el servidor de pago 20 se denomina indistintamente el adquirente.
La pasarela de pago 8 también está en comunicación con un servidor complementario 22 a través de una conexión de red 18. El servidor complementario 22 aloja un módulo de verificación 23, que verifica la ID complementaria y la ID de pago. Realizaciones de ejemplo de tales sistemas de verificación incluyen un servidor CVV o CSV 24, que contiene una base de datos 26 para almacenar valores de CVV y CSV (por ejemplo, ID complementarias) y números de cuenta de tarjeta de crédito asociados (por ejemplo, ID de pago). Alternativamente, o adicionalmente en combinación, el servidor 24 puede ser un servidor 3D Secure y la base de datos 26 puede contener contraseñas 3D Secure (por ejemplo, ID complementarias) y números de cuenta de tarjeta de crédito asociados (por ejemplo, ID de pago). En otra realización de ejemplo, un servidor bancario 28 contiene una base de datos 30 que almacena información de cuenta bancaria (por ejemplo, ID de pago) y una contraseña (por ejemplo, ID complementarias). En otra realización de ejemplo, un servidor de verificación 32 obtiene datos (por ejemplo, ID complementarias) de un usuario a través del dispositivo móvil 10 a través del proceso de recuperación 34, mediante lo cual los datos se almacenan en asociación con las ID de pago. Ejemplos de tales datos pueden incluir datos de voz, datos biométricos (por ejemplo, huellas dactilares, escaneo ocular, etc.), Datos de GPS, etc. Por ejemplo, en el proceso de recuperación 34, el servidor 32 se pone en contacto con el usuario a través del dispositivo móvil 10 y le pide al usuario su color favorito. Tales datos o ID complementarias se almacenan en asociación con la información de pago en el servidor complementario 22.
El servidor complementario 22 también se considera el emisor, que emite una cantidad de valor desde la cuenta de valor del usuario. En otras palabras, la cuenta de valor del usuario se almacena o se controla por el servidor complementario 22, también denominado indistintamente emisor. Un ejemplo de un emisor de este tipo podría ser una entidad de tarjeta de crédito (por ejemplo, Visa, MasterCard), un banco, o cualquier otra entidad que tenga una cantidad de valor en la cuenta de valor de un usuario.
En otra realización de ejemplo, el servidor complementario 22 (por ejemplo, el emisor) puede estar en comunicación con el servidor de pago 20 (por ejemplo, el adquirente), y no es necesario que se comunique a través de la pasarela de pago 8. El servidor complementario 22 y el servidor de pago 20 pueden comunicarse entre sí a través de la red 21. Por ejemplo, si el servidor complementario 22 es una cuenta de crédito Visa (por ejemplo, el emisor) y el servidor de pago 20 es un banco de minorista (por ejemplo, el adquirente), entonces la red 21 es VisaNet.
En otra realización de ejemplo, las operaciones y funciones del servidor complementario 22 y el servidor de pago 20 pueden combinarse en un sistema de servidor unificado. En otra realización de ejemplo, las funciones y operaciones de la pasarela de pago 8 y el servidor de pago 20 pueden combinarse en un sistema de servidor unificado. En otra realización de ejemplo, las funciones y operaciones de la pasarela de pago 8 y el servidor complementario 22 pueden combinarse en un sistema de servidor unificado. En otra realización de ejemplo más, las funciones y operaciones de todos los servidores 8, 20 y 22 pueden combinarse en un sistema de servidor unificado. También se aprecia que las conexiones 6, 16 y 18 pueden ser inalámbricas o no inalámbricas (por ejemplo, por cable), o ambas.
En particular, con respecto a la realización de ejemplo donde las funciones y operaciones de la pasarela de pago 8 y el servidor de pago 20 se combinan en un sistema de servidor unificado, la pasarela de pago 8 (por ejemplo, ahora el adquirente) solicita una cantidad de valor del servidor complementario 22 (por ejemplo, el emisor).
Se puede apreciar que hay varios tipos de métodos de liquidación, donde el dinero puede transferirse o moverse entre varias entidades para liquidar cuentas.
Volviendo a la figura 2, se muestra otra realización de ejemplo del sistema de autenticación y transacción, incluyendo dónde se almacena información durante el registro y cómo se mueve la información de un dispositivo a otro durante una transacción. La información que se almacena como resultado del proceso de registro se muestra como parte de los almacenamientos de memoria, ilustrados en líneas continuas. La información que se transmite durante una transacción se ilustra en líneas punteadas o discontinuas. Uno o más dispositivos móviles 10A y 10N (por ejemplo, cada uno de los cuales pertenece a un usuario) puede comunicarse con la pasarela de pago 8. Tras la finalización del registro, cada dispositivo móvil 10A, 10N almacena en su memoria 36A, 36N, respectivamente, al menos una ID de dispositivo móvil. Otra información almacenada en la memoria de dispositivo móvil 36A, 36N puede ser una información de número de un solo uso y personal (por ejemplo, nombre, fecha de nacimiento, dirección, etc.). En una realización de ejemplo, un dispositivo móvil 10 no almacena la ID complementaria ni la ID de pago. Además, los almacenamientos de memoria de la pasarela de pago 8 contienen, para cada dispositivo móvil, al menos la ID de dispositivo móvil y la ID de pago correspondientes. Otra información puede incluir un número de un solo uso. En una realización de ejemplo, la pasarela de pago 8 no almacena la ID complementaria. En otra realización de ejemplo, tras el registro con éxito, también se confirma que la ID de pago y la ID complementaria se almacenan en el servidor complementario 22 o en el módulo de verificación 23, en la memoria 40. Del mismo modo, la memoria 40 del servidor complementario 22 también puede almacenar un número de un solo uso. El servidor de pago 20 almacena al menos las ID de pago para cada uno de los usuarios. Se aprecia que típicamente, la ID complementaria y la ID de pago se almacenan en el servidor complementario 22 antes del proceso de registro, y la ID de pago se almacena en el servidor de pago 20 antes del proceso de registro.
En una transacción, después de que se complete el registro y la información requerida se haya almacenado en el dispositivo móvil 10 y los servidores, el usuario puede iniciar un pago desde una cuenta de pago, como se identifica por la ID de pago registrado. En una realización de ejemplo, el usuario solo introduce la ID complementaria en el dispositivo móvil 10 (bloque 44) para completar la transacción y la autenticación. La ID de dispositivo móvil, recuperada automáticamente de la memoria 36A del dispositivo móvil, y la ID complementaria se transfiere desde el dispositivo móvil 10 a la pasarela de pago 8 (bloque 46). La pasarela de pago 8 recupera entonces la ID de pago, correspondiente a la ID de dispositivo móvil recibida, y envía tanto la ID complementaria como la ID de pago al módulo de verificación 23 en el servidor complementario 22 (bloque 50). Después de que el servidor complementario 22 (o módulo de verificación 23 en el mismo) verifique la ID de pago recibida y la ID complementaria son auténticas o correctas en comparación con las ID almacenadas en la memoria 40, a continuación, el servidor complementario 22 envía un resultado de verificación 50 de vuelta a la pasarela de pago 8. Si el resultado de verificación confirma que la ID complementaria proporcionada por el dispositivo móvil 10 es correcta o auténtica, a continuación, la pasarela de pago 8 envía el resultado de verificación y la ID de pago al servidor de pago 20 (bloque 52), permitiendo de este modo que el servidor de pago 20 complete el pago desde la cuenta de pago.
La figura 3, la figura 4, la figura 5 y la figura 6 muestran varias de otras realizaciones de ejemplo para autenticar un dispositivo móvil durante un proceso de transacción. Por brevedad y para no complicar la descripción de los diversos procesos de transacción, los procesos de transacción se describen en adelante desde la etapa después de que el usuario haya introducido su ID complementaria en el dispositivo móvil 10 y el dispositivo móvil 10 haya enviado la ID de dispositivo móvil y la ID complementaria a la pasarela de pago 8.
En la figura 3, durante el proceso de transacción, en el bloque 190, la pasarela de pago 8 envía la ID de pago y la ID complementaria al servidor complementario 22 (por ejemplo, el emisor). El bloque 190 también incluye una solicitud de verificación complementaria. El servidor complementario 22, tras recibir la solicitud de verificación complementaria y verificar las ID, envía un resultado de verificación a la pasarela de pago 8 (bloque 92). La pasarela de pago 8 envía entonces la ID de pago y el resultado de verificación (bloque 194) al servidor de pago 20 (por ejemplo, el adquirente).
El servidor de pago 20 envía entonces una solicitud de autorización para el pago, ID de pago y resultado de verificación al servidor complementario 22 (bloque 196). El servidor complementario 22, basado en el resultado de verificación y la ID de pago, a continuación, emite o envía un resultado de autorización para el pago al servidor de pago 20 (bloque 198). Esta realización es adecuada para su uso, por ejemplo, donde la ID complementaria es una contraseña 3D Secure y el servidor complementario 22 es una cuenta Visa que tiene sistemas y métodos verificados por Visa.
La figura 4 muestra otra realización de ejemplo en la que la pasarela de pago 8 envía la ID de pago, la ID complementaria, la solicitud de verificación complementaria, y la solicitud de autorización de pago al servidor complementario 22 (bloque 200). De vuelta, el servidor complementario 22 envía un resultado de verificación y un resultado de autorización para el pago de vuelta a la pasarela de pago 8 (bloque 202). La pasarela de pago 8 transfiere entonces la ID de pago y el resultado de autorización para el pago, y opcionalmente el resultado de verificación, al servidor de pago 20 (bloque 204).
La figura 5 muestra otra realización de ejemplo en la que la pasarela de pago 8 envía la ID de pago y la ID complementaria al servidor de pago 20 (bloque 206). El servidor de pago 20 envía entonces una solicitud de verificación complementaria, una solicitud de autorización de pago, la ID complementaria y la ID de pago al servidor complementario 22 (bloque 208). El servidor complementario 22, tras verificar las ID, genera un resultado de autorización para el pago y un resultado de verificación. El servidor complementario 22 envía entonces al menos el resultado de autorización para el pago, y opcionalmente el resultado de verificación, de vuelta al servidor de pago 20 (bloque 210). Esta realización de ejemplo es adecuada, por ejemplo, para una ID complementaria que es un CVV (o similar).
La figura 6 muestra otra realización de ejemplo de un proceso de transacción, donde la pasarela de pago 8 envía la ID de pago y la ID complementaria al servidor complementario 22 (bloque 212). Tras la verificación de las ID por parte del servidor complementario 22, el servidor complementario 22 emite un resultado de autorización para el pago y el resultado de verificación. Al menos el resultado de la autorización para el pago y la ID de pago se envían al servidor de pago 20, y opcionalmente el resultado de verificación también (bloque 214).
De lo anterior, por lo tanto, puede apreciarse que las ID pueden transferirse entre diversas entidades para que el servidor complementario verifique la ID complementaria y la ID de pago, y para transferir los fondos al servidor de pago 20.
Se apreciará que cualquier módulo o componente a modo de ejemplo en el presente documento que ejecute instrucciones u operaciones puede incluir o de otro modo tener acceso a medios legibles por ordenador tales como medios de almacenamiento, medios de almacenamiento informático, o dispositivos de almacenamiento de datos (retirables y/o no retirables) tales como, por ejemplo, discos magnéticos, discos ópticos, o cinta. Los medios de almacenamiento informáticos pueden incluir medios volátiles y no volátiles, retirables y no retirables implementados en cualquier método o tecnología para el almacenamiento de información, tales como instrucciones legibles por ordenador, estructuras de datos, módulos de programa, u otros datos, excepto señales de propagación transitorias por sí mismas. Ejemplos de medios de almacenamiento informático incluyen RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento óptico, casetes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar la información deseada y al que se pueda acceder mediante una aplicación, módulo, o ambos. Cualquiera de dichos medios de almacenamiento informático puede ser parte del dispositivo móvil 10, pasarela de pago 8, servidor de pago 20, servidor complementario 22, o combinaciones de los mismos, o accesible o conectable al mismo. Cualquier aplicación o módulo descrito en el presente documento puede implementarse usando instrucciones u operaciones legibles/ejecutables por ordenador que pueden almacenarse o mantenerse de otro modo en tales medios legibles por ordenador.
Ahora se analizarán detalles con respecto a las diferentes realizaciones de los procesos de registro y transacción.
La figura 7 y la figura 8 proporcionan instrucciones ejecutables por ordenador de ejemplo para una realización de ejemplo de un proceso de registro y un proceso de transacción, respectivamente. Volviendo a la figura 7, el registro comienza por el dispositivo móvil 10 que recibe al menos la ID complementaria y la ID de pago, por ejemplo, del usuario. El dispositivo móvil 10 también puede recibir información personal o ID, tal como nombre, fecha de nacimiento, dirección, etc. En el bloque 56, el dispositivo móvil 10 envía al menos la ID complementaria y la ID de pago a la pasarela de pago 8.
En una realización de ejemplo, el dispositivo móvil 10 no almacena la ID complementaria y la ID de pago. De esta manera, la seguridad de la ID de pago y la ID complementaria no están en riesgo, incluso si la seguridad del dispositivo móvil 10 está comprometida (por ejemplo, se roba o se accede por un adversario). Puede apreciarse que la información (por ejemplo, la ID de pago y la ID complementaria) pueden pasar a través del dispositivo móvil 10, pero no almacenarse en el dispositivo móvil 10, dado que tal información se considera información no persistente. De la misma manera, la ID complementaria puede tratarse como información no persistente en la pasarela de pago 8, de modo que la pasarela de pago 8 no almacena la ID complementaria. La información no persistente se guardaría en memoria volátil tanto en la pasarela de pago 8 como en el dispositivo móvil 10. En algunos casos, esto puede implicar intercambiar o diversas estrategias de memoria compartida.
En el bloque 58, la pasarela de pago 8 envía o reenvía la ID complementaria y la ID de pago al módulo de verificación 23 (por ejemplo, ubicado en el servidor complementario 22). La pasarela de pago 8 no almacena la ID complementaria. De esta manera, la seguridad de la ID complementaria no está en riesgo, incluso si la seguridad de la pasarela de pago 8 está comprometida. Además, la responsabilidad por el riesgo de seguridad se reduce para la pasarela de pago 8. En el bloque 60, el módulo de verificación 23 verifica si la ID complementaria y la ID de pago recibidas son correctas, por ejemplo, comparando los valores recibidos con los valores previamente almacenados de ID complementarias e ID de pago. En el bloque 62, el módulo de verificación 23 envía un mensaje a la pasarela de pago 8, que indica si la ID complementaria y la ID de pago recibidas por el dispositivo móvil 10 se han verificado con éxito. En el bloque 64, si los datos se han verificado con éxito, a continuación, la pasarela de pago 8 genera una primera ID de dispositivo móvil (ID1 de dispositivo móvil) y almacena la primera ID de dispositivo móvil y la ID de pago en asociación entre sí, por ejemplo, en la memoria 38. La primera ID de dispositivo móvil , por ejemplo, se genera aleatoriamente y puede incluir algún valor relacionado con el propio dispositivo móvil 10. La primera ID de dispositivo móvil se deriva de o incluye una característica o elemento inherente del dispositivo móvil 10. La pasarela de pago 8 envía a continuación la primera ID de dispositivo móvil (ID1 de dispositivo móvil) al dispositivo móvil 10 (bloque 66), de modo que el dispositivo móvil 10 pueda almacenar la primera ID de dispositivo móvil (bloque 68).
En otra realización de ejemplo, la ID de dispositivo móvil se genera antes de que la ID complementaria y la ID de pago se hayan verificado con éxito. En otra realización de ejemplo, la ID de dispositivo móvil puede generarse a partir de uno cualquiera o más del dispositivo móvil 10, la pasarela de pago 8, el servidor de pago 20, o el servidor complementario 22.
Volviendo a la figura 8, la transacción implica que el usuario, a través del dispositivo móvil 10, compruebe un artículo o servicio para su compra a un minorista de comercio electrónico o de comercio desde teléfono móvil. Por ejemplo, el sitio del minorista (por ejemplo, sitio web o de red) dirige automáticamente el dispositivo móvil 10 a la pasarela de pago 8. Por lo tanto, no se requiere que el minorista aloje los procesos de autenticación de pago y transacción en sus servidores o sitio web. En una realización de ejemplo, la transición desde el sitio web del minorista de comercio electrónico o de comercio desde teléfono móvil parece ser fluida, de modo que un usuario puede no darse cuenta de que el sitio web o servidor ha cambiado a la pasarela de pago 8.
También se puede apreciar que los sistemas y métodos descritos en el presente documento pueden, por ejemplo, operar en una interfaz de navegador web y no requiere que se instale una aplicación adicional en el dispositivo móvil.
Se puede apreciar que la cuenta del minorista y la cantidad de pago ya son conocidas, según lo proporcionado por el sitio web de comercio electrónico o de comercio desde teléfono móvil del minorista, y tal información también se puede pasar a través de la pasarela de pago 8 y al servidor de pago 20, de modo que el servidor de pago 20 puede hacer un pago desde la cuenta de pago del usuario a la cuenta del minorista para la cantidad de pago especificada. Sin embargo, el sistema de transacción como se especifica en el presente documento no requiere que el usuario introduzca en la cantidad de pago, la información del minorista, o la información de pago propia del usuario. La única información requerida para ser introducida en el dispositivo móvil desde el usuario es la ID complementaria.
En particular, en el bloque 70, el dispositivo móvil 10 accede a la pasarela de pago 8 y proporciona la ID1 de dispositivo móvil, a la pasarela de pago 8. En el bloque 72, la pasarela de pago 8 determina si ID de dispositivo móvil, está presente en la pasarela de pago. Si es así, en el bloque 74, la pasarela de pago 8 recupera la ID de pago asociada con la ID1 de dispositivo móvil. Si no, en el bloque 90, la pasarela de pago 8 inicia el proceso de registro. Continuando desde el bloque 74, en el bloque 76, el dispositivo móvil 10 recibe la ID complementaria (de la entrada de usuario) y envía la ID complementaria y la ID de dispositivo móvil, (recuperada de la memoria del dispositivo móvil) a la pasarela de pago 8. En una realización de ejemplo, el dispositivo móvil 10 no almacena la ID complementaria. En el bloque 78, la pasarela de pago 8 recupera la ID de pago asociada con ID1 de dispositivo móvil, y envía la ID de pago y la ID complementaria al módulo de verificación 23. En el bloque 80, el módulo de verificación determina si la ID complementaria y la ID de pago recibidas son correctas, por ejemplo, comparando la ID complementaria recibida y la ID de pago con la ID complementaria y la ID de pago almacenada en el servidor complementario 22. El módulo de verificación 23 envía los resultados de verificación, por ejemplo, un testigo de tipo token de seguridad, a la pasarela de pago 8. Si el resultado de verificación indica que la ID complementaria no está verificada o no es correcta, luego en el bloque 92, la pasarela de pago envía un mensaje al dispositivo móvil alertando de que la transacción no está aprobada. Si, sin embargo, las ID complementarias se verifican con éxito, luego en el bloque 82, la pasarela de pago 8 envía el resultado de verificación (enviado por el módulo de verificación 23) y la ID de pago al servidor de pago 20. En el bloque 84, el servidor de pago 8 autentica o determina si el resultado de verificación es exitoso y, si está autenticado, utiliza la ID de pago para ejecutar el pago. En el bloque 86, la pasarela de pago 8 genera una nueva ID de dispositivo móvil, ID2 de dispositivo móvil, que reemplaza a la ID1 de dispositivo móvil, y está asociada con la misma ID de pago. La pasarela de pago 8 almacena la ID2 de dispositivo móvil y envía la misma al dispositivo móvil 10. En el bloque 88, el dispositivo móvil 10 almacena la ID2 de dispositivo móvil, y puede eliminar la ID1 de dispositivo móvil. Se aprecia que se genera una nueva ID de dispositivo móvil durante cada transacción para reemplazar la ID de dispositivo móvil anterior para evitar ataques de reinyección. La nueva ID de dispositivo móvil (por ejemplo, ID2 de dispositivo móvil) se usará en la siguiente transacción como una comprobación de seguridad realizada por la pasarela de pago 8.
En una realización alternativa (bloque 94) para el proceso de transacción de la figura 8, en el bloque 80, después de que el módulo de verificación 23 verifique con éxito que la ID complementaria y la ID de pago son auténticas, además de enviar el resultado de verificación a la pasarela de pago 8, el módulo de verificación 23 también envía la ID de pago y el resultado de verificación al servidor de pago 20 (bloque 96). En el bloque 100, el servidor de pago 20 ejecuta el pago. En el bloque 98, la pasarela de pago 8 genera la ID2 de dispositivo móvil y envía la misma al dispositivo móvil 10 para su almacenamiento.
En otra realización de ejemplo, la figura 9 proporciona instrucciones ejecutables por ordenador para un proceso de registro y la figura 10 proporciona instrucciones ejecutables por ordenador para un proceso de transacción. Volviendo a la figura 9, en el bloque 102, el dispositivo móvil 10 recibe, por ejemplo, a través de entradas de usuario, al menos la ID complementaria. Los dispositivos móviles 10 recuperan la ID de pago. El bloque 102 es similar al bloque 54, descrito anteriormente. En el bloque 104, el dispositivo móvil 10 genera y almacena la ID de dispositivo móvil. En el bloque 106, el dispositivo móvil 10 envía la ID complementaria, la ID de pago, y la ID de dispositivo móvil para la pasarela de pago 8. La ID complementaria y la ID de pago no se almacenan en el dispositivo móvil 10. En el bloque 108, la pasarela de pago 8 envía la ID complementaria y la ID de pago al módulo de verificación 23 (por ejemplo, ubicado en el servidor complementario 22). En el bloque 110, el módulo de verificación 23 verifica si la ID complementaria y la ID de pago son correctas y envía los resultados de verificación a la pasarela de pago 8. Si se verifica con éxito, la pasarela de pago almacena o guarda la ID de dispositivo móvil y la ID de pago en asociación entre sí (bloque 112). La pasarela de pago 8 genera entonces un valor de número de un solo uso (por ejemplo, de número de un solo uso, ),que se envía al dispositivo móvil 10 (bloque 114) para su almacenamiento en el mismo (bloque 106).
En otra realización de ejemplo, la pasarela de pago 8 puede almacenar la ID de dispositivo móvil y la ID de pago anteriormente, antes de que el módulo de verificación 23 verifique esa ID complementaria y la ID de pago.
En la figura 10, tras iniciar una transacción, el dispositivo móvil 10 recibe la ID complementaria del usuario, recupera el número! de un solo uso y la ID de dispositivo móvil de la memoria, y envía estos valores a la pasarela de pago 8 (bloque 118). En el bloque 120, la pasarela de pago 8 determina si la ID de dispositivo móvil está presente en la pasarela de pago 8, y si el número! de un solo uso es correcto. Por ejemplo, el número! de un solo uso es correcto si coincide con el valor de número de un solo uso almacenado en la pasarela de pago 8 en asociación con la ID de pago o la ID de dispositivo móvil, o ambas. Si es así, en el bloque 122, la pasarela de pago 8 recupera la ID de pago asociada con la ID de dispositivo móvil y envía la ID de pago, la ID de dispositivo móvil, y la ID complementaria al módulo de verificación 23 (por ejemplo, ubicado en el servidor complementario 22). En el bloque 124, el módulo de verificación 23 determina si la ID complementaria y la ID de dispositivo móvil son correctas. Si es así, el pago se procesa por el servidor de pago 20 (bloque 126), por ejemplo, propagando el resultado de verificación. En el bloque 128, la pasarela de pago 8 genera y envía un nuevo valor de número de un solo uso (por ejemplo, número 2 de un solo uso) al dispositivo móvil 10, que reemplaza el valor de número de un solo uso anterior (por ejemplo, número! de un solo uso). El nuevo valor de número de un solo uso está asociado con la ID de dispositivo móvil y la ID de pago. En el bloque 130, el nuevo valor de número de un solo uso se guarda y se usa para una transacción posterior. La actualización de los valores de número de un solo uso se usa para mitigar el riesgo de ataques de reinyección.
En la realización de ejemplo de la figura 9 y la figura 10, se puede apreciar que la ID de dispositivo móvil permanece estática y no cambia de transacción a transacción. Además, el uso de valores de número de un solo uso, aunque se prefiere, no es necesario.
A continuación se describen realizaciones y detalles de ejemplo adicionales de los sistemas y métodos anteriores.
En una realización de ejemplo, el dispositivo móvil 10 se retendrá de manera persistente, en un mecanismo de almacenamiento de navegador (tal como cookies, almacenamiento web, objetos compartidos locales, etc.), su ID de dispositivo móvil para su recuperación adicional. La pasarela de pago 8 mapea de manera persistente o asocia de otra manera en un mecanismo de almacenamiento de datos 38 la ID de dispositivo móvil con elementos de datos externos o internos (tales como identificadores de sistema, o datos de dispositivo móvil o datos de usuario, tal como el componente público de un par de claves) o entidades (tal como otros servicios, proveedores de servicios, u otras externalidades), que, directa o indirectamente, parcial o totalmente, identifican el dispositivo móvil específico 10.
En otra realización de ejemplo, cuando el dispositivo móvil 10 indica una intención de completar una transacción, el dispositivo móvil 10 proporciona (tal como a través de la solicitud HTTP o HTTPS) o pone a disposición (tal como a través de secuencias de comandos (del inglés, script) del lado del cliente) su ID de dispositivo móvil, junto con cualquier dato aplicable a la transacción, a la pasarela de pago 8. La pasarela de pago 8 usará la ID de dispositivo móvil para resolver elementos o entidades de datos mapeados o asociados para autenticar el dispositivo móvil 10 (ya sea por coincidencia de datos, llamadas de sistema externas, o cualquier medio similar).
En otra realización de ejemplo, el dispositivo móvil 10 es capaz de interactuar con la pasarela de pago 8 a través de protocolos similares a HTTP (cifrados o de otro modo). El dispositivo móvil 10 puede acceder a la pasarela de pago 8 con una aplicación tal como un navegador web, o una aplicación similar en función, ya sea parcial o totalmente, a un navegador web. El dispositivo móvil 10 participa en transacciones, o unidades de trabajo similares, que logran algún objetivo, tal como una transacción de comercio electrónico o de comercio desde teléfono móvil, publicar o recuperar contenido, identificar a un usuario, confirmar otra transacción, y otros objetivos similares.
En otra realización de ejemplo, la pasarela de pago 8 puede determinar si el dispositivo móvil 10 ha enviado una ID de dispositivo móvil con la solicitud de transacción. Si es así, la pasarela de pago 8 puede determinar si la ID de dispositivo móvil es válida. Si es así, la pasarela de pago 8 puede verificar la transacción con cualquiera o todos los servidores complementarios disponibles asociados 24, 28, 32. Si la pasarela de pago 8 considera que el riesgo de transacción está dentro de un umbral aceptable, por ejemplo, todos o la mayoría de los servidores complementarios 24, 28, 32 informaron de un resultado positivo, la pasarela de pago 8 realiza entonces la transacción, envío, según sea necesario, todos los datos a cualquiera o todos los servidores de pago 20 o mecanismos de soporte similares.
En otra realización de ejemplo, si el dispositivo móvil 10 no proporciona la ID de dispositivo móvil o una ID de dispositivo móvil no válida a la pasarela de pago 8, al dispositivo móvil 10 se le proporciona la opción de iniciar un proceso de registro con la pasarela de pago 8.
En otra realización de ejemplo, si una transacción no tiene éxito por alguna razón, se notifica al dispositivo móvil 10. La pasarela de pago 8 puede incluso reintentar la transacción fallida un número de veces, antes de notificar al dispositivo móvil 10 de la verificación sin éxito.
Los detalles con respecto a la ID de dispositivo móvil se describen a continuación. La ID de dispositivo móvil identifica de manera única cada dispositivo móvil. Una ID de dispositivo móvil es un valor o colección o conjunto de valores, que, juntos, son capaces de identificar un dispositivo móvil 10 de todos los demás dispositivos móviles 10. Los sistemas y métodos propuestos no dependen de, o requieren que, la ID de dispositivo móvil esté en cualquier formato o presentación específicos, ni la ID de dispositivo móvil es necesario que se derive por o con cualquier método o datos específicos. Además, la ID de dispositivo móvil no es necesario que se derive de un medio consistente o se represente de una manera específica. Por ejemplo, el método de generación de la ID de dispositivo móvil puede cambiar de una transacción a otra.
En una realización de ejemplo, la ID de dispositivo móvil es un valor compuesto que se deriva o crea basándose en una combinación de datos proporcionados por, o en nombre de, el dispositivo móvil 10. Por ejemplo, la ID de dispositivo móvil se basa en uno o más de los siguientes valores: información de identidad de abonado almacenada en una tarjeta SIM (módulo de identidad de abonado), un chip NFC (comunicación de campo cercano), IMEI (identidad internacional de equipo móvil) de un dispositivo móvil 10, proporcionada por información de red (a través de inyección de proxy, quizás), una lista de complementos/plug-in de navegador web, y, cookies, agente de usuario, y otros encabezados proporcionados por un navegador en el dispositivo móvil 10.
La ID de dispositivo móvil de tipo compuesto puede derivarse en múltiples etapas. Por ejemplo, la pasarela de pago 8 puede recoger el agente de usuario de un navegador web y retenerlo, temporalmente, hasta que cualquiera o todos los datos requeridos adicionalmente, tal como los que pueden recopilarse solo a través de la ejecución de un lenguaje de secuencia de comandos en el navegador del dispositivo móvil, pueden recuperarse y usarse para derivar una ID de dispositivo móvil.
En otra realización de ejemplo, la pasarela de pago 8 usa datos enviados en nombre del dispositivo móvil 10. Por ejemplo, si el dispositivo móvil 10 está accediendo a la pasarela de pago 8 a través de un proxy de Internet (por ejemplo, un proxy WAP, proxy de operador, proxy corporativo, BES, etc.), cualquier dato proporcionado adicionalmente, tales como números de teléfono, identificación de operador, o proveedores de proxy, pueden recopilarse y usarse para generar la ID de dispositivo móvil. Aún más, incluso información de la capa de red, tales como IP, puertos, nombres de DNS, etc. puede usarse en el proceso de derivación de ID de dispositivo móvil.
En una realización de ejemplo, datos derivados, consecuentes, o datos de punto en el tiempo, o una combinación de los mismos, pueden ser parte de la ID de dispositivo móvil. Tales datos se denominan datos temporales o efímeros. Una realización de ejemplo puede usar datos específicos del dispositivo móvil 10, tales como las coordenadas GPS (Sistema de Posicionamiento Global), temperatura de batería, lecturas de acelerómetro, niveles de iluminación (brillo de una sala, por ejemplo), SSID (ID de Conjunto de Servicios) o ESSID (ID de Conjunto de Servicios Extendido) de un punto de acceso inalámbrico, dirección IP (protocolo de Internet) de LAN (red de área local) de un dispositivo móvil 10, etc. como posibles componentes de una ID de dispositivo móvil. Puede usarse el ISP actual (proveedor de servicios de Internet), por lo tanto, también se pueden usar país, ciudad, y posiblemente la vecindad y la ubicación de la vivienda de un dispositivo móvil 10 para formar la ID de dispositivo móvil. En tal caso, datos aún más detallados, tal como el estado económico, estado de empleo, nivel de educación, características de comportamiento, etc. proporcionados por sistemas externos, pueden usarse como componentes de una ID de dispositivo móvil. En general, se pueden usar diversas características medibles del entorno del dispositivo móvil como componentes en la derivación de la ID de dispositivo móvil.
Se puede apreciar que cuando las ID de dispositivo móvil se derivan de los datos o características efímeras anteriores, la ID de dispositivo móvil no requiere un mecanismo de almacenamiento real en el dispositivo inalámbrico 10. En otras palabras, los datos efímeros derivados pueden recomponerse en una ID de dispositivo móvil “sobre la marcha”, o cuando se requiera durante los procesos de transacción y registro. Se reconoce que la ID de dispositivo móvil puede cambiar con el tiempo usando tales métodos. Para acomodar estas diferencias resultantes entre las ID de dispositivo móvil derivadas (o derivadas de nuevo) a lo largo del tiempo, una realización de ejemplo puede usar distancias de Levenshtein, algoritmos de indexación fonética, métodos variables de enlace de grabación, u otras técnicas similares. De esta manera, se puede determinar si la diferencia en una ID de dispositivo móvil en un punto en el tiempo es aceptablemente similar o asociarse con una ID de dispositivo móvil en otro punto en el tiempo. En otras palabras, las ID de dispositivo móvil no necesariamente es necesario que sean iguales. Una realización de ejemplo de este tipo acomoda diferencias entre ID de dispositivo móvil derivadas o derivadas de nuevo, o ambas.
Por lo tanto, se puede apreciar que la ID de dispositivo móvil se puede reemplazar por una nueva ID de dispositivo móvil y está asociada con la ID de pago para cada ejecución posterior del proceso de transacción. Además, durante el proceso de transacción, la pasarela de pago compara la ID de dispositivo móvil recibida del dispositivo móvil con la ID de dispositivo móvil previamente almacenada durante el proceso de registro para determinar si son similares, y si es así, autentica la transacción para su ejecución (por ejemplo, a través del servidor de pago 20).
En una realización de ejemplo, la pasarela de pago 8 almacena la ID de dispositivo móvil usando una base de datos relacional, base de datos de objetos, o almacenamiento de datos “NoSQL”. En otra realización de ejemplo, las ID de dispositivo móvil pueden almacenarse en almacenamiento de archivos planos, XML, o JSON. Preferiblemente, aunque no necesariamente, las ID de dispositivo móvil están protegidas por controles de acceso adecuados e incluso pueden almacenarse en una forma fuertemente cifrada.
Otro ejemplo de realización de una ID de dispositivo móvil es del tipo sustituto. Una ID de dispositivo móvil de tipo sustituto se refiere a un valor sustituto (por ejemplo, un valor sin significado fuera de la responsabilidad de ser un identificador) que es único dentro de la pasarela de pago 8. Tal realización no requiere o depende de un identificador sustituto para derivarse por ningún medio específico, ni una realización de este tipo debe requerir o depender de un identificador sustituto para estar en cualquier formato específico. Sin embargo, los candidatos preferidos para una ID de dispositivo móvil de tipo sustituto tienen las siguientes características de ejemplo: se puede visualizarse como una serie de caracteres legibles por humanos; puede generarse, calcularse, o crearse de otro modo relativamente rápido; se puede crear con un componente aleatorio usando un RNG seguro (generador de números aleatorios); y, no debe contener información sensible.
Un UUID versión 4 (identificador único universal) cumple todas estas características y es una realización que usa una ID de dispositivo móvil de tipo sustituto.
Aunque la ID de dispositivo móvil está asociada con información sensible en la pasarela de pago 8, la propia ID de dispositivo móvil, que es un sustituto, en una realización de ejemplo, no se considera (ni contiene) información sensible. Incluso aunque la ID de dispositivo móvil solo no sea suficiente para completar una transacción, la ID de dispositivo móvil está preferiblemente protegida razonablemente tanto en el dispositivo móvil 10 como en la pasarela de pago 8 y debe transmitirse a través de un canal autenticado seguro, como HTTPS.
Un dispositivo móvil 10 puede almacenar su ID de dispositivo móvil en uno (o más) de muchos mecanismos de almacenamiento expuestos al dispositivo móvil 10. Como la mayoría de los sitios web usan cookies HTTP para almacenar de manera segura un identificador de sesión, o datos sensibles (a menudo transitorios) similares, una realización usa cookies como un mecanismo de almacenamiento razonablemente seguro para la ID de dispositivo móvil. Otra realización puede usar almacenamiento DOM (o almacenamiento web) como mecanismo de almacenamiento.
En otra realización de ejemplo, por ejemplo, empleada por un proveedor de SaaS (Software como servicio), puede usar un enfoque híbrido, usando cada uno de los datos de ID de dispositivo móvil de tipo sustituto y tipo compuesto. Se pueden usar diferentes tipos de ID de dispositivo móvil para cada cliente, dispositivo móvil, transacción, etc. Además, otra realización puede incluso usar más de una estrategia, tal como el uso de una ID de dispositivo móvil de tipo compuesto con una ID de dispositivo móvil de tipo sustituto de reserva.
En una realización de ejemplo, si el dispositivo móvil 10 tiene un agente de usuario o dirección IP, y los cambios de dirección IP, el dispositivo móvil 10 sería necesario que se asocie de nuevo o se registre. En otras palabras, sería necesario que se genere una nueva ID de dispositivo móvil para reemplazar la ID de dispositivo móvil anterior. Sin embargo, la realización también puede usar un identificador único de 'reserva', que es una cadena sustituta almacenada en una web de navegador. Este identificador de reserva puede usarse para asociar de nuevo automáticamente el dispositivo móvil 10 con la ID de dispositivo móvil anterior, o puede usarse en lugar de la ID de dispositivo móvil anterior.
Los detalles y las realizaciones con respecto a los servidores complementarios 20 o los servicios de verificación complementarios se describen a continuación. Los sistemas complementarios normalmente se usan para complementar la autenticación de una transacción con el servidor de pago 20. Una realización de ejemplo de un servidor complementario 20 puede ser de un sistema BASE I, con el que la pasarela de pago 8 autentica una transacción usando un número de tarjeta de crédito (por ejemplo, ID de pago) y número CVV2 (por ejemplo, ID complementaria). Si el servidor complementario 20 indica que el número CVV2 coincide, o es correcta, la pasarela de pago 8, junto con el servidor de pago 20, realiza la transacción, posiblemente a través de un proveedor de servicios que ofrece un BASE II. Se aprecia que BASE (Ingeniería de sistemas del Banco de América, del inglés Bank of America System Engineering) son redes de procesamiento, donde BASE I autoriza transacciones, y el BASE II liquida y realiza las transacciones.
En una realización de ejemplo donde el servidor complementario 22 es parte de la pasarela de pago 8 o el servidor de pago 20, o ambos, la transacción combinada y el sistema de autenticación pueden autenticar una transacción y ejecutar la transacción en una etapa. Una realización de este tipo usa un único sistema como proveedor de servicios complementario y como proveedor de servicios de pago. Un procesador de tarjeta de crédito que realiza condicionalmente una transacción basándose en el resultado de una verificación de CVV2 es un ejemplo de dicho sistema complementario. Aunque no se requiere por esta invención, una realización de ejemplo de esta invención puede consumir el sistema complementario último en una serie de sistemas complementarios (22), a veces conocido como “último participante”. Esto puede ser una forma de los sistemas complementarios 24, 28, 32 que tienen diferentes esquemas de ponderación de resultado. Por ejemplo, si dos sistemas complementarios autentican positivamente una ID de pago y una ID complementaria, y otro sistema complementario no autentica las ID, luego los otros dos resultados de autenticación de los sistemas complementarios se repiten.
En otra realización de ejemplo, se utilizan múltiples sistemas complementarios. Por ejemplo, además de verificar CVV2, la transacción se autentica usando una realización externa del sistema de verificación de direcciones (AVS), o usando una realización de 3D Secure, o ambos. Dichas realizaciones exhiben además estrategias de decisión, que determinan dinámicamente el riesgo percibido de una transacción basándose en las respuestas de verificación de cualquiera o todos los sistemas complementarios. Por ejemplo, un fallo de AVS puede ser aceptable si tanto CVV2 como 3D Secure tienen éxito, se invocan diferentes grupos de sistemas complementarios según el estado económico o social, proporcionado, percibido o derivado de un titular de tarjeta de crédito en combinación con un perfil de riesgo de un comerciante.
Sistemas complementarios (por ejemplo, servidor 32, operación 34) pueden ser biológicos (por ejemplo, color del ojo del usuario, escáner de retina, huella dactilar, análisis de voz, etc.). Otros hechos verificables incluyen, por ejemplo, un color preferido del usuario. Cuando el servidor complementario 32 intenta verificar la respuesta proporcionada, el servidor complementario 32 puede contactar, a través de un sistema de respuesta de voz interactiva (IVR) o mecanismo similar, un familiar o compañero del usuario para verificar el color preferido del usuario. Se puede apreciar que el dispositivo móvil 10 está equipado con el hardware relevante para obtener los datos biológicos. Ejemplos de dicho hardware incluyen un micrófono, un escáner de huellas dactilares, una cámara, etc.
En una realización de ejemplo, la ID complementaria de usuario son datos de voz. En otras palabras, el usuario solo necesita decir o pronunciar una cierta palabra (o palabras) o sonidos para autenticar y ejecutar la transacción. Por ejemplo, el usuario dice una o más palabras que son grabadas por el dispositivo móvil 10. La palabra o palabras pueden ser la contraseña CVV, y se puede apreciar que el dispositivo móvil 10 tiene un micrófono para grabar los datos de voz. El dispositivo móvil 10 envía los datos de voz y la ID de dispositivo móvil a la pasarela de pago 8. La pasarela de pago envía los datos de voz y la ID de pago al servidor complementario 22 (por ejemplo, servidor complementario 32) para verificación. El servidor complementario 22 usa reconocimiento de voz, o reconocimiento de persona que habla, o ambos, para determinar si los datos de voz coinciden con los datos de voz almacenados en el servidor complementario 22 en asociación con la ID de pago dada. Si hay coincidencia en los datos de voz, entonces la ID complementaria se considera verificada con éxito. Puede apreciarse que el reconocimiento de voz determina lo que se dice, mientras que el reconocimiento de la persona que habla determina quién está diciendo las palabras o sonidos. El reconocimiento de voz típicamente hace uso de modelado acústico o modelado del lenguaje, o ambos. Dichas técnicas de modelado se usan en algoritmos de reconocimiento de voz basados estadísticamente. Los modelos de ejemplo incluyen los modelos ocultos de Markov (HMM) y el reconocimiento de voz basado en distorsión de tiempo dinámica (DTW). El reconocimiento de la persona que habla puede incluir el uso de impresiones de voz. Estas incluyen estimación de frecuencia, HMM, modelos de mezcla Gaussiana, algoritmos de coincidencia de patrones, redes neuronales, representación de matriz, cuantificación de vectores y árboles de decisión. Algunos sistemas de reconocimiento de persona que habla también usan técnicas “contra la persona que habla”, tales como modelos de cohorte, y modelos del mundo. Estos principios, o combinaciones de los mismos, puede usarse para analizar los datos de voz del usuario, y para determinar si se verifican los datos de voz (por ejemplo, ID complementaria).
Los detalles y realizaciones con respecto al proceso de registro se proporcionan a continuación. Puede usarse un proceso de reasociación como una etapa secundaria al proceso de registro, en el que la ID de dispositivo móvil derivada inicial o previamente se reemplaza con otra ID de dispositivo móvil. En el proceso de reasociación, la anterior asociación entre la ID de dispositivo móvil anterior y la ID de pago se recibe y se usa para asociar una nueva ID de dispositivo móvil con la misma ID de pago. Esta reasociación se usa preferiblemente cuando se usa una ID de dispositivo móvil de tipo sustituto y una delta o diferencia temporal en la ID de dispositivo móvil puede introducir un seguimiento de auditoría adicional. Esto puede ser beneficioso para determinar cómo ha cambiado la ID de dispositivo móvil, así como cuando la ID de dispositivo móvil ha cambiado.
En un caso en el que la ID de dispositivo móvil se purga o elimina del dispositivo móvil 10 (tal como cuando se eliminan las cookies del navegador de un dispositivo móvil), la reasociación puede añadir inteligencia de negocio adicional. La inteligencia de empresa puede referirse a la notificación de métricas para rastrear la identidad de las personas y su acción (por ejemplo, qué y cuándo). Esto puede usarse para garantía de calidad y auditoría, entre otras cosas. Sin embargo, se aprecia que puede haber riesgos, tal como fuga de datos e información, asociada con la reasociación. La fuga de datos puede ocurrir cuando un adversario logra “piratear” o asociar de nuevo el dispositivo móvil 10 con datos que no se asociaban anteriormente con el adversario. Por ejemplo, el adversario puede intentar asociar su propio dispositivo móvil con la ID de dispositivo móvil de un usuario, por lo tanto, robando de ese modo la ID de dispositivo móvil del usuario. El impacto de tales ataques puede mitigarse, por ejemplo, haciendo que la pasarela de pago 8 sólo escribe explícitamente. En otras palabras, el adversario puede no ser capaz de leer los datos asociados. Dado que la autenticación de una transacción aún depende de un artículo adicional (por ejemplo, la ID complementaria), el adversario no podría completar una transacción incluso con una asociación pirateada.
Además, otra realización añade procesos adicionales cuando se reasocia un dispositivo móvil 10. Por ejemplo, al usuario de un dispositivo móvil 10 se le puede solicitar que envíe por correo o fax una copia de su licencia de conducir, extracto de tarjeta de crédito, número de seguros sociales, u otra evidencia tangible de la identidad del usuario. Por lo tanto, se puede entender, que el proceso de registro puede adoptar realizaciones de la misma, solas o en combinación entre sí.
Se proporcionan otras realizaciones de ejemplo para mitigar aún más el riesgo de seguridad. Por ejemplo, los MAC (códigos de autenticación de mensaje) de una ID de dispositivo móvil pueden calcularse para ayudar a reducir la probabilidad de ataques de fuerza bruta con éxito. Otra realización de ejemplo limita la velocidad de reintento para mitigar transacciones fraudulentas y para permitir la activación de un sistema de alerta temprana. Aunque el número y tipo de controles de riesgo varían, los sistemas y métodos propuestos no dependen de ni requieren ningún mecanismo de control de riesgo específico.
En una realización de ejemplo de control de riesgos de seguridad, los MAC se usan en combinación con una ID de dispositivo móvil para aumentar la certeza de autenticidad de una transacción. Los MAC pueden calcularse usando HMAC (MAC basado en hash), mientras que otra realización puede usar CMAC (MAC basado en cifrado). Se pueden usar otros protocolos MAC. El protocolo MAC seleccionado debería verificar razonablemente la autenticidad de un mensaje. Por consiguiente, la pasarela de pago 8 preferentemente retiene suficientes datos para verificar cualquier MAC emitido, tal como la clave secreta usada para producir el MAC.
Durante el proceso de derivación de ID de dispositivo móvil, un MAC puede calcularse usando una clave secreta conocida solo por la pasarela de pago 8. El MAC puede almacenarse entonces en la pasarela de pago 8, posiblemente usando el mismo mecanismo de almacenamiento usado para almacenar la ID de dispositivo móvil. A continuación, el MAC se transfiere para su almacenamiento en el dispositivo móvil 10. El dispositivo móvil 10 almacena el MAC de una manera similar a la utilizada para el almacenamiento de su ID de dispositivo móvil.
Durante una transacción, el dispositivo móvil 10 envía, junto con todos los datos de transacción aplicables y la ID de dispositivo móvil, el MAC proporcionado por la pasarela de pago 8. La pasarela de pago 8 usa los datos de transacción proporcionados, probablemente en combinación con la ID de dispositivo móvil, para verificar el MAC proporcionado por el dispositivo móvil 10. Si el MAC no fuera verificable, la pasarela de pago 8, por ejemplo, revoca la ID de dispositivo móvil específica, deniega la transacción, notifica a los administradores de sistema, u otras acciones similares. Sin embargo, si, por ejemplo, la ID complementaria proporcionada por el dispositivo móvil 10 es correcta, según lo verificado por el servidor complementario 20, entonces la pasarela de pago 8 aún puede elegir autorizar la transacción.
Aunque los MAC pueden ser útiles para comprobar la autenticidad de la solicitud desde un dispositivo móvil 10, los MAC pueden no proporcionar la cantidad deseada de rendimiento de auditoría. Algunas realizaciones que emplean la comprobación de MAC no se benefician inherentemente de la capacidad de determinar dónde se creó realmente el MAC. Las realizaciones con tales requisitos de auditoría pueden beneficiarse, en su lugar, de firmas digitales.
En otra realización de ejemplo, los controles de riesgo de seguridad incluyen garantizar la fuente de origen utilizando firmas digitales. Tal realización puede emplear firmas digitales para lograr este requisito. Aunque una realización podría lograr esto posiblemente con MAC, una pasarela de pago 8 que se distribuye lógica o físicamente puede tener varias claves de firma, y cada nodo en la pasarela de pago 8 solo puede tener accesos a un subconjunto de las claves de firma. En tal escenario, verificar el mensaje real frente al firmante real y, posiblemente, autoridad de confianza, puede ser más fiable e informativo.
Cuando la pasarela de pago 8 firma la ID de dispositivo móvil, la firma puede enviarse al dispositivo móvil 10. Tras recibir la ID de dispositivo móvil y la firma, el dispositivo móvil 10 almacena los datos en un mecanismo de almacenamiento (cookies, almacenamiento DOM, objetos compartidos locales, etc.). Cuando el dispositivo móvil 10 indica un intento de completar una transacción, la firma digital almacenada, junto con la ID de dispositivo móvil, puede enviarse a la pasarela de pago 8. Tras recibir la firma digital, la pasarela de pago 8 verifica que la firma digital se creó dentro de la pasarela de pago 8 y puede verificar la ID de dispositivo móvil frente a la firma. Este proceso es además de transmitir y verificar la ID complementaria, como se discutió anteriormente.
Otra realización de ejemplo usa enfoques de no rechazo. En particular, las firmas digitales se combinan con una ID de dispositivo móvil para beneficiarse del no rechazo de origen. La introducción de no rechazo de origen puede ayudar a determinar la responsabilidad de una parte implicada en una transacción, tal como una parte de transacción (por ejemplo, la persona o usuario que es el titular de la tarjeta que inicia la transacción) que disputa una compra de tarjeta de crédito. Se aprecia que el no rechazo normalmente se habilita cuando el dispositivo móvil 10 genera su propia clave privada y protege adecuadamente la clave privada con un cifrado fuerte.
En un ejemplo de implementación de no rechazo, el dispositivo móvil 10 genera un par de claves y envía su clave pública a la pasarela de pago 8 durante el registro. La pasarela de pago 8 registra el dispositivo móvil 10 según los procesos descritos anteriormente, pero adicionalmente retiene la clave pública del dispositivo móvil 10. Cuando un dispositivo móvil 10 realiza una transacción posterior, el dispositivo móvil 10 puede firmar digitalmente o bien una porción o bien un conjunto completo de datos asociados con la transacción. Una realización de esto incluye firmar la ID de dispositivo móvil. Alternativamente, las calificaciones de transacción (precio, cantidad, fecha, etc.) están firmados por el dispositivo móvil 10. Estas operaciones de firma se pueden realizar además de implementar controles para evitar ataques de reinyección. Cuando la pasarela de pago 8 recibe los datos asociados con la solicitud de transacción, la pasarela de pago 8 verifica los datos firmados, o bien continuando como normal o bien denegando la solicitud de transacción según el resultado de verificación.
Los pares de claves y firmas digitales descritos anteriormente se pueden crear usando los plug-in en el navegador web del dispositivo móvil 10. Las mismas operaciones también se pueden realizar con lenguajes de secuencias de comandos del lado del cliente o aplicaciones externas. Por ejemplo, JavaScript puede usarse para generar un par de claves y crear firmas digitales. En otro ejemplo, se crea un par de claves a partir de una aplicación externa y se crean firmas digitales usando un plug-in de navegador.
En otra realización de ejemplo, los enfoques de revocación se pueden usar como un mecanismo de control de riesgos de seguridad. Dependiendo de cómo se genere la ID de dispositivo móvil, es posible que algunas realizaciones de una ID de dispositivo móvil tengan solo una cantidad razonable de control de acceso y puedan conocerse, ya sea por accidente o intencionalmente. Por ejemplo, es posible que un adversario pueda extraer la ID de dispositivo móvil de un dispositivo móvil 10 robado, aunque esto por sí solo sería insuficiente para autenticar una transacción. Además, herramientas de captura de paquetes, registros de servidor de terceros, y otros repositorios similares de información y herramientas, pueden usarse perceptiblemente para interceptar, derivar, o recuperar una ID de dispositivo móvil. Aunque algunas realizaciones pueden intentar mitigar este riesgo implementando secuencias, otras realizaciones pueden, además de o en lugar de, incluir un mecanismo que revocará, expirará, desasociará, invalidará o anulará de otro modo una ID de dispositivo móvil. Revocar la ID de dispositivo móvil preferiblemente, aunque no necesariamente, se implementa en combinación con otros mecanismos de control. La revocación se puede combinar, por ejemplo, con intentos de reintento limitantes para reducir la probabilidad de que un ataque de fuerza bruta sea con éxito. Esto se debe simplemente a que una ID de dispositivo móvil recuperada, interceptada, o derivada solo puede usarse un pequeño número de veces antes de que se anule la ID de dispositivo móvil.
Otro mecanismo de control de riesgo de seguridad implica “limitar el reintento”, lo que limita la frecuencia (y el riesgo asociado) de aceptación, y posteriormente procesamiento, de transacciones fraudulentas. Por ejemplo, si se usa una ID de dispositivo móvil para completar sin éxito una transacción numerosas veces en un corto período de tiempo, a continuación, se revoca la ID de dispositivo móvil. Por consiguiente, la ID de dispositivo móvil revocada puede descartar transacciones de origen que usen la ID de dispositivo móvil revocada.
En otro ejemplo limitante de reintento, una política de caducidad renovable utilizada. En una realización de ejemplo de este tipo, una ID de dispositivo móvil se revoca si el usuario de un dispositivo móvil 10 no puede completar con éxito una transacción después de realizar un número predeterminado de intentos (por ejemplo, cinco intentos) dentro de un período de tiempo de renovable (por ejemplo, ventana de dos minutos). En otra variación, puede usarse una ventana de tiempo fija como alternativa. Una ventana de tiempo renovable en el presente documento se refiere a una ventana de tiempo que se restablece después de algún tiempo (por ejemplo, minutos) después de la transacción más reciente; la ventana de tiempo es relativa a la mayor parte de la transacción. Una ventana de tiempo fija en el presente documento se refiere a una ventana de tiempo que se restablece después de un tiempo después de la primera transacción; la ventana de tiempo es absoluta como se determina a partir de la primera transacción.
En otro ejemplo limitante de reintento, hay múltiples capas de limitación de frecuencia. En particular, una capa está dirigida a prevenir el éxito de los ataques de fuerza bruta aguda y una capa secundaria está dirigida a prevenir el éxito de los ataques de fuerza bruta lenta, que puede, de lo contrario, escapar de detección inmediata. Por ejemplo, se usa una ventana de tiempo renovable en la primera capa, y se usa una ventana de tiempo fija en la segunda capa.
En otra realización de ejemplo de control de riesgo de seguridad, se usan secuencias, por ejemplo, para para facilitar la detección de manipulación o prevención de reinyecciones (ya sea accidental o intencional). De manera importante, los sistemas y métodos descritos en el presente documento no dependen o se limitan a la fuente o formato de secuencias. Números de secuencia generados aleatoriamente, o secuencias léxicas, o ambas pueden usarse. Las secuencias son preferiblemente impredecibles para evitar el pirateo y lo suficientemente grandes como para evitar ataques de fuerza bruta.
Una implementación de ejemplo de secuencias en el contexto de los sistemas y métodos propuestos incluye, durante el registro, generando la pasarela de pago 8, o proporcionarse, un valor de secuencia, que se almacena en la pasarela de pago 8 y se transmite al dispositivo móvil 10 para su almacenamiento en el mismo. Cuando se realiza una transacción, el dispositivo móvil 10 envía el valor de secuencia almacenado actualmente, además de los datos de transacción, la ID de dispositivo móvil y la ID complementaria. La pasarela de pago 8 comprueba el valor de secuencia del dispositivo móvil 10 para garantizar que sea el mismo que el valor de secuencia almacenado en la pasarela de pago 8. Si ambas secuencias coinciden, la pasarela de pago 8 continúa, como es habitual, con la transacción. Un nuevo valor de secuencia se genera y almacena adicionalmente tras la finalización de cada transacción. Si, sin embargo, las secuencias no coinciden, la pasarela de pago 8 puede tomar una cualquiera o más de las siguientes acciones: volver a sincronizar los valores de secuencia; ponderar el coste de una transacción fraudulenta y proceder condicionalmente; y, revocar completamente la ID de dispositivo móvil.
En otra realización de ejemplo, la ID de dispositivo móvil puede generarse para incluir un valor de secuencia, de modo que la ID de dispositivo móvil se reenvíe simplemente para cada transacción. Diversas técnicas de almacenamiento de datos, tales como dimensiones que cambian lentamente (tipo 2, 4 o 6, por ejemplo), pueden usarse para realizar un seguimiento de las ID de dispositivo móvil en secuencia.
Lo siguiente proporciona algunas realizaciones de ejemplo. Sin embargo, estos ejemplos no son exhaustivos y pueden adaptarse a situaciones similares.
Ejemplo 1: Autenticación de las transacciones de comercio electrónico/comercio desde teléfono móvil
Los sistemas y métodos propuestos se usan en una transacción de comercio electrónico o de comercio desde teléfono móvil para reducir el riesgo de una transacción fraudulenta, al garantizar que un usuario pueda probar razonablemente que conoce una ID complementaria, tal como un número CVV2 o contraseña 3D Secure, y también puede demostrar razonablemente que tiene acceso físico a un dispositivo móvil de confianza 10. Después de que un usuario haya terminado de seleccionar productos o servicios del sitio web de un comerciante, el usuario hará clic en un botón de enviar HTML (o mecanismo similar), indicando su intención de completar una transacción. El sistema de servidor del comerciante dirigirá el navegador web del dispositivo móvil a una página web de “comprobación”, que resume los detalles de transacción.
En una realización que usa un número CVV2, cuando el dispositivo móvil conocido 10 (por ejemplo, un dispositivo móvil 10 que se ha registrado con éxito) llega a la página web de “comprobación”, la pasarela de pago 8 usará la ID de dispositivo móvil para recuperar el número de tarjeta de crédito asociado (por ejemplo, ID de pago) de la memoria 38. La pasarela de pago 8 prepara entonces una transacción de tarjeta de crédito y solicita al usuario su número o CVV2 (por ejemplo, ID complementaria). A través del dispositivo móvil 10, el usuario proporciona su número CVV2 y devuelve los datos a la pasarela de pago 8. La pasarela de pago 8 usa un servidor complementario 22 para verificar el número CVV2. Si el número CVV2 se verifica con éxito, por ejemplo, como se indica mediante un código de confirmación del servidor complementario 22, la pasarela de pago 8 envía la transacción completa, tal como enviando el número de tarjeta de crédito y el número CVV2 a un servidor de pago 20.
Si, sin embargo, el número CVV2 no se verifica con éxito, la pasarela de pago 8 reintenta o deniega la transacción. En una realización en la que la pasarela de pago 8 intenta reintentar una transacción, la pasarela de pago 8 solicita al usuario, un segundo, tercero, o enésimo tiempo, o bien una corrección a la información proporcionada por el usuario o bien información complementaria. La pasarela de pago 8 vuelve a intentar el proceso de verificación con la información complementaria corregida. Si la pasarela de pago 8 no verifica con éxito la transacción después de un tercer intento (o algún otro número razonable para las circunstancias), la pasarela de pago 8 revoca la ID de dispositivo móvil o deniega la transacción, o ambas.
Si, sin embargo, el dispositivo móvil 10 llega a la página web de “comprobación” y no proporciona un identificador único conocido o válido, o envía un identificador no único a la pasarela de pago 8, la pasarela de pago 8 invoca el proceso de registro o reasociación, redirigiendo el dispositivo móvil 10 a una página web que describe las etapas necesarias para registrar o asociar de nuevo el dispositivo móvil 10<*>. Alternativamente, la pasarela de pago 8 deniega toda la transacción. Tal decisión podría ser tomada por sistemas lógicos externos, intervención humana, o mecanismos y/o procesos de decisión similares.
Ejemplo 2: Autenticación de las transacciones comercio electrónico/comercio desde teléfono móvil
Otra realización de ejemplo se usa en una transacción de comercio electrónico o de comercio desde teléfono móvil para reducir el riesgo de una transacción fraudulenta, garantizando que un usuario pueda probar razonablemente que conoce un pin, o una credencial similar, tal como un número CVV2, y también puede demostrar razonablemente que tiene acceso físico al dispositivo móvil 10.
Después de que un usuario haya terminado de seleccionar productos o servicios del sitio web de un comerciante, el usuario hará clic en un botón de enviar HTML (o mecanismo similar), indicando su intención de completar una transacción. El sistema de servidor del comerciante dirigirá el navegador del dispositivo móvil a una página web de “comprobación”, que resume los detalles de transacción.
Cuando se conoce un dispositivo móvil 10 (por ejemplo, un móvil 10 que se ha utilizado con éxito para completar el proceso de registro o reasociación) llega a la página web de <“>comprobación”, la pasarela de pago 8 usará la ID de dispositivo móvil para recuperar el número de tarjeta de crédito asociado de la memoria 38. La pasarela de pago 8 entonces preparará una transacción de tarjeta de crédito y solicitará al usuario su número o CVV2. El usuario introducirá su número CVV2 en el dispositivo móvil 10 (por ejemplo, en el navegador web del dispositivo móvil) y enviará los datos de vuelta a la pasarela de pago 8. La pasarela de pago 8 retransmite la información de transacción (por ejemplo, número de tarjeta de crédito, CVV2, cantidad, moneda, etc.) a un servidor complementario 22 que sirve también como emisor de cuenta. El sistema complementario verificará el número CVV2. Si el número CVV2 se verifica con éxito, el servidor complementario 22 envía la transacción completa, tal como enviando el número de tarjeta de crédito y el número de CVV2 a un servidor de pago 20 (por ejemplo, el adquirente). Posiblemente, el servidor complementario 22 y el adquirente 20 pueden ser la misma entidad, ocultando así los límites contextuales.
Si, sin embargo, el número CVV2 no se verifica con éxito, el servidor complementario 22 puede denegar la transacción.
Otra realización de ejemplo incluye la pasarela de pago 8 que intenta reintentar una transacción denegada por el servidor complementario 22. En una realización de este tipo, la pasarela de pago 8 solicita al usuario, un segundo, tercero, o enésimo tiempo, o bien una corrección a la información proporcionada por el usuario o bien información complementaria. La pasarela de pago 8 vuelve a intentar el proceso de verificación con la información corregida o la información complementaria. Si la pasarela de pago 8 no verifica con éxito la transacción después de tres intentos (o algún otro número razonable para las circunstancias), la pasarela de pago 8 revoca la ID de dispositivo móvil, deniega la transacción, o realiza alguna acción similar.
Se aprecia que el orden de las entidades de acceso puede cambiarse adicionalmente. Por ejemplo, la pasarela de pago 8 puede enviar todos los datos de transacción aplicables al servidor de pago 20, que luego realizaría la verificación con el servidor complementario 22. Además, incluso la pasarela de pago 8 o el módulo de verificación 23 puede ser el destinatario inicial de los datos de transacción; en una realización de este tipo, estos sistemas pueden delegar responsabilidades, por consiguiente.
Ejemplo 3: Mejora de protocolos existentes
Otra realización de ejemplo implica el uso de protocolos de verificación existentes, tal como 3D Secure (por ejemplo, implementación proporcionada bajo las marcas comerciales verificadas por Visa, MasterCard SecureCode, o J/Secure) para garantizar que un usuario pueda probar que conoce una contraseña. Los sistemas y métodos propuestos usan dichos protocolos de verificación para que un usuario también demuestre razonablemente que está haciendo la transacción desde un dispositivo móvil de confianza específico 10. Después de que un usuario haya terminado de seleccionar productos o servicios del sitio web de un comerciante utilizando el dispositivo móvil 10, el usuario hará clic en un botón de enviar HTML (o mecanismo similar), indicando su intención de completar una transacción. El sistema de servidor del comerciante puede dirigir el navegador del dispositivo móvil a una página web de “comprobación”, que resume los detalles de transacción. A continuación, el usuario introduce la contraseña 3D Secure solicitada (por ejemplo, ID complementaria) en la página web del comerciante. Tras enviar la contraseña, el sistema de servidor del comerciante dirigirá el navegador del dispositivo móvil, junto con los detalles de transacción necesarios (por ejemplo, en la especificación actual de 3D Secure, esto incluiría cosas tales como el número de tarjeta de crédito, fecha de caducidad de la tarjeta de crédito, cantidad de transacción, moneda de transacción, información de comerciante, datos de registro, como un mensaje o ID de transacción, número de un solo uso, etc.), a una implementación fácilmente verificable única, unificada y consistente, de 3D Secure, que es una realización de los sistemas y métodos propuestos.
Cuando se conoce un dispositivo móvil 10 (por ejemplo, un dispositivo móvil 10 que se ha registrado con éxito) se dirige a una página web de 3D Secure unificada de este tipo, el dispositivo móvil 10 envía, o bien junto con la solicitud original (posiblemente como un HTTPS (o, menos probable, HTTP)) o bien en una solicitud posterior, su ID de dispositivo móvil. La pasarela de pago 8 usa la ID de dispositivo móvil para recuperar un perfil de información asociada con la ID de dispositivo móvil, y, específicamente, una colección de números de tarjeta de crédito registrada (por ejemplo, ID de pago).
Usando la contraseña 3D Secure del titular de la tarjeta, a continuación, la pasarela de pago 8 determina el ACS de emisor apropiado (Servidor de Control de Acceso) (por ejemplo, servidor complementario 22) y envía al ACS los datos 3D Secure aplicables y la contraseña para compararlos con los almacenados en el almacenamiento de datos del remitente del titular de la tarjeta. El resultado de autenticación del ACS se envía de vuelta a la pasarela de pago 8. La pasarela de pago 8 transmite el resultado de autenticación al proveedor de servicios de pago del comerciante (por ejemplo, el servidor de pago 20), posiblemente mediante un redireccionamiento HTTP por el navegador del dispositivo móvil.
Si es aplicable una cualquiera de las siguientes condiciones, por ejemplo, el número de tarjeta de crédito que se usa en la transacción del comerciante no es conocido por la pasarela de pago 8; la tarjeta de crédito no está incluida en el programa 3D Secure; la ID de dispositivo móvil es desconocida o no válida de otro modo; y el dispositivo móvil 10 no envía la ID de dispositivo móvil, entonces la pasarela de pago 8 redirige el dispositivo móvil 10, o cambia estratégicamente la respuesta HTML, a una página web que delimita las instrucciones de reasociación (o registro) aplicables. En una realización, esto podría implicar una llamada telefónica fuera del canal al banco emisor del titular de tarjeta de crédito, o, podría requerir la finalización de un mecanismo de desafío-respuesta.
De manera perceptible, en lugar de que la ID de dispositivo móvil transmita su ID de dispositivo móvil junto con una solicitud HTTP (tal como cómo se enviaría cuando se usan las cookies), en una realización de ejemplo diferente, el dispositivo móvil 10 envía su ID de dispositivo móvil a la pasarela de pago 8 en una segunda (o enésima) solicitud. Esto se dirige por una secuencia de comandos de lado de cliente (tal como ECMAScript, JavaScript, VBScript, ActiveX, etc.) o una aplicación integrada o plug-in (tal como Adobe Flash, Microsoft Silverlight, Java Applets, etc.) que se ejecuta en el dispositivo móvil 10 a la pasarela de pago 8. Aunque el orden de las operaciones puede cambiar, el resultado de transmitir las ID a la pasarela de pago 8 se logra en las diversas realizaciones.
Las realizaciones anteriores son compatibles con implementaciones existentes de 3D Secure. Los sistemas de comerciante que usan actualmente 3D Secure pueden no notar ninguna diferencia, como los sistemas y métodos propuestos reemplazan las páginas de autenticación de emisor existentes (por ejemplo, devueltas por el servidor de directorios), que sirven como un proxy a una página de autenticación de emisor subyacente.
Ejemplo 4: Control de acceso
Similar al ejemplo 3, otras realizaciones se usan para controlar el acceso a datos protegidos, sensibles o clasificados garantizando que un usuario pueda demostrar razonablemente que conoce un cierto hecho verificable sobre sí mismo y también puede demostrar razonablemente que tiene acceso físico a un dispositivo móvil de confianza 10. Dichas realizaciones controlan el acceso a, por ejemplo, información médica valiosa, miembros de la comunidad, portales corporativos, y otros datos protegidos de manera similar.
El proceso de registro solicita información personal identificable (por ejemplo, ID complementaria), tal como un número de seguros sociales o una licencia de conducir, que puede verificarse mediante un servidor complementario 22, operado por o en nombre de una entidad de crédito, banco, u otra autoridad. Si la asociación es exitosa, al dispositivo móvil 10 se le da la ID de dispositivo móvil derivada para su almacenamiento, y la pasarela de pago 8 conservará la ID de dispositivo móvil.
Cuando un dispositivo móvil conocido 10 (por ejemplo, un dispositivo móvil 10 que se ha utilizado con éxito para completar el proceso de registro o reasociación) solicita acceso a dichos datos protegidos, el dispositivo móvil 10 responde, desde una página de “inicio de sesión”, junto con la solicitud original que contiene un nombre de usuario y contraseña, como una cookie de HTTPS (o, menos probable, HTTP), su ID de dispositivo móvil a la pasarela de pago 8. El usuario solo necesita proporcionar la información identificable personal durante el proceso de transacción, y esto también se transmite a la pasarela de pago 8. La pasarela de pago 8 usa la ID de dispositivo móvil para recuperar el perfil de información asociada con la ID de dispositivo móvil. En particular, una URL de un sistema complementario de autenticación está asociada con la ID de dispositivo móvil, y la URL se usa para dirigir la transmisión de la información identificable personalmente al sistema complementario (por ejemplo, servidor complementario 22), que se usa para verificar la información identificable personal proporcionada.
Volviendo a la figura 11, la figura 12 y la figura 13, se proporcionan capturas de pantalla de ejemplo de interfaces gráficas de usuario (GUI) usadas en el proceso de registro y el proceso de transacción. Las GUI se mostrarán en una pantalla del dispositivo móvil 10. Las interfaces físicas del dispositivo móvil 10 pueden ser una pantalla táctil, panel táctil, rueda de seguimiento, bola de seguimiento, botones, etc., o combinaciones de los mismos, que pueden usarse para interactuar con las GUI.
En una realización de ejemplo, las GUI están alojadas por la pasarela de pago 8 y están configuradas para aparecer como parte del sitio web del minorista de comercio electrónico o de comercio desde teléfono móvil. En otras palabras, el minorista de comercio electrónico o de comercio desde teléfono móvil no necesita facilitar el proceso de autenticación de transacción. Esto reduce la responsabilidad para el minorista de comercio electrónico o de comercio desde teléfono móvil por gestionar la ID de pago y la ID complementaria.
La figura 11 muestra una captura de pantalla 156 para una GUI de registro. Se muestra una GUI de este tipo, por ejemplo, cuando se intenta completar un pago usando un dispositivo móvil 10 que no se ha registrado en la pasarela de pago 8. La captura de pantalla 156 incluye pestañas 132, 134, y 136 para seleccionar la visualización de información de pago, detalles, y dirección, respectivamente. La selección de la pestaña de detalles 134 mostrará, por ejemplo, lo que se está adquiriendo, mientras que seleccionar la pestaña de dirección 136 mostrará, por ejemplo, la dirección a la que se está enviando el servicio o artículo. Se puede apreciar que las pestañas 134 y 136 son opcionales. La pestaña de pago 132 está activa y, por lo tanto, muestra la información de pago. Los detalles de transacción 138 se visualizan e incluyen la cantidad de dinero 140 que se transferirá desde el usuario 142 que inició la transacción al comerciante o minorista. Se pueden visualizar detalles adicionales 14, tal como el orden o número de transacción. Se aprecia que el usuario no necesita introducir los detalles de transacción 138, ya que esto se puede recuperar automáticamente durante el proceso de compras de comercio electrónico o comercio desde teléfono móvil, desde el sitio web del comerciante.
Continuando con la figura 11, los campos de entrada 146, 148 y 150 se visualizan para permitir que el usuario introduzca en su número de tarjeta de crédito, fecha de caducidad de la tarjeta de crédito, y número CVV, respectivamente. Se puede apreciar que los campos de entrada 146 y 148 pueden ser generalmente para cualquier ID de pago, y el campo de entrada 150 puede ser generalmente para cualquier ID complementaria, según sea aplicable a los principios descritos en el presente documento.
Después de que el usuario introduzca la ID de pago y la ID complementaria, el usuario puede seleccionar o hacer clic en el botón 52 para enviar la información para el registro, y, en este ejemplo, para hacer también una compra si el registro está aprobado. El botón 152 lee “Pagar ahora con One Touch”, ya que los sistemas y métodos propuestos se pueden poner a disposición bajo la marca comercial “One Touch”. Opcionalmente, si el usuario no desea registrar su ID de pago y establecer una asociación con una ID de dispositivo móvil, según los sistemas y métodos propuestos descritos en el presente documento, el usuario puede seleccionar o hacer clic en el botón 154 para intentar simplemente completar la transacción usando la información proporcionada (por ejemplo, campos de entrada 146, 148, 150) y registro anterior.
La figura 12 muestra una captura de pantalla 158 de una GUI de transacción de ejemplo que usa el número de CVV como ID complementaria. Después de que el registro se haya realizado con éxito, de modo que el dispositivo móvil 10 tiene una ID de dispositivo móvil, y la pasarela de pago 8 tiene la ID de dispositivo móvil y la ID de pago asociada, la GUI en la captura de pantalla 158 aparece cuando un usuario inicia una transacción y se “comprueba”. Los detalles de transacción 138 se visualizan automáticamente. Además, una indicación de ID de pago 162, que indica la ID de pago, ya sea en parte o en su totalidad, se visualiza en la GUI de transacción. La indicación de ID de pago 162 en este ejemplo muestra que, basándose en la asociación entre la ID de pago y la ID de dispositivo móvil, el usuario está intentando realizar un pago usando una tarjeta de crédito Visa que termina en los dígitos '4242' (164). Preferiblemente, solo se muestra una parte de la ID de pago, como es en este ejemplo, para evitar que un adversario recupere la información de pago completa. La indicación de ID de pago 162 se recupera de la pasarela de pago 8 y se envía al dispositivo móvil 10 para su visualización. Sin embargo, en otra realización de ejemplo, puede no haber visualización de la indicación de ID de pago 162 para una medida de seguridad adicional. El campo de entrada 66 permite al usuario introducir su número de CVV (por ejemplo, ID complementaria). A continuación, el usuario selecciona o hace clic en el botón 168 para invocar el dispositivo móvil 10 para enviar el número CVV a la pasarela de pago 8, con el fin de completar la transacción.
En otra GUI de transacción de ejemplo, el botón 168 no se visualiza. En su lugar, la GUI puede detectar la longitud de cuántos caracteres se introdujeron en el campo de entrada 166. Después de que la GUI detecta que se ha introducido el número requerido de caracteres (por ejemplo, tres caracteres para un número CVV) en el campo de entrada 166, la ID complementaria se envía automáticamente. Por ejemplo, tras detectar que el dispositivo móvil 10 ha introducido tres dígitos en el campo de entrada 166, los tres dígitos se transmiten automáticamente a la pasarela de pago 8, que reenvía los mismos dígitos al módulo de verificación 23.
Volviendo a la figura 12, tras detectar que el dispositivo móvil 10 se ha seleccionado o pulsado el botón 170, el dispositivo móvil 10 mostrará otra GUI (no mostrada) que permita al usuario cambiar las cuentas de pago. Se puede apreciar que, en una realización de ejemplo, más de una ID de pago puede estar asociada con una ID de dispositivo móvil.
La figura 13 muestra otra realización de ejemplo de una captura de pantalla 172 para una GUI de transacción, mediante lo cual la ID complementaria es una contraseña bajo el sistema de verificación complementaria verificado por Visa. Se muestran los detalles de transacción 174, e incluyen la cantidad de pago y el nombre del comerciante. La indicación de ID de pago 162 también se muestra en la GUI. Un campo de entrada 176 permite que un dispositivo móvil 10 reciba la contraseña del usuario para el sistema verificado por Visa. El dispositivo móvil 10, al detectar una entrada de selección o hacer clic en el botón 178, envía la contraseña a la pasarela de pago 8, con el fin de que la pasarela de pago 8 envíe la ID de pago correspondiente y la ID complementaria al servidor complementario del servidor autorizado para la verificación. Opcionalmente, tras detectar la longitud de la contraseña, si la longitud de la contraseña es estándar, a continuación, el dispositivo móvil 10 envía automáticamente la misma a la pasarela de pago 8; no se requiere el botón 178.
Ventajosamente, como se muestra por las GUI y los métodos y sistemas propuestos anteriormente, un usuario solo necesita proporcionar su ID complementaria para ejecutar una transacción. Esto aumenta la seguridad ya que se requiere menos información sensible. Menos información también significa que se reduce el tiempo dedicado a ejecutar un pago. La reducción en el tiempo también aumenta la seguridad. En particular, el período de tiempo durante el cual se expone la información sensible requerida, se reduce. Desde la perspectiva del usuario, los métodos y sistemas propuestos reducen el número de etapas para completar transacciones, haciéndolas rápidas y fáciles.
Otros beneficios incluyen reducir el riesgo de completar accidentalmente una transacción, mientras que aún reduce significativamente el número de entradas. Al solicitar a un usuario una ID complementaria en el proceso de autenticación, que es rápido, simple, y conveniente de proporcionar, se evitan tales transacciones accidentales.
Riesgos de almacenar información sensible, tal como ID de pago, o ID complementaria, o ambas, en el dispositivo móvil 10 se reducen en gran medida desplazando el almacenamiento de dichos datos sensibles a un sistema de servidor externo seguro (por ejemplo, pasarela de pago 8, servidor complementario 22). Dichos servidores externos no permiten el acceso de lectura externo e imponen un control de acceso estricto. La asociación y recuperación de los datos se hace posible mediante el uso de la ID de dispositivo móvil.
También se reconoce que para la ID complementaria se considera fiable, existe un requisito de al menos un control de acceso razonable. Un elemento testigo de tipo token compartido, tal como un número de tarjeta de crédito, que se proporciona a cualquier número de terceros, no tiene acceso controlado razonablemente; por lo tanto, un número de tarjeta de crédito no es una ID complementaria razonable para la autenticación. Asignando una ID de dispositivo móvil, que tiene la suposición de un control de acceso razonable, que identifica de manera única un dispositivo móvil 10, un sistema de autenticación de factor único existente puede convertirse en un sistema de autenticación de dos factores. Además, mediante la introducción de una ID complementaria, tal como un pin o contraseña, que solo se conoce por el usuario y no se almacena de manera persistente en el dispositivo móvil 10 o la pasarela de pago 8, un atacante no puede completar una transacción sin el conocimiento de la ID complementaria.
Cuando se atacan sistemas o protocolos, una característica de buen diseño es la indicación de tal ataque a todas las partes involucradas. Desafortunadamente, el diseño tradicional y la implementación de los sistemas de comercio electrónico y de comercio desde teléfono móvil rara vez exhiben esta característica, potencialmente poniendo a todas las partes en riesgo. Introducir un número de secuencia de transacción impredecible, que se genera y comparte entre el dispositivo móvil 10 y la pasarela de pago 8 después de cada transacción satisfactoria, cuando se usa junto con la ID de dispositivo móvil del dispositivo móvil, permite que la pasarela de pago 8 establezca que un dispositivo móvil 10 está realizando una transacción con conocimiento de la secuencia actual. Por consiguiente, si la pasarela de pago 8 identifica una transacción fuera de secuencia, la pasarela de pago 8 puede informar a todas las partes (por ejemplo, servidor de pago 20, servidor complementario 22) de potencial manipulación o compromiso. En tal escenario, la pasarela de pago 8 puede denegar transacciones adicionales desde el dispositivo móvil específico 10 hasta que se resuelva el problema.
Adicionalmente, reduciendo el número de veces que se solicitan las ID de un usuario, según algunas realizaciones descritas en el presente documento, el riesgo de ataques de intercepción puede reducirse significativamente o eliminarse por completo.
En otro aspecto, los sistemas y métodos propuestos permiten a un comerciante externalizar su procesamiento de tarjeta de crédito a un proveedor de terceros que ya tiene certificación PCI-DSS (por ejemplo, el proveedor de terceros que opera la pasarela de pago 8), de modo que el comerciante puede no tener que someterse a tal certificación por sí mismo.
En otro aspecto, una transacción, como se describe en el presente documento, depende del dispositivo móvil físico 10 desde el cual se inicia la transacción. Como se describe en el presente documento, limitando o especificando un dispositivo móvil particular 10 usando la ID de dispositivo móvil, solo un dispositivo móvil físico 10 puede iniciar sesión en, o realizar comandos autorizados en relación con la pasarela de pago 8 con la cuenta de un usuario. Por lo tanto, un atacante no puede usar otro dispositivo móvil 10 para realizar actividades fraudulentas.
Se reconoce además que no se requiere que los emisores sigan reglas de implementación estrictas, dando como resultado páginas web de autenticación inconsistentes que son difíciles de verificar (a diferencia de, por ejemplo, si la página de autenticación estuviera alojada en un dominio esperado, tal como “vbv.visa.com” o “securecode.mastercard.com” ). Al introducir una única página web de autenticación bien conocida, reconocible y consistente, los titulares de tarjeta de crédito pueden prestar más atención a sutilezas menores (y mayores), que puede estar presente en sitios web de phishing. De hecho, creando un único dominio dedicado responsable de la autenticación de emisor, tal como un dominio alojado por la pasarela de pago 8, los titulares de tarjeta de crédito pueden estar más dispuestos y ser capaces de verificar el certificado SSL y URL para asegurarse de que él o ella ha llegado a la página web de autenticación de emisión oficial. Además, presentando al titular de tarjeta de crédito información personal verificable familiar (por ejemplo, ID complementaria), el titular de tarjeta de crédito puede tener incluso más certeza de que se está comunicando con la autoridad legítima 3D Secure.
En general, se proporciona un sistema para autenticar una transacción en un dispositivo móvil. El sistema comprende un dispositivo móvil en comunicación con una pasarela de pago, la pasarela de pago en comunicación con un módulo de verificación. En un proceso de registro: el dispositivo móvil está configurado para recibir al menos una ID de pago de una cuenta de pago y una ID complementaria para verificar la ID de pago, y transmitir la ID de pago y la ID complementaria a la pasarela de pago; la pasarela de pago está configurada para enviar la ID de pago y la ID complementaria al módulo de verificación, el módulo de verificación configurado para verificar la ID complementaria y la ID de pago; y, al menos uno del dispositivo móvil y la pasarela de pago configurados para, tras recibir la pasarela de pago un resultado de verificación desde el módulo de verificación de que la ID de pago y la ID complementaria se verifican con éxito, generar una ID de dispositivo móvil, la ID de dispositivo móvil almacenada en el dispositivo móvil y almacenada en la pasarela de pago en asociación con la ID de pago.
En un proceso de transacción: el dispositivo móvil está configurado para recibir la ID complementaria y enviar la ID complementaria y la ID de dispositivo móvil a la pasarela de pago; la pasarela de pago está configurada para recuperar la ID de pago asociada con la ID de dispositivo móvil recibida y enviar la ID de pago y la ID complementaria al módulo de verificación para su verificación; y, después de que la pasarela de pago reciba otro resultado de verificación desde el módulo de verificación de que la ID complementaria y la ID de pago se verifican con éxito, la pasarela de pago está configurada para ejecutar la transacción.
En otro aspecto, el dispositivo móvil está configurado para enviar al menos una de la ID complementaria y la ID de pago sin almacenar la ID complementaria y la ID de pago en el dispositivo móvil. En otro aspecto, las operaciones de la pasarela de pago y el módulo de verificación se combinan en un servidor unificado. En otro aspecto, la pasarela de pago ejecuta la transacción a través de un servidor de pago, el servidor de pago en comunicación con al menos uno de la pasarela de pago y el módulo de verificación.
En general, también se proporciona un sistema para autenticar una transacción. El sistema comprende una pasarela de pago, un módulo de verificación y un servidor de pago. La pasarela de pago está en comunicación con al menos uno del servidor de pago y el módulo de verificación, teniendo la pasarela de pago almacenada en la misma una ID de dispositivo móvil en asociación con una ID de pago. El servidor de pago está en comunicación con al menos uno de la pasarela de pago y el módulo de verificación. En una transacción: la pasarela de pago está configurada para recibir la ID de dispositivo móvil y una ID complementaria, la ID complementaria para verificar la ID de pago; la pasarela de pago está configurada para recuperar la ID de pago asociada con la ID de dispositivo móvil, y configurada para enviar la ID de pago y la ID complementaria al módulo de verificación; y, después de que el módulo de verificación verifique sucesivamente la ID de pago y la ID complementaria, el servidor de pago configurado para ejecutar la transacción.
En otro aspecto, un dispositivo móvil está en comunicación con la pasarela de pago, en el que el dispositivo móvil está configurado para enviar la ID de dispositivo móvil y la ID complementaria a la pasarela de pago. En otro aspecto, el servidor de pago está en comunicación tanto con la pasarela de pago como con el módulo de verificación, y la pasarela de pago está configurada para enviar la ID complementaria y la ID de pago al módulo de verificación a través del servidor de pago.
En otro aspecto, el módulo de verificación está configurado para enviar un resultado de verificación con éxito a al menos uno del servidor de pago y la pasarela de pago. En otro aspecto, la pasarela de pago está configurada para enviar la ID complementaria sin almacenar la ID complementaria en la pasarela de pago. En otro aspecto, la ID de pago está compuesta por al menos uno de: un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, y un número de cuenta de puntos. En otro aspecto, la ID complementaria está compuesta por al menos uno de: un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), una verificación de código de tarjeta (CCV), un pin, una contraseña, datos biométricos, y datos de voz.
En otro aspecto, la ID de dispositivo móvil incluye al menos uno de: información de identidad de abonado almacenada en una tarjeta SIM o IMEI del dispositivo móvil, información de red, una dirección IP, una identificación de operador telefónico, una dirección de puerto, un nombre de DNS, una coordenada GPS del dispositivo móvil, la temperatura de batería del dispositivo móvil, una ubicación geográfica del dispositivo móvil, una lectura de acelerómetro del dispositivo móvil, una cookie, un agente de usuario, y un encabezado, en donde la cookie, el agente de usuario y el encabezado se proporcionan por un navegador en el dispositivo móvil o un almacenamiento DOM en el dispositivo móvil.
En otro aspecto, la ID de dispositivo móvil se genera aleatoriamente. En otro aspecto, la ID de dispositivo móvil se reemplaza por una nueva ID de dispositivo móvil y se asocia con la ID de pago para cada ejecución posterior del proceso de transacción. En otro aspecto, durante el proceso de transacción, la pasarela de pago compara la ID de dispositivo móvil recibida con la ID de dispositivo móvil previamente almacenada en la misma para determinar si son similares, y si es así, permitir que se ejecute la transacción. En otro aspecto, la ID de dispositivo móvil recibida en el proceso de transacción debe ser igual a la ID de dispositivo móvil previamente almacenada en la pasarela de pago para que se ejecute la transacción.
En general, también se proporciona un método para autenticar una transacción en un dispositivo móvil, teniendo almacenado el dispositivo móvil en el mismo una ID de dispositivo móvil, el método se realiza en el dispositivo móvil. El método comprende: recibir mediante el dispositivo móvil a través de una GUI de transacción una ID complementaria para verificar una ID de pago; enviando el dispositivo móvil la ID complementaria y la ID de dispositivo móvil a una pasarela de pago, teniendo la pasarela de pago almacenada en la misma la ID de pago y la ID de dispositivo móvil en asociación entre sí; y, después de que la pasarela de pago ejecute la transacción basándose en la ID de pago asociada con la ID de dispositivo móvil y reciba la verificación de que la ID complementaria y la ID de pago son auténticas, recibir mediante el dispositivo móvil desde la pasarela de pago una confirmación de que la transacción está completa.
En otro aspecto, el dispositivo móvil envía al menos una de la ID complementaria y la ID de pago sin almacenar la ID complementaria y la ID de pago en el dispositivo móvil.
En otro aspecto, el método incluye un proceso de registro para almacenar la ID de dispositivo móvil en el dispositivo móvil, comprendiendo además el método: recibir mediante el dispositivo móvil desde una GUI de registro al menos la ID de pago de una cuenta de pago y la ID complementaria, y transmitir la ID de pago y la ID complementaria a la pasarela de pago sin almacenar la ID de pago y la ID complementaria en el dispositivo móvil; y, el dispositivo móvil, tras recibir de la pasarela de pago que la ID de pago y la ID complementaria se verifican con éxito, obtener un componente para una ID de dispositivo móvil, la ID de dispositivo móvil asociada con la ID de pago en la pasarela de pago, y la ID de dispositivo móvil almacenada en el dispositivo móvil. En otro aspecto, el dispositivo móvil obtiene el componente para la ID de dispositivo móvil mediante al menos uno de generar y recibir el componente.
En general, también se proporciona un método para autenticar una transacción en una pasarela de pago, teniendo la pasarela de pago almacenada en la misma una ID de dispositivo móvil en asociación con una ID de pago, comprendiendo el método realizado en la pasarela de pago: recibir mediante la pasarela de pago desde un dispositivo móvil una ID complementaria y la ID de dispositivo móvil, la ID complementaria para verificar la ID de pago, y teniendo almacenado el dispositivo móvil en el mismo la ID de dispositivo móvil; recuperar mediante la pasarela de pago la ID de pago asociada con la ID de dispositivo móvil y enviar la ID de pago y la ID complementaria a un módulo de verificación para su verificación; y, después de recibir mediante la pasarela de pago un resultado de verificación desde el módulo de verificación de que la ID complementaria y la ID de pago se verifican con éxito, ejecutar mediante la pasarela de pago la transacción.
En otro aspecto, el método incluye un proceso de registro para almacenar la ID de dispositivo móvil y la ID de pago en la pasarela de pago, comprendiendo además el método: recibir mediante la pasarela de pago del dispositivo móvil al menos la ID de pago de una cuenta de pago y la ID complementaria, y transmitir la ID de pago y la ID complementaria al módulo de verificación; y, después de recibir mediante la pasarela de pago un resultado de verificación inicial del módulo de verificación de que la ID de pago y la ID complementaria se verifican con éxito, la pasarela de pago obtiene un componente para una ID de dispositivo móvil, la ID de dispositivo móvil asociada con la ID de pago y almacenada en la pasarela de pago, y la ID de dispositivo móvil almacenada en el dispositivo móvil.
En otro aspecto, la pasarela de pago obtiene el componente para la ID de dispositivo móvil mediante al menos uno de generar y recibir el componente.
En otro aspecto, la pasarela de pago ejecuta la transacción a través de un servidor de pago, el servidor de pago en comunicación con al menos uno de la pasarela de pago y el módulo de verificación.
En general, también se proporciona un método para autenticar una transacción, comprendiendo el método: recibir mediante una pasarela de pago una ID de dispositivo móvil y una ID complementaria, la ID complementaria para verificar una ID de pago; recuperando la pasarela de pago la ID de pago asociada con la ID de dispositivo móvil, la ID de pago y la ID de dispositivo móvil que se almacenan en la pasarela de pago en asociación entre sí, y enviar la ID de pago y la ID complementaria a un módulo de verificación; después de verificar con éxito el módulo de verificación la ID de pago y la ID complementaria, un servidor de pago que ejecuta la transacción, el servidor de pago en comunicación con al menos uno de la pasarela de pago y el módulo de verificación.
Volviendo brevemente a la figura 14 y la figura 15, las operaciones anteriores se muestran más generalmente en forma de diagrama de flujo dividido según el dispositivo móvil 10, la pasarela de pago 8, y el módulo de verificación 23. En particular, en la figura 14, que muestra el proceso de registro, en el bloque 180, el dispositivo móvil 10 puede usar la GUI 156 de ejemplo para recibir la ID de pago y la ID complementaria. Notablemente, la ID de dispositivo móvil puede generarse en el dispositivo móvil 10 o en la pasarela de pago 8, según el bloque 184. La ID de dispositivo móvil puede generarse alternativamente antes en el proceso de registro. En la figura 15, que muestra el proceso de transacción, en el bloque 182, el dispositivo móvil 10 puede usar las GUI 158 o 172 de ejemplo para recibir la ID complementaria. Además, como se describió anteriormente, por ejemplo, con respecto a las figuras 3, 4, 5 y 6, tras verificar con éxito la ID complementaria y la ID de pago, una cualquiera o más de la pasarela de pago 8, servidor complementario 22 (por ejemplo, emisor), y el servidor de pago 20 (por ejemplo, adquirente) puede ejecutar el proceso de pago o liquidación.
En otro aspecto de los sistemas y métodos propuestos, se reconoce que después de que se haya realizado una transacción, un usuario puede disputar la transacción. En otras palabras, el usuario puede afirmar que no ha realizado o permitido la transacción, y que la transacción se realizó por error. Por ejemplo, el minorista cargó incorrectamente al usuario por la transacción usando la ID de pago, o un adversario ha asumido falsamente la identidad del usuario y ha realizado un pago usando la ID de pago del usuario.
Se reconoce además que es difícil para un servidor de pago 20 o un banco emisor (por ejemplo, la entidad que realiza el pago al minorista) para confirmar si la transacción fue o no autorizada realmente por el usuario. En situaciones en las que parece que el usuario no ha autorizado la transacción, los fondos de la transacción se devuelven al usuario. En otras palabras, hay un proceso de devolución de cargos en el que los fondos del servidor de pago 20 (o banco emisor) y la pasarela de pago 8, o ambos, se devuelven al usuario.
Los sistemas y métodos propuestos proporcionan una manera de confirmar si una transacción fue realmente autorizada o no por el usuario, de esta manera, liquidando las disputas de devolución de cargos. El dispositivo móvil 10 genera una firma digital usando datos de transacción y, durante una disputa de devolución de cargos, la firma digital se usa para confirmar si el usuario realmente aprobó o no la transacción.
Volviendo a la figura 16, se proporcionan instrucciones ejecutables por ordenador de ejemplo para generar una firma digital. En el bloque 201, se obtiene una clave privada (por ejemplo, a partir de una base de datos de claves de cifrado) o se genera. La clave privada puede obtenerse o generarse por la pasarela de pago 8. En otra realización de ejemplo, la clave privada puede obtenerse o generarse por el dispositivo móvil 10, el servidor de pago 20, el servidor complementario 22, o el módulo de verificación 23. La clave privada se puede generar usando, por ejemplo, un generador de números aleatorios o generador de números pseudoaleatorios.
En otra realización de ejemplo, la clave privada puede incluir datos relacionados con una red de comunicación, tal como una red de telefonía celular. Por ejemplo, un número de teléfono, o datos derivados del número de teléfono, o la identidad internacional de equipo móvil (IMEI), puede incluirse en la clave privada.
La clave privada se cifra usando una clave, en el presente documento denominada clave secundaria, (bloque 203) y a continuación almacenarse en el dispositivo móvil 10 (bloque 205). La clave secundaria, por ejemplo, es una ID complementaria. Se apreciará que la clave secundaria usada para cifrar la clave privada puede o no ser la ID complementaria. En otra realización de ejemplo, la clave secundaria se deriva de o es una función de la ID complementaria. Por ejemplo, puede usarse una función de derivación de clave, tal como PBKDF2.
Se apreciará que usar la ID complementaria para derivar o formar la clave secundaria puede ser ventajoso si se requiere que el usuario proporcione la clave secundaria. El usuario recuerda una credencial menos, como ID complementaria se usa para verificación y para derivar o formar la clave secundaria.
La pasarela de pago 8 puede cifrar la clave privada. Alternativamente, el dispositivo móvil 10, el servidor de pago 20, el servidor complementario 22, o el módulo de verificación 23 pueden cifrar la clave privada. La clave privada se puede cifrar usando diversos métodos de cifrado conocidos. Ejemplos no limitantes de métodos de cifrado incluyen cifrados simétricos fuertes, tales como Estándar de Cifrado Avanzado (AES) y Twofish. En otra realización de ejemplo, se usa un cifrado de encriptación con un modo de operación que ayuda a prevenir ataques de texto sin formato y oculta patrones, por ejemplo, encadenamiento de bloques de cifrado (CBC).
Los bloques 201, 203, 205 pueden tener lugar durante el proceso de registro, o cualquier tiempo previo a una transacción. Por ejemplo, se puede obtener o generar una clave privada antes o durante un proceso de registro. En una realización de ejemplo, durante el proceso de registro, cuando la ID complementaria se pasa desde el dispositivo móvil 10 a la pasarela de pago 8, la clave privada se cifra usando la clave (por ejemplo, la ID complementaria) y se almacena en el dispositivo móvil 10. En otra realización de ejemplo, el proceso de obtención y almacenamiento de la clave privada en el dispositivo móvil 10 puede ocurrir por separado del proceso de registro.
Continuando con la figura 16, en el bloque 207, el dispositivo móvil recibe la ID complementaria (por ejemplo, del usuario). A continuación, el dispositivo móvil 10 descifra la clave privada cifrada usando la clave secundaria (bloque 2098). El dispositivo móvil 10 usa la clave privada para firmar datos de transacción, y opcionalmente la ID de dispositivo móvil, para crear una firma digital (bloque 210). Los ejemplos de firmas digitales incluyen las de los siguientes tipos: RSA, DSA, y ECC. La firma digital se almacena entonces para que pueda recuperarse en un tiempo posterior (bloque 213). Por ejemplo, la firma digital se almacena en al menos uno de la pasarela de pago 8, el servidor de pago 20, el módulo de verificación 23, el servidor complementario 22, y el dispositivo móvil 10.
El término “datos de transacción” puede incluir al menos uno de los siguientes: el número de factura de la transacción, cantidad de pago, la fecha de la transacción, el tiempo de la transacción, la dirección de envío, la dirección de facturación, el correo electrónico del comprador, y el número de teléfono del comprador. Además de firmar los datos de transacción, el dispositivo móvil puede, por ejemplo, también firmar la ID de dispositivo móvil y la ID complementaria.
En una realización de ejemplo, los datos de transacción originales se ponen a disposición de al menos uno de la pasarela de pago 8, el servidor de pago 20, el módulo de verificación 23, y el servidor complementario 22. Durante el proceso de verificación, los datos de transacción proporcionados pueden verificarse contra la firma digital usando un esquema de verificación de firma.
Volviendo a la figura 17, se proporcionan instrucciones ejecutables por ordenador de ejemplo para liquidar una disputa de devolución de cargos utilizando la firma digital. En el bloque 215, se recibe una disputa con respecto a una transacción, y la disputa incluye los datos de transacción. En el bloque 217, se recupera la firma digital asociada con los datos de transacción. Por ejemplo, los datos de transacción se usan para buscar e identificar la firma digital correspondiente. A continuación, la firma digital se proporciona para liquidar la disputa (bloque 219). La firma digital se verifica usando un esquema de verificación de firma digital (bloque 221) y se determina si la verificación es satisfactoria o no (bloque 222). Se apreciará que el tipo de esquema de verificación puede depender del algoritmo de firma que se usó. Más generalmente, varios esquemas de verificación de firma digital son aplicables a los principios descritos en el presente documento.
En una realización de ejemplo, si la clave privada está cifrada con una clave secundaria que se considera que tiene baja entropía, a continuación, la clave pública correspondiente se mantiene en secreto y no es fácilmente alcanzable.
Se supone que solo el dispositivo móvil 10 del usuario tiene la clave privada, que es única para el dispositivo móvil 10 o usuario (por ejemplo, si el usuario tiene múltiples dispositivos móviles). Por lo tanto, por ejemplo, si se verifica la firma digital, entonces se confirma que la transacción fue realizada por el dispositivo móvil que tiene acceso a la clave privada, y, por lo tanto, fue realmente autorizada por el usuario (bloque 226). De lo contrario, si la firma digital no se verifica con éxito, entonces se confirma que la transacción no fue realizada por un dispositivo móvil que tiene acceso a la clave privada, y, por lo tanto, no fue autorizada por el usuario (bloque 224).
La clave privada puede almacenarse en una aplicación de Internet (por ejemplo, un navegador web) en el dispositivo móvil 10. En otra realización de ejemplo, la clave privada puede almacenarse en un módulo de plataforma de confianza en el dispositivo móvil. En otra realización de ejemplo, la clave privada puede almacenarse en un chip de comunicaciones de campo cercano (NFC) en el dispositivo móvil. En otra realización de ejemplo, la clave privada puede almacenarse en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil. En otra realización de ejemplo, la clave privada puede almacenarse en una tarjeta digital segura (SD), u otro dispositivo de almacenamiento retirable, en el dispositivo móvil. La clave privada también puede almacenarse en el almacenamiento o memoria de una aplicación en el dispositivo móvil. La aplicación puede no estar relacionada con la aplicación de Internet.
En una realización de ejemplo, el banco emisor es una entidad separada del servidor de pago 20. En dicho ejemplo, el banco emisor emite una disputa de devolución de cargos que incluye los datos de transacción. El servidor de pago 20 recibe los datos de transacción y disputa de devolución de cargos y recupera la firma digital para liquidar la disputa de devolución de cargos.
En otra realización de ejemplo de generación de una firma digital, la clave privada no está cifrada. Volviendo a la figura 18, en el bloque 250, se genera una clave privada y se almacena en el dispositivo móvil (bloque 252). Las operaciones 250 y 252 pueden tener lugar durante el registro o en cualquier tiempo anterior a una transacción. Durante una transacción, el dispositivo móvil 10 usa una clave privada para firmar los datos de transacción para crear una firma digital (bloque 254). La firma digital se almacena para que pueda recuperarse más tarde (bloque 256).
Cuando cualquiera de los servidores de pago 20 recibe una disputa de devolución de cargos con respecto a una transacción, la pasarela de pago 8, o el dispositivo móvil 10, incluyendo los datos de transacción (bloque 258), la entidad respectiva recupera la firma digital asociada con los datos de transacción (bloque 260). La firma digital se proporciona a continuación para liquidar la disputa (bloque 262). La disputa se liquida determinando si la firma digital se verifica o no con éxito.
En una realización de ejemplo, cuanto mayor sea el número de firmas digitales que se han verificado para un dispositivo móvil dado o una clave privada dada, mayor será la confianza que la verificación exitosa de la firma digital evidencia que la transacción no es fraudulenta. En otras palabras, con cada verificación exitosa posterior de una firma digital asociada con un dispositivo móvil dado o una clave privada dada, aumenta la confianza de que la verificación exitosa demuestra que la transacción es auténtica.
Se supone que la clave privada se almacena de manera segura en el dispositivo móvil 10, y que la clave privada se usa para firmar los datos de transacción solo durante una transacción. Además, se reconoce que la acción del usuario que introduce la ID complementaria en el dispositivo móvil 10 durante una transacción es una indicación de que el usuario autoriza la transacción. Por lo tanto, no se requiere que la clave privada se almacene en el dispositivo móvil 10 en una forma cifrada. Al no cifrar la clave privada, se reduce el número de etapas y se aumenta la velocidad del proceso.
Por lo tanto, se apreciará que la clave privada utilizada en la generación de firmas digitales puede cifrarse o, en otras realizaciones de ejemplo, no cifrarse.
En otro aspecto, se utiliza un MAC para liquidar disputas de devolución de cargos. Tanto el dispositivo móvil 10 como un dispositivo informático (por ejemplo, pasarela de pago 8 o módulo de verificación 23) tienen una clave secreta (por ejemplo, una clave secreta compartida) que se usan para generar MAC a partir de los datos de transacción. Por ejemplo, el dispositivo móvil 10 genera un primer MAC usando los datos de transacción en el tiempo de la transacción, y un dispositivo informático genera un segundo MAC usando los datos de transacción. Si el primer y el segundo MAC son idénticos, entonces se determina que la transacción fue autorizada por el usuario. De lo contrario, la transacción se considera fraudulenta.
La clave secreta, por ejemplo, es única para cada dispositivo móvil o puede ser única para un usuario.
La figura 19 proporciona instrucciones ejecutables por ordenador de ejemplo para liquidar una disputa de devolución de cargos utilizando MAC. En el bloque 251 se genera una clave secreta, por ejemplo, o bien por el dispositivo móvil o bien el dispositivo informático, o ambos. La clave secreta se almacena tanto en el dispositivo móvil 10 como en el dispositivo informático (por ejemplo, pasarela de pago, servidor de pago, módulo de verificación) (bloque 253). Los bloques 251 y 253 pueden ocurrir antes de una transacción, tal como durante un proceso de registro. Se apreciará que la clave secreta se almacena en al menos una de una aplicación de Internet en el dispositivo móvil, en un módulo de plataforma de confianza en el dispositivo móvil, en un chip NFC en el dispositivo móvil, en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil, en un dispositivo de almacenamiento retirable en el dispositivo móvil, y en el almacenamiento de una aplicación en el dispositivo móvil.
La clave secreta también puede estar cifrada, por ejemplo, usando una clave secundaria. La clave secundaria puede ser una función de una ID complementaria.
Durante una transacción, el dispositivo móvil 10 aplica un algoritmo de MAC a los datos de transacción usando la clave secreta para generar un primer MAC (bloque 255). En el bloque 257, el dispositivo móvil 10 almacena el primer MAC en el dispositivo informático (por ejemplo, pasarela de pago, servidor de pago, módulo de verificación) o en el dispositivo móvil 10.
Si la clave secreta está cifrada, luego se descifra primero para que se pueda usar para generar el primer MAC. Por ejemplo, si la clave secundaria se usa para descifrar la clave secreta cifrada, el usuario puede introducir en el dispositivo móvil 10 la información (por ejemplo, ID complementaria) necesaria para derivar la clave secundaria. La clave secundaria derivada se usa luego para descifrar la clave secreta.
En otra realización de ejemplo, el primer MAC se calcula aplicando un algoritmo de MAC a los datos de transacción y una ID de dispositivo móvil. De esta manera, el primer MAC puede usarse para identificar mejor que se generó a partir del dispositivo móvil 10.
Continuando con la figura 19, después de que se complete la transacción, un dispositivo informático (por ejemplo, pasarela de pago, servidor de pago, módulo de verificación) recibe una disputa con respecto a una transacción que incluye datos de transacción (bloque 259). Por ejemplo, el dispositivo informático recibe el primer MAC del dispositivo móvil 10. A continuación, el dispositivo informático recupera el primer MAC asociado con los datos de transacción (bloque 261). A continuación, el dispositivo informático calcula un segundo MAC utilizando la clave secreta y los datos de transacción (bloque 263). En una realización de ejemplo, el mismo algoritmo de MAC usado para calcular el primer MAC puede usarse para calcular el segundo MAC. En el bloque 265, el dispositivo informático determina si la transacción es fraudulenta o no basándose en una comparación del primer MAC y el segundo MAC.
En particular, se determina que la transacción es fraudulenta si el primer MAC y el segundo MAC son diferentes. De lo contrario, se determina que la transacción no es fraudulenta si el primer MAC y el segundo MAC son iguales.
El dispositivo informático también puede determinar si una transacción posterior es fraudulenta o no verificando MAC posteriores usando la clave secreta. Si los MAC posteriores proporcionan un resultado de verificación que es exitoso, a continuación, el dispositivo informático aumenta un valor de confianza o nivel de confianza en el que el resultado de verificación asociado con el dispositivo móvil o la clave secreta demuestra que la transacción posterior no es fraudulenta.
En una realización de ejemplo, la clave secreta puede almacenarse en el dispositivo informático en forma cifrada. En otro ejemplo, el dispositivo informático recibe del dispositivo móvil 10 una clave secundaria usada para descifrar la clave secreta cifrada almacenada en el dispositivo informático. Como se describió anteriormente, la clave secundaria es en función de la ID complementaria. En otras palabras, el dispositivo móvil genera la clave secundaria usando la ID complementaria y envía la clave secundaria al dispositivo informático.
También se puede apreciar que el MAC puede ser un MAC basado en cifrado (CMAC), tales como CMAC-AES y CMAC-TDES. El MAC también puede ser un MAC basado en hash (HMAC), tal como HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, y HMAC-RIPEMD. Se apreciará que se pueden aplicar varios tipos de MAC a los principios descritos en el presente documento.
En otro aspecto de los sistemas y métodos propuestos, se usa una firma digital para autenticar una transacción. Antes de una transacción, por ejemplo, durante el registro, una clave privada se almacena en el dispositivo móvil 10. Durante una transacción, el dispositivo móvil 10 firma datos de transacción para crear una firma digital. El módulo de verificación 23 u otra entidad de servidor obtiene la ID de pago y la firma digital y verifica la firma digital. Si la firma digital se verifica con éxito, usa la ID de pago para ejecutar una transacción. Los detalles se describen con respecto a las figuras 20, 21 y 22.
Volviendo a la figura 20, se proporcionan instrucciones ejecutables por ordenador de ejemplo para registrar una ID de dispositivo móvil y una ID de pago. Durante el proceso de registro, o cualquier tiempo previo al proceso de transacción, se genera una clave privada. La clave privada se almacena en el dispositivo móvil 10. Opcionalmente, la clave privada está cifrada, y la clave privada cifrada se almacena en el dispositivo móvil 10.
En particular, en el bloque 264, el dispositivo móvil 10 recibe la ID de pago y la ID complementaria y envía la misma a la pasarela de pago 8. La pasarela de pago 8 envía las ID al módulo de verificación 23 (bloque 266) para su verificación (bloque 268). El módulo de verificación 23 envía el resultado de verificación (bloque 270), y al recibir (bloque 272), la pasarela de pago 8 envía confirmación de registro al dispositivo móvil 10 (bloques 274 y 276). Durante el proceso de registro, antes o después de la verificación, se genera una ID de dispositivo móvil (bloque 278) y se guarda en el dispositivo móvil (bloque 280) y en la pasarela de pago 8 en asociación con la ID de pago (bloque 282). También tiene lugar en algún tiempo durante el proceso de registro la generación de la clave privada (bloque 284), que se puede cifrar usando una clave secundaria (bloque 286). La clave privada, que puede o no estar cifrada, se almacena en el dispositivo móvil 10 (bloque 290).
Volviendo a la figura 21, durante una transacción, el dispositivo móvil 10 recibe una entrada para ejecutar una transacción. Si la clave privada se cifra usando una clave secundaria, entonces la entrada puede incluir la clave secundaria (bloque 290). El dispositivo móvil 10 descifra la clave privada cifrada usando la clave secundaria (bloque 292). Sin embargo, si la clave privada no está cifrada en el dispositivo móvil 10, a continuación, no se ejecutan las operaciones de proporcionar una clave secundaria y descifrar la clave privada.
El dispositivo móvil 10 firma los datos de transacción usando la clave privada para generar una firma digital (bloque 294). En el bloque 296, el dispositivo móvil envía la firma digital y la ID de dispositivo móvil a la pasarela de pago 8. El dispositivo móvil 10 también puede enviar los datos de transacción, que pueden usarse para verificar la firma digital. En el bloque 298, usando la ID de dispositivo móvil, la pasarela de pago 8 recupera la ID de pago asociada. En el bloque 300, al menos uno de la pasarela de pago 8, el módulo de verificación 23 y el servidor de pago 20 verifican la firma digital. Se apreciará que, si el esquema de verificación que se emplea usa los datos de transacción originales, a continuación, los datos de transacción originales se ponen a disposición de la entidad que verifica la firma digital. Si el resultado de verificación es exitoso, entonces el pago o transacción se habilita usando la ID de pago, por ejemplo, a través del servidor de pago 20 (bloque 302). Por ejemplo, al servidor de pago 20 se le da una instrucción ejecutable por ordenador para procesar el pago para la transacción.
A continuación, se puede enviar una confirmación de que la transacción se ha completado al dispositivo móvil 10 y visualizarse en la GUI del dispositivo móvil.
En otra realización de ejemplo, la operación del bloque 298 solo se puede realizar después de verificar con éxito la firma digital (bloque 300).
Volviendo a la figura 22, se proporciona otra realización de ejemplo de autenticación de una transacción usando una firma digital. Similar a la figura 21, en el bloque 291, el dispositivo móvil 10 recibe una ID complementaria. Si la clave privada está cifrada, el dispositivo móvil 10 descifra la clave privada usando una clave secundaria (bloque 292). Como se describe, la clave secundaria puede ser una función de la ID complementaria, y, por lo tanto, la ID complementaria se usa para descifrar la clave privada. Los bloques 294 y 296, se realizan como se describió anteriormente.
La pasarela de pago 8 verifica la firma digital (bloque 297). La pasarela de pago 8 recupera la ID de pago asociada con la ID de dispositivo móvil, y envía la ID de pago y la ID complementaria al módulo de verificación 23 para su verificación (bloque 299). En el bloque 301, el módulo de verificación verifica la ID de pago y la ID complementaria, por ejemplo, comparando las ID con las ID previamente almacenadas. En el bloque 303, si la firma digital se verifica con éxito y la ID de pago y la ID complementaria se verifican con éxito, entonces se habilita el pago de la transacción, por ejemplo, a través del servidor de pago 20.
Se puede apreciar que usar una firma digital como se describe en las figuras 20, 21 y 22 permite tanto que una transacción se autentique, así como también que se proporcione una firma digital que puede usarse para liquidar disputas de devolución de cargos si surgen. El uso de una firma digital también permite a una pasarela de pago y a un comerciante ahorrar dinero en tarifas de transacción donde las transacciones no se envían con una firma válida. Por ejemplo, la pasarela de pago 8 no procesaría una transacción que tiene una firma no válida, ya que dicha transacción puede evitarse o pueden devolverse los cargos.
Adicionalmente, una firma digital permite validar la transacción cuando se transmite a través de un protocolo no fiable. Una firma digital también evita que un ataque de intermediario cambie con éxito cualquier valor crítico (por ejemplo, cantidad total de fondos para la transacción, número de factura, dirección de envío, etc.).
Los principios anteriores con respecto al uso de una firma digital para autenticar una transacción también se aplican a los MAC. En lugar de firmar datos de transacción para crear una firma digital, se aplica un algoritmo de MAC a los datos de transacción para generar un primer MAC en el dispositivo móvil y un segundo MAC en el dispositivo informático (por ejemplo, pasarela de pago, servidor de pago, módulo de verificación). Si el primer y segundo MAC son iguales, luego se autentica la transacción y se habilita el pago. Las operaciones son muy similares a las operaciones descritas en la figura 20, 21 y 22, sin embargo, en lugar de generar y verificar firmas digitales, los MAC se generan y verifican usando una clave secreta disponible para ambos del dispositivo móvil y el dispositivo informático.
En particular, un dispositivo móvil 10 recibe una entrada para ejecutar la transacción. El dispositivo móvil 10 calcula un primer MAC usando una clave secreta y datos de transacción. La clave secreta se almacena tanto en el dispositivo móvil 10 como en un dispositivo informático. El dispositivo móvil 10 envía a continuación el primer MAC y una ID de dispositivo móvil al dispositivo informático para verificar el primer MAC para autenticar la transacción. Los datos de transacción también se envían al dispositivo informático. El dispositivo informático tiene almacenado en el mismo la ID de dispositivo móvil en asociación con una ID de pago de una cuenta de pago.
El dispositivo informático, tras recibir del dispositivo móvil el primer MAC y la ID de dispositivo móvil, recupera la ID de pago asociada con la ID de dispositivo móvil. El dispositivo informático calcula entonces un segundo m Ac usando la clave secreta y los datos de transacción. Tras determinar que el primer MAC y el segundo MAC son iguales, el dispositivo informático permite el pago de la transacción usando la ID de pago. A continuación, el dispositivo informático envía una confirmación al dispositivo móvil 10 de que la transacción se ha completado.
El dispositivo móvil 10 recibe la confirmación, y, por ejemplo, puede mostrar la confirmación al usuario.
En otro aspecto de los sistemas y métodos propuestos, la ID complementaria se usa para verificar la ID de pago, aunque no se requiere que la ID complementaria pase a través de la pasarela de pago 8. Por lo tanto, la pasarela de pago 8 no necesita manejar o gestionar la ID complementaria. Esto reduce la responsabilidad y el riesgo para la pasarela de pago 8. Los detalles se describen con respecto a las figuras 23 y 24.
En particular, volviendo a la figura 23, durante un proceso de registro, el dispositivo móvil 10 recibe al menos la ID de pago y la ID complementaria (bloque 304). Se puede apreciar que la ID de dispositivo móvil ya está generada u obtenida, y almacenada en el dispositivo móvil 10. El dispositivo móvil 10 envía entonces la ID de pago y la ID de dispositivo móvil a la pasarela de pago 8 (bloque 306). La pasarela de pago 8 almacena la ID de pago y la ID de dispositivo móvil (bloque 308). La pasarela de pago 8 envía la ID de pago y la ID de dispositivo móvil al módulo de verificación 23 (bloque 30).
El dispositivo móvil 10, tras recibir la ID complementaria, envía la ID complementaria y la ID de dispositivo móvil al módulo de verificación 23 (bloque 312). La transmisión de la ID complementaria y la ID de dispositivo móvil no pasa a través de la pasarela de pago 8 y puede, por ejemplo, enviarse directamente al módulo de verificación 23. Se puede apreciar que las operaciones del bloque 312 y 310 pueden ocurrir en diferentes tiempos o aproximadamente al mismo tiempo.
El módulo de verificación 23 recibe así la ID móvil y la ID de pago de una fuente, y recibe la ID móvil y la ID complementaria de otra fuente. En el bloque 314, el módulo de verificación 23 usa las ID de dispositivo móvil comunes o coincidentes para asociar la ID complementaria y la ID de pago correspondientes. Es decir, una ID complementaria y una ID de pago se corresponden entre sí, si se determina que la ID de móvil asociada con la ID de pago (de una fuente) es la misma que la ID de móvil asociada con la ID complementaria (de la otra fuente). En el bloque 316, el módulo de verificación verifica la ID complementaria y la ID de pago y envía el resultado de verificación. En el bloque 318, si el resultado de verificación es exitoso, entonces la pasarela de pago 8 establece un indicador de que la ID de dispositivo móvil y la ID de pago (como se almacenan en la pasarela de pago 8) se verifican con éxito. El indicador, por ejemplo, puede ser un valor booleano que indica que la ID de dispositivo móvil y la ID de pago se verifican con éxito.
Continuando a partir de la figura 23, la figura 24 proporciona instrucciones ejecutables por ordenador de ejemplo para autenticar una transacción sin pasar la ID complementaria a través de la pasarela de pago 8. En el bloque 320, el dispositivo móvil 10 recibe la ID complementaria. En el bloque 322, el dispositivo móvil 10 envía la ID de dispositivo móvil a la pasarela de pago 8. La pasarela de pago 8 recupera la ID de pago asociada y comprueba el indicador si la ID de pago y la ID móvil se verifican con éxito (bloque 324). Si se verifica, la pasarela de pago 8 envía la ID de pago y la ID de dispositivo móvil al módulo de verificación 23 (bloque 326).
El dispositivo móvil 10 también envía la ID complementaria y la ID de dispositivo móvil al módulo de verificación 23 (bloque 328). La operación del bloque 328 puede ocurrir en un tiempo diferente o aproximadamente al mismo tiempo que la operación del bloque 326.
En el bloque 330, el módulo de verificación 23 usa las ID de dispositivo móvil común para hacer coincidir o asociar la ID complementaria con la ID de pago correspondiente. En el bloque 332, el módulo de verificación 23 verifica la ID de pago y la ID complementaria. Si el resultado de verificación es exitoso, a continuación, cualquiera de la pasarela de pago 8, el módulo de verificación 23 y el servidor de pago 20 permiten la ejecución del proceso de pago, por ejemplo, a través del servidor de pago 20 (bloque 334).
La realización de ejemplo de las figuras 23 y 24 proporciona un enrutamiento alternativo de datos que no requiere que la ID complementaria se reenvíe o pase a través de la pasarela de pago 8.
En otro aspecto, los sistemas y métodos propuestos incluyen almacenar la ID complementaria en el dispositivo móvil 10 para que no se requiera que el usuario introduzca la ID complementaria en el dispositivo móvil 10 cada vez que se realiza una transacción. Volviendo a la figura 25, se proporcionan instrucciones ejecutables por ordenador de ejemplo para una transacción. El dispositivo móvil 10 recibe la ID complementaria (bloque 336) y tiene lugar una transacción (bloque 338). La transacción puede tener lugar de varias maneras según las diversas realizaciones de ejemplo descritas en el presente documento. En el bloque 340, a continuación, el dispositivo móvil 10 determina si almacenar la ID complementaria o eliminarla de la memoria del dispositivo móvil. Se apreciará que en ciertas situaciones, es deseable no almacenar la ID complementaria en almacenamiento o memoria no volátil. La determinación puede basarse en diversas condiciones, incluyendo, por ejemplo, preferencias preestablecidas del usuario, el período de tiempo entre las dos transacciones anteriores, ubicación del dispositivo móvil 10, la hora del día, o combinaciones de los anteriores. Se pueden aplicar otras condiciones.
En esta realización de ejemplo, se determina que la ID complementaria se almacena en el dispositivo móvil 10. En el bloque 342, el dispositivo móvil 10 recibe una indicación (por ejemplo, del usuario) para ejecutar otra transacción. A continuación, el dispositivo móvil 10 envía la ID de dispositivo móvil y la ID complementaria que se almacenaron en el dispositivo móvil para permitir la autenticación de la transacción (bloque 344). De esta manera, el usuario no necesita volver a introducir la ID complementaria en el dispositivo móvil 10 cuando intenta autenticar la otra transacción.
En otra realización de ejemplo, la operación del bloque 340 se ejecuta periódicamente para determinar si cualquier ID complementaria ingresada recientemente o guardada previamente debe almacenarse en el dispositivo móvil 10 o eliminarse.
En general, los sistemas y métodos descritos en el presente documento incluyen un método para liquidar una disputa para una transacción ejecutada previamente, el método realizado por un dispositivo informático, comprendiendo el método: recibir la disputa con respecto a la transacción que incluye datos de transacción asociados; recuperar una firma digital asociada con los datos de transacción, la firma digital calculada mediante la firma de los datos de transacción; verificar la firma digital usando una clave pública, la clave pública correspondiente a una clave privada almacenada en un dispositivo móvil; y determinar si la transacción es fraudulenta o no basándose en un resultado de verificación de la firma digital. En otro aspecto, se determina que la transacción es fraudulenta si el resultado de verificación no es exitoso. En otro aspecto, se determina que la transacción no es fraudulenta si el resultado de verificación es exitoso. En otro aspecto, el dispositivo informático recibe del dispositivo móvil la firma digital, la firma digital se firma usando la clave privada. En otro aspecto, el método comprende además determinar si una transacción posterior es fraudulenta o no verificando una firma digital posterior usando la clave pública, y si la firma digital posterior proporciona un resultado de verificación posterior que es exitoso, a continuación, aumentando el dispositivo informático un valor de confianza de que el resultado de verificación posterior demuestra que la transacción posterior no es fraudulenta. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, la firma digital se calcula firmando los datos de transacción y una ID de dispositivo móvil, la ID de dispositivo móvil que identifica el dispositivo móvil. En otro aspecto, la firma digital se verifica usando uno cualquiera de un esquema de RSA, un esquema de DSA, un esquema de ECDSA, y un esquema de firma ElGamal. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo informático. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo móvil y la clave pública se envía al dispositivo informático.
En general, los sistemas y métodos descritos en el presente documento también incluyen un método para liquidar una disputa para una transacción, el método realizado por un dispositivo móvil, comprendiendo el método: almacenar una clave privada en el dispositivo móvil antes de la transacción; usar mediante el dispositivo móvil la clave privada para firmar criptográficamente datos de transacción para generar una firma digital durante la transacción; enviar mediante el dispositivo móvil la firma digital a un dispositivo informático, teniendo el dispositivo informático acceso a una clave pública correspondiente a la clave privada y configurado para verificar la firma digital para determinar si la transacción es fraudulenta o no. En otro aspecto, la clave privada se almacena en el móvil en una forma cifrada. En otro aspecto, la clave privada se cifra usando una clave secundaria. En otro aspecto, la clave secundaria es una función de una ID complementaria, la ID complementaria para verificar una ID de pago de una cuenta de pago usada en la transacción, y la clave privada se cifra usando la clave secundaria. En otro aspecto, durante la transacción, el método comprende además recibir mediante el dispositivo móvil la clave secundaria y descifrar la clave privada cifrada usando la clave secundaria para su uso en la generación de la firma digital. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, la firma digital se calcula firmando los datos de transacción y una ID de dispositivo móvil, identificando la ID de dispositivo móvil al dispositivo móvil. En otro aspecto, la firma digital se genera usando uno cualquiera de un esquema de RSA, un esquema de DSA, un esquema de ECDSA, y un esquema de firma ElGamal. En otro aspecto, la clave privada se almacena en una aplicación de Internet en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un módulo de plataforma de confianza en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un chip de comunicaciones de campo cercano (NFC) en el dispositivo móvil. En otro aspecto, la clave privada se almacena en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un dispositivo de almacenamiento retirable en el dispositivo móvil. En otro aspecto, la clave privada se almacena en el almacenamiento de una aplicación en el dispositivo móvil. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo informático. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo móvil y la clave pública se envía al dispositivo informático.
En general, los sistemas y métodos descritos en el presente documento incluyen un método para autenticar una transacción usando una firma digital, el método realizado por un dispositivo informático, comprendiendo el método: almacenar una ID de dispositivo móvil que identifica un dispositivo móvil en asociación con una ID de pago de una cuenta de pago; recibir del dispositivo móvil una firma digital y la ID de dispositivo móvil, la firma digital calculada mediante la firma de datos de transacción asociados con la transacción; recuperar la ID de pago asociada con la ID de dispositivo móvil; verificar la firma digital usando una clave pública, la clave pública correspondiente a una clave privada almacenada en el dispositivo móvil; y al verificar con éxito la firma digital, permitir el pago de la transacción usando la ID de pago. En otro aspecto, la firma digital es firmada por la clave privada. En otro aspecto, el método comprende además recibir una ID complementaria desde el dispositivo móvil, la ID complementaria para verificar la ID de pago. En otro aspecto, el método comprende además verificar con éxito la ID complementaria y la ID de pago antes de permitir el pago de la transacción. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, la firma digital se calcula firmando los datos de transacción y la ID de dispositivo móvil. En otro aspecto, la firma digital se verifica usando uno cualquiera de un esquema de RSA, un esquema de DSA, un esquema de ECDSA, y un esquema de firma ElGamal. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo informático. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo móvil y la clave pública se envía al dispositivo informático.
En general, los sistemas y métodos como se describen en el presente documento también incluyen un método para autenticar una transacción usando una firma digital, el método realizado por un dispositivo móvil, comprendiendo el método: recibir una entrada para ejecutar la transacción; calcular la firma digital mediante firma de manera criptográfica, con una clave privada, datos de transacción asociados con la transacción; enviar la firma digital y una ID de dispositivo móvil del dispositivo móvil a un dispositivo informático para verificar la firma digital para autenticar la transacción, teniendo el dispositivo informático almacenada en el mismo la ID de dispositivo móvil en asociación con una ID de pago de una cuenta de pago; y recibir desde el dispositivo informático una confirmación de que la transacción está completa. En otro aspecto, la clave privada corresponde a una clave pública, la clave pública almacenada en el dispositivo informático. En otro aspecto, la clave privada se cifra usando una clave secundaria y se almacena en el dispositivo móvil en forma cifrada. En otro aspecto, el método comprende además descifrar la clave privada cifrada usando la clave secundaria. En otro aspecto, la entrada incluye datos para derivar la clave secundaria y el método comprende además derivar la clave secundaria usando la entrada. En otro aspecto, la clave secundaria es una función de una ID complementaria, la ID complementaria para verificarla ID de pago, y la entrada incluye la ID complementaria para derivar la clave secundaria. En otro aspecto, la entrada incluye una ID complementaria, la ID complementaria para verificar la ID de pago, y el método comprende además enviar el dispositivo móvil la ID complementaria al dispositivo informático; y el dispositivo móvil, en el dispositivo informático que ejecuta la transacción basándose en la ID de pago y que recibe la verificación de que la ID complementaria y la ID de pago son auténticas, recibir desde el dispositivo informático la confirmación de que la transacción está completa. En otro aspecto, el método comprende además un proceso de registro que se produce para almacenar la ID de dispositivo móvil en el dispositivo móvil antes de la transacción, comprendiendo además el método: recibir mediante el dispositivo móvil de una GUI de registro al menos la ID de pago y la ID complementaria, y transmitir la ID de pago y la ID complementaria al dispositivo informático; y, tras recibir del dispositivo informático que la ID de pago y la ID complementaria se verifican con éxito, obtener mediante el dispositivo móvil un componente para la ID de dispositivo móvil. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, la firma digital se calcula firmando los datos de transacción y la ID de dispositivo móvil. En otro aspecto, la firma digital se verifica usando uno cualquiera de un esquema de RSA, un esquema de DSA, un esquema de ECDSA, y un esquema de firma ElGamal. En otro aspecto, la clave privada se almacena en una aplicación de Internet en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un módulo de plataforma de confianza en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un chip de comunicaciones de campo cercano (NFC) en el dispositivo móvil. En otro aspecto, la clave privada se almacena en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil. En otro aspecto, la clave privada se almacena en un dispositivo de almacenamiento retirable en el dispositivo móvil. En otro aspecto, la clave privada se almacena en el almacenamiento de una aplicación en el dispositivo móvil. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo informático. En otro aspecto, la clave privada y la clave pública se generan en el dispositivo móvil y la clave pública se envía al dispositivo informático.
En general, los sistemas y métodos descritos en el presente documento también incluyen un método para autenticar una transacción, comprendiendo el método: recibir mediante un dispositivo móvil una ID complementaria, la ID complementaria para verificar una ID de pago de una cuenta de pago, teniendo el dispositivo móvil almacenada en el mismo una ID de pago; enviar mediante el dispositivo móvil la ID de dispositivo móvil a una pasarela de pago, teniendo la pasarela de pago almacenada en la misma la ID de pago en asociación con la ID de dispositivo móvil; recuperar mediante la pasarela de pago la ID de pago asociada con la ID de dispositivo móvil y enviar la ID de pago y la ID de dispositivo móvil a un módulo de verificación; enviar mediante el dispositivo móvil la ID complementaria y la ID de dispositivo móvil al módulo de verificación; usando el módulo de verificación las ID de dispositivo móvil coincidentes para asociar la ID complementaria y la ID de pago y verificar la ID complementaria y la ID de pago asociadas; y si se verificó con éxito, permitir mediante el módulo de verificación la ejecución de la transacción.
En general, los sistemas y métodos descritos en el presente documento también incluyen un método para autenticar una transacción, el método realizado en un dispositivo móvil, teniendo almacenado el dispositivo móvil en el mismo una ID de dispositivo móvil, comprendiendo el método: recibir mediante el dispositivo móvil a través de una GUI de transacción una ID complementaria para verificar una ID de pago; enviar mediante el dispositivo móvil la ID de dispositivo móvil a una pasarela de pago, teniendo la pasarela de pago almacenada en la misma la ID de pago y la ID de dispositivo móvil en asociación entre sí; enviar mediante el dispositivo móvil la ID complementaria y la ID de dispositivo móvil a un módulo de verificación, el módulo de verificación en comunicación con la pasarela de pago; después de que la pasarela de pago ejecute la transacción basándose en la ID de pago asociada con la ID de dispositivo móvil y recibir verificación de que la ID complementaria y la ID de pago son auténticas, recibir mediante el dispositivo móvil desde la pasarela de pago una confirmación de que la transacción está completa. En otro aspecto, el método comprende además un proceso de registro para almacenar la ID de dispositivo móvil en el dispositivo móvil, comprendiendo además el método: recibir mediante el dispositivo móvil de una g Ui de registro al menos la ID de pago de una cuenta de pago y la ID complementaria, y transmitir la ID de pago y la ID de dispositivo móvil a la pasarela de pago; transmitir mediante el dispositivo móvil la ID complementaria y la ID de dispositivo móvil al módulo de verificación; y, tras recibir de la pasarela de pago que la iD de pago y la ID complementaria se verifican con éxito, obtener mediante el dispositivo móvil un componente para la ID de dispositivo móvil, la ID de dispositivo móvil almacenada en el dispositivo móvil. En otro aspecto, el método comprende además obtener mediante el dispositivo móvil el componente para la ID de dispositivo móvil mediante al menos uno de generar y recibir el componente. En otro aspecto, el servidor de comerciante envía la ID complementaria sin almacenar la ID complementaria en el servidor de comerciante. En otro aspecto, la ID de pago está compuesta por al menos uno de: un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, un número de tarjeta de valor, y un número de cuenta de puntos. En otro aspecto, la ID complementaria está compuesta por al menos uno de: un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), una verificación de código de tarjeta (CCV), un pin, una contraseña, datos biométricos, y datos de voz. En otro aspecto, la ID de dispositivo móvil incluye al menos uno de: información de identidad de abonado almacenada en una tarjeta SIM o IMEI del dispositivo móvil, información de red, una dirección IP, una identificación de operador telefónico, una dirección de puerto, un nombre de DNS, una coordenada GPS del dispositivo móvil, la temperatura de batería del dispositivo móvil, una ubicación geográfica del dispositivo móvil, una lectura de acelerómetro del dispositivo móvil, una cookie, un agente de usuario, y un encabezado, en donde la cookie, el agente de usuario, y el encabezado se proporcionan por el navegador en el dispositivo móvil, o información almacenada en un almacenamiento de modelo de objeto de documento (DOM) en el dispositivo móvil.
En general, los sistemas y métodos descritos en el presente documento incluyen un método para autenticar una transacción en un módulo de verificación, comprendiendo el método: recibir mediante el módulo de verificación desde una pasarela de pago una ID de pago y una ID de dispositivo móvil de un dispositivo móvil, la pasarela de pago en comunicación con el dispositivo móvil; recibir mediante el módulo de verificación desde el dispositivo móvil la ID de dispositivo móvil y una iD complementaria, la ID complementaria para verificar la ID de pago; hacer coincidir mediante el módulo de verificación la ID de dispositivo móvil recibida desde la ID de pago y la iD de dispositivo móvil recibida de dispositivo móvil para determinar si la ID complementaria y la ID de pago están asociadas entre sí; tras determinar que la ID complementaria y la ID de pago están asociados entre sí, verificar mediante el módulo de verificación la ID complementaria y la ID de pago. En otro aspecto, el módulo de verificación verifica comparando la ID complementaria y la ID de pago con una ID complementaria previamente almacenada y una ID de pago previamente almacenada, y si son idénticas, determinar que la ID complementaria y la ID de pago se verifican con éxito. En otro aspecto, la ID de pago está compuesta por al menos uno de: un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, un número de tarjeta de valor, y un número de cuenta de puntos. En otro aspecto, la ID complementaria está compuesta por al menos uno de: un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), una verificación de código de tarjeta (CCV), un pin, una contraseña, datos biométricos, y datos de voz. En otro aspecto, la ID de dispositivo móvil incluye al menos uno de: información de identidad de abonado almacenada en una tarjeta SIM o IMEI del dispositivo móvil, información de red, una dirección IP, una identificación de operador telefónico, una dirección de puerto, un nombre de DNS, una coordenada GPS del dispositivo móvil, la temperatura de batería del dispositivo móvil, una ubicación geográfica del dispositivo móvil, una lectura de acelerómetro del dispositivo móvil, una cookie, un agente de usuario, y un encabezado, en donde la cookie, el agente de usuario, y el encabezado se proporcionan por el navegador en el dispositivo móvil, o información almacenada en un almacenamiento de modelo de objeto de documento (DOM) en el dispositivo móvil.
En general, los sistemas y métodos descritos en el presente documento incluyen un método para liquidar una disputa para una transacción ejecutada previamente, el método realizado por un dispositivo informático, comprendiendo el método: recibir la disputa con respecto a la transacción que incluye datos de transacción asociados; recuperar un primer código de autenticación de mensaje (MAC) asociado con los datos de transacción, el primer MAC calculado por un dispositivo móvil; calcular un segundo MAC usando una clave secreta, la clave secreta almacenada tanto en el dispositivo informático como en el dispositivo móvil; y determinar si la transacción es fraudulenta o no basándose en una comparación del primer MAC y el segundo MAC. En otro aspecto, se determina que la transacción es fraudulenta si el primer MAC y el segundo MAC son diferentes. En otro aspecto, se determina que la transacción no es fraudulenta si el primer MAC y el segundo MAC son iguales. En otro aspecto, el dispositivo informático recibe del dispositivo móvil el primer MAC, el primer MAC calculado usando la clave secreta. En otro aspecto, comprende además determinar si una transacción posterior es fraudulenta o no verificando MAC posteriores usando la clave secreta, y si los MAC posteriores proporcionan un resultado de verificación que es exitoso, a continuación, el dispositivo informático que aumenta un valor de confianza de que el resultado de verificación demuestra que la transacción posterior no es fraudulenta. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, el dispositivo informático almacena la clave secreta en asociación con una ID de dispositivo móvil, la ID de dispositivo móvil para identificar el dispositivo móvil. En otro aspecto, el primer MAC y el segundo MAC se calculan aplicando un algoritmo de MAC a los datos de transacción y una ID de dispositivo móvil, la ID de dispositivo móvil que identifica el dispositivo móvil. En otro aspecto, el dispositivo informático recibe el primer MAC y la ID de dispositivo móvil desde el dispositivo móvil. En otro aspecto, la clave secreta se almacena en el dispositivo informático en forma cifrada. En otro aspecto, el MAC es un MAC basado en cifrado (CMAC) o un MAC basado en hash (HMAC).
En general, los sistemas y métodos descritos en el presente documento incluyen un método para liquidar una disputa para una transacción, el método realizado por un dispositivo móvil, comprendiendo el método: almacenar una clave secreta en el dispositivo móvil antes de la transacción; usar mediante el dispositivo móvil la clave secreta y los datos de transacción para calcular un primer MAC durante la transacción; enviar mediante el dispositivo móvil el primer MAC a un dispositivo informático, teniendo el dispositivo informático acceso a la clave secreta y configurado para verificar el primer MAC para determinar si la transacción es fraudulenta o no. En otro aspecto, la clave secreta se almacena en el dispositivo móvil en una forma cifrada. En otro aspecto, la clave secreta se cifra usando una clave secundaria. En otro aspecto, la clave secundaria es una función de una ID complementaria, la ID complementaria para verificar una ID de pago de una cuenta de pago usada en la transacción, y la clave secreta se cifra usando la clave secundaria. En otro aspecto, durante la transacción, el método comprende además recibir mediante el dispositivo móvil la clave secundaria y descifrar la clave secreta cifrada usando la clave secundaria. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, el primer MAC se calcula aplicando un algoritmo de MAC a los datos de transacción y una ID de dispositivo móvil, la ID de dispositivo móvil que identifica el dispositivo móvil. En otro aspecto, la clave secreta se almacena en una aplicación de Internet en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un módulo de plataforma de confianza en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un chip de comunicaciones de campo cercano (NFC) en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un dispositivo de almacenamiento retirable en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en el almacenamiento de una aplicación en el dispositivo móvil. En otro aspecto, la clave secreta se genera en el dispositivo informático o el dispositivo móvil. En otro aspecto, el MAC es un MAC basado en cifrado (CMAC) o un MAC basado en hash (HMAC).
En general, los sistemas y métodos descritos en el presente documento incluyen un método para autenticar una transacción usando MAC, el método realizado por un dispositivo informático, comprendiendo el método: almacenar una ID de dispositivo móvil que identifica un dispositivo móvil en asociación con una ID de pago de una cuenta de pago; recibir del dispositivo móvil un primer MAC y la ID de dispositivo móvil, el primer MAC calculado usando una clave secreta y datos de transacción asociados con la transacción, la clave secreta almacenada en el dispositivo móvil y en el dispositivo informático; recuperar la ID de pago asociada con la ID de dispositivo móvil; calcular un segundo MAC usando la clave secreta y los datos de transacción; y tras determinar que el primer MAC y el segundo MAC son iguales, permitir el pago de la transacción usando la ID de pago. En otro aspecto, comprende además recibir una ID complementaria desde el dispositivo móvil, la ID complementaria para verificar la ID de pago. En otro aspecto, comprende además verificar con éxito la ID complementaria y la ID de pago antes de permitir el pago de la transacción. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, el primer MAC y el segundo MAC se calculan aplicando un algoritmo de MAC a los datos de transacción y la ID de dispositivo móvil. En otro aspecto, la clave secreta se genera en el dispositivo informático o el dispositivo móvil. En otro aspecto, el MAC es un m Ac basado en cifrado (CMAC) o un MAC basado en hash (HMAC).
En general, los sistemas y métodos descritos en el presente documento incluyen un método para autenticar una transacción usando MAC, el método realizado por un dispositivo móvil, comprendiendo el método: recibir una entrada para ejecutar la transacción; calcular un primer MAC usando una clave secreta y datos de transacción, la clave secreta almacenada tanto en el dispositivo móvil como en un dispositivo informático; enviar el primer MAC y una ID de dispositivo móvil del dispositivo móvil al dispositivo informático para verificar el primer MAC para autenticar la transacción, teniendo el dispositivo informático almacenada en el mismo la ID de dispositivo móvil en asociación con una ID de pago de una cuenta de pago; y recibir desde el dispositivo informático una confirmación de que la transacción está completa. En otro aspecto, la clave secreta se cifra usando una clave secundaria y se almacena en el dispositivo móvil en forma cifrada. En otro aspecto, el método comprende además descifrar la clave secreta cifrada usando la clave secundaria. En otro aspecto, la entrada incluye datos para derivar la clave secundaria y el método comprende además derivar la clave secundaria usando la entrada. En otro aspecto, la clave secundaria es una función de una ID complementaria, la ID complementaria para verificar la ID de pago, y la entrada incluye la ID complementaria para derivar la clave secundaria. En otro aspecto, la entrada incluye una ID complementaria, la ID complementaria para verificar la ID de pago, y el método comprende además enviar el dispositivo móvil la ID complementaria al dispositivo informático; y, después de que el dispositivo informático ejecuta la transacción basándose en la ID de pago y reciba la verificación de que la ID complementaria y la ID de pago son auténticas, recibir mediante el dispositivo móvil desde el dispositivo informático la confirmación de que la transacción está completa. En otro aspecto, comprende además un proceso de registro que se produce para almacenar la ID de dispositivo móvil en el dispositivo móvil antes de la transacción, comprendiendo además el método: recibir mediante el dispositivo móvil de una GUI de registro al menos la ID de pago y la ID complementaria, y transmitir la ID de pago y la ID complementaria al dispositivo informático; y, tras recibir del dispositivo informático que la ID de pago y la ID complementaria se verifican con éxito, obtener mediante el dispositivo móvil un componente para la ID de dispositivo móvil. En otro aspecto, los datos de transacción comprenden al menos uno del número de factura de la transacción, una cantidad de pago, una fecha de la transacción, un tiempo de la transacción, una dirección de envío, una dirección de facturación, un correo electrónico del comprador, y el número de teléfono del comprador. En otro aspecto, el primer MAC se calcula aplicando un algoritmo de MAC a los datos de transacción y la ID de dispositivo móvil. En otro aspecto, la clave secreta se almacena en una aplicación de Internet en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un módulo de plataforma de confianza en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un chip de comunicaciones de campo cercano (NFC) en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en una tarjeta de módulo de identidad de abonado (SIM) en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en un dispositivo de almacenamiento retirable en el dispositivo móvil. En otro aspecto, la clave secreta se almacena en el almacenamiento de una aplicación en el dispositivo móvil. En otro aspecto, la clave secreta se genera en el dispositivo móvil y se envía al dispositivo informático.
En otro aspecto de los sistemas y métodos descritos en el presente documento, se reconoce que la experiencia del usuario para llegar a un sitio web de pago o página web de pago (por ejemplo, como se muestra en las figuras 11, 12 y 13) pueden ser engorrosos. Por ejemplo, un usuario puede necesitar navegar por un sitio web de comercio electrónico y seleccionar un producto para activar que el dispositivo móvil 10 visualice un sitio web o página web de pago.
Por lo tanto, los sistemas y métodos descritos en el presente documento proporcionan una forma de activar más fácilmente que el dispositivo móvil 10 visualice un sitio web o página web de pago basándose en los datos adquiridos por el dispositivo móvil 10. Los datos, por ejemplo, pueden adquirirse a partir de códigos de barras, imágenes, colocando el dispositivo móvil 10 cerca de un terminal de comunicación de campo cercano (NFC), y a partir de datos de audio. Los detalles se explican a continuación.
Volviendo a la figura 26, se muestra un sistema de ejemplo para autenticar una transacción o pago, similar al mostrado en la figura 1. En la figura 26, sin embargo, el dispositivo móvil 10 también está en comunicación con un servidor 346 para identificar productos y servicios. El servidor 346 incluye bases de datos 348 y 350 que asocian identificaciones de productos y servicios con direcciones de red para autenticación de pago o transacción. Las direcciones de red pueden incluir, sin limitación, localizadores uniformes de recursos (URL), direcciones del sitio web, etc. Cuando el dispositivo móvil 10 inicia el sitio web de una dirección de red, se muestra un sitio web o página web de pago. Ejemplos de los sitios web o páginas web de pago se muestran en las figuras 11, 12 y 13. Los sitios web o páginas web de pago pueden estar alojados en la pasarela de pago 8. Las direcciones de red almacenadas en la base de datos 350 pueden ser proporcionadas por la pasarela de pago 8. Se puede apreciar que la base de datos 350 puede estar en comunicación con la pasarela de pago 8 representada por la línea de puntos 351.
La base de datos 348 almacena identificaciones de productos o servicios, o ambos. Las identificaciones pueden incluir muchas formas diferentes. Por ejemplo, pueden usarse números de serie, números de SKU, datos de audio, texto, y las imágenes para identificar un producto o un servicio. En una realización de ejemplo, una identificación dada puede estar asociada con una o más direcciones de red. En otra realización de ejemplo, una dirección de red dada está asociada con una o más identificaciones.
El dispositivo móvil 10 proporciona al servidor 346 datos (por ejemplo, datos de imagen, datos de código de barras, datos de audio, datos de texto, etc.), que el servidor 346 usa para identificar un producto o servicio de la base de datos 348. A continuación, el servidor 346 obtiene la(s) dirección(es) de red del sitio web de pago asociado con el producto o servicio y devuelve la(s) dirección(es) de red al dispositivo móvil 10. El dispositivo móvil 10 puede usar la dirección de red para iniciar un sitio web de pago para comprar el producto o servicio, usando los métodos de autenticación de transacción descritos en el presente documento (por ejemplo, a través de la pasarela de pago 8).
Se puede apreciar que el servidor 346 puede procesar los datos proporcionados por el dispositivo móvil 10 para adquirir la identificación de producto o servicio. Por ejemplo, si el dispositivo móvil 10 proporciona al servidor 346 un archivo de imagen, un código de barras, o archivo de audio, el servidor 346 puede aplicar respectivamente reconocimiento de imágenes al archivo de imagen, decodificar el código de barras, o aplicar reconocimiento de audio al archivo de audio para derivar o extraer la identificación de producto o servicio. Una vez obtenida la identificación, la dirección de red correspondiente se busca y obtiene usando las bases de datos 348 y 350.
En otra realización, el archivo de imagen, código de barras, o el archivo de audio pueden procesarse en el dispositivo móvil 10 para adquirir la identificación de producto o servicio. El dispositivo móvil 10 envía entonces la identificación de producto o servicio al servidor 346.
Volviendo a la figura 27, se muestran componentes de ejemplo de un dispositivo móvil 10. El dispositivo móvil 10 contiene un procesador principal 352 que interactúa con un número de componentes que incluyen, entre otras cosas, entradas/salidas auxiliares 354, un puerto de datos 356, un teclado 358, un altavoz 360 (por ejemplo, un altavoz de audio), un micrófono 362, un receptor GPS 364 y una cámara 366. El dispositivo móvil 10 también puede incluir un subsistema NFC 368, un subsistema de comunicación de corto alcance 370, y otros subsistemas de dispositivo 372.
El dispositivo móvil 10 usa un sistema de comunicación 374 para interactuar con la red inalámbrica 2. Los tipos de memoria incluyen memoria flash 378 y memoria de acceso aleatorio (RAM) 376. La pantalla del dispositivo móvil 380 puede ser una pantalla de tipo pantalla táctil u otro tipo de pantalla.
Puede usarse un sistema operativo 384 para gestionar y ejecutar componentes de software. Los componentes o aplicaciones de software incluyen un navegador web o un navegador de internet 388, una aplicación de código de barras 390, una aplicación de reconocimiento de imágenes 392, una aplicación de reconocimiento óptico de caracteres (OCR) 394, una aplicación de reconocimiento de audio 396, y una aplicación de reconocimiento de música 398. La aplicación de código de barras 390 es para escanear códigos de barras y extraer datos para decodificar códigos de barras. Un ejemplo no limitante de una aplicación de reconocimiento de música 398 está disponible comercialmente bajo el nombre de Shazam, que reconoce una canción (o un programa de televisión, etc. ) registrando “huellas acústicas” basándose en datos de espectrogramas en comparación con una base de datos. Se puede apreciar que diversas aplicaciones de escaneo de códigos de barras, aplicaciones de reconocimiento de imágenes, aplicaciones de OCR, aplicaciones de reconocimiento de audio y aplicaciones de reconocimiento de música conocidas y futuras son aplicables a los principios descritos en el presente documento. También se puede apreciar que puede haber otros componentes de software 386.
Volviendo a la figura 28, se muestran instrucciones ejecutables por ordenador de ejemplo para un dispositivo móvil 10 que inicia un sitio web o página web de pago basándose en los datos adquiridos por el dispositivo móvil 10. En el bloque 400, el dispositivo móvil 10 adquiere datos. Los datos adquiridos pueden tener la forma de un código de barras, imagen, texto, audio, etc. Los datos también se pueden adquirir tocando el dispositivo móvil 10 cerca de un dispositivo NFC, que comunica datos a través del subsistema NFC 368 del dispositivo móvil. Se puede apreciar que los datos se pueden adquirir de varias maneras. Los datos adquiridos incluyen una dirección de red.
En el bloque 402, el dispositivo móvil 10 inicia un sitio web o página web de pago para un producto o servicio dado usando la dirección de red. El sitio web o página web de pago puede incluir opciones para seleccionar términos y parámetros para el producto o servicio que va a comprarse. Por ejemplo, un usuario puede seleccionar la cantidad de artículos que va a seleccionarse, la fecha en la que el servicio (por ejemplo, vuelos y hoteles) va a utilizarse, y el tipo de producto (por ejemplo, tamaño, color, y modelo). Otro parámetro de ejemplo puede ser la cantidad de dinero que se donará a una organización benéfica. En otras palabras, en el bloque 404, el dispositivo móvil 10 recibe la(s) selección(es) con respecto a los términos y parámetros del producto o servicio.
En el bloque 406, el dispositivo móvil 10 recibe la ID complementaria usada para autenticar la transacción. Desde aquí, las operaciones descritas anteriormente pueden ejecutarse para autenticar la transacción.
Se puede apreciar que el bloque 404 es opcional, y que al iniciar el sitio web de pago (bloque 402), el dispositivo móvil 10 puede recibir la ID complementaria para autenticar el pago (bloque 406).
Volviendo a la figura 29, se muestran instrucciones ejecutables por ordenador de ejemplo para adquirir una dirección de red, iniciar un sitio web o página web separado para obtener términos y parámetros para el producto o servicio que va a comprarse, y luego iniciar un sitio web de pago para el producto o servicio dado. En el bloque 408, el dispositivo móvil 10 adquiere la fecha, que incluye la dirección de red. El dispositivo móvil 10 inicia luego un sitio web para un producto o servicio dado usando la dirección de red (bloque 410). El dispositivo móvil 10, a través del sitio web iniciado, recibe selecciones del usuario con respecto a los términos y parámetros del producto o servicio que va a comprarse (bloque 412). Después de que se hayan realizado las selecciones, en el bloque 414, el dispositivo móvil 10 inicia un sitio web de pago para el producto o servicio dado según la selección recibida. Por ejemplo, si se selecciona una cantidad de dos productos, a continuación, el coste de pago total de los dos productos se muestra en el sitio web o página web de pago. En el bloque 416, el dispositivo móvil 10 recibe la ID complementaria usada para autenticar el pago. De nuevo, desde aquí, las operaciones descritas anteriormente pueden ejecutarse para autenticar la transacción.
En otra realización de ejemplo, los datos adquiridos no incluyen la dirección de red directamente, pero pueden obtenerse a través de bases de datos que asocian la dirección de red con identificaciones de producto o servicio.
Volviendo a la figura 30, se proporcionan instrucciones ejecutables por ordenador de ejemplo para obtener una dirección de red basándose en datos adquiridos por el dispositivo móvil 10. En el bloque 418, el dispositivo móvil adquiere datos. En el bloque 420, el dispositivo móvil reconoce que los datos están relacionados con uno o más productos o servicios 420. Por ejemplo, dependiendo del tipo de datos, puede haber una identificación en los datos adquiridos que identifica un producto o servicio. En el bloque 422, el dispositivo móvil 10 usa los datos adquiridos para buscar una o más direcciones de red asociadas con el producto o servicio identificado. Se puede apreciar que el dispositivo móvil 10 puede enviar los datos adquiridos al servidor 346, que luego devuelve una dirección de red de un sitio web o página web de pago para comprar el producto o servicio identificado. En otra realización de ejemplo, el dispositivo móvil 10 ha almacenado en las bases de datos para buscar y adquirir la dirección de red asociada. Se puede apreciar que hay varias formas en las que el dispositivo móvil 10 obtiene la dirección de red (bloque 424).
En el bloque 4264, el dispositivo móvil 10 inicia un sitio web para un producto o servicio dado usando la dirección de red. Se pueden recibir parámetros o términos relacionados con la compra del producto o servicio (bloque 428). El dispositivo móvil 10 inicia el sitio web o página web de pago para el producto o servicio dado según las selecciones recibidas (bloque 430). El dispositivo móvil 10 recibe entonces la ID complementaria usada para autenticar el pago (bloque 432).
Volviendo a la figura 3, se proporciona un ejemplo de adquisición de códigos de barras. Se puede apreciar que muchos códigos de barras son aplicables a los principios descritos en el presente documento. Como se describió anteriormente, se pueden usar códigos de barras unidimensionales y códigos de barras bidimensionales. Ejemplos no limitantes de códigos de barras aplicables incluyen: U.P.C., Codabar, Código 26, Código 39, Código 93, Código 128, Código 11, CPC Binday, DUN 14, EAN 2, Ea N 5, EAN 8, EAN 14, Marca de identificación de orientación (Facing Identification Mark, FIM), GS1 -128, Barra de datos GS1, ITF-14, código de barras de imagen latente, Plessey, PLANET, MSI, JAN, Telepen, 3-DI, ArrayTag, código Aztec, código Aztec pequeño, Alphabet cromático, Chromocode, Codablock, Código 1, Código 16K, Código 49, ColorCode, código de matriz compacto, código CP, Cyber Code, dtough, DataGlyphs, Matriz de datos, código Datastrop, código de puntos A, EZcode, código de matriz de cuadrícula, código de barras de color de alta capacidad, HueCode, INTACTA.CODE, InterCode, MaxiCode, mCode, MiniCode, MMCC, código de puntos del lector electrónico de Nintendo, Optar, PaperDisk, PDMark, código de respuesta rápida (QR), código de marca rápida, código inteligente, código Snowflake, Shot Code, SPARQCode, SuperCode, Trillcode, Ultracode, UnisCode, VeriCode, VScode, WaterCode, etc. Se puede apreciar que cualquier imagen codificada visualmente es aplicable a los principios descritos en el presente documento.
En la figura 31, se muestran ejemplos de códigos de barras 434. Se muestran un código de barras 2D 436 y un código de barras 1D 438. El dispositivo móvil 10 usa la cámara 366 para escanear o capturar imágenes del código de barras. Puede usarse una aplicación de escáner de código de barras 390. En particular, en el bloque 440, el dispositivo móvil 10 escanea el código de barras 436. El código de barras se decodifica a continuación (bloque 442). Se puede determinar si los datos del código de barras contienen una dirección de red, o un identificador de producto o servicio (bloque 444).
En una realización de ejemplo, los datos de código de barras contienen una dirección de red relacionada con el producto o servicio. Por ejemplo, la dirección de red es un sitio web o página web que para comprar un producto o servicio dado, y proporciona acceso a la interfaz con la pasarela de pago 8. En el bloque 446, el dispositivo móvil 10 usa los datos de código de barras para extraer la dirección de red contenida en los datos de código de barras. En el bloque 448, el dispositivo móvil inicia un sitio web de pago para el producto o servicio dado usando la dirección de red.
En otra realización de ejemplo, si el código de barras contiene un identificador de producto o servicio (por ejemplo, un número de SKU), el identificador de producto o servicio se obtiene a partir de los datos de código de barras decodificados (bloque 450). En el bloque 452, el identificador de producto o servicio se usa para buscar una base de datos que almacene los identificadores en asociación con direcciones de red. En el bloque 454, el dispositivo móvil 10 obtiene la dirección de red asociada con el producto o servicio identificado. El dispositivo móvil 10 inicia entonces un sitio web o página web de pago para comprar el producto o servicio dado usando la dirección de red (bloque 456).
Tras ejecutar los bloques 448 y 456, el dispositivo móvil 10 interactúa con la pasarela de pago 8 u otros servidores como se describió anteriormente para autenticar la transacción.
Se puede apreciar que las operaciones del bloque 442, el bloque 444, el bloque 450, o el bloque 452 pueden implementarse por el dispositivo móvil 10 o el servidor 346.
Volviendo a la figura 32, se proporciona otra realización de ejemplo usando reconocimiento de imágenes para adquirir una dirección de red. La cámara 366 del dispositivo móvil puede usarse para tomar imágenes de vídeo o imágenes estáticas, y los datos de imagen pueden usarse a continuación para obtener una dirección de red. Por ejemplo, se puede tomar una imagen de un objeto, tal como un zapato 458. Usando reconocimiento de imágenes, el dispositivo móvil 10 visualizará un sitio web o página web de pago para comprar el par de zapatos correspondientes al zapato 458. En otro ejemplo, el dispositivo móvil 10 puede obtener una imagen de una caja de pañuelos 460 que se muestra en una pantalla de televisión 46. Por ejemplo, puede haber un anuncio o comercial de la caja de pañuelos 460, y el usuario usa el dispositivo móvil 10 para capturar una o imágenes de la caja de pañuelos 460. El dispositivo móvil 10 luego usa la imagen para mostrar un sitio web o página web de pago para comprar la caja de pañuelos. En otra realización de ejemplo, el dispositivo móvil 10 puede capturar una imagen del texto 462. Por ejemplo, puede leerse en el texto 462 “Comprar entradas para la película HARRY POTTER www.buytickets.com”. La aplicación de OCR 394 puede usarse para identificar el texto, y basándose en el texto, el dispositivo móvil 10 visualiza un sitio web o página web de pago para comprar las entradas de película para la película de Harry Potter. Por lo tanto, se puede apreciar que se pueden usar diversas imágenes para obtener una dirección de red para un sitio web o página web de pago, que puede usarse para comprar un producto o servicio dado en relación con la imagen capturada. Los detalles se proporcionan a continuación.
Continuando con la figura 32, en el bloque 464, el dispositivo móvil 10 captura imágenes estáticas o imágenes de vídeo. Las imágenes pueden ser de un objeto, texto, etc. A continuación, se aplica reconocimiento de imágenes a la imagen (bloque 466). Se pueden aplicar diversas técnicas de reconocimiento de imágenes para identificar el objeto o servicio, incluyendo reconocimiento de patrones, técnicas de perfilado, y reconocimiento óptico de caracteres. Se puede apreciar que pueden usarse la aplicación de reconocimiento de imágenes 392 o la aplicación de OCR 394, o ambas.
En el bloque 468, se determina si la imagen contiene una dirección de red. Por ejemplo, si la imagen incluye texto, el texto puede incluir una dirección de red (por ejemplo, URL o dirección de sitio web). Si es así, en el bloque 470, el dispositivo móvil usa los datos de imagen para obtener la dirección de red, y luego inicia un sitio web de pago para un producto o servicio dado usando la dirección de red (bloque 472).
Si no se incluye una dirección de red en los datos de imagen, luego en el bloque 474, los datos se derivan de los datos de imagen. Por ejemplo, un número de serie o un nombre de un producto o servicio puede derivarse del texto en la imagen. Esto se usa para identificar un producto o servicio que va a comprarse. En el bloque 476, los datos de imagen, o datos derivados de los datos de imagen, se usan para consultar una base de datos (por ejemplo, bases de datos 348 y 350) que almacena datos asociados con las direcciones de red. Por ejemplo, la imagen del zapato 458 también se almacena en la base de datos 348. Por lo tanto, cuando la imagen del zapato 458, que ha sido adquirida por el dispositivo móvil 10, se compara con la imagen ya almacenada en la base de datos 348, se identifica la coincidencia de las imágenes. Una dirección de red para un sitio web o página web de pago para comprar el par de zapatos se almacena en asociación con la imagen del zapato 458. Por lo tanto, se obtiene esta dirección de red correspondiente. De manera similar, el texto “Comprar entradas para la película HARRY POTTER” puede almacenarse en la base de datos 348 en asociación con una dirección de red para un sitio web o página web de pago para comprar una o más entradas de película para la película Harry Potter.
En el bloque 478, el dispositivo móvil 10 obtiene la dirección de red asociada con los datos de imagen (o los datos derivados de los datos de imagen). En el bloque 480, el dispositivo móvil 10 inicia el sitio web de pago para un producto o servicio dado usando la dirección de red.
Se puede apreciar que las operaciones del bloque 466, el bloque 468, el bloque 474, o el bloque 476 pueden implementarse por el dispositivo móvil 10 o el servidor 346.
Al iniciar el sitio web o página web de pago, se pueden llevar a cabo las operaciones descritas anteriormente para autenticar una transacción. Las operaciones, por ejemplo, incluyen recibir mediante el dispositivo móvil 10 la ID complementaria.
Se proporciona otra realización de ejemplo en la que se usan datos de audio para adquirir una dirección de red para un sitio web o página web de pago. Volviendo a la figura 33, el dispositivo móvil 10 puede usar el micrófono 362 para grabar o capturar datos de audio. Ejemplos de datos de audio incluyen música 482, voz (en un idioma dado) 484, y otros ruidos o sonidos. Una aplicación de reconocimiento de audio 396 o una aplicación de reconocimiento de música 398, o ambas, pueden usarse para obtener datos usados para determinar una dirección de red.
En una realización de ejemplo, se está reproduciendo música 482 y el dispositivo móvil 10 captura o graba la música 482. El dispositivo móvil 10 luego reconoce la canción y obtiene una dirección de red para un sitio web o página web de pago en la que se puede comprar la canción reconocida. En otra realización de ejemplo, la voz 484 incluye detalles sobre un producto o servicio. Por ejemplo, la voz 484 puede tener las palabras “ ¡Todo el mundo! ¡Escuchen! ¡Compre un ordenador AX31 nuevo y reciba un 20 % de descuento! ¡Use el código de descuento: 20AX31”. Se reconocen de la voz las palabras “Ordenador AX31”, y la dirección de red se obtiene para un sitio web o página web de pago que se usa para comprar el ordenador particular. Las palabras “código de descuento: 20AX31” también puede reconocerse, y un descuento dado (por ejemplo, el 20 %) se aplica automáticamente a la compra mostrada en el sitio web de pago o página web para el ordenador. Los detalles se proporcionan a continuación.
Continuando con la figura 33, el dispositivo móvil 10 captura o graba datos de audio (bloque 486) y el reconocimiento de audio se aplica a los datos de audio (bloque 488). Se pueden usar técnicas de reconocimiento de audio tales como reconocimiento de voz y reconocimiento de música. Se determina si los datos de audio contienen una dirección de red (bloque 490). Por ejemplo, los datos de audio pueden ser una grabación de una persona que dice “w - w - w - punto -comprar - entradas - de - película - punto - com - barra - uno - dos - tres - punto - h - 1 - m - 1”. Esta dirección de red “www.buymovieticskets.com/123.html” se obtiene luego usando reconocimiento de voz.
Si los datos de audio incluyen una dirección de red, en el bloque 492, el dispositivo móvil 10 usan los datos de audio para extraer la dirección de red, y luego inicia un sitio web o página web de pago para un producto o servicio dado usando la dirección de red (bloque 494).
Si no se incluye una dirección de red en los datos de audio, a continuación, los datos de audio se usan para determinar una identificación de la canción o producto o servicio (bloque 496). La identificación puede ser un nombre, número de serie, etc. La identificación se usa para consultar o buscar en una base de datos (por ejemplo, bases de datos 348 y 350) que almacenan las identificaciones en asociación con direcciones de red (bloque 498). El dispositivo móvil l0 obtiene la dirección de red asociada con la identificación.
En una realización de ejemplo, el dispositivo móvil 10 envía los datos de audio al servidor 346, que extrae el identificador de producto o servicio. El servidor 346 determina entonces la dirección de red asociada para un sitio web o página web de pago para comprar el producto o servicio identificado, y luego devuelve la dirección de red al dispositivo móvil 10.
En otra realización de ejemplo, el dispositivo móvil 10 extrae el identificador de producto o servicio de los datos de audio, y luego envía el identificador al servidor 346. El servidor 346 determina entonces la dirección de red asociada para un sitio web o página web de pago para comprar el producto o servicio identificado, y luego devuelve la dirección de red al dispositivo móvil 10.
Al obtener la dirección de red, el dispositivo móvil 10 inicia el sitio web o página web de pago para el producto o servicio dado (bloque 502).
Se puede apreciar que las operaciones del bloque 488, el bloque 496, el bloque 474, o el bloque 498 pueden implementarse por el dispositivo móvil 10 o el servidor 346.
Al iniciar el sitio web o página web de pago, se pueden llevar a cabo las operaciones descritas anteriormente para autenticar una transacción. Las operaciones, por ejemplo, incluyen recibir mediante el dispositivo móvil 10 la ID complementaria.
Se puede apreciar que el proceso de adquisición de datos, usando los datos para obtener automáticamente una dirección de red para un sitio web o página web de pago, e iniciando o visualizando automáticamente el sitio web o página web de pago, proporciona una experiencia de compra más fluida e integrada. Esto reduce el número de entradas requeridas por el usuario, lo que también ahorra tiempo.
Los sistemas y métodos relacionados con iniciar una transacción pueden combinarse con cualquiera de los otros sistemas y métodos relacionados con la ejecución y autenticación de transacciones, incluyendo los descritos en el presente documento. Por ejemplo, la página web mostrada puede incluir un campo para introducir en el mismo una ID complementaria, que se usa para autenticar y ejecutar la transacción.
En otro aspecto, el dispositivo móvil recibe una ID complementaria a través de la página web, la ID complementaria para verificar una ID de pago de una cuenta de pago usada para comprar el producto o el servicio. En otro aspecto, el dispositivo móvil genera una firma digital y el dispositivo móvil envía la firma digital y una ID de dispositivo móvil a una pasarela de pago para autenticar la transacción. En otro aspecto, el dispositivo móvil recibe al menos una selección para modificar uno o más parámetros asociados con la transacción. En otro aspecto, el uno o más parámetros incluyen la cantidad del producto que va a comprarse. En otro aspecto, el dispositivo móvil usa los datos para buscar la dirección de red en una base de datos, la base de datos asocia identificaciones de productos o servicios con direcciones de red. En otro aspecto, el dispositivo móvil envía los datos a un servidor, y el servidor busca la dirección de red en la base de datos, y devuelve la dirección de red al dispositivo móvil. En otro aspecto, los datos adquiridos son una imagen de código de barras. En otro aspecto, los datos adquiridos son una imagen de un objeto, o texto, o ambos. En otro aspecto, la imagen es una imagen de vídeo. En otro aspecto, los datos adquiridos son datos de audio.
El alcance de la invención se define en las reivindicaciones adjuntas.

Claims (14)

REIVINDICACIONES
1. Un sistema para autenticar una transacción en un dispositivo móvil, comprendiendo el sistema:
un dispositivo móvil (10) en comunicación con una pasarela de pago (8), la pasarela de pago en comunicación con un módulo de verificación (23);
en el que en un proceso de registro:
- el dispositivo móvil (10) está configurado para recibir al menos una ID de pago de una cuenta de pago y una ID complementaria para verificar la ID de pago, y transmitir (56) la ID de pago y la ID complementaria a la pasarela de pago (8);
- la pasarela de pago (8) está configurada para recibir la ID de pago y la ID complementaria del dispositivo móvil (10) y enviar (58) la ID de pago y la ID complementaria al módulo de verificación (23) sin almacenar la ID complementaria en la pasarela de pago (8), el módulo de verificación configurado para verificar (60) la ID complementaria y la ID de pago;
- la pasarela de pago (8) está configurada para, después de que la pasarela de pago (8) recibe un resultado de verificación desde el módulo de verificación (23) de que la ID de pago y la ID complementaria se verifican con éxito, obtener al menos una característica del dispositivo móvil (10) y generar (64) una ID de dispositivo móvil derivada de la al menos una característica del dispositivo móvil (10), almacenar la ID de dispositivo móvil en asociación con la ID de pago, y enviar (66) la ID de dispositivo móvil al dispositivo móvil; y,
- el dispositivo móvil (10) está configurado para almacenar (68) la ID de dispositivo móvil recibida desde la pasarela de pago (8); y,
en el que, en un proceso de transacción:
- el dispositivo móvil (10) está configurado para recibir la ID complementaria, recuperar la ID de dispositivo móvil almacenada, y enviar (70) la ID complementaria y la ID de dispositivo móvil a la pasarela de pago;
- la pasarela de pago (8) está configurada para recuperar (74) la ID de pago asociada con la ID de dispositivo móvil recibida y enviar (78) la ID de pago y la ID complementaria al módulo de verificación (23) para su verificación; y,
- después de que la pasarela de pago (8) recibe otro resultado de verificación desde el módulo de verificación (23) de que la ID complementaria y la ID de pago se verifican con éxito, la pasarela de pago está configurada para ejecutar la transacción;
- en el que la pasarela de pago está configurada para generar (86) una nueva ID de dispositivo móvil que reemplaza la ID de dispositivo móvil y para asociar (86) la nueva ID de dispositivo móvil con la ID de pago para cada ejecución posterior del proceso de transacción.
2. El sistema según la reivindicación 1, en el que las operaciones de la pasarela de pago y el módulo de verificación se combinan en un servidor unificado.
3. El sistema según una cualquiera de las reivindicaciones 1 a 2, en el que la pasarela de pago ejecuta la transacción a través de un servidor de pago, el servidor de pago en comunicación con al menos uno de la pasarela de pago y el módulo de verificación.
4. El sistema según una cualquiera de las reivindicaciones 1 a 3, en el que la ID de pago está compuesta por al menos uno de: un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, y un número de cuenta de puntos.
5. El sistema según una cualquiera de las reivindicaciones 1 a 4, en el que la ID complementaria está compuesta por al menos uno de: un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), una verificación de código de tarjeta (CCV), un pin, una contraseña, datos biométricos, y datos de voz.
6. El sistema según una cualquiera de las reivindicaciones 1 a 5, en el que la al menos una característica del dispositivo móvil (10) incluye al menos uno de: información de identidad de abonado almacenada en una tarjeta SIM o IMEI del dispositivo móvil, información de red, una dirección IP, una identificación de operador telefónico, una dirección de puerto, un nombre de DNS, una coordenada GPS del dispositivo móvil, la temperatura de batería del dispositivo móvil, una ubicación geográfica del dispositivo móvil, una lectura de acelerómetro del dispositivo móvil, una cookie, un agente de usuario, y un encabezado, en donde la cookie, el agente de usuario y el encabezado se proporcionan por un navegador en el dispositivo móvil o un almacenamiento DOM en el dispositivo móvil.
7. El sistema según una cualquiera de las reivindicaciones 1 a 6, en el que la ID de dispositivo móvil incluye datos generados aleatoriamente.
8. El sistema según una cualquiera de las reivindicaciones 1 a 8 que comprende además, durante el proceso de transacción, comparar mediante la pasarela de pago la ID de dispositivo móvil recibida con la ID de dispositivo móvil previamente almacenada en la misma para determinar si son similares, y si es así, permitir que se ejecute la transacción.
9. El sistema según la reivindicación 9, en el que la ID de dispositivo móvil recibida en el proceso de transacción debe ser igual a la ID de dispositivo móvil previamente almacenada en la pasarela de pago para que se ejecute la transacción.
10. Un método para autenticar una transacción en un dispositivo móvil, comprendiendo el método:
un proceso de registro, comprendiendo el proceso de registro:
- recibir mediante el dispositivo móvil (10) al menos una ID de pago de una cuenta de pago y una ID complementaria para verificar la ID de pago, y transmitir la ID de pago y la ID complementaria a una pasarela de pago (8);
- recibir mediante la pasarela de pago (8) la ID de pago y la ID complementaria desde el dispositivo móvil (10) y enviar la ID de pago y la ID complementaria a un módulo de verificación (23) sin almacenar la ID complementaria en la pasarela de pago (8), el módulo de verificación (23) configurado para verificar la ID complementaria y la ID de pago;
- después de que la pasarela de pago (8) recibe un resultado de verificación desde el módulo de verificación (23) de que la ID de pago y la ID complementaria se verifican con éxito, obtener mediante la pasarela de pago al menos una característica del dispositivo móvil (10) y generar mediante la pasarela de pago (8) una ID de dispositivo móvil derivada de la al menos una característica del dispositivo móvil (10), almacenar la ID de dispositivo móvil en asociación con la ID de pago, y enviar la ID de dispositivo móvil al dispositivo móvil; y, - almacenar mediante el dispositivo móvil (10) la ID de dispositivo móvil recibida desde la pasarela de pago (8); y,
un proceso de transacción, comprendiendo el proceso de transacción:
- recibir mediante el dispositivo móvil (10) la ID complementaria, recuperar la ID de dispositivo móvil almacenada, y enviar la ID complementaria y la ID de dispositivo móvil a la pasarela de pago (8);
- recuperar mediante la pasarela de pago (8) la ID de pago asociada con la ID de dispositivo móvil recibida y enviar la ID de pago y la ID complementaria al módulo de verificación (23) para su verificación;
- después de que la pasarela de pago (8) recibe otro resultado de verificación desde el módulo de verificación (23) de que la ID complementaria y la ID de pago se verifican con éxito, ejecutar mediante la pasarela de pago (8) la transacción;
- generar mediante la pasarela de pago (86) una nueva ID de dispositivo móvil que reemplaza la ID de dispositivo móvil y asociar (86) la nueva ID de dispositivo móvil con la ID de pago para cada ejecución posterior del proceso de transacción.
11. El método según la reivindicación 10, en el que ejecutar mediante la pasarela de pago la transacción comprende ejecutar mediante la pasarela de pago la transacción a través de un servidor de pago, el servidor de pago en comunicación con al menos uno de la pasarela de pago y el módulo de verificación.
12. El método según una cualquiera de las reivindicaciones 10 a 11, en el que la ID de pago está compuesta por al menos uno de: un número de tarjeta de crédito, una fecha de caducidad, un número de tarjeta bancaria, un número bancario, y un número de cuenta de puntos.
13. El método según una cualquiera de las reivindicaciones 10 a 12, en el que la ID complementaria está compuesta por al menos uno de: un valor de seguridad de tarjeta (CSV), un código de seguridad de tarjeta (CSC), un valor de verificación de tarjeta (CVV o CVV2), un código de valor de verificación de tarjeta (CVVC), un código de verificación de tarjeta (CVC o CVC2), un código de verificación (V-Code o Código V), una verificación de código de tarjeta (CCV), un pin, una contraseña, datos biométricos, y datos de voz.
14. El método según una cualquiera de las reivindicaciones 10 a 13, en el que la al menos una característica del dispositivo móvil (10) incluye al menos uno de: información de identidad de abonado almacenada en una tarjeta SIM o IMEI del dispositivo móvil, información de red, una dirección IP, una identificación de operador telefónico, una dirección de puerto, un nombre de DNS, una coordenada GPS del dispositivo móvil, la temperatura de batería del dispositivo móvil, una ubicación geográfica del dispositivo móvil, una lectura de acelerómetro del dispositivo móvil, una cookie, un agente de usuario, y un encabezado, en donde la cookie, el agente de usuario y el encabezado se proporcionan por un navegador en el dispositivo móvil o un almacenamiento DOM en el dispositivo móvil.
ES11849728T 2010-12-14 2011-12-13 Autenticación de transacciones usando un identificador de dispositivo móvil Active ES2951585T3 (es)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
CA2724297A CA2724297C (en) 2010-12-14 2010-12-14 System and method for authenticating transactions through a mobile device
CA2743035A CA2743035C (en) 2010-12-14 2011-06-14 System and method for authenticating transactions through a mobile device
US13/162,324 US8655782B2 (en) 2010-12-14 2011-06-16 System and method for authenticating transactions through a mobile device
CA2748481A CA2748481C (en) 2010-12-14 2011-08-11 System and method for initiating transactions on a mobile device
US201161522862P 2011-08-12 2011-08-12
PCT/CA2011/050771 WO2012079170A1 (en) 2010-12-14 2011-12-13 Authenticating transactions using a mobile device identifier

Publications (1)

Publication Number Publication Date
ES2951585T3 true ES2951585T3 (es) 2023-10-23

Family

ID=43646043

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11849728T Active ES2951585T3 (es) 2010-12-14 2011-12-13 Autenticación de transacciones usando un identificador de dispositivo móvil

Country Status (7)

Country Link
US (1) US8655782B2 (es)
EP (1) EP2652688B1 (es)
CN (2) CN106875173B (es)
AU (1) AU2011342282B2 (es)
CA (3) CA2724297C (es)
ES (1) ES2951585T3 (es)
WO (1) WO2012079170A1 (es)

Families Citing this family (200)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8985442B1 (en) * 2011-07-18 2015-03-24 Tiger T G Zhou One-touch payment using haptic control via a messaging and calling multimedia system on mobile device and wearable device, currency token interface, point of sale device, and electronic payment card
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US9846866B2 (en) * 2007-02-22 2017-12-19 First Data Corporation Processing of financial transactions using debit networks
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
US10157269B2 (en) * 2010-05-06 2018-12-18 John K. Thomas Verification system for secure transmission in a distributed processing network
US9596237B2 (en) 2010-12-14 2017-03-14 Salt Technology, Inc. System and method for initiating transactions on a mobile device
US10263936B2 (en) * 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner
US10546306B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US9473647B2 (en) 2011-09-07 2016-10-18 Elwha Llc Computational systems and methods for identifying a communications partner
US9159055B2 (en) 2011-09-07 2015-10-13 Elwha Llc Computational systems and methods for identifying a communications partner
US10546295B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9491146B2 (en) 2011-09-07 2016-11-08 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US9928485B2 (en) 2011-09-07 2018-03-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9432190B2 (en) 2011-09-07 2016-08-30 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US9690853B2 (en) 2011-09-07 2017-06-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9195848B2 (en) 2011-09-07 2015-11-24 Elwha, Llc Computational systems and methods for anonymized storage of double-encrypted data
US9141977B2 (en) 2011-09-07 2015-09-22 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US20130085944A1 (en) * 2011-09-29 2013-04-04 Pacid Technologies, Llc System and method for application security
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
DE202012100620U1 (de) 2011-11-22 2012-06-13 Square, Inc. System zur Bearbeitung von kartenlosen Bezahlungstransaktionen
CN103186853B (zh) * 2011-12-31 2016-07-13 北大方正集团有限公司 一种服务器端和客户端移动支付方法、装置及***
US10049168B2 (en) * 2012-01-31 2018-08-14 Openwave Mobility, Inc. Systems and methods for modifying webpage data
CN103248495B (zh) * 2012-02-10 2016-03-30 ***通信集团公司 一种应用内付费的方法、服务器、客户端和***
US9633201B1 (en) 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US9373112B1 (en) 2012-03-16 2016-06-21 Square, Inc. Ranking of merchants for cardless payment transactions
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
DE102012005952A1 (de) 2012-03-26 2013-09-26 Percy Dahm Verfahren zur evidenzbasierten Absicherung mobiler Zahlungstransaktionen
CA2909081C (en) 2012-04-16 2022-05-10 Salt Technology Inc. Systems and methods for facilitating a transaction using a virtual card on a mobile device
US8458090B1 (en) * 2012-04-18 2013-06-04 International Business Machines Corporation Detecting fraudulent mobile money transactions
US9934511B2 (en) 2012-06-29 2018-04-03 Mastercard International Incorporated System and method for determining merchant location and availability using transaction data
US9811837B2 (en) 2012-06-29 2017-11-07 Mastercard International Incorporated System and method for setting a product watch on transaction data
US10586260B2 (en) 2012-07-19 2020-03-10 Apple Inc. Securing in-app purchases
US9785945B2 (en) 2012-08-01 2017-10-10 Mastercard International Incorporated System and method for preventing multiple refunds and chargebacks
US10332088B2 (en) 2012-08-01 2019-06-25 Mastercard International Incorporated System and method for setting a hot product alert on transaction data
WO2014022813A1 (en) 2012-08-02 2014-02-06 The 41St Parameter, Inc. Systems and methods for accessing records via derivative locators
EP2883180B1 (en) * 2012-08-10 2018-07-11 Chipp'd Ltd. System for providing multiple levels of authentication before delivering private content to client devices
US20150206126A1 (en) * 2012-08-16 2015-07-23 Rockhard Business Concepts And Consulting Cc Authentication method and system
US20150235215A1 (en) * 2012-08-16 2015-08-20 Tango Mobile, LLC System and Method for Mobile or Web-Based Payment/Credential Process
US20140052613A1 (en) 2012-08-17 2014-02-20 Square, Inc., A Delaware Corporation Systems and methods for providing gratuities to merchants
JP2015527675A (ja) * 2012-08-21 2015-09-17 コリア クレデック ライフ カンパニー リミテッド スマートフォンを活用してクレジットカード売上伝票を使用しないクレジットカード取引方法
CN103138935B (zh) * 2013-01-25 2016-05-04 宝利数码有限公司 一种基于电信运营商的身份认证***
CN102915604A (zh) * 2012-08-31 2013-02-06 宝利数码有限公司 一种基于二维码和电信服务商的移动支付***
US20140067687A1 (en) * 2012-09-02 2014-03-06 Mpayme Ltd. Clone defence system for secure mobile payment
US20140067678A1 (en) * 2012-09-02 2014-03-06 Mpayme Ltd. Dispute code system for secure mobile payment
US20140074704A1 (en) * 2012-09-11 2014-03-13 Cashstar, Inc. Systems, methods and devices for conducting transactions with electronic passbooks
US10223688B2 (en) * 2012-09-24 2019-03-05 Samsung Electronics Co., Ltd. Competing mobile payment offers
US9818152B2 (en) 2012-10-18 2017-11-14 Mastercard International Incorporated System and method for allowing forward-sold goods purchased via credit/debit card to be resold
WO2014078569A1 (en) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systems and methods of global identification
CN103020827B (zh) * 2012-12-05 2017-06-23 北京奇虎科技有限公司 支付处理方法和***
CN104969245B (zh) * 2013-02-06 2018-10-19 苹果公司 用于安全元件交易和资产管理的装置和方法
US9704146B1 (en) 2013-03-14 2017-07-11 Square, Inc. Generating an online storefront
US9940616B1 (en) 2013-03-14 2018-04-10 Square, Inc. Verifying proximity during payment transactions
WO2014184671A2 (en) * 2013-04-15 2014-11-20 Tactegic Holdings Pty Limited Systems and methods for efficient network security adjustment
US9084115B2 (en) 2013-05-13 2015-07-14 Dennis Thomas Abraham System and method for data verification using a smart phone
US20140379580A1 (en) 2013-06-25 2014-12-25 Square, Inc. Integrated online and offline purchase authorization
CN103839322B (zh) * 2013-07-10 2017-04-19 天地融科技股份有限公司 智能卡及校验数据输出方法、操作请求响应方法及***
US20150032621A1 (en) * 2013-07-24 2015-01-29 Mastercard International Incorporated Method and system for proximity fraud control
CN103413220A (zh) * 2013-08-08 2013-11-27 天地融科技股份有限公司 一种信息输出方法、装置及信息处理方法、***
CN103414565B (zh) * 2013-08-08 2016-12-28 天地融科技股份有限公司 输出方法及安全设备、响应方法及***、执行方法及***
CN103414566B (zh) * 2013-08-08 2016-09-14 天地融科技股份有限公司 输出方法及安全设备、响应方法及***、执行方法及***
CN104426657B (zh) * 2013-08-23 2017-12-26 阿里巴巴集团控股有限公司 一种业务认证方法、***及服务器
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
US9922321B2 (en) 2013-10-22 2018-03-20 Square, Inc. Proxy for multiple payment mechanisms
US9836739B1 (en) 2013-10-22 2017-12-05 Square, Inc. Changing a financial account after initiating a payment using a proxy card
US10417635B1 (en) 2013-10-22 2019-09-17 Square, Inc. Authorizing a purchase transaction using a mobile device
US8892462B1 (en) 2013-10-22 2014-11-18 Square, Inc. Proxy card payment with digital receipt delivery
US9471913B1 (en) * 2013-10-23 2016-10-18 Compass Plus US, Corp. Method and system for cardless processing of E-invoicing
US10319013B2 (en) 2013-10-28 2019-06-11 Square, Inc. Electronic ordering system
US11803841B1 (en) 2013-10-29 2023-10-31 Block, Inc. Discovery and communication using direct radio signal communication
US20150134439A1 (en) 2013-11-08 2015-05-14 Square, Inc. Interactive digital receipt
US11481781B2 (en) 2013-12-18 2022-10-25 PayRange Inc. Processing interrupted transaction over non-persistent network connections
US8856045B1 (en) 2013-12-18 2014-10-07 PayRange Inc. Mobile-device-to-machine payment systems
US11481780B2 (en) 2013-12-18 2022-10-25 PayRange Inc. Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US20150170136A1 (en) * 2013-12-18 2015-06-18 PayRange Inc. Method and System for Performing Mobile Device-To-Machine Payments
US11074580B2 (en) 2013-12-18 2021-07-27 PayRange Inc. Device and method for providing external access to multi-drop bus peripheral devices
US9875473B2 (en) 2013-12-18 2018-01-23 PayRange Inc. Method and system for retrofitting an offline-payment operated machine to accept electronic payments
US11983692B2 (en) 2013-12-18 2024-05-14 PayRange Inc. Mobile payment module with dual function radio transmitter
US11966926B2 (en) 2013-12-18 2024-04-23 PayRange Inc. Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US9659296B2 (en) 2013-12-18 2017-05-23 PayRange Inc. Method and system for presenting representations of payment accepting unit events
US11205163B2 (en) 2013-12-18 2021-12-21 PayRange Inc. Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options
US11966895B2 (en) 2013-12-18 2024-04-23 PayRange Inc. Refund centers for processing and dispensing vending machine refunds via an MDB router
US10019724B2 (en) 2015-01-30 2018-07-10 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
US11475454B2 (en) 2013-12-18 2022-10-18 PayRange Inc. Intermediary communications over non-persistent network connections
US10810682B2 (en) 2013-12-26 2020-10-20 Square, Inc. Automatic triggering of receipt delivery
US10621563B1 (en) 2013-12-27 2020-04-14 Square, Inc. Apportioning a payment card transaction among multiple payers
US20150186875A1 (en) * 2013-12-30 2015-07-02 Tencent Technology (Shenzhen) Company Limited Information Configuration Method, Device, System, Client And Server
CN104753687B (zh) * 2013-12-31 2019-01-01 ***通信集团公司 一种基于统一计费平台的计费方法及装置
US10206098B2 (en) * 2014-01-07 2019-02-12 Cellco Partnership System and methods of transaction originator identifier for on-line commercial transaction
WO2015150917A2 (en) * 2014-02-05 2015-10-08 Salt Technology Inc. System and method for authenticating transactions through a mobile device
US9405925B2 (en) 2014-02-09 2016-08-02 Microsoft Technology Licensing, Llc Content item encryption on mobile devices
US10198731B1 (en) 2014-02-18 2019-02-05 Square, Inc. Performing actions based on the location of mobile device during a card swipe
US9224141B1 (en) 2014-03-05 2015-12-29 Square, Inc. Encoding a magnetic stripe of a card with data of multiple cards
US10692059B1 (en) 2014-03-13 2020-06-23 Square, Inc. Selecting a financial account associated with a proxy object based on fund availability
US9355374B2 (en) 2014-03-19 2016-05-31 Bluefin Payment Systems Llc Systems and methods for creating fingerprints of encryption devices
US11256798B2 (en) 2014-03-19 2022-02-22 Bluefin Payment Systems Llc Systems and methods for decryption as a service
US9461973B2 (en) 2014-03-19 2016-10-04 Bluefin Payment Systems, LLC Systems and methods for decryption as a service
US9864986B1 (en) 2014-03-25 2018-01-09 Square, Inc. Associating a monetary value card with a payment object
US9619792B1 (en) 2014-03-25 2017-04-11 Square, Inc. Associating an account with a card based on a photo
SG10201401620VA (en) * 2014-04-17 2015-11-27 Mastercard Asia Pacific Pte Ltd A Method For Authenticating A Transaction, And Corresponding Servers, Systems, Devices, Computer-Readable Storage Mediums And Computer Programs
US10026083B1 (en) 2014-05-11 2018-07-17 Square, Inc. Tab for a venue
US9652751B2 (en) 2014-05-19 2017-05-16 Square, Inc. Item-level information collection for interactive payment experience
US20150348024A1 (en) * 2014-06-02 2015-12-03 American Express Travel Related Services Company, Inc. Systems and methods for provisioning transaction data to mobile communications devices
US9454773B2 (en) 2014-08-12 2016-09-27 Danal Inc. Aggregator system having a platform for engaging mobile device users
US10154082B2 (en) 2014-08-12 2018-12-11 Danal Inc. Providing customer information obtained from a carrier system to a client device
US9461983B2 (en) 2014-08-12 2016-10-04 Danal Inc. Multi-dimensional framework for defining criteria that indicate when authentication should be revoked
CN104268756B (zh) * 2014-09-18 2019-03-05 努比亚技术有限公司 移动支付方法和***
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
US10230531B2 (en) 2014-10-23 2019-03-12 Hewlett Packard Enterprise Development Lp Admissions control of a device
WO2016068942A1 (en) 2014-10-30 2016-05-06 Hewlett Packard Enterprise Development Lp Encryption for transactions in a memory fabric
US10699031B2 (en) * 2014-10-30 2020-06-30 Hewlett Packard Enterprise Development Lp Secure transactions in a memory fabric
US9477956B2 (en) * 2014-12-17 2016-10-25 Mastercard International Incorporated Method to enable consumers to make purchases at E-commerce websites using their mobile number
US9860825B2 (en) * 2014-12-22 2018-01-02 Verizon Patent And Licensing Inc. Mobile hardware identity in an environment with multiple radio access networks
KR102264992B1 (ko) 2014-12-31 2021-06-15 삼성전자 주식회사 무선 통신 시스템에서 서버 할당 방법 및 장치
CN104599124A (zh) * 2015-01-06 2015-05-06 宇龙计算机通信科技(深圳)有限公司 移动支付信息的保护方法、装置及移动支付***
WO2016118523A1 (en) 2015-01-19 2016-07-28 InAuth, Inc. Systems and methods for trusted path secure communication
USD862501S1 (en) 2015-01-30 2019-10-08 PayRange Inc. Display screen or portion thereof with a graphical user interface
USD836118S1 (en) 2015-01-30 2018-12-18 Payrange, Inc. Display screen or portion thereof with an animated graphical user interface
US20160224973A1 (en) * 2015-02-01 2016-08-04 Apple Inc. User interface for payments
EP3257005A4 (en) * 2015-02-11 2018-07-04 Mastercard International Incorporated Online form fill for tokenized credentials
CN105989485B (zh) * 2015-02-16 2020-06-05 阿里巴巴集团控股有限公司 一种业务管理方法和装置
US10193700B2 (en) 2015-02-27 2019-01-29 Samsung Electronics Co., Ltd. Trust-zone-based end-to-end security
CN104735079B (zh) * 2015-04-02 2018-10-30 北京嘀嘀无限科技发展有限公司 基于域名***dns的支付验证方法及设备
US9721251B1 (en) 2015-05-01 2017-08-01 Square, Inc. Intelligent capture in mixed fulfillment transactions
US10026062B1 (en) 2015-06-04 2018-07-17 Square, Inc. Apparatuses, methods, and systems for generating interactive digital receipts
US11354625B2 (en) 2015-07-23 2022-06-07 Adp, Inc. Employment verification system
US10846696B2 (en) 2015-08-24 2020-11-24 Samsung Electronics Co., Ltd. Apparatus and method for trusted execution environment based secure payment transactions
US10699274B2 (en) 2015-08-24 2020-06-30 Samsung Electronics Co., Ltd. Apparatus and method for secure electronic payment
US9935941B2 (en) 2015-09-16 2018-04-03 International Business Machines Corporation Mobile based multi-channel citizen account origination in digital economy
EP3153985A1 (en) * 2015-10-08 2017-04-12 Thomson Licensing Device and method for password generation in a user device
CN105898728A (zh) * 2015-10-22 2016-08-24 乐视致新电子科技（天津）有限公司 手机账号会员权益绑定方法、手机设备、服务器及***
CN113947396A (zh) * 2015-12-30 2022-01-18 创新先进技术有限公司 一种***支付请求处理方法及装置
US20170193466A1 (en) * 2015-12-31 2017-07-06 Jonathan A Clark Electronic system for routing marketplace transactions
WO2017127564A1 (en) 2016-01-19 2017-07-27 Priv8Pay, Inc. Network node authentication
US10601859B2 (en) * 2016-02-25 2020-03-24 Trusona, Inc. Anti-replay systems and methods
US10636019B1 (en) 2016-03-31 2020-04-28 Square, Inc. Interactive gratuity platform
FR3050348A1 (fr) * 2016-04-18 2017-10-20 Orange Procede d'obtention par un terminal mobile d'un jeton de securite
US10810583B2 (en) 2016-04-29 2020-10-20 Digital Asset Holdings Digital asset modeling
CN106096943B (zh) * 2016-06-01 2019-12-03 中国联合网络通信集团有限公司 基于nfc的支付方法、扣费装置及终端
RU2635276C1 (ru) * 2016-06-24 2017-11-09 Акционерное общество "Лаборатория Касперского" Безопасная аутентификация по логину и паролю в сети Интернет с использованием дополнительной двухфакторной аутентификации
GB2552458A (en) 2016-06-30 2018-01-31 Vocalink Ltd Generation of web pages for verification of data
CA3029619C (en) * 2016-07-01 2022-12-06 American Express Travel Related Services Company, Inc. Systems and methods for validating transmissions over communication channels
CN110086809B (zh) * 2016-07-13 2022-03-15 吴平 通过移动设备对附近目标设施进行权限操作
WO2018022993A1 (en) 2016-07-29 2018-02-01 Trusona, Inc. Anti-replay authentication systems and methods
WO2018049234A1 (en) 2016-09-09 2018-03-15 Trusona, Inc. Systems and methods for distribution of selected authentication information for a network of devices
KR20190062402A (ko) 2016-10-12 2019-06-05 모하메드 하마드 알 하즈리 대용 셀룰러리스 로밍
CN106485487A (zh) * 2016-10-13 2017-03-08 中国互联网络信息中心 一种网上支付方法、域名***及网上支付装置
CN107026836B (zh) 2016-10-28 2020-03-06 阿里巴巴集团控股有限公司 一种业务实现方法和装置
WO2018111858A1 (en) 2016-12-12 2018-06-21 Trusona, Inc. Methods and systems for network-enabled account creation using optical detection
TWI661366B (zh) * 2017-01-12 2019-06-01 財金資訊股份有限公司 以電子裝置進行支付之方法及其系統
CA3029871C (en) * 2017-02-01 2021-04-20 Tai Chiu CHAN Authentication server, authentication system and method
CN108573373A (zh) * 2017-03-13 2018-09-25 上海诺基亚贝尔股份有限公司 用于安全支付的方法和装置
US20180285944A1 (en) * 2017-03-30 2018-10-04 Mastercard International Incorporated Methods and Systems for Use in Providing Spend Profiles for Reviewers, in Response to Requests for Validation of Reviews Submitted by the Reviewers
US10097663B1 (en) * 2017-05-22 2018-10-09 American Express Travel Related Services Company, Inc. Using integrated code to extract device characteristics for online security
JP7093531B2 (ja) * 2017-06-02 2022-06-30 ブルーフィン ペイメント システムズ エルエルシー ウェブブラウザを介して決済端末を管理するシステム及び方法
US20180349891A1 (en) * 2017-06-02 2018-12-06 Bluefin Payment Systems Llc Systems and methods for online payment processing using secure inline frames
US11711350B2 (en) 2017-06-02 2023-07-25 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption
US10515342B1 (en) 2017-06-22 2019-12-24 Square, Inc. Referral candidate identification
TWI668656B (zh) * 2017-07-19 2019-08-11 臺灣銀行股份有限公司 自動電匯解款伺服器
IT201700087233A1 (it) * 2017-07-28 2019-01-28 Alessandro Capuzzello Sistema di autenticazione sicura dell’identità di un utente in un sistema elettronico per transazioni bancarie
CN108241974B (zh) * 2017-12-06 2020-11-10 创新先进技术有限公司 Nfc便携设备的写入、支付方法、装置以及设备
US11188904B2 (en) 2017-12-15 2021-11-30 Mastercard International Incorporated Methods, system and computer program products for wireless device based authentication
CN108304858B (zh) * 2017-12-28 2022-01-04 ***股份有限公司 对抗样本识别模型生成方法、验证方法及其***
CN108205852A (zh) * 2017-12-29 2018-06-26 新开普电子股份有限公司 Pos终端加密支付方法
CN108416592B (zh) * 2018-03-19 2022-08-05 成都信达智胜科技有限公司 一种高速语音识别方法
AU2019253110B2 (en) 2018-04-13 2022-09-01 Plaid Inc. Secure permissioning of access to user accounts, including secure distribution of aggregated user account data
US10496998B1 (en) 2018-05-15 2019-12-03 Capital One Services, Llc Generating a random verification code for a transaction
CN109035636A (zh) * 2018-06-04 2018-12-18 阿里巴巴集团控股有限公司 一种收款设备、一种收款方法及装置
US10810585B2 (en) * 2018-07-06 2020-10-20 Mastercard International Incorporated Systems and methods for authenticating users in connection with mobile operations
US11765262B2 (en) 2018-09-27 2023-09-19 Iqx Corp. Customer capture using dynamically generated customized webpages
US10944745B2 (en) 2018-12-06 2021-03-09 Bank Of America Corporation System and method for device and transaction authentication
US10986079B2 (en) 2018-12-06 2021-04-20 Bank Of America Corporation System and method for hierarchical decisioning within a hybrid blockchain
US11741465B2 (en) 2019-05-02 2023-08-29 Mastercard International Incorporated Systems and methods for generating pre-chargeback dispute records
EP4018618A4 (en) 2019-05-13 2023-10-25 Bluefin Payment Systems, LLC VAULTLESS TOKENIZATION AND ENCRYPTION SYSTEMS AND METHODS
US11233658B2 (en) 2019-08-14 2022-01-25 OX Labs Inc. Digital transaction signing for multiple client devices using secured encrypted private keys
CN110782257B (zh) * 2019-09-11 2022-03-15 黄海波 一种基于产品标识码和流通码的产品交易控制方法及设备
WO2021055618A1 (en) * 2019-09-17 2021-03-25 Plaid Inc. System and method linking to accounts using credential-less authentication
CN111062713B (zh) * 2019-11-25 2021-07-23 支付宝(杭州)信息技术有限公司 一种支付***、方法、服务器设备、介质及装置
CN111031066B (zh) * 2019-12-25 2022-02-01 哈尔滨新中新电子股份有限公司 一卡通***中pc机、网关和pos机之间数据传输方法
US11741620B1 (en) * 2020-01-24 2023-08-29 Apple Inc. Plane detection using depth sensor and semantic information
US10701561B1 (en) * 2020-01-31 2020-06-30 Lowe's Companies, Inc. System and techniques for secret key transfer in benefit denial system
US10721224B1 (en) 2020-01-31 2020-07-21 Lowe's Companies, Inc. System and techniques for trans-account device key transfer in benefit denial system
US11395142B2 (en) 2020-01-31 2022-07-19 Lowe's Companies, Inc. System and techniques for secret key transfer in benefit denial system
SG10202001079QA (en) * 2020-02-06 2020-07-29 Alipay Labs Singapore Pte Ltd Method and System for Processing a Transaction
CN111309745B (zh) * 2020-02-10 2022-04-22 腾讯科技（深圳）有限公司 虚拟资源处理方法、装置、电子设备及存储介质
CN111724494B (zh) * 2020-06-27 2022-05-10 阿波罗智联(北京)科技有限公司 交通信息的处理方法、装置、电子设备及存储介质
CN111880857B (zh) * 2020-07-17 2024-06-07 百度在线网络技术（北京）有限公司 小程序的下发方法、装置、设备以及存储介质
CN111901418B (zh) * 2020-07-28 2023-06-30 北京中科麒麟信息工程有限责任公司 基于单向文件传输协议的外接式终端防护设备及***
CA3189855A1 (en) 2020-08-18 2022-02-24 William Frederick Kiefer System and method for managing user interaction flows within third party applications
CN112464700A (zh) * 2020-08-19 2021-03-09 ***股份有限公司 基于生物特征信息的鉴权方法、计算机***和可读介质
CN113159874A (zh) * 2021-05-25 2021-07-23 北京中科闻歌科技股份有限公司 增值税***的检测方法、装置和可读存储介质
US11924350B2 (en) 2021-07-29 2024-03-05 Digital Asset (Switzerland) GmbH Cryptographically enforced partial blinding for distributed system
TWI782678B (zh) * 2021-08-26 2022-11-01 中華電信股份有限公司 應用於數位簽署元件的認證系統及方法
CN114095237B (zh) * 2021-11-17 2023-06-27 清华大学 基于区块链的去中心化的域间源地址验证服务***和方法
CN115936608B (zh) * 2022-12-01 2024-03-05 深圳市雁联计算***有限公司 基于交易链路的分布式流水号生成方法、装置及存储介质

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5237627A (en) 1991-06-27 1993-08-17 Hewlett-Packard Company Noise tolerant optical character recognition system
EP1334440A1 (en) 2000-09-21 2003-08-13 Trintech Limited A computerized method and system for a secure on-line transaction using cardholder authentication
US20090228816A1 (en) * 2000-11-20 2009-09-10 Andras Vilmos Method and system for realising on-line electronic purchase transaction between a buyer and a merchant
US7742984B2 (en) 2001-07-06 2010-06-22 Hossein Mohsenzadeh Secure authentication and payment system
US7373515B2 (en) 2001-10-09 2008-05-13 Wireless Key Identification Systems, Inc. Multi-factor authentication system
AUPS087602A0 (en) * 2002-03-04 2002-03-28 Ong, Yong Kin (Michael) Electronic fund transfer system
GB2387253B (en) 2002-04-03 2004-02-18 Swivel Technologies Ltd System and method for secure credit and debit card transactions
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
CN1922623A (zh) * 2004-02-17 2007-02-28 富士通株式会社 无线钱包
EP1785891A1 (en) 2005-11-09 2007-05-16 Sony Deutschland GmbH Music information retrieval using a 3D search algorithm
US20070288377A1 (en) * 2006-04-26 2007-12-13 Yosef Shaked System and method for authenticating a customer's identity and completing a secure credit card transaction without the use of a credit card number
CN106936587B (zh) * 2006-06-19 2020-05-12 维萨美国股份有限公司 消费者认证***和方法
US10102518B2 (en) 2007-02-22 2018-10-16 First Data Corporation Enrollment and registration of a device in a mobile commerce system
US7963441B2 (en) 2007-03-26 2011-06-21 Sears Brands, Llc System and method for providing self service checkout and product delivery using a mobile device
US20080249938A1 (en) 2007-04-03 2008-10-09 Cpni Inc. System and method for merchant discovery and transfer of payment data
US10853855B2 (en) 2007-05-20 2020-12-01 Michael Sasha John Systems and methods for automatic and transparent client authentication and online transaction verification
US20090119209A1 (en) * 2007-11-02 2009-05-07 Chris Sorensen Mobile transaction network
CA2730175A1 (en) 2008-07-09 2010-01-14 Xtreme Mobility Inc. Secure wireless deposit system and method
US7596530B1 (en) 2008-09-23 2009-09-29 Marcelo Glasberg Method for internet payments for content
CN101527070A (zh) * 2009-04-15 2009-09-09 唐宇良 安全交易控制方法和***
WO2010126509A2 (en) * 2009-04-30 2010-11-04 Donald Michael Cardina Systems and methods for randomized mobile payment
CN101794420A (zh) * 2009-12-31 2010-08-04 卓望数码技术（深圳）有限公司 一种支付认证方法、终端及***
US20110313898A1 (en) 2010-06-21 2011-12-22 Ebay Inc. Systems and methods for facitiating card verification over a network

Also Published As

Publication number Publication date
CN103443813A (zh) 2013-12-11
CN103443813B (zh) 2016-12-14
CA2748481A1 (en) 2011-10-17
EP2652688A1 (en) 2013-10-23
CN106875173B (zh) 2021-06-25
EP2652688A4 (en) 2015-01-21
CA2724297C (en) 2013-11-12
CA2748481C (en) 2014-10-14
US8655782B2 (en) 2014-02-18
WO2012079170A1 (en) 2012-06-21
AU2011342282B2 (en) 2017-02-23
CN106875173A (zh) 2017-06-20
CA2743035C (en) 2017-08-08
EP2652688B1 (en) 2023-06-21
US20120150742A1 (en) 2012-06-14
EP2652688C0 (en) 2023-06-21
AU2011342282A1 (en) 2013-08-01
CA2743035A1 (en) 2011-08-24
CA2724297A1 (en) 2011-03-04

Similar Documents

Publication Publication Date Title
ES2951585T3 (es) Autenticación de transacciones usando un identificador de dispositivo móvil
US10360561B2 (en) System and method for secured communications between a mobile device and a server
US9596237B2 (en) System and method for initiating transactions on a mobile device
US11895225B2 (en) Systems and methods for trustworthy electronic authentication using a computing device
JP7346426B2 (ja) 検証可能なクレームをバインドするシステム及び方法
US20120150748A1 (en) System and method for authenticating transactions through a mobile device
EP3138265B1 (en) Enhanced security for registration of authentication devices
KR102358546B1 (ko) 장치에 대해 클라이언트를 인증하기 위한 시스템 및 방법
CN106664208B (zh) 使用安全传输协议建立信任的***和方法
US20140156531A1 (en) System and Method for Authenticating Transactions Through a Mobile Device
US20180254904A1 (en) Integrated authentication system for authentication using single-use random numbers
CN113474774A (zh) 用于认可新验证器的***和方法
CN106575326A (zh) 利用非对称加密实施一次性密码的***和方法
WO2015150917A2 (en) System and method for authenticating transactions through a mobile device
KR101799517B1 (ko) 인증 서버 및 방법
Tran Mobile Payment Security: A case study of Digital Wallet MOMO
US20210194919A1 (en) System and method for protection against malicious program code injection