ES2215064T3 - Metodos y aparatos para realizar transacciones electronicas. - Google Patents

Metodos y aparatos para realizar transacciones electronicas.

Info

Publication number
ES2215064T3
ES2215064T3 ES00959619T ES00959619T ES2215064T3 ES 2215064 T3 ES2215064 T3 ES 2215064T3 ES 00959619 T ES00959619 T ES 00959619T ES 00959619 T ES00959619 T ES 00959619T ES 2215064 T3 ES2215064 T3 ES 2215064T3
Authority
ES
Spain
Prior art keywords
user
transaction
server
computer
wallet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES00959619T
Other languages
English (en)
Inventor
Russell Bennett
Fred Bishop
Elliot Glazer
Zyg Gorgol
William G. Hohle
David Johnstone
Walter D. Lake
Marvin Simkin
Nick Swift
Dirk White
Michael Johnson
Coby Royer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
American Express Travel Related Services Co Inc
Original Assignee
American Express Travel Related Services Co Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by American Express Travel Related Services Co Inc filed Critical American Express Travel Related Services Co Inc
Application granted granted Critical
Publication of ES2215064T3 publication Critical patent/ES2215064T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un método de operación de aparato de ordenador para llevar a cabo una transacción, comprendiendo el método: a. recibir una solicitud de transacción (1002; 1102) desde un usuario en un servidor (140; 130); b. emitir una pregunta (1004; 1106, 1108) al usuario; c. recibir una respuesta (1008; 1110, 1112) desde el usuario basada en la pregunta; d. procesar dicha respuesta para verificar al usuario (1010; 1114); e. montar las credenciales para la transacción, comprendiendo dichas credenciales al menos una clave; f. proporcionar al menos una parte de dichas credenciales a dicho usuario (1012); g. recibir una segunda solicitud (1014; 1110) desde dicho usuario, incluyendo dicha segunda solicitud dicha porción de dichas credenciales; y h. validar (1016, 1018; 1112, 1116) dicha porción de dichas credenciales con dicha clave para proporcionar acceso a un servicio de transacción.

Description

Métodos y aparatos para realizar transacciones electrónicas.
Campo de la invención
La presente invención se refiere, generalmente, a métodos y aparatos para realizar transacciones en la red. Más particularmente, la invención se refiere a sistemas para autentificación y realización de negocios sobre redes de datos, tales como Internet.
Antecedentes de la invención
En los últimos años, muchos consumidores han descubierto la conveniencia y economía de comprar artículos y servicios electrónicamente. Están disponibles un gran número de canales para las compras electrónicas (denominados comúnmente 
\hbox{ compras-e ,}
que incluyen redes de televisión de compra-desde-casa, respuestas a llamadas a publicidad en televisión, y similares. Más recientemente, la compra directa a través de Internet está siendo extremadamente popular.
En una transacción típica por Internet, un consumidor identifica generalmente los artículos y/o servicios para compra mediante la visión en publicidad en línea, tal como documento de lenguaje de recargo de hipertexto (HTML) previsto a través de un navegador de World Wide Web (WWW). El pago se produce típicamente a través de un número de tarjeta de cargo que está previsto a través de un canal de seguridad, tal como una conexión de capa de casquillo de seguridad (SSL) que se establece entre el consumidor y el comerciante. El número de cuenta de la tarjeta de cargo es típicamente un número de tarjeta de crédito de dieciséis dígitos. Los números de las tarjetas de crédito cumplen con un formato normalizado que tiene cuatro conjuntos de números espaciados, como se representa por el número "0000 0000 0000 0000". Los primeros cinco a siete dígitos son reservados para los fines de procesamiento e identidad del banco de emisión, tipo tarjeta, etc. El último decimosexto dígito es utilizado como un control de suma para el número del dígito dieciséis. Los intermediarios de ocho a diez dígitos son utilizados para identificar únicamente al cliente. El comerciante procesa entonces el número de la tarjeta de carga, por ejemplo, recibiendo la autorización directa del emisor de la tarjeta, después, el comerciante completa la transacción. La norma del SSL se describe, por ejemplo por, "The SSL Protocol Version a 3.0" con fecha 8 de Noviembre de 1996, que está disponible en línea en http://home.netscape.com/eng/ssl3/draft302.txt.
Aunque tienen lugar millones de transacciones cada día a través de Internet, las transacciones SSL convencionales muestran con frecuencia un número de inconvenientes marcados. Aunque la SSL proporciona típicamente una conexión extremo a extremo de seguridad que previene que terceras partes sin escrúpulos fisgoneen (por ejemplo "rastreo") u obtengan de otro modo un número de tarjeta de cargo del comprador, el protocolo no proporciona medios para asegurar que el propio número de tarjeta de cargo es válido, o que la persona que proporciona el número de tarjeta está autorizada legalmente a hacerlo. Debido a la alta incidencia de fraude en las transacciones por Internet, la mayoría de los emisores de tarjetas de cargo consideran que las transacciones de red sean transacciones de "Tarjeta No Presente" sujetas a un mayor porcentaje de descuento. Dicho de otro modo, debido al riesgo incrementado de las transacciones "Tarjeta No Presente", la mayoría de los emisores de tarjeta de cargo cargan al comerciante un porcentaje más alto para aceptar los números de tarjeta a través de medios electrónicos que lo que se cargaría si la tarjeta fuera presentada físicamente al comerciante.
Para mejorar las deficiencias de seguridad inherentes en los números de tarjeta de cargo en transporte sobre las redes no seguras, muchos han sugerido el uso de "tarjetas inteligentes". Las Tarjetas Inteligentes incluyen típicamente un chip de circuito integrado que tiene un microprocesador y memoria para almacenar datos directamente sobre la tarjeta. Los datos pueden corresponder con una clave criptográfica, por ejemplo, o con un monedero electrónico que mantiene el valor electrónico de la moneda. Se han sugerido en la técnica anterior algunos esquemas de tarjeta inteligente, pero estos muestran típicamente un inconveniente marcado puesto que no son estándar. En otras palabras, los comerciantes deben obtener típicamente nuevo software de propietario para sus expositores de Web para aceptar las transacciones con tarjeta inteligente. Además, han sido excesivos hasta la fecha los costes de administración implicados con la asignación y que mantienen la información criptográfica asociada con tarjetas inteligentes.
La norma de Transacción Electrónica de Seguridad (SET) ha sido sugerida para mejorar la seguridad de las transacciones por Internet a través del uso de varias técnicas criptográficas. Aunque la SET no proporciona seguridad mejorada sobre las transacciones SLL estándar, la administración implicada con varias claves públicas y privadas requeridas para llevar a cabo transacciones ha limitado la aceptación dispersada de las SET. La SET requiere también software especial para estos comerciantes que deseen mantener transacciones SET.
La tecnología de cartera digital existente, tal como la tecnología de cartera digital prevista por ejemplo por GlobeSet, Inc, 1250 Capital of Texas Highway South, Building One, Suite 300, Austin, TX, 78746, proporciona medios para clientes para utilizar productos de tarjeta de transacción (por ejemplo, crédito, cargo, débito, tarjetas inteligentes, números de cuenta y similares) para pagar los productos y servicios en línea. En general, las carteras digitales son herramientas que almacenan información personal (nombre, dirección, número de tarjeta de cargo, número de tarjeta de crédito, etc.) con el fin de facilitar el comercio electrónico u otras interacciones en la red. La información personal puede ser memorizada sobre un servidor general o en el lugar del cliente (PC o Tarjeta Inteligente) o en un híbrido tanto de un servidor general como un servidor del cliente. El servidor general de la cartera digital está compuesto de un servidor de Web y un servidor de base de datos que aloja en el centro la información personal del cliente y la información de la tarjeta de crédito, preferencias de compra y perfiles de comerciantes en línea.
Una cartera digital realiza preferentemente funciones tales como un relleno de forma automática del formulario con una sola firma/una palabra de paso de las páginas de verificación, compra con uno o dos click, personalización de Websites, orden en línea y seguimiento de suministro, recibos electrónicos detallados, y ofertas y promociones a medida basadas en los patrones de venta y opciones. Más particularmente, la compra con un click activa la cartera y confirma la compra al mismo tiempo. Una verificación con dos click activa en primer lugar la cartera, después, el segundo click confirma la compra.
En uso, la marca de libro de la cartera es pinchada típicamente por el cliente y se establece una sesión de SSL con el servidor de la Cartera. Se ejecuta una conexión con el navegador y el cliente suministra una ID/palabra de paso o la tarjeta inteligente para autenticación con el fin de acceder a los datos de la cartera. Cuando se compra en un comerciante en línea, los datos de la cartera adecuados son transferidos desde el servidor de la cartera hasta el servidor de la Web del comerciante.
El documento US-5.534.857 (BOWCOCK, MATTHEW P y col.), 9 de Julio de 1996, describe un método y aparato para escribir de forma segura datos confidenciales a partir de un emisor hasta una tarjeta inteligente del cliente, sin ninguna posibilidad de proporcionar credenciales a un usuario para proporcionar acceso a un servicio que está siendo autentificado a través de una pregunta-respuesta.
El documento US-A-5.832.212 (CRAGUN, BRIAN JOHN, y col), 3 de Noviembre de 1998, describe un navegador de censura de visión por Internet, sin un proceso remoto de exploración para caracteres particulares.
El documento EP-A-0.917.120 (CITICORP DEV CENTER INC), 19 de Mayo de 1999, describe un cliente de cartera digital para facilitar las transacciones electrónicas a través de una red digital en unión con un programa navegador.
Se desea, por tanto, un nuevo sistema de realización de transacciones electrónicas. Un sistema de este tipo debería proporcionar seguridad mejorada sin gastos adicionales para clientes y comerciantes. Además, un nuevo sistema de este tipo debería integrarse bien con varias carteras de Internet y otros servicios previstos por varios vendedores.
Resumen de la invención
De acuerdo con un aspecto de la presente invención, está previsto un método para llevar a cabo una transacción como se define en la reivindicación 1.
De acuerdo con otro aspecto de la presente invención, está previsto un sistema de transacción para facilitar una transacción financiera solicitada por un usuario que opera con un ordenador de usuario sobre una red de datos como se define en la reivindicación 5.
De acuerdo con otro aspecto de la presente invención, está prevista una invención ejecutada con ordenador como se define en la reivindicación 17.
Se describe también aquí un método ejecutado con ordenador para proteger a un servidor de red de ser utilizado como la base de un ataque sobre un cliente de la red, comprendiendo el método:
a.
recibir una solicitud para una conexión en dicho servidor desde dicho cliente de la red; y
b.
explorar una parte de dicho servidor de la red para caracteres particulares asociados con un protocolo;
c.
verificar que cualquier respuesta desde dicho servidor de la red hasta dicho cliente de la red está desprovista de dichos caracteres particulares; y
d.
proporcionar dicha respuesta de dicho servidor de la red hasta dicho cliente de la red.
El método puede comprender adicionalmente limitar el acceso a dicho servidor de la red para dicho protocolo a dicha porción de dicho servidor de la red. Dichos caracteres particulares pueden ser sustituidos con caracteres benignos, de modo que se reduce el riesgo de seguridad poseído por dicho protocolo seleccionado y, opcionalmente, dichos caracteres particulares pueden ser registrados para formar un registro de seguridad. Dicho registro de seguridad puede ser revisado para determinar si son hostiles dichos caracteres particulares.
En una forma de realización, dicho protocolo comprende javascript.
Este método puede utilizarse en la protección del servidor de la red durante una transacción de compra electrónica, por ejemplo, donde la transacción de compra electrónica se lleva a cabo utilizando una cartera digital.
Se describe también aquí un cliente de cartera digital para facilitar las transacciones electrónicas a través de una red digital, en unión con un programa navegador, comprendiendo el cliente de cartera digital:
a.
una aplicación de cartera configurada para iniciar una sección con un servidor de cartera a través de dicha red digital en respuesta a las entradas desde un usuario; y
b.
una interfaz para un dispositivo lector, donde dicho dispositivo lector está configurado para aceptar una ficha para verificar la identidad de dicho usuario; y
donde dicha aplicación de cartera es accionable para autentificar dicho usuario con respecto a dicho servidor de cartera utilizando dicha ficha y poniendo en contacto dicho servidor de cartera a través de dicha red digital para consumar dichas transacciones electrónicas.
La cartera digital puede comprender adicionalmente un activador para acceder a dicho servidor de cartera, donde dicho activador intercambia información con dicho servidor de cartera para completar dichas transacciones electrónicas.
La aplicación de cartera digital puede estar configurada adicionalmente para autentificar dicho usuario con respecto a dicho servidor de cartera basado al menos, en parte, en una credencial recibida en dicho cliente de cartera digital desde un servidor de seguridad sobre dicha red digital.
El activador de dicho cliente de cartera digital puede comprender un indicador de estado representado a dicho usuario, correspondiendo dicho indicador de estado con la disponibilidad de los servicios de cartera para una página web.
La aplicación de la cartera puede configurarse adicionalmente para obtener una firma digital desde dicha ficha y proporcionar dicha firma digital a dicho servidor de cartera a través de dicha red digital.
Se describe también un servidor de cartera para facilitar una transacción a través de una red digital, comprendiendo el servidor de cartera:
a.
una interfaz a una red digital; y
b.
una aplicación de servidor de cartera en comunicación con una base de datos, donde dicho servidor de cartera está configurado para recibir una solicitud para una transacción desde un cliente de cartera, para procesar una credencial recibida desde dicho cliente de cartera para autentificar a un usuario de dicho cliente de cartera para recuperar información del usuario desde dicha base de datos para autentificar dicho usuario y completar dicha transacción en nombre de dicho usuario utilizando dicha información del usuario.
Dicha credencial puede comprender una firma digital. Dicha credencial puede comprender adicionalmente un extracto aleatorio firmado digitalmente por una ficha en posesión de dicho usuario.
El extracto puede proporcionarse a dicho cliente de cartera por un servidor de seguridad.
En una forma de realización de este tipo, la finalización de dicha transacción en nombre de dicho usuario comprende típicamente completar un formulario del comerciante con dicha información del usuario.
Se describe también un método ejecutado con ordenador para facilitar una compra en línea que comprende las etapas de:
autentificar con dicho servidor de seguridad;
recibir una credencial de dicho servidor de seguridad;
identificar una dirección de comerciante desde la que realizar dicha compra;
proporcionar dicha credencial a un servidor de cartera para autentificar dicho usuario a dicho servidor de cartera;
después de la autentificación con éxito con dicho servidor de cartera,
re-direccionar las comunicaciones con dicha dirección del comerciante a dicho servidor de cartera, de forma que dicho servidor de cartera proporciona información de la compra sobre dicho usuario a dicha dirección del comerciante; y
recibir una confirmación de los resultados de dicha compra.
Se describe adicionalmente aquí un método ejecutado por ordenador para facilitar una compra en línea que comprende las etapas de:
recibir una solicitud para transacción desde un usuario en un servidor, comprendiendo dicha solicitud una dirección de comerciante y una credencial;
verificar dicha credencial para autentificar dicho usuario;
recuperar la información del usuario desde una base de datos en repuesta a dicha etapa de verificación;
completar un formulario en línea correspondiente a dicha dirección del comerciante; y proporcionar un resultado de compra a dicho usuario.
Dicha credencial puede comprender una firma digital. Dicha credencial puede comprender adicionalmente datos recibidos desde un servidor de seguridad.
En una forma de realización, dicho servidor de seguridad es afiliado con dicho servidor.
La firma digital puede producirse por una tarjeta inteligente.
En las formas de realización ejemplares de la invención, un usuario es provisto con una ficha inteligente, tal como una tarjeta inteligente, que puede utilizarse en la realización de transacciones electrónicas. La ficha inteligente contiene un certificado digital y se autentifica adecuadamente con un servidor sobre la red que conduce toda o partes de la transacción en nombre del usuario. El usuario es un comprador que lleva a cabo una transacción de compra y el servidor es un servidor de cartera que interactúa con un servidor de seguridad para proporcionar la fiabilidad y confidencialidad mejoradas en la transacción.
Las transacciones electrónicas, tales como transacciones de compra se llevan a cabo por:
la recepción de una solicitud de transacción desde un usuario en un servidor: emisión de una pregunta al usuario;
la recepción de una respuesta desde el usuario basada en la pregunta; procesar la respuesta para verificar un instrumento de transacción; montar las credenciales que incluyen al menos una clave
para la transacción electrónica; proporcionar al menos una porción de las credenciales al usuario;
recibir la segunda solicitud desde el usuario que incluye la parte de las credenciales; y validar la porción de las credenciales con la clave para proporcionar acceso a un servicio de transacción.
Además, la presente invención protege un servidor de red de un ataque por: limitación de acceso al servidor de la red hasta una porción del servidor de la red para al menos un protocolo seleccionado y explorar la porción del servidor de la red para caracteres particulares asociados con el protocolo seleccionado. Los caracteres particulares pueden ser retirados o sustituidos con caracteres benignos con el fin de reducir el riesgo de la seguridad impuesto por el protocolo seleccionado. Preferentemente, los caracteres pueden ser registrados con el fin de formar un registro de seguridad. El registro de seguridad puede ser revisado para determinar si son hostiles los caracteres particulares. Alternativamente, puede denegarse una solicitud.
La presente invención incluye también una herramienta de transacción, tal como una cartera digital utilizada para realizar transacciones de compra, que tiene un activador y una barra de herramientas. Preferentemente, la barra de herramientas permite al usuario realizar una pequeña descarga del activador y la barra de herramientas utiliza uno o más controles del sistema operativo, por ejemplo, un icono de bandeja del sistema. La herramienta de transacción incluye también un componente de relleno del formulario y un componente de memoria automática para rellenar previamente formularios con información prevista previamente por el usuario.
Breve descripción de los dibujos
Las características anteriores y otras características y ventajas de la presente invención se describen de aquí en adelante en la siguiente descripción detallada de las formas de realización ejemplares que deben leerse en unión con las figuras de los dibujos que se acompañan, donde los números de referencia iguales son utilizados para identificar partes iguales o similares en las vistas similares, y:
Las figuras 1A-1C son diagramas de bloques de varias formas de realización de un sistema de transacción electrónica.
La figura 2 es un diagrama de bloques de un sistema de compra ejemplar.
La figura 3 es un diagrama de bloques de un sistema de seguridad ejemplar.
La figura 4 es un diagrama de bloques de un servidor de cartera ejemplar.
Las figuras 5-8 son pantallas de representación ejemplares para una forma de realización de una cartera digital formada de acuerdo con la presente invención.
La figura 9 es un diagrama de bloques de un proceso ejemplar ejecutado por una aplicación del activador ejemplar.
La figura 10 es un diagrama de secuencia de mensaje de una secuencia de registro ejemplar.
La figura 11 es un diagrama de secuencia de mensaje de una secuencia de compra ejemplar.
La figura 12A es un diagrama de secuencia de mensaje que ilustra un problema de seguridad potencial encontrado con muchos lenguajes de escritura.
La figura 12B es un diagrama de secuencia de mensaje de un flujo de comunicaciones correctas sin los problemas de seguridad mostrados en la figura 12A; y
La figura 13 es un diagrama de flujo de un proceso ejemplar para la reducción o eliminación del código ejecutable no deseado.
Descripción detallada de las formas de realización ejemplares preferidas
La presente invención puede describirse aquí en términos de componentes de bloques funcionales y varias etapas de procesamiento. Debería apreciarse que tales bloques funcionales pueden llevarse a cabo por cualquier número de componentes de hardware y/o software configurados para realizar las funciones específicas. Por ejemplo, la presente invención puede emplear varios componentes de circuito integrado (I.C.), por ejemplo, elementos de memoria, elementos de procesamiento, elementos lógicos, tablas de consulta, y similares, que pueden llevar acabo una variedad de funciones bajo el control de uno o más microprocesadores u otros dispositivos de control. De forma similar, los elementos de software de la presente invención pueden ejecutarse con cualquier programación o lenguaje de escritura, tal como C; C++, Java, COBOL, assembler, PERL, o similar, siendo ejecutados varios algoritmos con cualquier combinación de estructura de datos, objetos, procesos, rutas u otros elementos de programación. Adicionalmente, debería indicarse que la presente invención puede emplear cualquier número de técnicas convencionales para la transmisión de datos, señalización, procesamiento de datos, control de red, y similares. Todavía adicionalmente, la invención podría utilizarse para detectar o prevenir las cuestiones de seguridad con un lenguaje de escritura, tal como JavaScript, VBcript o similar.
Debería apreciarse que las ejecuciones particulares mostradas y descritas aquí, son ilustrativas de la invención y de su mejor modo y no están destinadas a limitar, de otro modo, el alcance de la presente invención de ninguna manera. Efectivamente, por bien de la brevedad, la interconexión de datos convencional, desarrollo de la aplicación y otros aspectos funcionales de los sistemas (y componentes de los componentes operativos individuales de los sistemas) pueden no describirse de forma detallada aquí. Adicionalmente, las líneas de conexión mostradas en las varias figuras contenidas aquí están destinadas a representar las relaciones funcionales ejemplares y/o los acoplamientos físicos entre los varios elementos. Debería indicarse que pueden estar presentes muchas relaciones funcionales alternativas o adicionales o conexiones físicas en un sistema de transacción electrónica.
Para simplificar la descripción de las formas de realización ejemplares, la invención se describe frecuentemente por pertenecer al sistema del comercio electrónico que se mueve en Internet. No obstante, se apreciará que podrían formularse muchas aplicaciones de la presente invención. Por ejemplo, el sistema podría utilizarse para autentificar usuarios de un sistema de ordenador o activar un sistema de código de paso, o cualquier otro fin. De forma similar, la invención podría utilizarse en unión con cualquier tipo de ordenador personal, ordenador de red, estación de trabajo, mini ordenador, cuadro principal o similar que accione cualquier sistema operativo tal como cualquier versión del Windows, Windows NT, Windows 2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, o similares. Además, aunque la invención se describe con frecuencia aquí por ser ejecutada con protocolos de comunicaciones TCP/IP, se entenderá fácilmente que la invención podría ejecutarse también utilizando IPX, Appletalk, IP-6, NetBI-OS, OSI o cualquier número de protocolos existentes o futuros.
Adicionalmente, el cliente y el comerciante pueden representar personas individuales, entidades, o negocios, mientras que el banco puede representar otros tipos de instituciones que emiten tarjetas, tales como compañías de tarjetas de crédito, compañías de patrocinio de tarjetas, o emisores de terceras partes bajo contrato con instituciones financieras. La red de pago incluye redes de propietarios existentes que se adaptan actualmente a transacciones para tarjetas de crédito, tarjetas de débito, y otros tipos de tarjetas financieras/bancarias. La red de pago es una red cerrada que se supone es segura para los fisgones, tales como red de la American Express®, red de la VisaNet® o Veriphone®.
Adicionalmente, pueden estar implicados otros participantes en algunas fases de la transacción, tales como una institución de establecimiento de intermediario, pero estos participantes no se muestran. Cada participante está equipado con un sistema de computación para facilitar las transacciones. El cliente tiene un ordenador personal, el comerciante tiene un ordenador/servidor, y el banco tiene un ordenador de cuadro principal; no obstante, cualquiera de los ordenadores puede ser un mini-ordenador, un servidor de PC, un conjunto de ordenadores en red, ordenadores portátiles, libros de notas, ordenadores móviles, cajas superiores, y similares.
Haciendo referencia ahora a la figura 1A, un sistema de transacción 100 incluye de forma adecuada al menos un ordenador de usuario 110, un ordenador autorizador de la transacción 120, un servidor de seguridad 130 y un servidor de herramienta de transacción opcional 140. En las varias formas de realización descritas detalladamente aquí, el sistema de transacción 200 es utilizado en el comercio electrónico para llevar a cabo transacciones de compra. Específicamente, el ordenador del usuario 110 es un ordenador de comprador o cliente, el ordenador autorizador de la transacción 120 es un ordenador del comerciante y el servidor de la herramienta de transacción 140 es un servidor de cartera digital. Se apreciará que aunque el sistema de transacción descrito aquí es un sistema de comercio electrónico, la presente invención se puede aplicar igualmente a varios otros sistemas de transacción electrónica.
Los varios sistemas de ordenador y servidores están interconectados como es adecuado por una red de datos 102, que es cualquier red de datos tal como Internet u otra red de datos pública. Otras redes adecuadas 102 incluyen la red de teléfono pública conmutada (PSTN), intranets de corporaciones o universidades y similares. En varias formas de realización, tales como una mostrada en la figura 1B, el ordenador del comerciante 120 está acoplado electrónicamente al servidor de seguridad 130 a través de una conexión de datos 152 separado de la red 102. De forma similar, varias formas de realización incluyen una conexión 150 separada de la red 102 que conecta el servidor de la cartera 140 y el servidor de la red 130, Las conexiones de datos ejemplares adecuadas para uso con conexiones 150 y 152, incluyen conexiones telefónicas, conexiones ISDN, T1 dedicado u otras conexiones de datos, conexiones inalámbricas y similares. Se apreciará que la conexión 150 y la conexión 152 pueden ser conexiones idénticas, o cada una puede ser de una forma de conexión totalmente diferente en varias formas de realización de la invención.
Varias formas de realización, tales como una mostrada en la figura 1C, incluyen también un servidor de aplicación 160. En varias formas de realización, las bases de datos (no mostradas), y/o los servidores de perfil (no mostrados) pueden estar conectados al servidor de aplicación 160 y/o servidor de cartera 140. El servidor de aplicación 160 puede ser utilizado para equilibrar la carga de trabajo. La dispersión de la carga de trabajo entre la cartera digital 140 y el servidor de aplicación 160 puede mejorar la eficiencia y/o la seguridad. Por ejemplo, el servidor de aplicación 160 puede realizar parte de la funcionalidad realizada por el servidor de la Cartera 140, tal como acceso a la base de datos. Puesto que el servidor de aplicación 160 no está conectado a la red de datos 102, la seguridad puede mejorarse teniendo acceso a la base de datos que se realiza por el servidor de aplicación 160 en lugar del servidor de cartera 140.
Aunque se han ilustrado en las figuras 1A-1C varias formas de realización ejemplares en las figuras 1A-1C, se apreciará que son posibles otras formas de realización. Por ejemplo, una forma de realización puede incluir conexión 150 pero no conexión 152, o viceversa. Adicionalmente, los componentes (por ejemplo, cliente 110, comerciante 120, servidor de seguridad 130, servidor de cartera 140 y servidor de aplicación 160) pueden ser ordenadores individuales o grupos en red de ordenadores que actúan con el fin similar de cumplir las funciones descritas aquí. La funcionalidad atribuida a un solo componente puede ser distribuida entre uno o más ordenadores individuales con el fin de cumplir la funcionalidad descrita. Por ejemplo, el servidor de la cartera 140, puede ser, de hecho, una colección de servidores de Web, servidores de aplicación, servidores de base de datos y otros tipos de servidores.
Para llevar a cabo una transacción, el cliente 110 establece de forma adecuada una conexión a través de la red 102 con un comerciante 120. Cuando debe consumarse una compra, el cliente 110 accede al servidor de cartera 140. El cliente 110 es dirigido de nuevo al servidor de seguridad 130 para verificar que una tarjeta inteligente está en posesión del cliente. La tarjeta inteligente puede incluir un certificado digital que identifica únicamente la tarjeta, de forma que pueden crearse las credenciales digitales en relación con la transacción, como se describe a continuación. En varias formas de realización, las porciones de las credenciales digitales son retornadas al cliente 110 y una porción está prevista al servidor de cartera 140 a través de una conexión de seguridad 150. El cliente 110 puede utilizar entonces las credenciales digitales para autentificar a un servidor de cartera 140, que puede completar la transacción electrónica como un poder para el cliente 110. El servidor de la cartera 140 puede incluir la funcionalidad para completar los formularios de compra afiliados con el ordenador del comerciante 120, por ejemplo. Cuando el comerciante 120 recibe un identificador de instrumento de compara de seguridad desde el cliente 110 o desde el servidor de cartera 140, puede tener lugar la autorización de tarjeta sobre la conexión 152 como cualquier autorización de tarjeta de cargo ordinaria. Como se describe anteriormente, las comunicaciones pueden realizarse utilizando varios protocolos, por ejemplo, SSL o VPN y similares. Puesto que la tarjeta inteligente contiene información de identificación que es única para la tarjeta particular y que puede hacerse conocer a la red a través de medios electrónicos, una transacción de compra llevada a cabo con una tarjeta inteligente es más segura que una transacción llevada a cabo con una tarjeta de cargo o de crédito ordinaria. Puede justificarse un porcentaje de descuento menor para la transacción de seguridad, que puede procesarse por el emisor de la tarjeta como una transacción "Tarjeta Presente". Adicionalmente, si la transacción es una transacción "Tarjeta Presente", el riesgo de fraude puede ser transferido desde el comerciante al emisor de la tarjeta.
Con referencia ahora a la figura 2, un ordenador de comprador ejemplar 110 (referido también como un ordenador de cliente, consumidor, o de usuario), es un sistema de ordenador que es capaz de iniciar una transacción de compra electrónica sobre red de datos 102. En varias formas de realización, el ordenador del comprador 110 es un ordenador personal que acciona cualquier sistema operativo 212, tal como cualquier versión del sistema operativo de Windows, disponible de Microsoft Corporation of Redmond, Washington o cualquier versión del sistema operativo de MacOS disponible de Apple Corporation de Cupertino, California.
El ordenador del comprador 110 incluye adecuadamente hardware y/o software para permitir que una tarjeta inteligente 202 se interconecte con un navegador de Web 216 a través de un sistema operativo 212. El navegador de Web 216 es cualquier programa compatible con el ordenador personal 110 que se comunica a través de la red 102, tal como Netscape Communicator, disponible de Netscape Corporation of Mountain View, California, Internet Explorer disponible de Microsoft Corporation of Redmond, Washington, o el Navegador AOL disponible de America Online Corporation de Dulles, Virginia. En varias formas de realización, el ordenador del comprador 110 incluye un cliente de la cartera 214, que es cualquier programa de ordenador configurado para comunicarse con el servidor de la cartera 140. Un cliente de cartera ejemplar 214 es el Microsoft Wallet, o el Globeset Wallet disponible de la Globeset Corporation of Austin, Texas, aunque podría utilizarse cualquier programa de cartera.
El cliente de la cartera 214 y el navegador 216 pueden interactuar con la tarjeta inteligente 202 por el envío de datos a través del sistema operativo 212 a un lector de tarjeta 204. El lector de tarjeta 204 es cualquier dispositivo lector capaz de transferir información entre el cliente de la tarjeta 214 y la tarjeta inteligente 202. En varias formas de realización, el lector de tarjeta 204 es un lector compatible con la ISO-7816, tal como el Modelo GCR410 disponible de Gemplus Corporation of Redwood City, California, o cualquier otro lector adecuado.
La tarjeta inteligente 202 es cualquier tarjeta que es capaz de realizar transacciones electrónicas, tales como cualquier tarjeta inteligente que es compatible con las siguientes normas ISO:
ISO/IEC 7816-1:1998 Tarjetas de identificación-tarjetas de Circuito(s) Integrado(s) con contactos - Parte 1: Características Físicas;
ISO/IEC-7816-2: 1999 Tecnología de información-tarjetas de identificación-tarjetas de circuito(s) integrado(s) con contactos - Parte 2: Dimensiones y localización de los contactos;
ISO/IEC 7816-3:1997 Tecnología de información-tarjetas de identificación-tarjetas de circuito(s) integrado(s) con contactos - Parte 3: Señales electrónicas y protocolos de transmisión;
ISO/IEC 7816-4: 1995 Tecnología de información-tarjetas de identificación-tarjetas de circuito(s) integrado(s) con contactos - Parte 4: Comandos de Inter-industrias para intercambio;
ISO/IEC 7816-5: 1994 Tarjetas de identificación-tarjetas de circuito(s) integrado(s) con contactos - Parte 5: Sistema de numeración y procesamiento de registro para identificadores de aplicación;
ISO/IEC 7816-6: 1996 Tarjetas de identificación-tarjetas de circuito(s) integrado(s) con contactos - Parte 6: Elementos de datos inter-industrias; e
ISO/IEC 7816-7: 1999 Tarjetas de identificación tarjetas de circuito(s) integrado(s) integrados con contactos - Parte 7: Comandos de Inter-industrias para Lenguaje de Consulta de Tarjeta Estructura (SCQL).
Una tarjeta inteligente ejemplar 202 es una tarjeta inteligente de acuerdo con las especificaciones de la ISO 7816 que incluyen un chip de modelo SLE66 disponible de Infineon Corporation of Munich, Alemania. El chip SLE66 incluye una memoria (tal como, una memoria de 16k, aunque podría utilizarse más o menos memoria) y un procesador que acciona, por ejemplo, el sistema operativo Multos (tal como Multos v.4). En varias formas de realización, la tarjeta inteligente 202 incluye también un applet para almacenar y procesar certificados digitales u otras funciones criptográficas. Para una introducción básica de la criptografía, ver "Applied Cryptography: Protocols, Algothms, And Source Code in C", por Bruce Scheneier y publicado por John Wiley & Sons (segunda edición, 1996).
Por ejemplo, un applet X.509 Java podría incluirse en la tarjeta inteligente 202 para el procesamiento de un certificado X.509 memorizado. Aunque las formas de realización descritas aquí utilizan una tarjeta inteligente, se apreciará que otras fichas inteligentes, por ejemplo, un sistema global para teléfono móvil de comunicación móvil (GSM), puede sustituirse por la tarjeta inteligente en varias formas de realización de la invención.
Con referencia ahora a la figura 3, un servidor de seguridad 130 incluye de forma adecuada una interfaz a la red 102, un motor de seguridad 304 y un servidor autorizado 306 que comunica con una base de datos 310. La interfaz de la red 302 es cualquier programa que facilita las comunicaciones sobre la red 102, tal como un servidor de Web. En varias formas de realización, la interfaz de la red 302 está basada en el Servidor Netscape Enterprise, disponible de Netscape Corporation of Mountain View, California. La interfaz Network 302 recibe mensajes electrónicos sobre la red 102 y los encamina al motor de seguridad 304 o al servidor de autorización 306 como sea adecuado.
El motor de seguridad 304 y el servidor de autorización 306 pueden separarse por un mamparo cortafuegos 308. El mamparo cortafuegos 309 es cualquier control de hardware o software (tal como un control de acceso del encaminador) capaz de limitar el flujo de datos entre una red interna y una externa (no mostrado). En varias formas de realización, el motor de seguridad 304 reside de forma adecuada fuera del mamparo cortafuegos para administrar transferencias de datos entre el servidor de seguridad 130 y el cliente 110 o el servidor de la cartera 140. El servidor de la autorización 306 retiene la información confidencial valiosa tal como base de datos 310, que puede contener una referencia cruzada de x.509 certificados almacenados sobre las varias tarjetas inteligentes 202 asociadas con el sistema 100, de manera que puede mantenerse de forma adecuada sobre una red interna para seguridad mejorada. Se entenderá que la funcionalidad del motor de seguridad 304 y el servidor de autorización 306 puede combinarse de forma adecuada o separarse de varias maneras sin separarnos del alcance de la presente invención.
Con referencia ahora a la figura 4, un servidor de cartera ejemplar 140 incluye una interfaz de red 402, un servidor de applet opcional 404 y una aplicación applet 406. La interfaz de red 402 es cualquier programa que facilita las comunicaciones en la red 102, tal como un servidor de Web. En varias formas de realización, la interfaz de red 402 está basada en el Servidor de Netscape Enterprise, disponible de Netscape Corporation of Mountain View, California. El servidor applet opcional 404 proporciona la funcionalidad del servidor para los programas distribuidos, tales como programas Java o controles ActiveX. Un servidor applet ejemplar es el Servidor Java Applet disponible de Sun Microsystems of Mountain View, California. El servidor Applet 404 y la interfaz de red 402 proporciona funcionalidad de soporte para aplicación de cartera 406, que puede manipular la funcionalidad del registro, recuperar los datos de la cartera desde la base de datos de la cartera 408, y/o administrar transacciones como se describe aquí. En varias formas de realización de la invención, el servidor de la cartera 140 puede incluir el programa SERVERWALLET (a.k.a. NETWALLET) disponible de Globeset Corporation of Austin, Texas.
Las varias formas de realización de la invención pueden incluir una aplicación del activador que ayuda de forma adecuada a los consumidores con el proceso de compra de cartera. La aplicación del activador puede presentar información de estado, por ejemplo, o puede lanzar de forma activa el cliente de la cartera 214 (figura 2) cuando sea adecuado. Adicionalmente, el activador puede mantener una memoria cache local de sitios soportados por la cartera.
El programa de aplicación del activador puede ser ejecutado como una aplicación de ordenador convencional. En varias formas de realización, la aplicación del activador representa información como un icono de bandeja del sistema, como un "mapa binario flotante", o de cualquier otra manera adecuada. Las representaciones gráficas (por ejemplo, iconos) pueden indicar la información de estado, tal como "navegación en un sitio adecuado", "navegación en una página de control soportada", "navegación en una página de pago soportada", "ventanas de navegador no abiertas", "navegación en una página no soportada", y/o similares.
Un mapa binario flotante puede ser ejecutado con cualquier fichero o formato gráfico, por ejemplo, fichero de formato de intercambio de gráficos (GIF). Las formas de realización alternativas, presentan información en formato gráfico, audio, visual, audiovisual, multimedia, animado u otros formatos. Además, los ficheros GIL pueden ser sustituidos con ficheros LZW, ficheros TIFF, ficheros GIF animados, ficheros JPEG, ficheros MPEG, o cualquier otro tipo de formato o fichero gráfico, audio o multimedia.
Preferentemente, la presente invención es mejorada proporcionando una herramienta de transacción que permita a un usuario utilizar de forma más fácil la herramienta de transacción. La herramienta de transacción puede utilizarse para varias transacciones electrónicas. Por ejemplo, transacciones de compra, transacciones de asesoramiento financiero, transacciones de seguros, transacciones de consumidor a consumidor, tales como transacciones de trueque, transacciones relacionadas con ofertas y recompensas, etc. La herramienta de transacción descrita aquí detalladamente es una cartera digital utilizada para las transacciones de compra electrónica. La cartera digital es mejorada proporcionando una ventana con controles para el cliente para utilizar de forma más fácil la cartera. Preferentemente, la presente invención incluye una ejecución del lado del cliente para acceder a la funcionalidad de la cartera digital ("activador") y una barra de herramientas del lado del servidor, que permite al usuario realizar una pequeña descarga del activador y utilizar uno o más elementos de control de la interfaz del Usuario del Sistema Operativo, por ejemplo, un icono de bandeja de sistema de Microsoft Windows.
El activador es código objeto que se mueve sobre el ordenador del usuario y contiene rutas para acceso del servidor de la cartera. El activador puede generar eventos y el activador contiene la lógica de procedimiento que permite la comunicación con el servidor de la cartera en respuesta al usuario específico y a las acciones o eventos del sistema. Preferentemente, el activador presenta un solo elemento gráfico, por ejemplo, un icono que en la forma de realización de Microsoft Windows aparece como un icono de bandeja del sistema Windows, y el cual permite al usuario activar la apariencia de la barra de herramientas de la cartera. En varias formas de realización, la barra de herramientas de la cartera es, en efecto, una ventana de navegador especial, que accede al servidor de cartera. El activador se comunica con el servidor de cartera para automatizar la actualización del código de objeto del activador, a través de una pequeña descarga. Preferentemente, el usuario es consultado para una confirmación antes de realizar la descarga del activador. En varias formas de realización, el activador comunica con las aplicaciones distintas a la cartera, por ejemplo, ofertas de premios.
El sistema proporciona el contenido de las opciones relevantes sobre cada una de sus páginas web, a saber, información dinámica y contextual que es específica de cada página vista por el usuario. Esto se alcanza por el activador que supervisa las URL y se conmuta potencialmente en páginas de forma que el usuario puede ser consciente de oportunidades potenciales. Por ejemplo, el activador puede comprobar si el usuario está viendo un sitio de comercio y presentar las ofertas aplicables (por ejemplo, descuentos en las mercancías, etc.) al usuario. El activador puede supervisar también versiones de software en el sistema del usuario e informar al usuario de posibles versiones mejoradas. En una forma de realización ejemplar, el sistema es ejecutado sobre cualquier red, tal como una WAN, LAN, Internet, o cualquier ordenador personal, dispositivo electrónico inalámbrico o cualquier otro dispositivo similar. El sistema puede ejecutarse sobre un sistema operativo, por ejemplo, Microsoft Windows, Mac OS; Linux, Windows CE, Palm OS, y otros.
El activador, que es ejecutado preferentemente en el lado del cliente, permite al usuario 110 tener una comunicación constante o intermitente con el emisor de la cartera digital 140, por ejemplo, American Express, sin tener que tener espacio de toma de ventanas intrusivo en la pantalla del usuario. Como se describe anteriormente, esto permite que el emisor de la cartera supervise y presente los posibles objetos de interés para el usuario en instantes de tiempo adecuados. Los controles configurables presentados en la ventana permiten al cliente navegar rápidamente hasta los sitios de Web deseados, e invocar inmediatamente la funcionalidad deseada, tal como registro de la tarjeta de compra digital. Preferentemente, la barra de herramientas del cliente puede ser una ventana discreta que se asocia con la ventana del navegador del usuario, y mantiene la geometría que la hace efectivamente parte del navegador del usuario. Aunque cuando el usuario pincha sobre sus controles, la ventana permanece en su estado original, a saber, la ventana se dirige a la ventana del navegador para visitar las URL deseadas e invocar las acciones específicas (tales como, uso de la cartera digital). Por ejemplo, después de seleccionar un icono de la cartera digital procedente de la bandeja del sistema, la barra de herramientas de la cartera digital 502 es representada como una ventana discreta que está asociada con la ventana del navegador del usuario 500 como se muestra en la figura 5. En una forma de realización alternativa, la barra de herramientas del cliente que encuadra la ventana de la cartera existente, proporcionando los controles adicionales como se describe anteriormente en una extensión del área de ventana que está prevista por una cartera existente. En otra forma de realización alternativa, el área es dividida en la ventana del navegador estándar del usuario para crear un área que puede ser utilizada para la cartera y los otros controles descritos anteriormente.
El sistema proporciona preferentemente un modo conveniente para clientes no solamente para visitar sus URL favoritas, sino también para invocar a la funcionalidad específica que podrían incurrir de otro modo muchas etapas, y que podrían cambiar a medida que se actualizan continuamente los sitios de los vendedores. El sistema proporciona también una experiencia de usuario más simple formando sitios de cartera y de comercio-e no solamente más fáciles de utilizar, sino haciendo fácil de encontrar la barra de herramientas de la cartera y la barra de herramientas del cliente. Cuando un usuario tiene muchas ventanas diferentes abiertas, puede ser difícil y molesto encontrar la ventana de cartera, especialmente a medida que las diferentes ventanas del navegador configuran GUI durante el curso de la navegación e interacción normal con sitios. Como tal, el uso del icono de la bandeja del sistema y la funcionalidad del lado del servidor proporciona una experiencia superior al usuario. En una forma de realización preferida, el sistema presente trabaja con cualquier navegador conocido en la técnica, tal como Nestscape Navigator.
Aunque los sistemas de la técnica anterior pueden proporcionar simplemente un portal adaptable (por ejemplo, MyAmericanExpress.com), que permita al usuario visitar la página y, después, atravesar los enlaces desde esta página, una forma de realización ejemplar de la presente invención proporciona de forma adecuada una ventana con controles que se colocará sobre el escritorio del usuario a medida que navega a lo largo de la Web. Adicionalmente, la barra de herramientas del cliente proporciona medios de automatización de acciones para el usuario, donde estas acciones tienen lugar en sitios de comercio-electrónico de terceras partes. Además, los sistemas de la técnica anterior utilizan una ventana de navegador separada para hacer controles de la cartera, pero la presente invención utiliza una ventana de navegador estándar que ha sido dividida para proporcionar un área a ocupar por la cartera. Por ejemplo, en una forma de realización preferida, un icono de cartera digital está disponible al usuario como un icono de bandeja del sistema (no mostrado). Después de invocar al icono de la cartera digital, la barra de herramientas de la cartera digital 502 es representada como se muestra en la figura 5. La barra de herramientas de la cartera digital no es llamativa, al mismo tiempo que incluye controles que permiten al usuario utilizar la cartera digital. Preferentemente, la barra de herramientas 502 está asociada con la ventana del navegador 500.
Como se muestra en la figura 6, si el usuario selecciona un botón de directorio de compras desde la barra de herramientas 502, la barra de herramientas se expande hasta una página de directorio de compras 602. El usuario puede seleccionar un comerciante de la lista de comerciantes 604 representada en la página de directorio de compras 602. Después de seleccionar un comerciante de la lista de comerciantes 604, la cartera digital llega al usuario hasta el sitio del comerciante seleccionado 702, tal como se muestra en la figura 7. Preferentemente, cuando la cartera digital toma a un usuario hasta un sitio del comerciante 702, la barra de herramientas 502 retorna a su tamaño normal.
Cuando el usuario realiza una compra desde un comerciante, por ejemplo, colocando objetos en una tarjeta de compra y procediendo a su verificación en el sitio del comerciante, la función de verificación es realizada, en parte, por la cartera digital de la presente invención. Como se muestra en la figura 8, cuando el usuario indica una compra deseada en un sitio de comerciante 702, se representa la interfaz de usuario de verificación 802 de la cartera digital. Por ejemplo, la pantalla de verificación 802 aparece en un lado de la ventana del navegador, mientras que la ventana del comerciante 702 está todavía representada sobre el lado opuesto de la ventana del navegador. La mayoría de la información que un usuario tendría que introducir en la verificación del comerciante (por ejemplo, nombre, dirección, dirección de e-mail, información de tarjeta de crédito, etc.) es conocida ya por la cartera digital y es pre-rellenada en la ventana de verificación de la cartera digital 802. En una forma de realización preferida, el usuario puede editar la información pre-rellenada.
Preferentemente, el presente sistema incluye también métodos y aparatos que facilitan un número fiable de formularios de HTML sobre los sitios de la Web. El resultado final es que los usuarios pueden identificar el contenido de la información que desean proporcionar a los sitios de una manera general, independiente de la apariencia real, etiquetado, y comportamientos de varios sitos de Web de comercio electrónico. Preferentemente, la presente invención incluye un componente de "de memoria automática" que permite al usuario capturar los datos que ha introducido y un componente de "relleno de formulario" que incluye un conjunto potente de procesos que resultan de la combinación de diferentes modelos de sitios y usuarios.
La presente invención recoge información de los usuarios almacenándola de forma segura y fiable en un servidor, y después, la proporciona a los campos de formulario adecuado bajo la dirección el usuario. El sistema mantiene los mapas de la información del usuario con los varios campos de formulario de HTML de sitios que son de interés para el usuario. Esta información puede estar dirigida entonces a cómo rellenar los formularios HTML (o pre-relleno) para usuarios que desean interactuar con estos sitios.
Con respecto a la característica de "memoria automática", las carteras digitales de la técnica anterior pueden ejecutar una función de memoria automática, pero debe iniciarse por el usuario. Con la característica presente de "memoria automática", los usuarios de cartera digital no necesitan pinchar un botón para recordar el formulario que acaban de rellenar, puesto que el presente sistema recuerda los campos que el usuario está presentando sobre una ventana del comerciante. Cuando se presenta un formulario (por ejemplo, pulsando el botón de "Presentación", o un botón "Compra"), la cartera en línea responde determinando si la ventana que activa la presentación del formulario es una ventana de interés del comerciante. Si es así, la cartera recuerda de forma adecuada los datos; de otro modo, la cartera puede desconsiderar el caso de la presentación del formulario y continuar funcionando normal. Los controles de la cartera digital pueden incluir un botón con etiqueta "recordar" o puede soportar una característica de recordatorio automática que está siempre activa. En general, pueden recordarse los campos distintos a estos que son automáticamente conocidos por la cartera. En este contexto, el recordatorio de medios de campo que cuando un usuario introduce datos en un campo específico, el valor será memorizado en el sistema. El componente de la cartera detectará los valores del campo introducidos de este modo, y los transmitirá de forma segura a un servidor a través de Internet. Cuando un usuario se dirige a continuación a esta página, la cartera, además de rellenar el formulario con campos que son recuperados del sistema de cartera, conocerá también el formulario con valores que han sido recordados previamente. Cuando se procesa el formulario (pre-rellenado), la cartera recuperará de forma segura los valores de campo desde el servidor.
Más particularmente, con respecto al navegador Explorer de internet, la invención ejecuta adecuadamente un control ActiveX que se fija el mismo a una página Web, tal como, por ejemplo, the American Express Online Wallet. En una forma de realización preferida, el control ActiveX contiene un método que captura los eventos del navegador de todos los navegadores de Internet Explorer, de forma que la Cartera en línea de American Express puede responder a estos eventos, si es necesario por una función JavaScript cargada dentro de la Carta en línea de American Express, permitiendo así al sistema obtener el documento descargado completamente dentro de un navegador de Internet Explorer. Específicamente, esto permite que el sistema capture el evento de "Documento Completo" surgido por el navegador Internet Explorer que especifica cuando un documento ha finalizado su carga. Cuando este evento es capturado, el control de ActiveX notifica a la Cartera en línea American Express mediante llamada a la función de JavaScript cargada dentro de la Cartera en línea de American Express. Esta función responde a este evento comunicando de forma adecuada con el control de ActiveX para capturar los eventos de "Presentación Formulario" para todos los formularios sobre todos los navegadores de Internet Explorer.
Cuando un usuario rellena un formulario en una página Web, y pincha el botón "Presentar" (es decir, cualquier control, tal como un botón que presente un formulario), para esta página, la Cartera en línea de American Express es notificada por la llamada de control de Active X una función de JavaScript cargada dentro de la Cartera En Línea de American Express. La Cartera En Línea de American Express determina entonces de forma adecuada si el documento que surge del evento de "Presentación" es de interés, registrando la URL de la ventana que ha dado lugar al evento. Si el evento debe ser manipulado, la Cartera En Línea de American Express debe llamar a una función adecuada dentro del control ActiveX que obtiene el modelo del objeto del documento (DOM) que emitió el evento. El DOM puede ser atravesado y los valores del formulario pueden ser salvados de forma que puedan ser enviados al servidor para almacenarse en la memoria. En una forma de realización preferida, el control de ActiveX debe separarse adecuadamente de la captura de eventos del navegador y formar eventos de "Presentación", de manera que se reduzcan al mínimo los errores de tiempo de ejecución.
Con respecto al navegador de Netscape, debido a la ejecución de eventos de Netscape, el sistema captura el evento desde el interior de Javascript solo. Si el sistema obtiene con éxito el privilegio de "Escritura de Navegador Universal", (es decir, concedido por el usuario), el sistema puede llamar con éxito a una función que permita a una ventana externa capturar eventos de otra ventana. El sistema puede atravesar entonces el modelo objeto del documento para todos los cuadros de esta ventana. Cuando se hace así, el sistema notifica a cada formulario de la ventana que el sistema quiere capturar el evento "Presentación". Como tal, cuando un usuario rellena un formulario sobre la ventana que el sistema notificó y pincha el botón "Presentación", (es decir, cualquier control tal como un botón, que presenta un formulario) para esta página, la cartera en línea es notificada y responde de forma adecuada. Un técnico en la materia apreciará que la presente invención puede ser ejecutada en cualquier sistema de transacción adecuado, incluyendo, pero sin limitarse a ningún sistema de cartera digital adecuado.
Con respecto a la función de relleno de formulario, la cartera digital, tal como, por ejemplo, la Cartera En Línea American Express, proporciona una funcionalidad de relleno de formulario par ayudar a los usuarios a rellenar formularios. Los sistemas de la técnica anterior, tales como el sistema previsto por GlobeSet, Inc, utiliza típicamente un Objeto de Asistente del Navegador (BHO). El método BHO incluye con frecuencia inconvenientes tales como, por ejemplo, el navegador Internet Explorer 5.0 tiene un error donde cargará solamente el primer BHO especificado en el registro. Éste es un problema para cualquier aplicación puesto que no puede asegurar si su BHO está cargado o no. Además, un BHO es cargado para cada caso de Internet Explorer de forma que los casos múltiples de un BHO podrían ejecutarse en cualquier tiempo dado - comiéndose por tanto la memoria y haciendo lenta la navegación para todos los navegadores hacia solamente uno de interés.
La presente invención sustituye preferentemente la solución de BHO utilizando el mismo control de ActiveX como se especifica en la característica de "memoria automática". Fijando el control ActiveX sobre la página de la Web de Cartera En Línea, el sistema obtiene de forma adecuada el modelo objeto del documento para cualquier documento cargado dentro de cualquier navegador de Explorer de Internet dado utilizando, por ejemplo, the Shell Windows API. Cuando un usuario pincha un botón de "Rellenar Formulario" en la Cartera En Línea, la cartera puede responder obteniendo, en primer lugar, el modelo del objeto del documento a través del control Active X. A continuación, la cartera puede salvar los nombres de los campos que forman los formularios y los envía a un motor heurístico sobre el servidor. El servidor responderá a esta solicitud retornando los valores que deberían utilizarse para rellenar estos campos. Los campos pueden ser rellenados entonces utilizando el mismo modelo objeto del documento obtenido previamente. Como tal, la presente invención reduce el problema de tener que introducir datos repetitivos en los formularios en los sitios de la Web. Además de ahorrar esfuerzo por parte de los clientes, se incrementa la exactitud de los datos introducidos.
Más particularmente, la arquitectura de la presente invención combina un modelo del lado del servidor de cada sitio (por ejemplo, campos, páginas, enlaces, etc.) modelo del lado del servidor del usuario (por ejemplo, perfil), modelo del sitio generado por el usuario (por ejemplo, registro macro, etiquetado, arrastrar y colgar) modelo del sitio generalmente manualmente por el sistema (por ejemplo, aumentar y validar los modelos generados por el usuario), y modelo del sitio generado heurísticamente (por ejemplo, inferencia de información semántica sobre campos, acciones, etc.). El presente sistema crea y memoriza varios tipos distintos de modelos. El primero caracteriza el sitio, por ejemplo, cómo registrarse, cómo añadir algo a una tarjeta de compra, cómo buscar un tipo de producto, cómo introducir preferencias (por ejemplo, viajes), etc. El segundo modelo caracteriza al usuario, por ejemplo, cuáles son las cosas que el usuario puede hacer y cuáles son los atributos de perfil de un usuario. Combinando estos dos modelos, el presente sistema crea procesos especiales que añaden una gran flexibilidad y potencia. El sistema se corresponde desde el modelo de qué puede hacer el usuario, hasta el modelo del sitio, donde los modelos de sitio son generados por cualquier método conocido. Como tal, el modelo del sitio puede crearse por el usuario, por el ordenador central, por la compañía de la tarjeta de transacción (emisor) o incluso por el proveedor del sitio. En una forma de realización preferida, ECML/XML puede utilizarse para representar los modelos para el sitio. En varias formas de realización, los modelos del sitio pueden intercambiarse con otros sistemas.
Por ejemplo, un usuario puede visitar de forma rutinaria sitios de diferentes líneas aéreas y servicios de viajes con el fin de comprar billetes de avión. Cada sitio tiene típicamente campos de diferentes pantallas para recoger información, que son relativamente similares entre los varios sitios. No obstante, cada sitio utilizará diferentes campos de formulario HTML que son colocados sobre diferentes URL, y que pueden cambiar también con el tiempo. Incluso aunque la información es de naturaleza muy similar a través de los diferentes sitios, no existe actualmente un mecanismo común para automatizar el proceso de rellenar campos para las preferencias de viajes de los usuarios (por ejemplo, estancias, comidas, horarios del viaje, premios de afinidad, etc.). Cada sitio puede tener su propio perfil del usuario que memoriza mucha de esta información. No obstante, el usuario necesitaría crear un perfil de este tipo para cada sitio, independientemente, dada la práctica actual.
La presente invención incluye reconocimiento del campo basado en heurística. En este método, las etiquetas del campo son identificadas por su proximidad espacial para formar campos de interés. Una combinación de las etiquetas del campo y los atributos del HTML del campo del formulario (más notablemente, atributo "nombre" de la HTML, elementos de "entrada" y "seleccionar", "acción") se utilizarán como la entrada a un motor heurístico que contiene un diccionario como ayuda a la identificación de campos deseados.
En otra forma de realización, la presente invención incluye reconocimiento del campo mediado por el usuario. En este método, el usuario captura de forma intencionada la entrada a través de un botón de "Recordatorio" o control similar que permite a los servidores capturar información sobre la secuencia de acciones que ejecuta el usuario. Cuando el usuario hace esto, puede "reproducir" efectivamente las acciones (similar a una escritura macro empleada en otros sistemas de software). Como tal, las acciones del usuario pueden ser alimentadas en el motor heurístico y alimentarse también directamente dentro de las tablas del mapa del campo que se utilizan por los procesos del motor.
En una forma de realización preferida, los dos métodos anteriores pueden necesitar cierta interacción con el fin de crear completamente mapas del proceso y formar mapas de campo que describan de forma exacta la navegación y formen posibilidades de terminación del campo que permitan esta invención. Cuando sea necesario, analistas humanos actuarán de una forma similar a lo que se produce durante un reconocimiento de campo mediado por el usuario, aunque proporcionarán mucha más información sobre su navegación y procesos de relleno de formulario que lo haría un usuario típico. En todos los casos, la información que es acumulada es utilizada para crear un mapa del proceso (o mapa del sitio detallado) que describa la secuencia de acciones (relleno de formulario, HTTP Host, HTTP Get, etc.) por las que pueden producirse varias actividades. Un mapa de campo se generará también para cada una de las páginas Web en el mapa del proceso, donde el mapa del campo define los nombres exactos de los campos que pueden ser utilizados para automatizar la presentación del formulario. Pueden requerirse también mapas de estado para seguir los estados de los usuarios a medida que interactúan con el sitio Web (el estado del usuario, tal como los registrados frente a los no registrados, modificarán los resultados de las acciones específicas en el sitio).
En una forma de realización preferida, el proceso por el que el usuario interactúa puede ser o bien completamente automático (en cuyo caso el usuario transmite solamente el deseo de realizar una acción escrita), o puede ser mediado por el usuario (en cuyo caso la invención puede rellenar previamente campos de formulario para el usuario, ofreciendo así al usuario la oportunidad de corregir, cambiar o completar cualquiera de los campos que requieren entrada de datos adicionales). Adicionalmente, los productos y servicios descritos anteriormente, la tecnología de activación en el formulario del proceso y mapas del campo pueden ser ventajosos para nuevos productos y servicios, tales como permitir a las compañías automatizar la entrada de datos del formulario para sus visitantes del sitio. Por ejemplo, si una compañía compila procesos y mapas de campo para beneficio de sus propios clientes (por cualquiera de los medios descritos anteriormente), entonces la compañía puede autorizar también esta información, servicios y productos a terceros clientes. Los sitios para los que existen estos mapas pueden utilizar también la presente invención, de forma que los sitios se benefician suministrando un servidor similar a sus clientes que no se están beneficiando del sistema. Los procesos subyacentes por sí mismos se basarán también en un sistema que adquiere esta información y la reformatea, por ejemplo, como XML y ECML. Estas representaciones estándar deberían formar la base del intercambio de información para los dos últimos productos/servicios.
Con referencia ahora a la figura 9, un proceso 900 ejecutado por un programa activador ejemplar incluye de forma adecuada la inicialización de la aplicación (etapa 902), supervisión del localizador de recursos uniforme (URL) a medida que el usuario navega o compra en línea (etapa 904), determinando si el usuario está navegando en un sitio soportado (etapa 906), determinado el tipo de sitio soportado (etapas 908 y 912) y respondiendo de forma adecuada en las etapas de procesamiento 910 y 914 (respectivamente). Otras características (tales como cupones, ofertas especiales, supervisión, seguridad y similares) pueden ser ejecutadas en la etapa 916.
La etapa de inicialización 902 implica adecuadamente abertura de la aplicación del activador y la inicialización de la aplicación como sea adecuado. La aplicación del activador puede ser iniciada en respuesta al arranque del sistema, conexión a una red (tal como Internet o una LAN), o inicialización de un navegador (tal como Internet Explorer, disponible de Microsoft Corporation of Redmond, Washington o Netscape Explorer, disponible de Netscape Corporation of Mountain View, California). En varias formas de realización, la aplicación del activador puede ponerse en contacto con el servidor de la cartera 140 (figura 1), la aplicación de la cartera 406 (figura 4) u otro servidor en la red 102. La aplicación del activador se pone en contacto de forma adecuada con el servidor remoto para obtener información tal como una lista de sitios Web, nombres de dominio, o URL que están soportadas por la cartera. Esta información puede obtenerse sobre una base regular (por ejemplo, diaria, semanal, mensual o en cada inicialización de la aplicación del agente) o cuando se llama por la aplicación del activador o el servidor. En varias formas de realización, la aplicación del activador almacena la lista de URL soportada en una memoria cache o fichero sobre una unidad local o en una memoria en el ordenador del cliente.
A medida que el usuario navega en Internet u otra red de datos 102, la aplicación del activador supervisa de forma adecuada la localización del usuario sobre la red. Un método de supervisión de la navegación del usuario es supervisar la URL utilizada por el navegador del usuario. En tales formas de realización, la aplicación del activador obtiene la presente URL desde el navegador de usuario (o desde la interfaz de red del sistema como sea adecuado), y compara (etapa 906) la presente URL con respecto a la lista de URL soportadas obtenidas desde el servidor remoto en la etapa de inicialización 902. Estas comparaciones se muestran en etapas separadas lógicamente 906, 908, 912 y 916 en la Figura 9, aunque estas etapas podrían utilizarse combinadas o separadas de cualquier modo sin separarnos del ámbito de la invención. Por ejemplo, aunque la figura 9 muestra que se están ejecutando comparaciones múltiples, puede ser suficiente una sola comparación de cada URL presente contra la lista de URL soportadas en ciertas formas de realización.
Si la URL presente se corresponde con una URL soportada, la aplicación del activador responde adecuadamente. Por ejemplo, si la URL presente es una página de verificación soportada (sí, en la etapa 908), la aplicación del activador ejecuta un proceso de verificación (etapa 910). El proceso de verificación puede incluir notificar al usuario que la página de verificación es soportada a través de un mensaje que salta, o por la representación de un icono particular en la bandeja del sistema o en la ventana flotante. Si la aplicación del cliente de la cartera 214 no está abierta ya, la aplicación del activador puede presentar una casilla de diálogo u otro mensaje guía al usuario que indique la página está soportada por la aplicación de la cartera 214. El mensaje guía puede proporcionar también un botón u otro mecanismo por el que el usuario pueda abrir la aplicación de la cartera 214.
Si la URL presente se corresponde con una página de pago soportada (sí, en la página 912), la aplicación del activador puede proporcionar instrucciones de pago a la aplicación de la cartera, o de otro modo control de paso a la aplicación de la cartera(etapa 914). Los mensajes enviados entre la aplicación del activador, la aplicación de la cartera, el navegador, y similares, pueden enviarse por los mensajes de Escritorio Abierto, mensajes de Enlace de Objeto e Intercalación (OLE), llamadas de ruta de objeto, llamadas OS, o similares.
En las varias formas de realización, la funcionalidad descrita anteriormente es alcanzada utilizando tipos como se describe a continuación. Los tipos son utilizados para detectar un contexto válido de usuario. Si se detecta un contexto válido de usuario, el activador, o bien lanzará una aplicación de servidor o alcanzar una barra de herramientas de servidor que permita al usuario lanzar otras aplicaciones. Por ejemplo, un navegador de usuario podría tener varios tipos que signifiquen la capacidad para comprar a través de o bien un pago privado o un producto específico de tarjeta. El activador puede lanzar una barra de herramientas que permita al usuario seleccionar un instrumento de pago deseado (por ejemplo, pagos privados o una tarjeta en la cartera digital del usuario). Se apreciará que las aplicaciones disponibles no están todas relacionadas necesariamente con una transacción de compra. En varias formas de realización, la información del contexto está memorizada tanto sobre un servidor como en tipos asociadas con el navegador. Por ejemplo, los tipos podrían actuar como una clave por la que puede recuperarse la información del contexto desde el usuario.
Puede incorporarse también otra funcionalidad (etapa 916) en la aplicación del activador. Por ejemplo, podrían ejecutarse los mecanismos de seguridad (tal como estos descritos anteriormente y a continuación), las funciones de supervisión del cliente, cupones, ofertas especiales, y similares. En el caso de cupones o de ofertas especiales, el activador podría detectar la URL presente como correspondiente a un producto particular o página Web. Cuando el usuario "surfea" o navega hasta la URL soportada, la aplicación del activador notifica la coincidencia y presenta al usuario (a través de una ventana de diálogo, o a través del navegador, o similar) una oferta especial, tal como una oportunidad de compra de un producto particular o recibe un descuento especial sobre una compra. Se apreciará que podrían incorporarse otra funcionalidad en la aplicación del activador sin separarnos del ámbito de la presente aplicación.
En varias formas de realización de la invención, el cliente de la cartera 214 (figura 2) es rellenado previamente con información que es específica para el usuario/cliente particular. Con referencia a la figura 1, un usuario puede aplicar para una cartera digital poniendo en contacto un servidor de Web, tal como un servidor de cartera 140 sobre la red 102. El usuario completa un formulario de registro (que puede generarse con scripts CGI, por ejemplo) a aplicar en la cartera. El servidor de la cartera 140 recibe de forma adecuada información demográfica, recuento y otra información (por ejemplo, dirección, dirección de envío, nombre, número de la tarjeta de crédito, y similares) desde el servidor de autentificación 306 (Figura 3) u otro servidor en una red privada. Esta información puede utilizarse para configurar un cliente de cartera 214 (Figura 2) que es único para el usuario particular. Un método de configuración del cliente de cartera 214 es crear un fichero de configuración que esté asociado con el cliente 204 y que sea leído por el cliente 214 para obtener la información de la cartera como se describe anteriormente.
Preferentemente, la información del registro incluye también información del lector de tarjeta que incluye si el puerto del lector de tarjeta debiese ser en serio o puerto USB. Si se aprueba la aplicación de la cartera, un lector de tarjeta puede ser enviado o previsto de otro modo al usuario, y un código especial (tal como una tecla criptográfica, o una palabra de paso, o cualquier otro tipo de código electrónico o formulario) está previsto también para el usuario. El usuario registra entonces para servicio de cartera en línea por el contacto electrónico del servido de cartera 140 y la autentificación al servidor con la tarjeta y/o con el código especial. Después de proporcionar el código especial, el usuario recibe una copia configurada especialmente del software de la cartera, que puede instalarse en el ordenador del cliente 110, como sea adecuada. El procedimiento de relleno previo de la cartera puede utilizarse con cualquier tarjeta de crédito o tarjeta de cargo asociando simplemente una versión del programa de la cartera con un código especial. La información de configuración para un usuario particular está asociada con un código que está previsto para el usuario, que puede presentar después el código especial para autentificarlo con el servidor de la cartera 140 para obtener una copia de la cartera que se ha pre-configurado ya con los datos específicos al usuario particular.
Con referencia principal ahora a la figura 1, y 10, el cliente 110 inicia adecuadamente una transacción por registro en el servidor de cartera 140 utilizando tarjeta inteligente 202. Para registrar el servidor de cartera 140, el cliente 110 puede conectarse en primer lugar al servidor de seguridad 130 a través del navegador 216. El usuario selecciona un localizador de recursos uniforme particular (URL) para la marca de registro a través de una marca de libro, un procedimiento abreviado de Internet, un hiperenlace, o cualquier otra técnica adecuada. El servidor de seguridad 130 puede retornar entonces una página de registro a través de la interfaz de la red 302. En varias formas de realización, una entrada de formulario y botón de presentación para usuario/registro de palabra de paso y un enlace de hipertexto para registro de tarjeta inteligente están previstos como parte de la página de registro. El usuario selecciona el registro de la tarjeta inteligente, y el navegador 216 responde de forma adecuada dirigiendo el registro sobre el mensaje solicitado 1002 (Figura 10). El servidor de seguridad 130 recibe la solicitud de registro 1002 e inicia el proceso de registro de tarjeta inteligente como sea adecuado. En varias formas de realización, el servidor de seguridad 130 formatea una pregunta criptográfica por el servidor de autorización 305 o el motor de seguridad 304 en respuesta al mensaje de solicitud del registro 1002. La pregunta criptográfica 1004 es cualquier tipo de mensaje de pregunta que previene los ataques de reproducción (por ejemplo, mensajes fraudulentos creados para el re-envío de paquetes de autentificación enviados previamente), tales como una pregunta que está basada en los datos aleatorios y está diseñada para solicitar una respuesta desde la aplicación X.509 memorizada sobre la tarjeta inteligente 202. La pregunta es prevista entonces de forma adecuada al cliente 110 a través de la red 102 como mensaje de pregunta 1004.
Después de la recepción del mensaje de pregunta 1004, el navegador 216 pasa de forma adecuada el mensaje 1004 al cliente 214 para procesar con la tarjeta inteligente 202. Si el cliente de la cartera 214 no está en funcionamiento, el navegador 216 puede abrir automáticamente el programa. El cliente de la cartera 214 prepara entonces la respuesta de firma, como sea adecuado. Por ejemplo, el cliente de la cartera 214 puede extraer la información de pregunta del servidor, formatear una nueva pregunta del cliente (es decir, una segunda pregunta criptográfica para la tarjeta inteligente 202), combinar ambas preguntas en una pregunta doble, y computarizar una información no significativa de la doble pregunta para uso final, por ejemplo, en un bloque criptográfico de Sistema Criptográfico de Clave Pública (PKCS1). La información no significativa puede ser calculada de acuerdo con cualquier algoritmo, tal como MD3 ó MD4, por ejemplo, y es utilizada de forma adecuada para garantizar la terminación y exactitud de los datos en el bloque de preguntas dobles. Se entenderá que el PKCS1 es una norma de criptografía de clave pública que define mecanismos para el cifrado y firma de datos utilizando los criptosistemas de clave pública RSA. La norma PKCS es definida completamente en PKCS #1: RSA Crytography Specifications Version 2.0, de fecha Septiembre de 1998 (disponible en línea de http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-1html),
El bloque PKCS es previsto de forma adecuada a la tarjeta inteligente 202 a través del lector 204 para procesamiento (etapa 1006 en la figura 10). En varias formas de realización, el lector de tarjeta 204 interactúa con el ordenador del cliente 110 para indicar al usuario un identificador personal, por ejemplo, un número de identificación personal (PIN) u otro identificador único, para acceder a la tarjeta. En una forma de realización preferida, un PIN es memorizado en la tarjeta inteligente 202. Alternativamente, un PIN u otro identificador personal puede memorizarse en cualquier parte del sistema, por ejemplo, en el lector 204 o el ordenador del cliente 110. El usuario introduce de forma adecuada al identificador personal como sea adecuado para desbloquear la tarjeta inteligente 202, que recibe el bloque de pregunta doble desde el cliente de la cartera 214 y firma digitalmente el bloque según sea adecuado. En varias formas de realización, la tarjeta inteligente 202 contiene una clave privada que es utilizada para computarizar una firma digital del bloque. El bloque firmado es retorno entonces al cliente de la cartera 214, como sea adecuado. En varias formas de realización, la tarjeta inteligente 202 proporciona también un certificado (tal como un certificado X.509) que corresponde con la clave privada utilizada para calcular la firma digital.
Después de recibir la firma y el certificado desde la tarjeta inteligente 202, el cliente de la cartera 214 crea de forma adecuada un mensaje de respuesta adecuado 1008 que debe ser enviado al servidor de seguridad 130. Aunque el mensaje de respuesta 1008 puede estar en cualquier formato, varias formas de realización formatean el mensaje de respuesta 1008 como un mensaje PKCS7 definido en PKCS #7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note, Versión 1.5, Revisado el 1 de Noviembre de 1993, disponible en línea de ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-7.doc
Después de recibir el mensaje de respuesta 1008, el servidor de seguridad 130 procesa el mensaje según sea adecuado (etapa 1010 en la figura 10). En varias formas de realización, el mensaje de respuesta 1008 está encaminado al servidor de autorización 306, que verifica el certificado y la firma previstos por la tarjeta inteligente 202. Después de la verificación con éxito del certificación y validación de la firma, en varias formas de realización puede generarse una ficha de seguridad y retornarse al cliente 110 o tarjeta inteligente 202.
De esta manera, una presentación posterior de la ficha de Seguridad proporciona medios para que el usuario establezca la identidad e interactúe de forma segura con el servidor de la cartera. En varias formas de realización, el servidor de autorización 306 puede crear también una ficha de seguridad adicional que identifica al usuario. En varias formas de realización, esta ficha puede constar de múltiples porciones que pueden corresponderse entonces con un certificado digital adecuado, tarjeta inteligente, u otros datos, posiblemente, utilizando datos en base de datos 310. En varias formas de realización, la ficha de seguridad adicional y/o las porciones puede proporcionarse al cliente 110 en unión con el mensaje de redirección 1012. En varias formas de realización, la ficha de seguridad adicional puede estar prevista al cliente o mantenerse sobre el servidor de autorización 306.
Después de la recepción del mensaje de redirección 1012, el cliente 110 puede ponerse en contacto de forma adecuada con el servidor de la cartera 140 para solicitar una conexión. En varias formas de realización, el mensaje de "Conectar Solicitud" 1014 incluye de modo adecuado la ficha de seguridad y posiblemente, la ficha de seguridad adicional en su totalidad o parte por parte del mensaje de redirección 1012. El servidor de la cartera 140 consulta al servidor de seguridad 130 el utilizar cierta combinación de fichas de seguridad en conjunto o por partes para obtener la identificación del cliente 110. La consulta 1016 y la respuesta 1018 son transmitidas adecuadamente a través de la red 150, que, en algunas formas de realización, se mantiene separada de la red 102 para mejorar la seguridad del sistema 100. Una forma de realización alternativa emplea la red 102 que, en algunas formas de realización, ofrece seguridad mejorada por la Red Privada Virtual, protocolo SSL, uso de secretos compartidos, y/u otros medios criptográficos. Si las credenciales de retorno 1018 están en orden, el servidor de la cartera 140 recupera los atributos correspondientes al cliente 110 desde la base de datos de la cartera 408 y notifica al cliente 110 un mensaje vía registro 1020. Se apreciará que son posibles las formas de realización alternativas de una secuencia de registro. Se apreciará también cualquier tipo de esquemas de cifrado, formatos de mensaje y similares, podrían ser utilizados para ejecutar una secuencia de registro 1000.
Haciendo referencia ahora a la figura 11, un flujo ejemplar de autentificación 1100 adecuado para uso durante una transacción de compra comienza con un cliente 110 colocando una solicitud 1102 con el servidor de la cartera 140 para un caso (tal como una compra) para la que se requiere la autentificación. El servidor de la cartera 140 reconoce de forma adecuada el evento y presenta un mensaje de solicitud 1104 al servidor de seguridad 130, por ejemplo, a través de un canal de comunicación 150, para formatear un mensaje de pregunta. El servidor de autentificación 306 (o cierto otro componente del servidor de seguridad 130, como sea adecuado) formatea entonces el mensaje de pregunta 1106 (que puede incluir datos aleatorios) y proporciona el mensaje de pregunta 1106 al servidor de la cartera 140, por ejemplo, a través de la conexión 150. El servidor de la cartera 140 recibe el mensaje de pregunta 1106 y dirige los datos de pregunta hasta el navegador 216 como mensaje de solicitud de firma 1108. El navegador 216 abre el cliente de la cartera 214, si es necesario, y dirige el mensaje de solicitud de firma 1108. Como se describe anteriormente, el cliente de la cartera 214 formatea un bloque de solicitud de firma tal como un bloque PCKS1 que incluye una pregunta de servidor, una pregunta de cliente y una información con errores. El bloque de solicitud de firma resultante es previsto a la tarjeta inteligente 202 a través del lector 204. La tarjeta inteligente 202 firma de forma adecuada el bloque y proporciona una copia de su certificado X.509, como sea adecuado.
El bloque firmado puede ser retornado entonces al cliente de la cartera 214, que formatea adecuadamente un mensaje de respuesta de firma adecuado 1110 (tal como un mensaje PKCS7) y lo envía al servidor de cartera 140. El servidor de cartera 140 formula entonces el mensaje de control de validez 1112, que incluye los datos desde el mensaje de respuesta de firma 1110 y la ficha de seguridad asociada con el cliente 110 durante el proceso de registro (tal como el proceso de registro ejemplar mostrado en la figura 10). En las formas de realización alternativas, la ficha de seguridad prevista es recibida desde el cliente 110 como parte del mensaje de respuesta de firma 1110. El mensaje de verificación de validez 1112 es enviado al servidor de seguridad 130 a través de la conexión 150, como sea adecuado. El servidor de seguridad 130 puede encaminar entonces el mensaje de verificación de validez hasta el servidor de autorización 306, como es adecuado, que puede verificar la firma y recuperar la ficha de seguridad adecuada desde la base de datos 310 (etapa 1114 en la figura 11). La ficha de seguridad y/o el código de identificación único opcional recuperado de la base de datos es comparado entonces con la ficha de seguridad o los ID recibidos del servidor de cartera 140. Si los dos objetos (por ejemplo, fichas de seguridad o los ID) coinciden, puede deducirse que la tarjeta utilizada actualmente por el cliente 110 es la misma tarjeta utilizada por el cliente 110 en el momento del registro. Se envía entonces un mensaje de aprobación o de rechazo 1116 desde el servidor de seguridad 140, y se permite continuar la transacción.
En varias formas de realización, el servidor de la cartera 140 actúa como un poder por el cliente 110 durante las transacciones. Por ejemplo, el servidor de la cartera 140 completa los formularios de compra incluyendo la dirección de envío, número de tarjeta y similar, en nombre del usuario 110. El comerciante 120 puede autorizar entonces la transacción de compra como una transacción de tarjeta de cargo estándar utilizando hardware y software convencionales. No obstante, se conseguirá que la seguridad añadida proporcionada por los sistemas descritos aquí, permitirá una confidencia adecuada en la identidad del comprador, justificando, por tanto, un menor porcentaje de descuento para la transacción.
Varias formas de realización de la invención incorporan una protección añadida contra infracciones de seguridad. Debido a muchas funciones del lado del servidor incorporadas en el servidor de seguridad 130 o el servidor de la cartera 140, por ejemplo, pueden incorporar varios componentes de escritura escritos en lenguajes de escritura, tales como Javascript (como se define por Sun Microsystems of Moutain View, California), o VB-script (como se define por the Microsoft Corporation of Redmond, Washington), servidores acoplados a la red 102 pueden proporcionar funcionalidad variada a los múltiples clientes 110 a través de tales lenguajes de servidor proporcionando scripts (o código) desde el servidor al cliente. El código es interpretado, compilado o ejecutado de otro modo por el ordenador del cliente 110. En las formas de realización que incorporan Javascript, por ejemplo, los scripts son interpretados y ejecutados por un programa navegador (por ejemplo, Internet Explorer, Netscape Communicator o similar), que se ejecuta en el ordenador del cliente 110. Otras formas de realización incluyen otros navegadores sin PC, por ejemplo, teléfonos de Protocolo de Aplicación Inalámbrico (WAP) que soportan los scripts de Lenguaje de Marcación Inalámbrico (WML). Los varios lenguajes de escritura pueden contener instrucciones, objetos u otros mecanismos de datos para acceder a los ficheros sobre el disco duro del usuario, por ejemplo, o manipulando de otro modo los datos en el ordenador del usuario. Para prevenir que fuentes no autorizadas proporcionen código ejecutable al usuario, los lenguajes de escritura pueden incluir un mecanismo que permita al usuario aprobar los scripts previstos solamente desde las fuentes de confianza. Por ejemplo, un usuario que lleva a cabo una transacción electrónica, como se describe anteriormente, puede permitir scripts previstos desde el servidor de la cartera para ejecución, pero puede prevenir otros scripts previstos por otras fuentes se ejecuten sobre el ordenador del usuario.
Un problema de seguridad potencial encontrado con muchos lenguajes de escritura se muestra en la figura 12A. Un "pirata informático" sin escrúpulos puede crear un sitio Web 1204 que esté diseñado para realizar actividades maliciosas con respecto a los usuarios de un servidor de Web legítimo 1206. El sitio del pirata informático 1204 (mostrado como el "sitio criminal" en la figura) puede proporcionar, por ejemplo, una porción de código, tal como script, al usuario. El sitio criminal 1204 puede inducir también al navegador de Web del usuario 216 a solicitar un localizador de recursos uniforme, particular (URL) en servidor legítimo 1206 (tal como el servidor de la cartera 140, o cualquier otro servidor sobre la red 102). La URL de referencia puede ser manipulada de forma deliberada, tal que el servidor legítimo 1206, retorna, por ejemplo, un mensaje de error u otra respuesta al navegador del cliente 216. En varias formas de realización, la respuesta del servidor legítimo 1206 puede incluir automáticamente una porción o variación de la solicitud desde el navegador de la Web del usuario 216. Si esta respuesta incluye Javascript, VBscript u otro código generado como resultado del intento malicioso del sitio criminal 1204, entonces, el código pude ejecutarse sobre el ordenador del usuario. Este ejemplo ilustra una de muchas técnicas en las que un "pirata informático" puede inducir a un servidor de Web legítimo 1206 a enviar instrucciones maliciosas a un navegador de Web de usuario 216. Debido a que los varios lenguajes de codificación y escritura contienen instrucciones para acceder al sistema de fichero de ordenador central, registro, o similar, se entenderá que la ejecución no autorizada de tales códigos es muy poco deseable. Sin embargo, la técnica mostrada en la figura 12A puede permitir script u otro código desde un sitio criminal 1204 que esté previsto para un ordenador de usuario. Puesto que el ordenador del usuario piensa que la escritura llegó desde una fuente de confianza (es decir, el servidor de la cartera), el ordenador del cliente puede ejecutar el código desde el sitio criminal, creando así el potencial para el daño, diseminación o destrucción de datos no autorizados, o similares. La figura 12B ilustra el flujo de comunicación correcta que debería producirse (en oposición al flujo del ataque criminal mostrado en la figura 12A).
Para prevenir este problema de seguridad potencial, varias formas de realización de la invención incluyen de forma adecuada técnicas para la reducción o eliminación de código ejecutable no deseado. Con referencia a la figura 13, un proceso 1300 para reducir la probabilidad de ataques de scripts incluye adecuadamente las etapas de limitar las porciones del servidor de tener permiso elevado (etapa 1302), eliminando los caracteres peligrosos dentro de esta porción del sitio (etapa 1304), codificando ciertos caracteres donde sea necesario (etapa 1306), y registrando opcionalmente los datos que están previstos para los usuarios desde la porción elevada del sitio de Web (1308).
Con respecto a la etapa 1302, un sitio de Web incluye típicamente varias páginas, teniendo cada página una URL única. Los usuarios del sitio pueden establecer una confianza elevada en ciertos servidores (tales como estos correspondientes a instituciones financieras o comercios que son acreditados). Limitando la confianza elevada a solamente una porción del sitio de Web (por ejemplo, un subconjunto limitado de URL correspondientes al sitio de WEB de confianza), el nivel de confianza ofrecido al resto del sitio es reducido de forma adecuada y se mejora la seguridad. La confianza puede limitarse a una porción limitada del sitio, configurando el navegador de Web del usuario para confiar solamente en una porción del sitio, por ejemplo. El navegador de la Web de usuario puede estar configurado manualmente por un script de configuración previsto por un servidor de la cartera, por ejemplo. Cuando están permitidas solamente ciertas páginas (por ejemplo, una porción) del sitio de la Web con confianza elevada, algunos scripts incluidos en las referencias a otras páginas, o bien no se ejecutarán o se ejecutarán con confianza elevada.
Además de (o como una alternativa a) la configuración del cliente, tal que el cliente solamente "tiene confianza" en una cierta porción del servidor que puede estar configurada para mejorar la seguridad de la interacción del cliente-servidor. Por ejemplo, escribiendo con una confianza elevada puede no estar permitido en la mayoría del servidor para mejorar la seguridad. Además, los datos proporcionados a la porción de confianza del sitio de la Web pueden ser supervisados y/o modificados antes de ser retornados al usuario (etapas 1304 y 1306). La mayoría de los lenguajes de escritura requieren ciertos caracteres para formatear comandos. Por ejemplo, el lenguaje Javascript es codificado frecuentemente con instrucciones script establecidas entre los paréntesis de ángulo ("<" y ">"). Por tanto, los paréntesis de ángulo pueden ser retirados de cualquier contenido que será retornado por una porción de confianza del sitio de la Web. Si una página Web proporcionada desde una porción de confianza del sitio de la Web fuera para incluir un programa Javascript "criminal" que intenta utilizar paréntesis de ángulo, por ejemplo, las instrucciones script no se ejecutarían sobre el ordenador del usuario debido a que las instrucciones script no estarían formateadas adecuadamente después de retirar los paréntesis del ángulo. Alternativamente, ciertos caracteres "peligrosos" (tales como los paréntesis del ángulo en Javascript) pueden ser retornados en un formato alternativo, por ejemplo, en "anotación "y" comercial" con una "y" comercial "&" y valor de Código Estándar Americano para Intercambio de Información "ASCII" para el carácter particular, o sustituyendo el carácter "peligroso" con un carácter seguro, tal como el carácter de "espacio" (etapa 1306). Se apreciará que cualquiera de los caracteres podría eliminarse o codificarse en varias formas de realización de la invención, dependiendo de los lenguajes particulares, entornos de escritura, y similares que pueden utilizarse.
En varias formas de realización, una etapa opcional 1308 incluye de forma adecuada mantener un registro de datos de información previsto por las varias porciones del sitio de la Web. Todo el contenido en el que los caracteres han sido codificados o retirados puede ser registrado de forma que el registro puede revisarse para determinar si el sitio de la Web está siendo utilizado para comprometer un cliente de la red. Por ejemplo, todo el contenido previsto desde la página Web, todo el contenido previsto desde dentro de la porción de confianza, todo el contenido que tiene contenido de escritura/programación, todo el contenido desde fuera de la porción de confianza, o cualquier otra parte del contenido del sitio Web podría ser registrado en uno o más ficheros de datos. Los ficheros de datos pueden ser buscados de forma adecuada y consultados, de otro modo, para determinar si han existido intentos de proporcionar contenido no autorizado a usuarios por el servidor.
En muchos casos, las máquinas internas pueden ser atacadas por un sitio "criminal" que envía el contenido que contiene script a un servidor de la red que puede registrar el contenido en ficheros de trayectoria de control (por ejemplo, registro). Dado que un navegador puede haberse configurado con alta confianza para ficheros que residen en el servidor, en varias formas de realización, cuando un usuario revisa los ficheros de trayectoria de control de la Web u otros servidores de comercio electrónico utilizando el navegador, puede ejecutarse un script sobre el cliente de la red con el nivel de confianza, del servidor de la red que suministró los registros de trayectoria de control (por ejemplo, con un nivel de alta confianza). La ejecución de este script puede provocar un ataque que puede producirse mucho después de que se envió el script al servidor de la red. Este ataque puede ser prevenido utilizando los mismos métodos y procedimientos descritos anteriormente para prevenir la escritura del sitio, tal como los ataques "criminales" descritos anteriormente. Un filtro, tal como uno descrito en la figura 13, que funciona en el servidor de la red, tal como un servidor de la red, o que funciona en un cliente de red, tal como un navegador de PC, puede filtrar los caracteres de control script y codificar los caracteres, rechazar los caracteres o rechazar todo el registro.
El alcance de la invención debería determinarse por las reivindicaciones permitidas en lugar de por los ejemplos dados anteriormente.

Claims (21)

1. Un método de operación de aparato de ordenador para llevar a cabo una transacción, comprendiendo el método:
a. recibir una solicitud de transacción (1002; 1102) desde un usuario en un servidor (140; 130);
b. emitir una pregunta (1004; 1106, 1108) al usuario;
c. recibir una respuesta (1008; 1110, 1112) desde el usuario basada en la pregunta;
d. procesar dicha respuesta para verificar al usuario (1010; 1114);
e. montar las credenciales para la transacción, comprendiendo dichas credenciales al menos una clave;
f. proporcionar al menos una parte de dichas credenciales a dicho usuario (1012);
g. recibir una segunda solicitud (1014; 1110) desde dicho usuario, incluyendo dicha segunda solicitud dicha porción de dichas credenciales; y
h. validar (1016, 1018; 1112, 1116) dicha porción de dichas credenciales con dicha clave para proporcionar acceso a un servicio de transacción.
2. El método de la reivindicación 1, donde la transacción es una transacción de compra electróni-
ca.
3. El método de la reivindicación 2, donde la transacción de compra electrónica se lleva a cabo utilizando una cartera digital (140; 214).
4. El método de la reivindicación 1, 2 ó 3, donde el usuario lleva a cabo la transacción a través de una tarjeta inteligente (202).
5. Un sistema de transacción (100) para facilitar una transacción financiera solicitada por un usuario que acciona un ordenador de usuario (110) sobre una red de datos (102), comprendiendo el sistema:
a. un autorizador de la transacción (120); y
b. un servidor de seguridad (130) configurado para verificar que una ficha inteligente está en la posesión del usuario y proporcionar una credencial digital a dicho ordenador de usuario si dicha verificación es útil;
donde dicho autorizador de transacción (120) está configurado para autorizar una transacción solicitada por dicho usuario basada en al menos parte de dicha credencial digital prevista por dicho ordenador de usuario a través de dicha red de datos
(102).
6. El sistema de transacción de la reivindicación 5, que comprende adicionalmente un servidor de herramienta de transacción.
7. El sistema de transacción de la reivindicación 5 ó 6, que comprende adicionalmente un servidor de cartera (140) en comunicación con dicho ordenador del usuario (110) a través de dicha red digital
(102).
8. El sistema de transacción de la reivindicación 7, donde dicho servidor de cartera (140) está configurado para recibir una solicitud (1102) para una transacción desde dicho ordenador de usuario (110) para poner en contacto un sistema de ordenador de comerciante (120) y proporcionar información sobre dicho usuario (110) a dicho sistema de ordenador de comerciante.
9. El sistema de transacción de cualquiera de las reivindicaciones 5-8, donde el ordenador del usuario (110) comprende una herramienta de transacción y un lector (204), donde dicho lector está configurado para transferir información entre la herramienta de transacción y la ficha inteligente.
10. El sistema de transacción de la reivindicación 9, donde dicha herramienta de transacción es un cliente de la cartera (214).
11. El sistema de transacción de cualquiera de las reivindicaciones 5-10, donde la ficha inteligente es una tarjeta inteligente (202).
12. El sistema de transacción de cualquiera de las reivindicaciones 5-11, donde la conexión entre dicho servidor de seguridad (100) y dicho ordenador de autorizador de la transacción (120) es a través de dicha conexión de datos (152) separada desde dicha red de datos (102).
13. El sistema de transacción de la reivindicación 9, donde dicha herramienta de transacción se comunica con dicho servidor de seguridad (130) a través de una conexión de datos (150) separada de dicha red de datos (102).
14. El sistema de transacción de cualquiera de las reivindicaciones 5-13, donde la ficha inteligente comprende un certificado digital que identifica únicamente al usuario asociado con la ficha inteligente.
15. El sistema de transacción de la reivindicación 14, donde el usuario de dicha ficha inteligente desbloquea el acceso al certificado digital por el uso de un identificador personal.
16. El sistema de transacción de cualquiera de las reivindicaciones 5-15, donde la ficha inteligente es emitida por un emisor y donde una transacción realizada utilizando dicho sistema de transacción es considerada una transacción de "tarjeta presente" como se considera por el emisor de la ficha inteligente.
17. Un método ejecutado con ordenador para facilitar el acceso a un servicio, comprendiendo el método las etapas de:
recibir una solicitud de registro (1002) desde un usuario;
verificar que dicho usuario está en posesión de una ficha (1004, 1006, 1008, 1010);
proporcionar una credencial a dicho usuario si dicha verificación tiene éxito (1012);
recibir una solicitud de transacción desde un usuario (1014), comprendiendo dicha solicitud de transacción al menos una parte de dicha credencial; y
procesar al menos dicha parte de dicha credencial para proporcionar acceso a dicho servicio (1016; 1018).
18. El método de la reivindicación 17, donde dicha etapa de verificación comprende una pregunta-respuesta.
19. El método de la reivindicación 18, donde dicha pregunta-respuesta comprende datos aleatorios proporcionados a dicha ficha.
20. El método de la reivindicación 19, donde dicha pregunta-respuesta comprende adicionalmente una firma digital de dichos datos aleatorios.
21. El método de cualquiera de las reivindicaciones 17-20, donde dicho servicio es una transacción financiera.
ES00959619T 1999-08-31 2000-08-30 Metodos y aparatos para realizar transacciones electronicas. Expired - Lifetime ES2215064T3 (es)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US15188099P 1999-08-31 1999-08-31
US151880P 1999-08-31
US16466899P 1999-11-09 1999-11-09
US164668P 1999-11-09
US16557799P 1999-11-15 1999-11-15
US165577P 1999-11-15
US20163500P 2000-05-03 2000-05-03
US201635P 2000-05-03

Publications (1)

Publication Number Publication Date
ES2215064T3 true ES2215064T3 (es) 2004-10-01

Family

ID=27495993

Family Applications (1)

Application Number Title Priority Date Filing Date
ES00959619T Expired - Lifetime ES2215064T3 (es) 1999-08-31 2000-08-30 Metodos y aparatos para realizar transacciones electronicas.

Country Status (28)

Country Link
EP (1) EP1212732B1 (es)
JP (2) JP2003508838A (es)
KR (1) KR100806993B1 (es)
CN (1) CN1376292A (es)
AR (1) AR027848A1 (es)
AT (1) ATE258328T1 (es)
AU (1) AU775976B2 (es)
BR (1) BR0013822A (es)
CA (3) CA2382922C (es)
CZ (1) CZ2002744A3 (es)
DE (1) DE60007883T2 (es)
DK (1) DK1212732T3 (es)
DZ (1) DZ3214A1 (es)
ES (1) ES2215064T3 (es)
HK (1) HK1048550B (es)
HR (1) HRP20020180A2 (es)
HU (1) HUP0202471A2 (es)
IL (1) IL148319A0 (es)
MA (1) MA27459A1 (es)
MX (1) MXPA02002081A (es)
NO (1) NO20020996L (es)
NZ (1) NZ517840A (es)
PL (1) PL353773A1 (es)
PT (1) PT1212732E (es)
SI (1) SI1212732T1 (es)
TR (2) TR200201280T2 (es)
TW (1) TW548564B (es)
WO (1) WO2001016900A2 (es)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020186255A1 (en) 1999-10-28 2002-12-12 Shafron Thomas Joshua Method and system of facilitating on-line shopping using an internet browser
JP2002318808A (ja) * 2001-04-20 2002-10-31 Cybozu Inc 個人情報登録支援システム
US7363486B2 (en) 2001-04-30 2008-04-22 Activcard Method and system for authentication through a communications pipe
WO2002089444A1 (en) * 2001-04-30 2002-11-07 Activcard Ireland, Limited Method and system for authenticating a personal security device vis-a-vis at least one remote computer system
US20020162021A1 (en) 2001-04-30 2002-10-31 Audebert Yves Louis Gabriel Method and system for establishing a remote connection to a personal security device
US7225465B2 (en) 2001-04-30 2007-05-29 Matsushita Electric Industrial Co., Ltd. Method and system for remote management of personal security devices
WO2002091316A1 (en) 2001-04-30 2002-11-14 Activcard Ireland, Limited Method and system for remote activation and management of personal security devices
JP4780915B2 (ja) * 2001-11-01 2011-09-28 ヤフー！ インコーポレイテッド インターネットブラウザを用いてオンライン・ショッピングを簡便化する方法およびシステム
US7162631B2 (en) 2001-11-02 2007-01-09 Activcard Method and system for scripting commands and data for use by a personal security device
US20030167399A1 (en) * 2002-03-01 2003-09-04 Yves Audebert Method and system for performing post issuance configuration and data changes to a personal security device using a communications pipe
CN100339781C (zh) * 2002-04-26 2007-09-26 国际商业机器公司 向请求实体传送身份相关信息的方法和***
EP1406156A1 (en) * 2002-10-03 2004-04-07 Nokia Corporation Method for activation of the wallet program in an internet terminal and an internet terminal
US7089429B2 (en) * 2002-11-25 2006-08-08 Nokia Corporation Creation of local usage rights voucher
US8473355B2 (en) * 2002-12-06 2013-06-25 Facebook, Inc. System and method for electronic wallet conversion
US7483845B2 (en) 2003-06-24 2009-01-27 Nokia Corporation Methods, system, and computer readable medium for user data entry, at a terminal, for communication to a remote destination
AU2003903229A0 (en) 2003-06-25 2003-07-10 Ewise Systems Pty Ltd A system and method for facilitating on-line payment
US7549054B2 (en) * 2004-08-17 2009-06-16 International Business Machines Corporation System, method, service method, and program product for managing entitlement with identity and privacy applications for electronic commerce
WO2006117768A1 (en) * 2005-05-03 2006-11-09 Lincor Solutions Limited An information management and entertainment system
WO2007012583A1 (fr) * 2005-07-26 2007-02-01 France Telecom Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
CZ2006759A3 (cs) * 2006-12-01 2008-07-09 Kalfus@Jan Zpusob úhrady hotovostních plateb pri uzavírání obchodu prostrednictvím internetu a hotovostní platební systém
DE102007009212A1 (de) * 2007-02-26 2008-08-28 Giesecke & Devrient Gmbh Tragbarer Datenträger
GB2447059B (en) 2007-02-28 2009-09-30 Secoren Ltd Authorisation system
CN101184107B (zh) * 2007-12-17 2010-09-01 北京飞天诚信科技有限公司 网上交易***及利用该***进行网上交易的方法
DE102008021030B4 (de) * 2008-04-24 2020-02-20 Volkswagen Ag Verfahren zum Betreiben eines Fahrzeugs sowie entsprechende Vorrichtung und entsprechendes Fahrzeug
KR101062099B1 (ko) * 2008-08-14 2011-09-02 에스케이 텔레콤주식회사 카드에 저장된 어플리케이션의 활성화를 위한 시스템 및 방법
EP2340503A4 (en) * 2008-10-13 2013-01-09 Hewlett Packard Development Co SYSTEMS AND METHODS FOR SECURING SENSITIVE INFORMATION
US8160064B2 (en) 2008-10-22 2012-04-17 Backchannelmedia Inc. Systems and methods for providing a network link between broadcast content and content located on a computer network
US9094721B2 (en) 2008-10-22 2015-07-28 Rakuten, Inc. Systems and methods for providing a network link between broadcast content and content located on a computer network
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US8602293B2 (en) 2009-05-15 2013-12-10 Visa International Service Association Integration of verification tokens with portable computing devices
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
WO2012122049A2 (en) 2011-03-04 2012-09-13 Visa International Service Association Integration of payment capability into secure elements of computers
DE102011015486B4 (de) 2011-03-29 2012-12-20 Sikom Software Gmbh Verfahren und Anordnung zur Erstellung situationsgerechter multimedialer Protokolle mittels Telekommunikationsnetz mit WEB- und Sprachportalen
KR101767301B1 (ko) 2011-09-09 2017-08-10 라쿠텐 인코포레이티드 대화형 텔레비전 노출에 대한 소비자 제어를 위한 시스템들 및 방법들
US9137262B2 (en) 2011-10-11 2015-09-15 Citrix Systems, Inc. Providing secure mobile device access to enterprise resources using application tunnels
US9280377B2 (en) 2013-03-29 2016-03-08 Citrix Systems, Inc. Application with multiple operation modes
CA2862020C (en) 2012-01-19 2018-03-20 Mastercard International Incorporated System and method to enable a network of digital wallets
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US9171302B2 (en) * 2012-04-18 2015-10-27 Google Inc. Processing payment transactions without a secure element
EP2815365A4 (en) * 2012-05-04 2015-11-18 Mastercard International Inc PLATFORM TRANSFORMING CONVERGED ELECTRONIC WALLET
US9053340B2 (en) 2012-10-12 2015-06-09 Citrix Systems, Inc. Enterprise application store for an orchestration framework for connected devices
US9774658B2 (en) 2012-10-12 2017-09-26 Citrix Systems, Inc. Orchestration framework for connected devices
US8910239B2 (en) 2012-10-15 2014-12-09 Citrix Systems, Inc. Providing virtualized private network tunnels
CN104854561B (zh) 2012-10-16 2018-05-11 思杰***有限公司 用于应用程序管理框架的应用程序封装
US20140108793A1 (en) 2012-10-16 2014-04-17 Citrix Systems, Inc. Controlling mobile device access to secure data
US9971585B2 (en) 2012-10-16 2018-05-15 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US10284627B2 (en) 2013-03-29 2019-05-07 Citrix Systems, Inc. Data management for an application with multiple operation modes
US9413736B2 (en) * 2013-03-29 2016-08-09 Citrix Systems, Inc. Providing an enterprise application store
US9355223B2 (en) 2013-03-29 2016-05-31 Citrix Systems, Inc. Providing a managed browser
US9985850B2 (en) 2013-03-29 2018-05-29 Citrix Systems, Inc. Providing mobile device management functionalities
US10373166B2 (en) * 2013-05-24 2019-08-06 Marc George System for managing personal identifiers and financial instrument use
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
RU2686014C1 (ru) 2013-12-19 2019-04-23 Виза Интернэшнл Сервис Ассосиэйшн Способы и системы облачных транзакций
US11270298B2 (en) 2014-04-14 2022-03-08 21, Inc. Digital currency mining circuitry
JP2017511562A (ja) * 2014-04-16 2017-04-20 ニュークリアス ソフトウェア エクスポーツ リミテッド 大量電子取引の効率的運用のための装置、システム、及び方法
DE102014005701A1 (de) 2014-04-17 2015-10-22 HST High Soft Tech GmbH Verfahren zur telefonischen Authentifizierung von Benutzern privater oder öffentlicher Netzwerke zum Datenaustausch
AU2015264124B2 (en) 2014-05-21 2019-05-09 Visa International Service Association Offline authentication
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
TWI559169B (zh) * 2015-10-01 2016-11-21 Chunghwa Telecom Co Ltd Authorization method and architecture of card with user - side card authority control and traceability
CN107067251B (zh) * 2016-01-25 2021-08-24 苹果公司 使用具有地理上受限的非本地凭据的电子设备进行交易
WO2017165576A1 (en) 2016-03-22 2017-09-28 Visa International Service Association Adaptable authentication processing
US11516664B2 (en) * 2016-04-05 2022-11-29 Carrier Corporation Credential licensing service
KR101941587B1 (ko) * 2017-07-28 2019-04-11 김금철 카드사가 결제요청을 수신한 후에 사용자를 직접 확인하는 결제시스템 및 결제방법
TWI695354B (zh) * 2018-11-21 2020-06-01 呂英璋 電腦程式編程學習系統

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0722596A4 (en) * 1991-11-12 1997-03-05 Security Domain Pty Ltd METHOD AND SYSTEM FOR SECURE, DECENTRALIZED PERSONALIZATION OF CHIP CARDS
DE4339460C1 (de) * 1993-11-19 1995-04-06 Siemens Ag Verfahren zur Authentifizierung eines Systemteils durch ein anderes Systemteil eines Informationsübertragungssystems nach dem Challenge-and Response-Prinzip
US5832212A (en) * 1996-04-19 1998-11-03 International Business Machines Corporation Censoring browser method and apparatus for internet viewing
US5905736A (en) * 1996-04-22 1999-05-18 At&T Corp Method for the billing of transactions over the internet
JPH09305666A (ja) * 1996-05-16 1997-11-28 Nippon Telegr & Teleph Corp <Ntt> 電子決済方法ならびにシステム
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6167520A (en) * 1996-11-08 2000-12-26 Finjan Software, Inc. System and method for protecting a client during runtime from hostile downloadables
IL120632A0 (en) * 1997-04-08 1997-08-14 Zuta Marc Multiprocessor system and method
MXPA00002497A (es) 1997-09-12 2003-07-21 Amazon Com Inc Metodo y sistema para hacer una orden de compra por medio de una red de comunicaciones.
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
KR100241350B1 (ko) * 1997-10-27 2000-02-01 정선종 전자 거래에서 안전한 전자 공증문서 생성방법
EP0917119A3 (en) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Distributed network based electronic wallet
KR20010033972A (ko) * 1998-01-09 2001-04-25 사이버세이퍼 코퍼레이션 클라이언트측 공개키 인증방법 및 단기증명장치
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol

Also Published As

Publication number Publication date
KR100806993B1 (ko) 2008-02-25
DZ3214A1 (fr) 2001-03-08
HUP0202471A2 (en) 2002-11-28
WO2001016900A2 (en) 2001-03-08
HK1048550A1 (en) 2003-04-04
AU775976B2 (en) 2004-08-19
TR200201280T2 (tr) 2002-08-21
JP2011060291A (ja) 2011-03-24
CZ2002744A3 (cs) 2004-02-18
HK1048550B (zh) 2004-10-21
NZ517840A (en) 2005-03-24
TR200202436T2 (tr) 2003-01-21
CA2382922A1 (en) 2001-03-08
WO2001016900A3 (en) 2001-10-04
SI1212732T1 (en) 2004-10-31
KR20020039339A (ko) 2002-05-25
HRP20020180A2 (en) 2004-06-30
DE60007883T2 (de) 2004-10-14
EP1212732B1 (en) 2004-01-21
BR0013822A (pt) 2002-07-23
IL148319A0 (en) 2002-09-12
CN1376292A (zh) 2002-10-23
CA2893917C (en) 2017-01-17
JP2003508838A (ja) 2003-03-04
CA2753375A1 (en) 2001-03-08
MA27459A1 (fr) 2005-08-01
AU7090700A (en) 2001-03-26
CA2753375C (en) 2015-09-22
TW548564B (en) 2003-08-21
ATE258328T1 (de) 2004-02-15
MXPA02002081A (es) 2004-07-30
DK1212732T3 (da) 2004-06-07
CA2382922C (en) 2011-12-13
NO20020996L (no) 2002-04-24
JP5439322B2 (ja) 2014-03-12
PT1212732E (pt) 2004-06-30
DE60007883D1 (de) 2004-02-26
PL353773A1 (en) 2003-12-01
AR027848A1 (es) 2003-04-16
EP1212732A2 (en) 2002-06-12
NO20020996D0 (no) 2002-02-28
CA2893917A1 (en) 2001-03-08

Similar Documents

Publication Publication Date Title
ES2215064T3 (es) Metodos y aparatos para realizar transacciones electronicas.
US20180114206A1 (en) Methods and apparatus for conducting electronic transactions
RU2252451C2 (ru) Способ проведения трансакций, компьютеризованный способ защиты сетевого сервера, трансакционная система, сервер электронного бумажника, компьютеризованный способ выполнения онлайновых покупок (варианты) и компьютеризованный способ контроля доступа
US7505941B2 (en) Methods and apparatus for conducting electronic transactions using biometrics
CA2482558C (en) Mobile account authentication service
JP2005508040A (ja) データ通信ネットワークにおける本人確認の品質向上
JP2005539279A (ja) データ通信ネットワーク上での本人確認における強化されたプライバシー保護
JP2005531823A (ja) データ通信ネットワーク上に分布された資源へのユーザアクセスの制御
AU2004231226B2 (en) Methods and apparatus for conducting electronic transactions
JP2006502459A (ja) データ通信ネットワークにおける本人確認情報の管理