ES2307924T3 - Sistema y metodo para verificar la transmision y la integridad de mensajes electronicos. - Google Patents
Sistema y metodo para verificar la transmision y la integridad de mensajes electronicos. Download PDFInfo
- Publication number
- ES2307924T3 ES2307924T3 ES03721293T ES03721293T ES2307924T3 ES 2307924 T3 ES2307924 T3 ES 2307924T3 ES 03721293 T ES03721293 T ES 03721293T ES 03721293 T ES03721293 T ES 03721293T ES 2307924 T3 ES2307924 T3 ES 2307924T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- server
- receipt
- sender
- rpost
- 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
- 238000000034 method Methods 0.000 title claims abstract description 60
- 230000005540 biological transmission Effects 0.000 title claims abstract description 25
- 238000012384 transportation and delivery Methods 0.000 description 124
- 230000006870 function Effects 0.000 description 28
- 238000012790 confirmation Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 15
- 238000012012 milestone trend analyses Methods 0.000 description 14
- 238000012795 verification Methods 0.000 description 14
- 238000012545 processing Methods 0.000 description 13
- 230000032258 transport Effects 0.000 description 12
- 230000008901 benefit Effects 0.000 description 9
- 238000010200 validation analysis Methods 0.000 description 9
- 238000004422 calculation algorithm Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 5
- 101001094649 Homo sapiens Popeye domain-containing protein 3 Proteins 0.000 description 5
- 101000608234 Homo sapiens Pyrin domain-containing protein 5 Proteins 0.000 description 5
- 101000578693 Homo sapiens Target of rapamycin complex subunit LST8 Proteins 0.000 description 5
- 102100035477 Popeye domain-containing protein 3 Human genes 0.000 description 5
- 230000009471 action Effects 0.000 description 5
- 229910052799 carbon Inorganic materials 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 230000008520 organization Effects 0.000 description 4
- 238000007781 pre-processing Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 102100024412 GTPase IMAP family member 4 Human genes 0.000 description 3
- 101000833375 Homo sapiens GTPase IMAP family member 4 Proteins 0.000 description 3
- 238000000151 deposition Methods 0.000 description 3
- 230000008021 deposition Effects 0.000 description 3
- GKSPIZSKQWTXQG-UHFFFAOYSA-N (2,5-dioxopyrrolidin-1-yl) 4-[1-(pyridin-2-yldisulfanyl)ethyl]benzoate Chemical compound C=1C=C(C(=O)ON2C(CCC2=O)=O)C=CC=1C(C)SSC1=CC=CC=N1 GKSPIZSKQWTXQG-UHFFFAOYSA-N 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000010365 information processing Effects 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000002372 labelling Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000012805 post-processing Methods 0.000 description 2
- 241000237858 Gastropoda Species 0.000 description 1
- 101000942586 Homo sapiens CCR4-NOT transcription complex subunit 8 Proteins 0.000 description 1
- 101001094629 Homo sapiens Popeye domain-containing protein 2 Proteins 0.000 description 1
- 101000608230 Homo sapiens Pyrin domain-containing protein 2 Proteins 0.000 description 1
- 102100035482 Popeye domain-containing protein 2 Human genes 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000543 intermediate Substances 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G06Q50/40—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/234—Monitoring or handling of messages for tracking messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
Abstract
Un método para transmitir un mensaje de un remitente a una dirección de destino incluyendo los siguientes pasos: Recibir el mensaje en un servidor (14) de parte del remitente, Transmitir normalmente el mensaje del servidor a la dirección de destino por una primera ruta (1212), caracterizada por los siguientes pasos, recibir del remitente en el servidor una indicación particular (1202), indicando que el remitente desea que el mensaje sea transmitido a la dirección de destino por una segunda ruta distinta a la primera ruta y proporcionar la transmisión del mensaje por la segunda ruta a la dirección de destino (1214) de acuerdo con la indicación particular (1202) del remitente.
Description
Sistema y método para verificar la transmisión y
la integridad de mensajes electrónicos.
Esta invención se refiere en general a un
sistema y método para verificar la entrega y contenido de un
mensaje electrónico y, más particularmente, a un sistema y método de
proporcionar posteriormente una prueba con respecto a la entrega y
el contenido de un mensaje de correo electrónico. Más
específicamente, la invención se refiere a un sistema y método para
enviar correo registrado a través de Internet y verificar a la vez
la entrega y el contenido de un mensaje electrónico y proporcionar
ulteriormente una prueba con respecto a la entrega y el contenido
del mensaje de correo electrónico registrado.
En años recientes, el correo electrónico se ha
vuelto una herramienta mercantil indispensable. El correo
electrónico ha reemplazado al "correo caracol" para muchas
prácticas mercantiles debido a que es más rápido, más barato y en
general más confiable. Pero siguen existiendo algunas aplicaciones
de correo donde la copia papel sigue siendo predominante, como es
el caso del correo certificado. Por ejemplo, cuando una carta es
enviada por correo certificado, al remitente se le proporciona un
acuse de recibo para probar que la carta fue enviada. Un recibo de
correo certificado, retomado, agrega la confirmación del Servicio
Postal que la carta fue satisfactoriamente entregada al destinatario
o al agente autorizado del destinatario. Adicionalmente, correos
privados tales como Federal Express® y United Parcel Service®
(UPS), proporcionan algún tipo de confirmación de entrega. Ya que
cada pieza de paquete de correo es, en efecto, registrada es
natural que los consumidores acudan a esos servicios cuando desean
una prueba de la entrega.
Muchos sistemas existentes de correo electrónico
y programas de correo electrónico proporcionan ya alguna forma de
prueba de entrega. Por ejemplo, algunos sistemas de correo
electrónico hoy en día permiten que un remitente marque un mensaje
con etiquetas de "solicitud de notificaciones". Tales etiquetas
permiten que un remitente solicite notificación que el mensaje fue
entregado y/o cuando el mensaje fue abierto. Cuando un remitente
solicita notificación de entrega, el sistema de correo electrónico
de Internet puede proporcionarle al remitente un acuse de recibo de
correo electrónico que el mensaje fue entregado al servidor de
correo o al buzón electrónico del destinatario. El mensaje de acuse
de recibo puede incluir el titulo del mensaje, la dirección de
destino y el tiempo de entrega. Este puede también incluir
(dependiendo de los tipos de "indicadores" que son
proporcionados y activados en el software de envío), una lista de
todas las "estaciones" de Internet que el mensaje recorrió en
ruta hacia su destino. Esta forma de informar está constituida
dentro de algunas de las reglas y protocolos que implementan el
correo electrónico. Además, cuando un mensaje es enviado con una
solicitud de "notificación de lectura" el programa de correo
electrónico del destinatario puede enviarle al remitente una
notificación de correo electrónico indicando que el destinatario
abrió ese mensaje para su lectura. Muchos clientes de correo
electrónico pueden y de hecho apoyan este tipo de informe; sin
embargo, los protocolos de Internet no hacen esto obligatorio.
Sin embargo, esto no significa que un correo
electrónico enviado con una petición de notificación sea tan
efectivo en todos sus aspectos como el correo certificado. Diversas
personas certifican y registran las cartas debido a que desean
obtener una prueba de entrega, por ejemplo, una prueba que puede ser
utilizada en un procedimiento civil o criminal, o una prueba que
satisfará a un supervisor o a un cliente o a una agencia
gubernamental de que un mensaje ha sido enviado, una labor ha sido
realizada, una orden colocada, o un requerimiento de contrato
satisfecho.
Un recibo de registro del Servicio Postal de los
Estados Unidos de América (USPS) constituye una prueba de la
entrega debido a que el USPS se encuentra tras la misma. Un acuse de
recibo representa la confirmación de la Oficina Postal que la carta
o encomienda en cuestión fue efectivamente entregada al
destinatario o a su representante autorizado. Por otra parte, con el
acuse de recibo de correo electrónico existen diversos obstáculos
para que un acuse de recibo de correo electrónico sea admitido y
sirva de base como evidencia persuasiva en un tribunal de justicia,
como una prueba que el mensaje fue entregado. Después de todo, el
acuse de recibo podría ser solo otro mensaje de correo electrónico
que podría haber sido alterado o creado por cualquiera, en
cualquier momento.
Existe una necesidad de un sistema de correo
electrónico y/o método que pueda proporcionar prueba confiable del
contenido y entrega de un mensaje de correo electrónico, con el fin
de sacar mejor provecho de la conveniencia y del bajo costo de la
comunicación por correo electrónico.
Para cumplir esta necesidad, se han establecido
algunos sistemas, mediante los cuales los remitentes pueden recibir
una prueba de entrega de parte de un tercero, suscribiéndose a
servicios mediante los cuales:
- a)
- El remitente transmite un mensaje electrónico a un tercero junto con una lista de los destinatarios pretendidos del documento.
- b)
- El tercero envía una notificación a cada uno de los destinatarios pretendidos del mensaje, invitándolos a visitar la página Web del tercero, donde se puede ver el mensaje.
- c)
- Si el destinatario pretendido visita la página Web del tercero para ver el mensaje, el tercero registra esta
- d)
- visita de modo que el remitente pueda saber que su mensaje ha sido leído por el destinatario.
Los inconvenientes de tales sistemas son
múltiples. En primer lugar, éstos confían esencialmente en la
cooperación del destinatario del correo electrónico para recolectar
sus mensajes del servicio del tercero. Pero las circunstancias en
las cuales un remitente puede desear una prueba de la entrega de un
mensaje, son frecuentemente circunstancias en las cuales no se
puede asumir que el destinatario pretendido cooperará en la
recepción del mensaje. En los casos en que, por ejemplo, el acusar
recibo del mensaje podría colocar una carga financiera o legal
sobre el destinatario, éste último puede simplemente ignorar la
notificación que hay un correo a su disposición, para recibir.
Nótese que no existe nada en tal sistema para garantizar que el
destinatario pretendido ha recibido la notificación de tener correo
pendiente. En segundo lugar, tales sistemas son problemáticos y
lentos para utilizarse comparado con el correo electrónico regular,
en cuanto a que éste puede requerir que el remitente y/o el
destinatario se conecten a un sitio Web de la Red Mundial (World
Wide Web) para enviar, recolectar y verificar la entrega de cada
mensaje. Además, la transmisión de documentos mediante tales
métodos puede requerir que el remitente y el destinatario carguen y
descarguen archivos desde o hacia un sitio de la red. Finalmente,
debido a que estos métodos requieren que el tercero conserve una
copia de la totalidad de cada mensaje hasta que éstos sean
recolectados o hayan expirado, los métodos pueden requerir que su
proveedor destine recursos computacionales sustanciales para el
almacenamiento de datos y el rastreo de datos durante un periodo
prolongado de tiempo. Como un método alternativo de proporcionar
prueba de la entrega, algunos sistemas proporcionan a los clientes
de correo electrónico propietarios o de buscadores de la red
programas de extensión específicos
(plug-ins) que notificarán a los remitentes
cuando un mensaje ha sido recibido, siempre que que el destinatario
utilice el mismo cliente de mensajería. La desventaja obvia de tales
sistemas es que requieren que tanto el remitente come el
destinatario utilicen el mismo cliente de mensajería.
Existe por lo tanto una necesidad para un
sistema/método de correo electrónico que pueda proporcionar una
prueba confiable del contenido y de la entrega de los mensajes
electrónicos, que no requiera el cumplimiento o la cooperación del
destinatario, que no requiera un software de correo electrónico
especial por parte del remitente o del destinatario, que opere con
la misma o casi la misma conveniencia y velocidad de uso que el
correo electrónico convencional y que pueda ser operado
económicamente por un proveedor de servicio.
Un objetivo general de la invención divulgada y
reivindicada en solicitud co-pendiente
no-provisional 09/626,577 (archivo de abogados
RPOST-57228) presentado por Terrance Tomkow el 27 de
Julio, 2000 y cedido de registro al cesionario de registro en esta
solicitud, (subsecuentemente publicado como solicitud de patente
internacional no. WO-A-02/1 1025),
es proporcionar un sistema y método para una verificación
confiable, a través de documentación segura y a prueba de
alteraciones, el contenido y entrega de un mensaje electrónico tal
y como un correo electrónico. Esta solicitud representa conocimiento
previo de conformidad con lo dispuesto en la Regla 29(1)(a).
Idealmente, la invención divulgada y reivindicada en la solicitud
co-pendiente 09/626,577 (archivo de abogados
RPOST-57228) proporcionará al correo electrónico y
otros mensajes electrónicos un estatus legal igual, o incluso
superior, al correo registrado de los Estados Unidos de América.
Sin embargo, no es necesario para la invención que se establezca
algún estatus legal particular para los mensajes enviados según los
métodos expuestos aquí, puesto que la invención proporciona
información útil y verificación independientemente de ello.
La invención divulgada y reivindicada en la
solicitud co-pendiente
no-provisional 09/626,577 incluye un sistema de
mensajes electrónicos que crea y registra una firma digital de cada
mensaje electrónico enviado a través del sistema. Un autor puede
enviar una copia del mensaje de correo electrónico al sistema o
generar el mensaje electrónico dentro del mismo sistema. El sistema,
entonces, redirige y entrega el mensaje electrónico a todos los
destinatarios (o a los gestores de correo designados asociados con
los destinatarios), incluyendo destinatarios "A"
("to") y destinatarios "cc". A partir de ese
momento, el sistema devuelve un recibo de entrega al creador del
mensaje electrónico. El recibo incluye, entre otras cosas: el
mensaje original, la firma digital del mensaje y un historial de la
sincronización de reconocimiento e intercambio (handshaking)
y de la entrega, incluyendo los tiempos de entrega a los
destinatarios. Para verificar y autenticar posteriormente la
información contenida en el recibo, el creador o usuario envía una
copia del recibo al sistema. El sistema verifica en ese momento que
la firma digital coincida con el mensaje original y el resto del
recibo. Si ambos coinciden, el sistema envía entonces una carta o
proporciona otra confirmación de autenticidad verificando que el
mensaje electrónico no ha sido alterado.
El sistema divulgado y reclamado en solicitud
co-pendiente no-provisional
09/626,577 puede incluir un tipo de servidor de correo electrónico
conectado a Internet, que puede ser utilizado de varias maneras.
Por ejemplo, los usuarios individuales pueden registrar sus mensajes
electrónicos, como correos electrónicos, enviando una "copia
carbón" (cc:) al sistema o redactando el mensaje dentro del
sistema mismo. Los usuarios corporativos o de comercio electrónico,
pueden cambiar su servidor a un servidor que incorpora la presente
invención y hacer todos sus mensajes electrónicos externos sean
registrados, con la opción de hacer que el sistema conserve y
archive los recibos. El sistema puede aceptar y verificar mensajes
electrónicos encriptados y administrar los mensajes electrónicos
delante o detrás de un "cortafuegos" (fire wall). Los
usuarios situados en la Web, por ejemplo, individuos o corporaciones
que utilizan correos electrónicos situados en la Web (Webmail),
como MSN Hotmail® o Yahoo Mail®, pueden seleccionar una casilla o
sino incluir un indicador dentro de sus programas de correo
electrónico para seleccionar caso por caso si hacer los correos
electrónicos de registro y/o archivar los mensajes utilizando el
sistema divulgado y reclamado en la solicitud
co-pendiente no-provisional
09/626,577.
La firma digital puede ser creada utilizando
técnicas de firma digital conocidas, tales como realizar una
función de hash sobre el mensaje para producir un digesto de mensaje
y luego cifrando el digesto de mensaje. Se pueden crear firmas
digitales separadas para el cuerpo del mensaje, cualquier archivo
adjunto y para la totalidad del mensaje, incluyendo el cuerpo, los
archivos adjuntos y los digestos individuales de cada mensaje. El
digesto de mensaje encriptado proporciona un tipo de autenticación
de mensaje o código de validación o documentación segura. Se puede
también generar y utilizar otra autenticación de mensaje y/o
códigos de validación.
La patente de Estados Unidos de América no.
6,314,454 describe un sistema que permite a los usuarios enviar
mensajes certificados de correo electrónico. Un servidor recibe un
mensaje de correo electrónico designado para entrega certificada.
El servidor dirige el mensaje de correo electrónico a una cuenta
receptora. Cualquier acción tomada con respecto al mensaje por la
cuenta receptora es transmitida al servidor, que envía dicha
información al remitente.
La patente de Estados Unidos de América no.
6,343,313 describe un sistema de comunicaciones de computadoras
interconectadas que maneja flujos de datos arbitrarios y transporta
a diferentes velocidades dichos flujos, donde actualizaciones
intermedias pueden ser descartadas si las mismas se tornan obsoletas
por actualizaciones de datos entrantes posteriores, optimizando la
utilización de recursos de red y nodo, el mensaje electrónico; y
proporcionando al remitente del mensaje, como mínimo, una parte del
dialogo SMTP y por lo menos una parte de la información de DSN.
En todavía otro aspecto, la invención divulgada
y reivindicada en solicitud co-pendiente 09/626,577
incluye un método para verificar el contenido de un mensaje
electrónico recibido, incluyendo: recibir el mensaje electrónico;
generar una firma digital correspondiente al contenido del mensaje
recibido; proporcionar el mensaje y la firma digital a un
destinatario designado; y, posteriormente, verificar que la firma
digital corresponda al mensaje.
De acuerdo con aun otro aspecto de la invención
divulgada y reivindicada en solicitud co-pendiente
09/626,577, el método incluye establecer si un mensaje fue recibido
electrónicamente por un destinatario, incluyendo: probar que un
mensaje fue despachado electrónicamente junto con la dirección de un
destinatario de parte de un remitente; crear una firma asociada al
mensaje; despachar el mensaje por vía electrónica a la dirección
del destinatario; rastrear el mensaje para determinar un Estado de
Entrega final del mensaje despachado a la dirección del
destinatario; tras recibir el Estado de Entrega final del mensaje,
generar un recibo, el recibo incluyendo una copia del mensaje, la
firma y el Estado de Entrega final para el mensaje; y proporcionar
el recibo al remitente para establecer posteriormente que el
mensaje fue recibido electrónicamente por el destinatario.
De acuerdo con aun otro aspecto de la invención
divulgada y reivindicada en solicitud co-pendiente
09/626, 577, se proporciona un método para demostrar que un mensaje
electrónico enviado a un destinatario fue leído, incluyendo:
proporcionar un mensaje electrónico junto con una dirección de
destinatario; calcular una firma digital que corresponda al mensaje
electrónico; despachar el mensaje por vía electrónica a la
dirección del destinatario; solicitar una notificación (de
"lectura") del destinatario a un Agente de Usuario de Correo
(Mail UserAgent) (cliente de correo electrónico) del
destinatario; tras recibir la notificación de lectura, generar un
recibo de lectura, el recibo de lectura incluyendo una copia del
mensaje, la firma digital para el mensaje electrónico
correspondiente y una segunda firma digital para el recibo de
lectura del destinatario; y proporcionar el recibo de lectura para
posterior verificación que dicho mensaje fue recibido por el
destinatario.
De acuerdo con otro aspecto de la invención
divulgada y reivindicada en solicitud co-pendiente
09/626,577, se proporciona un método para validar la integridad de
la copia aparente de un mensaje electrónico, incluyendo: recibir la
copia aparente del mensaje electrónico, dicha copia aparente
incluyendo un digesto de mensaje cifrado asociado con este;
descifrar el digesto de mensaje; generar un segundo digesto de
mensaje basado en el contenido de la copia aparente; y validar la
copia aparente al comparar el digesto de mensaje descifrado y el
segundo digesto de mensaje para determinar si los dos digestos de
mensaje concuerdan.
De acuerdo con aspectos aun mas allá de la
invención divulgada y reivindicada en solicitud
co-pendiente 09/
626,577, se proporciona un método para la validación de un correo electrónico registrado recibido, incluyendo: recibir un recibo electrónico, dicho recibo incluyendo un mensaje de base y un digesto de mensaje cifrado; descifrar el digesto de mensaje cifrado; generar un segundo digesto de mensaje a partir del mensaje de base; y validar el correo electrónico si el digesto de mensaje cifrado concuerda con el segundo digesto de mensaje.
626,577, se proporciona un método para la validación de un correo electrónico registrado recibido, incluyendo: recibir un recibo electrónico, dicho recibo incluyendo un mensaje de base y un digesto de mensaje cifrado; descifrar el digesto de mensaje cifrado; generar un segundo digesto de mensaje a partir del mensaje de base; y validar el correo electrónico si el digesto de mensaje cifrado concuerda con el segundo digesto de mensaje.
En aun otro aspecto, la invención divulgada y
reivindicada en solicitud co-pendiente 091626,577
incluye un sitio Web en el cual los usuarios tienen la posibilidad
de acudir para enviar y recibir mensajes seguros, el anfitrión del
sitio Web (website host) desempeñándose como tercero
independiente, que enviará y recibirá los mensajes y proporcionará
documentación segura con respecto al contenido y a la entrega de
los mensajes.
Los objetivos antes descritos de la invención
divulgada y reivindicada en solicitud co-pendiente
09/626,577 y otras características y beneficios de la presente
invención, se tornarán evidentes para aquéllos expertos en la
materia cuando se lean conjuntamente con la siguiente descripción
detallada de una personificación preferida ilustrativa y cuando
sean vistos conjuntamente con los dibujos adjuntos en los cuales los
mismos números de referencia corresponden a los mismo números de
las partes, así como las reivindicaciones añadidas.
La presente invención proporciona un método para
transmitir un mensaje de un remitente a una dirección de destino de
acuerdo a la reivindicación 1.
En términos generales, un servidor recibe un
mensaje de parte de un remitente y transmite el mensaje a través de
Internet al destinatario. El servidor normalmente transmite el
mensaje en una primera ruta por Internet hacia el destinatario.
Cuando el remitente indica en una posición particular en el mensaje
que el mensaje es registrado, el servidor transmite el mensaje por
una segunda ruta vía Internet hacia el destinatario. El remitente
también puede proporcionar indicaciones adicionales en el mensaje
para hacer que el servidor maneje el mensaje en otras formas
especiales que normalmente no son proporcionadas por el
servidor.
Después de enterarse por el recibo o a través
del agente del destinatario vía Internet que el mensaje fue
satisfactoriamente recibido, el servidor crea y manda al remitente,
un recibo electrónico. El recibo incluye por lo menos uno y
preferiblemente la totalidad, de: el mensaje y cualquier archivo
adjunto, una plantilla de éxito/fracaso de la entrega, detallando
los recibos y la fecha y hora de recepción del mensaje por parte de
los agentes específicos de destinatario y el fracaso de otros
agentes del destinatario para recibir el mensaje así como una firma
digital del mensaje y archivos adjuntos subsecuentemente. Al
verificar que la firma digital en el recibo del remitente concuerda
con el recibo digital en el servidor, el servidor puede verificar,
sin retener el mensaje, que el recibo es genuino y que el mensaje es
exacto.
Una detallada descripción de la personificación
preferida de la invención será hecha con referencia a los dibujos
acompañantes:
La Fig. 1 es un diagrama de sistema de una
primera personificación de la invención divulgada y reivindicada en
solicitud co-pendiente 09/626,577, según la cual los
mensajes salientes son registrados al ser transmitidos por un Agente
de Transporte de Correo (Mail Transport Agent) (MTA)
especial.
Las Figs. 2-2F constituyen un
diagrama de flujo representativo para hacer de registro un correo
electrónico saliente de acuerdo a la personificación de La Fig.
1.
La Fig. 3 es un diagrama de sistema de una
segunda personificación de la invención divulgada y reivindicada en
solicitud co-pendiente 09/626,577, en cuya
personificación los remitentes pueden instruir a un Agente de
Transporte de Correo para que transmita los mensajes seleccionados a
través de un Agente de Transporte de Correo diseñado para hacer de
registro los mensajes seleccionados.
La Fig. 4 es un diagrama de sistema de una
tercera personificación de la invención divulgada y reivindicada en
solicitud co-pendiente 09/626,577, en la cual se
envían copias carbón (cc's) de los mensajes salientes a un servidor
especial para hacerlos de registro.
La Fig. 5 es un diagrama de sistema de una
cuarta personificación de la invención divulgada y reivindicada en
solicitud co-pendiente 09/626,577, según la cual los
usuarios componen mensajes salientes para hacerlos de registro en
un sitio web designado.
La Fig. 6 es un diagrama de sistema de una
quinta personificación de la invención divulgada y reivindicada en
solicitud co-pendiente 09/626,577 en la cual los
usuarios pueden enviar correos electrónicos hechos de registro y
archivar recibos dentro de un Agente de Usuario de Correo (Mail
User Agent) (MUA) situado en la Web.
La Fig. 7 es un diagrama de flujo para validar
un recibo de correo electrónico hecho de registro.
La Fig. 8 es un diagrama de sistema de una
personificación de la presente invención para hacer de registro los
mensajes entrantes.
La Fig. 9 es un diagrama de flujo para hacer de
registro los mensajes entrantes.
La Fig. 10 es un diagrama de flujo para validar
mensajes recibidos hechos de registro.
La Fig. 11 es un diagrama de sistema
representando un uso ejemplar de la invención divulgada y
reivindicada en solicitud co-pendiente 09/626,577
por parte de un comercio electrónico para hacer de registro y
confirmar las comunicaciones entrantes y salientes.
La Fig. 12 es un diagrama de bloques
representando un gráfico de flujo de un método para hacer de
registro el correo en un sistema como el representado en las
diferentes personificaciones individuales mostradas en las Figuras
previas y mostrando como un mensaje de un remitente a un servidor,
con una indicación representando correo hecho de registro, provee
la transmisión del mensaje por parte del servidor a un destinatario
a través de una ruta especial distinta de la ruta por la cual el
mensaje es normalmente transmitido por parte del servidor hacia el
destinatario;
La Fig. 13 es un diagrama de bloques
representando un gráfico de flujos similar al mostrado en Figura 12
pero con bloques adicionales para proporcionar funciones especificas
adicionalmente a las funciones proporcionadas por el gráfico de
flujos en la Figura 12; y
La Fig. 14 es una vista parcial de una forma
utilizada por el remitente para hacer de registro un mensaje que
será enviado por el servidor al destinatario.
\vskip1.000000\baselineskip
Esta descripción no debe ser tomada en un
sentido limitativo, sino que está hecha meramente con el propósito
de ilustración de los principios generales de la invención. Los
títulos de sección y la organización general de la presente
descripción detallada tiene como único propósito el de conveniencia
y no tienen la intención de limitar la presente invención.
Acordemente, la invención será descrita con respecto a sistemas de
mensajería de correo electrónico que utilizan la arquitectura y la
infraestructura de red de Internet. Debe comprenderse que el tipo
particular de mensaje y de arquitectura de red descrita aquí es para
ilustración únicamente; la invención también se aplica a otros
protocolos de mensaje electrónico y tipos de mensaje que utilizan
otras arquitecturas de red de computadoras, incluyendo redes
alámbricas e inalámbricas. Para conveniencia de discusión, los
mensajes que son procesados de acuerdo a la invención divulgada y
reivindicada en solicitud co-pendiente 09/626,577
serán designados aquí como mensajes "hechos de registro". En la
descripción a continuación, el término "RPost" se referirá en
términos generales a una entidad de terceros que crea y/u opera
software y/o hardware implementando la presente invención y/o actúa
como tercero desinteresado verificador de mensaje. Los mensajes que
son procesados según las presentes invenciones son designados como
mensajes "registrados". El término es utilizado para
conveniencia de discusión ejemplar únicamente y no debe entenderse
como limitativo de la invención.
\vskip1.000000\baselineskip
La Fig. 1 es un diagrama de sistema de una
primera personificación de la presente invención, donde correos
electrónicos salientes son hechos de regtstrp de acuerdo a la
invención divulgada y reivindicada en solicitud
co-pendiente no-provisional
09/626,577. En esta personificación, el servidor RPost 14 sirve como
Agente de Transporte de Correo (MTA) saliente principal para un
mensaje de remitente Agente de Usuario de Correo (MUA) 13. Aunque
el destinatario del mensaje 18 es técnicamente el destinatario y por
lo tanto simplemente el destinatario pretendido o destino
pretendido en ese momento, para simplicidad de la discusión esta
entidad se denominará aquí como el destinatario o destino. Nótese
que un mensaje individual puede tener muchos destinos distintos y
que cada uno de estos puede ser alcanzado a través de un MTA
distinto. El método para enviar mensajes hechos de registro puede
dividirse en tres partes:
- 1)
- Pre procesamiento: los pasos a realizarse antes de transmitir un mensaje;
- 2)
- Transmisión: el método para entregar mensajes a los destinatarios;
- 3)
- Post procesamiento: los procedimientos para obtener información sobre los mensajes después de su entrega, la creación de recibos y la validación de recibos.
\vskip1.000000\baselineskip
Al recibir un mensaje para su transmisión, el
servidor RPost 14 creará registros en una base de datos para cada
mensaje que se utilizará para almacenar información como:
- a)
- el tiempo en el cual el mensaje fue recibido;
- b)
- los nombres de los archivos adjuntos del mensaje; y
- c)
- el número de direcciones del mensaje.
\vskip1.000000\baselineskip
Para cada destino del mensaje, la base de datos
registrará:
- a)
- el nombre del destino (si está disponible);
- b)
- la dirección de Internet del destino;
- c)
- el tiempo en el cual el mensaje fue entregado al Servidor de Correo de destino; y
- d)
- el Estado de Entrega de este destino.
Los Estado de Entrega del Destinatario
utilizados por el sistema incluirán:
- NO ENVIADO
- Este estado indica que el mensaje no ha sido enviado.
\vskip1.000000\baselineskip
- ENTREGADO-Y-EN ESPERA-DEL-DSN
- Este estado indica que el mensaje ha sido entregado a un MTA compatible con ESMTP que soporta la Notificación de Estado de Entrega (Delivery Status Notification) (DSN) de forma tal que se pueda esperar una notificación de éxito/fracaso.
\vskip1.000000\baselineskip
- ENTREGADO
- Este estado significa que la copia del mensaje enviado a este destinatario ha sido satisfactoriamente entregada a un servidor que no soporta DSN ESMTP.
\vskip1.000000\baselineskip
- ENTREGADO-A-CASILLA DE CORREO
- Este estado significa que un mensaje DSN ha sido recibido indicando que la copia del mensaje enviado a este destinatario fue entregada a la casilla de correo del destinatario.
\vskip1.000000\baselineskip
- REENVIADO
- Este estado significa que un DSN de MTA ha sido recibido indicando que la copia del mensaje enviado a este destinatario ha sido reenviada hacia otro servidor.
\vskip1.000000\baselineskip
- NO-ENTREGABLE
- Este estado indica que después de múltiples intentos RPost no ha podido conectarse con un MTA para entregar los mensajes al destinatario.
\vskip1.000000\baselineskip
- FRACASO
- Este estado significa que un DSN de MTA ha sido recibido indicando un fracaso en entregar una copia del mensaje a este destinatario.
\vskip1.000000\baselineskip
En este momento el sistema también llevará a
cabo funciones de hash en los contenidos del mensaje.
El servidor RPost 14 emplea una función de hash
y un algoritmo de cifrado. La función de hash puede ser una de
cualesquiera funciones de hash conocidas, incluyendo MD2, MD5, el
Algoritmo de Hash Seguro (Secure Hashing Algorithm) (SHA), u
otras funciones de hash que podrían ser desarrolladas en el futuro.
Los algoritmos y métodos de Hash son descritos en Criptografía
Aplicada: Protocolos, Algoritmos y Código Fuente en C de Bruce
Schneider, (Applied Cryptography: Protocols, Algorithms, and
Source Code in C), publicado por John Wiley & Sons, Inc.
(New York) 1993; la Publicación de Estándar de Procesamiento de
Información Federal (Federal Information Processing Standard
Publication) 180-1 (FIPS PUB
180-1), el Estándar de Hash Seguro (Secure Hash
Standard), Instituto Nacional de Estándares y Tecnología
(National Institute of Standards and Technology); y en la
Patente de los Estados Unidos de América No. 5,530,757 emitida a
Krawczyk, titulado "Huella Digital Distribuida para Verificación
de Integridad de Información" ("Distributed Fingerprints
for Information Integrity Verification") que enseña funciones
de hash, de cifrado y métodos y sistemas para implementar esas
funciones. Pueden utilizarse otros métodos conocidos o nuevos para
detectar si los contenidos del mensaje han sido alterados.
Una buena función hash H es unidireccional; es
decir, que es difícil de invertir, cuando "difícil de
invertir" significa que dado un valor h hash, es
computacionalmente imposible encontrar una entrada x en modo que
H(x) = h. Además, la función de hash debe ser, como mínimo,
débilmente libre de colisión, lo que significa que, dado un mensaje
x, es computacionalmente imposible encontrar una entrada y en modo
que H(x) = H(y). La consecuencia de esto es que un
potencial falsificador que conoce el algoritmo utilizado y el valor
hash resultante o el digesto de mensaje no puede sin embargo crear
un mensaje falso, cuyo hash coincida con el mismo número. El valor
hash h devuelto por una función de hash es generalmente llamado un
digesto de mensaje. El digesto de mensaje es algunas veces designado
"huella digital" del mensaje x. Actualmente, se recomienda que
las funciones de hash unidireccionales produzcan un resultado que
sea por lo menos de 128 bits de largo, con el objetivo de asegurar
que los resultados sean seguros y no falsificables. Al paso al que
evoluciona el presente estado de la técnica, la longitud recomendada
para las funciones de hash seguras podría incrementar.
El servidor Rpost 14 computa un digesto de
mensaje para el cuerpo de mensaje y un digesto de mensaje separado
para cada uno de los archivos adjuntos del mensaje y conserva los
mismos de forma tal que puedan ser incluidos posteriormente en un
recibo del mensaje.
Antes de que el mensaje sea alterado por los
requerimientos propios del registro, una copia del mensaje original
y sus archivos adjuntos son almacenados de un modo que permita que
los mismos pueden ser recuperados posteriormente por el
sistema.
El servidor Rpost 14 puede alterar un mensaje de
múltiples formas antes de la transmisión al MTA del
destinatario.
Aunque dicho procedimiento no es necesario para
la práctica de la invención, el mensaje puede ser etiquetado para
denotar el hecho que el mensaje ha sido hecho de registro, como por
ejemplo incluyendo las palabras "Hecho de Registro" o
aplicando al inicio de la línea "asunto" del mensaje una
etiqueta como:
"Este mensaje ha sido hecho de registro con
RPost. Visite nuestro sitio Web en la dirección www.RPost.com para
información adicional". Al final de los mensajes originales u
otro tipo de etiquetas.
Adicionalmente, la etiqueta puede contener
instrucciones, direcciones de la Red Mundial de Internet (World
Wide Web) o vínculos que invitan y permiten al destinatario
enviar una respuesta hecha de registro al mensaje vinculándose a
una Página Web desde la cual pueden redactarse y enviarse mensajes
hechos de registro.
Si bien el etiquetado es opcional, el mensaje
entregado será generalmente designado aquí el mensaje
etiquetado.
Los protocolos de Internet proporcionan dos
formas de recibo para mensajes de correo electrónico:
Estos son correos electrónicos que son enviados
por el MTA del destinatario, notificando al remitente nominal del
mensaje que varios eventos han ocurrido. Los MTAs que se ajustan al
protocolo SMTP normalmente solo enviarán una notificación en el
caso de que el agente de correo no puede entregar un mensaje a la
casilla de correo del destinatario (como puede suceder si la
dirección no es válida o si la casilla de correo del destinatario
ha excedido su cuota de almacenamiento permitida).
Con la introducción del estándar SMTP Extendido
se ha vuelto posible para los MTAs remitentes solicitar
notificaciones de éxito y fracaso de la entrega de los mensajes.
Esas Notificaciones de Estado de Entrega (DSN) son correos
electrónicos enviados por un MTA receptor al remitente nominal del
mensaje cuando ocurren ciertos eventos: por ej. El mensaje ha sido
satisfactoriamente depositado en la casilla de correo del
destinatario; el mensaje no puede ser entregado a la casilla de
correo del destinatario por alguna razón; el mensaje del
destinatario ha sido reenviado a otro servidor que no proporciona
recibos DSN.
Nótese que solamente los servidores de correo
electrónico que soportan el protocolo SMTP Extendido (ESMTP)
soportan esta forma de DSN y que el soporte para esta función es
opcional para servidores ESMTP y depende de la configuración
seleccionada por el administrador del servidor.
A pesar de que DSN es un término que solamente
se empezó a usar con el advenimiento del ESMTP, a continuación
usaremos "DSN" para referirnos a cualquier mensaje generado por
un MTA que se refiera al estado de un mensaje recibido, sea éste
conforme o no al protocolo ESMTP.
Estos son correos electrónicos que son enviados
al autor (nominal) de un mensaje por el Agente de Usuario de Correo
(MUA) (programa de correo electrónico) del destinatario cuando
ocurren ciertos eventos: por ej. el mensaje es abierto para su
lectura, o borrado del sistema sin ser leído. Por la convención de
Internet (RFC 1891), ningún programa MUA puede ser obligado a
generar dichas notificaciones. El que un MUA llegue a generar dichos
recibos va a depender de la configuración seleccionada por su
usuario.
El servidor Rpost 14 configurará y transmitirá
mensajes de una forma que intentará obtener ambas notificaciones
DSN de MTA y MUA de los MTAs y MUAs compatibles. Para obtener un
Recibo de Lectura de MUAs compatibles, deberán incluirse ciertos
encabezados en la sección de encabezado de un mensaje de correo
electrónico. Distintos MUAs responden a distintos encabezados; por
lo tanto, el Servidor 14 deberá agregar diferentes encabezados a
cada mensaje que solicite una notificación de lectura de una forma
reconocida por varios MUAs. Estos encabezados toman todos la
siguiente forma:
- Etiqueta de encabezado: nombre de usuario <dirección de usuario>
Por ejemplo:
- Disposición–notificación-a: john smith
- <jsmith@adomain.com>
- Notificación-de lectura-a: john smith
- <jsmith@adomain.com>
en el cual "john smith" es el nombre del
usuario a quien una notificación MUA debe ser enviada y
"<jsmith@adomain.com>" es la dirección de Internet de este usuario. Normalmente, dichos encabezados se referirían al autor del mensaje pero en el caso del presente método, se requiere que la notificación sea devuelta a RPost de forma tal que la notificación pueda ser procesada por RPost. Para asegurarse de que éste sea el caso, el Servidor 14 insertará encabezados que soliciten que los recibos MUA sean enviados a una dirección donde puedan ser procesados por el servidor RPost, por ejemplo: "readreceipts@RPost.com". Esto le indicará a cualquier MUA receptor compatible que envíe sus notificaciones a una dirección RPost para su procesamiento.
"<jsmith@adomain.com>" es la dirección de Internet de este usuario. Normalmente, dichos encabezados se referirían al autor del mensaje pero en el caso del presente método, se requiere que la notificación sea devuelta a RPost de forma tal que la notificación pueda ser procesada por RPost. Para asegurarse de que éste sea el caso, el Servidor 14 insertará encabezados que soliciten que los recibos MUA sean enviados a una dirección donde puedan ser procesados por el servidor RPost, por ejemplo: "readreceipts@RPost.com". Esto le indicará a cualquier MUA receptor compatible que envíe sus notificaciones a una dirección RPost para su procesamiento.
La tarea de procesar notificaciones MUA
devueltas hace surgir otro problema que debe ser resuelto en esta
etapa. No existen estándares que gobiernen el formato o el
contenido de las notificaciones MUA. A menudo harán referencia al
titulo o al asunto del mensaje original y a la hora del evento (por
ej. "abierto para lectura") que están reportando. Pero aunque
esta información esté incluida en la notificación es raramente
suficiente para identificar como único al mensaje que lo provoca o
para identificar al autor de ese mensaje. Cuando el sistema recibe
una notificación MUA debe contar con la capacidad de identificar al
mensaje que lo provoca, de tal manera que pueda incluir la
información de la notificación en el recibo que RPost generará para
el remitente. Alternativamente, el sistema debería, por lo menos,
ser capaz de identificar en modo confiable al remitente de mensaje
al cual hace referencia la notificación MUA, de forma tal que la
información de la notificación pueda ser transmitida al remitente en
forma de un recibo de Lectura de RPost (ver más abajo).
Para cumplir con este último objetivo, el
sistema puede sacar provecho del hecho que las direcciones Internet
tienen dos componentes: un campo `nombre' y un campo `dirección', el
campo `dirección' estando delimitado por cuñas "<>". La
mayoría de los MUAs incluirán ambos campos en la dirección de
destino de sus notificaciones MUA. Al componer sus solicitudes de
recibos MUA, el sistema RPost incluirá la dirección de
manejo-de-recibo del servidor 14
como la dirección para la notificación pero utilizará la dirección
del remitente original en el campo `nombre' del encabezado. Por
ejemplo, si el remitente original del mensaje es el usuario John
Smith con dirección de Internet jsmith@domain.com, el servidor
Rpost 14 incluirá encabezados de la siguiente forma:
- Disposición-notificación-a: jsmith@adomain.com
- <read receipts@RPostcom>
Esto típicamente resultará en que el MUA
compatible envíe una notificación a readreceipts@RPost.com señalada
como:
- jsmith@adomain.com <readreceipts@RPost.com>
Al recibir dicha notificación en la dirección
"readreceipts@RPost.com", el servidor puede, analizando el
campo de destinatario, determinar que la notificación concierne un
mensaje originalmente enviado por jsmith@adomain.com, por más que
esto no pueda ser determinado examinando los contenidos de la
notificación. Con esta información en mano, el servidor puede
empaquetar los contenidos de la notificación en un recibo de
Lectura RPost digitalmente firmado y enviar el recibo a la dirección
jsmith@adomain.com.
El sistema RPost también intentará por todos los
medios obtener y recoger notificaciones DSN de MTA generadas por
los MTAs del destinatario. Puesto que dichas notificaciones son
siempre enviadas a la dirección referida en el campo "DE:"
("FROM:") del encabezado del mensaje, el servidor 14
alterará cada encabezado de mensaje de forma tal que el mensaje es
recibido como "DE:" una dirección RPost en la cual los DSN
pueden ser procesados.
Sin embargo, el problema de procesamiento de DSN
plantea otra cuestión, que será resuelta en esta etapa. Los DSN no
tienen ningún estándar de contenido o formato; a menudo es imposible
determinar, simplemente examinando los contenidos de esos correos
electrónicos, cual es el mensaje que están notificando sus
contenidos. Este problema supuestamente se refería a los DSN
generados en compatibilidad con el protocolo ESMTP mediante el uso
de números de identidad (ver RFC 1869) de sobre DSN (envelope ID
numbers). Según el protocolo, un MTA transmisor puede incluir un
número de referencia junto a su solicitud de DSN. Este número seria
mencionado en cualquier DSN devuelto, permitiendo al remitente
identificar el asunto del mensaje del DSN. Sin embargo, de hecho,
muchos MTAs que se reportan a sí mismos como soportando DSN ESMTP
no devuelven una identidad de sobre DSN ni cualquier otra
información suficiente para identificar de manera confiable el
asunto de mensaje. Finalmente, aun cuando un DSN realice la
devolución de información suficiente para identificar el mensaje del
cual está proporcionando notificación, a menudo no contendrá
información suficiente para identificar el destinatario específico
del mensaje que ha generado la notificación. Por lo tanto, un único
mensaje puede ser enviado a dos destinatarios en mismo dominio; uno
puede ser satisfactoriamente entregado a la casilla de correo del
destinatario; el otro, no. El MTA para el dominio puede informar
esos eventos en un DSN en modos que no proporcionan al remitente
una forma de determinar a cual destinatario le fue
satisfactoriamente entregado y a cual no (como por ejemplo, puede
suceder si los DSN reportan la dirección del destinatario por sus
nombres o alias locales en lugar de hacerlo por la dirección
contenida en el mensaje original).
La presente invención soluciona este problema en
cuatro pasos:
- 1)
- Un número de identificación único es generado por cada mensaje saliente (por ej. basado en un sello de tiempo). Este número es almacenado en una base de datos.
- 2)
- Los destinatarios de cada mensaje son enumerados y los números de identificación almacenados en una base de datos.
- 3)
- El mensaje es enviado separadamente al MTA de cada uno de los destinatarios pretendidos. (Aun cuando dos destinatarios tengan un nombre de dominio y MTA común, el servidor 14 transmitirá el mensaje a ese MTA en dos sesiones SMTP de telnet separadas).
- 4)
- Cuando el servidor 14 transmite el mensaje a un MTA de destinatario, aumenta el espacio "DE" del mensaje para mostrar el mensaje como habiendo sido enviado desde una dirección que incorpora la identidad única del mensaje y el número de identificación del remitente. La dirección también contiene una subcadena (por ej. "rcpt") que habilita al servidor para identificar mensajes de retorno como DSNs.
Por lo tanto, un único mensaje denominado
"mmyyddss" por parte del servidor 14, del remitente llamado
John Smith, podrá ser enviado a su primer destinatario pretendido
(denominado "a" por el sistema) con un encabezado que lee:
- De: John Smith rcptmmddyyssb@RPost.com
El mismo mensaje podría ser enviado al Segundo
destinatario con un encabezado que lea:
- De: John Smith <rcptmmddyyssb@RPost.com>
Muchos MUAs de correo electrónico desplegarán
únicamente el nombre del remitente de un mensaje y por lo tanto la
dirección especial no será visible para la mayoría de los
destinatarios.
La ventaja de esta forma de mandar es que cuando
los MTAs del destinatario emiten DSNs (sean o no compatibles ESMTP)
ellos mandarán esos DSNs a distintas direcciones RPost. Cuando
recibe esos DSNs, el servidor 14 puede identificarlos como mensajes
DSN por su prefijo "RCPT" y, al analizar los destinatarios,
puede determinar cual mensaje y cual destinatario es el tema del
DSN.
El servidor 14 alterará el campo "DE" de
cada mensaje para referirse a un destinatario del mensaje cada vez
que intente transmitir el mensaje al MTA de ese destinatario
Para asegurar que las respuestas del
destinatario a los mensajes transmitidos sean dirigidas
adecuadamente el servidor 14 agregará un encabezado de mensaje
explícito "responder-a:"
("reply-to:") en el mensaje que incluye
el nombre del remitente original y la dirección Internet. En el caso
del presente ejemplo este sería:
- Responder-a: John smith <jsmith@adomain.com>
Esto guiará a los MUAs del destinatario a mandar
las respuestas a un mensaje recibido a la dirección real del
remitente, en lugar de la dirección construida por RPost.
\vskip1.000000\baselineskip
Como fue señalado más arriba, es parte del
método que el servidor 14 transmita una copia separada de un
mensaje saliente a cada destinatario de ese mensaje. Además, RPost
intentará realizar cada una de dichas entregas a través de una
conexión directa de SMTP con un intercambiador de correo (mail
eXchanger) (MX) de registro para cada destino.
Aviso: cada dirección válida de correo
electrónico de Internet incluye un nombre de dominio de Internet o
una dirección IP. Cada nombre/dirección de dominio tiene asociado
con el mismo un(os) servidor(es) de correo
electrónico autorizado(s) a recibir correo para direcciones
en ese dominio. Obsérvese que ciertos dominios tienen más de un
servidor. El Servidor de Nombre de Dominio responsable para cada
dominio difunde la identidad de sus servidores de correo a través de
Internet. Esta información es de dominio público y es administrada
y transmitida en formas que cumplen con las reglas y convenciones
que gobiernan el correo electrónico y el servicio de Nombre de
Dominio de Internet.
Antes de transmitir una copia de un mensaje a
cualquier destino, el servidor Rpost 14 realizará una Consulta de
Nombre de Servidor de Internet (Internet Name Server Lookup)
para identificar un MTA asociado con el dominio de destino.
Habiendo identificado el MTA responsable para recibir correo a
nombre de una dirección de destino, el sistema intentará abrir una
conexión telnet con el MTA local de destino.
Es una práctica común que los correos
electrónicos de Internet sean reenviados de MTA en MTA hasta que
alcancen su destino final. El propósito primordial para proporcionar
una conexión directa entre el servidor Rpost 14 y el MTA de destino
es que el servidor RPost pueda registrar la entrega del mensaje,
(este registro toma la forma de un dialogo SMTP) con el servidor de
correo electrónico que tiene la responsabilidad propietaria para
recibir correo electrónico del nombre de dominio del
destinatario.
La existencia de este registro proporciona
evidencia útil que el mensaje fue entregado, de la misma forma que
un recibo de correo registrado proporciona evidencia de entrega. El
correo Registrado de USPS es considerado demostrablemente entregado
si puede probarse que fue entregado al agente autorizado del
destinatario (por ej. una secretaria o un funcionario del
departamento de correspondencia). En el caso de algún desafío legal
al mérito probatorio de un recibo de entrega RPost, deberá
reconocerse que al seleccionar un proveedor de servicio de correo
electrónico de Internet, el destinatario ha autorizado a ese
proveedor a recolectar mensajes electrónicos a nombre suyo. A su
vez, ese proveedor de servicio ha reconocido su estatus de agente
autorizado para destinatarios de correo electrónico de ese nombre de
dominio al difundir las direcciones de sus MTAs como los servidores
de correo electrónico receptivos para este dominio.
Por consiguiente, al haber entregado los
mensajes directamente al servidor de correo responsable para la
recepción del correo electrónico del destinatario, RPost habrá
entregado el mensaje a un agente que el destinatario ha autorizado
legalmente a recibir su correo. Al registrar la transacción de
entrega (esa transacción representada en la forma de un diálogo
SMTP) RPost puede reivindicar contar con prueba de entrega al agente
autorizado del destinatario.
Nótese que mientras que el método aquí descrito
intenta recolectar otras formas de prueba de entrega para cada
destino, sean o no exitosos estos intentos, va a depender de
factores que no estarán bajo el control de RPost, (por ej. la forma
de soporte SMTP utilizada en el servidor de correo del
destinatario). Por otra parte, cada entrega exitosa directa a un
servidor de correo de un destinatario siempre generará un registro
SMTP. Registrar este registro le permite a RPost proporcionar prueba
de la entrega a cualquier destino válido de Internet que cumple con
los protocolos mínimos (SMTP) para el correo de Internet. Esto
representa una importante ventaja del método actual sobre otros
métodos que pueden intentar probar la entrega recurriendo a DSN de
ESMTP.
Habiendo identificado al MTA para un destino de
un mensaje, el servidor Rpost 14 intentará abrir una conexión ESMTP
con el MTA de destino emitiendo un comando "EHLO"
(handshake) en cumplimiento con RFC 1869. Si el SERVIDOR 16
soporta el ESMTP, este responderá listando cuales servicios ESMTP
soporta el mismo.
Si el SERVIDOR 16 soporta el ESMTP, el servidor
Rpost 14 determina en primer lugar si el SERVIDOR 16 soporta el
Servicio ESMTP "VERIFICAR" ("VERIFY"). El servicio
Verificar le permite a un servidor SMTP de llamada
determinar, entre otras cosas, si una dirección en un dominio de MTA
es genuina. Si el servidor Rpost 14 determina por esos medios que
la dirección a la que está intentando entregar su mensaje no es
válida, terminará la conexión, cesará los intentos de entregar un
mensaje a este destinatario y registrará, en su base de datos, el
estado de este destino de mensaje como
NO-ENTREGABLE.
Cualquiera sea su resultado, el servidor Rpost
14 registrará el diálogo ESMTP "VERIFICAR" en un archivo y lo
almacenará de forma tal que pueda ser adjuntado o incluido
posteriormente en el Recibo de Entrega para este mensaje. Debe
notarse que, debido a cuestiones de seguridad, pocos servidores
ESMTP soportan la función VERIFICAR.
Si el Sistema 16 no soporta el método VERIFICAR,
entonces el servidor Rpost 14 intentará sin embargo entregar el
mensaje al Sistema 16. Normalmente, un MTA acepta mensajes para
cualquier. dirección nominalmente en su dominio y envía
ulteriormente un DSN si la dirección es inválida.
El servidor Rpost 14 intentará entonces
determinar si el servidor de destino soporta DSN de servicio ESMTP.
Si lo hace, RPost transmitirá el mensaje solicitando que el SERVIDOR
16 notifique el remitente del mensaje con un DSN ESMTP si la
entrega al destinatario es exitosa o fracasa. Después de la
transmisión exitosa del mensaje a este destino, el sistema
registrará el Estado de Entrega de este destino como
ENTREGADO-EN-ESPERA-DE-DSN.
Si el Servidor 16 responde al comando
"EHLO" de forma tal que indique que no soporta el ESMTP, el
servidor Rpost 14 emitirá un mensaje "HELO" para iniciar una
conexión SMTP. Si esta conexión es lograda, el servidor Rpost 14
transmitirá el mensaje en cumplimiento con el protocolo SMTP y
registrará el Estado de Entrega del destino como ENTREGADO.
Sea la conexión SMTP o ESMTP, el servidor Rpost
14 registrará la totalidad del diálogo de protocolo entre los dos
servidores. Típicamente, este dialogo incluirá mensajes de protocolo
en los cuales, entre otras cosas, el servidor de destino se
identifica, otorga permiso para descargar un mensaje para un
destinatario determinado y, reconoce que el mensaje fue recibido.
RPost salvará el registro de esta transacción de forma tal que
pueda posteriormente acceder a la misma e incluirla dentro, o
agregarla al Recibo de Entrega RPost para dicho mensaje.
\global\parskip0.900000\baselineskip
Por varias razones RPost podría no lograr
alcanzar una conexión SMTP con un MTA de un destinatario o puede
alcanzar dicha conexión pero no obtener el permiso para transmitir
el mensaje por parte del destinatario. En ese caso, si la consulta
DNS de Internet revela que la dirección de destino es servida por
varios MTAs, el servidor Rpost 14 intentará entregar su mensaje a
cada uno de estos. RPost seguirá intentando entregar a un MTA
apropiado tan frecuentemente como los recursos del sistema lo
permitan. Si después de un tiempo de duración establecida, RPost no
puede entregar el mensaje a una dirección, este designará el estado
para este destinatario de este mensaje como
"NO-ENTREGABLE" y cesará todo intento de enviar
este mensaje a la dirección de destino.
Cuando el servidor Rpost 14 es exitoso en la
transmisión de un mensaje a un Servidor de destino que
explícitamente soporta DSN ESMTP, RPost registrará el estado de este
destinatario de mensaje como
"ENTREGADO-Y-EN
ESPERA-DE DSN".
Cuando el servidor Rpost 14 es exitoso en la
transmisión de un mensaje al Servidor de destino a través de una
conexión que no soporta explícitamente DSN ESMTP, RPost registrará
el estado de este destinatario para este mensaje como
"ENTREGADO".
Los DSNs de MTA serán devueltos al servidor
Rpost 14 dirigidos a direcciones ficticias en su dominio
propietario (por ej. "RPost.com"), esas direcciones habiendo
sido construidas y descritas más arriba. El servidor Rpost 14
realizará un escaneo de todo el correo entrante dirigido al dominio
y detectará los mensajes de DSN por medio de su
sub-cadena (por ej. "rcpt"). Al analizar esas
direcciones en la forma descrita anteriormente, el sistema puede
identificar el mensaje y el destinatario que ha provocado la
notificación DSN.
No hay formato estándar para los mensajes DSN;
tampoco hay léxico estándar en el cual estos informen sus
resultados. Para evaluar un DSN recibido, el sistema deberá buscar
en la línea del asunto y en el cuerpo de los mensajes DSN palabras
y frases que expresen el significado de los DSN. Por ejemplo, frases
tales como "entrega exitosa" o "entregado a casilla de
correo" o "fue entregado" normalmente señalan que el mensaje
al cual hace referencia el DSN fue depositado en la casilla de
correo del destino. Cuando el Sistema detecta frases como ésas
cambiará el Estado de Entrega de este destino del mensaje a
"ENTREGADO A CASILLA DE CORREO".
Frases tales como "no pudo ser entregado",
"error fatal", "fracaso" y "sin éxito" típicamente
señalan un DSN que reporta un fracaso por parte del MTA en entregar
el mensaje al destino. Cuando el sistema detecta frases como ésas
en el DSN, cambiará el registro de los Estados de Entrega del
destinatario a "FRACASO".
Aunque el sistema siempre entrega el correo a un
MTA propietario para el dominio de destino, esos MTAs en ocasiones
reenviarán el mensaje a un servidor distinto (como podría ser el
caso, por ejemplo, si el MTA receptor envía el correo desde atrás
de un firewall). En este caso el DSN contendrá frases tales
como "reenviado" o "reenviado a". En dichos casos, el
sistema cambiará el Estado de Entrega a "REENVIADO".
Habiendo evaluado el DSN y actualizado el Estado
de Entrega del destinatario conformemente, el sistema almacenará el
DSN y cualquier archivo adjunto que este contenga de forma tal que
este(os) mensaje(s) puedan ser incluidos en y/o
adjuntados a un Recibo de Entrega RPost.
De tanto en tanto, el sistema realizará un
escaneo de cada mensaje enviado y examinará el estado de cada
destino de dicho mensaje para determinar si el sistema ha completado
el procesamiento de entrega a ese destino. El criterio para
completar dependerá del Estado de Entrega de ese destino:
- ENTREGADO: Este estado indica que una copia del mensaje para este destinatario ha sido entregada a un MTA que no soporta DSN ESMTP. Dicho MTA podrá sin embargo enviar una forma de Notificación de Estado de Entrega en el caso de que el mensaje no pueda ser entregado a la Casilla de Correo del destinatario (como puede suceder, por ejemplo, si la dirección de destino no corresponde a una cuenta válida dentro del dominio). Por consiguiente, el sistema no tratará la entrega para dicho destinatario como completada hasta que transcurra un cierto período de tiempo desde la entrega al MTA del destinatario. Este período de tiempo -típicamente dos a veinticuatro horas- representa una estimación de un tiempo máximo requerido por la mayoría de servidores para retornar una notificación de fracaso de la entrega y este puede ser ajustado si el destino especifico de dominio es remoto o conocido por su lentitud a la hora de producir dichas notificaciones.
\vskip1.000000\baselineskip
- REENVIADO: este estado significa que un DSN ha sido recibido indicando que el MTA de destinatario ha dirigido el mensaje a otro MTA que no soporta DSN de ESMTP. En este caso, es sin embargo posible que el MTA al cual el mensaje ha sido entregado envíe una notificación de fracaso en la entrega en los tiempos requeridos. Como corresponde, los destinatarios con este estado son tratados como completados bajo las mismas condiciones que los destinatarios con el estado ENTREGADO.
\global\parskip1.000000\baselineskip
- ENTREGADO-Y-EN-ESPERA-DE-DSN: este estado indica que el MTA del destinatario soporta el DSN de ESMTP y que un DSN ha sido solicitado pero no ha sido aún recibido. Podría suceder algunas veces que aunque un MTA se identifica como soportando este servicio no proporcione sin embargo DSNs aun ante casos de entrega exitosa. Por consiguiente, el sistema observará las entregas a un destino con este estado como completado aun si no se recibe un DSN después de un intervalo de tiempo. Este intervalo -típicamente de seis a veinticuatro horas- representa una estimación del tiempo máximo típicamente requerido para que un MTA compatible devuelva un DSN.
\vskip1.000000\baselineskip
- ENTREGADO-A-CASILLA-DE-CORREO: este estado indica que un DSN señalando una entrega exitosa ha sido recibido para este destinatario y por lo tanto la entrega del mensaje a este destino ha sido completada.
\vskip1.000000\baselineskip
- FRACASO, NO-ENTREGABLE: las entregas a destinatarios con este estado son siempre tratadas como completadas.
Cuando el sistema comprueba que una entrega a
todos los destinatarios de un mensaje ha sido completada, éste
construirá un Recibo de Entrega para el mensaje.
\vskip1.000000\baselineskip
Los Recibos de Entrega son correos electrónicos
enviados al remitente original del mensaje
hecho-de-registro. El recibo 20
puede contener:
- 1.
- un identificador para propósitos administrativos. Este identificador puede ser o puede incluir referencias a la identidad (ID) del remitente y/o el valor de la identidad Internet del Mensaje (Internet Message-ID) del remitente como fue recibido por el sistema;
- 2.
- la fecha y la hora en la cual el recibo fue generado;
- 3.
- el cuerpo referido del mensaje original junto con las direcciones de correo electrónico de los destinatarios pretendidos;
- 4.
- la fecha y la hora a la cual el servidor RPost recibió el mensaje;
- 5.
- una plantilla para cada destino enumerando:
- (i)
- la hora a la cual el MTA del destinatario recibió el mensaje y/o la hora a la cual el sistema recibió un informe DSN del MTA del destinatario;
- (ii)
- un Estado de Entrega del mensaje para ese destino. El Estado de Entrega referido en un Recibo de Entrega está basado en los registros internos del sistema de Estado de Entrega del destino. Estos pueden ser transcritos de la siguiente forma:
- \bullet
- Entregas a destinatarios cuyo estado es FRACASO o NO-ENTREGABLE serán registradas en el recibo como "fracaso".
- \bullet
- Entregas a destinatarios cuyo estado es ENTREGADO o ENTREGADO-Y-EN-ESPERA-DE-DSN serán registradas en el recibo como "entregado a servidor de correo".
- \bullet
- Entregas a destinatarios cuyo estado es ENTREGADO-A-CASILLA-DE-CORREO serán registradas en el recibo como "entregado a casilla de correo".
\vskip1.000000\baselineskip
- \quad
- El propósito de esos informes es advertir al lector con precisión sobre la forma de verificación de entrega que el sistema ha sido capaz de alcanzar.
- 6.
- una lista de los archivos adjuntos originales del correo electrónico junto con los digestos de mensaje por separado de cada uno de esos archivos adjuntos;
- 7.
- copias de los archivos adjuntos al mensaje original, cada archivo adjunto original siendo adjuntado al recibo;
- 8.
- transcripciones, sumarios o abstracciones de las transcripciones de todos los diálogos SMTP involucrados en la entrega del mensaje a cada destino;
- 9.
- citaciones de los cuerpos y archivos adjuntos de todos los informes DSN recibidos, incluyendo cualquier detalle sobro la entrega o la disposición del mensaje que los mismos puedan revelar; y
- 10.
- todos los archivos que fueron devueltos al sistema como archivos adjuntos a los informes DSN.
Cada uno de estos elementos del recibo pueden
contar con sus propios digestos de mensaje o firmas digitales
incluidas dentro del recibo. Adicionalmente, el recibo puede incluir
un digesto de mensaje general cifrado único o firma digital
computada y agregada como parte del recibo, proporcionando por lo
tanto un código único de autentificación de mensaje que podría ser
utilizado para autenticar la totalidad de la información contenida
dentro del recibo. Puesto que el recibo mismo y los diálogos SMTP y
los informes DSN dentro del recibo contienen estampillas de tiempo,
el recibo incluye un registro no-falsificable de
el/los destinatario(s) del mensaje, del contenido del
mensaje y de la(s) hora(s) y ruta(s) de
entrega.
Las notificaciones MUA pueden ser obtenidas e
incorporadas dentro de los recibos de Entrega RPost de la misma
forma que los DSNs de MTA. Sin embargo, las notificaciones MTA son
típicamente emitidas por MTAs receptores dentro de un rango de
algunas horas de la entrega, mientras que las Notificaciones MUA no
serán generadas, si es que lo son, hasta que el destinatario abra
su cliente de correo electrónico MUA y lleve a cabo alguna acción
con respecto al correo recibido. Por esta razón, en esta
personificación de la invención, las notificaciones MUA son
recolectadas separadamente de las notificaciones MTA y reportadas en
"Recibos de Lectura RPost" ("RPost Reading
Receipts") separadamente de los "Recibos de Entrega
RPost" ("RPost Delivery Receipts").
Las notificaciones MUA obtenidas por encabezados
de mensaje construidos de la forma descrita anteriormente serán
devueltas a una dirección común RPost (por ej.
"readreceipts@RPost.com") y cada notificación contendrá - en
el campo "nombre" de su dirección - la dirección del remitente
original de este mensaje. Por ser esta la única información
requerida para generar un recibo de lectura RPost de la forma
descrita a continuación, el sistema puede tratar con notificaciones
MUA en el momento que lleguen esas notificaciones y sin necesidad
de haber almacenado información alguna en sus bancos de datos con
respecto al mensaje original.
Los avisos MUA pueden informar, entre otras
cosas, que un mensaje ha sido leído por un destinatario, que un
mensaje ha sido desplegado en la terminal del destinatario (que haya
sido leído o no), que un mensaje ha sido borrado sin haber sido
abierto. No hay ningún estándar regido por protocolo para el
contenido o formato de los mensajes MUA. El sistema puede ser
configurado de forma tal que examine el texto de los MUAs para
interpretar esos informes de la misma forma que el sistema utiliza
los DSNs de MTA. Sin embargo, en la presente personificación de la
invención, los MUAs no son evaluados o interpretados
per-el servifior Rpost 14 pero son, en cambio,
reenviados al remitente para su propia evaluación de forma tal que
puedan ser autenticados por RPost. Para lograr esto, el sistema
creará un mensaje de correo electrónico estilado como una
"Notificación de Lectura RPost", que puede incluir, entre
otros items:
- 1.
- la línea de asunto de la notificación MUA recibida;
- 2.
- el cuerpo de la notificación MUA recibida citada como el cuerpo de la Notificación de Lectura;
- 3.
- la notificación MUA recibida incluida como un archivo adjunto;
- 4.
- cualquier archivo(s) adjunto(s) de la notificación MUA recibida incluidos como archivo(s) adjunto(s).
- 5.
- digestos de mensaje de la notificación MUA recibida y cualquier archivo adjunto de esa notificación;
- 6.
- una sello de fecha y hora;
- 7.
- un hash cifrado de, por los menos, los items 5 y 6 proporcionando una firma digital con sello de tiempo que pueda ser autenticada para el documento y la totalidad de sus contenidos.
\vskip1.000000\baselineskip
En el caso de la presente personificación de la
invención, tanto los recibos de entrega como los recibos de lectura
RPost son enviados al remitente original del mensaje
hecho-de-registro. Puesto que esos
recibos están digitalmente firmados con un hash cifrado, RPost puede
autenticar la información contenida en esos mensajes en cualquier
momento que sean presentados a RPost para dicho propósito, de la
manera descrita a continuación. Esto significa que una vez que este
ha transmitido una copia del recibo a su remitente (con
instrucciones para el remitente de conservar el recibo para sus
registros), RPost no tiene necesidad alguna de retener ningún dato
referente al mensaje o a su entrega y puede expurgar la totalidad
de dichos registros de su sistema. Por lo tanto, RPost no necesita
conservar copia alguna del mensaje original o del recibo. Esta
economía de memoria de archivo le proporciona a la presente
invención una ventaja sobre varios sistemas de autenticación de
mensaje de conocimiento previos que requieren grandes cantidades de
almacenamiento de datos por parte del proveedor de servicio.
En este caso la carga de retener datos de
recibos recae en el remitente original del mensaje.
Alternativamente o adicionalmente, el verificador RPost en su
calidad de tercero puede, tal vez por una suma adicional, archivar
una copia permanente del recibo o de algún o todos los datos del
recibo. El recibo o parte(s) del mismo puede ser almacenado
en cualquier dispositivo de almacenamiento de archivo apropiado,
incluyendo una cinta magnética, un CD ROM u otros tipos de
dispositivos de almacenamiento. Adicionalmente o alternativamente,
RPost puede devolver recibos o partes del mismo a un sistema de
almacenamiento dedicado este propósito que pueda ser controlado por
el remitente o por la organización del remitente.
Como descrito más arriba, el recibo de
información RPost incluye todos los datos del mensaje original del
remitente y sus archivos adjuntos. Existen circunstancias en la
cuales los usuarios del sistema podrían no querer asumir la carga
de retener recibos en sus registros (por ej., por temor a la pérdida
accidental de datos) pero pueden igualmente no desear que los
contenidos de su mensaje queden en manos de un tercero como RPost.
Conformemente, RPost puede descartar los contenidos de los mensajes
pero conservar en su base de datos únicamente información que (por
ej. remitente, fecha de redacción, digestos de mensaje, destinos y
Estados de Entrega) pueda ser proporcionada por RPost para
autenticar y verificar la entrega de un mensaje cuando le sea
presentada una copia del mensaje retenido por el remitente.
En caso de que el emisor de un mensaje requiera
ulteriormente evidencia de que el correo electrónico fue enviado,
entregado y/o leído, el emisor presenta el/los recibo(s)
del/de los mensaje(s) a los operadores del sistema.
Por ejemplo, para poder probar que un mensaje
particular fue enviado del remitente 10 al destinatario 18, el
remitente 10 envía a RPost una copia del recibo 20 con una solicitud
de verificación de la información contenida dentro del recibo a una
casilla de correo predefinida en RPost, por ej. verify@RPost.com.
RPost determina entonces si el recibo es o no es un recibo
válido.
Un recibo es un recibo válido si la firma
digital concuerda con el resto del recibo y si los digestos de
mensaje concuerdan con las partes respectivas correspondientes del
mensaje original. Específicamente, RPost realiza la función de hash
sobre varias porciones del mensaje, incluyendo el cuerpo del
mensaje, los archivos adjuntos y el mensaje en general, incluyendo
el diálogo SMTP y los informes DSN, para producir uno o más
digestos de mensaje correspondientes a la aparente copia del
mensaje. RPost compara los digestos de mensaje en la aparente copia,
incluyendo el digesto de mensaje en su totalidad, con el digesto de
mensaje que RPost ha computado de la aparente copia del mensaje. El
digesto del mensaje general puede ser comparado o bien descifrando
la totalidad del digesto del mensaje recibido como la firma digital
en el aparente recibo o bien cifrando la totalidad del digesto del
mensaje que ha sido calculado desde la aparente copia del mensaje.
Si los digestos de mensaje, incluyendo la firma digital, concuerdan,
entonces el recibo es un recibo auténtico generado por RPost.
Suponiendo que se utilizó una buena función de hash y que las
llaves utilizadas en la función de hash criptográfica y el algoritmo
de cifrado de la firma digital no han sido divulgados a otros, es
virtualmente imposible que el recibo haya sido "falsificado"
por la persona que presenta el recibo. Es decir, el recibo debe
haber sido un recibo generado por RPost y, por lo tanto, el mensaje
contenido en el recibo, la información sobre a/de (to/from),
la fecha y la hora de entrega, el hecho de entrega exitosa, la ruta
por la cual transitó el menaje y cualquier información DSN contenida
dentro del recibo, debe ser una copia verdadera de la información y
es exacta. RPost puede entonces proporcionar autentificación,
verificación y confirmación de la información contenida dentro del
recibo. Esta confirmación puede tomar la forma de un correo
electrónico de confirmación, un testimonio de declaración jurada de
empleados de RPost familiarizados con los métodos utilizados por
RPost, testimonios en vivo declarados bajo juramento en
deposiciones y en un tribunal de justicia así como otras formas de
testimonio. RPost puede cobrar al remitente 10, al destinatario 18
o a cualquier otra entidad, tarifas por los diversos y respectivos
servicios de confirmación. RPost puede igualmente proporcionar
testimonio u otra confirmación con respecto a la
no-autenticidad de un aparente recibo. Puede aportar
testimonio en conformidad con las Reglas Federales de Evidencia
(Federal Rules of Evidence) 901(9), 901 (10),
803(6), 803(7), 1001-1004, 1006,
702-706, las reglas estatales de evidencia
correspondientes y otras reglas aplicables.
En resumen, el sistema proporciona evidencia
confiable basada en el testimonio de un tercero desinteresado que
un mensaje particular que cuenta con un contenido particular fue
enviado, cuando fue enviado, quien lo envió, quien lo recibió,
cuando fue abierto para su lectura y cuando fue borrado. Esta
evidencia puede ser presentada en cualquier momento que surja una
disputa en relación al contenido y a la entrega de mensajes, como
por ejemplo en la formación de contratos, en el momento de la compra
de acciones u órdenes de venta y en muchas otras aplicaciones. Los
operadores del sistema puedan atestiguar sobre la precisión de la
información contenida en el recibo mismo sin necesidad de que los
operadores conserven registro alguno o copia alguna de la
información contenida en el recibo.
Una ventaja significativa del sistema es que
puede ser utilizado por MUAs existentes sin necesidad de realizar
cambio alguno en el mismo. Debido a que la computación, el cifrado,
la interrogación y el diálogo ESMTP, la recolección de informes DSN
y la compilación de recibo, son realizadas por un tercero, el
servidor Rpost 14, ninguna de estas funciones necesita ser
implementada dentro de algún equipo del usuario. Por consiguiente,
los usuarios pueden sacar ventaja del sistema rápida y
fácilmente.
En la personificación de la invención descrita
anteriormente, el servidor Rpost 14 hace de registro la entrega de
todos los mensajes que pasan a través del mismo. Como alternativa,
un servidor Rpost 14 puede hacer de registro únicamente aquellos
mensajes que cuentan con ciertos destinos (por ej. externos a una
organización) o que son enviados desde ciertos remitentes (por ej.
un grupo de relaciones de clientela). Sino, o adicionalmente, el
servidor Rpost 14 puede hacer de registro únicamente aquellos
mensajes que contienen caracteres distintivos o cadenas en el
asunto o cuerpo del mensaje. Por ejemplo, el servidor puede hacer
de registro únicamente mensajes en lo cuales el remitente haya
incluido "Hacer de Registro" ("Make of Record") o
"(MR)" en el asunto del mensaje. La totalidad de otros
mensajes podrá ser entregada por el servidor Rpost 14 o algún otro
servidor que funcione como un MTA convencional de Internet.
En esta personificación, RPost puede obtener
ingresos en una variedad de formas. Por ejemplo: RPost puede
cobrarle a un remitente 10 de menaje o a su organización una suma
basada en cada- mensaje, en la cantidad de kilobytes, en base a una
suma básica periódica tal como mensual o en una combinación de
todas o cualesquiera de las anteriores. RPost puede también cobrar
tarifas por la autentificación y la verificación de un recibo, con
una lista de tarifas dependiendo de si la verificación solicitada
es un simple correo electrónico de retorno, una declaración escrita
o jurada, una declaración jurada por escrito en deposición o en
estrados judiciales, o un testimonio jurado de experto en deposición
o tribunal de justicia. Si los usuarios optan por que RPost
conserve copias de esos recibos, RPost podrá cobrar tarifas de
almacenamiento por artículo y por kilobyte/mes.
Las Figs. 2A-2G constituyen un
gráfico de flujo mostrando una operación ejemplar de la primera
personificación del sistema. Modificar este gráfico de flujo para
aplicarlo a otras personificaciones está al alcance de cualquier
persona familiarizada con software en general y los protocolos del
correo electrónico.
La Fig 3A, Pre-procesamiento,
enseña los pasos a seguir con un mensaje antes de que sea
transmitido por el Servidor de Hacer de Registro (el Sistema).
Para hacer de registro un mensaje de correo
electrónico, en el paso 201 un emisor/remitente/usuario crea un
mensaje de correo electrónico utilizando cualquier Agente de Usuario
de Correo (MUA) de Internet. Posibles MUAs incluyen: (1) programas
de correo electrónico del lado del cliente; (2) programas de correo
electrónico basados en el servidor 45; (3) servicios de correo
electrónico basados en la Web; y (4) formularios HTML consignados a
través de páginas web. El mensaje puede contener archivos adjuntos
según se describe en las Solicitudes para Comentarios (Requests
for Comments) (RFC5) 822, 2046 y 2047, las cuales están
incorporadas en la presenta a título de referencia. Las RFCs son una
serie de notas sobre Internet que exponen los múltiples aspectos de
la comunicación por computadora, concentrándose en protocolos,
procedimientos, programas y conceptos de conexiones de red.
En esta personificación, el sistema funciona
como el servidor de correo saliente del remitente y por lo tanto el
mensaje del remitente será directamente transferido al servidor
RPost por el MUA del remitente (paso 202).
En el paso 203, el sistema crea una copia del
mensaje original para ser almacenado para un procesamiento
ulterior.
En el paso 204, el sistema crea un registro en
una base de datos que puede incluir información tal como: la hora a
la cual el mensaje fue recibido por el servidor, los nombres y
tamaños) de los archivo(s) adjuntos(s) del Mensaje,
el nombre (si es conocido) de cada destino del mensaje; la dirección
Internet de cada destino; la hora a la cual el mensaje fue
entregado al MTA de destino (inicialmente este valor es nulo) y una
unidad que registra el Estado de Entrega de cada destino.
En el paso 205, el Estado de Entrega de cada
destino esta establecido en "NO-ENVIADO".
En el paso 206, el sistema genera y archiva un
digesto de mensaje o huella digital generada a partir del cuerpo
del mensaje.
En el paso 207, el sistema genera y almacena un
hash o digesto de mensaje para cada archivo adjunto incluido en el
mensaje.
En el paso 208, el sistema puede crear una copia
modificada del mensaje original. En esta segunda copia (paso 209),
la linea de asunto original del mensaje puede ser modificada para
indicar que esta copia ha sido hecha de registro (por ej.
incluyendo la mención "Hecho de Registro").
En el paso 210, puede añadirse al cuerpo del
mensaje una notificación que el mensaje ha sido hecho de registro
por el sistema junto con vínculos al sitio Web de la red de Internet
(Word Wide Web site).
En el paso 211, pueden agregarse encabezados de
correo electrónico solicitando una notificación de lectura en una
variedad de formatos de encabezamiento reconocidos por varios MUAs.
Las solicitudes de notificación dirigen la notificación de retorno
a una dirección asociada con el sistema: por ejemplo,
"readreceipts@RPost.com". Dichos encabezados también
incluirán la dirección del remitente original del mensaje en el
campo "nombre" de la dirección a la cual la notificación del
MUA debe ser enviada.
\newpage
Habiendo completado el
Pre-procesamiento, el sistema ahora transmitirá una
copia del mensaje a cada uno de los destinos, como ilustrado en la
Fig. 2B.
La Fig 2B ilustra los pasos provistos para
transmitir un mensaje hecho de registro. Como el paso 220 indica,
el proceso proporciona una transmisión separada para cada
destinatario del mensaje.
En el paso 221, el sistema cambia el campo del
encabezado de su copia de trabajo del mensaje para mostrar el
mensaje como proviniendo "DE:" ("FROM:") un
remitente cuyo nombre es el remitente original del mensaje pero
cuya dirección es una dirección "RPost.com" construida con:
- a)
- una cadena utilizada para identificar notificaciones MTA que retornan (por ej. "RCPT");
- b)
- una cadena que identifica como único el mensaje que está siendo enviado;
- c)
- una etiqueta que identifica como único el destino al cual esta copia está siendo enviada.
En el paso 222, utilizando el nombre de dominio
del destino al cual se está enviando en ese momento, el sistema
ejecuta una consulta de intercambio de Servidor de Nombre de Dominio
para encontrar la dirección del o los MTA(s)
responsable(s) de recolectar correo para direcciones en este
dominio.
En el paso 223, el sistema intenta realizar una
conexión de telnet directa con el MTA del destino. Si la conexión
falla, el sistema intentará realizar nuevamente la conexión. Siempre
que el sistema no haya excedido un número máximo de
re-intentos (227) para este destino, el sistema
entonces intentará realizar la conexión, tal vez utilizando otro
servidor MX para el dominio de destino (228).
Si, tras realizar un número máximo de
re-intentos, el sistema no logra conectar con un MTA
para ese destino, el sistema, como se detalla en el paso 226,
registrará este Estado de Entrega de destino como
"NO-ENTREGABLE" y cesará de intentar entregar
este mensaje a su destino.
Al conectarse con el MTA de destino, el sistema
iniciará a hacer de registro sus diálogos de (E)SMTP con el
MTA (225).
En el paso 229, el sistema intentará iniciar un
intercambio SMTP Extendido (ESMTP) con el MTA de destino al emitir
un comando "EHLO".
Si el MTS de destino soporta el ESMTP, el
sistema determinará entonces (230) si el MTA de destino soporta la
función de SMTP VERIFICAR (VERIFY). Si el MTA soporta
VERIFICAR, el sistema intentará entonces determinar si la dirección
de destino es una dirección válida dentro del dominio (231).
Si la dirección no es válida, entonces, como en
el paso 232, el sistema registrará el Estado de Entrega de este
destino como "FRACASO" y cesará los intentos de entrega de este
mensaje al destino.
Si la dirección es válida o si el servidor de
ESMTP no soporta "VERIFICAR", el sistema determinará entonces
(233) si el MTA que recibe soporta el servicio DSN de Notificación
de Estado de Entrega ESMTP.
Si el MTA no soporta el DSN ESMTP, el sistema
transmitirá el mensaje con solicitudes ESMTP para notificar al
remitente nominal del éxito o del fracaso de la entrega del mensaje
(234). Habiendo transmitido el mensaje, el sistema registrará el
Estado de Entrega de este destino como
"ENTREGADO-Y-EN-ESPERA-DE-DSN"
(235).
Si el MTA que recibe no soporta el SMTP
Extendido, el sistema transmitirá el mensaje utilizando el SMTP
(236) y registrará el estado de los destinos como "ENTREGADO"
(237).
Habiendo entregado el mensaje, el sistema
almacenará entonces el diálogo (E)SMTP, registrando la
entrega de modo que este pueda ser recuperado ulteriormente (238) e
intentar enviar el mensaje a otro destino.
Habiendo transmitido un mensaje a su(s)
destino(s), el sistema debe realizar múltiples funciones
para poder obtener información sobre la disposición del mensaje. La
Fig. 2C ilustra el proceso por medio del cual el sistema procesa
Notificaciones MTA devueltas por MTAs del destinatario.
Por razón del formato utilizado en el encabezado
de mensajes enviados ilustrado en la Fig 2B paso 221, las
notificaciones de mensaje MTA serán entregadas a direcciones locales
ficticias en el servidor. El sistema será capaz de detectar estas
notificaciones por una cadena (por ej. "rcpt") alojada en sus
direcciones (241). Al analizar la dirección, según se ilustra en
242, el sistema puede determinar cual mensaje provocó la
notificación de recibo en cual destino.
En el paso 243, el sistema realiza. un escaneo
de la linea de asunto y del cuerpo de los MTAs recibidos en
búsqueda de frases que indican que el MTA está informando una
entrega exitosa, una entrega fallida, o que el mensaje ha sido
reenviado a otro servidor.
En el caso de que el proceso en paso 243 revele
que la notificación está informando una entrega exitosa, el
sistema, como se ilustra en el paso 245, cambiará el Estado de
Entrega del destino relevante del mensaje relevante a
"ENTREGADO-A-CASILLA-DE-CORREO".
Si el sistema determina que la notificación MTA
está informando un fracaso de la entrega, el sistema (247) cambiará
el Estado de Entrega del destino relevante del mensaje relevante a
"FRACASO".
En el caso de que el sistema determine que la
notificación MTA indica que el mensaje fue reenviado a otro
servidor, el sistema, como se ilustra en el paso 249, cambiará el
Estado de Entrega del destino relevante del mensaje relevante a
"REENVIADO".
Habiendo procesado la Notificación MTA, el
sistema salvará este mensaje y todos sus archivos adjuntos de
manera tal que puedan ser obtenidos y utilizados en la construcción
de un recibo para este destino (250).
De tanto en tanto, como se ilustra en la Fig.
2D, el sistema examinará el estado de cada mensaje para determinar
si el sistema ha recuperado todas las notificaciones MTA que debería
recibir para cada destino de mensaje y podrá entonces proceder a
construir el recibo para el mensaje.
El sistema examinará el Estado de Entrega de
cada destino del mensaje.
Si algún destino tiene el Estado de Entrega
"NO-ENVIADO", entonces el procesamiento del
mensaje no está completado. (252).
Si el Estado de Entrega de un destino es
"ENTREGADO-Y-EN-ESPERA-DE-DSN",
entonces el sistema no observará el procesamiento de este destino
como completado a menos que, como se ilustra en el paso 254, el
tiempo desde la entrega del mensaje haya excedido el periodo de
espera del sistema (por ej. 24 hrs.).
Si el Estado de Entrega de un destino es
"ENTREGADO" (257), entonces el sistema observará el
procesamiento de este destino como completado siempre que (258) haya
transcurrido un período de tiempo que los operadores del sistema
consideren como suficiente para haber recibido una notificación del
fracaso de la entrega de los MTAs de destino. (Por ej. 2
horas).
Cualquier otro Estado de Entrega de destino (por
ej. "FRACASO", "NO-ENTREGABLE",
"ENTREGADO-A
CASILLA-DE-CORREO" es considerado
como un procesamiento completado.
Si el procesamiento de cualquiera de los
destinos del mensaje no es completado, el sistema no realiza otra
acción sino que procede a considerar otros mensajes en el sistema
(paso 255).
Sin embargo, como se ilustra en el paso 259, si
el procesamiento de cada destino del mensaje es completada, el
sistema generará un Recibo de Entrega para el mensaje.
Según se ilustra a nodo de ejemplo en la Fig.
2E, el recibo puede incluir:
Un identificador para propósitos administrativos
como en el bloque 271. Este identificador puede ser, o puede
incluir, una referencia a la identidad del remitente y/o el valor de
la identidad Internet del mensaje (Internet
Message-ID) del remitente como se recibió por
parte del sistema.
Como en el bloque 272, pueden también incluirse
el cuerpo referenciado del mensaje original 12 junto a las
direcciones de los destinatarios pretendidos del correo
electrónico.
Como en el bloque 273, una plantilla para cada
destinatario enumerando:
- a)
- la hora a la cual el MTA del destinatario recibió el mensaje y/ola hora a la cual el sistema recibió el DSN del MTA del destinatario;
- b)
- el informe de Estado de Entrega del mensaje para ese destino, por ej., "Entregado a Servidor de Correo", "Entregado a Casilla de Correo", "Reenviado", "Fracaso en la Entrega", o "No-Entregable".
\vskip1.000000\baselineskip
Como en el bloque 274, una lista de los archivos
adjuntos originales del correo electrónico junto con sus valores de
hash o digestos de mensaje individuales.
Como en el bloque 275, las transcripciones o
abstracciones de las transcripciones de todos los diálogos SMTP
involucrados en la entrega del mensaje para cada destino.
Como en el bloque 276, citas de los cuerpos y de
los archivos adjuntos de todos los DSNs recibidos, incluyendo
cualquier detalle de la entrega o de la disposición del mensaje que
estos puedan revelar.
Como en el bloque 277, el sistema puede adjuntar
al recibo copias de todos los archivos adjuntos del mensaje
original y, como en el bloque 278, el sistema puede adicionalmente
adjuntar archivos devueltos al sistema como archivos adjuntos a los
DSNs.
En el paso 279, habiendo generado el texto del
recibo hasta ahora, el sistema genera entonces un primer hash para
el mensaje de correo electrónico y un segundo hash para cualquier
archivo adjunto al cuerpo del recibo y calcula una firma digital
para cada uno de los hash utilizando una llave de cifrado conocida
únicamente por los operadores del sistema. El cifrado puede emplear,
por ejemplo, el Estándar para Cifrado de Datos (Data Encryption
Standard) descrito en la Publicación para Estándar de
Procesamiento de Información Federal (Federal Information
Processing Standard Publication) 4-2 (FIPS PUB
46-2), el Estándar de Cifrado de Datos (Data
Encryption Standard), del Instituto Nacional de Estándares y
Tecnología (National Institute of Standards and Technology),
incorporados en la presente a título de referencia.
Alternativamente, pueden utilizarse otros conocidos o nuevos métodos
de cifrado del valor hash.
En el paso 280, el hash cifrado es entonces
agregado al final del mensaje como la "firma digital del
documento".
En el pago 281, el recibo 20, ahora completo,
puede ser enviado por correo electrónico al remitente con el
consejo de que sea conservado para los registres del remitente. En
el paso 282, el sistema puede ahora borrar todas las copias del
mensaje original, los archivos adjuntos y los DSNs.
Alternativamente, en lugar de enviar el recibo al remitente, el
sistema puede almacenar el recibo o ambos, tanto el remitente como
el sistema, pueden archivar el recibo.
Porque las notificaciones MUA son devueltas
únicamente bajo opción del destinatario y únicamente cuando el
destinatario realice alguna acción con respecto al mensaje recibido,
las personificaciones del sistema pueden escoger tratar esos
mensajes devueltos diferentemente de las notificaciones MTA.
La Fig. 2F ilustra como esas notificaciones MUA
pueden ser tratadas por el sistema. Las notificaciones MUA son
solicitadas por el sistema al incluir varios encabezados en mensajes
salientes de la manera mostrada en la Fig 2A, paso 211. Esos
encabezados dirigen MUAs compatibles para que envíen notificaciones
a una dirección de sistema (por ej. "readreceipts@Rpost.com")
creada para este propósito. Los encabezados también utilizan, en el
campo `nombre' de esta dirección de retorno, la dirección de correo
electrónico del remitente original del mensaje. Por consiguiente, en
el paso 286, cuando las notificaciones MUA son devueltas a
readreceipts@RPost.com el sistema puede, al examinar la dirección de
la notificación, determinar la dirección a la cual la notificación
de lectura debe ser enviada.
Cuando llega el recibo de lectura desde un MUA
de destino, el sistema, en el paso 287, genera un recibo de lectura
que contiene el asunto de la notificación MUA recibida como su
asunto e incorpora, en su cuerpo de mensaje, el cuerpo de la
Notificación MUA recibida.
En el paso 288, el sistema adjunta al recibo
cualquier archivo que pueda acompañar al recibo MUA (típicamente,
esos pueden incluir detalles de la entrega o de la disposición así
como referencias de identificación al correo electrónico
original).
En el paso 289, el sistema genera un hash para
cualquier archivo adjuntado al recibo y registra este hash en el
cuerpo del recibo.
En el paso 290, el sistema genera un hash para
el cuerpo del recibo y sus archivos adjuntos, cifra este hash y
agrega el resultado al mensaje como "firma digital del
documento".
En el paso 291, el sistema envía el recibo
resultante al remitente del mensaje. En el paso 292, habiendo
enviado este recibo, el sistema puede borrar todos los registros
internos de la transacción.
La Fig. 3 es un diagrama de sistema de una
segunda personificación de la presente invención en la cual el
servidor Rpost 14 no funciona como el MTA primario del usuario sino
que trabaja en colaboración con otro MTA. En esta personificación,
el remitente puede elegir hacer de registro un mensaje saliente en
particular al incluir algún tipo de etiqueta en un mensaje saliente,
en el asunto del mensaje, o en las direcciones del mensaje. Por
ejemplo, si y solo si un remitente incluye el símbolo "(Hecho de
Registro)" "(Made of Record)" o `(MR)' en el asunto
del mensaje del MTA del remitente dirigirá el mensaje para que sea
transmitido a través del servidor Rpost 14 para generar un
recibo.
En esta personificación, los operadores de RPost
reciben ingresos del operador del MTA del remitente a razón de
mensaje y/o de cantidad de kilobyte transmitido.
La Fig. 4 es un diagrama de sistema de una
tercera personificación en la cual una copia carbón ("cc") es
enviada al servidor Rpost 14. En esta personificación, el usuario o
remitente 10 del mensaje puede utilizar un MUA y un MTA estándar
sin modificación. El remitente 10 del mensaje redacta el correo
electrónico teniendo un cuerpo de mensaje y cualquier número de
archivos adjuntos y lo dirige para enviar al destinatario 18, junto
con cualquier copia carbón (cc) y copia carbón invisible (cci) que
desee. Adicionalmente, el remitente 10 del mensaje agrega una
dirección de cc con destino RPost. El servidor Rpost 14 etiqueta el
mensaje como anteriormente y envía el mensaje etiquetado incluyendo
archivos adjuntos al MTA 16 del destinatario y a cualquier cc
designado. Con el recibo de dicha copia, el servidor Rpost 14 puede
enviar un correo electrónico confirmando recibo de dicha copia.
El destinatario 18 y otros destinatarios del
mensaje recibirán ahora dos versiones del mismo mensaje: una
primera versión del mensaje recibido directamente del remitente 10 y
una segunda y etiquetada versión que ha sido dirigida desde RPost.
Una vez que RPost recibe confirmación del MTA 16 del destinatario
que la versión etiquetada del mensaje fue satisfactoriamente
recibida por el MTA 16 del destinatario, el servidor Rpost 14
redacta un mensaje de recibo 20 como anteriormente y envía el recibo
al remitente 10 para sus registros.
Pueden generarse ingresos al establecer cuentas
para dominios emisores de mensajes o para remitentes de mensajes
individuales y cobrando a las cuentas de usuario por uso, por
kilobyte, por mes o una combinación de estos. Pueden igualmente
generarse ingresos colocando anuncios en los recibos y por los
servicios de autentificación y verificación previamente
descritos.
La Fig. 5 es un diagrama de sistema de una
cuarta personificación. En esta personificación, el servidor 14
RPost está asociado con un sitio Web en el cual un usuario redacta
mensajes. El remitente 10 del mensaje visita el sitio Web de RPost
y redacta su mensaje en el sitio Web completando la información de
destinatarios deseados "A", "cc", "ccl",
"Asunto" y el texto del mensaje. Los archivos adjuntos pueden
ser agregados utilizando características disponibles en buscadores
y servidores Web. En estas persónifcación, el remitente proporciona
además una dirección a la cual el recibo
hecho-de-registro puede ser enviado.
El servidor Rpost 14 envía el recibo al remitente 10 a través del
MTA del remitente.
Pueden generarse ingresos al establecer cuentas
para dominios emisores de mensajes o para los remitentes
individuales de mensajes y cobrando a las cuentas de los usuarios
por mensaje, por kilobyte, por mes, o una combinación de los
mismos. Pueden igualmente generarse ingresos colocando anuncios en
los recibos y por los servicios de autentificación y verificación,
como descrito previamente.
La Fig. 6 es un diagrama de sistema de una
quinta personificación. En esta personificación, el servidor Rpost
14 esta asociado a un Agente de Usuario de Correo basado en la Web.
Además de permitirle a los usuarios redactar correo a través de un
buscador Web, dicho MUA le proporciona a los abonados casillas de
correo visibles que despliegan mensajes archivados en el sitio de
servidor Web. Los abonados a dicho servicio obtienen acceso a
cuentas de correo mediante el uso de nombres de usuario y
contraseñas. En esta personificación, el remitente 10 del mensaje
visita el sitio Web de RPost, accede a una cuenta de correo
electrónico al ingresar su nombre de usuario y su contraseña y
redacta su mensaje, que puede ser transportado para una entrega al
servidor Rpost 14. Los recibos generados por el servidor Rpost 14
son devueltos a una casilla de correo situada en la Web asociada
con la cuenta del abonado.
Además de las fuentes de ingresos disponibles en
otras personificaciones, en esta personificación los operadores
pueden cobrar sumas a razón de archivo de recibos conservados en la
casilla de correo situada en la Web.
En todas esas personificaciones, el recibo puede
servir como evidencia que:
- (1)
- el emisor envió un mensaje de correo electrónico;
- (2)
- el mensaje fue enviado a cierta hora;
- (3)
- el correo electrónico fue dirigido a ciertos destinatarios;
- (4)
- el correo electrónico fue entregado a la casilla de correo de cada uno de los destinatarios pretendidos;
- (5)
- el correo electrónico fue entregado en una hora determinada;
- (6)
- el correo electrónico fue entregado por cierta ruta de red; y
- (7)
- el mensaje de correo electrónico y sus archivos adjuntos tenían el contenido especifico registrado en el recibo.
Asimismo, el sistema bajo ciertas circunstancias
genera un recibo separado que puede ser utilizado como evidencia
que:
- (1)
- el correo electrónico fue examinado a través del Agente de Usuario de Correo (MUA) del destinatario; y
- (2)
- el destinatario realizó ciertas acciones en respuesta al mensaje, por ej., lectura o eliminación del correo electrónico, en un momento particular.
Como con las otras personificaciones, esta
personificación produce evidencia documentada que puede ser avalada
y verificada por operadores terceros desinteresados del sistema en
referencia a la entrega y la integridad de un mensaje electrónico.
En otras palabras, el sistema puede ser concebido como un
transformador del correo electrónico para hacer correo electrónico
de registro que pueda ser utilizado posteriormente para demostrar
que un mensaje de correo electrónico en particular fue enviado, que
fue satisfactoriamente entregado, cuando y como.
Si una disputa llegase a surgir en algún
momento, la disputa puede ser resuelta a través del recibo generado
por el sistema por cuanto el recibo está codificado de tal manera
que los operadores del sistema pueden determinar la autenticidad
del recibo como el producto del sistema. Por consiguiente, los
operadores del sistema pueden avalar y atestiguar la exactitud de la
información contenida en un recibo auténtico, apoyándose únicamente
en la información contenida en el recibo mismo y sin necesidad que
los operadores preserven registro alguno o copia alguna de la
información contenida en el recibo.
Además de estos beneficios, los recibos
generados por el sistema pueden también ser útiles como evidencia
de la existencia y la autoría de dichos materiales según sean
transmitidos a través del sistema. Además, el sistema es fácil de
utilizar ya que puede ser utilizado desde cualquier programa/MUA de
cliente de correo de Internet, de forma tal que no se requiere
software adicional alguno.
La Fig. 7 es un diagrama de flujo que ilustra un
método ejemplar para la validación de un recibo. En el caso de que
el remitente de un mensaje requiera evidencia que un correo
electrónico fue enviado y entregado (y/o leído) el remitente
presenta el recibo correspondiente al mensaje a los operadores del
sistema, en el paso 700. Los operadores del sistema, en el paso 702,
separan y descifran entonces la firma digital del documento añadida
al recibo. En el paso 703, los operadores generan un hash del resto
del documento, incluyendo archivos adjuntos.
En el paso 704, si el valor actual de hash no
concuerda con el valor de hash descifrado, entonces el sistema
genera in informe, señalando que RPost no puede autenticar el recibo
como un registro exacto de la entrega o de los contenidos del
mensaje descritos en el recibo.
Si el hash descifrado es equivalente al hash
actual del mensaje, el sistema puede, como en el paso 706,
garantizar que la información contenida en el cuerpo del mensaje no
ha cambiado desde que el recibo pasó a través del sistema. Si el
mensaje original no contiene archivos adjuntos, el sistema podrá
generar en ese momento un informe que garantiza que el recibo es un
registro exacto de los contenidos del mensaje y su entrega por
medio del servidor RPost.
Si el recibo informa que el mensaje original
contenía archivos adjuntos, entonces el recibo también informa
acerca del nombre y del valor de hash de cada uno de los archivos
adjuntos. Al generar el recibo, todos los archivos adjuntos del
mensaje original son adjuntados sin cambios al recibo.
Conformemente, el sistema generará, para cada uno de dichos
archivos adjuntos, un hash del archivo adjunto (708) y lo compara
con el valor de hash registrado en el cuerpo del recibo (709).
Si el valor de hash calculado de un archivo
coincide con el valor incluido en el recibo, el sistema puede
garantizar que el archivo adjunto al recibo es idéntico a aquel
adjuntado al mensaje como fue originalmente entregado. Si los
valores de hash no coinciden, entonces el sistema informará que no
puede garantizar que el archivo adjuntado al recibo es idéntico al
archivo adjuntado al mensaje original.
Habiendo realizado este cálculo para cada
archivo adjuntado al mensaje original, el sistema prepara un
informe que notifica sobre la autenticidad del recibo y cada uno de
los archivos adjuntos (710) o que informa acerca del fracaso de la
validación (712).
Habiendo completado su evaluación, el sistema
agregará entonces una copia del recibo y todos los archivos
adjuntos al informe que ha generado y lo enviará por correo
electrónico a la dirección de retorno del usuario que sometió el
informe para su validación.
La Fig. 8 es un diagrama de sistema que ilustra
otra personificación de la invención, según la cual los correos
electrónicos entrantes son
hechos-de-registro. En esta
personificación, un remitente 60 de mensaje envía un correo
electrónico 70. El MTA 62 del remitente envía el mensaje 70 hacia
Internet como de costumbre. Sin embargo, en esta personificación
RPost contrata con el suscriptor de servicio/destinatario 68 para
hacer de registro los correos electrónicos entrantes. Según el
acuerdo, RPost es designado junto con Network Solutions, Inc. (NSI)
u otra autoridad de nombre de dominio, como destinatario de correo
(servidor MX) para el destinatario 68. Esto causa que el pedido del
Servicio de Nombre de Dominio (DNS), realizado por el MTA 62 del
remitente, retorne a la dirección IP de RPost como la dirección IP
para el destinatario, lo que a su vez causa que el MTA 62 del
remitente envíe el mensaje de correo electrónico al servidor RPost
64. El servidor RPost 64 actúa como un MTA de SMTP, POP, POP3 o IMAP
(conjuntamente, "servidor cte correo POP") para el
destinatario 68. Los MTAs de SMTP, POP e IMAP son gobernados por RFC
821, el protocolo de SMTP, Protocolo de Oficina Postal RFC 1939
(Post Office Protocol), Protocolo Versión 4 rev 1 (que hizo
obsoleto RFC173O), incorporados en la presente a titulo de
referencia.
El servidor RPost 64 prepara una versión 74
hacer-de-registro del mensaje
original 70 y coloca esta versión 74
hecha-de-registro dentro del
casillero de destinatario 68 en lugar de, o adicionalmente a, el
mensaje original 70. La versión
hecha-de-registro puede contar con
todas las características y las opciones de verificación e
información discutidas anteriormente en conexión con recibos de
correo electrónico. Esta información puede incluir, sin limitase a:
los digestos de mensaje individuales para cada uno del cuerpo y
texto del mensaje, la información de a/de (to/from), otra
información de encabezado, cada archivo adjunto, un digesto de
mensaje general y una firma digital así como la información de ruta
del mensaje y las etiquetas. La versión 74
hecha-de-registro del mensaje 70
como se muestra en Fig. 6 incluye el cuerpo del mensaje, incluyendo
la información de encabezado, un archivo adjunto, los digestos de
mensaje separados para cada uno y una firma digital o un digesto de
mensaje cifrado. Las funciones de hash y cifrado son realizadas
utilizando frases privadas o llaves privadas conocidas únicamente
por los operadores del sistema. La versión 74
hecha-de-registro es puesta a
disposición del destinatario 68 para su inspección o descarga a
través del MUA del destinatario.
El servidor RPost 64 puede opcionalmente enviar
un correo electrónico de confirmación 72 al remitente 60 del
mensaje. El mensaje de confirmación 72 puede ser un simple mensaje
de texto indicando que un mensaje fue recibido y
hecho-de-registro. El mensaje de
Confirmación 72 también puede incluir un mensaje tal como "Su
mensaje de correo electrónico fue recibido el 24 de Marzo del 2000 a
las 2:05 p.m. La firma digital del mensaje era [firma digital de
128-bit]. Para mayor información, visite nuestro
sitio Web en www.RPost.com". Alternativamente, o adicionalmente,
el mensaje de confirmación 72 puede incluir toda la información
contenida en la versión 74
hecha-de-registro.
Por lo tanto, el sistema puede proporcionar al
destinatario 68 del mensaje un recibo 74 u otra confirmación
demostrable que indique que:
- (1)
- el destinatario recibió un mensaje de correo electrónico;
- (2)
- el mensaje fue recibido a una hora determinada;
- (3)
- el correo electrónico fue dirigido desde un determinado remitente;
- (4)
- el mensaje aparenta haber sido entregado por una cierta ruta de red; y
- (5)
- el mensaje de correo electrónico y sus archivos adjuntos tenían un contenido específico.
\vskip1.000000\baselineskip
Conformemente, el sistema proporciona evidencia,
que puede ser avalada por los operadores del sistema, que mensajes
electrónicos y documentos particulares fueron entregados a
destinatarios teniendo cierto contenido y presentándose a si mismos
como habiendo provenido de ciertos remitentes.
La Fig. 9 es un gráfico de flujo ilustrando un
ejemplo de hacer de registro correo entrante. En el paso 901, el
servidor RPost 64 recibe un nuevo mensaje de correo electrónico. En
el paso 902, el sistema genera un(a) hash/firma digital de
los contenidos del mensaje incluyendo los encabezados y archivos
adjuntos del mensaje. Adicionalmente, el sistema puede generar un
hash separado para cada archivo adjunto del mensaje. En el paso
903, el sistema cifra el/los hash(es) utilizando una llave de
cifrado conocida únicamente por los operadores del sistema. En el
paso 904, el/los resultantes hash(es) cifrados son entonces
agregados al cuerpo del mensaje. En ese momento, en el paso 905, el
mensaje modificado puede ser puesto a disposición para su
inspección o descarga a través del MUA del destinatario.
La Fig. 10 es un gráfico de flujo de un ejemplo
de validación de un mensaje de correo electrónico recibido
hecho-de-registro. En el paso 1000,
en el caso de que el destinatario de un mensaje deba requerir
evidencia que un correo electrónico con un contenido especifico fue
recibido a un hora en particular, el destinatario puede presentar
una copia de la versión 74
hecha-de-registro (Fig. 8) del
mensaje de correo electrónico 70 a los operadores del sistema para
su verificación. Para verificar el mensaje, en el paso 1001, el
sistema separa y descifra la firma digital del documento agregada al
mensaje. En el paso 1002, el sistema genera un hash del resto del
documento y uno por cada archivo adjuntado al mensaje. En los pasos
1003 y 1004, los hash son comparados. Si el/los hash del documento
coinciden con el/los hash descifrados, entonces el mensaje y sus
archivos adjuntos han pasado a través del sistema y no han sido
alterados desde su entrega al destinatario.
Habiendo determinado que el correo electrónico
no ha sido alterado, los operadores del sistema pueden garantizar
que:
- (1)
- el correo electrónico fue recibido por el sistema en determinado momento de tiempo;
- (2)
- el correo electrónico pretende haber arribado al sistema por una cierta ruta de Internet;
- (3)
- el correo electrónico pretende ser de cierto remitente; y
- (4)
- el correo electrónico y sus archivos adjuntos fueron entregados con el contenido especifico que contienen actualmente.
Por otra parte, en el paso 1006, si los valores
de hash no coinciden, entonces el operador no puede garantizar que
el correo electrónico es auténtico, por ej., que el correo
electrónico es una versión exacta de un correo electrónico que fue
recibido por el sistema.
La Fig. 11 ilustra como la invención puede ser
utilizada por un negocio que utiliza herramientas electrónicas (un
"negocio electrónico" o "e-business"). El
e-business 30 puede utilizar el sistema para
hacer-de-registro todos los mensajes
de correo electrónico entrantes y salientes de sus clientes 34. En
este caso, el sistema incluye el servidor 36 de Protocolo de
Oficina Postal (POP) y el servidor 38 Protocolo Simple de
Transferencia de Correo (SMTP). Por ejemplo, el
e-business 30 puede configurar su sitio Web para que
envíe formularios de correo electrónico a sus clientes y para
dirigir consultas y quejas 40 de clientes 34. Las consultas,
quejas, órdenes, ofertas de compra y otra información 46
hechas-de-registro son enviadas al
e- business 30 por el sistema. Se proporcionan entonces recibos a
los clientes 34 mediante el servidor 38 de SMPT. De esta forma, no
cabe más duda sobre si el cliente envió o no la comunicación y lo
que contenta. Asimismo, el e-business puede
configurar un sitio Web 32 a través del servidor RPost para que cada
comunicación con los clientes pueda ser
hecha-de-registro. En otras
palabras, a través del formulario de datos del sitio Web, las
órdenes 42 y respuestas automatizadas 44 pueden ser
hechas-de-registro a través del
servidor del sistema; Además, cualquier confirmación, aviso de
cobro, asistencia al cliente y ofertas especiales 48 enviadas por
el e-business a clientes 34 pueden ser
hechas-de-registro y la confirmación
enviada al cliente para eliminar argumentos sobre qué fue ordenado,
cuándo y por quién. Si se desea, pueden proporcionarse recibos
idénticos para ambos, los clientes 34.y el
e-business 30. Alternativamente, las funciones del
servidor POP 36 y el servidor SMTP 38 pueden ser combinadas en un
único servidor de sistema.
POP es un protocolo utilizado para recuperar
correo electrónico de un servidor de correo electrónico. Múltiples
aplicaciones de correo electrónico (en ocasiones llamadas clientes
de correo electrónico) utilizan el protocolo POP, aunque algunas
pueden utilizar el más reciente Protocolo de Acceso a Mensajes de
Internet (Internet Message Access Protocol) (IMAP). Una
versión de POP, llamada POP2, requiere que el SMTP envíe mensajes.
Una versión más reciente, POP3, puede ser utilizada con o sin SMTP.
SMTP es un protocolo para enviar mensajes de correo electrónico
entre servidores. Varios sistemas de correo electrónico que envían
correo electrónico por Internet utilizan el SMTP para enviar
mensajes de un servidor a otro; los mensajes pueden en ese momento
ser recuperados con un cliente de correo electrónico que utilice ya
sea POP o IMAP. Adicionalmente, el SMTP es generalmente utilizado
para enviar mensaje de un cliente de correo a un servidor de
correo. Los servidores de Correo Electrónico pueden utilizar una
variedad de protocolos para comunicarse con Internet. Los
protocolos comúnmente utilizados incluyen al SMTP, POP3 e IMAP4. Los
lectores de correo se encuentran al extremo opuesto del servidor.
Siendo que los servidores de correo reciben mensajes vía SMTP, los
lectores de correo electrónico envían correo electrónico a un
servidor de correo utilizando SMPT. De igual forma, teniendo en
cuenta que los servidores de correo envían mensajes utilizando POP3
y opcionalmente IMAP4, los lectores de correo reciben mensajes de
servidores de correo utilizando el protocolo POP3 o IMAP4.
Aunque todo lo descrito más arriba generalmente
describe un sistema y método de verificación que un correo
electrónico fue enviado y/o recibido, la invención divulgada y
reivindicada en solicitud 09/626,577 puede aplicarse a cualquier
mensaje electrónico que pueda ser transmitido a través de una red de
mensajería electrónica o a través de cualquier portal electrónico.
Los mensajes electrónicos pueden incluir texto, audio, vídeo,
gráficos, datos y archivos adjuntos de distintos tipos. Los métodos
y técnicas aquí mostradas pueden ser programados en servidores y
otras computadoras y los programas de computadoras implementando la
invención pueden ser grabados en medios legibles por computadora
incluyendo pero no limitados a CD ROMs, RAM, discos duros y cintas
magnéticas. Los Servicios de Correo Electrónico
hechos-de-registro en conformidad
con la presente invención pueden ser asociados con servicios de
proveedores de servicio de Internet (Internet service
provider) (ISP) para proporcionar una única solución de
proveedor ISP a clientes corporativos y otros clientes
institucionales. Implementar la invención descrita más arriba está
al alcance de todo usuario familiarizado con la técnica de
software.
Como previamente indicado, las Figuras
1-11 muestran y la especificación describe, sistemas
en los cuales el servidor recibe un mensaje de un remitente y
transmite este mensaje por una primera ruta a un destinatario o a
un Agente de Transporte de Correo (MTA) del destinatario. Existen
ocasiones en que el remitente puede desear que el servidor envíe el
mensaje al destinatario o a un Agente de Transporte de Correo del
destinatario por una ruta de mayor o menor recorrido, o por lo menos
una ruta distinta a la primera ruta. Para lograr esto 35, el
remitente etiqueta el formulario de mensaje 1200 (Fig. 14) con una
indicación particular tal como "(R)" en una posición
determinada como la línea de asunto del mensaje. Esta posición
particular es indicada en 1202 en el formulario de mensaje 1200 en
Figura 14. El paso de etiquetar "(R)" en la línea de
"asunto" 1202 del mensaje es mostrada en 1206 en Figura 12.
El mensaje con la "(R)" en la linea de
"asunto" es transmitido por el remitente al servidor 14, que
constituye el Agente de Transporte de Correo del remitente. Esto es
indicado en 1208 en la Figura 12. Como se indica en 1210, el
servidor realiza un escaneo de la linea de "asunto" para
determinar si existe una "(R)" en la línea, si la respuesta es
"No" (ver 1211), el servidor transmite el mensaje al
destinatario o al Agente de Transporte de Correo del destinatario a
través de la ruta mostrada en las Figuras 1-11 e
indicada en Figura 12 como "la ruta normal" y discutida antes
en la especificación. Esto es indicado en 1212 en la Figura 12. Si
la respuesta es "Si" (ver 1213), el mensaje es transmitido a
través de una ruta de red especial como se indica en 1214 en la
Figura 12.
\newpage
La Figura 13 es idéntica en un número de
aspectos a la Figura 12. Sin embargo, la Figura 13 incluye bloques
adicionales para realizar funciones adicionales distintas a las
mostradas en la Figura 12. Estas incluyen sin limitarse, lo
siguiente.
- (1)
- El remitente puede desear que una copia del mensaje sea archivada. Esto se puede obtener agregando un código tal como el número "1" después de "(R)" en la línea de "asunto" de forma tal que el código es "R1".
- (2)
- El remitente puede desear que un registro de la transmisión sea registrado por el servidor 14 constituyendo el agente de transporte de correo del remitente. Esto se puede obtener proporcionando un código tal como "(R2)" en la línea de asunto del mensaje.
- (3)
- El remitente puede desear que un registro de la transmisión del mensaje sea registrado en una base de datos. Esto se puede obtener al proporcionar un código tal como "(R3)" en la linea de asunto ("subject") del mensaje.
(4) El remitente puede desear que un registro de
la transmisión del mensaje sea registrado en una base de datos con
una anotación especial o referencia adicional. Esto se puede obtener
al proporcionar un código tal como "(R4)" en la linea de
asunto del mensaje.
La Figura 13 proporciona un método donde el
servidor que constituye el Agente de Transporte de Correo del
remitente procesa mensajes de correo electrónico seleccionados tales
como aquellos especificados en este párrafo.
La Figura 13 es particularmente limitada a un
código "(xyz)" en la línea de "asunto" ("subject")
del mensaje. En la Figura 13, el remitente es mostrado en 1300
redactando un mensaje electrónico que incluye "(xyz)" en la
línea de "asunto" del mensaje. Como se indica en 1210 en las
Figuras 12 y 13, el servidor 14 que constituye el agente de
transporte de correo, realiza un escaneo de la línea de
"asunto" en el mensaje saliente. Si la línea de "asunto"
en el mensaje no contiene el código "(R)", el servidor
transmite el mensaje a través de la ruta mostrada en la Figura
1-11 y expuesta más arriba (ver 1212 en las Figuras
12 y 13). Si el código "(R)" es detectado por el servidor en
la línea de "asunto" del mensaje, el servidor transmite el
mensaje por una ruta de red especial como se indica en 1214 en las
Figuras 12 y 13.
La Figura 13 indica en 1304 que el código
"(xyz)" es removido por el servidor de la línea de
"asunto" del mensaje. Si el delimitador "xyz" es
detectado, una copia del mensaje es salvada. Esto es indicado en
1306 en la Figura 13. Si el delimitador "xyz" no es
identificado, no será salvada una copia del mensaje.
A pesar de que la presente invención ha sido
entonces descrita en detalle con respecto a las personificaciones
preferidas y a los dibujos relacionados, debe ser evidente para
aquellos expertos en la técnica que se pueden realizar varias
adaptaciones y modificaciones a la presente invención sin apartarse
del ámbito de la invención, las palabras "medios para" no
estando previstas para ser interpretadas de acuerdo con 35 U.S.C.
\NAK112, párrafo 6.
Claims (11)
1. Un método para transmitir un mensaje de un
remitente a una dirección de destino incluyendo los siguientes
pasos:
- Recibir el mensaje en un servidor (14) de parte del remitente,
- Transmitir normalmente el mensaje del servidor a la dirección de destino por una primera ruta (1212), caracterizada por los siguientes pasos,
- recibir del remitente en el servidor una indicación particular (1202), indicando que el remitente desea que el mensaje sea transmitido a la dirección de destino por una segunda ruta distinta a la primera ruta y
- proporcionar la transmisión del mensaje por la segunda ruta a la dirección de destino (1214) de acuerdo con la indicación particular (1202) del remitente.
2. Un método según se establece en la
reivindicación 1 donde la indicación particular (1202) es
proporcionada en el mensaje del remitente por el remitente.
3. Un método según se establece en la
reivindicación 2 donde la indicación particular es proporcionada en
una posición particular del mensaje.
4. Un método según se establece en cualquiera de
las reivindicaciones 1 a 3 donde el remitente le indica al servidor
(14), con una primera adición a la indicación particular (1202), que
una copia del mensaje debe ser archivada cuando el servidor
transmita el mensaje por la segunda ruta a la dirección de destino y
donde, de acuerdo a la primera adición a la indicación particular,
el servidor (14) archiva una copia del mensaje (1306) cuando el
servidor transmite el mensaje por una segunda ruta a la dirección de
destino (1214).
5. Un método según se establece en cualquiera de
las reivindicaciones 1 a 4 donde el remitente indica, con una
segunda adición a la indicación particular (1202) que un registro de
la transmisión debe ser registrado por el servidor (14) cuando el
servidor transmite el mensaje por una segunda ruta a la dirección de
destino y donde de acuerdo con la segunda adición a la indicación
particular, el servidor (14) registra un registro de la transmisión
cuando el servidor transmite el mensaje por la segunda ruta a la
dirección de destino (1214).
6. Un método según se establece en cualquiera de
las reivindicaciones 1 a 5 donde el remitente indica que un registro
de la transmisión del mensaje debe ser registrado en una base de
datos cuando una tercera adición sea proporcionada a la indicación
particular (1202) y cuando el servidor transmite el mensaje por la
segunda ruta a la dirección de destino y donde de acuerdo con la
tercera adición a la indicación particular, el servidor proporciona
un registro de transmisión del mensaje en la base de datos cuando
el servidor transmite el mensaje por la segunda ruta a la dirección
de destino (1214).
7. Un método según se establece en cualquiera de
las reivindicaciones 1 a 6 donde el remitente indica que la
transmisión del mensaje debe ser registrada en una base de datos con
una anotación especial cuando una cuarta adición es proporcionada a
la indicación particular (1202) y cuando el mensaje es transmitido
por el servidor (14) por la segunda ruta a la dirección de destino y
donde el servidor (14) registra la transmisión de mensaje en la
base de datos con una anotación especial cuando la cuarta adición es
proporcionada a la indicación particular y cuando el mensaje es
transmitido por el servidor por la segunda ruta a la dirección de
destino (1214).
8. Un método según se establece en cualquiera de
las reivindicaciones 1 a 7 donde un recibo es transmitido por el
servidor (14) al remitente después de la transmisión del mensaje por
el servidor a la dirección de destino; y donde el mensaje y el
recibo son borrados del servidor después de la transmisión del
recibo por medio del servidor al remitente (292).
9. Un método según se establece en la
reivindicación 8 donde el servidor (14) crea una firma digital del
recibo y transmite la firma digital con el recibo al remitente (290)
y donde el servidor borra la firma digital después de la
transmisión del recibo al remitente.
10. Un método según se establece en la
reivindicación 9 donde el remitente transmite el recibo con la firma
digital al servidor (14) cuando el remitente desea que el recibo
sea autenticado y donde el servidor utilice el recibo y la firma
digital del recibo para autenticar el recibo.
11. Un método según se establece en la
reivindicación 10 donde el servidor obtiene una primera huella
digital, un hash del recibo y descifra la firma digital para obtener
una segunda huella digital, un hash, (702, 703) y donde el servidor
autentica el recibo si la primera y segunda huella digital
coinciden.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US991201 | 2002-02-22 | ||
| US09/991,201 US7240199B2 (en) | 2000-12-06 | 2002-02-22 | System and method for verifying delivery and integrity of electronic messages |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2307924T3 true ES2307924T3 (es) | 2008-12-01 |
Family
ID=27766581
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03721293T Expired - Lifetime ES2307924T3 (es) | 2002-02-22 | 2003-02-21 | Sistema y metodo para verificar la transmision y la integridad de mensajes electronicos. |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US7240199B2 (es) |
| EP (1) | EP1476995B1 (es) |
| JP (1) | JP2005518763A (es) |
| KR (1) | KR101029030B1 (es) |
| CN (2) | CN1636365B (es) |
| AT (1) | ATE398373T1 (es) |
| AU (1) | AU2003224616B2 (es) |
| CA (1) | CA2476176C (es) |
| DE (1) | DE60321543D1 (es) |
| DK (1) | DK1476995T3 (es) |
| ES (1) | ES2307924T3 (es) |
| HK (1) | HK1080644B (es) |
| PT (1) | PT1476995E (es) |
| WO (1) | WO2003073711A2 (es) |
Families Citing this family (343)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6854007B1 (en) * | 1998-09-17 | 2005-02-08 | Micron Technology, Inc. | Method and system for enhancing reliability of communication with electronic messages |
| US20040039912A1 (en) * | 1999-02-26 | 2004-02-26 | Bitwise Designs, Inc. To Authentidate Holding Corp. | Computer networked system and method of digital file management and authentication |
| US7103635B2 (en) * | 2000-01-28 | 2006-09-05 | Lucent Technologies Inc. | Really simple mail transport protocol |
| US20020104026A1 (en) * | 2001-01-29 | 2002-08-01 | Robert Barra | Method and apparatus for providing a service to transfer messages over a communications network |
| WO2002017553A2 (en) * | 2000-08-18 | 2002-02-28 | United States Postal Service | Apparatus and methods for the secure transfer of electronic data |
| JP4060535B2 (ja) * | 2001-01-24 | 2008-03-12 | 株式会社リコー | インターネットファクシミリ装置およびその制御方法 |
| US20020111937A1 (en) * | 2001-01-29 | 2002-08-15 | Mark Wetherbee | Method and system for permissible internet direct marketing |
| US8484294B1 (en) * | 2001-02-21 | 2013-07-09 | Charles Schwab & Co., Inc. | System and method for verified delivery of e-mail messages |
| US6820081B1 (en) | 2001-03-19 | 2004-11-16 | Attenex Corporation | System and method for evaluating a structured message store for message redundancy |
| US8438465B2 (en) * | 2001-04-03 | 2013-05-07 | Purdue Pharma L.P. | Privileged communication system with routing controls |
| JP2002312293A (ja) * | 2001-04-12 | 2002-10-25 | Matsushita Graphic Communication Systems Inc | 電子メール受信装置およびその方法 |
| US7225230B1 (en) * | 2001-06-28 | 2007-05-29 | Bellsouth Intellectual Property Corporation | System and method for electronic message status notification |
| US6978274B1 (en) | 2001-08-31 | 2005-12-20 | Attenex Corporation | System and method for dynamically evaluating latent concepts in unstructured documents |
| US6778995B1 (en) | 2001-08-31 | 2004-08-17 | Attenex Corporation | System and method for efficiently generating cluster groupings in a multi-dimensional concept space |
| US6888548B1 (en) | 2001-08-31 | 2005-05-03 | Attenex Corporation | System and method for generating a visualized data representation preserving independent variable geometric relationships |
| US7271804B2 (en) | 2002-02-25 | 2007-09-18 | Attenex Corporation | System and method for arranging concept clusters in thematic relationships in a two-dimensional visual display area |
| US7610339B2 (en) * | 2002-03-04 | 2009-10-27 | Datawitness Online Ltd. | Internet-based communications verification system |
| US20030174841A1 (en) * | 2002-03-15 | 2003-09-18 | Novell Inc. | Methods, systems, and data structures for secure data content presentation |
| US7627753B2 (en) * | 2002-03-19 | 2009-12-01 | Microsoft Corporation | Secure digital data format and code enforced policy |
| US7155408B2 (en) * | 2002-04-25 | 2006-12-26 | Digital Assurance Certification L.L.C. | Method and apparatus for managing information and communications related to municipal bonds and other securities |
| US7966492B1 (en) * | 2002-05-10 | 2011-06-21 | Emc Corporation | System and method for allowing an e-mail message recipient to authenticate the message |
| AUPS324602A0 (en) * | 2002-06-28 | 2002-07-18 | Ehrlich, Julian | Electronic message system |
| US7298836B2 (en) * | 2002-09-24 | 2007-11-20 | At&T Bls Intellectual Property, Inc. | Network-based healthcare information systems |
| US7376704B2 (en) * | 2002-09-24 | 2008-05-20 | At&T Delaware Intellectual Property, Inc. | Methods, systems, and products for converting between legacy systems |
| US7573999B2 (en) * | 2002-12-31 | 2009-08-11 | At&T Intellectual Property I, L.P. | Computer telephony integration (CTI) complete healthcare contact center |
| US7620170B2 (en) | 2002-12-31 | 2009-11-17 | At&T Intellectual Property I, L.P. | Computer telephony integration (CTI) complete customer contact center |
| US7356139B2 (en) * | 2002-12-31 | 2008-04-08 | At&T Delaware Intellectual Property, Inc. | Computer telephony integration (CTI) complete hospitality contact center |
| US7440567B2 (en) * | 2003-01-27 | 2008-10-21 | At&T Intellectual Property I, L.P. | Healthcare virtual private network methods and systems |
| US8149823B2 (en) * | 2003-01-27 | 2012-04-03 | At&T Intellectual Property I, L.P. | Computer telephony integration (CTI) systems and methods for enhancing school safety |
| US7248688B2 (en) | 2003-01-27 | 2007-07-24 | Bellsouth Intellectual Property Corporation | Virtual physician office systems and methods |
| US7958187B2 (en) * | 2003-02-19 | 2011-06-07 | Google Inc. | Systems and methods for managing directory harvest attacks via electronic messages |
| US8005899B2 (en) | 2003-03-19 | 2011-08-23 | Message Level Llc | System and method for detecting and filtering unsolicited and undesired electronic messages |
| US20070005970A1 (en) * | 2003-05-21 | 2007-01-04 | Trupp Steven E | E-mail authentication protocol or MAP |
| AU2003229234A1 (en) * | 2003-05-30 | 2005-01-21 | Privasphere Gmbh | System and method for secure communication |
| EP1645071B1 (en) * | 2003-07-03 | 2010-12-22 | Koninklijke Philips Electronics N.V. | Secure indirect addressing |
| US7610313B2 (en) | 2003-07-25 | 2009-10-27 | Attenex Corporation | System and method for performing efficient document scoring and clustering |
| US20050044150A1 (en) * | 2003-08-06 | 2005-02-24 | International Business Machines Corporation | Intelligent mail server apparatus |
| US7788485B2 (en) * | 2003-08-07 | 2010-08-31 | Connell John M | Method and system for secure transfer of electronic information |
| CA2537156A1 (en) * | 2003-08-29 | 2005-03-10 | Everest Software, Inc. | Business software application system and method |
| JP2005101883A (ja) * | 2003-09-25 | 2005-04-14 | Hitachi Ltd | 電子メール文書原本性保証装置 |
| US20050144242A1 (en) * | 2003-10-31 | 2005-06-30 | Justin Marston | Caching in an electronic messaging system |
| US20050198168A1 (en) * | 2003-12-04 | 2005-09-08 | Justin Marston | Messaging protocol discovery |
| EP1560137A1 (en) * | 2004-01-30 | 2005-08-03 | Sap Ag | Technique for reliable message confirmation |
| US8266218B2 (en) | 2004-02-12 | 2012-09-11 | International Business Machines Corporation | Automated electronic message filing system |
| US7191175B2 (en) | 2004-02-13 | 2007-03-13 | Attenex Corporation | System and method for arranging concept clusters in thematic neighborhood relationships in a two-dimensional visual display space |
| WO2005081477A1 (en) | 2004-02-17 | 2005-09-01 | Ironport Systems, Inc. | Collecting, aggregating, and managing information relating to electronic messages |
| US7584256B2 (en) * | 2004-04-12 | 2009-09-01 | Borderware Technologies Inc. | Replicating message queues between clustered email gateway systems |
| US7747860B2 (en) * | 2004-05-04 | 2010-06-29 | Message Level, Llc | System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison |
| WO2005109794A1 (en) * | 2004-05-12 | 2005-11-17 | Bluespace Group Ltd | Enforcing compliance policies in a messaging system |
| US7917588B2 (en) * | 2004-05-29 | 2011-03-29 | Ironport Systems, Inc. | Managing delivery of electronic messages using bounce profiles |
| US7870200B2 (en) | 2004-05-29 | 2011-01-11 | Ironport Systems, Inc. | Monitoring the flow of messages received at a server |
| US20060048210A1 (en) * | 2004-09-01 | 2006-03-02 | Hildre Eric A | System and method for policy enforcement in structured electronic messages |
| US20060059548A1 (en) * | 2004-09-01 | 2006-03-16 | Hildre Eric A | System and method for policy enforcement and token state monitoring |
| EP1805646A4 (en) * | 2004-09-29 | 2010-06-23 | Pitney Bowes Inc | SYSTEM FOR DETERMINING AND CORRECTING MAIL ENTITY DEFECTS |
| US7991705B2 (en) | 2004-09-29 | 2011-08-02 | Pitney Bowes Inc. | Mail processing system for determining mail entity defects and correcting mail entity defects |
| US20080086532A1 (en) * | 2004-10-04 | 2008-04-10 | Brian Cunningham | Method for the Verification of Electronic Message Delivery and for the Collection of Data Related to Electronic Messages Sent with False Origination Addresses |
| US20060086798A1 (en) * | 2004-10-23 | 2006-04-27 | Linspire, Inc. | Deferred email message system and service |
| US20060101124A1 (en) * | 2004-11-10 | 2006-05-11 | Landis Michael D | Method and apparatus for mass email transmission |
| US7434262B2 (en) | 2004-12-08 | 2008-10-07 | At&T Intellectual Property I, L.P. | Methods and systems that selectively resurrect blocked communications between devices |
| US7404151B2 (en) | 2005-01-26 | 2008-07-22 | Attenex Corporation | System and method for providing a dynamic user interface for a dense three-dimensional scene |
| US7356777B2 (en) | 2005-01-26 | 2008-04-08 | Attenex Corporation | System and method for providing a dynamic user interface for a dense three-dimensional scene |
| US8572755B2 (en) * | 2005-03-29 | 2013-10-29 | Microsoft Corporation | Trust verification in copy and move operations |
| US7681074B2 (en) | 2005-04-29 | 2010-03-16 | Microsoft Corporation | Transport high availability |
| US7693071B2 (en) | 2005-05-27 | 2010-04-06 | Microsoft Corporation | System and method for routing messages within a messaging system |
| US10021062B2 (en) | 2005-07-01 | 2018-07-10 | Cirius Messaging Inc. | Secure electronic mail system |
| US9401900B2 (en) | 2005-07-01 | 2016-07-26 | Cirius Messaging Inc. | Secure electronic mail system with thread/conversation opt out |
| US7730142B2 (en) | 2005-07-01 | 2010-06-01 | 0733660 B.C. Ltd. | Electronic mail system with functionality to include both private and public messages in a communication |
| US8688790B2 (en) * | 2005-07-01 | 2014-04-01 | Email2 Scp Solutions Inc. | Secure electronic mail system with for your eyes only features |
| DE602005003221T2 (de) * | 2005-07-29 | 2008-08-28 | Research In Motion Ltd., Waterloo | Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen |
| GB0519466D0 (en) * | 2005-09-23 | 2005-11-02 | Scansafe Ltd | Network communications |
| US8200971B2 (en) * | 2005-09-23 | 2012-06-12 | Cisco Technology, Inc. | Method for the provision of a network service |
| US20070078967A1 (en) * | 2005-10-03 | 2007-04-05 | Timekeeping Systems, Inc. | Guard tour event notification system |
| PT1773055E (pt) * | 2005-10-07 | 2015-02-27 | Nagra France Sas | Método de verificação de direitos contidos num módulo de segurança |
| US8077699B2 (en) * | 2005-11-07 | 2011-12-13 | Microsoft Corporation | Independent message stores and message transport agents |
| US7730141B2 (en) | 2005-12-16 | 2010-06-01 | Microsoft Corporation | Graphical interface for defining mutually exclusive destinations |
| WO2007082308A2 (en) * | 2006-01-13 | 2007-07-19 | Bluespace Software Corp. | Determining relevance of electronic content |
| US8601160B1 (en) * | 2006-02-09 | 2013-12-03 | Mcafee, Inc. | System, method and computer program product for gathering information relating to electronic content utilizing a DNS server |
| WO2007095159A2 (en) | 2006-02-14 | 2007-08-23 | Message Level, Llc | Predelivery verification of an intended recipient and dynamic generation of message content upon verif |
| US20070233789A1 (en) * | 2006-03-31 | 2007-10-04 | Microsoft Corporation | Determining failed delivery of email messages using email notifications |
| US8239458B2 (en) * | 2006-03-31 | 2012-08-07 | Microsoft Corporation | Determining failed delivery of email messages using email notifications |
| US8099343B1 (en) | 2006-04-20 | 2012-01-17 | At&T Intellectual Property I, L.P. | Distribution schemes and related payment models for subscriber-created content |
| KR100887898B1 (ko) * | 2006-09-27 | 2009-03-11 | 엘지전자 주식회사 | 이동통신단말기의 발신 메시지 변경 사항 확인방법 및 이를수행하기 위한 이동통신단말기 |
| WO2008064668A2 (de) * | 2006-11-30 | 2008-06-05 | Teles Ag Informationstechnologien | Verfahren der zustellung einer in mindestens einer elektronischen darstellung vorliegenden primär-information |
| US8554868B2 (en) | 2007-01-05 | 2013-10-08 | Yahoo! Inc. | Simultaneous sharing communication interface |
| US20090006860A1 (en) * | 2007-06-26 | 2009-01-01 | John Gordon Ross | Generating multiple seals for electronic data |
| US20090006258A1 (en) * | 2007-06-26 | 2009-01-01 | John Gordon Ross | Registration Process |
| US20090003588A1 (en) * | 2007-06-26 | 2009-01-01 | John Gordon Ross | Counter Sealing Archives of Electronic Seals |
| US20090006842A1 (en) * | 2007-06-26 | 2009-01-01 | John Gordon Ross | Sealing Electronic Data Associated With Multiple Electronic Documents |
| US8606862B2 (en) * | 2007-08-21 | 2013-12-10 | Microsoft Corporation | Electronic mail delay adaptation |
| US8909714B2 (en) * | 2007-08-21 | 2014-12-09 | Microsoft Corporation | Electronic mail delay adaptation |
| US8706819B2 (en) * | 2007-08-21 | 2014-04-22 | Microsoft Corporation | Electronic mail delay adaptation |
| US20090055491A1 (en) * | 2007-08-21 | 2009-02-26 | Microsoft Corporation | Electronic mail delay adaption |
| US20090138711A1 (en) * | 2007-11-21 | 2009-05-28 | Dennis Heimbigner | Sender Email Address Verification Using Reachback |
| FR2926175B1 (fr) * | 2008-01-07 | 2012-08-17 | Trustseed Sas | Procede et dispositif de signature |
| JP5045472B2 (ja) * | 2008-02-07 | 2012-10-10 | 富士通株式会社 | メール管理装置、メール管理方法およびメール管理プログラム |
| NL2001357C2 (nl) * | 2008-03-10 | 2009-09-11 | Copyconfirm B V | Werkwijze voor registratie van elektronische berichten. |
| FR2930392B1 (fr) * | 2008-04-22 | 2022-01-28 | Trustseed | Procede et dispositif de securisation de transferts de donnees |
| US8312033B1 (en) | 2008-06-26 | 2012-11-13 | Experian Marketing Solutions, Inc. | Systems and methods for providing an integrated identifier |
| US8600912B2 (en) * | 2008-09-30 | 2013-12-03 | Escher Group (Irl) Limited | Electronic business postal system |
| US8341141B2 (en) * | 2008-12-16 | 2012-12-25 | Krislov Clinton A | Method and system for automated document registration |
| US8589372B2 (en) | 2008-12-16 | 2013-11-19 | Clinton A. Krislov | Method and system for automated document registration with cloud computing |
| US8914351B2 (en) | 2008-12-16 | 2014-12-16 | Clinton A. Krislov | Method and system for secure automated document registration from social media networks |
| US9240978B2 (en) * | 2008-12-31 | 2016-01-19 | Verizon Patent And Licensing Inc. | Communication system having message encryption |
| US8374930B2 (en) * | 2009-02-02 | 2013-02-12 | Trustifi Corporation | Certified email system and method |
| US8495736B2 (en) * | 2009-03-24 | 2013-07-23 | Lockheed Martin Corporation | Method and apparatus for providing information assurance attributes through a data providence architecture |
| US8341023B2 (en) * | 2009-06-17 | 2012-12-25 | Trustifi Corporation | Certified email system and method |
| US8713018B2 (en) | 2009-07-28 | 2014-04-29 | Fti Consulting, Inc. | System and method for displaying relationships between electronically stored information to provide classification suggestions via inclusion |
| US8612446B2 (en) | 2009-08-24 | 2013-12-17 | Fti Consulting, Inc. | System and method for generating a reference set for use during document review |
| EP2515759A4 (en) | 2009-12-23 | 2015-01-21 | Given Imaging Inc | METHOD OF ASSESSING CONSTIPATION USING INGREDIENT CAPSULE |
| US8582801B2 (en) | 2010-02-08 | 2013-11-12 | Google Inc. | Assisting the authoring of posts to an asymmetric social network |
| US9729352B1 (en) * | 2010-02-08 | 2017-08-08 | Google Inc. | Assisting participation in a social network |
| US8825759B1 (en) | 2010-02-08 | 2014-09-02 | Google Inc. | Recommending posts to non-subscribing users |
| US8561085B2 (en) * | 2010-04-14 | 2013-10-15 | Bank Of America Corporation | System and method for providing a communications framework |
| US8527597B2 (en) | 2010-12-07 | 2013-09-03 | Google Inc. | Determining message prominence |
| DE202011002655U1 (de) | 2011-02-11 | 2011-04-14 | Francotyp-Postalia Gmbh | Ein-/Ausgabestation und System zur netzwerkbasierten Druckausgabe |
| JP4879361B1 (ja) * | 2011-04-28 | 2012-02-22 | 楽天株式会社 | 電子メールシステム、電子メールシステムの制御方法、中継装置、プログラム、及び情報記憶媒体 |
| US8584211B1 (en) | 2011-05-18 | 2013-11-12 | Bluespace Software Corporation | Server-based architecture for securely providing multi-domain applications |
| US9607336B1 (en) | 2011-06-16 | 2017-03-28 | Consumerinfo.Com, Inc. | Providing credit inquiry alerts |
| CN102855424A (zh) * | 2011-06-29 | 2013-01-02 | 盛乐信息技术（上海）有限公司 | 一种数字指纹提取方法、装置和文字作品识别方法、装置 |
| MX2014000392A (es) | 2011-07-12 | 2014-04-30 | Mobli Technologies 2010 Ltd | Metodos y sistemas para proporcionar funciones de edicion de contenido visual. |
| ES2676394T3 (es) | 2012-01-16 | 2018-07-19 | Carlos TICÓ FARRÉ | Un procedimiento, un sistema y un producto de programa informático para certificar que un servidor de correo electrónico de destino ha recibido un mensaje de correo electrónico enviado por un emisor a al menos una dirección de destino |
| DK2632096T3 (en) * | 2012-02-21 | 2017-06-12 | Lleidanetworks Serveis Telemàtics S A | Procedure for certification of delivery of electronic messages |
| US8972357B2 (en) | 2012-02-24 | 2015-03-03 | Placed, Inc. | System and method for data collection to validate location data |
| US11734712B2 (en) | 2012-02-24 | 2023-08-22 | Foursquare Labs, Inc. | Attributing in-store visits to media consumption based on data collected from user devices |
| US10155168B2 (en) | 2012-05-08 | 2018-12-18 | Snap Inc. | System and method for adaptable avatars |
| US9436686B1 (en) * | 2012-08-07 | 2016-09-06 | Google Inc. | Claim evaluation system |
| US20150206349A1 (en) | 2012-08-22 | 2015-07-23 | Goldrun Corporation | Augmented reality virtual content platform apparatuses, methods and systems |
| EP2723023B1 (en) * | 2012-10-19 | 2020-03-04 | Lleidanetworks Serveis Telemàtics S.A. | Method for the registration and certification of receipt of electronic mail |
| US8775972B2 (en) | 2012-11-08 | 2014-07-08 | Snapchat, Inc. | Apparatus and method for single action control of social network profile access |
| AT13431U1 (de) * | 2012-12-03 | 2013-12-15 | Hpc Duale Zustellsysteme Gmbh | Verfahren zum Zustellen von Schriftstücken |
| ES2472272B1 (es) * | 2012-12-27 | 2015-04-13 | Safe Creative S.L. | Certificación digital del envío de un correo electrónico |
| US9633322B1 (en) | 2013-03-15 | 2017-04-25 | Consumerinfo.Com, Inc. | Adjustment of knowledge-based authentication |
| US10664936B2 (en) | 2013-03-15 | 2020-05-26 | Csidentity Corporation | Authentication systems and methods for on-demand products |
| KR101439018B1 (ko) * | 2013-04-11 | 2014-09-05 | 현대자동차주식회사 | 차량정보 제공 시스템 |
| US11159475B2 (en) * | 2013-05-14 | 2021-10-26 | International Business Machines Corporation | Sending a read receipt to each user specified on a read receipt distribution list |
| US9721147B1 (en) | 2013-05-23 | 2017-08-01 | Consumerinfo.Com, Inc. | Digital identity |
| US9742713B2 (en) * | 2013-05-30 | 2017-08-22 | Snap Inc. | Apparatus and method for maintaining a message thread with opt-in permanence for entries |
| US9705831B2 (en) | 2013-05-30 | 2017-07-11 | Snap Inc. | Apparatus and method for maintaining a message thread with opt-in permanence for entries |
| US10439972B1 (en) | 2013-05-30 | 2019-10-08 | Snap Inc. | Apparatus and method for maintaining a message thread with opt-in permanence for entries |
| US20150058133A1 (en) * | 2013-08-26 | 2015-02-26 | Michael D. Roth | Personal profile receiving apparatus and method of use thereof |
| US9578005B2 (en) * | 2013-10-01 | 2017-02-21 | Robert K Lemaster | Authentication server enhancements |
| US9083770B1 (en) | 2013-11-26 | 2015-07-14 | Snapchat, Inc. | Method and system for integrating real time communication features in applications |
| CA2863124A1 (en) | 2014-01-03 | 2015-07-03 | Investel Capital Corporation | User content sharing system and method with automated external content integration |
| US9628950B1 (en) | 2014-01-12 | 2017-04-18 | Investment Asset Holdings Llc | Location-based messaging |
| US10082926B1 (en) | 2014-02-21 | 2018-09-25 | Snap Inc. | Apparatus and method for alternate channel communication initiated through a common message thread |
| US8909725B1 (en) | 2014-03-07 | 2014-12-09 | Snapchat, Inc. | Content delivery network for ephemeral objects |
| US10373240B1 (en) | 2014-04-25 | 2019-08-06 | Csidentity Corporation | Systems, methods and computer-program products for eligibility verification |
| US9276886B1 (en) | 2014-05-09 | 2016-03-01 | Snapchat, Inc. | Apparatus and method for dynamically configuring application component tiles |
| US9396354B1 (en) | 2014-05-28 | 2016-07-19 | Snapchat, Inc. | Apparatus and method for automated privacy protection in distributed images |
| US9537811B2 (en) | 2014-10-02 | 2017-01-03 | Snap Inc. | Ephemeral gallery of ephemeral messages |
| IL239238B (en) | 2014-06-05 | 2022-04-01 | Mobli Tech 2010 Ltd | Automatic enrichment of advertising with the help of social network trends |
| US9113301B1 (en) | 2014-06-13 | 2015-08-18 | Snapchat, Inc. | Geo-location based event gallery |
| US9225897B1 (en) | 2014-07-07 | 2015-12-29 | Snapchat, Inc. | Apparatus and method for supplying content aware photo filters |
| US9906367B2 (en) * | 2014-08-05 | 2018-02-27 | Sap Se | End-to-end tamper protection in presence of cloud integration |
| US10055717B1 (en) | 2014-08-22 | 2018-08-21 | Snap Inc. | Message processor with application prompts |
| US10423983B2 (en) | 2014-09-16 | 2019-09-24 | Snap Inc. | Determining targeting information based on a predictive targeting model |
| US10824654B2 (en) | 2014-09-18 | 2020-11-03 | Snap Inc. | Geolocation-based pictographs |
| US11216869B2 (en) | 2014-09-23 | 2022-01-04 | Snap Inc. | User interface to augment an image using geolocation |
| US10284508B1 (en) | 2014-10-02 | 2019-05-07 | Snap Inc. | Ephemeral gallery of ephemeral messages with opt-in permanence |
| US9015285B1 (en) | 2014-11-12 | 2015-04-21 | Snapchat, Inc. | User interface for accessing media at a geographic location |
| US9854219B2 (en) | 2014-12-19 | 2017-12-26 | Snap Inc. | Gallery of videos set to an audio time line |
| US10311916B2 (en) | 2014-12-19 | 2019-06-04 | Snap Inc. | Gallery of videos set to an audio time line |
| US9385983B1 (en) | 2014-12-19 | 2016-07-05 | Snapchat, Inc. | Gallery of messages from individuals with a shared interest |
| US9754355B2 (en) | 2015-01-09 | 2017-09-05 | Snap Inc. | Object recognition based photo filters |
| US11388226B1 (en) | 2015-01-13 | 2022-07-12 | Snap Inc. | Guided personal identity based actions |
| US10133705B1 (en) | 2015-01-19 | 2018-11-20 | Snap Inc. | Multichannel system |
| US9521515B2 (en) | 2015-01-26 | 2016-12-13 | Mobli Technologies 2010 Ltd. | Content request by location |
| US9294425B1 (en) | 2015-02-06 | 2016-03-22 | Snapchat, Inc. | Storage and processing of ephemeral messages |
| US10447631B2 (en) | 2015-03-06 | 2019-10-15 | Microsoft Technology Licensing, Llc | Enhanced acknowledgment for messages |
| US10223397B1 (en) | 2015-03-13 | 2019-03-05 | Snap Inc. | Social graph based co-location of network users |
| KR102371138B1 (ko) | 2015-03-18 | 2022-03-10 | 스냅 인코포레이티드 | 지오-펜스 인가 프로비저닝 |
| US9692967B1 (en) | 2015-03-23 | 2017-06-27 | Snap Inc. | Systems and methods for reducing boot time and power consumption in camera systems |
| US9881094B2 (en) | 2015-05-05 | 2018-01-30 | Snap Inc. | Systems and methods for automated local story generation and curation |
| US10135949B1 (en) | 2015-05-05 | 2018-11-20 | Snap Inc. | Systems and methods for story and sub-story navigation |
| CN107431632B (zh) | 2015-05-06 | 2022-09-16 | 斯纳普公司 | 用于短暂群组聊天的系统和方法 |
| US10503264B1 (en) | 2015-06-16 | 2019-12-10 | Snap Inc. | Radial gesture navigation |
| US9906479B1 (en) | 2015-06-16 | 2018-02-27 | Snap Inc. | Storage management for ephemeral messages |
| US10993069B2 (en) | 2015-07-16 | 2021-04-27 | Snap Inc. | Dynamically adaptive media content delivery |
| US10817898B2 (en) | 2015-08-13 | 2020-10-27 | Placed, Llc | Determining exposures to content presented by physical objects |
| US11121997B1 (en) | 2015-08-24 | 2021-09-14 | Snap Inc. | Systems, devices, and methods for determining a non-ephemeral message status in a communication system |
| US10616162B1 (en) | 2015-08-24 | 2020-04-07 | Snap Inc. | Systems devices and methods for automatically selecting an ephemeral message availability |
| US10157333B1 (en) | 2015-09-15 | 2018-12-18 | Snap Inc. | Systems and methods for content tagging |
| US9652896B1 (en) | 2015-10-30 | 2017-05-16 | Snap Inc. | Image based tracking in augmented reality systems |
| US11119628B1 (en) | 2015-11-25 | 2021-09-14 | Snap Inc. | Dynamic graphical user interface modification and monitoring |
| US10474321B2 (en) | 2015-11-30 | 2019-11-12 | Snap Inc. | Network resource location linking and visual content sharing |
| US9984499B1 (en) | 2015-11-30 | 2018-05-29 | Snap Inc. | Image and point cloud based tracking and in augmented reality systems |
| US10354425B2 (en) | 2015-12-18 | 2019-07-16 | Snap Inc. | Method and system for providing context relevant media augmentation |
| KR101727126B1 (ko) * | 2015-12-29 | 2017-04-14 | 주식회사 코인플러그 | 파일에 대한 공증 및 검증을 수행하는 방법 및 서버 |
| US9674129B1 (en) | 2016-10-05 | 2017-06-06 | eTorch Inc. | Email privacy enforcement |
| US9824332B1 (en) | 2017-04-12 | 2017-11-21 | eTorch Inc. | Email data collection compliance enforcement |
| US9559997B1 (en) | 2016-01-11 | 2017-01-31 | Paul Everton | Client agnostic email processing |
| US10285001B2 (en) | 2016-02-26 | 2019-05-07 | Snap Inc. | Generation, curation, and presentation of media collections |
| US10679389B2 (en) | 2016-02-26 | 2020-06-09 | Snap Inc. | Methods and systems for generation, curation, and presentation of media collections |
| US11023514B2 (en) | 2016-02-26 | 2021-06-01 | Snap Inc. | Methods and systems for generation, curation, and presentation of media collections |
| US10530731B1 (en) | 2016-03-28 | 2020-01-07 | Snap Inc. | Systems and methods for chat with audio and video elements |
| US10270839B2 (en) | 2016-03-29 | 2019-04-23 | Snap Inc. | Content collection navigation and autoforwarding |
| US10339365B2 (en) | 2016-03-31 | 2019-07-02 | Snap Inc. | Automated avatar generation |
| US11900418B2 (en) | 2016-04-04 | 2024-02-13 | Snap Inc. | Mutable geo-fencing system |
| US10686899B2 (en) | 2016-04-06 | 2020-06-16 | Snap Inc. | Messaging achievement pictograph display system |
| US9813642B1 (en) | 2016-05-06 | 2017-11-07 | Snap Inc. | Dynamic activity-based image generation |
| US10474353B2 (en) | 2016-05-31 | 2019-11-12 | Snap Inc. | Application control using a gesture based trigger |
| US11068546B2 (en) | 2016-06-02 | 2021-07-20 | Nuix North America Inc. | Computer-implemented system and method for analyzing clusters of coded documents |
| US10334134B1 (en) | 2016-06-20 | 2019-06-25 | Maximillian John Suiter | Augmented real estate with location and chattel tagging system and apparatus for virtual diary, scrapbooking, game play, messaging, canvasing, advertising and social interaction |
| US10638256B1 (en) | 2016-06-20 | 2020-04-28 | Pipbin, Inc. | System for distribution and display of mobile targeted augmented reality content |
| US11201981B1 (en) | 2016-06-20 | 2021-12-14 | Pipbin, Inc. | System for notification of user accessibility of curated location-dependent content in an augmented estate |
| US10805696B1 (en) | 2016-06-20 | 2020-10-13 | Pipbin, Inc. | System for recording and targeting tagged content of user interest |
| US11044393B1 (en) | 2016-06-20 | 2021-06-22 | Pipbin, Inc. | System for curation and display of location-dependent augmented reality content in an augmented estate system |
| US11785161B1 (en) | 2016-06-20 | 2023-10-10 | Pipbin, Inc. | System for user accessibility of tagged curated augmented reality content |
| US11876941B1 (en) | 2016-06-20 | 2024-01-16 | Pipbin, Inc. | Clickable augmented reality content manager, system, and network |
| US11507977B2 (en) | 2016-06-28 | 2022-11-22 | Snap Inc. | Methods and systems for presentation of media collections with automated advertising |
| US10430838B1 (en) | 2016-06-28 | 2019-10-01 | Snap Inc. | Methods and systems for generation, curation, and presentation of media collections with automated advertising |
| US9681265B1 (en) | 2016-06-28 | 2017-06-13 | Snap Inc. | System to track engagement of media items |
| US10182047B1 (en) | 2016-06-30 | 2019-01-15 | Snap Inc. | Pictograph password security system |
| US10387514B1 (en) | 2016-06-30 | 2019-08-20 | Snap Inc. | Automated content curation and communication |
| US11334768B1 (en) | 2016-07-05 | 2022-05-17 | Snap Inc. | Ephemeral content management |
| US10855632B2 (en) | 2016-07-19 | 2020-12-01 | Snap Inc. | Displaying customized electronic messaging graphics |
| US20190190721A1 (en) * | 2016-08-14 | 2019-06-20 | Jeremy Machet | Email verification method |
| KR102267482B1 (ko) | 2016-08-30 | 2021-06-22 | 스냅 인코포레이티드 | 동시 로컬화 및 매핑을 위한 시스템 및 방법 |
| US10552968B1 (en) | 2016-09-23 | 2020-02-04 | Snap Inc. | Dense feature scale detection for image matching |
| US10609036B1 (en) | 2016-10-10 | 2020-03-31 | Snap Inc. | Social media post subscribe requests for buffer user accounts |
| US10432559B2 (en) | 2016-10-24 | 2019-10-01 | Snap Inc. | Generating and displaying customized avatars in electronic messages |
| KR20220156101A (ko) | 2016-11-01 | 2022-11-24 | 스냅 인코포레이티드 | 고속 비디오 캡처 및 센서 조절 |
| CN112738408B (zh) | 2016-11-07 | 2022-09-16 | 斯纳普公司 | 图像修改器的选择性识别和排序 |
| US10203855B2 (en) | 2016-12-09 | 2019-02-12 | Snap Inc. | Customized user-controlled media overlays |
| US10740939B1 (en) | 2016-12-09 | 2020-08-11 | Snap Inc. | Fast image style transfers |
| US11616745B2 (en) | 2017-01-09 | 2023-03-28 | Snap Inc. | Contextual generation and selection of customized media content |
| US10454857B1 (en) | 2017-01-23 | 2019-10-22 | Snap Inc. | Customized digital avatar accessories |
| US10915911B2 (en) | 2017-02-03 | 2021-02-09 | Snap Inc. | System to determine a price-schedule to distribute media content |
| US10319149B1 (en) | 2017-02-17 | 2019-06-11 | Snap Inc. | Augmented reality anamorphosis system |
| US11250075B1 (en) | 2017-02-17 | 2022-02-15 | Snap Inc. | Searching social media content |
| US10074381B1 (en) | 2017-02-20 | 2018-09-11 | Snap Inc. | Augmented reality speech balloon system |
| US11019001B1 (en) | 2017-02-20 | 2021-05-25 | Snap Inc. | Selective presentation of group messages |
| US10374993B2 (en) | 2017-02-20 | 2019-08-06 | Snap Inc. | Media item attachment system |
| US10878837B1 (en) | 2017-03-01 | 2020-12-29 | Snap Inc. | Acoustic neural network scene detection |
| US10565795B2 (en) | 2017-03-06 | 2020-02-18 | Snap Inc. | Virtual vision system |
| US10523625B1 (en) | 2017-03-09 | 2019-12-31 | Snap Inc. | Restricted group content collection |
| US10582277B2 (en) | 2017-03-27 | 2020-03-03 | Snap Inc. | Generating a stitched data stream |
| US10581782B2 (en) | 2017-03-27 | 2020-03-03 | Snap Inc. | Generating a stitched data stream |
| US11170393B1 (en) | 2017-04-11 | 2021-11-09 | Snap Inc. | System to calculate an engagement score of location based media content |
| US10387730B1 (en) | 2017-04-20 | 2019-08-20 | Snap Inc. | Augmented reality typography personalization system |
| US10212541B1 (en) | 2017-04-27 | 2019-02-19 | Snap Inc. | Selective location-based identity communication |
| US11893647B2 (en) | 2017-04-27 | 2024-02-06 | Snap Inc. | Location-based virtual avatars |
| KR20220141927A (ko) | 2017-04-27 | 2022-10-20 | 스냅 인코포레이티드 | 지도-기반 소셜 미디어 플랫폼들에 대한 위치 프라이버시 관리 |
| US10382372B1 (en) | 2017-04-27 | 2019-08-13 | Snap Inc. | Processing media content based on original context |
| US10467147B1 (en) | 2017-04-28 | 2019-11-05 | Snap Inc. | Precaching unlockable data elements |
| US10943255B1 (en) | 2017-04-28 | 2021-03-09 | Snap Inc. | Methods and systems for interactive advertising with media collections |
| US10679428B1 (en) | 2017-05-26 | 2020-06-09 | Snap Inc. | Neural network-based image stream modification |
| US10803120B1 (en) | 2017-05-31 | 2020-10-13 | Snap Inc. | Geolocation based playlists |
| CN107358550B (zh) * | 2017-06-08 | 2022-02-22 | 上海市高级人民法院 | 刑事案件智能证据校验方法、审查方法及具有其的存储介质和终端设备 |
| US10788900B1 (en) | 2017-06-29 | 2020-09-29 | Snap Inc. | Pictorial symbol prediction |
| US11323398B1 (en) | 2017-07-31 | 2022-05-03 | Snap Inc. | Systems, devices, and methods for progressive attachments |
| US11216517B1 (en) | 2017-07-31 | 2022-01-04 | Snap Inc. | Methods and systems for selecting user generated content |
| US11164376B1 (en) | 2017-08-30 | 2021-11-02 | Snap Inc. | Object modeling using light projection |
| US9980100B1 (en) | 2017-08-31 | 2018-05-22 | Snap Inc. | Device location based on machine learning classifications |
| US11475254B1 (en) | 2017-09-08 | 2022-10-18 | Snap Inc. | Multimodal entity identification |
| US10474900B2 (en) | 2017-09-15 | 2019-11-12 | Snap Inc. | Real-time tracking-compensated image effects |
| US10740974B1 (en) | 2017-09-15 | 2020-08-11 | Snap Inc. | Augmented reality system |
| US10891723B1 (en) | 2017-09-29 | 2021-01-12 | Snap Inc. | Realistic neural network based image style transfer |
| US10872292B1 (en) | 2017-10-09 | 2020-12-22 | Snap Inc. | Compact neural networks using condensed filters |
| US10499191B1 (en) | 2017-10-09 | 2019-12-03 | Snap Inc. | Context sensitive presentation of content |
| US10573043B2 (en) | 2017-10-30 | 2020-02-25 | Snap Inc. | Mobile-based cartographic control of display content |
| US10599289B1 (en) | 2017-11-13 | 2020-03-24 | Snap Inc. | Interface to display animated icon |
| US11551059B1 (en) | 2017-11-15 | 2023-01-10 | Snap Inc. | Modulated image segmentation |
| US10885564B1 (en) | 2017-11-28 | 2021-01-05 | Snap Inc. | Methods, system, and non-transitory computer readable storage medium for dynamically configurable social media platform |
| US11265273B1 (en) | 2017-12-01 | 2022-03-01 | Snap, Inc. | Dynamic media overlay with smart widget |
| US10217488B1 (en) | 2017-12-15 | 2019-02-26 | Snap Inc. | Spherical video editing |
| US11017173B1 (en) | 2017-12-22 | 2021-05-25 | Snap Inc. | Named entity recognition visual context and caption data |
| US10523606B2 (en) | 2018-01-02 | 2019-12-31 | Snap Inc. | Generating interactive messages with asynchronous media content |
| US10678818B2 (en) | 2018-01-03 | 2020-06-09 | Snap Inc. | Tag distribution visualization system |
| US10482565B1 (en) | 2018-02-12 | 2019-11-19 | Snap Inc. | Multistage neural network processing using a graphics processor |
| US11507614B1 (en) | 2018-02-13 | 2022-11-22 | Snap Inc. | Icon based tagging |
| US10885136B1 (en) | 2018-02-28 | 2021-01-05 | Snap Inc. | Audience filtering system |
| US10726603B1 (en) | 2018-02-28 | 2020-07-28 | Snap Inc. | Animated expressive icon |
| US10979752B1 (en) | 2018-02-28 | 2021-04-13 | Snap Inc. | Generating media content items based on location information |
| US10327096B1 (en) | 2018-03-06 | 2019-06-18 | Snap Inc. | Geo-fence selection system |
| US10933311B2 (en) | 2018-03-14 | 2021-03-02 | Snap Inc. | Generating collectible items based on location information |
| US11163941B1 (en) | 2018-03-30 | 2021-11-02 | Snap Inc. | Annotating a collection of media content items |
| US11310176B2 (en) | 2018-04-13 | 2022-04-19 | Snap Inc. | Content suggestion system |
| US10219111B1 (en) | 2018-04-18 | 2019-02-26 | Snap Inc. | Visitation tracking system |
| KR20240027845A (ko) | 2018-04-18 | 2024-03-04 | 스냅 인코포레이티드 | 증강 표현 시스템 |
| US11487501B2 (en) | 2018-05-16 | 2022-11-01 | Snap Inc. | Device control using audio data |
| US10896197B1 (en) | 2018-05-22 | 2021-01-19 | Snap Inc. | Event detection system |
| US10911234B2 (en) | 2018-06-22 | 2021-02-02 | Experian Information Solutions, Inc. | System and method for a token gateway environment |
| US10679393B2 (en) | 2018-07-24 | 2020-06-09 | Snap Inc. | Conditional modification of augmented reality object |
| US10997760B2 (en) | 2018-08-31 | 2021-05-04 | Snap Inc. | Augmented reality anthropomorphization system |
| US10698583B2 (en) | 2018-09-28 | 2020-06-30 | Snap Inc. | Collaborative achievement interface |
| US10778623B1 (en) | 2018-10-31 | 2020-09-15 | Snap Inc. | Messaging and gaming applications communication platform |
| US11199957B1 (en) | 2018-11-30 | 2021-12-14 | Snap Inc. | Generating customized avatars based on location information |
| US10939236B1 (en) | 2018-11-30 | 2021-03-02 | Snap Inc. | Position service to determine relative position to map features |
| US11032670B1 (en) | 2019-01-14 | 2021-06-08 | Snap Inc. | Destination sharing in location sharing system |
| US10939246B1 (en) | 2019-01-16 | 2021-03-02 | Snap Inc. | Location-based context information sharing in a messaging system |
| US11294936B1 (en) | 2019-01-30 | 2022-04-05 | Snap Inc. | Adaptive spatial density based clustering |
| US11297027B1 (en) | 2019-01-31 | 2022-04-05 | Snap Inc. | Automated image processing and insight presentation |
| US10936066B1 (en) | 2019-02-13 | 2021-03-02 | Snap Inc. | Sleep detection in a location sharing system |
| US10838599B2 (en) | 2019-02-25 | 2020-11-17 | Snap Inc. | Custom media overlay system |
| US10964082B2 (en) | 2019-02-26 | 2021-03-30 | Snap Inc. | Avatar based on weather |
| US10852918B1 (en) | 2019-03-08 | 2020-12-01 | Snap Inc. | Contextual information in chat |
| US11868414B1 (en) | 2019-03-14 | 2024-01-09 | Snap Inc. | Graph-based prediction for contact suggestion in a location sharing system |
| US11852554B1 (en) | 2019-03-21 | 2023-12-26 | Snap Inc. | Barometer calibration in a location sharing system |
| US11249614B2 (en) | 2019-03-28 | 2022-02-15 | Snap Inc. | Generating personalized map interface with enhanced icons |
| US10810782B1 (en) | 2019-04-01 | 2020-10-20 | Snap Inc. | Semantic texture mapping system |
| WO2020227801A1 (en) * | 2019-05-13 | 2020-11-19 | William Pearce | Method of detecting an email phishing attempt or fraudulent email using sequential email numbering |
| US10582453B1 (en) | 2019-05-30 | 2020-03-03 | Snap Inc. | Wearable device location systems architecture |
| US10560898B1 (en) | 2019-05-30 | 2020-02-11 | Snap Inc. | Wearable device location systems |
| US10893385B1 (en) | 2019-06-07 | 2021-01-12 | Snap Inc. | Detection of a physical collision between two client devices in a location sharing system |
| US11134036B2 (en) | 2019-07-05 | 2021-09-28 | Snap Inc. | Event planning in a content sharing platform |
| US11307747B2 (en) | 2019-07-11 | 2022-04-19 | Snap Inc. | Edge gesture interface with smart interactions |
| CN112351404B (zh) * | 2019-08-08 | 2022-08-16 | 上海擎感智能科技有限公司 | 一种蓝牙连接方法、装置及车机 |
| US11812347B2 (en) | 2019-09-06 | 2023-11-07 | Snap Inc. | Non-textual communication and user states management |
| US11941065B1 (en) | 2019-09-13 | 2024-03-26 | Experian Information Solutions, Inc. | Single identifier platform for storing entity data |
| US11821742B2 (en) | 2019-09-26 | 2023-11-21 | Snap Inc. | Travel based notifications |
| US11218838B2 (en) | 2019-10-31 | 2022-01-04 | Snap Inc. | Focused map-based context information surfacing |
| US11429618B2 (en) | 2019-12-30 | 2022-08-30 | Snap Inc. | Surfacing augmented reality objects |
| US11128715B1 (en) | 2019-12-30 | 2021-09-21 | Snap Inc. | Physical friend proximity in chat |
| US10880496B1 (en) | 2019-12-30 | 2020-12-29 | Snap Inc. | Including video feed in message thread |
| US11169658B2 (en) | 2019-12-31 | 2021-11-09 | Snap Inc. | Combined map icon with action indicator |
| US11343323B2 (en) | 2019-12-31 | 2022-05-24 | Snap Inc. | Augmented reality objects registry |
| CN111246479B (zh) * | 2020-01-06 | 2023-08-01 | 上海闻泰电子科技有限公司 | 抵御假冒运营商攻击的方法、装置、终端设备及存储介质 |
| US11316806B1 (en) | 2020-01-28 | 2022-04-26 | Snap Inc. | Bulk message deletion |
| US11265281B1 (en) | 2020-01-28 | 2022-03-01 | Snap Inc. | Message deletion policy selection |
| US11228551B1 (en) | 2020-02-12 | 2022-01-18 | Snap Inc. | Multiple gateway message exchange |
| US11516167B2 (en) | 2020-03-05 | 2022-11-29 | Snap Inc. | Storing data based on device location |
| US11619501B2 (en) | 2020-03-11 | 2023-04-04 | Snap Inc. | Avatar based on trip |
| US10956743B1 (en) | 2020-03-27 | 2021-03-23 | Snap Inc. | Shared augmented reality system |
| US11430091B2 (en) | 2020-03-27 | 2022-08-30 | Snap Inc. | Location mapping for large scale augmented-reality |
| US11625873B2 (en) | 2020-03-30 | 2023-04-11 | Snap Inc. | Personalized media overlay recommendation |
| CN115699130A (zh) * | 2020-03-31 | 2023-02-03 | 斯纳普公司 | 增强现实美容产品教程 |
| US11700225B2 (en) | 2020-04-23 | 2023-07-11 | Snap Inc. | Event overlay invite messaging system |
| CN111651346B (zh) * | 2020-04-27 | 2022-11-18 | 深圳平安医疗健康科技服务有限公司 | 前端组件的测试方法、装置、存储介质及计算机设备 |
| US11843574B2 (en) | 2020-05-21 | 2023-12-12 | Snap Inc. | Featured content collection interface |
| US11423652B2 (en) | 2020-06-10 | 2022-08-23 | Snap Inc. | Adding beauty products to augmented reality tutorials |
| KR20230022241A (ko) | 2020-06-10 | 2023-02-14 | 스냅 인코포레이티드 | 애플리케이션을 론칭하기 위한 시각적 검색 |
| US11483267B2 (en) | 2020-06-15 | 2022-10-25 | Snap Inc. | Location sharing using different rate-limited links |
| US11290851B2 (en) | 2020-06-15 | 2022-03-29 | Snap Inc. | Location sharing using offline and online objects |
| US11503432B2 (en) | 2020-06-15 | 2022-11-15 | Snap Inc. | Scalable real-time location sharing framework |
| US11314776B2 (en) | 2020-06-15 | 2022-04-26 | Snap Inc. | Location sharing using friend list versions |
| US11308327B2 (en) | 2020-06-29 | 2022-04-19 | Snap Inc. | Providing travel-based augmented reality content with a captured image |
| US11899905B2 (en) | 2020-06-30 | 2024-02-13 | Snap Inc. | Selectable items providing post-viewing context actions |
| US11832015B2 (en) | 2020-08-13 | 2023-11-28 | Snap Inc. | User interface for pose driven virtual effects |
| US11349797B2 (en) | 2020-08-31 | 2022-05-31 | Snap Inc. | Co-location connection service |
| US11606756B2 (en) | 2021-03-29 | 2023-03-14 | Snap Inc. | Scheduling requests for location data |
| US11645324B2 (en) | 2021-03-31 | 2023-05-09 | Snap Inc. | Location-based timeline media content system |
| US11829834B2 (en) | 2021-10-29 | 2023-11-28 | Snap Inc. | Extended QR code |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3441003B2 (ja) * | 1993-03-17 | 2003-08-25 | 日本電信電話株式会社 | マルチメディア情報転送方法 |
| JPH07253972A (ja) * | 1994-03-16 | 1995-10-03 | Hitachi Ltd | 文書通信装置とその文書処理方法 |
| JPH07273791A (ja) * | 1994-03-29 | 1995-10-20 | Sumitomo Electric Ind Ltd | マルチメディア電子メールシステム |
| US5553145A (en) * | 1995-03-21 | 1996-09-03 | Micali; Silvia | Simultaneous electronic transactions with visible trusted parties |
| AU5883896A (en) | 1995-05-31 | 1996-12-18 | Marshall A. Sloo | Method and apparatus for handling communications |
| US6343313B1 (en) * | 1996-03-26 | 2002-01-29 | Pixion, Inc. | Computer conferencing system with real-time multipoint, multi-speed, multi-stream scalability |
| IL119430A0 (en) | 1996-10-15 | 1997-01-10 | Barkan Mordhai | Electronic mail system and method |
| US5978836A (en) * | 1997-07-28 | 1999-11-02 | Solectron Corporation | Workflow systems and methods |
| WO1999008424A1 (de) | 1997-08-06 | 1999-02-18 | Siemens Aktiengesellschaft | Verfahren und vorrichtung zur generierung von informationen über versendete nachrichten |
| US6725376B1 (en) * | 1997-11-13 | 2004-04-20 | Ncr Corporation | Method of using an electronic ticket and distributed server computer architecture for the same |
| US6314454B1 (en) * | 1998-07-01 | 2001-11-06 | Sony Corporation | Method and apparatus for certified electronic mail messages |
| US6618747B1 (en) * | 1998-11-25 | 2003-09-09 | Francis H. Flynn | Electronic communication delivery confirmation and verification system |
| US6609138B1 (en) * | 1999-03-08 | 2003-08-19 | Sun Microsystems, Inc. | E-mail list archiving and management |
| WO2001010090A1 (en) | 1999-07-28 | 2001-02-08 | Tomkow Terrance A | System and method for verifying delivery and integrity of electronic messages |
| US7886008B2 (en) * | 1999-07-28 | 2011-02-08 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
| US7966372B1 (en) | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
| JP2001109487A (ja) * | 1999-10-07 | 2001-04-20 | Matsushita Electric Ind Co Ltd | 電子メールの音声再生装置、その音声再生方法、及び音声再生プログラムを記録した記録媒体 |
| US6438215B1 (en) * | 2000-02-29 | 2002-08-20 | Ameritech Corporation | Method and system for filter based message processing in a unified messaging system |
| US6584564B2 (en) * | 2000-04-25 | 2003-06-24 | Sigaba Corporation | Secure e-mail system |
| JP4521943B2 (ja) * | 2000-07-24 | 2010-08-11 | キヤノン株式会社 | 情報提供装置及び情報提供方法、コンピュータ読み取り可能な記憶媒体 |
| JP2002041404A (ja) * | 2000-07-24 | 2002-02-08 | Canon Inc | 情報提供システム及び装置とその方法 |
| JP3900806B2 (ja) * | 2000-08-10 | 2007-04-04 | 村田機械株式会社 | ファクシミリサーバ |
-
2002
- 2002-02-22 US US09/991,201 patent/US7240199B2/en not_active Expired - Fee Related
-
2003
- 2003-02-21 WO PCT/US2003/004964 patent/WO2003073711A2/en active Application Filing
- 2003-02-21 DK DK03721293T patent/DK1476995T3/da active
- 2003-02-21 EP EP03721293A patent/EP1476995B1/en not_active Expired - Lifetime
- 2003-02-21 KR KR1020047013043A patent/KR101029030B1/ko not_active IP Right Cessation
- 2003-02-21 PT PT03721293T patent/PT1476995E/pt unknown
- 2003-02-21 CN CN038042800A patent/CN1636365B/zh not_active Expired - Fee Related
- 2003-02-21 DE DE60321543T patent/DE60321543D1/de not_active Expired - Lifetime
- 2003-02-21 AT AT03721293T patent/ATE398373T1/de active
- 2003-02-21 CA CA2476176A patent/CA2476176C/en not_active Expired - Fee Related
- 2003-02-21 CN CN2012100464577A patent/CN102638449A/zh active Pending
- 2003-02-21 ES ES03721293T patent/ES2307924T3/es not_active Expired - Lifetime
- 2003-02-21 AU AU2003224616A patent/AU2003224616B2/en not_active Ceased
- 2003-02-21 JP JP2003572260A patent/JP2005518763A/ja active Pending
-
2006
- 2006-01-06 HK HK06100301.8A patent/HK1080644B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| HK1080644A1 (en) | 2006-04-28 |
| US20020144154A1 (en) | 2002-10-03 |
| CN1636365A (zh) | 2005-07-06 |
| ATE398373T1 (de) | 2008-07-15 |
| HK1080644B (zh) | 2013-01-25 |
| PT1476995E (pt) | 2008-09-22 |
| CA2476176C (en) | 2013-11-26 |
| AU2003224616A2 (en) | 2003-09-09 |
| DE60321543D1 (de) | 2008-07-24 |
| JP2005518763A (ja) | 2005-06-23 |
| AU2003224616B2 (en) | 2008-12-11 |
| CA2476176A1 (en) | 2003-09-04 |
| KR20040091656A (ko) | 2004-10-28 |
| US7240199B2 (en) | 2007-07-03 |
| CN1636365B (zh) | 2012-05-09 |
| AU2003224616A1 (en) | 2003-09-09 |
| KR101029030B1 (ko) | 2011-04-15 |
| DK1476995T3 (da) | 2008-10-13 |
| EP1476995A2 (en) | 2004-11-17 |
| CN102638449A (zh) | 2012-08-15 |
| WO2003073711A3 (en) | 2003-11-27 |
| WO2003073711A2 (en) | 2003-09-04 |
| EP1476995B1 (en) | 2008-06-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2307924T3 (es) | Sistema y metodo para verificar la transmision y la integridad de mensajes electronicos. | |
| US10887271B2 (en) | System and method for verifying delivery and integrity of electronic messages | |
| KR100604630B1 (ko) | 전자 메시지의 배달 및 완전성을 검증하는 시스템 및 방법 | |
| US10182026B2 (en) | System for, and method of, providing the transmission, receipt and content of a reply to an electronic message | |
| US7660989B2 (en) | System for, and method of, authenticating an electronic message to a recipient | |
| US20050021963A1 (en) | System for, and method of, proving the transmission, receipt and content of a reply to an electronic message |