[go: up one dir, main page]

MX2011005324A - Metodo y aparato para proteccion dirigida por consumidor para transacciones con tarjeta de pago. - Google Patents

Metodo y aparato para proteccion dirigida por consumidor para transacciones con tarjeta de pago.

Info

Publication number
MX2011005324A
MX2011005324A MX2011005324A MX2011005324A MX2011005324A MX 2011005324 A MX2011005324 A MX 2011005324A MX 2011005324 A MX2011005324 A MX 2011005324A MX 2011005324 A MX2011005324 A MX 2011005324A MX 2011005324 A MX2011005324 A MX 2011005324A
Authority
MX
Mexico
Prior art keywords
transaction
account
information
criterion
authorize
Prior art date
Application number
MX2011005324A
Other languages
English (en)
Inventor
Richard Howard Ledbetter
Deborah Joy Ingram
Suzanne Adrienne Laprova
Original Assignee
Pscu Financial Services
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 Pscu Financial Services filed Critical Pscu Financial Services
Publication of MX2011005324A publication Critical patent/MX2011005324A/es

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Método y aparato para facilitar una transacción comercial entre un tenedor de cuenta y un comerciante. El tenedor de cuenta tiene una cuenta asociada con información de cuenta correspondiente. La información de cuenta incluye al menos un criterio de autorización previa de una transacción. Cuando el consumidor inicia una transacción de compra, se genera una solicitud de aprobación de transacción que incluye información referente a la transacción comercial. Una entidad para aprobación de compra compara la solicitud de aprobación para transacción recibida con la información de cuenta, para determinar si se satisface el criterio como mínimo para autorización previa de la transacción. Se niega la solicitud de aprobación de transacción cuando se realiza una determinación de que no se satisface el criterio como mínimo para autorización previa de la transacción.

Description

MÉTODO Y APARATO PARA PROTECCIÓN DIRIGIDA POR CONSUMIDOR PARA TRANSACCIONES CON TARJETA DE PAGO RECLAMACIÓN DE PRIORIDAD Esta solicitud reclama prioridad de la solicitud de patente de los E.U.A. No. de Serie 12/353,733 presentada el 14 de enero, 2009, que a su vez reclama prioridad de la solicitud de patente de los E.U.A. No. de Serie 12/275,975 presentada el 21 de noviembre, 2008.
CAMPO DE LA INVENCIÓN La presente invención se refiere a métodos y sistemas para proporcionar transacciones comerciales electrónicas seguras. En particular, la presente invención se refiere a métodos y sistemas para evitar transacciones comerciales que no son previamente autorizadas.
ANTECEDENTES DE LA INVENCIÓN El comercio electrónico, compra y venta por medios electrónicos, se ha vuelto común en la sociedad moderna. Con la expansión continua de la Red Mundial, el comercio electrónico se ha vuelto factible para cualquier persona u organización con una computadora. Por varias razones, cada vez más personas eligen realizar transacciones desde una computadora, por ejemplo compra o pago de facturas. Una razón por la que los consumidores son atraídos al comercio por Internet es debido a que los negocios basados en Internet típicamente ofrecen ítems con precios de descuento. Otra razón es que Internet es accesible las veinticuatro horas del dia, permitiendo que el consumidor realice negocios, por ejemplo, compre, a su conveniencia .
Los medios de pago para muchas compras electrónicas del consumidor consisten de una tarjeta de crédito. La tarjeta de crédito representa una cuenta de crédito pre-arreglada propiedad de un tenedor o titular de cuenta y expedida por una Institución Financiera, la propietaria de la cuenta. En un escenario, el tenedor o titular de la cuenta hace una compra electrónica con un comerciante, utilizando una tarjeta de crédito. El comerciante presenta la solicitud de compra a una compañía de tarjetas de crédito para autorización de compra. La compañía de tarjetas de crédito autoriza entonces o niega la transacción de tarjeta de crédito con el comerciante. Si la compra es aprobada, a la cuenta de crédito pre-arreglada se le hace cargo por la cantidad de la compra. En este escenario, la autorización realizada por la compañía de la tarjeta de crédito puede involucrar un sistema de seguridad de cuenta de tercero, que verifica la compra con el tenedor o titular de la cuenta.
Las tarjetas de crédito ofrecen muchas ventajas a los titulares de las cuentas. Por ejemplo, gente que tiene acceso a una tarjeta de crédito puede gastar menos tiempo en el banco, así como obtener el saldo o balance de las cuentas de cheques y de ahorros. Además, una tarjeta de crédito elimina la necesidad por transportar grandes cantidades de efectivo. Adicionalmente, la aprobación de compra es automatizada cuando se utiliza una tarjeta de crédito mientras que la aprobación de compra con cheque o giro, es retrasada. Por lo tanto, cuando se hace una compra por teléfono o giro postal, al utilizar una tarjeta de crédito se elimina el retardo asociado con el envío de pago a través del correo.
Como resultado de incrementado comercio electrónico, la seguridad de la tarjeta de crédito se ha vuelto una consideración principal para los propietarios de cuentas y los titulares de cuentas. Algunos titulares de cuentas son cautelosos de hacer compras con tarjeta de crédito por Internet, por temor a intercepción y uso no autorizado de su cuenta de tarjeta de crédito. Estos temores son justificados debido a que el lenguaje en que la mayoría de las páginas de la red de Internet están escritas, el Lenguaje de Marcado de Hipertexto (HTML = HyperText Markup Language) , utiliza métodos vulnerables para transferir información.
Para combatir aspectos de seguridad en Internet, algunas redes de comerciantes utilizan técnicas de cifrado para asegurar transacciones hechas por Internet. Esto ofrece poca comodidad al consumidor preocupado, debido a que estas técnicas de cifrado pueden ser descifradas por criminales sofisticados. Además, incluso si la transmisión del número de tarjeta de crédito es segura, el número de tarjeta todavía es almacenado en la computadora receptora y puede ser robado al tener acceso a esta computadora. Adicionalmente, los números de tarjetas de crédito pueden ser robados directamente de la tarjeta por dispositivos tales como exploradores o digitalizadores de bolsillo.
Algunas cuentas comerciales, por ejemplo cuentas de cheques, ofrecen tarjetas de débito que enfrentan los mismos, si no incrementados, riesgos de seguridad que las tarjetas de crédito. Las tarjetas de débito son similares a las tarjetas de crédito, sin embargo, para completar una transacción de débito, frecuentemente se da el Número de Identificación Personal (PIN = Personal Identification Number) del titular de la cuenta además del número de tarjeta, al tiempo de hacer la compra. Además, la tarjeta de débito retira fondos de la cuenta (típicamente una cuenta de cheques) a la cual corresponde. En muchos casos, el PIN dado con las transacciones de tarjeta de débito puede ser el mismo PIN empleado para tener acceso a la cuenta, por ejemplo, por un cajero automático o teléfono, al cual se enlaza la tarjeta de débito. Si una transacción de compra se realiza utilizando una tarjeta de débito es interceptada y utilizada en forma fraudulenta, el ladrón que intercepta tiene la capacidad tanto de hacer compras utilizando el número de la tarjeta de débito y, con el PIN, retirar fondos directamente de la cuenta de débito asociada.
La necesidad por mejorada seguridad de tarjeta de crédito ha impuesto presión en las compañías de tarjeta de crédito y los comerciantes para proporcionar métodos para reforzar transacciones electrónicas seguras. Por ejemplo, la patente de los E.U.A. No. 6,012,144 otorgada a Pickett describe un método para realizar transacciones seguras, tales como compras con tarjeta de crédito, utilizando dos o más redes no seguras (tales como Internet y el sistema de telefonía pública) de manera tal que se afirme la seguridad. Una persona que decide iniciar una transacción segura, envía un mensaje sobre una de las redes no seguras a una computadora. Esa computadora automáticamente utiliza la segunda red no segura para hacer contacto con la persona de regreso para verificar la transacción. El mecanismo de devolución de llamada emplea un método para autenticar la identidad o autoridad de la persona que inicia la transacción. Ningún dispositivo para acceso no autorizado a los datos de alguien más (snooping) en la red o derivación de cable, puede ver toda la transacción. Ninguna base de datos sencilla contiene todo el conjunto de información .
La patente de los E.U.A. No. 5,903,721 otorgada a Sixtus describe un método para ejecutar una transacción en linea segura entre una computadora de proveedor y una computadora de usuario, en donde la computadora de proveedor y la computadora de usuario están interconectadas a una red de computadora tal como Internet para comunicaciones de datos entre ellas. El método comprende las etapas de transmitir de la computadora de usuario un mensaje de solicitud de transacción a la computadora de proveedor por la red de computadoras, la solicitud de transacción financiera comprende datos de identificación de usuario únicos para la computadora del usuario; en respuesta a recibir la solicitud de transacción, la computadora de proveedor envía una solicitud de verificación de transacción a una computadora de servidor de confianza interconectada a la red de computadoras, la solicitud de verificación de transacción comprende los datos de identificación de usuario y datos indicativos de la transacción solicitada; en respuesta a recibir la solicitud de verificación de transacción, la computadora de servidor de confianza autentica la computadora de usuario al utilizar los datos de identificación de usuario y comunicar con la computadora de usuario para verificación con los datos de identificación de usuario; y al servidor de confianza que autoriza la transacción cuando ha pasado la etapa de autenticación.
Como otro ejemplo, la patente de los E.U.A. No. 5,991,738 otorgada a Ogram describe un sistema de pago automatizado, particularmente adecuado para compras sobre una red de computadoras distribuidas tal como Internet. En esta red de computadoras distribuidas, una computadora de comerciante o de proveedor contiene cierta información promocional, que se comunica a la computadora de un cliente. Con base en la información promocional, el operador de la computadora de cliente decide adquirir los servicios o bienes descritos por la información promocional. La computadora del cliente está enlazada con una computadora para procesamiento de pagos y el número de tarjeta de crédito del cliente y la cantidad de los bienes o servicios, se transmiten a la computadora de procesamiento de pagos. La computadora de procesamiento de pagos hace contacto automáticamente con un banco para verificación de la tarjeta de crédito y la cantidad; el banco transmite una autorización a la computadora de procesamiento de pago. La computadora de procesamiento de pago comunica una señal de transacción auto-generada, y en algunas modalidades, una clave, para la computadora de cliente. En una modalidad, cuando se emplea una clave, la computadora de cliente utiliza la clave con la computadora del comerciante, para obtener acceso a información protegida o para establecer instrucciones de embarque.
Un método de seguridad adicional se describe en la patente de los E.U.A. No. 7,264,154 otorgada a Harris (a continuación "Harris"), que describe un sistema y método para verificar una transacción comercial entre un titular de tarjeta, un comerciante, y una compañía de tarjetas de crédito. El titular de la tarjeta hace una compra con el comerciante utilizando un número de tarjeta de crédito completo. El comerciante envía una solicitud de aprobación de transacción (TAR = Transaction Approval Request) para aprobación con la compañía de tarjetas de crédito. La compañía de tarjetas de crédito ejecuta aprobación de crédito convencional de la solicitud de aprobación de transacción, así como verifica la solicitud de aprobación de transacción con el titular de la tarjeta. Se envía una aprobación al comerciante solo después de la solicitud de aprobación de transacción tanto es aprobado convencionalmente por la compañía de la tarjeta de crédito como verificada por el titular de la tarjeta. El titular de la tarjeta o la compañía de tarjetas de crédito, puede iniciar verificación de la solicitud de aprobación de la tarjeta. La solicitud de aprobación de transacción también puede ser verificada automáticamente si uno o muchos criterios de verificación previa son satisfechos por datos contenidos en la solicitud de aprobación de transacción. Los criterios de verificación previa pueden determinarse inicialraente y/o modificarse por el titular de la tarjeta. Como otra característica de seguridad, el titular de la tarjeta puede activar y desactivar selectivamente su cuenta/ta jeta de crédito como desee. La propia tarjeta de crédito incluye señales de medidas de seguridad.
El sistema y método de Harris, sin embargo requieren que la solicitud de aprobación de transacción sea verifica por el titular de la tarjeta, es decir la aprobación se envía al comerciante solo después de que se verifica la solicitud de aprobación de transacción por el titular de la tarjeta. Esto coloca al titular de la tarjeta en el proceso de aprobación de transacción por cada transacción y aumenta el tiempo de procesamiento de transacción.
Además, Harris describe verificación automática de una solicitud de aprobación de transacción si se cumplen criterios de verificación previa. Por ejemplo, en la columna 4, línea 62-columna 5, línea 31, Harris describe un sistema y método para verificación previa de ciertas transacciones. De acuerdo con Harris, el módulo de autorización compara la solicitud de aprobación de transacción con los criterios de verificación previa y verifica automáticamente la solicitud de aprobación de transacción si se cumplen los criterios de verificación previa. Harris también describe, en la columna 9, linea 65-columna 10, linea 4, que Lista de Espera Pendiente de Verificación (VPQ = Verification Pending Queue) 228 proporciona almacenamiento para TARs pendientes que esperan verificación por el titular de la tarjeta 102 y que las TARs permanecen en VPQ 228 hasta que se verifican, niegan o hasta que termina un periodo de tiempo predeterminado. Además, la Figura 14 de Harris ilustra que si en la quinta etapa 809, los requerimientos de verificación previa no se satisfacen, entonces en una sexta etapa 810, el módulo de autorización 226A transfiere el registro TAR asociado a VPQ 228 (que proporciona almacenamiento hasta disposición del titular de la tarjeta, como se discutió anteriormente) . De acuerdo con esto, el sistema y método de las TARs de verificación previa de Harris proporcionan entonces dos opciones: 1). TAR ya se aprueba cuando se satisfacen los criterios de verificación previa; o 2) la TAR se dirige a VPQ para mayor verificación por el titular de la tarjeta, cuando no se satisfacen los criterios de verificación previa. Como tal, la disposición final de una TAR no-verificada previamente se retrasa, mientras que TAR se almacena en VPQ, hasta que el titular de la tarjeta tiene la oportunidad de verificar la TAR. Además, al almacenar TARs no-verificadas previamente o pre-verificadas , se aumenta significativamente el potencial para violación de la seguridad de las TARs almacenadas.
COMPENDIO DE LA INVENCIÓN En un aspecto, la presente invención se refiere a un método para facilitar una transacción comercial entre un titular de cuenta, quien tiene una cuenta, y un comerciante. La cuenta se asocia con la información de cuenta, que puede incluir al menos un criterio para autorización previa de una transacción. El método comprende las etapas de recibir una solicitud de aprobación de transacción (TAR) , que incluye información referente a la transacción comercial, y comparar la información recibida con la información de cuenta, para determinar si se satisfacen los criterios para autorización previa de la transacción. El método además comprende la etapa de negar la TAR cuando se hace una determinación de que los criterios de autorización previa no se satisfacen. Al negar la TAR de esta manera, el tiempo de disposición de las TARs no-previamente-autorizadas se reduce al mínimo significativamente y se evitan comunicaciones adicionales con el propietario de la cuenta y transmisión adicional de información de cuenta sensible.
En otro aspecto, la presente invención proporciona un método para utilizar una cuenta para realizar una transacción entre un comerciante y un titular de cuenta. La cuenta se asocia con la información de cuenta, que puede incluir cuando menos un criterio para autorización previa de una transacción. El método comprende las etapas de enviar una TAR, que incluye información referente a la transacción y obtener un resultado de una comparación de la información enviada a la información de cuenta. El resultado de la comparación incluye una determinación de si se satisfacen los criterios de autorización previa. El método además comprende la etapa de rehusar o negar la transacción asociada con los criterios de autorización previa no-satisfechos cuando se realiza una determinación que los criterios de autorización previa no se satisfacen.
La presente invención, en otro aspecto, se refiere a un sistema para facilitar una transacción comercial entre un comerciante y un titular de cuenta. La cuenta se asocia con información de cuenta, que puede incluir cuando menos un criterio para autorización previa de una transacción. El sistema comprende un servidor, configurado para recibir la información de cuenta y una TAR, que puede incluir información referente a la transacción comercial. El servidor también puede ser configurado adicionalmente para comparar la información recibida con la información de cuenta, para determinar si los criterios de autorización previa son satisfechos. El servidor además se configura para negar la TAR cuando se hace una determinación de que los criterios de autorización previa no se satisfacen.
Además, la presente invención proporciona un sistema que comprende adicionalmente una terminal de comerciante y una terminal de cuenta. La terminal de comerciante se conecta a una red y se configura para transmitir la TAR. La terminal de comerciante además se configura para recibir una aprobación o negación de la TAR. La terminal de cuenta se conecta a la red y se configura para transmitir la información de cuenta. En este aspecto de la invención, el servidor puede estar en comunicación con la terminal de cuenta y la terminal de comerciante, mediante la red. El servidor puede ser configurado para recibir la información referente a la primera transacción comercial y además configurado para comparar la información recibida con la información de cuenta, para determinar si los criterios de autorización previa se satisfacen. En este aspecto, el servidor además se configura para negar la TAR cuando se hace una determinación de que no se satisfacen los criterios de autorización previa.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La presente invención se comprenderá mejor en vista de las figuras no-limitantes, en donde caracteres semejantes se refieren a iguales o similares partes a través de las vistas, y en donde: La Figura 1 es un diagrama de flujo que muestra un método para facilitar una transacción entre un comerciante y un titular de cuenta, de acuerdo con una modalidad de la presente invención; La Figura 2 es un diagrama de flujo que muestra un método para facilitar una transacción entre un comerciante y un titular de cuenta, que utiliza una etapa de supervisión o monitoreo de acuerdo con otra modalidad de la presente invención; La Figura 3 es un diagrama de flujo que muestra un método para facilitar una transacción entre un comerciante y un titular de cuenta, en donde se realizan múltiples solicitudes de aprobación de transacción, de acuerdo con todavía otra modalidad de la presente invención; La Figura 4 es un diagrama de bloques que muestra un sistema de acuerdo con una modalidad de la presente invención; y La Figura 5 es un diagrama de bloques que muestra un servidor de acuerdo con una modalidad de la presente invención .
DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS La presente invención se refiere a proporcionar transacciones electrónicas más seguras, en particular a prevención de transacciones que no son autorizadas previamente, por ejemplo, por el titular de la cuenta. En el curso de comercio de todos los días, compradores y vendedores realizan transacciones entre ellos. Al hacerlo, se generan solicitudes de aprobación de transacción (TARs), por ejemplo por comerciantes o por otras instituciones. Estas TARs son solicitudes, usualmente de los comerciantes para verificación de que la transacción que se intenta es autorizada por el comprador prospecto. Típicamente, estas TARs están sujetas a un proceso de verificación de transacción, que puede realizarse por una institución financiera o por una tercera parte que es un sistema de seguridad de cuenta. En general, la TAR se verifica por el propietario de la cuenta y resulta de una aprobación o negación de la TAR que se proporcionan al comerciante. En este escenario, toda TAR se retransmite o comunica al propietario de la cuenta, en cuyo punto, al propietario de la cuenta se le da la oportunidad por aprobar o negar la TAR. La decisión por aprobar o negar la TAR se realiza después de que se hace la TAR. Como tal, incluso TARs que no hubieran satisfecho los criterios de autorización previa, por ejemplo, criterios de autorización previa predeterminados, se comunican al propietario de cuenta para disponer. Procesos tales como estos involucran etapas de comunicación y verificación por todas y cada una de las TAR, así como alimentación adicional del propietario de la cuenta, ambas de las cuales proporcionan oportunidades para que la seguridad de la cuenta sea violada. En contraste, la presente invención protege al propietario de la cuenta y el titular de la cuenta, al primero proporcionar criterios de autorización previa definidos y después negar todas las TARs que no cumplen con los criterios de autorización previa definidos. Al hacerlo, la necesidad por mayores comunicaciones al propietario de la cuenta referente a las TARs non-autorizadas previas y la transmisión de información de cuenta sensible se reducen al mínimo, al igual que oportunidades para violaciones de seguridad, por ejemplo, fraude de tarjeta de crédito. Además, debido a que la TAR no-previamente-autorizada es negada, y no ocurre compra, se eliminan en forma substancial la necesidad por que el propietario de la cuenta y/o el titular de la cuenta inicien subsecuentemente procedimientos de disputa.
La Figura 1 representa un proceso de transacción financiera de acuerdo con modalidades preferidas de la presente invención. Una modalidad se refiere a un método para facilitar una transacción, por ejemplo, una transacción comercial o una primera transacción comercial, entre un titular de cuenta y un comerciante. En modalidades preferidas, el titular de la cuenta es el titular de una cuenta, y la cuenta se utiliza para proporcionar fondos para la transacción. Transacciones ejemplares incluyen pero no están limitadas a compras a crédito, compras a débito, devoluciones, pagos de facturas y compras en linea. Esta lista de transacciones no es exhaustiva. En una modalidad preferida, la cuenta es de una tarjeta de crédito o una tarjeta de débito y la cuenta se asocia con una tarjeta de crédito o una tarjeta de débito, respectivamente. Típicamente, la tarjeta de crédito o la tarjeta de débito se proporcionan por la institución financiera, por ejemplo una compañía de tarjetas de crédito o una compañía de tarjetas de débito, y se utilizan para facilitar transacciones que involucran la cuenta. Otros tipos de cuentas que pueden utilizarse en diversas modalidades de la invención, incluyen tarjetas de regalo, o cualesquiera tarjetas o plásticos omitidos por una Institución Financiera. En general, el comerciante ofrece bienes o servicios que pueden ser adquiridos, por ejemplo adquiridos por Internet, por el titular de la cuenta utilizando la tarjeta de crédito o la tarjeta de débito.
En muchas de las modalidades aquí descritas, una tarjeta de crédito o tarjeta de débito se utiliza como un medio para facilitar el comercio electrónico. Aquellos con destreza en la técnica se darán cuenta que la presente invención sin embargo no se limita a compras hechas utilizando tarjetas de crédito o tarjetas de débito. La presente invención puede emplearse en conjunto con cualquier tipo de cuenta para facilitar transacciones electrónicas seguras y sin riesgo, que incluyen transmisión de un número de cuenta, tal como transacciones por Internet u otras transacciones electrónicas.
En una modalidad, la cuenta se asocia con información de cuenta. La información de cuenta puede ser cualquier información referente a la cuenta. Información de cuenta puede incluir, por ejemplo el nombre asociado con la cuenta, un número que identifica la cuenta, el saldo de la cuenta, un número de direccionamiento del banco, un código de identificación u otros criterios que ayudan a identificar en forma única a la cuenta. En una modalidad preferida, la información de cuenta se proporciona, por ejemplo, proporciona a la institución de seguridad por cuenta de tercera parte o se proporciona a la compañía de tarjetas de crédito por el titular de la cuenta. En modalidades alternas, la información de cuenta puede proporcionarse por fuentes diferentes al titular de la cuenta, por ejemplo, la institución que proporciona la cuenta o la compañía de tarjetas de crédito. En otra modalidad, la información de cuenta es una compilación de información que se proporciona por el titular de la cuenta y/u otras fuentes.
En una modalidad preferida, la información de cuenta es modificable por el titular de la cuenta. Es decir, el titular de la cuenta puede ser capaz de cambiar y/o actualizar la información de cuenta. En una modalidad preferida, el titular de la cuenta tiene la capacidad de actualizar la información de cuenta en cualquier tiempo. De preferencia, el titular de la cuenta tiene la capacidad de cambiar y/o actualizar la información de la cuenta para evitar que ocurran transacciones no-autorizadas previamente. En otra modalidad, el titular de la cuenta puede actualizar la información de cuenta en tiempos especificados, es decir, antes de realizar una solicitud de transacción .
En una modalidad preferida, la información de cuenta incluye cuando menos un criterio para autorización previa de una transacción. Estos criterios de autorización previa pueden incluir, pero no están limitados a una lista de comerciantes autorizados, un intervalo para la cantidad de transacción autorizada, una cantidad de transacción máxima autorizada, un indicador de seguro autorizado, y/o una información de tiempo y/o fecha autorizada, o cualquier combinación o permutación de los anteriores. Por ejemplo, una venta de una cantidad en dólares determinada de un comerciante determinado dentro de un marco de tiempo determinado, puede ser pre-autorizada . En una modalidad preferida, los criterios de autorización previa se proporcionan, determinan y/o modifican por el titular de la cuenta. Como un ejemplo, el titular de la cuenta puede proporcionar criterios de previa autorización a la institución de seguridad de cuenta de tercero, mediante un método de Respuesta de Voz Interactiva (IVR = Interactive Voice Response) , mediante un representante de servicio a clientes, o por medios electrónicos tales como Internet, Asistente Digital Personal (PDA = Personal Digital Assistant) , teléfono celular, etc. En una modalidad en la que se utiliza la IVR, la IVR puede utilizar la Identificación de Número Automático (ANI = Automatic Number Identification) del teléfono del titular de la cuenta como una de las formas de verificación de cliente. En una modalidad, el método IVR fuerza al titular de la cuenta a proporcionar una respuesta de seguridad, por ejemplo, los últimos cuatro dígitos del número de seguridad social del titular de la cuenta, para probar identidad. En otra modalidad, el suministro o modificación de la autorización previa no permite acceso externo a información sensible, por ejemplo, números de cuenta o saldos de cuenta; solo se permite acceso a criterios de previa autorización. En otras modalidades, la información de cuenta se proporciona por aplicaciones móviles, aplicaciones de banca desde el hogar, otras aplicaciones basadas en la Red y/o aplicaciones de servicios de Red. Las características asociadas con la información de cuenta, por ejemplo aquellas referentes al suministro y modificación de las mismas, visto con anterioridad, son también aplicables a los criterios de autorización previa.
En modalidades preferidas, los criterios de autorización previa se proporcionan por el titular de la cuenta y no están establecidos, por ejemplo no preestablecidos por la institución de seguridad, tercero, o por la compañía de la tarjeta de crédito. Esta modalidad se distingue de los métodos y/o sistemas en donde los criterios de autorización previa se pre-establecen por una compañía de tarjetas de crédito ya que el titular de la cuenta es quien establece los criterios de autorización previa, no la Compañía de la tarjeta de crédito. Como tal, el titular de la cuenta se proporciona con incrementado control sobre la cuenta. Además, los criterios de autorización previa no son pre-establecidos sin el conocimiento o alimentación por parte del titular de la cuenta.
El término "autorización previa" o "pre-autorización" como se emplea en este documento, se refiere a la satisfacción de criterios de aceptación de una transacción particular antes que se comunique la transacción propuesta al propietario de la cuenta, o a un tercero adicional, para aprobación o negación. En una modalidad preferida la autorización previa se basa en los criterios de autorización previa discutidos anteriormente. Para propósitos de claridad, "verificación" significa que la solicitud de compra se comunica al propietario de la cuenta, o equivalente, para aprobación o negación. "Verificación" puede no significar necesariamente una aprobación de la solicitud de compra.
Como se muestra en la Figura 1, en una modalidad de la presente invención, el método comprende la etapa 120 para generar una solicitud de compra. La solicitud de compra puede relacionarse a la compra de bienes o servicios, el pago de deudas, o el movimiento de capital. En una modalidad, la compra se inicia por el titular de la cuenta, por ejemplo el titular de la tarjeta, al hacer o intentar hacer una compra, por ejemplo una compra electrónica de un comerciante. Esta compra puede realizarse por ejemplo por Internet, a través del teléfono, a través del correo o en persona.
En una modalidad preferida, el método comprende la etapa 130 para recibir una TAR. De preferencia, el comerciante presenta una TAR a un tercero, por ejemplo a una institución de seguridad de cuenta, tercera parte, un banco u otra institución financiera y/o una compañía de procesamiento de tarjetas, en respuesta a la solicitud de compra del titular de la cuenta. Típicamente, la tercera parte recibe la TAR del comerciante. En una modalidad, la institución de seguridad de tercera parte, banco u otra institución financiera y/o la compañía de procesamiento de tarjeta realiza la autorización. En una modalidad, la compañía de procesamiento de tarjetas transmite la TAR a la institución de seguridad de tercera parte para autorización. Al recibir la TAR, la TAR se somete a un proceso de autorización antes de que se emita una aprobación o negación de la TAR.
El proceso de autorización, en general incluye verificación de la compra, que se discutirá a continuación. En una modalidad, la autorización incluye una aprobación de crédito, que puede realizarse por la compañía de procesamiento de tarjeta como se conoce en la técnica. Típicamente, en el proceso de autorización, las solicitudes de compra, por ejemplo solicitudes de compra que se pueden aprobar con anterioridad o previamente, se comunican a y/o verifican por el propietario de la cuenta. En una modalidad preferida, la institución de seguridad de cuenta, tercera parte, verifican la solicitud de transacción autorizable en forma previa con el propietario de la cuenta, y transmite resultados de verificación, indicando si la solicitud de transacción se ha aprobado, negado, renunciado, etc., de regreso a la compañía de procesamiento de tarjetas. La verificación puede lograrse por Internet, por lineas telefónicas y/o por cualquier otro medio de comunicación electrónica .
En modalidades preferidas, la TAR incluye información referente a la transacción comercial. Como un ejemplo, la TAR puede incluir el nombre del comerciante, un identificador referente al comerciante, la cantidad involucrada en la transacción, una descripción de producto, la fecha y hora de la transacción o cualquier otra información que ayude a identificar la transacción al propietario de la cuenta para verificación. En una modalidad preferida, esta información se utiliza, por ejemplo por la institución de seguridad, tercera parte, para determinar la disposición de la TAR, por ejemplo aprobación pre-autorizada o mayor verificación.
De acuerdo con esto, en una modalidad preferida, el método comprende la etapa 140 de comparar la información recibida referente a la transacción comercial, con la información de la cuenta, para determinar si el criterio como mínimo para autorización previa de la transacción, se satisface. En otras palabras, la información de transacción se analiza a la luz de la información de cuenta, para determinar la disposición de la TAR, por ejemplo cómo se manejará la TAR. En una modalidad preferida, la etapa de comparación se realiza por la institución de seguridad, tercera parte. En otra modalidad, la etapa de comparación se realiza por la compañía de procesamiento de tarjetas.
En una modalidad, la información de transacción relevante se compara con los criterios de autorización previa, que se han proporcionado previamente, por ejemplo por el titular de la cuenta. En una modalidad preferida, la información de transacción y los criterios de autorización previa se comparan y/o analizan antes de verificación con el propietario de la cuenta. En otra modalidad, la información de transacción y los criterios de pre-autorización se comparan y/o analizan de manera concurrente con la verificación del propietario de la cuenta.
En una modalidad, la información de la cuenta comprende una lista de comerciantes preferidos y la información de transacción comprende un identificador de comerciante, por ejemplo un nombre de comerciante o número de identificación de comerciante (ID). En esta modalidad, el criterio para autorización previa es que el comerciante involucrado en la transacción es uno de los comerciantes citados como un comerciante preferido. De acuerdo con esto, el identificador de comerciante se comparará con la lista de comerciantes preferidos. Si el comerciante está en la lista, la TAR es pre-autorizada . Si el comerciante no está en la lista, se niega la TAR. En una modalidad preferida, una TAR negada se rechaza y no está sujeta a mayor verificación .
En una modalidad, la información de cuenta comprende un intervalo de cantidad de transacción y la información de transacción comprende una cantidad de transacción. En esta modalidad, el criterio para autorización previa es que la cantidad de transacción está dentro del intervalo de la cantidad de transacción. De acuerdo con esto, la cantidad de transacción se comparará con el intervalo de cantidad de transacción. Si la cantidad de transacción está dentro del intervalo de cantidad de transacción, la TAR es pre-autorizada . Si la cantidad de transacción está fuera del intervalo de cantidad de transacción, la TAR se niega. En una modalidad, la comparación puede realizarse de manera tal que una cantidad de transacción que cae en uno de los puntos extremos del intervalo de cantidad de transacción es pre-autorizada o negada, dependiendo de la información de cuenta adicional. En una modalidad preferida, una TAR negada se rechaza y no está sujeta a mayor verificación.
En una modalidad, la información de cuenta comprende un máximo de cantidad de transacción y la información de transacción comprende una cantidad de transacción. En esta modalidad, el criterio para autorización previa es que la cantidad de transacción es igual a o inferior al máximo de la cantidad de transacción.
De acuerdo con esto, la cantidad de transacción se comparará con el máximo de cantidad de transacción. Si la cantidad de transacción es igual a o inferior al máximo de cantidad de transacción, la TAR es pre-autorizada . Si la cantidad de transacción está sobre el máximo de cantidad de transacción, se niega la TAR. En una modalidad, el máximo de cantidad de transacción es una cantidad que es predeterminada, por ejemplo predeterminada por el titular de la cuenta. En una modalidad preferida, una TAR negada se rechaza y no está sujeta a mayor verificación.
En una modalidad, la información de cuenta comprende información de hora y fecha, por ejemplo intervalos de horas y fechas y la información de transacción comprende información de hora y fecha de transacción. En esta modalidad, el criterio para autorización previa es que la hora y fecha de transacción correspondan a los intervalos de horas y fechas que se proporcionan en la información de cuenta. De acuerdo con esto, la información de hora y fecha de transacción será comparada con los intervalos de hora y fecha de cuenta. Si la hora y fecha de transacción caen dentro de los intervalos de hora y fecha de la información de cuenta, la TAR es pre-autorizada. Si la hora y fecha de transacción caen fuera de los intervalos de hora y fecha de la información de cuenta, la TAR es negada. En una modalidad preferida, una TAR negada se rechaza y no está sujeta a mayor verificación.
Por supuesto, otros datos de transacción pueden compararse con otros datos de cuenta. Los ejemplos citados anteriormente no constituyen una lista completa.
En una modalidad, hay más de un criterio en el que se base cuando se realiza la comparación. En una modalidad preferida, cada uno de estos criterios debe ser satisfecho para que ocurra la autorización previa de la TAR. En otra modalidad, sólo una cantidad predeterminada de los criterios debe ser satisfecha, a fin de que una TAR sea pre-autorizada . En otra modalidad, si cualquiera de los criterios para autorización previa no se satisfacen, no ocurre autorización previa de la TAR. En otra modalidad preferida, sólo hay un criterio que debe satisfacerse a fin de que ocurra la autorización previa de la TAR. En otra modalidad, algunos de los criterios se satisfacen y algunos no se satisfacen. En esta modalidad, si más de una cantidad de criterios predeterminados se satisfacen, la TAR es pre-autorizada, de otra forma la TAR es negada.
En una modalidad preferida, el método comprende la etapa 160 de negar la solicitud de aprobación de transacción cuando se hace una determinación de que el criterio o criterios para pre-autorizar la transacción no se satisfacen. En una modalidad preferida, TARs que contienen información de transacción que no satisface los criterios de autorización previa, son negadas sin estar sujetas a mayor verificación. Por ejemplo sin ser comunicadas a o de otra forma presentadas al propietario de la cuenta. En otras palabras, de acuerdo con una modalidad preferida, al propietario de la cuenta no se requiere que verifique ninguna TAR que no ha cumplido con los criterios de autorización previa; la TAR es negada antes de proceder al propietario de la cuenta. Esta modalidad es claramente distinguida de métodos que requieren verificación del propietario de la cuenta, subsecuente al recibo de la TAR por toda y cada TAR que se reciba; en estos métodos, la falla en satisfacer los criterios de autorización previa, no resulta en una negación automática de la TAR. En las modalidades de los métodos y sistemas de la presente invención, por otra parte, TARs no pre-autorizadas son negadas, sin posibilidad de mayor verificación. Al proporcionar negación, por ejemplo negación automática de todas las TARs que no satisfacen los criterios de autorización previa, el tiempo de disposición de las TARs no pre-autorizadas se reduce al mínimo en forma significativa. También, comunicaciones adicionales con el propietario de la cuenta y transmisión adicional de la información de cuenta sensible, se evitan. Además, debido a que la TAR es negada y no ocurre compra, no hay necesidad porque el propietario de la cuenta y/o el titular de la cuenta subsecuentemente inicien procedimientos de disputa. Por lo tanto, se logra una transacción de mayor protección, más segura, se evitan transacciones fraudulentas y aumenta la confianza del consumidor.
Como se muestra en la Figura 1, cuando los criterios de autorización previa se satisfacen por la información de transacción, el método puede incluir la etapa 190 de otorgar la TAR, por ejemplo pre-autorizar la transacción. En una modalidad, ante autorización previa de la TAR, procede la transacción, por ejemplo el propietario de la cuenta recibe la TAR pre-autorizada para verificación y ante aprobación por el propietario de la cuenta, se realiza la compra.
En una modalidad preferida, el método además comprende la etapa de evitar que se realicen mayores o adicionales determinaciones respecto a una TAR no pre-autorizada. En otras palabras, en esta modalidad, las TARs no pre-autorizadas mayor verificación se evita en forma activa, por ejemplo mayor verificación por el propietario de la cuenta no se permite, ya sea en forma permanente, o por un periodo de tiempo predeterminado, por ejemplo 20 minutos, 30 minutos, 1 hora, 24 horas, 1 semana, 1 mes, etc .
En una modalidad, el método además comprende la etapa 170 de reportar la negación de la TAR. Al reportar la negación de la TAR, las partes involucradas, por ejemplo el titular de la cuenta y/o la compañía de la tarjeta de crédito, se hacen conscientes de la TAR no pre-autorizada . De acuerdo con esto, pueden tomarse los pasos apropiados entonces para asegurar la cuenta. En una modalidad, el reporte o notificación de intento de una transacción no autorizada se comunica al titular de la cuenta inmediatamente o en forma sustancialmente inmediata. Como tal, el titular de la cuenta se alerta en forma inmediata o sustancialmente inmediata que puede haber ocurrido posible actividad fraudulenta. Como un ejemplo, la TAR negada puede ser reportada al teléfono, computadora, PDA, o teléfono celular del titular de la cuenta. En una modalidad, la alerta inmediata permite que el titular de la cuenta reporte rápidamente el evento a una institución de supervisión, por ejemplo manejo de fraude. Otras instituciones de supervisión ejemplares incluyen IDT.
En una modalidad preferida, la etapa de reporte 170 comprende notificar al propietario de la cuenta y/o a todas las partes de la transacción financiera, cuando se niega la TAR.
En modalidades preferidas, métodos y sistemas de la invención aplican a transacción y TARs relacionadas de cualquier cantidad incluyendo restaurantes de servicio rápido (QSR = Quick Service Restaurants) y otras transacciones que no requieren firma. En otras modalidades, la cantidad de la transacción o un intervalo de cantidad de transacción puede ser especificado y el proceso de autorización puede sólo aplicar a transacciones en el intervalo especificado, por ejemplo transacciones que están sobre limites de piso internacionales. Hablando en general, transacciones QSR, son aquellas transacciones bajo la cantidad de 20 dólares de los E.U.A. Típicamente, estas transacciones cuando se inician con una tarjeta de crédito o débito, no requieren firma. La cantidad de 20 dólares es solamente ejemplar por supuesto, y cualquier cantidad puede ser especificada para determinar el intervalo de transacciones QSR.
En una modalidad, la información de cuenta comprende un indicador de estado bloqueado. El indicador de estado bloqueado, indica si la cuenta está disponible para transacciones particulares, por ejemplo si la cuenta está bloqueada o liberada para transacciones particulares. En una modalidad, la información de transacción comprende información referente al hecho de que se realiza una solicitud de transacción. En esta modalidad, el criterio para autorización previa es si el indicador de estado bloqueado está en el modo bloqueado. En esta modalidad, la solicitud de transacción se compara con el indicador de estado bloqueado. Si el indicador de estado bloqueado está en el modo liberado, la TAR es pre-autorizada . Si el indicador de estado bloqueado está en el modo bloqueado, la TAR es negada. En una modalidad preferida, una TAR negada es rechazada y no está sujeta a mayor verificación. En otra modalidad preferida, el modo del indicador de estado bloqueado es especifico a un ítem particular de información de transacción, por ejemplo especifico para un comerciante particular. En esta modalidad preferida, el indicador de estado bloqueado puede estar en el modo bloqueado para un comerciante, sin embargo todavía estar en modo liberado para otros comerciantes. Como tal, la cuenta no está bloqueada para todas las transacciones subsecuentes. Por el contrario, la cuenta permanece disponible para uso por otros comerciantes. Esta modalidad es diferente de otros métodos que desactivan completamente una tarjeta de uso, una vez que se ha satisfecho un criterio particular, entonces se reactiva la misma tarjeta al modificar los datos de activación. Al utilizar los métodos (y sistemas) de la presente invención, una cuenta puede ser bloqueada en relación a un comerciante, mientras que aún está disponible a otros, lo que resulta en un grado adicional de seguridad y conveniencia.
En una modalidad alterna, el modo del indicador de estado bloqueado no se relaciona a un comerciante particular. En esta modalidad, si el indicador de estado bloqueado está en el modo bloqueado, la cuenta puede estar bloqueada respecto a esto y todas las TARs subsecuentes; de conformidad, todas las TARs recibidas cuando la cuenta está bloqueada, serán negadas. En una modalidad preferida, el modo del indicador de estado bloqueado puede ser modificado, por ejemplo cambiado del modo bloqueado al modo liberado o viceversa. En otro modalidad, el modo del indicador de estado bloqueado puede ser modificado múltiples veces, por ejemplo cambiado del modo bloqueado al modo liberado y de regreso al modo bloqueado. Como un ejemplo, el titular de la cuenta puede ajustar el indicador de estado bloqueado a "modo bloqueado" por un periodo de tiempo particular. Como tal, todas las TARs que se reciben durante el periodo de tiempo serán negadas. Como un ejemplo adicional, el titular de la cuenta puede entonces modificar, por ejemplo actualizar, el indicador de estado bloqueado a "modo liberado", en cuyo punto todas las TARs recibidas después de la modificación no serán negadas. Por el contrario éstas TARs pueden ser adicionalmente verificadas .
Como se muestra en la Figura 2, en una modalidad preferida, cuando uno de los criterios para autorización previa es si el indicador de estado bloqueado está en el modo bloqueado, el método incluye la etapa 150 de determinar si la cuenta está bloqueada respecto a la información de transacción particular. En una modalidad preferida, se hace una determinación de si la TAR fue negada debido a que no satisface los criterios de modo bloqueado. Además, si la TAR fue negada por no satisfacer los criterios de modo bloqueado, una modalidad preferida del método además comprende la etapa 155 de supervisar la cuenta que está bloqueada con relación a una información de transacción particular.
Como se muestra en la Figura 3, en modalidades preferidas de la invención, múltiples TARs pueden ser procesadas. De acuerdo con esto, en una modalidad preferida, el método comprende la etapa 180 de determinar después de negar la TAR previa, si hay al menos una TAR adicional. En otra modalidad preferida, el método comprende la etapa 195 de determinar después de otorgar la TAR previa si hay al menos una TAR adicional. Las transacciones adicionales pueden ser por ejemplo compras adicionales del mismo comerciante o compras de un comerciante totalmente diferente. Al proporcionar la capacidad de procesar múltiples TARs, las modalidades de la presente invención son capaces de proporcionar seguridad para múltiples transacciones sobre periodos prolongados de tiempo. En una modalidad, al menos una TAR adicional incluye información referente a una segunda transacción comercial. La información de segunda transacción tiene las mismas características que la primera u original información de transacción que se discutió anteriormente.
En modalidades preferidas, en donde múltiples TARs se procesan, la información de cuenta es actualizable, por ejemplo capaz de ser actualizada por el titular de la cuenta. La información de cuenta es capaz de ser modificada, por ejemplo actualizada antes que la primera (original) TAR, después de la primera TAR o en ambos casos. De preferencia, la información de cuenta es capaz de ser actualizada en cualquier tiempo durante la ejecución de las modalidades del método. En otra modalidad preferida, la información de cuenta se actualiza después de la solicitud de transacción original y antes de la solicitud de aprobación de transacción adicional como mínimo. De preferencia, la información de cuenta se actualiza para incluir al menos un criterio para pre-autorizar una segunda transacción. En una modalidad, el o los criterios de autorización previa para la segunda transacción son diferentes de aquellos de la primera transacción. En una modalidad alterna, el o los criterios de autorización previa para la segunda transacción son los mismos que aquellos de la primera transacción, por ejemplo no son modificados .
En una modalidad preferida, el método además comprende la etapa de comparar la información recibida referente a la segunda transacción comercial con la información de cuenta actualizada. En esta etapa, se hace una determinación de si se satisfacen los criterios para pre-autorizar la segunda transacción. Esta etapa de comparación es similar a la etapa de comparación discutida anteriormente, excepto por el hecho de que la segunda información de transacción y la información de cuenta actualizada pueden ser diferentes.
En una modalidad preferida, la etapa de comparación es seguida por la etapa de negar la solicitud de aprobación de transacción cuando se hace una determinación de que el o los criterios para pre-autorizar la transacción no se satisfacen. De nuevo, esta etapa es similar a la etapa de negación discutida anteriormente, y aplican las mismas características.
En modalidades preferidas, los métodos y sistemas de la presente invención se diseñan y/o configuran para no interferir con transacciones pre-programadas y pre-programadas recurrentes. En algunas modalidades, los métodos y sistemas de la invención no inhiben que ocurran a como se programaron las transacciones pre-programadas y transacciones pre-programadas recurrentes. En dicho caso, sólo se hace blanco en las transacciones no pre-autorizadas, mientras que la funcionalidad en proceso de la cuenta, por ejemplo las transacciones pre-programadas y las transacciones pre-programadas recurrentes, se permite que continúen como es normal.
Otra modalidad preferida se refiere a un método para utilizar una cuenta para realizar una transacción comercial entre un comerciante y un titular de la cuenta. En una modalidad de este método, el comerciante conduce la transacción, por ejemplo el comerciante realiza el método. En una modalidad preferida, el comerciante realiza el método para verificar que se efectúa una compra potencial por el titular de la cuenta. Por supuesto, en esta modalidad, el titular de la cuenta puede utilizar la cuenta para pagar por otra compra. En una modalidad, la cuenta está asociada con información de cuenta. En modalidades preferidas, las características de la cuenta, la información de cuenta y los criterios de autorización previa pueden ser similares a aquellas características previamente discutidas con relación a otras modalidades.
En una modalidad preferida, el método comprende la etapa de enviar una TAR. En algunas modalidades, las características de la o las TAR(s) pueden ser similares a aquellas previamente discutidas en relación a otras modalidades de la presente invención. De preferencia, el comerciante envía la TAR, por ejemplo envía la TAR a una tercera parte, por ejemplo una institución de seguridad de tercera parte o una compañía de procesamiento de tarjetas, en respuesta a una solicitud de compra del titular de la cuenta. De acuerdo con esto, la tercera parte recibe la TAR del comerciante.
En una modalidad preferida, el método comprende la etapa de obtener una comparación de la información enviada respecto a la transacción comercial con la información de cuenta. En una modalidad preferida, el comerciante realiza la etapa de obtención. En una modalidad, la información de transacción se analiza a la luz de la información de cuenta para determinar la disposición de la TAR, por ejemplo cómo se manejará la TAR. De preferencia, la comparación es un proceso de autorización, que compara la información incluida en la TAR en el o los criterios de autorización previa. En una modalidad, la institución de seguridad de tercera parte o la compañía de procesamiento de tarjeta realiza la autorización, después proporciona resultados de la autorización al comerciante. En otra modalidad, la comparación por ejemplo la autorización, se realiza por el comerciante .
En una modalidad preferida, la comparación incluye una determinación de si se satisfacen los criterios para autorización previa de la transacción. En una modalidad, la comparación se realiza al comparar la información de transacción relevante con los criterios de autorización previa, que se han proporcionado previamente. En una modalidad preferida, la información de transacción y los criterios de autorización previa se comparan y/o analizan antes de verificar con el propietario de la cuenta. En otra modalidad, la información de transacción y los criterios de autorización previa se comparan y/o analizan concurrentemente con la verificación del propietario de la cuenta. En modalidades preferidas, las características de la comparación y/o la determinación pueden ser similares a las características discutidas anteriormente con relación a la etapa de comparación utilizada en otras modalidades.
En una modalidad preferida, el método comprende la etapa de rehusar la transacción, por ejemplo la transacción asociada con criterios de autorización previa no satisfechos, cuando se realiza una determinación de que el o los criterios para autorización previa de la transacción no se satisfacen. En una modalidad, el comerciante realiza la etapa de rehusar, por ejemplo rehúsa la transacción o niega la TAR, cuando no se satisfacen los criterios de autorización previa. En modalidades preferidas, las características de la etapa de rehusar pueden ser similares a las características discutidas anteriormente con relación a la etapa de negación utilizada en otras modalidades. En una modalidad preferida, TARs que contienen información de transacción que no satisfacen los criterios de autorización previa, se niegan y las transacciones respectivas se rehúsan sin ser sometidas a mayor verificación, por ejemplo sin ser comunicadas o de otra forma presentadas al propietario de la cuenta. En otras palabras, de acuerdo con una modalidad preferida, el rehusar la transacción y/o negar la TAR no están sujetos a mayor verificación por el propietario de la cuenta. Esta modalidad se distingue claramente de métodos que requieren verificación del propietario o titular de la cuenta, subsecuente a la presentación de la TAR, por todas y cada una de las TAR que se envían o se presentan. En las modalidades del método y sistema de la presente invención, TARs no pre-autorizadas son negadas y las transacciones respectivas son rehusadas, sin la posibilidad de mayor verificación. Al hacerlo, se evitan comunicaciones adicionales con el propietario de la cuenta y transmisión adicional de información de cuenta sensible.
Como se muestra en la Figura 4, el sistema 400 es ejemplar de un sistema para facilitar una primera transacción comercial entre un comerciante y un titular de cuenta, de acuerdo con las modalidades preferidas de la invención. Este sistema es capaz de implementar, al menos, las modalidades de los métodos aquí discutidas. En modalidades preferidas, el sistema 400 comprende la terminal de comerciante 420, la terminal de cuenta 440 y el servidor 460. En una modalidad, se incluyen en el sistema múltiples terminales de comerciante 420 y/o terminales de cuenta 440. El servidor 460 de preferencia se implementa por el uso de una o más computadoras de propósitos generales, tales como por ejemplo una Sun Microsystems Fl5k. Cada terminal de comerciante 420 y/o terminal de cuenta 440 también de preferencia se implementa por el uso de una o más computadoras de propósitos generales tales como por ejemplo una computadora personal típica fabricada por Dell, Gateway, o Hewlett-Packard. Cada servidor 460, terminal de cuenta 440 y terminal de comerciante 420 pueden incluir un microprocesador. El microprocesador puede ser cualquier tipo de procesador, tal como por ejemplo cualquier tipo de microprocesador o microcontrolador de propósitos generales, un procesador de procesamiento de señal digital (DSP = Digital Signal Processing), un circuito integrado específico de aplicación (ASIC = Application Specific Integrated Circuit) , una memoria de sólo lectura programable (PROM = Progra mable Read Only Memory), o semejantes. El servidor 460 puede utilizar su microprocesador para leer un medio legible por computadora que contiene programa o soporte lógico que incluye instrucciones para llevar a cabo una o más de las funciones del servidor 460.
Cada servidor 460, terminal de cuenta 440 y terminal de comerciante 420, también puede incluir una memoria de computadora, tal como por ejemplo memoria de acceso aleatorio (RAM = Random Access Memory) . Sin embargo, la memoria de computadora de cada uno del servidor 460, terminal de cuenta 440 y terminal de comerciante 420 puede ser cualquier tipo de memoria de computadora o cualquier otro tipo de medio de almacenamiento electrónico que se ubica ya sea en forma interna o externa al servidor correspondiente 460, la terminal de cuenta 440 y la terminal de comerciante 420, tal como por ejemplo la memoria de sólo lectura (ROM = Read Only Memory) , memoria de sólo lectura de disco compacto (CDROM = Compact Disc Read Only Memory) , memoria electro-óptica, memoria magneto-óptica, una memoria de sólo lectura programable y borrable (EPROM) , una memoria de sólo lectura programable eléctricamente borrable (EEPROM) , un medio legible por computadora o semejantes. De acuerdo con modalidades ejemplares, la RAM correspondiente puede contener por ejemplo el programa operativo ya sea para el servidor 460, terminal de cuenta 440 y terminal de comerciante 420. Como se apreciará con base en la siguiente descripción, la RAM puede por ejemplo ser programada utilizando técnicas convencionales conocidas por aquellos que tienen destreza ordinaria en la especialidad de programación de computadoras. El código fuente actual o código objeto para llevar a cabo las etapas por ejemplo de un programa de computadora, puede almacenarse en la RAM. Cada uno del servidor 460, terminal de cuenta 440 y terminal de comerciante 420, también puede incluir una base de datos. La base de datos puede ser cualquier tipo de base de datos de computadora para almacenar, mantener y permitir acceso a la información electrónica ahi almacenada.
Como se mencionó anteriormente, el servidor 460 de preferencia reside en una red, tal como una red de área local (LAN = Local Area Network) , una red de área amplia ( AN = Wide Area Network), o Internet. En una modalidad, la terminal de cuenta 440 y la terminal de comerciante 420, de preferencia se conectan a la red en la que reside el servidor 460, de esta manera permitiendo comunicaciones electrónicas entre el servidor 460, la terminal de cuenta 440 y la terminal de comerciante 420 sobre una conexión de comunicaciones, ya sea en forma local o remota tal como por ejemplo una conexión Ethernet, una conexión RS-232 o semej antes .
En modalidades preferidas, la terminal de comerciante 420 se configura para trasmitir una TAR, que incluye información de cuenta, por ejemplo como se discutió anteriormente con relación a la etapa 120 de generar una solicitud de compra. En una modalidad, la terminal de cuenta 440 se asocia con la cuenta del titular de la cuenta, por ejemplo el titular de la cuenta tiene acceso a la cuenta.
De preferencia, la terminal de cuenta 440 se configura para trasmitir información de cuenta, por ejemplo proporcionar información de cuenta al servidor 460. Como un ejemplo, la información de cuenta se transmite por la red 480 al servidor 460. El servidor 460 puede estar en comunicación tanto con la terminal del comerciante 420 como con la terminal de cuenta 440. En modalidades preferidas, el servidor 460 se configura para recibir información referente a la primera transacción comercial y además se configura para comparar la información de transacción con la información de cuenta, para determinar si se satisfacen los criterios para autorización previa o pre-autorización, como se discutió anteriormente con relación a la etapa 140 de comparar la información de transacción con los criterios de autorización previa. En una modalidad preferida el servidor 460 se configura para negar la TAR cuando se hace una determinación que los criterios de autorización previa no se satisfacen, como se discutió anteriormente con relación a la etapa 160 de negar la TAR. En una modalidad, el servidor 460 además se configura para evitar adicionales determinaciones respecto a la solicitud de aprobación de transacción realizada.
Como se muestra en la Figura 5, en modalidades preferidas, el servidor 460 puede comprender un módulo de comunicaciones 510, un módulo de comparación 520, un módulo de autorización previa 530 y opcionalmente un módulo de reporte 540. Éstos módulos pueden implementarse en soporte lógico, equipo físico o una combinación de los mismos. En una modalidad, el módulo de comunicaciones 510 recibe la TAR. De acuerdo con esto, el módulo de comunicaciones 510 está en comunicación con la fuente TAR, por ejemplo el comerciante. El módulo de comunicaciones 510 recibe la TAR del comerciante y opcionalmente almacena la TAR en RAM. En una modalidad preferida, el módulo de comunicaciones 510 dirige la información de cuenta a los componentes adicionales del sistema. De preferencia, la TAR que se recibe por el módulo de comunicaciones 510, incluye información referente a la transacción comercial como se discutió en detalle anteriormente. En modalidades preferidas, el módulo de comunicaciones 510 se configura para recibir al menos una solicitud de aprobación de transacción adicional, que incluye información referente a una segunda transacción comercial. Como tal, el servidor 460 es capaz de manejar múltiples TARs ya sea en serie o en paralelo. Debido a que el servidor 460 tiene la capacidad de manejar múltiples TARs y/o solicitudes de compra, el servidor 460 y de acuerdo con esto, el sistema 400 son capaces de proporcionar seguridad para múltiples transacciones que deben extenderse por periodos prolongados de tiempo.
En una modalidad, a fin de recibir información de transacción, el módulo de comparación 520 está en comunicación con el módulo de comunicaciones 510. En otra modalidad, a fin de recibir los criterios de autorización previa, el módulo de comparación 520 está en comunicación con la fuente de los criterios de autorización previa. En modalidades preferidas, el módulo de comparación 520 compara la información de transacción con los criterios de autorización previa y determina si los criterios de autorización previa se satisfacen. De preferencia, el módulo de comparación 520 comunica la determinación de autorización previa al módulo de autorización previa 530. Además, en una modalidad preferida, el módulo de comparación 520 se configura para comparar la información de transacción para múltiples transacciones, con la información de cuenta actualizada para las transacciones respectivas .
En una modalidad, a fin de hacer la determinación de autorización previa, el módulo de autorización previa 530 está en comunicación con el módulo de comparación 520. De preferencia, el módulo de comparación 520 proporciona la información de comparación al módulo de autorización previa 530. A fin de negar TARs no pre-autorizadas , el módulo de autorización previa considera si los criterios de autorización previa se satisfacen. Si los criterios se satisfacen, se otorga la TAR; si los criterios no se satisfacen, se niega la TAR, como se discutió anteriormente. Además, en una modalidad preferida, el módulo de autorización previa 530 se configura para otorgar o negar múltiples TARs relacionadas a múltiples transacciones.
En otra modalidad, la etapa 140 de comparar y la etapa 160 de negar, se realizan por un módulo. En esta modalidad, un módulo de comparación separado y un módulo de autorización previa separado no son necesarios.
El servidor 460, opcionalmente se configura para reportar la negación de la TAR no pre-aprobada . En una modalidad, el servidor 460 puede comprender el módulo de reporte 540, para reportar la negación de la TAR no pre-aprobada. En una modalidad, el módulo de reporte 540 está en comunicación con el módulo de autorización previa 530. Como tal, el módulo de reporte 540 recibe información referente a la negación u otorgamiento de la TAR del módulo de autorización previa 530. Al recibir esta información, el módulo de reporte 540 reporta la disposición de la TAR como se discutió anteriormente.
Modalidades de la invención serán más evidentes en vista de los siguientes ejemplos no limitantes.
Ejemplo 1 En un escenario, el Propietario de la Cuenta tiene una cuenta de tarjeta de crédito. Para la cuenta de tarjeta de crédito, el Propietario de la Cuenta proporciona los siguientes criterios de autorización previa: Cantidad máxima = $1000; Lista de comerciantes = Bloomingdale' s, Barnes & Noble y Local Grocery Store; Estado bloqueado = activado ("bloqueado") .
El Hijo del Propietario de la Cuenta obtiene tarjeta de crédito del Propietario de la Cuenta e intenta hacer una compra por $50 en Sports Authority.
Un programa de protección de tarjeta de crédito (CCPP = Credit Card Protection Program) de acuerdo con la presente invención, se utiliza para autorizar compras con tarjetas de crédito y la solicitud de compra se envía al CCPP. En este caso, no son satisfechos todos los criterios de autorización previa, la solicitud de compra es negada y la transacción se cierra permanentemente, sin posibilidad de mayor verificación.
Ejemplo Comparativo A Se repite el escenario del Ejemplo 1, sin embargo se emplea un CCPP que dirige compras no pre-autorizadas a una lista de espera para mayor verificación. Inicialmente, la solicitud de compra, se compara con los criterios de autorización previa, después, debido a que no todos los criterios se satisfacen, se envía a la lista de espera para adicional disposición. Mientras que la solicitud de compra está en la lista de espera, el Hijo tiene acceso a la cuenta de tarjeta de crédito en línea y actualiza los criterios de autorización previa a: Cantidad máxima = $10; Lista de comerciantes = Bloomingdale' s, Barnes & Noble y Sports Authority.
El Hijo regresa a Sports Authority. CCPP verifica la solicitud de compra (que permanece en la lista de espera) contra los criterios actualizados y de acuerdo con esto, pre-autoriza la solicitud de compra. La compra procede y a la tarjeta de crédito se le carga por la compra de $50.
CCPP utiliza las paradas o topes de la presente invención y cierra la compra, permanentemente, una vez que falla la autorización previa inicial. Incluso si el Hijo alteró los criterios de autorización previa y regresó a Sports Authority como en el Ejemplo Comparativo, la oportunidad para mayor verificación de la solicitud de compra no hubiera sido posible debido al cierre permanente de la transacción. En contraste, CCPP del Ejemplo Comparativo permitió que permaneciera abierta por un periodo de tiempo indefinido. Mientras que permanece abierta, la cuenta es susceptible a violaciones de sequridad.
Cualquier característica descrita o reivindicada con respecto a cualquier implementación descrita, puede ser combinada en cualquier combinación con cualquiera una o más otras características descritas o reivindicadas con respecto a cualquier otra implementación o implementaciones descritas, en la medida que las características no necesariamente sean incompatibles en sentido técnico, y todas estas combinaciones están dentro del alcance de la presente invención. Además, las reivindicaciones agreqadas a continuación establecen algunas combinaciones no limitantes de características dentro del alcance de la invención, pero también se contemplan dentro del alcance de la invención, todas las posibles combinaciones de la materia de cualesquiera dos o más de las reivindicaciones, en cualquier combinación posible, siempre que la combinación no sea necesariamente incompatible en sentido técnico .

Claims (20)

REIVINDICACIONES
1. Un método para facilitar una primera transacción comercial entre un titular de cuenta y un comerciante, el titular de cuenta tiene una cuenta activa, la cuenta se asocia con información de cuenta, la información de cuenta incluye al menos un criterio para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta y el método comprende las etapas de: recibir una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la transacción comercial; comparar la información recibida referente a la transacción comercial con la información de cuenta, para determinar si se satisface el criterio como mínimo para autorización previa o pre-autorizar la transacción; y, cuando se realiza una determinación de que no se satisface el criterio como mínimo para autorización previa de la transacción, negar la solicitud de aprobación de transacción sin desactivar la cuenta; y cuando se hace una determinación que se satisface el criterio como mínimo para autorización previa de la transacción, pre-autorizar la solicitud de aprobación de transacción.
2. El método de conformidad con la reivindicación 1, caracterizado porque además comprende la etapa de evitar que se hagan mayores determinaciones respecto a la solicitud de aprobación de transacción negada .
3. El método de conformidad con la reivindicación 1, caracterizado porque la información de cuenta es modificable por el titular de la cuenta.
4. El método de conformidad con la reivindicación 1, caracterizado porque la información de cuenta se elige del grupo que consiste de una lista de identificadores de comerciantes; información de cantidad de transacción; información de fecha y hora; un indicador de estado bloqueado y sus combinaciones; y la información recibida referente a la transacción comercial, se elige del grupo que consiste de un identificador de un comerciante que solicita aprobación de transacción; información de cantidad de transacción; información de fecha y hora y sus combinaciones .
5. El método de conformidad con la reivindicación 4, caracterizado porque además comprende la etapa de supervisar una cuenta que tiene un estado bloqueado.
6. El método de conformidad con la reivindicación 1, caracterizado porque además comprende la etapa de recibir al menos una solicitud de aprobación de transacción adicional, la solicitud de aprobación de transacción adicional como mínimo incluye información referente a una segunda transacción comercial.
7. El método de conformidad con la reivindicación 6, caracterizado porque información de cuenta es actualizable, después de la solicitud de aprobación de transacción original y antes de cuando menos una solicitud de aprobación de transacción adicional, para incluir al menos un criterio para autorización previa de una segunda transacción.
8. El método de conformidad con la reivindicación 7, caracterizado porque además comprende las etapas de: comparar la información recibida a la segunda transacción comercial con la información de cuenta actualizada, para determinar si se satisface el criterio como mínimo para pre-autorizar la segunda transacción; y cuando se hace una determinación de que no se satisface el criterio como mínimo para pre-autorizar la transacción adicional como mínimo, negar la solicitud de aprobación de transacción adicional como mínimo.
9. El método de conformidad con la reivindicación 1, caracterizado porque además comprende la etapa de reportar la negación de la solicitud de aprobación de transacción no-pre-autorizada ..
10. Un método para utilizar una cuenta activa para realizar una transacción entre un comerciante y un titular de cuenta, la cuenta se asocia con información de cuenta, la información de cuenta incluye un criterio como mínimo para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta, el método comprende las etapas de: presentar una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la transacción comercial; obtener un resultado de comparación de la información presentada por relación a la transacción comercial con la información de cuenta, el resultado de la comparación incluye una determinación de si se satisface el criterio como mínimo para pre-autorizar la transacción; y, cuando se realiza una determinación, el criterio como mínimo para pre-autorizar la transacción no es satisfecho, rehusando la transacción asociada con el criterio de autorización previa no-satisfecho como mínimo, en donde la cuenta permanece activa para una solicitud de aprobación de transacción adicional; y cuando se hace una determinación de que se satisface el criterio como mínimo para pre-autorizar la transacción, aprobar la solicitud de aprobación de transacción.
11. Un sistema para facilitar una primera transacción comercial entre un comerciante y un titular de cuenta, el titular de cuenta tiene una cuenta activa, la cuenta se asocia con información de cuenta, la información de cuenta incluye al menos un criterio para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta, el sistema comprende: un servidor configurado para recibir la información de cuenta y una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la primera transacción comercial; el servidor además se configura para comparar la información recibida referente a la primera transacción comercial con la información de cuenta, para determinar si se satisface el como mínimo para autorización previa; en donde el servidor además se configura para negar la solicitud de aprobación de transacción cuando se realiza una determinación que no se satisface el criterio como mínimo para pre-autorizar la transacción, sin desactivar la cuenta; y en donde el servidor además se configura para pre-autorizar la solicitud de aprobación de transacción cuando se realiza una determinación de que se satisface el criterio como mínimo para pre-autorizar la transacción.
12. El sistema de conformidad con la reivindicación 11, caracterizado porque el servidor además se configura para evitar que se realicen mayores determinaciones respecto a la solicitud de aprobación de transacción .
13. El sistema de conformidad con la reivindicación 11, caracterizado porque el módulo de comunicación del servidor además se configura para recibir al menos una solicitud de aprobación de transacción adicional, la solicitud de aprobación de transacción adicional incluye información referente a una segunda transacción comercial.
14. El sistema de conformidad con la reivindicación 13, caracterizado porque la información de cuenta es actualizable, después de la solicitud de aprobación de transacción original y antes de la solicitud de aprobación de transacción adicional como mínimo, para incluir al menos un criterio para pre-autorizar una segunda transacción .
15. El sistema de conformidad con la reivindicación 14, caracterizado porque el servidor además se configura para comparar la información recibida respecto a la segunda transacción comercial con la información de cuenta actualizada, para determinar si se satisface el criterio como mínimo para pre-autorizar la segunda transacción; y cuando se realiza una determinación de que no se satisface el criterio como mínimo para pre-autorizar la transacción adicional como mínimo, negar la solicitud de aprobación de transacción adicional como mínimo.
16. Un sistema para facilitar una primera transacción comercial entre un comerciante y un titular de cuenta, el titular de cuenta tiene una cuenta activa, la cuenta está asociada con información de cuenta, la información de cuenta incluye cuando menos un criterio para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta, el sistema comprende: una terminal de comerciante, conectada a una red, la terminal de comerciante se configura para transmitir una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la primera transacción comercial, la terminal de comerciante se configura para recibir una aprobación o negación de la solicitud de aprobación de transacción; una terminal de cuenta, la terminal de cuenta se asocia con la cuenta y se conecta con la red, la terminal de cuenta se configura para transmitir la información de cuenta; y un servidor, en comunicación con la terminal de cuenta y la terminal de comerciante mediante la red, el servidor se configura para recibir la información referente a la primera transacción comercial y el servidor se configura para comparar la información recibida referente a la primera transacción comercial con la información de cuenta, para determinar si se satisface el criterio como mínimo para autorización previa; en donde el servidor además se configura para negar la solicitud de aprobación de transacción sin desactivar la cuenta, cuando se realiza una determinación de que no se satisface el criterio como mínimo para pre-autorizar la transacción; y en donde el servidor además se configura para pre-autorizar la solicitud de aprobación de transacción cuando se realiza una determinación de que se satisface el criterio como mínimo para pre-autorizar la transacción.
17. El sistema de conformidad con la reivindicación 16, caracterizado porque el criterio como mínimo para pre-autorizar una transacción, se comunica por la red desde la terminal de cuenta al servidor.
18. El sistema de conformidad con la reivindicación 16, caracterizado porque el criterio como mínimo para pre-autorizar una transacción se modifica por la terminal de cuenta mediante la red.
19. Un método para facilitar una primera transacción comercial entre un titular de cuenta y un comerciante, el titular de cuenta tiene una cuenta activa, la cuenta se asocia con información de cuenta, la información de cuenta incluye al menos un criterio para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta, y el método comprende las etapas de: recibir una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la transacción comercial; comparar la información recibida respecto a la transacción comercial con la información de cuenta para determinar si se satisface el criterio como mínimo para pre-autorizar la transacción; y cuando se realiza una determinación de que no se satisface el criterio como mínimo para pre-autorizar la transacción, abstenerse de mayor comunicación respecto a la transacción comercial con el titular de la cuenta, sin desactivar la cuenta; y cuando se realiza una determinación de que se satisface el criterio como mínimo para autorización previa de la transacción, pre-autorizar la solicitud de aprobación de transacción.
20. Un sistema para facilitar una primera transacción comercial entre un comerciante y un titular de cuenta, el titular de cuenta tiene una cuenta activa, la cuenta se asocia con la información de cuenta, la información de cuenta incluye cuando menos un criterio para pre-autorizar una transacción, el criterio como mínimo se proporciona por el titular de la cuenta, el sistema comprende: un servidor configurado para recibir la información de cuenta y una solicitud de aprobación de transacción, la solicitud de aprobación de transacción incluye información referente a la primera transacción comercial; el servidor además se configura para comparar la información recibida respecto a la primera transacción comercial con la información de cuenta para determinar si se satisface el criterio como mínimo para autorización previa; en donde el servidor además se configura para abstenerse de mayor comunicación respecto a la transacción comercial con el titular de la cuenta, sin desactivar la cuenta, cuando se realiza una determinación de que no se satisface el criterio como mínimo para autorización previa de la transacción; y en donde el servidor además se configura para pre-autorizar la solicitud de aprobación de transacción cuando se hace una determinación de que se satisface el criterio como mínimo para pre-autorizar la transacción.
MX2011005324A 2008-11-21 2009-06-17 Metodo y aparato para proteccion dirigida por consumidor para transacciones con tarjeta de pago. MX2011005324A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US27597508A 2008-11-21 2008-11-21
US12/353,733 US8725601B2 (en) 2008-11-21 2009-01-14 Method and apparatus for consumer driven protection for payment card transactions
PCT/US2009/047663 WO2010059270A1 (en) 2008-11-21 2009-06-17 Method and apparatus for consumer driven protection for payment card transactions

Publications (1)

Publication Number Publication Date
MX2011005324A true MX2011005324A (es) 2011-10-17

Family

ID=40789757

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2011005324A MX2011005324A (es) 2008-11-21 2009-06-17 Metodo y aparato para proteccion dirigida por consumidor para transacciones con tarjeta de pago.

Country Status (4)

Country Link
US (2) US8725601B2 (es)
CA (1) CA2744417C (es)
MX (1) MX2011005324A (es)
WO (1) WO2010059270A1 (es)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6315193B1 (en) * 1998-08-31 2001-11-13 Mastercard International Incorporated Financial transaction card with installment loan feature
US20050049964A1 (en) * 2003-01-14 2005-03-03 Winterer Mary Jo Financial transaction card with automatic payment feature
US8799153B2 (en) 1998-08-31 2014-08-05 Mastercard International Incorporated Systems and methods for appending supplemental payment data to a transaction message
US20100094735A1 (en) * 2006-11-15 2010-04-15 Charles Reynolds Methods and systems for automated payments
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US20120030115A1 (en) * 2008-01-04 2012-02-02 Deborah Peace Systems and methods for preventing fraudulent banking transactions
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20110178929A1 (en) * 2009-03-03 2011-07-21 Paul Durkin Business-to-business transaction qualifier
US8019685B2 (en) * 2009-03-03 2011-09-13 Visa International Service Association System and method for account level blocking
US12423709B2 (en) 2009-03-05 2025-09-23 Tara Chand Singhal System of security that prevents abuse of identity data in global commerce via mobile wireless authorizations
US20110173122A1 (en) * 2010-01-09 2011-07-14 Tara Chand Singhal Systems and methods of bank security in online commerce
US9619801B2 (en) * 2010-08-02 2017-04-11 Stanton Management Group, Inc. User positive approval and authentication services (UPAAS)
US8832804B1 (en) 2011-08-05 2014-09-09 Google Inc. Password pre-verification in client-server applications
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US20140172690A1 (en) * 2012-12-17 2014-06-19 Sas Institute Inc. Systems and Methods For Matching Domain Specific Transactions
US20140236811A1 (en) * 2013-02-15 2014-08-21 Uniloc Luxembourg S.A. Efficient inter-bank funds transfers
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US20140297435A1 (en) * 2013-03-28 2014-10-02 Hoiling Angel WONG Bank card secured payment system and method using real-time communication technology
US8788389B1 (en) 2013-04-26 2014-07-22 Quisk, Inc. Methods and systems for providing a customer controlled account lock feature
US10878422B2 (en) * 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US20140379580A1 (en) * 2013-06-25 2014-12-25 Square, Inc. Integrated online and offline purchase authorization
WO2015001452A1 (en) 2013-07-03 2015-01-08 Visa Cape Town (Pty) Ltd System and method for authorizing direct debit transactions
US10515370B2 (en) 2013-10-09 2019-12-24 The Toronto-Dominion Bank Systems and methods for providing tokenized transaction accounts
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US10176542B2 (en) * 2014-03-24 2019-01-08 Mastercard International Incorporated Systems and methods for identity validation and verification
US10380575B2 (en) * 2014-06-26 2019-08-13 Capital One Services, Llc Systems and methods for transaction pre authentication
CA2906911C (en) 2014-09-29 2023-08-15 The Toronto-Dominion Bank Systems and methods for generating and administering mobile applications using pre-loaded tokens
US9898912B1 (en) * 2014-10-07 2018-02-20 State Farm Mutual Automobile Insurance Company Systems and methods for automatically generating an escape route
US10783508B1 (en) 2014-12-16 2020-09-22 Square, Inc. Processing multiple point-of-sale transactions
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US20160335717A1 (en) * 2015-05-11 2016-11-17 Facebook, Inc. Systems and methods for providing subsequent payment options for identified eligible users
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
EP3139329A1 (en) * 2015-09-03 2017-03-08 Mobile Elements Corp Contactless mobile payment system
US10607200B2 (en) 2015-12-28 2020-03-31 Square, Inc. Point of sale system having a customer terminal and a merchant terminal
SG10201604590XA (en) * 2016-06-06 2018-01-30 Mastercard International Inc Methods and apparatus for authorizing a transaction
US10504092B2 (en) 2016-06-21 2019-12-10 Square, Inc. Transaction interface control
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US12130937B1 (en) 2016-07-01 2024-10-29 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US10783509B2 (en) 2017-09-29 2020-09-22 Square, Inc. Message sizing and serialization optimization
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
US11188912B2 (en) * 2017-12-21 2021-11-30 Mastercard International Incorporated Systems and methods for use in authenticating users to accounts in connection with network transactions
US11094180B1 (en) 2018-04-09 2021-08-17 State Farm Mutual Automobile Insurance Company Sensing peripheral heuristic evidence, reinforcement, and engagement system
US10769618B2 (en) * 2018-07-10 2020-09-08 Capital One Services, Llc Systems and methods for temporarily activating a payment account for fraud prevention
US11410153B1 (en) * 2018-07-31 2022-08-09 Block, Inc. Enrolling mobile-payment customers after online transactions
US20200074541A1 (en) 2018-09-05 2020-03-05 Consumerinfo.Com, Inc. Generation of data structures based on categories of matched data items
US10402817B1 (en) * 2018-10-12 2019-09-03 Capital One Services, Llc Relaxed fraud detection for transactions using virtual transaction cards
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US20200410503A1 (en) * 2019-06-29 2020-12-31 Paypal, Inc. Conditional Transaction Pre-Approval
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
US11004004B1 (en) * 2019-10-16 2021-05-11 Capital One Services, Llc Methods and systems for customizing recommendations based on user actions
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US12021861B2 (en) 2021-01-04 2024-06-25 Bank Of America Corporation Identity verification through multisystem cooperation
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US11836690B1 (en) 2022-04-12 2023-12-05 Wells Fargo Bank, N.A. Systems and methods for private network issuance of digital currency
US12155641B1 (en) 2022-04-15 2024-11-26 Wells Fargo Bank, N.A. Network access tokens and meta-application programming interfaces for enhanced inter-enterprise system data promulgation and profiling
US12086866B2 (en) * 2022-09-21 2024-09-10 Shopify Inc. Systems and methods for preventing malicious modifications to order information sent over a network

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5655007A (en) * 1994-10-13 1997-08-05 Bell Atlantic Network Services, Inc. Telephone based credit card protection
US5708422A (en) * 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US5822737A (en) * 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US5991750A (en) * 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions
US6226624B1 (en) * 1997-10-24 2001-05-01 Craig J. Watson System and method for pre-authorization of individual account remote transactions
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US6636833B1 (en) * 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
US20010042051A1 (en) * 1998-06-26 2001-11-15 Jeremey L. Barrett Network transaction system for minimizing software requirements on client computers
AU3355900A (en) 1999-02-03 2000-08-25 Steven M. Koehler System and method for monitoring a credit account
US6721713B1 (en) * 1999-05-27 2004-04-13 Andersen Consulting Llp Business alliance identification in a web architecture framework
US7319986B2 (en) * 1999-09-28 2008-01-15 Bank Of America Corporation Dynamic payment cards and related management systems and associated methods
US20050108096A1 (en) * 1999-09-28 2005-05-19 Chameleon Network Inc. Portable electronic authorization system and method
AU2001241609A1 (en) * 2000-02-23 2001-09-03 Capital One Financial Corporation Systems and methods for providing anonymous financial transactions
US7379919B2 (en) * 2000-04-11 2008-05-27 Mastercard International Incorporated Method and system for conducting secure payments over a computer network
US8380628B1 (en) * 2000-07-17 2013-02-19 Harris Intellectual Property, Lp System and method for verifying commercial transactions
WO2002007110A2 (en) * 2000-07-17 2002-01-24 Connell Richard O System and methods of validating an authorized user of a payment card and authorization of a payment card transaction
US6978369B2 (en) * 2000-08-04 2005-12-20 First Data Corporation Person-centric account-based digital signature system
US7346577B1 (en) * 2000-08-28 2008-03-18 Javien Digital Payment Solutions, Inc. Third-party billing system and method
US20020152179A1 (en) * 2000-10-27 2002-10-17 Achiezer Racov Remote payment method and system
US6931382B2 (en) * 2001-01-24 2005-08-16 Cdck Corporation Payment instrument authorization technique
US7143069B2 (en) * 2001-05-25 2006-11-28 American Express Travel Related Services Co. System and method for interactive secure dialog between card holder and issuer
EP1402486A1 (en) 2001-06-27 2004-03-31 Snapcount Limited Transcation processing
US7890375B2 (en) * 2001-07-31 2011-02-15 Half.Com, Inc. Method and system to facilitate pre-ordering via an electronic commerce facility, and to automatically facilitate satisfying of a pre-order upon listing of an appropriate offer via the electronic commerce facility
US7461028B2 (en) * 2001-11-27 2008-12-02 Pitney Bowes Inc. Method and system for authorizing use of a transaction card
US7389275B2 (en) * 2002-03-05 2008-06-17 Visa U.S.A. Inc. System for personal authorization control for card transactions
AU2002251458A1 (en) 2002-04-03 2003-10-13 Amsoft Systems System and method for detecting card fraud
US7264154B2 (en) * 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
US8296235B2 (en) * 2007-09-07 2012-10-23 Ebay Inc. System and method for cashback funding

Also Published As

Publication number Publication date
US20090164354A1 (en) 2009-06-25
CA2744417C (en) 2018-01-16
CA2744417A1 (en) 2010-05-27
WO2010059270A1 (en) 2010-05-27
US8660955B2 (en) 2014-02-25
US8725601B2 (en) 2014-05-13
US20130013513A1 (en) 2013-01-10

Similar Documents

Publication Publication Date Title
US8660955B2 (en) Method and apparatus for consumer driven protection for payment card transactions
US9530129B2 (en) Secure authentication and payment system
US7761381B1 (en) Method and system for approving of financial transactions
US8170954B2 (en) Secure and efficient payment processing system with account holder defined transaction limitations
US8069084B2 (en) Customer controlled account, system, and process
US7483858B2 (en) Network-based system
CA2604913C (en) Method and system for risk management in a transaction
US7127427B1 (en) Secure transaction processing system and method
US9430769B2 (en) Secure and efficient payment processing system
US20100179906A1 (en) Payment authorization method and apparatus
US20090240620A1 (en) Secure payment system
US20080015988A1 (en) Proxy card authorization system
JP2006501584A (ja) 取引承認トークンを用いる電子決済確認
KR20080067641A (ko) 신원 절도 및 위조 방지 시스템과 방법
CA2659530A1 (en) Risk detection and assessment of cash payment for electronic purchase transactions
WO2008050132A2 (en) Secure authentication and payment system
EP1134707A1 (en) Payment authorisation method and apparatus
US20020123935A1 (en) Secure commerce system and method
GB2360383A (en) Payment authorisation
KR20010077335A (ko) 전자상거래에서 씨티아이에 의한 대금 결제 인증방법

Legal Events

Date Code Title Description
FA Abandonment or withdrawal