ES2275702T3 - Recibo digital de una transaccion. - Google Patents
Recibo digital de una transaccion. Download PDFInfo
- Publication number
- ES2275702T3 ES2275702T3 ES01955892T ES01955892T ES2275702T3 ES 2275702 T3 ES2275702 T3 ES 2275702T3 ES 01955892 T ES01955892 T ES 01955892T ES 01955892 T ES01955892 T ES 01955892T ES 2275702 T3 ES2275702 T3 ES 2275702T3
- Authority
- ES
- Spain
- Prior art keywords
- transaction
- document
- digital
- receipt
- verification
- 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
Links
Classifications
-
- 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
-
- 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/04—Payment circuits
-
- 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/04—Payment circuits
- G06Q20/047—Payment circuits using payment protocols involving electronic receipts
-
- 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/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- 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/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- 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/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- 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/12—Card verification
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (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)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Cash Registers Or Receiving Machines (AREA)
- Oscillators With Electromechanical Resonators (AREA)
- Holo Graphy (AREA)
- Gyroscopes (AREA)
Abstract
Un medio leíble mediante ordenador destinado a servir de registro de la existencia de una transacción, almacenando el medio leíble por ordenador: un recibo digital de la transacción susceptible de ser presentado a un usuario, comprendiendo el recibo digital: una descripción de la transacción en formato inteligible; una prueba infalsificable de que se ha producido la transacción; y una propuesta de verificación de la prueba infalsificable, sin necesidad de interacción humana adicional para su identificación, en el que: la transacción consiste en la existencia de un documento en un momento específico; el recibo digital incluye un formulario en un lenguaje de marcas estándar, incluyendo el formulario el documento, codificado como texto oculto; la descripción de la transacción comprende: un nombre que identifique el documento, y un tiempo que identifique el momento específico; la prueba infalsificable comprende un indicador de marca de tiempo firmado digitalmente, codificado como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo: una huella digital del documento, y la marca de tiempo del documento; y la propuesta de verificación comprende, en el formulario, un elemento activado por el usuario, de modo que la activación de dicho elemento transmita el texto oculto de la prueba infalsificable y el texto oculto del documento a un proveedor de servicio, para su verificación.
Description
Recibo digital de una transacción.
\global\parskip0.900000\baselineskip
Esta invención se refiere, en general, a
criptografía de clave pública, firmas digitales e infraestructura de
clave pública (ICP). Más específicamente, se refiere a la generación
y al uso de registros y recibos digitales de transacciones.
Como consecuencia de la popularidad y aceptación
crecientes del ordenador, de Internet y de otras formas de
comunicaciones en red, las transacciones y los documentos
electrónicos aumentan en número e importancia. Por ejemplo, el
volumen de compras de consumo, comercio entre empresas,
transacciones de Bolsa y otras formas de inversión que tienen lugar
a través de Internet y/o redes inalámbricas aumenta progresivamente,
al igual que otras formas de comercio en modo de conexión. Además,
el número de documentos generados o disponibles electrónicamente y
el número de documentos existentes solamente en forma electrónica
(por ejemplo, la oficina sin papeles) aumentan, también, de modo
progresivo.
El número creciente de transacciones y
documentos electrónicos da lugar a una necesidad correspondiente de
métodos fiables de realización de registros de estas transacciones y
estos documentos. Por ejemplo, cuando un consumidor compra un
artículo por Internet usando su tarjeta de crédito, es deseable
realizar un registro fiable, irrefutable de la compra. Si dos
sociedades "firman" electrónicamente un contrato, es deseable
registrar tanto el acto de la firma como el contenido del contrato.
En la oficina sin papeles, es deseable "certificar mediante
notaría digital" ciertos documentos, garantizando así que, con
posterioridad, pueda probarse su existencia en un momento
específico.
Un enfoque al problema de los registros consiste
en el uso de criptografía. Las características de la criptografía de
clave pública, en particular, pueden usarse de varios modos para
realizar registros fuertes de transacciones. Por ejemplo, en el caso
de Internet de consumo, un consumidor con un certificado digital
podría generar una firma digital de su pedido que incluya el número
de la tarjeta de crédito, creando así un registro de la compra. En
el ejemplo del contrato, las dos sociedades podrían, igualmente,
generar una firma digital bipartita del contrato, usando cada
sociedad su certificado digital. En el ejemplo de notaría digital,
un tercero (es decir, el notario) podría atestiguar el documento,
merced a la incorporación de una marca de tiempo y una firma digital
en el documento (véase, por ejemplo, el documento
US-A-5497422).
Pero con el fin de lograr una aceptación amplia,
estos enfoques deberían de ser intuitivos y fáciles de usar. Un
problema de los intentos pasados de generar una infraestructura de
registros de transacciones consiste en la incomodidad y dificultad
de su uso. Por ejemplo, en muchos enfoques se genera una firma
digital para atestiguar una transacción y estas firmas digitales se
almacenan por si en el futuro son necesarias. Pero las firmas
digitales son ininteligibles. De ese modo, para encontrar la firma
digital correcta en un caso específico, las firmas digitales tienen
que almacenarse de manera segura, con una descripción de la
transacción. Una vez localizada la firma digital correcta, se
requiere una tratamiento adicional para hacer el contenido de la
firma digital útil para los usuarios.
Con frecuencia, estas funciones se realizan
mediante partes de lógica diferentes. Por ejemplo, puede usarse
lógica de base de datos para almacenar las firmas digitales y su
correspondiente lógica en una gran base de datos central. Puede
usarse lógica de navegación auxiliar para tratar la firma digital
correcta una vez localizada. Pero este enfoque puede ser incómodo y
poco intuitivo. La base de datos central implica que tenga que
accederse a ella para localizar los registros correctos. Por tanto,
es difícil que una entidad envíe una copia del registro de la
transacción a otra entidad, en particular, si ambas no tienen acceso
a la base de datos en un momento determinado. Un problema similar se
produce si una entidad carece del accesorio de navegación correcto o
no sabe como usarlo.
Por tanto, existe la necesidad de enfoques
simples e intuitivos para realizar y usar registros de transacciones
y documentos. Existe la necesidad de otros enfoques que permitan que
estos registros puedan ser movidos con facilidad sin comprometer su
integridad.
Los problemas mencionados en lo que antecede se
resuelven merced a las particularidades de las reivindicaciones 1,
10, 18, 21 y 24.
De acuerdo con la presente invención, un medio
leíble mediante ordenador sirve como registro de que se ha producido
una transacción. El medio leíble mediante ordenador almacena un
recibo digital (300,700,900) de la transacción susceptible de ser
presentado a un usuario. El recibo digital (300,700,900) incluye una
descripción (310,710,720,910,
1020) de la transacción en un formato inteligible, una prueba infalsificable (320) de la existencia de la transacción, y una propuesta (330,740,940,1030) de verificación. Preferiblemente, la prueba infalsificable (320) no puede verse en la presentación. La activación de la propuesta (330,740,940,1030) de verificación confirma la prueba infalsificable (320), sin necesidad de interacción humana adicional para su identificación.
1020) de la transacción en un formato inteligible, una prueba infalsificable (320) de la existencia de la transacción, y una propuesta (330,740,940,1030) de verificación. Preferiblemente, la prueba infalsificable (320) no puede verse en la presentación. La activación de la propuesta (330,740,940,1030) de verificación confirma la prueba infalsificable (320), sin necesidad de interacción humana adicional para su identificación.
\global\parskip0.990000\baselineskip
En una realización, el medio leíble mediante
ordenador sirve a modo de registro de la existencia de un documento
en un momento específico. El recibo digital (700) incluye un
formulario en un lenguaje de marcas estándar, tal como HTML o XML, y
contiene un nombre (710) que identifica el documento, un tiempo
(730) que identifica el momento específico, un indicador de marca de
tiempo firmado digitalmente, codificado como texto oculto en el
formulario, y un botón (740) de verificación. El indicador de marca
de tiempo incluye una "huella digital" del documento (por
ejemplo, un picado (hash) del documento), y la marca de tiempo del
documento. La activación del botón (740) de verificación transmite
el texto oculto a un proveedor (130) de servicio para su
verificación. En otra realización, el formulario incluye, también,
el propio documento (910), codificado como texto oculto. Asimismo,
la activación de la propuesta de verificación (940) transmite el
texto oculto del documento al proveedor (130) de servicio para su
verificación.
De acuerdo con otro aspecto de la invención, un
método (200,400) de generación de un registro de la existencia de
una transacción incluye los pasos que siguen. Se recibe (210,410)
una solicitud de generación de un recibo digital (300,700) de la
transacción. Se genera (220,420) una prueba infalsificable (320) de
la existencia de la transacción. Se genera (230,430) un recibo
digital (300,700,900) de la transacción. El recibo digital
(300,700,900) es susceptible de ser presentado a un usuario e
incluye una descripción (310,710,720,910,1020) de la transacción, la
prueba infalsificable (320) generada, y una propuesta
(330,740,940,1030) de verificación. Cuando se activa la propuesta
de verificación se verifica la prueba (320) sin necesidad de
interacción humana adicional para su identificación.
De acuerdo con otro aspecto de la invención, un
método (250,450) para verificar que se ha producido una transacción
incluye los pasos siguientes. Se presenta (265,465) el recibo
digital (300,700,900) descrito en lo que antecede y se activa
(270,470) la propuesta (330,740,940,1030) de verificación,
iniciándose así la verificación de la prueba infalsificable (320).
En una realización se recibe (295,495) la verificación de la prueba,
y, una vez recibida, se presenta una segunda propuesta de
verificación. Entonces, la activación (202,402) de la segunda
propuesta verifica (202,404,406) la transacción subyacente.
Los métodos (200,250,400,450) de los dos
párrafos anteriores se ponen en práctica, preferiblemente, mediante
lógica ejecutable mediante un procesador.
La presente invención es particularmente
ventajosa porque el recibo digital (300,700,900) incluye una
propuesta (330,740,940,1030) de verificación y la prueba
infalsificable (320) que tenga que verificarse. Ello hace el recibo
digital (300,700,900) más fácil e intuitivo de usar. Por ejemplo, en
caso de que el recibo digital (300,700,900) no incluyese la
propuesta de verificación (330,740,940,1030) se necesitarían lógica
o instrucciones independientes para verificar la prueba (320).
Alternativamente, si el recibo digital (300,700,900) no incluye la
prueba (320), entonces, ésta tendría que obtenerse a partir de otra
fuente. Cualquiera de estos casos plantean un problema si el
usuario (120) no dispone del acceso adecuado a la parte que falte.
Al incluir tanto la propuesta de verificación (330,740,940) como la
prueba (320) que tenga que verificarse, el recibo digital
(300,700,900) es autosuficiente y se evita este problema. De ese
modo, por ejemplo, el recibo digital (300,700,900) puede ser enviado
a un tercero (120), que podría verificarlo activando (270,470) la
propuesta de verificación (330,740,940,1030).
La invención presenta otras ventajas y
características que se pondrán de manifiesto con más facilidad a
partir de la descripción detallada que sigue de la invención y de
las reivindicaciones adjuntas, cuando se consideran conjuntamente
con los dibujos adjuntos, en los que:
la figura 1 es un diagrama de bloques de un
sistema de acuerdo con la presente invención;
las figuras 2A y 2B son trazas de
acontecimientos que ilustran un método de funcionamiento del sistema
de la figura 1;
la figura 3 es una ilustración de una
realización preferida de un recibo digital de una transacción de
acuerdo con la presente invención;
las figuras 4A y 4B son trazas de
acontecimientos que ilustran un método preferido de funcionamiento
del sistema de la figura 1;
las figuras 5-8 son distintos
formularios y cuadros de diálogo que ilustran el método de la figura
4;
la figura 9 es un formulario que ilustra una
realización alternativa del método de la figura 4; y
la figura 10 es una captura de pantalla que
ilustra todavía otra realización de acuerdo con la invención.
Esta invención se refiere, en general, a
criptografía de clave pública, firmas digitales y certificados
digitales expedidos por una autoridad de certificación (AC), que,
conjuntamente, forman parte de una infraestructura de clave pública
(ICP) para el aseguramiento de transacciones en modo de conexión.
Antes de volver a las figuras, es útil describir primero estos
conceptos subyacentes.
La criptografía de clave pública es un enfoque
para el aseguramiento de comunicaciones merced al uso de pares de
claves. Cada par de claves incluye una clave pública y una clave
privada, cada una de las cuales consiste en, típicamente, un número
grande. La clave privada es mantenida de modo seguro por la entidad,
mientras que la clave pública se hace disponible ampliamente. La
clave pública y la clave privada están relacionadas matemáticamente,
de modo que un mensaje cifrado mediante una clave pueda ser
descifrado mediante la otra, pero la relación es tal que no es
factible, desde el punto de vista del cálculo, obtener una clave
dada la otra. En otros términos, si un tercero conoce la clave
pública de una entidad (caso típico), es imposible, desde el punto
de vista del cálculo, deducir la clave privada correspondiente (que,
típicamente, es mantenida de modo seguro por la entidad). RSA, DSA y
ElGamal son algoritmos de cifrado de clave pública bien
conocidos.
Estos pares de claves pueden ser usados para
"firmar digitalmente" documentos. Una entidad "firma
digitalmente" un documento merced al cifrado del documento o de
una versión tratada del mismo mediante la clave privada de la
entidad. Ello permite a un tercero autenticar el documento al
verificar que (i) se ha usado la clave privada de la entidad (en
lugar de otra clave) para firmar digitalmente el documento; (ii) el
contenido del documento no ha cambiado desde que fue firmado
digitalmente; y (iii) la entidad, luego, no puede negar que firmó
digitalmente el documento. La primera característica se denomina, a
menudo, de "paternidad", la segunda de "integridad" y la
tercera de "no repudio".
Preferiblemente, un documento se firma
digitalmente generando, primero, un picado unidireccional (véase en
lo que sigue) del documento, creando lo que generalmente se denomina
compilación de documento. A continuación, la compilación de
documento se cifra mediante la clave privada de la entidad, con el
fin de generar la firma digital del documento. Típicamente, un
tercero recibe el documento y la correspondiente firma digital, y,
entonces, autentica el documento como sigue. Dicho tercero descifra
la firma digital recibida mediante la clave pública de la entidad
con el fin de generar una compilación del documento descifrada, que
tiene que ser idéntica a la compilación del documento original. El
tercero genera, también, un picado unidireccional del documento
recibido mediante la misma función de picado que la usada por la
entidad, con el fin de generar una nueva compilación del documento.
El tercero, entonces, compara la compilación de documento descifrada
con la compilación de documento recién generada. Si son idénticas,
el tercero ha autenticado el documento.
Una función de picado (hash) es una
transformación que recibe una entrada de tamaño de variable y
devuelve una salida de tamaño fijo, típicamente menor que la
entrada, denominada picado de la entrada. Una función unidireccional
es una transformación significativamente más fácil de ejecutar en
una dirección que en la dirección opuesta. Por tanto, una función de
picado unidireccional es una transformación con ambas
características. Preferiblemente, las funciones de picado
unidireccionales usadas para generar firmas digitales generan,
también, salidas, en general, de menor tamaño que las entradas, son
susceptibles de tratar entradas de cualquier tamaño, y, hasta cierto
punto, son libres de colisiones. Las funciones de picado, por
naturaleza, son funciones en relación de varios a uno, lo que
significa que muchas entradas pueden corresponderse con la misma
salida. Pero si la función de picado es libre de colisiones, este
problema potencial se evita a efectos prácticos. Una función de
picado es débilmente libre de colisiones si, dada una entrada, no es
posible, desde el punto de vista del cálculo, encontrar otra entrada
que se corresponda con la misma salida. Una función de picado es
fuertemente libre de colisiones si no es posible, desde el punto de
vista del cálculo, encontrar dos entradas cualesquiera que se
correspondan con la misma salida. Funciones de picado
unidireccionales bien conocidas son MD2, MD5 y
SHA-1.
El uso de criptografía de clave pública enfoca
muchos de los problemas inherentes a la seguridad en una red abierta
tal como Internet. Pero, sin más, siguen existiendo dos problemas
significativos. Primero, las distintas partes tienen que poder
acceder a las claves públicas de muchas entidades de manera eficaz.
Segundo, como las comunicaciones y las transacciones están
protegidas merced a los pares de claves y las entidades están
asociadas con sus claves públicas y, de algún modo, son
identificadas por las mismas, tiene que existir un método seguro
para que terceros puedan verificar que una clave pública determinada
pertenezca, realmente, a cierta entidad.
Los certificados digitales constituyen un método
para el tratamiento de ambos problemas. Un "certificado
digital" es un documento que asocia, de manera fiable, cierta
clave pública con cierta entidad, tal como personas físicas,
entidades legales, servidores de red y similares. De modo más
específico, un certificado digital, preferiblemente, es expedido por
un tercero de confianza, conocido, en general, como autoridad de
certificación (AC). El certificado digital contiene información
acerca de la identidad de la entidad (también conocida como
suscriptor del certificado digital) y la clave pública de la
entidad, y el certificado digital está firmado digitalmente por la
AC.
El certificado digital documenta, de manera
fiable, que la clave pública del certificado digital está asociada
con el suscriptor del certificado. Los terceros que deseen verificar
esta información pueden verificar la autenticidad de la firma
digital de la AC y la integridad del contenido del certificado
digital de la manera descrita en lo que antecede. Si el tercero
confía en la AC, entonces, puede confiar, también, en que la clave
pública del certificado digital esté asociada con el suscriptor del
certificado. Por tanto, si un desconocido comunica con el tercero
usando la clave privada correspondiente a la clave pública del
certificado digital, el tercero puede confiar, en adelante, en que
el desconocido sea el suscriptor mencionado en el certificado
digital. Si el tercero carece de base para confiar en la AC, podrá
establecer tal base merced a la autenticación del certificado
digital de la AC. El tercero continuará autenticando certificados
digitales, recorriendo una cadena de certificados digitales
expedidos a autoridades de certificación, hasta llegar a una AC en
la que confíe, en cuyo momento, el tercero puede confiar en que la
clave pública del certificado digital esté asociada con el
suscriptor del certificado.
Preferiblemente, los certificados digitales
cumplen con el formato definido por ITU Recommendation X.509 (1997
E): Information Technology - Open Systems Interconnection - The
Directory: Authentication Framework (Recomendación X.509 de
International Telecommunication Union (1997 E): (Tecnología de
Información - Interconexión de sistemas abiertos - Directorio:
Esquema de Autenticación), junio de 1997. El certificado digital
puede almacenarse en cualquier tipo de medio leíble mediante
ordenador, incluyendo, de modo no limitativo, discos duros, tarjetas
de microcircuito, memoria flash, bandas magnéticas, tales como las
de la parte posterior de las tarjetas de crédito, o como códigos de
barras impresos.
Por seguridad y otras razones, los certificados
digitales, típicamente, son válidos, solamente, durante un periodo
de tiempo limitado. Por ejemplo, cuando se expiden certificados
digitales, éstos pueden incluir una fecha efectiva y una fecha de
expiración, siendo el certificado digital válido, solamente, entre
estas fechas. Por otro lado, si un certificado digital se encuentra
en compromiso con anterioridad a su fecha de expiración, puede ser
revocado, incluyéndose el certificado digital en una lista de
revocación de certificados.
Una ICP es un sistema para proporcionar
seguridad que usa criptografía de clave pública y certificados
digitales. Ciertos servicios se usan para establecer, difundir,
mantener y atender las claves públicas y los certificados digitales
asociados usados en una ICP. Estos servicios son proporcionados por
entidades que se denominarán proveedores de servicios. Por
seguridad, eficacia y otras razones, los proveedores de servicios a
menudo son AC, y deben serlo para poder proporcionar ciertos
servicios. Ejemplos de tales servicios incluyen la expedición de
nuevos certificados digitales, la comprobación de la validez de
certificados digitales, la generación de firmas digitales, y/o el
mantenimiento de registros de transacciones que utilicen la ICP.
La figura 1 es un diagrama de bloques de un
sistema ilustrativo 100 de acuerdo con la presente invención. El
sistema 100 incluye un usuario 110 solicitante, un usuario confiante
120, y un proveedor 130 de servicio de infraestructura de clave
pública (ICP), que se comunican entre sí. Opcionalmente, el sistema
100 incluye una base de datos 140 de registros de transacciones
accesible para el proveedor 130 de servicios.
Los usuarios 110 y 120 pueden ser individuos,
grupos de individuos, entidades legales, tales como corporaciones,
ordenadores o similares. El proveedor 130 de servicio es una entidad
que proporciona servicios asociados con el funcionamiento de una
ICP. En este ejemplo particular, el proveedor 130 de servicio ofrece
servicios de notaría digital con el fin de generar y,
subsiguientemente, verificar registros de transacciones. Los
registros del proveedor 130 de servicio son almacenados en una base
de datos 140, que, típicamente es mantenida con gran seguridad y
gran fiabilidad, con objeto de mejorar la fiabilidad de los
registros de la base de datos 140 y de los servicios ofrecidos por
el proveedor 130 de servicio.
Los usuarios 110 y 120 comunican con el
proveedor 130 de servicio y, también, pueden comunicar entre sí. Las
conexiones de las comunicaciones pueden realizarse merced a medios
cualesquiera, incluyendo redes de ordenadores tales como Internet
y/o conexiones inalámbricas. Las conexiones no tienen que ser
permanentes o continuas. En una realización preferida, los usuarios
110 y 120 emplean navegadores de red estándar para comunicar, a
través de Internet, con el servidor de red del proveedor 130 de
servicio, usando el protocolo HTTP.
El usuario solicitante 110 desea realizar un
registro de una transacción y solicita al proveedor 130 de servicio
que lo haga. Después, el usuario confiante 120 quiere verificar que
se ha producido la transacción y lo hace confiando en el registro
generado por el proveedor 130 de servicio. El proveedor 130 de
servicio puede ofrecer seguridad adicional tratando el registro con
el fin de verificar la autenticidad del registro o de la transacción
subyacente. A modo de ejemplo, la transacción puede ser la compra de
un artículo en modo de conexión, realizando el proveedor 130 de
servicio un registro para atestiguar la compra. Alternativamente, la
transacción puede ser la existencia de un documento, realizando el
proveedor 130 de servicio un registro para atestiguar el contenido
del documento en un momento específico. En este caso, el proveedor
130 de servicio representa, esencialmente, la función de notario
digital.
El término "transacción" se usa en sentido
amplio. Incluye acontecimientos, tales como una compra de bienes en
modo de conexión o la firma electrónica de un contrato, así como
documentos. El ejemplo de la figura 2 se ilustra en el contexto de
la generación de un registro de una "transacción" en el sentido
general del término. La realización preferida de las figuras
4-8 usa un ejemplo de notaría, en el que atestiguar
la "transacción" significa atestiguar la existencia de un
documento específico en un momento específico. La realización
preferida de la figura 9 usa un ejemplo en el que la transacción es
una compra en modo de conexión. Pero debe entenderse que los
principios ilustrados es estos dos últimos ejemplos son aplicables,
también, a otros tipos de transacciones. El término "documento"
se usa, también, en sentido amplio. Incluye cualquier tipo de
contenido electrónico, por ejemplo, archivos de audio o video,
código de lógica, animaciones y archivos de datos, además de las
versiones electrónicas de documentos de papel tradicionales.
Las figuras 2A y 2B son trazas de
acontecimientos que muestran el funcionamiento del sistema 100. La
figura 2A ilustra la generación 200 de un registro, por la que el
proveedor 130 de servicio genera un registro digital de la
transacción para el usuario solicitante 110. La figura 2B muestra la
verificación 250 del registro, merced a la cual el proveedor 130 de
servicio (que podría ser un proveedor de servicio diferente)
verifica el registro digital y/o la transacción subyacente para el
usuario confiante 120 (que podría coincidir con el usuario
solicitante 110). No todas las ejecuciones utilizarán ambas etapas
200 y 250 o todos los pasos individuales mostrados, pero se incluyen
todos con el fin de ilustrar distintos aspectos de la invención.
En las figuras 2A y 2B, cada uno de las cuadros
con línea de trazos 110, 120 y 130 representan uno de los
componentes del sistema 100. Las cuadros con líneas continuas
representan distintos pasos de los métodos. La posición de un cuadro
con línea continua dentro de un cuadro con línea de trazos indica
que, en general, el paso es ejecutado por ese componente. Por
ejemplo, el paso 210 está ubicado dentro del cuadro con línea de
trazos del usuario solicitante 110. Ello indica que el usuario
solicitante 110, en general, ejecuta el paso 210 de transmitir una
solicitud al proveedor 130 de servicio. Pero, como resultará claro a
partir de los ejemplos que siguen, no debe entenderse que ello
suponga que el proveedor 130 de servicio no juegue papel alguno. Por
ejemplo, llenar la solicitud puede ser una actividad interactiva que
involucre al usuario 110 y al proveedor 130 de servicio, y, como
mínimo, el proveedor 130 de servicio recibirá la solicitud
transmitida por el usuario 110. Preferiblemente, los pasos se ponen
en práctica mediante lógica que se ejecute en los diversos
componentes del sistema 100, posiblemente con la asistencia de
módulos de equipos especializados. Pueden ponerse en práctica,
también, mediante equipos y/o microprogramas.
Con referencia a la figura 2A, el usuario
solicitante 110 empieza transmitiendo 210 al proveedor 130 de
servicio una solicitud de creación de un registro digital de una
transacción. Típicamente, la solicitud incluye una descripción de la
transacción en formato inteligible. Por ejemplo, el usuario
solicitante 110 podría crear una breve descripción de texto de la
transacción o enviar un icono que represente la transacción, o puede
generarse, automáticamente, un breve compendio de la transacción
cuando ésta se produzca. La solicitud incluye, también, información
que debe ser tratada por el proveedor 130 de servicio cuando genere
el registro digital. Esta información puede transmitirse en formatos
estándar con el fin facilitar su tratamiento, y puede ser
ininteligible. En el marco de una compra en modo de conexión, esta
información podría incluir detalles de la transacción y/o la
confirmación de que la transacción se ha producido, por ejemplo,
número de tarjeta de crédito, total de compra, código de
autorización de tarjeta de crédito, etc. En el caso de una firma de
contrato en modo de conexión, podrían incluirse los certificados
digitales o información similar de las partes firmantes. En el caso
de notaría de documento, podría incluirse el propio documento.
El proveedor 130 de servicio recibe 210 la
descripción inteligible y la información adicional. El proveedor
trata la información adicional con el fin de generar 220 una prueba
infalsificable de que la transacción (por ejemplo, una firma
digital) se ha producido. Preferiblemente, la prueba infalsificable
no puede ser modificada posteriormente sin que se detecte la
modificación. Por ejemplo, el proveedor de servicio podría ofrecer
funciones de marca de tiempo, picado y/o firma digital como parte de
este tratamiento. Asimismo, podría incorporar información adicional
de otras fuentes. El tipo exacto de tratamiento y prueba generada
dependerá de la aplicación específica. El proveedor de servicio
almacena 240 un registro de la transacción, preferiblemente, en su
base de datos 140. En una realización preferida, este registro
incluye la descripción inteligible proporcionada 210 por el usuario
solicitante 110, la prueba infalsificable generada 220 por el
proveedor 130 de servicio, y, también, información relativa a la
solicitud del usuario 110 de generación de un registro digital y la
identidad del usuario 110.
Asimismo, el proveedor 130 de servicio genera
230 un segundo registro digital de la transacción, del que se
muestra un ejemplo en la figura 3. Por conveniencia, este registro
digital se denominará recibo digital. Típicamente, el recibo digital
300 incluye una descripción 310 de la transacción. Por ejemplo,
podría incluir, total o parcialmente, la descripción inteligible
recibida del usuario solicitante 110. El recibo digital incluye,
también, la prueba infalsificable 320 generada por el proveedor 130
de servicio. En una realización, se incluye la propia prueba
infalsificable 320 como parte del recibo digital. En un enfoque
alternativo, la prueba infalsificable 320 se incluye por alusión,
por ejemplo, merced a la inclusión un enlace con la prueba, como
parte del recibo digital. En una realización preferida, la prueba
320 se incluye en el recibo digital pero se oculta de modo que no
puedan verla los usuarios, puesto que, a menudo, la prueba será
ininteligible. El recibo digital 300 incluye, también, una propuesta
330 de verificación. Cuando se activa la propuesta 330 de
verificación se inicia el proceso de verificación de la prueba
infalsificable 320. Se hace notar que en este proceso, no hay
necesidad de nadie identifique afirmativamente la prueba que haya de
verificarse, puesto que el propio recibo digital 300 identifica la
prueba 320. En una realización, la activación de la propuesta 330 de
verificación transmite la prueba 320 al proveedor 130 de servicio
para su verificación contra la base de datos 140 de éste. En una
realización alternativa, ello da lugar a cálculos locales de
verificación de la prueba 320. Con referencia de nuevo a la figura
2A, una vez que el proveedor 130 de servicio haya generado 230 el
recibo digital, éste es transmitido 235 al usuario solicitante 110,
que, típicamente, lo almacena 237 para su uso posterior. En una
realización, la lógica del usuario solicitante almacena 237 el
recibo digital, transparente para el usuario 110 solicitante.
La figura 2B muestra un ejemplo del modo en que
un usuario confiante 120 usaría el recibo digital 300 para verificar
que se ha producido la transacción. El usuario confiante 120 accede
260 al recibo digital 300. Por ejemplo, el usuario solicitante 110
podría enviar un correo electrónico o transmitir de otro modo una
copia del recibo 300 al usuario confiante 120 o éste podría
solicitar el recibo 300 al proveedor 130 de servicio u obtener el
recibo 300 a partir de una base de datos o directorio central.
Cuando se presente 265 el recibo 300, el usuario confiante 120 puede
ver la descripción 310 de la transacción y la propuesta 330 de
verificación. Asimismo, el usuario 120 puede ver la prueba
infalsificable 320, pero no necesariamente, puesto que, de modo
preferido, la prueba 320 se oculta para que no pueda verse. El
usuario confiante activa 270 la propuesta 330 de verificación, lo
que inicia el proceso de verificación. En este ejemplo particular,
la prueba infalsificable 320 se obtiene a partir del recibo digital
y se envía 280 al proveedor 130 de servicio, que compara 290 la
prueba recibida 320 con el registro correspondiente de la base de
datos 140. Si hay coincidencia, se verifica la prueba 320. De otro
modo, no hay verificación (suponiendo que la prueba no haya sido
verificada por otros medios). En cualquier caso, el resultado es
enviado 295 al usuario confiante 120. En una realización preferida,
si la prueba 320 es verificada, se presenta una segunda propuesta de
verificación. La activación 202 de esta propuesta permite al usuario
confiante 120 avanzar un paso y verificar 204 la transacción
subyacente (por ejemplo, verificar la integridad del documento
subyacente, en el marco de la notaría digital).
Se hace notar que el recibo digital 300 incluye
tanto una propuesta 330 de verificación como la prueba
infalsificable 320 que haya de verificarse. Por ello, en cierto modo
es autosuficiente, y, de alguna manera,
"auto-verificante". Esta es una ventaja
significativa puesto que hace el recibo digital 300 más fácil e
intuitivo de usar. Por ejemplo, no hay necesidad de que el usuario
solicitante 120 identifique independientemente la prueba concreta
que tenga que verificarse. A modo de ejemplo adicional, si el recibo
digital no incluye la propuesta 330 de verificación, serían
necesarias lógica o instrucciones separadas para verificar la prueba
320. Ello aumentaría la complejidad, puesto que el usuario
confiante 120 podría no conocer o no tener acceso a la lógica e
instrucciones necesarias, particularmente desde el momento en que el
usuario confiante 120 y el usuario solicitante 110, probablemente,
serían entidades diferentes y podrían usar proveedores de servicio
diferentes con sistemas incompatibles. Aún cuando el usuario
confiante 120 haya usado la misma lógica, simplemente, podría no
estar disponible en ese momento. Por ejemplo, la lógica podría
residir en un ordenador y el recibo digital 300 en otro. Al incluir
la prueba infalsificable 320 y la propuesta 330 de verificación en
la misma posición, se evitan estos problemas. Por otro lado, la
inclusión de la descripción inteligible 310 simplifica
adicionalmente el uso del recibo digital 300, puesto que proporciona
una etiqueta significativa del recibo
digital.
digital.
Las figuras 4-8 ilustran una
realización preferida del sistema 100 y del método 200, a través de
un sistema basado en el HTTP, específicamente, Internet. Los
usuarios 110 y 120 acceden a Internet usando lógica de navegación
convencional. El proveedor 130 de servicio intercomunica con
Internet a través de un servidor de red. El usuario solicitante 110
desea realizar un registro de la existencia de un documento
específico en un momento específico. En esencia, el usuario
solicitante 110 busca un notario digital y esta función es ofrecida
por el proveedor 130 de servicio. Después, el usuario confiante 120
desea verificar la "certificación notarial" reivindicada por el
usuario solicitante 110, y, quizás, también, el contenido del
documento específico. Al igual que el método 200, el método 400
puede dividirse, más o menos, en dos etapas: generación 400 de
registro y verificación 450 de registro, como se ilustra,
respectivamente, en las figuras 4A y 4B.
Con referencia a la figura 4A, el usuario
solicitante 110 empieza enviando 410 al proveedor 130 de servicio
una solicitud de generación de un registro digital de una
transacción. En esta realización el usuario solicitante 110 lo hace
visitando 412 el sitio web del proveedor 130 de servicio en una
dirección de Internet con protocolo Secure Sockets Layer (SSL URL)
que ofrezca el servicio de certificación notarial. El usuario 110 se
autentica 414 a sí mismo ante el proveedor 130 de servicio mediante
un certificado digital y el par de claves correspondiente. Para los
fines del servicio de certificación notarial, la identidad del
usuario solicitante 110 queda definida mediante el certificado
digital. El usuario 110 navega 416 por el sitio web del proveedor
130 de servicio con el fin de seleccionar el servicio de
certificación notarial digital y solicita el servicio llenando y
presentando 418 el formulario HTML 500 mostrado en la figura 5. En
esta realización, el formulario 500 puede conseguirse en el sitio
web del proveedor 130 de servicio. En realizaciones alternativas
puede ponerse en práctica la misma capacidad funcional mediante
otros formularios provenientes de otras fuentes o mediante una
función integrada en una aplicación (por ejemplo, como botón
"notaría" incorporado en una barra de herramientas de una
aplicación de tratamiento de textos o en el controlador de
impresión). En el formulario 500 el usuario 110 identifica el
documento que debe certificarse notarialmente en el cuadro 510 y,
también, incluye una descripción del documento en el cuadro 520.
Cuando es presentada 418, esta información es firmada digitalmente
por el usuario 110 y enviada al proveedor 130 de servicio. Además
del nombre 510 y de la descripción 520 del documento, se envía al
proveedor 130 de servicio, también, el propio documento.
A partir de la información recibida del usuario
110, el proveedor 130 de servicio genera 420 una prueba
infalsificable del documento que, en este ejemplo, es un indicador
de marca de tiempo generado como sigue. El proveedor 130 de servicio
calcula 422 un picado del documento recibido (por ejemplo, usando el
algoritmo de picado SHA-1) y, entonces, genera 424
un indicador de marca de tiempo del picado. En una realización
preferida, el proveedor de servicio genera 424 el indicador de marca
de tiempo solicitando uno a una autoridad de marcado de tiempo de
confianza. El indicador de marca de tiempo incluye el picado del
documento, la marca de tiempo, información que identifique la
autoridad de marcado de tiempo y la firma digital de la autoridad de
marcado de tiempo de todo lo anterior. En una realización preferida,
el indicador de marca de tiempo cumple el protocolo descrito en el
borrador del Grupo de trabajo de ingeniería de Internet (Internet
Engineering Task Force's) titulado "Internet X.509 Public Key
Infrastructure, Time Stamp Protocol (TSP),
draft-ietf-pkix-time-stamp"
(Infraestructura de clave pública X.509 de Internet, protocolo de
marca de tiempo, borrador de marca de tiempo para certificados
X.509). En realizaciones alternativas, la prueba puede adoptar otras
formas. Por ejemplo, el aspecto de marcado de tiempo puede omitirse
o puede usarse una huella digital del documento diferente de un
picado. Preferiblemente, la huella digital del documento identifica,
únicamente, al documento.
El proveedor 130 de servicio almacena 440 un
registro de la certificación notarial en su base de datos 140. Este
registro incluye la solicitud de certificación notarial del usuario
110 (que fue firmada digitalmente por el usuario 110), la identidad
del usuario 110, el picado del documento y el indicador de marca de
tiempo.
\global\parskip0.900000\baselineskip
El proveedor 130 de servicio genera 430,
también, un recibo digital de la transacción, para su transmisión al
usuario solicitante 110. La figura 7 muestra un ejemplo de este
recibo digital 700. Se trata de un documento HTML que incluye, como
elementos visibles, lo siguiente: el nombre 710 y la descripción 720
del documento, recibidos del usuario solicitante 110, y el tiempo
730 de la marca de tiempo. El recibo digital 700 incluye, también,
un formulario. El indicador de marca de tiempo se codifica en
formato de texto BASE64 y se integra en el formulario como campo
oculto del mismo, y, por tanto, no aparece en la presentación del
recibo digital 700. El formulario del recibo digital 700 incluye,
también, un botón 740 "Verificar recibo" (mostrado como botón
en esta realización, pero puede preverse, también, como elemento
diferente activado por el usuario). En una realización preferida,
el formulario incluido en el recibo digital 700 presenta la
estructura siguiente:
<método de formulario = enviar acción =
"https://proveedorservicio.com/">
- <tipo de entrada = valor "oculto" = "V1">
- <tipo de entrada = presentar valor = "Verificar">
</formulario>
"https://proveedorservicio.com/" es la SSL
URL del proveedor 130 de servicio. El valor "V1" es la versión
codificada en formato BASE64 del indicador de marca de tiempo.
Pueden usarse otros campos que soporten otras funciones o
proporcionen más información. Por ejemplo, el usuario solicitante
110 puede identificarse, también, en el recibo digital
700.
En una realización preferida, el recibo digital
700 no se genera automáticamente ni se envía al usuario 110
solicitante. En lugar de ello, el proveedor 130 de servicio envía
432 el resultado de la certificación notarial al usuario 110, como
se muestra en la figura 6. Si la certificación notarial tuvo éxito,
la pantalla 600 de resultados pregunta, también, al usuario 110 si
desea una copia del recibo digital 700. Si el usuario 110 solicita
434 una copia (por ejemplo, en este caso, haciendo clic en el botón
610), el proveedor de servicio genera 436 el recibo digital 700 y lo
transmite 435 al usuario 110. El usuario 110 solicitante almacena
437 el recibo digital 700, por ejemplo, en su disco duro local.
La figura 4B ilustra un ejemplo del modo en que
un usuario confiante 120 usaría el recibo digital 700 para verificar
la certificación notarial. El usuario confiante 120 accedería 460 al
recibo digital 700. El usuario 120 podría tener acceso a la copia
del recibo 700 guardado por el usuario solicitante 110.
Alternativamente, el usuario 120 podría recibir una copia del
usuario solicitante 110 o del proveedor 130 de servicio. En un marco
alternativo, el usuario solicitante 110 anunciaría el recibo digital
y el documento subyacente por Internet. Por ejemplo, el usuario
solicitante 110 podría ser una compañía que publique comunicados de
prensa y anuncie el comunicado de prensa y el recibo digital en su
sitio web, de manera que los interesados puedan verificar la
autenticidad del comunicado de prensa.
El usuario confiante 120 abre 465 el recibo
digital 700, que incluye el formulario HTML, usando su navegador.
Como se ha mencionado anteriormente, la presentación del recibo
digital incluye el nombre 710 y la descripción 720 del documento, el
tiempo 730 para la marca de tiempo, y un botón 740 "Verificar
recibo".
Al hacer clic 470 en el botón 740 se transmite
480 el indicador de marca de tiempo, integrado en el formulario HTML
como texto oculto, al proveedor 130 de servicio. En esta
realización, el texto oculto es enviado 480 al proveedor 130 de
servicio. El proveedor 130 de servicio descodifica 484 el texto en
formato BASE64 con el fin de recuperar el indicador de marca de
tiempo original. Verifica 482 la fiabilidad del indicador de marca
de tiempo examinando la firma digital y, luego, compara 490 el
indicador de marca de tiempo recuperado con los de su propia base de
datos 140. Se verifica si el indicador de marca de tiempo coincide
exactamente con el de la base de datos del proveedor 130 de
servicio. El proveedor 130 de servicio envía 495 el resultado de la
comparación al usuario confiante 120, verificando o no, de ese modo,
la fiabilidad del recibo digital 700.
Si el recibo digital 700 es verificado, el
proveedor 130 de servicio envía, también, la identidad del usuario
solicitante 110, el nombre original del documento 810, la
descripción del documento 820 y el tiempo 830 de la marca de tiempo,
obtenido a partir de la base de datos 140 del proveedor 130 de
servicio, como se muestra en la figura 8. La respuesta 800 incluye,
también, un formulario con una segunda propuesta 840 de
verificación, que permite al usuario confiante 120 avanzar un paso y
verificar el documento subyacente, además de verificar la
certificación notarial.
Debe hacerse notar que, hasta ahora, solamente
ha sido verificado el recibo digital 700 pero no el propio documento
subyacente. Además, el proveedor 130 de servicio no proporciona una
copia del documento ni almacena una copia del mismo en esta
realización, aunque podría hacerlo en realizaciones alternativas. Si
el usuario confiante 120 desea confiar en el contenido del
documento, es posible que desee, primero, verificar la integridad de
esos documentos. Puede hacerlo usando el botón 840 "Verificar
documento". Por ejemplo, si se pone de manifiesto que el
documento
D:\documentos\doc-listados\ListaPreciosVenta.doc es
el mismo que el documento certificado notarialmente, el usuario
confiante 120 identifica el documento usando el campo 850
"Buscar" y, a continuación, hace clic 402 en el botón 840
"Verificar documento". De ese modo se envía 404 el documento
D:\documentos\doc-listados\ListaPreciosVenta.doc al
proveedor 130 de servicio. La información usada para identificar el
indicador de marca de tiempo es enviada, también, al proveedor 130
de servicio. Por ejemplo, en una realización preferida, el número de
serie del indicador de marca de tiempo y el picado del documento
(obtenido a partir de la base de datos del proveedor de servicio) se
integran en la respuesta 800 como campos de formulario ocultos y se
envían al proveedor 130 de servicios cuando se activa el botón 840
"Verificar documento". El proveedor 130 de servicio pica 406 el
documento recibido. El picado recién generado se compara 408 con el
picado del indicador de marca de tiempo, devolviéndose 409 el
resultado al usuario confiante 120. Si ambos picados coinciden,
existe una buena base para creer que el documento recibido es el
mismo que el original. Si los picados no coinciden, hay razones para
creer que el documento ha sido modificado.
En una realización alternativa, el propio
documento se incluye como parte del recibo digital, y, de ese modo,
puede ser verificado al mismo tiempo que el recibo digital. La
figura 9 es un ejemplo de recibo digital 900 que ilustra este
enfoque. En este ejemplo, Greg Whitehead ha comprado el equipo Copa
Acelerador por \text{dollar}59,95. Como prueba de esta
transacción, se genera el documento 910 y, también, una marca de
tiempo del documento. El recibo digital 900 de esta transacción
incluye el documento 910 como elemento visible. De modo más preciso,
el documento 910 puede existir, originalmente, como documento HTML
separado independiente. Típicamente, no se incluye este documento
original completo en el recibo digital 900. Por ejemplo, no son
necesarias, como mínimo, las etiquetas de principio y fin del
documento original HTML. Así, típicamente, cierto grado de
reformateo y, posiblemente, también, de revisión tiene lugar cuando
se integra el documento HTML 910 en el recibo digital 900. Debe
entenderse que éste es generalmente el caso, aunque la distinción no
volverá a mencionarse explícitamente.
En una realización, el recibo digital incluye,
también, un formulario HTML y el documento 910 se codifica en
formato de texto BASE64 y se integra en el formulario como campo
oculto. El recibo digital 900 incluye, también, código javascript,
que descodifica y presenta el texto oculto en formato BASE64, que es
por lo que el documento 910 puede verse en el recibo digital 900. En
este ejemplo, el documento 910 sirve, también, como descripción de
la transacción. El formulario del recibo digital 900 incluye,
también, el indicador de marca de tiempo, pero éste está codificado
en formato de texto BASE64 e integrado en el formulario como campo
oculto y, por tanto, no aparece en la presentación del recibo
digital 900. El formulario incluye, también, un botón 940
"Verificar recibo". En una realización preferida, el formulario
se ejecuta como sigue:
<método de formulario = enviar acción =
"https://proveedorservicio.com/">
- <tipo de entrada = valor "oculto" = "V1">
- <tipo de entrada = valor "oculto" = "V2">
- <tipo de entrada = presentar valor = "Verificar">
</formulario>
"https://proveedorservicio.com/" es la SSL
URL del proveedor 130 de servicio. El valor "V1" es la versión
codificada en formato BASE64 del indicador de marca de tiempo y el
valor "V2" es la versión codificada en formato BASE64 del
documento 910. En una realización alternativa, los valores "V1"
y "V2" son enlaces con el indicador de marca de tiempo y el
documento, respectivamente, en lugar del indicador y del documento
reales.
Al hacer clic en el botón 940 se envían los
valores V1 y V2 (es decir, las versiones codificadas en BASE64 del
indicador de marca de tiempo y del documento 910) al proveedor 130
de servicio. El proveedor 130 de servicio descodifica el texto en
formato BASE64, con el fin de recuperar el indicador de marca de
tiempo y el documento 910 originales. Verifica la fiabilidad del
indicador de marca de tiempo examinando la firma digital y compara
el indicador de marca de tiempo recuperado con los de su propia base
de datos 140. El proveedor 130 de servicio verifica, también, la
autenticidad del documento 910. El proveedor 130 de servicio envía
el resultado de estas comparaciones al usuario confiante 120,
verificando o no, de ese modo, la fiabilidad del recibo digital 900,
que incluye el documento 910. En una realización alternativa,
algunos cálculos, o todos, (por ejemplo, verificar la autenticidad
del documento 910) pueden tener lugar localmente en los equipos del
cliente del usuario confiante 120.
En una variante de este enfoque, en lugar de que
el recibo digital contenga el indicador de marca de tiempo, el
documento subyacente y el botón de verificación, estos tres
elementos se publican en Internet separadamente, como se muestra en
la figura 10. En la figura 10, el documento subyacente 1010, un
comunicado de prensa, se presenta en una ubicación. Un "recibo de
notaría" 1020, que contiene el indicador de marca de tiempo, se
presenta separadamente; también se presenta por separado un
"sello" 1030, que es un formulario que contiene el botón 1040
de verificación y enlaces con el documento y el indicador de marca
de tiempo. En este ejemplo, la posición física se usa para indicar
que el recibo 1020 de notaría y el sello 1030 corresponden a un
comunicado de prensa 1010. Aunque la posición física parece
diferente, la activación del botón 1040 de verificación tiene el
mismo efecto que la activación del botón de verificación de los
ejemplos precedentes. Específicamente, tanto el indicador de marca
de tiempo como el documento subyacente son enviados al proveedor 130
de servicio para su verificación. En otros términos, el sello 1030,
en este caso, cumple la misma función que los recibos digitales 700
y 900 en relación con la iniciación del proceso de verificación.
Aunque la invención ha sido descrita con
considerable detalle en relación con ciertas realizaciones
preferidas de la misma, resultarán evidentes otras realizaciones.
Por ejemplo, las figuras 4-10 se han descrito en el
contexto de documentos HTML, pero son adecuados para uso, también,
XML y otros lenguajes de marcas estándar. En una realización que usa
XML, se define un documento tipo para el recibo digital, y se
muestran tipos de elementos, atributos, entidades y notaciones en
relación con el contenido del recibo digital. En una realización
alternativa pueden usarse, también, archivos binarios con campos en
dichos archivos definidos para ofrecer funciones similares. De modo
ilustrativo, casi todos los ejemplo han sido descritos en el
contexto de los propios documentos y los indicadores de marca de
tiempo, (o, de modo más general) en el contexto de las transacciones
y las pruebas correspondientes). Pero como se ilustra en algunos de
los ejemplos, otras ejecuciones pueden usar, alternativamente,
referencias o enlaces. Además, las funciones pueden ponerse en
práctica en modo de desconexión o mediante tratamientos por tandas.
Por tanto, el ámbito de las reivindicaciones adjuntas no debe
limitarse a la descripción de las realizaciones preferidas
contenidas en este documento.
Claims (29)
1. Un medio leíble mediante ordenador destinado
a servir de registro de la existencia de una transacción,
almacenando el medio leíble por ordenador:
- un recibo digital de la transacción susceptible de ser presentado a un usuario, comprendiendo el recibo digital:
- una descripción de la transacción en formato inteligible;
- una prueba infalsificable de que se ha producido la transacción; y
- una propuesta de verificación de la prueba infalsificable, sin necesidad de interacción humana adicional para su identificación,
en el que:
- la transacción consiste en la existencia de un documento en un momento específico;
- el recibo digital incluye un formulario en un lenguaje de marcas estándar, incluyendo el formulario el documento, codificado como texto oculto;
- la descripción de la transacción comprende:
- un nombre que identifique el documento, y
- un tiempo que identifique el momento específico;
- la prueba infalsificable comprende un indicador de marca de tiempo firmado digitalmente, codificado como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo:
- una huella digital del documento, y
- la marca de tiempo del documento; y
- la propuesta de verificación comprende, en el formulario, un elemento activado por el usuario, de modo que la activación de dicho elemento transmita el texto oculto de la prueba infalsificable y el texto oculto del documento a un proveedor de servicio, para su verificación.
2. El medio leíble por ordenador de la
reivindicación 1, en el que, cuando se presenta el recibo digital,
se presentan la descripción de la transacción y la propuesta de
verificación, pero no se presenta la prueba infalsificable.
3. El medio leíble por ordenador de la
reivindicación 1, en el que la prueba infalsificable comprende una
huella digital de la transacción.
4. El medio leíble por ordenador de la
reivindicación 1, en el que la prueba infalsificable comprende una
firma digital.
5. El medio leíble por ordenador de la
reivindicación 1, en el que la prueba infalsificable comprende la
marca de tiempo de la transacción.
6. El medio leíble por ordenador de la
reivindicación 1, en el que la prueba infalsificable se incluye en
el recibo digital por alusión.
7. El medio leíble por ordenador de la
reivindicación 1, en el que el lenguaje del recibo digital es un
lenguaje de marcas estándar.
8. El medio leíble por ordenador de cualquiera
de las reivindicaciones 1 a 7, en el que:
- cuando se presenta el recibo digital, un script descodifica y presenta el documento.
9. El medio leíble por ordenador de cualquiera
de las reivindicaciones 1 a 7, en el que el documento se incluye en
el recibo digital por alusión.
10. Un método para generar un registro de la
existencia de una transacción, que comprende:
- recibir la demanda de un usuario solicitante de generación de un recibo digital de la transacción;
- generar la prueba infalsificable de que se ha producido la transacción; y
- generar un recibo digital de la transacción susceptible de ser presentado a un usuario, comprendiendo el recibo digital:
- una descripción de la transacción en un formato inteligible;
- la prueba infalsificable de que la transacción ha tenido lugar; y
- una propuesta de verificación de la prueba infalsificable, sin necesidad de interacción humana adicional para su identificación,
en el que
- la transacción consiste en la existencia de un documento en un momento específico;
- el recibo digital incluye un formulario en un lenguaje de marcas estándar; y
- el paso de generar el recibo digital comprende:
- incluir un nombre que identifique el documento y un tiempo que identifique el momento específico, como parte de la descripción de la transacción;
- codificar un indicador de marca de tiempo firmado digitalmente como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo una huella digital del documento y la marca de tiempo del documento, y
- poner en práctica la propuesta de verificación como elemento activado por el usuario, en el formulario, de modo que la activación de dicho elemento transmita el texto oculto a un proveedor de servicio, para su verificación.
11. El método de la reivindicación 10, en el que
cuando se presenta el recibo digital, se presentan la descripción de
la transacción y la propuesta de verificación, pero no se presenta
la prueba infalsificable.
12. El método de la reivindicación 10, en el que
la prueba infalsificable se incluye en el recibo digital por
alusión.
13. El método de la reivindicación 10, en el que
el paso de generar la prueba infalsificable de la existencia de la
transacción comprende:
- recibir de un tercero la prueba infalsificable.
14. El método de la reivindicación 10, en el que
el paso de generar un recibo digital comprende generar el recibo
digital en un lenguaje de marcas estándar.
15. El método de cualquiera de las
reivindicaciones 10 a 14, en el que el paso de generar un recibo
digital comprende:
- codificar el documento como texto oculto en el recibo digital;
- incluir un script en el recibo digital; y
cuando se presenta el recibo digital, el script
descodifica y presenta el documento.
16. El método de cualquiera de las
reivindicaciones 10 a 15, en el que el documento se incluye en el
recibo digital por alusión.
17. El método de la reivindicación 10, que,
además, comprende:
- transmitir el recibo digital al usuario solicitante.
18. Un aparato para generar un registro de la
existencia de una transacción, comprendiendo dicho aparato:
- medios para recibir una solicitud de generación de un recibo digital de la transacción;
- medios para generar una prueba infalsificable de la existencia de la transacción; y
- medios para generar un recibo digital de la transacción, susceptible de ser presentado a un usuario,
- comprendiendo el recibo digital:
- una descripción de la transacción en un formato inteligible;
- la prueba infalsificable de la existencia de la transacción; y
- una propuesta de verificación de la prueba infalsificable, sin necesidad de interacción humana adicional para su identificación,
en el que
- la transacción consiste en la existencia de un documento en un momento específico;
- el recibo digital incluye un formulario en un lenguaje de marcas estándar;
- la descripción de la transacción comprende:
- un nombre que identifique el documento, y
- un tiempo que identifique el momento específico;
- la prueba infalsificable comprende un indicador de marca de tiempo firmado digitalmente, codificado como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo:
- una huella digital del documento, y
- la marca de tiempo del documento; y
- la propuesta de verificación comprende, en el formulario, un elemento activado por el usuario, de modo que la activación de dicho elemento transmita el texto oculto a un proveedor de servicio para su verificación.
19. El aparato de la reivindicación 18, en el
que:
- el lenguaje del recibo digital es un lenguaje de marcas estándar.
20. El aparato de las reivindicaciones 18 o 19,
en el que:
- el documento es codificado como texto oculto; y
- cuando se presenta el recibo digital, un strip descodifica y presenta el documento.
21. Un producto de programa de lógica para
generar un registro de la existencia de una transacción, controlando
el producto de programa de lógica el funcionamiento de un procesador
merced a la ejecución de la lógica por parte del procesador,
ejecutando la lógica los pasos de:
- recibir una solicitud de creación del recibo digital de una transacción;
- generar una prueba infalsificable de la existencia de la transacción; y
- generar un recibo digital de la transacción susceptible de ser presentado a un usuario, comprendiendo el recibo digital:
- una descripción de la transacción en formato inteligible;
- la prueba infalsificable de la existencia de la transacción; y
- una propuesta de verificación de la prueba infalsificable, sin necesidad de interacción humana adicional para su identificación,
en el que:
- la transacción consiste en la existencia de un documento en un momento específico;
- el recibo digital incluye un formulario en un lenguaje de marcas estándar;
- el paso de generar el recibo digital comprende:
\newpage
- incluir un nombre que identifique el documento y un momento que identifique el tiempo específico, como parte de la descripción de la transacción;
- codificar un indicador de marca de tiempo firmado digitalmente como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo una huella digital del documento y la marca de tiempo del documento; y
- la propuesta de verificación se lleva a la práctica como elemento activado por el usuario en el formulario, de modo que la activación de dicho elemento transmita el texto oculto a un proveedor de servicio para su verificación.
22. El producto de programa de lógica de la
reivindicación 21, en el que:
- el lenguaje del recibo digital es un lenguaje de marcas estándar.
23. El producto de programa de lógica de la
reivindicación 21, en el que:
- el recibo digital incluye, además, un script;
- el paso de generar un recibo digital comprende:
- codificar el documento como texto oculto en el recibo digital, de modo que, cuando se presente el recibo digital, el script descodifique el texto oculto y presente el documento.
24. Un método para verificar que se ha producido
una transacción, comprendiendo dicho método:
- presentar un recibo digital de la transacción, comprendiendo el recibo digital:
- una descripción de la transacción en un formato inteligible;
- una prueba infalsificable de la existencia de la transacción;
- una propuesta de verificación; y
- activar la propuesta de verificación, de modo que la prueba infalsificable se verifique sin necesidad de interacción humana adicional para su identificación,
en el que:
- la transacción consiste en la existencia de un documento en un momento específico; y
- la prueba infalsificable comprende un indicador de marca de tiempo firmado digitalmente, que comprende:
- una huella digital del documento; y
- la marca de tiempo del documento,
en el que
- el recibo digital incluye un formulario en un lenguaje de marcas estándar;
- la prueba infalsificable está codificada como texto oculto en el formulario; y
- la propuesta de verificación comprende un elemento activado por el usuario en el formulario, de modo que la activación de dicho elemento transmita el texto oculto a un proveedor de servicio para su verificación.
25. El método de la reivindicación 24 en el que
el paso de presentar el recibo digital comprende:
- presentar la descripción de la transacción y la propuesta de verificación; y
- no presentar la prueba infalsificable.
26. El método de la reivindicación 24, en el
que:
- el recibo digital comprende, además, el documento; y
- por el que, cuando se activa la propuesta de verificación, se verifica el documento sin necesidad de interacción humana adicional para su identificación.
27. El método de la reivindicación 26, en el
que:
- el recibo digital incluye, además, un script;
- el documento se codifica como texto oculto en el recibo digital; y
- el paso de presentar el recibo digital comprende:
- cuando se presente el recibo digital, ejecutar el script para descodificar el texto oculto y presentar el documento.
28. El método de la reivindicación 24, que,
además, comprende:
- recibir la verificación de la prueba infalsificable; y
- cuando se reciba la verificación de la prueba infalsificable, presentar una segunda propuesta de verificación, con el fin de verificar la transacción.
29. El método de la reivindicación 28, en el
que:
- la transacción consiste en la existencia de un documento en un momento específico;
- el lenguaje del recibo digital es un lenguaje de marcas estándar;
- el paso de presentar el recibo digital comprende:
- presentar el recibo digital a modo de formulario;
- presentar un nombre que identifique el documento y un tiempo que identifique el momento específico;
- no presentar un indicador de marca de tiempo firmado digitalmente codificado como texto oculto en el formulario, comprendiendo el indicador de marca de tiempo una huella digital del documento y la marca de tiempo del documento; y
- presentar la propuesta de verificación como elemento activado por el usuario, en el formulario, de modo que la activación de dicho elemento transmita el texto oculto a un proveedor de servicio para su verificación;
- el paso de recibir la verificación de la prueba infalsificable comprende recibir la verificación del proveedor de servicio en caso de que la huella digital y la marca de tiempo del texto oculto transmitido al proveedor de servicio coincida con un registro de la transacción mantenido independientemente; y
- el paso de presentar una segunda propuesta de verificación comprende presentar una propuesta para verificar si la huella digital en el texto oculto coincide con la huella digital de un segundo documento, que supuestamente es idéntico al documento existente en el momento específico.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US22185400P | 2000-07-28 | 2000-07-28 | |
| US221854P | 2000-07-28 | ||
| US09/907,788 US7694332B2 (en) | 2000-07-28 | 2001-07-17 | Digital receipt for a transaction |
| US907788 | 2001-07-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2275702T3 true ES2275702T3 (es) | 2007-06-16 |
Family
ID=26916219
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01955892T Expired - Lifetime ES2275702T3 (es) | 2000-07-28 | 2001-07-19 | Recibo digital de una transaccion. |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US7694332B2 (es) |
| EP (1) | EP1307863B1 (es) |
| AT (1) | ATE352082T1 (es) |
| AU (2) | AU7794301A (es) |
| CA (1) | CA2417406C (es) |
| DE (1) | DE60126096T2 (es) |
| ES (1) | ES2275702T3 (es) |
| WO (1) | WO2002011091A1 (es) |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050120217A1 (en) * | 2000-06-05 | 2005-06-02 | Reallegal, Llc | Apparatus, System, and Method for Electronically Signing Electronic Transcripts |
| GB2376323B (en) * | 2001-06-09 | 2006-03-15 | Hewlett Packard Co | Trusted and verifiable data storage system |
| US7660988B2 (en) * | 2002-03-18 | 2010-02-09 | Cognomina, Inc. | Electronic notary |
| US6934846B2 (en) * | 2003-01-22 | 2005-08-23 | Walter Szrek | Method of generating unpredictable and auditable random numbers |
| US20040221162A1 (en) * | 2003-02-03 | 2004-11-04 | Phill Kongtcheu | Method and systems to facilitate online electronic notary, signatures and time stamping |
| US7565545B2 (en) * | 2003-02-19 | 2009-07-21 | International Business Machines Corporation | Method, system and program product for auditing electronic transactions based on biometric readings |
| US7320073B2 (en) | 2003-04-07 | 2008-01-15 | Aol Llc | Secure method for roaming keys and certificates |
| US7500099B1 (en) * | 2003-05-16 | 2009-03-03 | Microsoft Corporation | Method for mitigating web-based “one-click” attacks |
| US8171416B2 (en) * | 2005-03-29 | 2012-05-01 | International Business Machines Corporation | Confirmation system and method for instant messaging |
| US7673135B2 (en) | 2005-12-08 | 2010-03-02 | Microsoft Corporation | Request authentication token |
| KR100816184B1 (ko) * | 2006-08-10 | 2008-03-21 | 한국전자거래진흥원 | 전자문서의 불변경성과 사실증명을 수행하는전자문서보관소 시스템 및 그 시스템에서 수행되는전자문서 등록방법, 열람방법, 발급방법, 이관방법, 증명서발급방법 |
| US8424073B2 (en) * | 2006-11-13 | 2013-04-16 | Microsoft Corporation | Refreshing a page validation token |
| FR2914763B1 (fr) * | 2007-04-06 | 2013-02-15 | Grp Des Cartes Bancaires | Cryptogramme dynamique |
| US9747598B2 (en) * | 2007-10-02 | 2017-08-29 | Iii Holdings 1, Llc | Dynamic security code push |
| US9208481B2 (en) * | 2008-07-08 | 2015-12-08 | Omnilync, Inc. | Transaction data capture device and system |
| US8386773B2 (en) * | 2008-12-09 | 2013-02-26 | Research In Motion Limited | Verification methods and apparatus for use in providing application services to mobile communication devices |
| US20110137803A1 (en) * | 2009-12-03 | 2011-06-09 | Symbol Technologies, Inc. | Secure electronic receipt systems and methods |
| US9171271B2 (en) * | 2010-01-15 | 2015-10-27 | New York University | Computer system, client device and method |
| US10592792B2 (en) | 2011-04-14 | 2020-03-17 | Handle Financial, Inc. | Systems and methods for barcode translation |
| US9646291B2 (en) | 2011-05-11 | 2017-05-09 | Visa International Service Association | Electronic receipt manager apparatuses, methods and systems |
| US20130124870A1 (en) * | 2011-11-16 | 2013-05-16 | Certicom Corp. | Cryptographic document processing in a network |
| CN103975333B (zh) * | 2011-12-01 | 2016-10-12 | 国际商业机器公司 | 跨系统安全登录 |
| US9191405B2 (en) | 2012-01-30 | 2015-11-17 | Microsoft Technology Licensing, Llc | Dynamic cross-site request forgery protection in a web-based client application |
| US9626701B2 (en) | 2012-05-23 | 2017-04-18 | Paynearme, Inc. | System and method for facilitating cash payment transactions using a mobile device |
| US20140074675A1 (en) * | 2012-09-12 | 2014-03-13 | Bank Of America Corporation | Digital receipt management |
| US20140358708A1 (en) * | 2013-05-30 | 2014-12-04 | Paynearme, Inc. | Payment Processing with Restricted Receipt Information |
| US10192407B2 (en) | 2014-01-10 | 2019-01-29 | Handle Financial, Inc. | Systems and methods for cash payments for online gaming |
| US10776761B2 (en) * | 2014-03-18 | 2020-09-15 | nChain Holdings Limited | Virtual currency system |
| EP3702992A1 (en) * | 2014-03-18 | 2020-09-02 | Nchain Holdings Limited | Virtual currency system |
| US9830580B2 (en) | 2014-03-18 | 2017-11-28 | nChain Holdings Limited | Virtual currency system |
| US9467299B1 (en) * | 2014-03-19 | 2016-10-11 | National Security Agency | Device for and method of controlled multilevel chain of trust/revision |
| US9467298B1 (en) * | 2014-03-19 | 2016-10-11 | National Security Agency | Device for and method of multilevel chain of trust/revision |
| US9978039B1 (en) | 2015-04-22 | 2018-05-22 | Ashutosh Mohan Sharma | Document gateway system to cloud-based document repository |
| US10374809B1 (en) * | 2016-12-13 | 2019-08-06 | Amazon Technologies, Inc. | Digital signature verification for asynchronous responses |
| US11741451B2 (en) | 2017-03-23 | 2023-08-29 | Mastercard International Incorporated | Systems and methods for dynamically generating customized records |
| DE102018108680A1 (de) * | 2018-04-12 | 2019-10-17 | Bundesdruckerei Gmbh | Verfahren zum manipulationssicheren Speichern von Transaktionsdaten in einem System mit elektronischen Registrierkassen und System |
| US10911243B1 (en) | 2018-12-14 | 2021-02-02 | Wells Fargo Bank, N.A. | Time-based digital signature |
| RU2736886C1 (ru) * | 2019-10-07 | 2020-11-23 | Галина Эдуардовна Добрякова | Способ и система заверки документов |
| US11593765B2 (en) * | 2019-10-25 | 2023-02-28 | Brex Inc. | Application data integration for automatic data categorizations |
| JP7041221B2 (ja) * | 2020-09-03 | 2022-03-23 | 東芝テック株式会社 | 電子レシートシステム |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2703800B1 (fr) | 1993-04-06 | 1995-05-24 | Bull Cp8 | Procédé de signature d'un fichier informatique, et dispositif pour la mise en Óoeuvre. |
| US5497422A (en) * | 1993-09-30 | 1996-03-05 | Apple Computer, Inc. | Message protection mechanism and graphical user interface therefor |
| JP3554765B2 (ja) | 1994-10-28 | 2004-08-18 | シュアティ コム インコーポレイテッド | ドキュメントをユニークに特定し認証する証明書を発行するデジタルドキュメント証明システム |
| US5915022A (en) * | 1996-05-30 | 1999-06-22 | Robinson; Rodney Aaron | Method and apparatus for creating and using an encrypted digital receipt for electronic transactions |
| US6327656B2 (en) * | 1996-07-03 | 2001-12-04 | Timestamp.Com, Inc. | Apparatus and method for electronic document certification and verification |
| US6868391B1 (en) * | 1997-04-15 | 2005-03-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Tele/datacommunications payment method and apparatus |
| AU758232B2 (en) * | 1997-10-06 | 2003-03-20 | Crisnet, Inc. | Single-document active user interface, method and system for implementing same |
| JP2000036000A (ja) | 1998-06-30 | 2000-02-02 | Sun Microsyst Inc | 電子商取引における中立的立会人 |
| WO2000025245A1 (en) | 1998-10-27 | 2000-05-04 | Receipt.Com, Inc. | Mechanism for multiple party notarization of electronic transactions |
| US6584507B1 (en) * | 1999-03-02 | 2003-06-24 | Cisco Technology, Inc. | Linking external applications to a network management system |
| WO2000079496A2 (en) | 1999-06-04 | 2000-12-28 | Receiptcity.Com, Inc. | A point-of-sale/service (pos) portal |
| US7142676B1 (en) * | 1999-06-08 | 2006-11-28 | Entrust Limited | Method and apparatus for secure communications using third-party key provider |
| GB2359156B (en) | 2000-02-14 | 2004-10-13 | Reuters Ltd | Methods of computer programs for and apparatus for providing and accessing digital content |
-
2001
- 2001-07-17 US US09/907,788 patent/US7694332B2/en not_active Expired - Fee Related
- 2001-07-19 DE DE60126096T patent/DE60126096T2/de not_active Expired - Lifetime
- 2001-07-19 AU AU7794301A patent/AU7794301A/xx active Pending
- 2001-07-19 AT AT01955892T patent/ATE352082T1/de not_active IP Right Cessation
- 2001-07-19 AU AU2001277943A patent/AU2001277943B2/en not_active Ceased
- 2001-07-19 ES ES01955892T patent/ES2275702T3/es not_active Expired - Lifetime
- 2001-07-19 EP EP01955892A patent/EP1307863B1/en not_active Expired - Lifetime
- 2001-07-19 CA CA2417406A patent/CA2417406C/en not_active Expired - Fee Related
- 2001-07-19 WO PCT/US2001/022969 patent/WO2002011091A1/en active IP Right Grant
-
2010
- 2010-02-26 US US12/713,926 patent/US8370916B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020161721A1 (en) | 2002-10-31 |
| AU7794301A (en) | 2002-02-13 |
| DE60126096T2 (de) | 2007-10-18 |
| CA2417406C (en) | 2014-04-22 |
| AU2001277943B2 (en) | 2006-11-02 |
| US20100154048A1 (en) | 2010-06-17 |
| US8370916B2 (en) | 2013-02-05 |
| DE60126096D1 (de) | 2007-03-08 |
| WO2002011091A1 (en) | 2002-02-07 |
| EP1307863A1 (en) | 2003-05-07 |
| ATE352082T1 (de) | 2007-02-15 |
| CA2417406A1 (en) | 2002-02-07 |
| EP1307863B1 (en) | 2007-01-17 |
| US7694332B2 (en) | 2010-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2275702T3 (es) | Recibo digital de una transaccion. | |
| US11818265B2 (en) | Methods and systems for creating and recovering accounts using dynamic passwords | |
| EP3721578B1 (en) | Methods and systems for recovering data using dynamic passwords | |
| CN111213139B (zh) | 基于区块链的无纸化文档处理 | |
| CN111226249B (zh) | 基于区块链的可信平台 | |
| CN111108522B (zh) | 基于区块链的传票送达 | |
| ES2251415T3 (es) | Metodo electronico para almacenar y recuperar documentos originales autentificados. | |
| JP5165598B2 (ja) | 秘密鍵とのアカウントリンク | |
| US20050021480A1 (en) | Method and apparatus for creating and validating an encrypted digital receipt for third-party electronic commerce transactions | |
| AU2001277943A1 (en) | Digital receipt for a transaction | |
| WO2012071498A2 (en) | Securing sensitive information with a trusted proxy frame | |
| KR20050089802A (ko) | 조건부 전자 서명의 생성 방법, 조건부 전자 서명의 검증방법, 상태 정보 배포 방법 및 이를 수행하는 데이터 처리장치 및 컴퓨터 프로그램 | |
| US10341353B1 (en) | System and method for issuing, authenticating, storing, retrieving, and verifying documents | |
| CN112740216A (zh) | 文档认证和公布的系统和基于计算机的方法 | |
| Schär et al. | Blockchain diplomas: Using smart contracts to secure academic credentials | |
| TWM520159U (zh) | 產生與驗證具電子認證與紙本認證的認證電子文件之裝置 | |
| US20210250359A1 (en) | System and method for authenticating, storing, retrieving, and verifying documents | |
| US20230259925A1 (en) | System and Method for Conducting Payment and Business Transactions | |
| Radke | Security ceremonies: including humans in cryptographic protocols | |
| Costa | Reducing fraud in authentication systems using attribute certificates | |
| Tzitzikas et al. | The File SecretMeeting. txt: On Authenticity Checking | |
| Sah | Survey on XML encryption |