ES2299666T3 - Un sistema de gestion de la informacion. - Google Patents

Un sistema de gestion de la informacion. Download PDF

Info

Publication number
ES2299666T3
ES2299666T3 ES03077587T ES03077587T ES2299666T3 ES 2299666 T3 ES2299666 T3 ES 2299666T3 ES 03077587 T ES03077587 T ES 03077587T ES 03077587 T ES03077587 T ES 03077587T ES 2299666 T3 ES2299666 T3 ES 2299666T3
Authority
ES
Spain
Prior art keywords
message
data
email
user
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES03077587T
Other languages
English (en)
Inventor
Peter Bryan Malcolm
John Anthony Napier
Andrew Mark Stickler
Nathan John Tamblin
Paul James Owen Beadle
Jason Paul Crocker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orchestria Ltd
Original Assignee
Orchestria Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orchestria Ltd filed Critical Orchestria Ltd
Application granted granted Critical
Publication of ES2299666T3 publication Critical patent/ES2299666T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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/214—Monitoring or handling of messages using selective forwarding
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • 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/212—Monitoring or handling of messages using filtering or selective blocking

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Game Theory and Decision Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Educational Administration (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Selective Calling Equipment (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Circuits Of Receivers In General (AREA)
  • Alarm Systems (AREA)

Abstract

Un sistema de gestión de información que comprende: una pluralidad de estaciones de trabajo adaptadas para su conexión a una red de ordenadores, teniendo cada estación de trabajo una memoria; una aplicación almacenada en dicha memoria de cada estación de trabajo para recibir mensajes de entrada desde dicha red y para transmitir un mensaje recibido como un menaje de salida a dicha red; un analizador, integrado dentro de la aplicación, siendo operable dicho analizador junto con los datos de directivas para determinar uno o más detalles completos del mensaje de salida, según se inicia la transmisión del mensaje de salida, y para impedir selectivamente que el mensaje de salida se reenvíe a otro receptor, o emitir una advertencia antes de que el mensaje se reenvíe a otro receptor, en dependencia con las normas definidas en dichos datos de directivas; en el que los datos de directivas están definidos de modo centralizado para la pluralidad de estaciones de trabajo, conteniendo normas para determinar uno o mas detalles completos del mensaje de salida, y para controlar la transmisión de dicho mensaje de salida en dependencia con esos detalles.

Description

Un sistema de gestión de la información.
Antecedentes de la invención
Esta invención se refiere a la provisión de la funcionalidad de gestión extendida de aplicaciones de Internet, particularmente en las áreas de seguridad de la información, revisión y reporte de transacciones, directivas centralizadas y conectividad de la aplicación.
El comercio electrónico ("comercio electrónico"), particularmente entre negocios ("B2B"), pero también entre negocios y consumidores ("B2C"), es un mercado de rápido crecimiento donde compradores y vendedores se comunican usando la Internet, una red de ámbito mundial de sistemas de ordenadores enlazados, en lugar de por medios tradicionales tales como el correo, el teléfono o las reuniones personales. Los vendedores anuncian sus productos y servicios usando folletos y catálogos digitales, que pueden verse o descargarse a través de una conexión de Internet, a través de páginas sobre la Web de Ámbito Mundial (WWW), o a través de sitios de mercado electrónico que típicamente tratan con artículos o servicios de un sector del mercado en particular. Los compradores pueden encontrar suministradores, seleccionar artículos, obtener cotizaciones, colocar o seguir pedidos, e incluso realizar pagos de forma enteramente electrónica y en cualquier instante. El comercio electrónico trae la promesa de incrementar la flexibilidad, elección y eficacia, con costos de obtención reducidos drásticamente.
Hay dos medios universalmente aceptados para interfaz de los usuarios con la Internet. El primero de estos es el "Buscador Web" que permite a los usuarios ver páginas de la Web de Ámbito Mundial accediendo a sitios Web individuales, las direcciones de las cuales se publican típicamente ampliamente, bien usando medios tradicionales, o haciendo referencia en otro sitio Web. El buscador Web más ampliamente adoptado es el "Internet Explorer" de la Corporación Microsoft.
El segundo medio de interfaz es usando un programa de Correo Electrónico, con el cual el usuario compone un mensaje, conocido como un correo electrónico, que a continuación se dirige electrónicamente a la dirección de receptor pretendido sobre la Internet. Los programas bien conocidos de Correo Electrónico incluyen el "Lotus Notes" de la Corporación IBM y el "Outlook" de la Corporación Microsoft.
En un escenario típico de comercio electrónico, un comprador puede identificar un producto particular, junto con los precios y la información de suministro, sobre el sitio Web del vendedor. A continuación el puede hacer un pedido, bien rellenando un pedido electrónico sobre el sitio Web, o enviando un correo electrónico directamente al vendedor. El pedido incluiría típicamente un compromiso de pago, quizás en la forma de detalles de una Tarjeta de Crédito, o mediante algún medio de pago electrónico. El vendedor típicamente enviaría un correo electrónico de vuelta para confirmar la aceptación del pedido.
Los Buscadores Web funcionan de acuerdo con normativas reconocidas, en particular el Protocolo de Transferencia de Hipertexto ("HTTP"), descrito totalmente en el documento de normativas de Internet RFC2616. Los programas de Correo Electrónico funcionan de acuerdo con normativas reconocidas, en particular el Protocolo de Transferencia de Correo Simple ("SMTP"), descrito enteramente en el documento de normativas de Internet RFC0821 y las Extensiones de Correo de Internet Multipropósito ("MIME") descrito enteramente en los documentos de normativas de Internet RFC2045-2049.
Ya que el comercio electrónico proporciona enormes beneficios, su adopción aumenta a muchos nuevos usos, que pueden dirigirse para asegurar su adopción continuada, particularmente si es para reemplazar en última instancia métodos tradicionales, Uno de los temas centrales es la seguridad.
La Internet es una red de comunicaciones abierta, que es por definición insegura ya que puede usarla cualquiera. Se han proporcionado medios para asegurar la información sensible a intercambiar sobre la Internet (por ejemplo una transacción de comercio electrónico) por la adopción de protocolos de transmisión y mensajería seguros. Los protocolos de transmisión seguros punto a punto, usados por ejemplo entre un Servidor Web y un Buscador Web, incluyen la "Capa de Conexión Segura" ("SSL"), definida por la Corporación de Comunicaciones Netscape, y su sucesor "Seguridad de la Capa de Transporte" ("TLS") definida en el documento de normativas de Internet RFC2246. Las normativas de mensajes de correo electrónico seguro incluyen las "Extensiones del Correo de Internet Multipropósito Seguro" ("S/MIME") descrito enteramente en el documento de normativas de Internet RFC2633 y el "Pretty Good Privacy" un sistema de mensajería segura de dominio público desarrollado por Philip Zimmerman.
Para controlar el acceso a la información sobre servidores conectados a la Internet, se ha adoptado ampliamente un sistema de nombres de usuario y contraseñas. Por ejemplo, el acceso a listas de precios con descuentos sobre un servidor Web particular puede estar restringido a usuarios de comercio que previamente han dado un nombre de usuario y contraseña permitiéndoles el acceso. De forma similar, los servicios de información en-línea típicamente hacen extensivo el uso de nombres de usuario y contraseñas para restringir el acceso a los que han pagado por el servicio. Proporcionando a cada usuario con un nombre de usuario único y una contraseña que se puede cambiar, el servicio puede asegurar que sólo los abonados de pago pueden acceder al sistema, y permitir a los usuarios impedir el acceso por otros a sus datos personales almacenados por el servicio.
En las aplicaciones de comercio electrónico, el tema de la identificación y la confianza es un problema considerable. Cuando un suministrador recibe un pedido a través de Internet es perfectamente posible, incluso probable, que no haya un conocimiento previo del cliente. El suministrador puede establecer que el cliente es a) quien el dice que es, en otras palabras que no está enmascarando a otra persona, y que b) que es de confianza y pagará en última instancia por los artículos o servicios a suministrar. Estos temas se han tratado principalmente en el comercio B2C por el uso de de tarjetas de crédito. El cliente proporciona su número de tarjeta de crédito y dirección con el pedido, que el suministrador verifica a continuación con la compañía de la tarjeta de crédito, y obtiene una autorización para el cargo. El proceso entero se realiza típicamente en línea sin intervención humana. Este método es en gran parte eficaz cuando un suministrador envía artículos a la dirección del titular de la tarjeta, ya que un ladrón potencial no sólo necesitaría robar los detalles de los titulares de la tarjeta, sino que también necesitarían interceptar la entrega de los artículos. Es mucho menos eficaz en el caso de servicios donde no está involucrada una entrega física.
Claramente, el uso de tarjetas de crédito en el comercio electrónico, aunque extendido, está restringido a las transacciones de pequeña escala que involucran potencialmente cantidades, digamos, de hasta 10.000 \textdollar. Para las transacciones por encima de tales cantidades (que en términos monetarios conjuntos exceden a los que están por debajo), debe usarse una tercera parte de confianza mutua para establecer tanto la identidad como la confianza.
Fundamental para establecer la identidad es el uso de los Certificados Digitales. Puede emitirse al cliente un Certificado Digital por una tercera parte de confianza, que se usa a continuación para "firmar" electrónicamente las comunicaciones. A la recepción de un mensaje firmado, el receptor (en este caso el suministrador) puede establecer positivamente a) la identidad del remitente, b) que el mensaje no se ha alterado, y c) que el remitente no puede por consiguiente denegar que el envió el mensaje. Las normativas reconocidas para los Certificados Digitales se describen en el documento X.509 de la ITU, y su uso en las comunicaciones de Internet en los documentos de normativas de Internet RFC2312, RFC2459, RFC2510, RFC2511, RFC2527, RFC2560, RFC2585 y RFC2632.
Pueden usarse los servicios de una Tercera parte, que se pueden facturar, tal como los proporcionados por Valicert Inc., para verificar que un Certificado Digital no se ha revocado, por ejemplo después de que el certificado se haya comprometido de algún modo.
Una vez que se establece la autenticidad de los mensajes, el suministrador puede usar otra tercera parte para establecer la confianza, o la misma tercera parte puede usarse para establecer tanto la autenticidad como la confianza. Por ejemplo, "Identrus", un consorcio de los mayores bancos del mundo, proporciona un sistema tal que cuando un suministrador recibe un mensaje firmado con un Certificado Digital emitido por Identrus, puede verificar independientemente que el cliente es titular de una cuenta válida de buen prestigio con un banco reconocido. En última instancia, el sistema se ha extendido de tal modo que el banco adicionalmente garantizará la transacción, y por consiguiente garantiza el pago al suministrador. Se apreciará que los términos "cliente" o "suministrador" pueden aplicarse a cualesquiera partes involucradas en la comunicación de Internet.
Puede verse que las combinaciones apropiadas de los sistemas descritos proporcionan un fundamento seguro para el uso de la Internet y los servicios y funciones disponibles a través de la misma. Sin embargo, hemos apreciado que hay varios problemas al dirigir el comercio electrónico usando sólo estos sistemas. Estos problemas se tratan a continuación.
En los protocolos de transmisión y mensajería seguros relacionados anteriormente, los datos usualmente se cifran antes de la transmisión y se descifran por el receptor pretendido antes de verlos. De este modo, si los datos se interceptaran durante la transmisión, serán seguros de ser vistos por terceras partes no autorizadas a menos que conozcan o puedan averiguar la clave de cifrado secreta del algoritmo de cifrado.
El cifrado y descifrado de los datos en cada extremo de un enlace seguro o mensaje requiere una potencia significativa de procesamiento. Adicionalmente ambas partes de transmisión y recepción deben estar en posesión de la misma clave de cifrado del algoritmo de cifrado, con la misma fortaleza de cifrado, para que el sistema funcione con éxito. Esto a menudo presenta un problema, por ejemplo cuando las regulaciones para la importación y exportación de datos hacia dentro o fuera de un sistema de ordenador prohíben el uso de algoritmos de mayor fortaleza, forzando el enlace o mensaje a cifrarse con una fortaleza de cifrado menor, o impidiendo totalmente las comunicaciones seguras. Por consiguiente, los enlaces y mensajería seguros se usan típicamente sólo cuando es necesario.
En el caso de comunicaciones sobre la Web de Ámbito Mundial, los requisitos para las transmisiones seguras se determinan y se inician por el servidor Web. Si, por ejemplo, el servidor está a punto de transmitir un formulario de pedido para que se complete por el usuario puede iniciar un enlace seguro de modo que la información del pedido se cifrará cuando se transmita de vuelta al servidor. De forma similar, una vez que el pedido está completo el servidor puede terminar el enlace seguro y volver a la comunicación normal no cifrada.
Típicamente, la única indicación que el usuario tiene de que se ha asegurado un enlace es un icono (usualmente representando un candado), que aparece en la ventana del buscador. Una vez que ha aparecido el icono, el usuario puede a continuación típicamente interrogar al buscador para determinar la fortaleza del algoritmo de cifrado que se está usando, y puede decidir si entrar o no, y posteriormente transmitir información sensible, tal como los detalles de su tarjeta de crédito y dirección.
En la práctica, sin embargo, los usuarios frecuentemente no comprueban que el enlace es seguro y mucho menos que la fortaleza de cifrado es adecuada para proteger la información que se está transmitiendo. Para resolver este problema, las aplicaciones de correo electrónico tales como el "Outlook" de la Corporación Microsoft proporcionan la capacidad de cifrar por defecto todos los correos electrónicos.
La amplia adopción de nombres de usuario y contraseñas ha creado un problema de gestión para muchos usuarios de Internet debido al número puro que necesitan recordar, particularmente cuando una buena práctica de seguridad requiere cambiar frecuentemente las contraseñas. De forma similar, los usuarios a menudo necesitan usar una variedad de nombres de usuario diferentes ya que algunas personas pueden haber tomado su "favorito" en un sitio determinado. En Buscadores de páginas como el "Internet Explorer" de la Corporación Microsoft, se han proporcionado facilidades para recordar, y completar automáticamente los campos de nombre de usuario y contraseña en las ocasiones posteriores, y añadiendo las utilidades de "ayudante" tal como el "Gator" de Gator.com. Estas facilidades mantienen típicamente un fichero de nombres de usuario, contraseñas y la página Web a la cual se aplica cada una. Estos ficheros están cifrados para asegurar que sólo el usuario apropiado pueda acceder a los mismos. Si se pierden tales ficheros de nombres de usuario y contraseñas o se vuelven inservibles, tal como cuando el usuario autorizado ha olvidado la clave de cifrado y ya no puede contactarse para proporcionarla, o cuando el fichero se pierde accidentalmente o maliciosamente, se destruye o se corrompe entonces el acceso a las cuentas de Internet pueden perderse, y cada sitio debe enfocarse individualmente para reemplazar o recuperar el nombre de usuario y/o contraseña necesarias. Esto pude ser un problema muy caro para las corporaciones en términos de accesos perdidos y tiempo de administración. Adicionalmente, tales nombres de usuario y contraseñas recordados están sólo disponibles para su uso sobre la máquina sobre la cual se usaron originalmente. Si el usuario se mueve a otra máquina, o usa múltiples máquinas entonces los nombres de usuario y contraseñas no están disponibles para el mismo desde las otras máquinas.
Todos los negocios, y muchos usuarios individuales, tienen una obligación legal de mantener los registros precisos de las transacciones que emprendan, pero para las transacciones del comercio electrónico esto puede resultar difícil. Los negocios deben mantener grabaciones para propósitos de revisión, por ejemplo para probar los términos bajo los cuales se pidieron los artículos en el caso de un conflicto. Tales registros son considerablemente más difíciles de mantener en un entorno de comercio electrónico, requiriendo que el usuario retenga, por ejemplo copias de los pedidos enviados por correo electrónico, o imprimir el recibo de la página de la Web a partir de la compra del sitio Web. Para el usuario, esta es una labor intensiva y no hay garantía de que cualquiera de tales grabaciones creadas sea completa o fiable.
Una solución automatizada de mantener registros de las transacciones de comercio electrónico se suministra por la aplicación Max Manager de la Corporación Max Manager. Max Manager captura las páginas de recibo en los sitios Web conocidos, extrae la información de la transacción a partir de esas páginas de recibos, y a continuación almacena localmente tanto la página del recibo como la información de la transacción extraída sobre la máquina sobre la cual está corriendo la aplicación. Sin embargo, para operar, el Max Manager debe suministrarse con la dirección exacta y la composición de la página del recibo. Max Manager determina que ha tenido lugar una transacción de comercio electrónico bien detectando la dirección de la página del recibo, o comparando la página actual que se está viendo por el buscador con la composición de la página recibo con la que se ha suministrado. Una vez que se ha identificado una página de recibo, se extraen los detalles relevantes de las transacciones a partir de la página del recibo usando la composición conocida de la página como una plantilla para propósito de comparación. Un inconveniente significativo con el Max Manager es que sólo puede usarse para extraer datos de las páginas para las cuales se han suministrado con los detalles. Además, si la composición de la página de recibo se cambia entonces el Max Manager no puede extraer de modo significativo ningún dato de la página hasta que se suministre con una nueva plantilla para la composición cambiada. Como los sitios Web se cambian frecuentemente, el Max Manager debe actualizarse constantemente para tener en cuenta tales cambios. Esto no es práctico a gran escala y conduce inevitablemente a que las transacciones se pierdan o lo que es peor que se informen incorrectamente.
Los problemas también provienen del hecho de que los terminales de ordenador están distribuidos, resultando a menudo que terminales y usuarios que están localizados en diferentes localizaciones. En entornos multiusuario, las máquinas de usuario pueden estar físicamente conectadas entre sí, usando por ejemplo una Red de Área Local ("LAN"), que proporciona un puerto de salida para la conexión a Internet. También pueden estar conectados a servidores locales tales como el "Exchange Server" de la Corporación Microsoft, que actúa como una punto central de recogida y distribución para mensajes de correo electrónico, y el "Proxy Server" de la Corporación Microsoft, que actúa tanto como una memoria caché para mejorar el funcionamiento de los Sitios Web visitados frecuentemente, y como un filtro para impedir el acceso a ciertos Sitios Web que pueden haberse señalado como no deseables. Sin embargo, en lo que se refiere al intercambio de información, excepto en el caso de un mensaje enviado entre dos usuarios locales, cada usuario opera enteramente aislado de los otros en la misma localización. Esto presenta un problema de gestión significativo para una corporación y otras organizaciones, que no tienen medios de controlar la actividad de los empleados y no pueden beneficiarse del ahorro significativo de costes que podría efectuarse por compartir información. Por ejemplo, dos usuarios en una organización pueden recibir independientemente mensajes de correo electrónico firmados digitalmente por el mismo remitente. Ambos receptores deben validar por separado el Certificado Digital, incurriendo en dos cargos de validación, al menos uno de los cuales fue innecesario.
Un sistema y un método para crear, editar y distribuir normas para procesar mensajes electrónicos se conoce de la patente de Estados Unidos número US 5.917.489. Tales normas se determinan por los usuarios de la estación de trabajo para borrar ayudas, rellenar, y responder a sus mensajes.
El documento US 6.073.142 describe un sistema y método para el aplazamiento y revisión automática de mensajes de correo electrónico.
La presente invención proporciona una funcionalidad adicional a los sistemas mencionados anteriormente para aliviar sus problemas inherentes y proporcionar un sistema integrado único para el intercambio de información.
Sumario de la invención
La invención se muestra en las reivindicaciones independientes a las cuales se hará ahora referencia. Las características ventajosas de la invención se fijan en las reivindicaciones adjuntas.
El sistema de gestión de información proporciona muchas ventajas en el entorno de comercio electrónico a las compañías que comercian en-línea, que pueden beneficiarse siendo capaces de regular las transacciones realizadas por su staff de acuerdo con sus instrucciones codificadas en los datos de directivas, automáticamente mantienen registros de contraseñas y negocios conducidos en-línea, evitando el pago por comprobaciones innecesarias de la validez de los certificados digitales, y asegurar que la transmisión de datos por su staff se realiza siempre con seguridad.
Breve descripción de los dibujos
Se describirá ahora con más detalle la realización preferida de la invención, a modo de ejemplo, y con referencia a los dibujos en los que:
la Figura 1 es una ilustración esquemática de la disposición actual de los sistemas y recursos que constituyen la Internet de acuerdo con la técnica anterior;
la Figura 2 es una ilustración esquemática de la realización preferida de la invención implementada en un entorno corporativo;
la Figura 3 es una ilustración esquemática del funcionamiento de un buscador Web de acuerdo con la realización preferida de la invención;
la Figura 4 es una ilustración de una ventana típica de entrada generada por un buscador Web;
la Figura 5 es una ilustración esquemática del funcionamiento de un cliente de correo electrónico de acuerdo con la realización preferida de la invención;
la Figura 6 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con la realización preferida de la invención, para capturar los valores del nombre de usuario y de la contraseña transmitidos por un usuario al sitio remoto de la Web;
la Figura 7 es una ilustración de un ejemplo de datos de directivas que especifican las condiciones de control para los datos de grabación;
la Figura 8 es un diagrama de flujo que ilustra el funcionamiento de un módulo que de expansión, de acuerdo con la realización preferida de la invención, para el reconocimiento de números de tarjeta de crédito contenidos en los datos transmitidos a o desde un servidor Web o un cliente de correo electrónico;
la Figura 9 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con la realización preferida de la invención, para establecer la validez de un certificado digital recibido por un usuario;
la Figura 10 es una ilustración de un ejemplo de datos de directivas para determinar si un certificado digital debe o no comprobarse;
la Figura 11 es diagrama de flujo que ilustra cómo se usa el ejemplo de datos de directivas mostrados en la Figura 10 para determinar si se requiere o no la verificación para un certificado digital;
la Figura 12 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para identificar las transmisiones desde un usuario o a un usuario que comprende parte de una transacción de comercio electrónico;
la Figura 13 es una ilustración de ejemplo de datos de directivas que se pretenden usar con el proceso ilustrado en la Figura 12 para identificar una transacción;
\newpage
la Figura 14 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para grabar transmisiones identificadas que comprenden una parte de una transacción simple formando por lo tanto un registro de la transacción;
la Figura 15 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para la aprobación o rechazo de las transacciones identificadas sobre la base de un escenario de directivas predeterminadas; y
la Figura 16 es una ilustración de ejemplo de datos de directivas para determinar si una transacción identificada requiere aprobación, y para identificar un aprobador apropiado;
la Figura 17 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para determinar un nivel apropiado de cifrado para una transmisión y permitir que esa transmisión se transmita sólo si se proporciona ese nivel;
la Figura 18 es una ilustración de ejemplo de datos de directivas que especifican la fortaleza de cifrado requerida para diversos tipos de datos;
la Figura 19 es una ilustración de ejemplo de datos de directivas para controlar el re-direccionamiento de los mensajes de salida;
la Figura 20 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para el re-direccionamiento de los mensajes de salida a una tercera parte para su revisión antes de su transmisión, utilizando los datos de directivas mostrados en la Figura 19;
la Figura 21 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, para controlar la carga hacia arriba de la información a un sitio externo de la compañía, utilizando los datos de directivas mostrados en la figura 19;
la Figura 22 es una ilustración de ejemplo de datos de directivas para controlar el reenvío de mensajes a receptores dentro o fuera de la compañía;
la Figura 23 es un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, usando los datos de directivas mostrados en la Figura 22;
la Figura 24 es una ilustración de ejemplo de datos de directivas para controlar si un mensaje de salida está firmado digitalmente o no; y
la Figura 25 un diagrama de flujo que ilustra el funcionamiento de un módulo de expansión, de acuerdo con una realización preferida de la invención, que utiliza los datos de directivas mostrados en la Figura 24.
Descripción de la realización preferida
El sistema preferido proporciona a los usuarios de Internet con un modo automático de gestionar el flujo de información sobre un sistema de ordenadores. Este proporciona facilidades para gestionar el nivel de seguridad al que se producen las transmisiones, facilidades para grabar las transacciones en-línea y para suspender transacciones que están a punto de realizarse a terceras partes para su aprobación, y medios para detener la realización de transacciones si se rechaza la aprobación; también proporciona facilidades para extraer y grabar los datos pertinentes a partir de cualesquiera transmisiones que se reciben o están a punto de transmitirse, y para gestionar de forma inteligente la transmisión de correos electrónicos.
El sistema preferido proporciona soluciones para muchos problemas encontrados por las compañías de comercio electrónico que comercian sobre la Internet; en consecuencia la siguiente discusión de ejemplo se dirigirá en su mayor parte a la implementación y uso del sistema por una compañía de un tamaño razonable que dirige al menos algunos de sus negocios sobre la Internet. Se apreciará que sin embargo cualquiera, incluyendo compañías de cualquier tamaño o descripción y los individuos privados, que usen la Internet pueden beneficiarse de la funcionalidad proporcionada por el sistema preferido.
La funcionalidad del sistema preferido se implementa mediante módulos de código que se "conectan" dentro del buscador Web o el cliente de correo electrónico. Estos módulos "de expansión" pueden usarse para controlar y alterar el comportamiento del buscador Web o el cliente de correo electrónico en su funcionamiento.
Muchos buscadores Web y clientes de correo electrónico ya existentes pueden integrarse fácilmente con tales módulos de expansión. En el caso del Internet Explorer de Microsoft, el módulo se conoce como un "Ayudante del Buscador", y se describe más enteramente en el documento "Browser Helper Objects: The Browser the Way You Want It" de Dino Esposito, publicado por la Corporación Microsoft en Enero de 1999. En el caso del Outlook de Microsoft y Exchange de Clientes de correo electrónico, la expansión se conoce como módulo "Extension" y se describe más enteramente en el documento "Microsoft Outlook and Exchange Client Extensions" de Sharon Lloyd, publicado por la Corporación Microsoft en Marzo de 1998. El uso de los módulos "Browser Helper Object" y "Extension" realizado en el sistema preferido se describirá con más detalle más adelante.
El uso de los módulos de expansión del buscador o del cliente de correo electrónico para implementar la funcionalidad del sistema preferido tiene la ventaja adicional de que, como el cifrado del contenido del mensaje se realiza usualmente por el propio buscador o cliente de correo electrónico, el examen del contenido de la transmisión, para extraer la información de la contraseña o para determinar el nivel deseado de cifrado por ejemplo, puede tener lugar antes de que el contenido se haya cifrado listo para la transmisión, o efectivamente después de que se haya recibido y descifrado.
La Figura 1 muestra la relación entre los proveedores de servicio, típicamente compañías que venden artículos y servicios sobre la Internet 10, y usuarios que desean comprar tales artículos o servicios. Los usuarios equipados con buscadores Web 22, 24 y 26, pueden conectar a través de Internet y recuperar información de la página Web desde los servidores Web 14 y 18. Como alternativa los usuarios con aplicaciones de correo electrónico 20, 30 y 32 pueden enviar mensajes de correo electrónico con abc.com y xyz.com a través de los servidores de correo electrónico 12 y
16.
En un establecimiento corporativo, tal como el que se ilustra en la esquina superior derecha de la Figura 1, los buscadores Web 24 y 26 del usuario corporativo se conectan a la Internet a través del servidor delegado 28. El servidor delegado 28 se usa como caché de las páginas Web y control de acceso a los sitios Web. De forma similar, la corporación tiene clientes de correo electrónico 30 y 32, conectados a la Internet a través del servidor de correo electrónico 34 que actúa como un punto de recogida central para los correos electrónicos de entrada en la corporación y que controlan la distribución de los correos electrónicos a los usuarios individuales. Se apreciará que aunque la Figura 1 describe abc.com y xyz.com como vendedores, la corporación puede ser tanto un comprador como un vendedor, y como compradores abc.com y xyz.com se describirían como usuarios corporativos para el propósito de esta descripción.
En el caso de los correos electrónicos enviados y recibidos por la aplicación de correo electrónico personal 20, se observará que el correo típicamente se recogerá y se distribuirá por un servidor de correo electrónico remoto proporcionado por el suministrador del servicio de conexión a la Internet al cual se suscribe el usuario personal.
Aunque muchas de las características y funciones de este sistema proporcionan un beneficio considerable a los usuarios individuales, el sistema proporciona la máxima ventaja cuando funciona en un entorno multiusuario donde la información de transacción se comparte con muchos usuarios. La Figura 2 muestra un diagrama esquemático de la configuración preferida del sistema en un entorno multiusuario. El sistema preferido comprende un servidor de Gestión Central 40 conectado a la base de datos 42 y a las consolas de operador 44. El Servidor de Gestión Central 40 está también conectado a las Expansiones de Aplicación de la Oficina de Gestión que comprende las Interfaces de Aplicación 50, 52 y una Interfaz del Programa de Aplicación abierta 54, y los componentes del Puerto de salida 60, 62 y 64. El componente del Puerto de salida 62 se muestra conectado a las Expansiones de Aplicación de Usuario, localizadas en una o más máquinas de usuario, comprendiendo la Expansión de Internet Explorer 70, la Expansión del Navegador de Netscape 72, la Expansión de Microsoft Outlook 74 y la Expansión de Lotus Notes 76. Estas expansiones se usan para proporcionar la funcionalidad del sistema preferido en el programa hospedador en el cual están integrados. Se muestran cuatro programas hospedadores posibles, el Internet Explorer, el Navegador de Netscape, el Outlook de Microsoft y el Lotus Notes, pero puede usarse cualquier otro programa con la capacidad de conectar con la Internet, suponiendo que su comportamiento pueda modificarse para implementar la funcionalidad del sistema preferido.
La conexión a Internet 10 se realiza a través de las expansiones de las aplicaciones de Usuario y sus programas hospedadores respectivos.
Los componentes del puerto de salida 70, 72 y 74 son opcionales pero se prefieren ya que permiten escalar todo el sistema, con cada puerto de salida que almacena o reenvía información, permitiendo por lo tanto que se conecten cualquier número de usuarios.
La información procedente de las Expansiones de aplicación múltiple 70, 72, 74 y 76 para las diferentes aplicaciones sobre máquinas de usuario múltiples, se comparte con el servidor de gestión central 40 y se almacena en la base de datos asociada 42.
Los Módulos de Aplicación de Oficina Posterior 50, 52 y 54 permiten al sistema hacer interfaz con aplicaciones de gestión de una tercera parte tales como los sistemas de procesamiento de pedidos y contabilidad. Esto permite que la información de transacción se introduzca automáticamente y se procese por tales sistemas.
Las Consolas del Operador 44 se proporcionan para propósitos administrativos, y en particular para la aprobación de transacciones. Aunque se representa lógicamente conectado directamente al servidor de gestión central en la Figura 2, tales consolas podrían funcionar sobre cualquier máquina conectada en red. Cuando una expansión de correo electrónico o buscador Web determina que una transacción particular requiere la aprobación, se envía una petición al Servidor de Gestión Central y se pone en cola pendiente de la aprobación por un operador autorizado.
El funcionamiento del sistema se controla por los datos de directivas, que almacenan las regulaciones de la corporación relativas a la seguridad, autorización, y las acciones que se permite realizar a los usuarios, así como una información de funcionamiento. Preferiblemente, los datos de directivas se almacenan en un fichero de directivas sobre el Servidor de Gestión para su acceso por cualquiera de las Consolas de Operador 44, las Expansiones de Aplicación de la Oficina de Gestión o las Expansiones de Aplicación de Usuario. El administrador del sistema o el supervisor de la red pueden definir una o más directivas o escenarios del fichero de directivas y pueden asignar usuarios individuales o grupos de usuarios a diferentes directivas, controlando de este modo la capacidad de usuario o incluso la capacidad de una estación de trabajo para interactuar con la Internet sin necesidad de fijar parámetros y controlar directamente cada máquina de usuario. Un usuario en un departamento de contabilidad o una compañía por ejemplo puede asignarse a unas "directivas de contabilidad"; cualquier cambio posterior a esas directivas resultará automáticamente en un cambio en las capacidades de todos los usuarios asignados a esas directivas.
Es preferible que la capacidad de editar o fijar los datos de directivas esté restringida al supervisor de red o a otra persona o personas autorizadas. Esto pude conseguirse designando uno o más estaciones de trabajo supervisoras en la red, posibilitadas con acceso para editar los datos de directivas tales como las Consolas de Operador 44.
Preferiblemente, las directivas son como una estructura de árbol, que permiten a los escenarios obligarse a bajar a los nodos de directivas individuales, y realizarse cambios globales rápidamente, por ejemplo si la CEO desea hacer que todas las compras requieran su aprobación si el flujo de caja de la compañía podría convertirse en un problema. Tal sistema basado en directivas reduce enormemente la latencia inherente tanto en los sistemas de compra tradicionales como en los entornos de compras actuales de comercio electrónico.
Cada usuario de la red tendrá su propia representación de los datos de directivas. Preferiblemente, se almacenan sólo las ramas y las hojas de cada directiva de usuario que difieren de las directivas de red maestra ya que esto permite ahorrar espacio en memoria. Aunque los datos de directivas se almacenan preferiblemente en forma de fichero sobre el Servidor de Gestión Central, no se pretende que el almacenamiento de los datos de directivas se restrinja sólo a la forma de fichero. Cualquier otra representación o codificación de escenario de directivas puede emplearse dentro del sistema preferido.
Ahora se describirá con más detalle la implementación del sistema en un buscador Web o en un cliente de correo electrónico.
Uso del sistema preferido en un buscador Web
La Figura 3 muestra el funcionamiento simplificado de un buscador Web. El buscador Web se lanza en la etapa S100 en respuesta a una petición de comienzo desde el usuario o automáticamente desde el fichero de arranque del ordenador de usuario. El fichero de arranque del ordenador del usuario contiene comandos para poner en funcionamiento automáticamente los programas especificados cuando el ordenador se inicia. Después de que el buscador Web se ha arrancado, típicamente solicita una "página de inicio", la página Web para ver por defecto, de acuerdo con un escenario predeterminado. Esto se muestra en la etapa S102.
La petición se envía al servidor Web apropiado 90, la dirección exacta de Internet de la cual se determina usualmente por los Servicios de Nombres de Dominios; el servidor Web 90 responde a continuación con los datos apropiados que definen la página Web. Este proceso se representa respectivamente como las etapas S104 y S106 que resultan en la etapa S108.
Los datos que definen la página Web consisten de un descriptor HTML, y otros tipos de datos posibles tales como XML o ActiveX, y Javascript que codifican programas ejecutables. El Buscador interpreta estos datos, mostrándolos en pantalla y/o ejecutándolos como sea apropiado en la etapa S110.
A continuación, típicamente el buscador espera para la entrada de usuario en la etapa S112. Tal entrada puede incluir rellenar campos presentados en pantalla, hacer clic sobre un hiper-enlace, o introducir la dirección de URL de la nueva página Web. En última instancia, tales acciones conducen a que se envíe una petición adicional al servidor Web 90 en la etapa S114 y la etapa S116. La petición puede ser simplemente otra dirección de página Web, o puede contener datos adicionales como los que se tecleen por el usuario en los campos presentados en
pantalla.
La Figura 4 muestra una pantalla de ejemplo de página Web, en la cual se presenta una GUI al usuario para recibir el nombre de usuario y la dirección de correo electrónico. Se verá de la referencia a la Figura 4 que el usuario ha introducido su nombre como "Fred Smith" dentro del campo provisto a la petición de nombre, y su dirección de correo electrónico como "fsmith@xyz.com" dentro del campo de dirección de correo electrónico.
Cuando el usuario hace clic sobre el botón de "Enviar" proporcionado sobre la ventana de petición, los detalles introducidos por el usuario se incluyen en el comando enviado el servidor Web 90. Tal comando puede ser;
http://www.sample.com/ sample2.htm? UserID = Fred+Smith&email = fsmith@xyz.com&submit = submit
De lo anterior puede verse que el nombre de usuario se incorpora dentro del comando como el valor de una variable llamada "UserID" y su dirección de correo electrónico se incorpora como el valor de una variable llamada "email".
El comando se ensambla en la etapa S114, y se transmite al servidor Web 90 en la etapa S116 donde pueden usarse el nombre de usuario y la dirección de correo electrónico, por ejemplo para mandar información del producto al usuario a través de correo electrónico, o para obtener acceso a otras páginas Web.
El módulo de expansión proporcionado por la realización preferida de la invención en la forma de un Objeto de Ayuda al Buscador (BHO) proporciona una funcionalidad adicional para aumentar la del buscador Web normalizado. El BHO se implementa para responder a un número significativo de eventos que se producen cuando el buscador Web se opera y se dirige por el usuario para interactuar con diversos sitios y páginas Web.
El BHO se implementa para monitorizar las peticiones de navegación y los datos transmitidos al servidor Web desde el buscador y los datos de identificación que son únicos para el usuario. Esto puede hacerse simplemente buscando en el flujo de datos de salida la presencia de palabras o frases predeterminadas. En el caso anterior mostrado en la Figura 4, pueden buscarse las dos definiciones de variables "UserID" y "email", y los datos que siguen a los mismos se extraen y se almacenan. Como alternativa, el BHO puede buscar el símbolo "?", que indica el final de la dirección URL a la que se está conectando e indica que lo que sigue son datos. El BHO puede monitorizar también los datos del flujo de entrada recibido desde el sitio Web al que se está conectando.
También, puede implementarse el BHO para monitorizar la operación del propio buscador Web. Al funcionar el buscador Web genera "eventos" para notificar a los módulos software co-dependientes u objetos de que acaba de ocurrir alguna cosa significativa o que se acaba de completar una acción. El nombre del evento es usualmente descriptivo en si mismo de lo que acaba de ocurrir; normalmente están disponibles datos adicionales que describen el evento con más detalles. El BHO está implementado para atrapar estos eventos y tomar una acción dependiendo de los mismos.
Uno de tales eventos para los que el BHO está implementado para responder al llamado "BeforeNavegation2" que lanza el buscador Web cuando el usuario solicita al buscador navegar por una nueva página. El evento se emite y puede reconocerse por el BHO antes de que se descargue la página solicitada, permitiendo al BHO tomar cualquier acción pertinente antes de que el usuario vea la página. Una de tales acciones podría ser grabar la página y cualquiera de los datos transmitidos en respuesta a esa página en una base de datos. Otra de tales acciones podría ser identificar el URL de la página solicitada a partir del evento e impedir que la página se descargue.
Otro evento que atrapa el BHO es el evento de "DocumentComplete", que se lanza por el buscador Web cuando se ha descargado totalmente una nueva página desde el sitio Web dentro de la memoria. La página se codifica en la forma de un Objeto de Documento, conforme al Modelo de Objeto de Documento de Microsoft (DOM). El DOM proporciona un acceso exhaustivo a los datos que comprenden la página, permitiendo BHO extraer los elementos de datos que son de su interés. Por ejemplo, el BHO puede solicitar datos del DOM para determinar si la página forma parte de una transacción de comercio electrónico. Esto puede hacerse buscando objetos en el DOM términos tales como "Recibo" o "Numero de Cuenta".
El BHO puede usar también el DOM para determinar los nombres de los campos o tipos de campos de los datos que se están solicitando sobre una página Web. Los datos introducidos por el usuario dentro de tales campos pueden extraerse a continuación desde el DOM y almacenarse o adoptar medidas. Los nombres de los campos son típicamente descriptivos de lo que se almacena; las contraseñas, por ejemplo, se mantienen frecuentemente en un campo llamado "contraseña" y de ese modo pueden buscarse sobre una página Web. Los números de las tarjetas de crédito pueden buscarse de un modo similar. Usualmente, los campos de contraseñas son un tipo tal que cualesquiera datos de entrada se presentan en pantalla como asteriscos. Esto también puede determinarse del análisis del DOM y usarse para identificar los datos pertinentes.
Los datos de usuario normalmente no estarían presentes en una página Web descargada del sitio de la Web, sino que se introducen por el usuario dentro de un formato HTML. Usualmente, los datos de usuario potencialmente sensibles se transmiten al sitio de la página Web a través del servidor Web cuando el usuario selecciona el botón de "Enviar". En esta etapa, el BHO puede atrapar el evento "Enviar" emitido por el buscador Web, y acceder al DOM para extraer los datos de usuario, y si es necesario, impedir que los datos se transmitan.
El cifrado y descifrado sobre un enlace seguro tiene lugar después del punto C y antes del punto A en la Figura 3 respectivamente. De este modo, el BHO puede analizar los datos antes de cifrarlos o después de descifrarlos. Esto es una ventaja ya que no hay necesidad de que el mismo BHO realice cualquier codificación o descodificación de los datos. Esto no afecta a la capacidad de determinar si el enlace es seguro o no, ya que un enlace seguro puede identificarse por el identificador del protocolo "https" en el comienzo de la dirección de la URL actual. Se prefiere que el examen del contenido de la transmisión tenga lugar antes de que se produzca el cifrado o después del descifrado.
Discusión del funcionamiento de un cliente de correo electrónico
Ahora se describen, con referencia a la Figura 5 de los dibujos, el funcionamiento de un cliente típico de correo electrónico, y la implementación de la realización preferida en un cliente de correo electrónico.
La Figura 5 muestra la operación simplificada de un cliente de correo electrónico. Las operaciones de Recepción y Envío típicamente funcionan independientemente, y estas operaciones se muestran separadamente sobre los lados opuestos de la Figura 5, comenzando con las etapas S120 y las etapas S130 respectivamente.
Una operación de "recibir un mensaje" de un cliente de correo electrónico se inicia en la etapa S120. Esto se puede hacerse automáticamente a intervalos predeterminados para mantener al usuario informado de cualesquiera nuevos mensajes que reciba, o puede hacerse en respuesta a la selección manual del usuario del icono de "recibir mensajes". El comienzo esta operación causa que el cliente de correo electrónico pregunte al servidor de correo electrónico 95 y descargue cualesquiera nuevos mensajes a la máquina del usuario. En la etapa S122, se recibe un mensaje de correo electrónico por el cliente de correo electrónico. Típicamente, cuando se recibe un nuevo mensaje, se añade a una "caja de entrada", con las cabeceras de los mensajes recibidos (nombre de los remitentes, fecha y título para por ejemplo) dispuestos en una lista. El usuario hace clic a continuación sobre la entrada apropiada en la lista para leer todo el mensaje produciendo que se presente sobre la pantalla de su ordenador. El mensaje de correo electrónico se presenta en pantalla en la etapa S124.
En el caso de un correo electrónico de salida, el usuario selecciona la opción de "componer correo electrónico" en la etapa S130. En respuesta, el cliente de correo electrónico proporciona una interfaz que comprende un editor de texto en el cual el usuario puede introducir el texto del cuerpo del mensaje y otra información tal como la dirección de destino, tema y así sucesivamente. El usuario compone el mensaje en la etapa S132 y a continuación opta por enviarlo, seleccionando un icono o una opción de menú proporcionada por el cliente de correo electrónico para emitir un "comando de envío". El correo electrónico se envía al servidor de correo electrónico para su transmisión al receptor en la etapa S134. Si se aplica cualquier cifrado por el cliente de correo electrónico, se aplica en la etapa S134 antes de la transmisión.
En la realización preferida, se proporciona una funcionalidad adicional para el cliente de correo electrónico a través de un módulo de expansión. Preferiblemente, el cliente de correo electrónico es uno de los proporcionados por Microsoft, tal como el cliente Microsoft Exchange, o el cliente Microsoft Outlook, y el módulo de expansión se codifica como una extensión del cliente Exchange. Estos se describen en el documento "Microsoft Outlook and Exchange Client Extensions" de Sharon Lloyd mencionados anteriormente.
Una Extensión del Cliente de Exchange es un objeto componente que cumple con el Modelo de Objeto Componente (COM) de Windows de Microsoft y ese utiliza la interfaz de Exchange IExchExt. Esta Interfaz proporciona varias interfaces adicionales para modificar el funcionamiento del cliente de correo electrónico Exchange, tal como la Interfaz de Comandos IExchExt, que permite modificar o reemplazar el comportamiento de un cliente existente y añadir nuevos comandos al menú del cliente; y la interfaz IExchExtEvents que permite personalizar el comportamiento a implementar para manejar los "eventos" del cliente tales como la llegada de nuevos mensajes, lectura, escritura, envío de mensajes y lectura y escritura del los ficheros adjuntos. También se proporcionan las interfaces IExchExtMessageEvents, IExchtSessionEvents y el IExchExtAttachmentEvents y proporcionan una funcionalidad añadida para las tareas más específicas que cada uno de los nombres de interfaces sugiere.
En la realización preferida, la Extensión de Cliente Exchange que forma el módulo de expansión se implementa para responder a lo "eventos" del cliente que se lanzan por el programa del cliente cuando realiza operaciones y completa acciones. Los "eventos" en cuestión se proporcionan por las interfaces COM que se han mencionado anteriormente. La monitorización del cliente de correo electrónico por el módulo de expansión puede verse por lo tanto como análogo al modo en el que el módulo de expansión BHO monitoriza la operación del buscador Web.
El módulo de expansión del cliente de correo electrónico se implementa para responder al evento "OnDelivery" que se lanza por ejemplo cuando se recibe un nuevo mensaje desde el sistema de suministro de correo subyacente y antes de que sea visible por el usuario. El evento "OnDelivery" contiene información para acceder a las diferentes partes del mensaje de correo electrónico que se ha descargado y que se mantiene en la memoria. La cabecera del mensaje, el cuerpo del mensaje y cualesquiera anexos se codifican en memoria como propiedades del objeto del mensaje que pueden accederse separadamente a través de llamadas a la Interfaz del Programa de Aplicación de Correo (MAPI).
A través de la información suministrada como parte del evento "OnDelivery", el módulo de expansión puede acceder a la cabecera del mensaje y extraer por ejemplo la identidad del remitente. Además, el módulo de expansión puede utilizar la información obtenida de las llamadas MAPI para explorar el cuerpo del mensaje recibido para palabras clave o los datos pertinentes. Puede buscar una evidencia de una transacción de comercio electrónico, identificando palabras significativas como "recibo" o "número de cuenta". El mensaje puede almacenarse a continuación para propósito de revisión. En el caso de un remitente no aprobado, o un contenido del mensaje perjudicial, puede borrarse el mensaje sin verse.
El análisis de un correo electrónico recibido se produce entonces en el punto A en la Figura 5 antes de que se vea por el usuario. Preferiblemente el correo electrónico se examina incluso antes de que el correo electrónico se coloque en la Caja de entrada. Cuando un mensaje no se descifra automáticamente antes de situarse en la Caja de entrada, por ejemplo cuando se requiere que el usuario introduzca una clave de descifrado, el mensaje se examina inmediatamente después del descifrado, pero antes de que se vea. Los Certificados Digitales pueden incluirse en los anexos al correo electrónico y pueden examinarse fácilmente antes de verlos, permitiendo cualesquiera acciones apropiadas a realizar, tales como una validación.
Otro evento significativo del cliente que implementa el módulo de expansión es responder al evento "OnWriteComplete" que se lanza cuando el usuario ha seleccionado el "comando enviar" y ha solicitado al cliente de correo electrónico transmitir un nuevo correo electrónico al sistema de entrega de correo. Este evento se lanza, en el punto B en la Figura 5, antes de que tenga lugar la transmisión y antes de cualquier cifrado. El nuevo mensaje a transmitir está almacenado en memoria del mismo modo que un objeto que puede accederse por las llamadas MAPI. El módulo de expansión puede usar las llamadas MAPI para explorar el contenido del correo electrónico de salida para los datos sensibles, tales como un número de la tarjeta de crédito, y 
\hbox{posteriormente produce que el mensaje  se grabe o
incluso se bloquee.}
Funcionamiento del Módulo de Expansión
Anteriormente se ha descrito la implementación preferida de los módulos de expansión del buscador Web y del cliente de correo electrónico con referencia a las Figuras 3 y 5. A continuación, se describirá con detalle la funcionalidad proporcionada por los módulos de expansión y con referencia a las Figuras 6 a 18.
Identificación y Grabación de los Nombres de Usuario, Contraseñas y otra información
El sistema preferido proporciona un medio para identificar, recoger y almacenar los datos contenidos en las transmisiones a y desde una estación de trabajo de usuario automáticamente, en particular, los nombres de usuario y contraseñas introducidos por un usuario para acceder a las páginas de sitios Web, los sitios del Protocolo de Transferencia de Ficheros ("FTP") y a otros sitios similares sobre la Internet.
Los sistemas que actualmente proporcionan facilidades para grabar las contraseñas sólo lo hacen cuando un usuario hace clic sobre la opción "recordar contraseña" proporcionada por la GUI. La contraseña se almacena dentro de un fichero local protegido sobre la máquina del usuario que sólo se abre cuando el usuario se autentifica sobre esa máquina, por ejemplo, introduciendo su nombre de usuario y contraseña en el instante de arranque. La opción de recordar la contraseña hace que el sistema recuerde la contraseña del usuario cuando visita la próxima vez, rellenando el campo de la contraseña con la contraseña de modo que el usuario no tiene que introducirla cada vez que se solicita. El inconveniente del fichero de contraseñas que las tiene almacenadas localmente es que si el usuario se traslada a otra máquina no tiene acceso al fichero de contraseñas almacenado y tendrá que reintroducir la contraseña el mismo.
El sistema preferido identifica las contraseñas automáticamente, sin necesidad de una instrucción por el usuario, y almacena las contraseñas identificadas y nombres de usuario en un almacén de datos. Preferiblemente ésta es la base de datos central 42. Esto permite re-llamar las contraseñas de cualquier usuario independientemente del terminal en el cual inicie sesión el usuario, proporcionando que el terminal tenga acceso a la base de datos central.
Cualesquiera contraseñas identificadas y nombres de usuario se almacenan en la base de datos junto con los nombres de los campos en los cuales están almacenados sobre el sitio de la Web original y la dirección del sitio de Internet al cual se transmitieron y en el cual se usan. La información del sitio puede recuperarse sencillamente como se incluye en la petición de HTTP enviando la información de contraseña y nombre de usuario a ese sitio, y en representación de la página Web mantenida en memoria.
Preferiblemente, en bien de la seguridad, la información almacenada en la base de datos se cifra, de modo que sólo varias personas seleccionadas, tales como los supervisores de red, los administradores de sistema o los directores de la compañía tienen acceso a la misma. Estos pueden acceder a la base de datos bien a través de una estación de trabajo en la red, introduciendo un nombre de usuario o una contraseña para identificarse a si mismos, o a través de una estación de trabajo del supervisor, tal como las Consolas de Operador 44.
Este almacenamiento de nombres de usuario y contraseñas junto con los detalles de las direcciones presenta una ventaja significativa para las compañías que usan las facilidades en línea. Con las tecnologías existentes, si un usuario olvida su contraseña de autentificación impidiéndose el acceso al fichero protegido, o deja la compañía sin haberla revelado, el servicio de Internet no puede accederse. Una situación similar se produce si se daña el fichero protegido, se borra o por el contrario se pierde. Cada servicio de Internet debe accederse entonces para reemplazar o recuperar la contraseña perdida, que puede ser caro en términos de acceso perdido y tiempo administrativo. Con el sistema preferido, la información de la contraseña puede recuperarse desde la base de datos central, de modo que no se pierde el acceso a los sitios Web.
La Figura 6 es un diagrama de flujo que ilustra esquemáticamente el funcionamiento del módulo de expansión implementado para extraer la información del nombre de usuario y de contraseña a partir de los datos a transmitir al servidor Web.
En la Etapa S150, el módulo de expansión comienza y analiza sintácticamente los datos a punto de transmitirse al servidor Web desde el buscador. Esto se produce en el punto "C" en el proceso ilustrado en la Figura 3. El control pasa a continuación a la etapa S152 donde el módulo de expansión determina si los datos que se van a transmitir contienen o no la información de nombre de usuario o contraseña.
Las contraseñas y nombres de usuario pueden identificarse del modo descrito anteriormente con referencia a las Figuras 3, 4 y 5, identificando los nombres de campos en el comando enviado o usando el DOM, por ejemplo, para buscar nombres de campo, tipos de campo, o el método de presentación en pantalla usado para identificar los datos sobre las páginas Web. Estos pueden recuperarse también del HTML de las páginas Web, de las ventanas asociadas o de la GUI (Interfaz Gráfica de Usuario) presentada por los servidores o proveedores remotos sobre la Web de Ámbito Mundial o incluso explorando el contenido de los mensajes de correo electrónico.
Identificar las contraseñas y los nombres de usuario en los comandos transmitidos o en el DOM de una página Web a partir de sus nombres de campos depende de los nombres de los campos que describen su propósito con etiquetas obvias tales como "contraseña" o "nombre de usuario". En casos en los que los nombres de cambo no son en si mismo significativos, la naturaleza de los datos que se están transmitiendo, pueden inferirse a partir del tipo de datos, que son "Cadena de caracteres", "Entero" y así sucesivamente, o el método de la presentación en pantalla usada para introducir los datos. Los campos que se pretenden para recibir una contraseña pueden identificarse a partir de la representación buscando un tipo de campo "contraseña" en el DOM. Las cajas de texto sobre una página Web dentro de la cual se introducen los datos de contraseña, por ejemplo, presentan típicamente un carácter de entrada como un asterisco; esta propiedad puede determinarse a partir del DOM y usarse para inferir que la entrada de datos a la celda de texto es una contraseña incluso si no hay otras indicaciones. Aunque, la contraseña se presenta en pantalla como una cadena de asteriscos, la representación en memoria aún contiene la información del carácter que se ha introducido por el usuario. La contraseña puede recuperarse simplemente extrayendo la entrada del campo.
Como alternativa, las contraseñas y los nombres de usuario pueden identificarse refiriéndonos a los almacenados por otros programas tales como el "Internet Explorer" de Microsoft cuando se selecciona la opción de recordar contraseña por el usuario. Tales contraseñas se almacenan en un fichero local protegido sobre el ordenador del usuario. Este fichero se "abre" cuando el usuario se autentifica sobre el ordenador, y por tanto puede accederse para obtener la información de contraseña y nombre de usuario por el módulo de expansión del buscador del sistema preferido.
Si el módulo de expansión no detecta un nombre de usuario o una contraseña en los datos que se están transmitiendo, el control pasa a la etapa S158 en cuyo punto el módulo sale y el control pasa de nuevo al punto "C" en la Figura 3. El buscador puede entonces transmitir los datos al servidor Web. Si por el contrario, se detecta un nombre de usuario o una contraseña por el módulo de expansión en la etapa S152 a continuación pasa el control a la etapa S154, donde los valores del nombre de usuario o contraseña identificados y el URL u otro identificador se extraen de la página Web a la cual se transmiten los datos. El control pasa a continuación a la etapa S156 donde, estos valores y el URL u otro identificador se almacenan en una base de datos predeterminada del sistema 42. Una vez que ha tenido lugar el almacenamiento, el control pasa a la etapa S158, donde el módulo sale y el control se pasa de nuevo al punto "C" en la Figura 3. El buscador puede transmitir a continuación los datos al servidor Web.
La realización preferida necesita no estar limitada sólo al almacenamiento de contraseñas y nombres de usuario que se han utilizado como un ejemplo por la ventaja inmediata que proporciona su almacenamiento. Puede ser útil extraer y almacenar otros tipos de datos, en particular los relativos a las transacciones del comercio electrónico, tales como información de tarjetas de crédito y certificados digitales para proporcionar una base de datos o registro. El sistema puede también aplicarse para extraer información de las transmisiones a los sistemas de correo electrónico.
La información puede extraerse del modo que se ha descrito anteriormente, a través del DOM o a través de las llamadas MAPI a la representación COM del contenido del correo electrónico, o puede extraerse del lenguaje en el que se codifica una página Web. Las páginas Web están típicamente codificadas en el Lenguaje con Anotaciones de Hipertexto (HTML), un texto legible por los seres humanos basado en un lenguaje que puede investigarse para palabras clave conocidas o indicadores que usan técnicas de coincidencia de textos convencionales. En la realización preferida, la grabación de los datos puede involucrar grabar sólo la información de contraseñas y nombre de usuario, grabando la URL de la página Web que se está viendo o de una cuenta de correo electrónico, grabando cualesquiera datos transmitidos a los campos de la página Web, y grabando el HTML de la página Web, de modo que la página Web puede recuperarse y verse más tarde.
Los módulos de expansión proporcionados por el sistema preferido funcionan junto con los datos de directivas, que pueden grabarse en un fichero, base de datos, o por ejemplo código software. Los datos de directivas permiten a un usuario del sistema preferido instruir el funcionamiento de cada uno de los módulos de expansión controlando por lo tanto su funcionalidad.
La representación de muestra de los datos de directivas, ilustrada en la Figura 7, muestra cómo un usuario puede controlar el funcionamiento del módulo de expansión para grabar información de contraseñas y nombres de usuario junto con otros tipos de datos.
La estructura tipo árbol de los datos de directivas, se ve claramente en la Fig. 7 que muestran sólo una rama mayor de los datos de directivas titulada "Grabación". La rama "Grabación" está separada en dos sub-ramas llamadas Buscador y Correo-E que contienen instrucciones para el funcionamiento de los módulos de expansión del buscador Web y del cliente de correo electrónico respectivamente.
La rama del Buscador contiene tres sub-ramas llamadas "DatosAGrabar", "CuandoComenzarGrabación" y "CuandoPararGrabación". La rama de DatosAGrabar especifica el tipo de datos que se extraen de las transmisiones a o desde las estaciones de trabajo del usuario y un servidor Web. En esta ilustración se han referido cuatro tipos de datos, siendo estos el URL de la página Web que se está viendo, el HTML de la página Web que se está viendo, los datos que se introducen por un usuario dentro de los campos provistos sobre la página Web y enviados al sitio Web, y cualesquiera otras contraseñas y nombres de usuario que se introducen por el usuario. Estas se refieren sobre cuatro sub-ramas diferentes de DatosAGrabar, tituladas "URL", "HTML", "CamposEnviados" y "Contraseñas". Una opción de Si/No sobre cada una de esas ramas especifica si los datos indicados se grabarán o no.
La rama CuandoComenzarGrabación fija varias condiciones que especifican el punto en el que los datos especificados en la rama DatosAGrabar se grabarán. Se ilustran cinco condiciones en este ejemplo cada uno de los cuales fija una rama separada y se titulan respectivamente "CuándoSeAbreBuscador", "SiNúmeroTarjetaCreditoTransmitido", "SiContraseña-Transmitida", "SiPalabrasClaveRecividas" y "SiPalabresClaveEnviadas". Si se usan o no estas condiciones para determinar cuando comenzar la grabación se indica por las marcas Si/No en cada rama.
De forma similar, la rama CuandoPararGrabación lista tres condiciones que pueden usarse para determinar el punto en el que se parara la grabación de los datos especificados en la rama DatosAGrabar. Estas condiciones son "CuandoUsuarioCierraBuscador", "CuandoUsuarioCambiaSitio" y "CuandoUsuarioCambiaPágina". El estado Si/No de cada una de estas condiciones y para cada tipo de datos a grabar puede fijarse fácilmente por un usuario del sistema preferido para controlar el funcionamiento del módulo de expansión.
La rama de correo electrónico de los datos de directiva se divide en la rama DatosAGrabar y la rama de CuandoGrabar. Cada una de estas ramas se subdivide en ramas que tratan de Correo Enviado y Correo Recibido. El tipo de datos que pueden grabarse se fija en la rama DatosAGrabar y para el correo enviado puede ser el mensaje de texto, cualquier anexo al mensaje, y en el caso de mensajes firmados con una firma digital, una copia del certificado digital acompañando la firma. Las condiciones para grabar el correo enviado y el correo recibido se fijan en la rama CuandoGrabar y pueden basarse en la identificación de un número de la tarjeta de crédito, una palabra clave o un certificado digital en el correo que se envía o se recibe.
La estructura tipo árbol descrita es la forma preferida para los datos de directivas ya que permite que los datos se organicen y se denominen fácilmente. También permite asignar a los diferentes usuarios a las diferentes ramas del árbol para recibir diferentes directivas. Aunque, se prefiere la estructura tipo árbol, pueden ser posibles otras disposiciones. Las ramas mostradas en este diagrama sólo pretenden ser ilustrativas.
Identificación de Números de Tarjetas de Crédito
El sistema preferido también busca números de Tarjetas de Crédito u otra información de cuentas en los datos a transmitir al servidor de la página Web o al cliente de correo electrónico buscando una cadena de dígitos numéricos, típicamente entre 14 y 16 de longitud. A continuación determina si la cadena de dígitos pasa una de las comprobaciones usadas universalmente por las compañías de tarjetas de crédito para validar los números de las tarjetas. Si se encuentra un número de tarjeta de crédito en la transmisión, entonces el sistema preferido puede tomar varias acciones dependiendo de los escenarios en el fichero de directivas, tales como referir la transmisión a una tercera parte para su aprobación, renegociar un nivel más alto de cifrado para guardar la seguridad de la transmisión si el número de la tarjeta de crédito pertenece a la compañía, o impedir completamente que tenga lugar la transmisión.
La prueba más común para identificar un número de tarjeta de crédito está definida en la normativa ANSI X4.13, y se conoce comúnmente como LUHN Mod 10.
La fórmula Luhn se aplica a un número de tarjeta de crédito para generar una comprobación de los dígitos, y de este modo se puede usar para validar tarjetas de crédito, en cuyo caso la comprobación de los dígitos forma parte de la fórmula. Para validar un número de tarjeta de crédito usando la fórmula Luhn, el valor de cada segundo dígito después del primero, comenzando desde el lado derecho del número y moviéndose hacia la izquierda, se multiplica por dos; todos los dígitos, tanto los que se han multiplicado por dos como los que no se han multiplicado se suman juntos; cualesquiera de los valores de dígitos que se hacen mayores o iguales a diez como resultado de duplicarse, se suman como si fueran dos valores de dígitos simples, por ejemplo: "10" cuenta como "1+0=1", "18" cuenta como "1+8=9". Si el total de la suma es divisible por 10, entonces la tarjeta de crédito es un número de tarjeta de crédito válida.
La Figura 8 es un diagrama de flujo que ilustra el funcionamiento del módulo de expansión que detecta los números de la tarjeta de crédito, usando la fórmula de Luhn que se ha descrito anteriormente, en los datos que están a punto de transmitirse. Si se identifica un número de una tarjeta de crédito, el módulo de expansión implementa comprobaciones adicionales basadas en las directivas, en base a cuyo resultado, el módulo de expansión puede determinar transmitir los datos que contienen el numero de la tarjeta de crédito o impedir la transmisión.
El módulo comienza el funcionamiento en la etapa S160, que sigue el punto "C" en el proceso ilustrado en la Figura 3 en el caso de la implementación del buscador, o el punto B en el proceso ilustrado en la Figura 5 en el caso de una implementación de un cliente de correo electrónico. El control pasa desde la etapa S160 a la etapa S162 en la que el módulo explora los datos a punto de transmitirse al servidor Web o el servicio de correo electrónico y extrae de los mismos una primera cadena de dígitos que es probablemente un número de tarjeta de crédito.
Esto se consigue explorando los datos contenidos en la transmisión para cadena de dígitos sobre un número particular de longitud de dígitos. Los números de tarjetas de crédito normalmente se constituyen de más de 12 dígitos, y no usualmente más de 16 dígitos de longitud. De este modo cualesquiera cadenas de dígitos en este intervalo pueden identificarse como posibles números de tarjetas de crédito.
Siguiendo la etapa de extracción S162 el control pasa a la etapa de decisión S164 donde se realiza una rutina de comprobación de final de fichero. Si los datos no contienen candidatos a números de tarjetas de crédito y se alcanza el final de la comprobación del fichero antes de que se pueda encontrarse cualquier primer número candidato, entonces en la etapa S164 el control pasa a la etapa S178 donde se permite que proceda la transmisión de los datos sin que se realice ninguna comprobación adicional. El módulo sale a continuación en la etapa S180. El control reanuda el funcionamiento del buscador de Web mostrado en la Figura 3 desde el punto "C" o en el funcionamiento del cliente de correo electrónico mostrado en la Figura 5 desde el punto B.
Si se encuentra un primer potencial número de tarjeta de crédito en los datos en la etapa S162, a continuación se extrae y se almacena en memoria. Aún no se ha alcanzado el final del fichero de modo que el control pasa desde la etapa S162 a la etapa S164 y a continuación a S166 donde se calcula una suma de comprobación para el número candidato almacenado usando la fórmula de Luhn. El control pasa a la etapa de decisión S168, donde se pregunta por la suma de comprobación.
Si la suma de comprobación indica que el número candidato no es un número válido de tarjeta de crédito entonces el control pasa de nuevo a la etapa S162 donde se extrae de los datos el siguiente número de tarjeta de crédito potencial. Si no se encuentra un segundo número de tarjeta de crédito, entonces se alcanza el final del fichero y el control pasa a la etapa S178 donde se permite que continúe la transmisión, y a continuación a la etapa S180 donde sale el modulo.
Por el contrario, si la suma de comprobación indica que el número candidato es un número de tarjeta de crédito válido entonces el control pasa a la etapa de decisión S170 donde se interrogan los escenarios de los datos de directivas para la acción apropiada a tomar. La acción puede determinarse a partir de factores tales como el propio número, la identidad del usuario que transmite el número y la dirección a la cual se envía. Los datos de directivas pueden por ejemplo especificar que las tarjetas de crédito no se transmitan, o que se requiere una fortaleza de cifrado más alta para la transmisión antes de que pueda procederse.
Esta etapa de comprobación de las directivas permite que se controlen las transacciones de tarjetas de crédito a un nivel más alto que el usuario que hace la transacción. De este modo pueden implementarse fácilmente y rápidamente decisiones financieras, y pueden imponerse automáticamente sin necesidad de monitorización. Un organismo puede, por ejemplo, desear restringir la capacidad de realizar transacciones de tarjetas de crédito sobre la cuenta de la organización para gente particular autorizada o puede desear restringir completamente las transacciones sobre una cuenta particular.
En la etapa S170, el número de la tarjeta de crédito y otros detalles de la transacción se comparan con el escenario del fichero de directivas y se determina si tiene lugar o no la transmisión. Si por alguna razón, con referencia a las comprobaciones de las directivas, se determina que no debe transmitirse el número de la tarjeta de crédito, el control pasa a la etapa S172 donde se para la transmisión de los datos, y a continuación a la etapa S174 donde sale el módulo. En este punto el sistema podría notificar al usuario que la petición se ha denegado por medio de un cuadro de mensaje en una ventaja asociada. A continuación el control vuelve al punto A en la Figura 3, en el caso de un buscador Web, o a la etapa S132, "componer correo" en la Figura 5, en el caso de un cliente de correo electrónico.
Si en la etapa S172, se determina que puede transmitirse el número de la tarjeta de crédito, el control pasa a la etapa S176 donde se produce la transmisión de datos, y a continuación a la etapa S180 donde sale el módulo. En este caso el control se reanuda desde el punto C en el funcionamiento del buscador Web ilustrado en la Figura 3, o desde el punto B en el funcionamiento del cliente de correo electrónico ilustrado en la Figura 5.
Los números de tarjetas de crédito no necesitan solamente identificarse en la etapa S162 explorando el contenido de la transmisión. En las implementaciones del buscador Web el número de la tarjeta de crédito puede por ejemplo identificarse directamente refiriéndose a los nombres de los campos de cualquiera de las variables que se van a transmitir o también a partir de la representación de la página Web en memoria. La discusión anterior acerca de la identificación de contraseñas explica esto con más detalle.
El sistema preferido puede también configurarse para buscar en las transmisiones de salida otros detalles financieros pertinentes, tales como números de cuentas. Los números de cuentas de la compañía a partir de los cuales paga, pueden depositarse o almacenarse en un fichero separado. Cualesquiera cadenas de caracteres o dígitos probables pueden extraerse a continuación de los datos de salida del modo descrito y compararse con las entradas en el fichero de cuentas para determinar si es un número de cuenta válido o no. A continuación puede permitirse que proceda la transacción o rechazarse del modo descrito anteriormente. Aunque nos hemos referido a números de tarjetas de crédito, se apreciará que puede usarse cualquier 
\hbox{tipo de número de
tarjeta  para realizar el pago, tales como números de tarjetas de
debito.}
También, aunque se ha explicado la identificación de los números de tarjetas de crédito con referencia a los datos que se transmiten, se apreciará que podrían usarse técnicas similares para identificar y extraer números de tarjetas de crédito a partir de las transmisiones que se están recibiendo.
Soporte de Autentificación y Validación
Las transacciones en-línea típicamente requieren algún tipo de autentificación de que el usuario es quien dice que es, y que está capacitado para pagar los artículos pedidos. Estos requisitos se cumplen usualmente por el comprador suministrando al comerciante con su número de tarjeta de crédito y la dirección del titular de la tarjeta que puede verificarse a continuación por el vendedor con el emisor de la tarjeta. Sin embargo, cada vez más se adjuntan Certificados Digitales a las transmisiones electrónicas por el usuario que, junto con una firma digital, permite al receptor verificar que la transmisión se originó por la persona llamada como remitente. Los certificados digitales de ciertas autoridades emisoras, tales como Identrus, puede actuar también como una garantía de que el titular cumplirá su compromiso de pago por la cantidad de dinero especificada. Estos certificados son útiles con el comercio en-línea.
Las firmas digitales son un medio usado ampliamente para el establecimiento de la identidad del individuo en-línea cuando se transmite información o cuando se dirige una transacción. También proporcionan una garantía al receptor de que cualquier información transmitida o detalles de transacción, que esos detalles y esa información no se han falsificado con un encaminamiento por una tercera parte no autorizada.
Los certificados digitales se emiten a los individuos, organizaciones, o compañías por Autoridades de Certificación independientes tales como Verising Inc. Una organización puede actuar como su propia Autoridad de Certificación emitiendo su propio certificado digital que puede derivarse o no desde un certificado "raíz" emitido por otra Autoridad de Certificación. Un certificado digital típicamente contiene el nombre del titular, un número de serie, una fecha de expiración, una copia de la clave pública del titular del certificado y la firma digital de la autoridad que emite el certificado. También se emite una clave privada para el titular del certificado que no debe revelar a nadie más.
Los certificados son únicos para cada titular y pueden revocarse por el emisor si el titular no es viable en adelante; como alternativa, un titular puede pedir tenerlo revocado si se ha visto comprometida la clave privada.
Las claves pública y privada pueden usarse también en tándem para cifrar o descifrar un mensaje. Nadie puede usar la clave pública del titular del certificado para cifrar un mensaje de modo que sólo puede leerse por el titular del certificado después de descifrar el mensaje con su clave privada.
Los mensajes también pueden firmarse digitalmente usando un software que convierte los contenidos del mensaje en un resumen matemático, llamada huella. La huella se cifra a continuación usando la clave privada del remitente. La huella cifrada puede usarse a continuación como una firma digital para el mensaje que se está transmitiendo. El mensaje original, la firma digital y el certificado digital del transmisor se envían todos al receptor quien, para confirmar que el mensaje que ha recibido está completo e inalterado de su forma original, puede también producir una huella para el mensaje recibido. Si, la huella recibida, que se ha descifrado con la clave pública del titular, coincide con la huella producida por el receptor, entonces el receptor puede confiar en que el mensaje que se ha enviado por la persona a la cual se emitió el certificado, y que el mensaje no se ha alterado en el camino de su forma original. Los certificados digitales son por lo tanto de considerable importancia y en aumento para las compañías que dirigen negocios sobre la Internet.
En casos en los que el comerciante en-línea hace uso de Certificados Digitales para asegurar la identidad de sus clientes, es necesario comprobar con el emisor que el certificado es válido aún antes de que se autorice cualquier transacción. Tales comprobaciones pueden realizarse en-línea usando un servicio de verificación independiente tal como el proporcionado por Valicert, Inc. Usualmente se hace un cargo por tales servicios.
Puede ser que empleados individuales de una organización reciban cada uno correos electrónicos desde un cliente único, firmado cada uno con su certificado digital, en ocasiones separadas. Actualmente, no hay modo para que una información acerca de un certificado recibido por un empleado se comparta con otro empleado a menos que lo compartan los mismos manualmente, y como resultado, los empleados individuales pueden solicitar que el mismo certificado se valide cada vez que lo reciben. Esto es sin embargo poco económico, ya que una vez que se revoca un certificado por su emisor, nunca se reinstala de nuevo, de modo que cualquier gasto de honorarios de validación sobre un certificado ya revocado es innecesario. Adicionalmente, el receptor puede desear realizar un juicio de negocios de si un certificado validado anteriormente debe re-comprobarse o no. Por ejemplo, si se recibe un día un pedido de artículos firmado digitalmente por valor de 1 millón de dólares, y el certificado se valida con éxito, y al siguiente día se recibe otro pedido por 50 dólares, firmado con el mismo certificado, la organización puede considerar que una segunda comprobación de validación es innecesaria, ahorrando por tanto el cargo de la validación.
El sistema preferido proporciona un medio para grabar información acerca de los Certificados Digitales que se han recibido, el estado del certificado en la última comprobación también así como, donde sea aplicable, la información de la transacción, tal como el cliente, cantidad, fecha, artículos y así sucesivamente. Esta información se almacena en una base de datos central a la cual tienen acceso todos los usuarios del sistema. El sistema preferido también proporciona un medio para usar la información almacenada para decidir si es deseable una comprobación de validación o no, y aceptar o rechazar transmisiones dependiendo del estado del certificado digital. De este modo los usuarios del sistema pueden recibir y revisar las transmisiones sin necesidad de establecer su autenticidad ellos mismos.
La Figura 9 ilustra el funcionamiento de un módulo de expansión del sistema preferido implementado para extraer certificados digitales de las transmisiones recibidas por los empleados de la compañía y grabarlos en una base de datos junto con su estado de validación y detalles de cualesquiera transacciones asociadas tales como fecha, cantidad, artículos y así sucesivamente. El módulo comprueba en primer lugar para determinar si el certificado es obviamente inválido, y que el mensaje se haya firmado correctamente por el mismo. El certificado es obviamente inválido, por ejemplo, si ha pasado su fecha de expiración, o si contiene una "huella digital" inválida. Tal huella digital puede ser una suma de comprobación, por ejemplo, para el propio certificado. El mensaje no se ha firmado correctamente si la firma no se puede verificar a partir de la información contenida dentro del certificado. Los detalles de la validación del certificado y el firmado de los mensajes se describen más enteramente en los documentos de la ITU y RFC referidos anteriormente. El módulo realiza a continuación una comprobación para determinar si se ha almacenado ya el certificado en la base de datos o no y grabar sólo aquellos que no lo están. Cuando ya está almacenada una copia del certificado, el módulo comprueba la grabación de la base de datos para determinar si se ha identificado anteriormente como revocada en cuyo caso la transmisión se rechaza inmediatamente. En caso contrario, el módulo determina a continuación, de acuerdo con las directivas que definen las reglas del negocio, si validar o no el certificado. Teniendo en cuenta los resultados de tal validación, a continuación determina si se debe confiar en el certificado, y por lo tanto si se debe rechazar o aceptar la transmisión firmada por el certificado digital. El módulo se inicia en la etapa S190, siguiendo la recepción de los datos que contienen un certificado digital. Los certificados digitales se transmiten típicamente como anexos a los mensajes y pueden identificarse examinando los primeros pocos octetos de bits en la cabecera del anexo. Estos octetos de bits identifican el tipo de fichero adjunto y de este modo indicarán si un anexo es un certificado digital o no.
La etapa de iniciación S190 se produce después del punto A en la Figura 3 si el módulo se implementa en un buscador Web, y después del punto A en la Figura 5 si el módulo se implementa en un cliente de correo electrónico. Siguiendo la inicialización, el módulo procede a la etapa S191 en la cual se comprueba la fecha de expiración del certificado, y la firma digital confirmada con la que se ha firmado el mensaje. Si el certificado ha expirado, o el mensaje está incorrectamente firmado, el módulo procede a la etapa S198 y rechaza la transmisión. En caso contrario el módulo procede a la etapa S192 en la cual se busca en la base de datos una copia recibida anteriormente del certificado digital. El control pasa a continuación a la etapa 194. Si se ha encontrado una copia del certificado en la base de datos entonces el control pasa a la etapa de decisión S196 donde el módulo determina si el certificado se ha marcado anteriormente como revocado. Esto se habrá producido si una comprobación de validez anterior reveló que el certificado se había revocado. Si el certificado no está ya en la base de datos el control pasa desde la etapa S194 a la etapa S202 donde se almacenan en la base de datos el nuevo certificado y la fecha en la que se recibió, junto con detalles adicionales tales como la dirección desde la cual se envió y detalles de cualquier transacción asociada con la transmisión tales como el valor monetario, número de cuenta etc. Si el certificado ya se ha marcado como revocado en la etapa S196 entonces el control pasa directamente a la etapa 198 en la cual se rechaza automáticamente la transmisión que comprende el certificado digital. Esto puede involucrar por ejemplo, transmitir un mensaje generado automáticamente al iniciador de la transmisión cuya certificado se ha encontrado como inválido para explicar el rechazo, y para impedir al receptor del certificado digital que tenga en cuenta cualesquiera etapas adicionales en conexión con la transmisión rechazada. El módulo sale a continuación en la etapa S200.
Sin embargo, si el certificado no se ha marcado anteriormente como revocado en la etapa S196, entonces el control pasa a la etapa S204 en la cual se consideran la historia de las transmisiones firmadas por el certificado, por otros certificados de la misma compañía, o usados para dirigir transacciones sobre la misma cuenta se consideran con los datos de directivas para determinar si se requiere una comprobación de validez del certificado en-línea. El control también pasa a la etapa S204 después de que se ha añadido un nuevo certificado digital a la base de datos en la etapa S202.
Los datos de directivas contienen instrucciones que cuando se consideran junto con la historia de las transmisiones firmadas recibidas anteriormente y las comprobaciones de revocación realizadas anteriormente indican si el certificado usado para firmar una transmisión debe verificarse o no en esta ocasión. En la Figura 10 se ilustra un ejemplo de datos de directivas a la cual haremos referencia.
Los datos de directivas están almacenados sobre la rama de AceptaciónClasificaciónConfianza de la rama CertificadosDigitales de la representación de los datos de directivas. La rama de AceptaciónClasificaciónConfianza se subdivide en dos ramas separadas que tratan individualmente con certificados digitales "monetarios", donde se ha usado un certificado para firmar una transmisión que involucra una transacción con el receptor por una cantidad de dinero, y los certificados digitales de "identidad" que no involucran una transacción monetaria con el receptor de la transmisión. Ciertos certificados se emiten sólo para uso en unión con las transacciones monetarias. Por ejemplo, el "certificado de garantía" emitido por algunas organizaciones bancarias en-línea, tales como Identrus, como una garantía para el receptor de transmisión firmada. Tal certificado de garantía testifica que el remitente de la transmisión es un cliente de un banco miembro de Identrus, y que si el no hace el pago, el banco aceptará la responsabilidad.
Las organizaciones que emiten diferentes tipos o clases de certificados digitales marcan cada certificado de acuerdo con su clase. Identificar un certificado como de una clase en particular es entonces una materia de conocimiento de cómo clasifican las diferentes organizaciones sus certificados y buscar el indicador apropiado en el certificado recibido.
Los usuarios de certificados digitales pueden proporcionar muchas clases de certificados adaptados para diferentes propósitos. Estos pueden tratarse separadamente con los datos de directivas por las correspondientes sub-ramas del árbol de datos de directivas.
En el ejemplo de directivas, la primera rama titulada "CertificadosIdentidad" trata con las transmisiones que no involucran una transacción monetaria. La rama comprende cuatro sub-ramas separadas. La primera de estas, titulada "AceptarSiempreDe" contiene una referencia a una tabla, la tabla "a" que lista los nombres de los individuos y organizaciones que se consideran fiables. Los nombres listados en esta tabla serán todos conocidos y de confianza implícita por la compañía, para los cuales, no se considera necesario determinar si se ha revocado o no un certificado digital por su emisor.
La segunda rama titulada "ComprobarSiempreDe" contiene una referencia a una tabla separada, la tabla b, en la que están almacenados los nombres de individuos y organizaciones para los cuales deben comprobarse siempre los certificados digitales. Claramente, los contenidos de la tabla a y la tabla b dependerán de la experiencia del usuario del sistema preferido y se dejará que el usuario los introduzca.
La tercera rama titulada "ComprobarSiDíasDesdeCertificadoRecibido-DeCompañía" especifica un periodo de tiempo que sigue a la recepción de un certificado digital válido desde una compañía, dentro del cual no se consideran necesarias las comprobaciones de cualquier certificado adicional recibido desde esa compañía. En este caso, el periodo de tiempo se fija a 10 días.
La cuarta rama titulada "ComprobarSiDíasDesdeEsteUltimoCertificado-Recibido" especifica un periodo de tiempo similar en el caso de un certificado digital individual. En el ejemplo mostrado los datos de directivas especifican esas comprobaciones de validez sobre cualquier certificado digital determinado sólo necesitan hacerse cada 30 días. De nuevo, el número de días especificados sobre cualquiera de estas ramas se deja que los decida el usuario del sistema preferido. La cantidad de tiempo que ha pasado desde que se ha recibido un certificado digital válido puede determinarse refiriéndonos a los certificados digitales y los datos asociados almacenados en la base de datos. Comprobar los certificados digitales periódicamente, mejor que cada vez que se reciben permite ahorrar dinero gastado para hacer comprobaciones. La rama de CertificadosMonetarios también contiene una rama AceptarSiempreDe y una rama ComprobarSiempreDe que se refieren a las tablas x e y respectivamente. La tabla x lista todas las organizaciones e individuos para los cuales no se requiere una comprobación de estado de un certificado digital; la tabla y lista todos los que siempre se requieren una comprobación.
La rama CertificadosMonetarios también contiene una rama de ComprobarSiCantidadExcede que especifica un umbral de la cantidad de la transacción por encima de la cual deben comprobarse todos los certificados digitales y finalmente una rama de SiComprobadoRecientemente que fija dos condiciones para realizar comprobaciones sobre un certificado digital que se ha recibido y validado recientemente. La rama SiComprobadoRecientemente permite al usuario especificar qué certificados recibidos para transacciones para una pequeña cantidad, en este caso 5.000 dólares, recibidos dentro de un tiempo especificado, en este caso 30 días, de una comprobación de revocación anterior, no necesita validación.
La Figura 11 ilustra el proceso del módulo de expansión que interactúa con los datos de directivas mostrados en la Figura 9. Este proceso es un subproceso del mostrado en la Figura 8 y se produce en la etapa S204 resultando en la etapa de decisión S206 en el cual el módulo de expansión determina si realizar o no una comprobación en-línea del estado del Certificado Digital que se ha recibido. El sub-proceso comienza en la etapa S220 desde la cual el control pasa a la etapa de decisión S222 en la cual se determina si la transmisión es monetaria a partir de la clase de Certificado Digital usado para firmar el mensaje. Si la transmisión es monetaria entonces el control fluye a la etapa de decisión S232, que es la primera en una cadena de etapas de decisión correspondientes a las ramas en la rama CertificadosMonetarios de la rama AceptaciónClasificaciónConfianza de los datos de directivas.
Si en la etapa S222, se determina que la transmisión no es monetaria, el control pasa a la etapa de decisión S224, que es la primera etapa de decisión en una cadena de etapas de decisión correspondientes a las ramas CertificadosIdentidad de la rama AceptaciónClasificaciónConfianza de los datos de directivas. En cada una de las etapas de decisión en la cadena se hace una simple comprobación para ver si se satisfacen las condiciones especificadas sobre cada una de las sub-ramas de la rama CertificadosIdentidad de los datos de directivas. Dependiendo de los resultados de esa comprobación el control fluye o a la etapa S242 en la cual se establece la confianza en el Certificado Digital y no se estima necesario ninguna comprobación en-línea del estado del Certificado Digital, o la etapa S244 en el cual no se establece la confianza y se estima necesario una comprobación en-línea, o a la siguiente etapa de decisión en la cadena.
De este modo, en la etapa S224, en la cual se determina si el remitente del Certificado Digital está listado en la tabla a, que es la tabla "AceptarSiempreDe", si el remitente del Certificado Digital está listado en la Tabla A entonces el control fluye desde la etapa de decisión S224 a la etapa S242 donde se establece la confianza en el Certificado y el subproceso termina volviendo a la etapa S208 en la figura 8. Si el remitente no está listado en la tabla a entonces el control fluye desde la etapa S224 a la siguiente etapa de decisión en la etapa de la cadena S226 en la que se determina si el remitente del Certificado Digital está listado en la tabla b, que es la tabla "ComprobarSiempreDe". De forma similar, si el remitente está listado en esta tabla el control fluye a la etapa S244 en la que se estima necesaria una comprobación en-línea del estado del Certificado Digital. El control vuelve desde la etapa S244 en el subproceso a la etapa S210 en la Figura 8.
Si el remitente del Certificado Digital no está listado en la tabla b entonces el control fluye desde la etapa de decisión S226 a la siguiente etapa de decisión en la cadena que representa la siguiente condición listada como una sub-rama listada en los datos de directivas. De este modo, en la etapa de decisión S228 se realiza una comprobación de si este Certificado Digital se ha validado en los últimos 30 días. Esto involucrará buscar el Certificado Digital en la base de datos de los Certificados Digitales almacenados y extraer de información almacenada la fecha en la cual se comprobó el Certificado Digital por última vez. Si se ha comprobado el estado del Certificado en los últimos 30 días, el control fluye a la etapa S242 donde se establece la confianza. Si la información en la base de datos de los Certificados Digitales almacenados indica que el Certificado Digital no se ha comprobado en los últimos 30 días entonces el control fluye desde la etapa S228 a la etapa S230 en la que se realiza una comprobación para ver si se ha recibido otro Certificado Digital de la misma compañía y si se ha comprobado ese Certificado Digital dentro de los últimos 10 días. Esta determinación involucra de nuevo comprobar la base de datos de los Certificados Digitales almacenados y la información relativa a esos Certificados Digitales. Si se ha comprobado el otro Certificado Digital en los últimos 10 días entonces el control fluye a la etapa S242 donde se establece la confianza en el Certificado Digital recibido. Si no, entonces el control fluye a la etapa S244.
En el caso de una transmisión monetaria, las condiciones fijadas sobre los datos de directivas se establecen a través de las etapas de decisión S232 a la etapa de decisión S240. Si en la etapa de decisión S232 el remitente del Certificado Digital se encuentra listado en la tabla x, que fija los nombres de las compañías y organizaciones para las cuales no se estima necesaria la comprobación del estado del Certificado Digital, entonces se establece la confianza y el control pasa a la etapa S242. De lo contrario el control pasa a la siguiente etapa de decisión en la cadena que es la etapa de decisión S234. En la etapa de decisión S234 si el remitente del Certificado Digital se encuentra listado en la tabla b, esto es la Tabla "ComprobarSiempreDe", entonces no se establece la confianza y el control pasa a S244. De lo contrario, el control pasa a la etapa de decisión S236, donde se determina si la cantidad para la cual se está realizando la transacción excede de 10.000 dólares. Esta determinación se hace con referencia a los datos de transacción firmados que contendrán la cantidad monetaria o de una forma predeterminada por el emisor del certificado, o contenido dentro del correo electrónico o correos electrónicos asociados que forman la transacción o transmisiones. Si se encuentra que la transacción es por una cantidad en exceso de 10.000 \textdollar, o si la cantidad de la transacción no puede determinarse con una referencia a los datos transmitidos, entonces no se establece la confianza y el control pasa a la etapa S244. De lo contrario la confianza a la etapa de decisión S238 en la que se determina si se ha comprobado el Certificado Digital dentro de los últimos 30 días. De nuevo, esta determinación se realiza con referencia a la base de datos de los Certificados Digitales almacenados y los datos relativos a los Certificados Digitales. Si el certificado no se ha comprobado dentro de los últimos 30 días entonces no se establece la confianza y el control pasa a la etapa S244. Si se ha comprobado, entonces el control pasa a la etapa de decisión S240 donde, si la cantidad determinada anteriormente de la transacción se estima que es por encima de 5.000 \textdollar entonces no se establece la confianza y el control pasa a la etapa S244. Si la cantidad de la transacción está por debajo de 5.000 \textdollar entonces se clasifica como un riesgo aceptable para confiar en el Certificado Digital, se establece la confianza y el control pasa a la etapa S242.
Estas dos últimas condiciones permiten al sistema determinar si comprobar el estado del certificado en base a la reciente historia de operaciones. Si por ejemplo, se está a punto de hacer una transacción por una parte por una suma modesta, es decir por debajo de 5.000 \textdollar, y la búsqueda de la transacción grabada y los detalles del certificado revelan que bastante recientemente, la misma parte hizo una transacción y en ese momento su certificado digital se confirmó como válido, entonces es discutible que la comprobación de nuevo de la validez del certificado de la parte tan pronto, después de la primera es innecesario, y es 
\hbox{preferible confiar en la  parte que
pagar las tasas de validación por segunda vez.}
Se apreciará que las instrucciones en el fichero de directivas pueden fijarse para reflejar el nivel de confianza que la compañía tiene en sus clientes y suministradores, en base a la experiencia de los individuos dentro de la compañía, las cantidades de las transacciones que se estiman permisibles sin un riesgo significativo y así sucesivamente. El fichero de directivas también puede establecerse para implementar más directivas generales que se usarán junto con una grabación de los detalles de la transacción para el titular del certificado digital. Por ejemplo, cualquier transacción que se ofrezca por el titular puede compararse con la grabación de las que han realizado anteriormente para ver si la cantidad y los artículos o servicios solicitados se mantienen con su historia comercial. Si no lo están, entonces puede ser deseable comprobar la validez del certificado para confirmar que es válido aún y que garantiza la identidad del remitente. Si se ha revocado, entonces una tercera parte puede haber adquirido la clave privada del titular original y estar intentando realizar transacciones fraudulentas.
Una vez comprobados los datos de directivas en la etapa S204, se establecerá la confianza en el certificado digital o no se establecerá. En la etapa de decisión S206, si se ha establecido la confianza entonces el control pasa a la etapa S208 en la que se acepta la transmisión que contiene la transacción. El control pasa a continuación a la etapa S200 donde el módulo sale y el control pasa de vuelta al punto A en la Figura 3 en el caso de un buscador Web, o al punto A en la Figura 5 en el caso de un cliente de correo electrónico.
Si en la etapa S206 no se establece la confianza en el certificado digital, entonces el control pasa a la etapa S210, donde se realiza una comprobación de validación en-línea sobre el certificado digital. Esto puede involucrar una comprobación para ver si el Certificado Digital se ha revocado o si, en el caso de una transacción de comercio electrónico, el emisor del Certificado Digital confirma una garantía para la cantidad prometida en la transacción. El control pasa a continuación a la etapa S212 en la cual se actualiza el estado de validez almacenado en la base de datos para ese certificado. El control pasa a continuación a la etapa S214 en la que, si se encontró inválido el certificado, el control pasa a la etapa S198 donde se rechaza la transmisión, o a la etapa S208 donde se acepta la transmisión. El rechazo de la transmisión puede significar que se borre de la casilla de los receptores de correo electrónico antes de abrirse, o que se marque la transmisión con la palabra "rechazado" o algún otro indicador. Siguiendo cualquiera de las etapas S198 o S208, el control pasa a la etapa S200 donde sale el módulo. Cada vez que se permite que se produzca una transacción, se actualiza la base de datos de tal modo que incluye la información acerca de la transacción, tal como la fecha y cantidad, para que la información pueda usarse en determinar la necesidad de futuras comprobaciones de validación.
Grabación de información
El sistema preferido también proporciona un modo automático en el que se graba la información de transacción para transacciones realizadas en-línea. En este contexto, la palabra "transacción" y "transacción de comercio" electrónico se pretende que signifiquen un acuerdo prometiendo dinero o valor de dinero realizado entre dos partes sobre la Internet, o incluso sobre la misma red de una compañía. Normalmente, el propio usuario es responsable de mantener la información de la transacción realizando copias impresas de los registros electrónicos relevantes o almacenando activamente copias de cualesquiera grabaciones electrónicas en ficheros sobre su ordenador. La confianza en los métodos manuales para asegurar estas grabaciones se mantienen claramente no fiables y de trabajo intenso.
El sistema preferido por el contrario explora el contenido de información de todas las comunicaciones procesadas por el sistema para las indicaciones de que ha comenzado una transacción o está teniendo lugar. Tales indicaciones son numerosas. La más sencilla es si el enlace es seguro o no ya que la mayor parte de las páginas Web negocian un enlace seguro antes de realizar una transacción y cierran ese enlace más tarde. Determinar si un enlace es seguro se consigue examinando el URL de la página Web de destino. Un enlace seguro se indica por una "s" después del prefijo "http". De este modo, un modo de funcionamiento del sistema preferido es grabar todos los datos transmitidos a la página Web mientras que el enlace es seguro. El sistema preferido también mantiene una grabación de las páginas Web que negocian los enlaces seguros pero que no son sitios de comercio electrónico, es decir los que están conectados a otro que hacen compras, y no graban ningún dato transmitido a estas páginas. Tal página Web puede ser la página Web de Hotmail de Microsoft que proporciona un servicio de correo electrónico.
Otra indicación puede ser simplemente el URL del sitio. En este caso el sistema preferido puede configurarse para grabar todos los datos transmitidos a la página Web que se ha identificado como la de una compañía de comercio en-línea. Otras indicaciones podrían ser un número de tarjeta de crédito identificado, un recibo electrónico, un correo electrónico confirmando la venta, el uso de un certificado digital, en particular un certificando de garantía digital, o un código de compra.
Una vez que se ha identificado que se ha produciendo, el sistema preferido puede grabar los detalles de la transacción tanto almacenando totalmente cada comunicación entre un usuario y el comerciante identificado, como explorando las transmisiones y extrayendo los detalles particulares, tales como fecha, importe, tipo de artículos, cantidad y así sucesivamente.
La grabación de los datos de transacción pueden pararse cuando se identifica el final de la transacción o después de que han tenido lugar un número predefinido de transmisiones entre el comprador y el comerciante. De forma similar, una vez que se ha identificado una transacción, el sistema preferido puede grabar en la base de datos un número predefinido de transmisiones en memoria caché que tuvieron lugar inmediatamente después de la primera transmisión reconocida de la transacción.
Esto será útil, por ejemplo, cuando la primera indicación de que se está produciendo una transmisión es la detección de un número de tarjeta de crédito o un recibo electrónico, ya que éstos probablemente se reciben muy al final de una transacción. Las transmisiones anteriores pueden, por ejemplo, consistir de páginas Web que contienen información relativa a los artículos o servicios que se están comprando, o un intercambio de correos electrónicos donde se acuerda la especificación o los términos de suministro. Obsérvese que es perfectamente posible para las transmisiones anteriores que sean del mismo tipo de aquellas en las que se detectaron las transacciones, de un tipo diferente, o ser una mezcla de tipos. Por ejemplo un usuario podría visitar un sitio Web www.abc.com, obteniendo detalles de artículos, y a continuación pedirlos en un correo electrónico enviado a pedidos@abc.com.
El sistema preferido graba los detalles de la transacción en una base de datos común centralizada 42. Adicionalmente, la base de datos puede ser un fichero local o un servicio sobre la red. La información almacenada en la base de datos puede cifrarse usando técnicas de cifrado conocidas de modo que sólo una persona con la autorización necesaria puede accederla.
La Figura 12 es una ilustración del funcionamiento de una implementación de ejemplo de un módulo para identificar cuándo se está dirigiendo una transacción electrónica en-línea. La Figura 14 ilustra el proceso por el cual el sistema preferido graba una transacción identificada en la base de datos, y la Figura 15 ilustra cómo el sistema preferido permite aprobar o rechazar una transacción identificada sobre la base de unas directivas de aprobación predeterminadas.
Con referencia a la Figura 12, el funcionamiento de un módulo para identificar cuándo se está produciendo una transacción en-línea se describirá a continuación.
El módulo comienza el funcionamiento en la etapa S250 en respuesta a una recepción de datos o en respuesta a una iniciación por el usuario de una transmisión de datos al sitio remoto. En el caso de una implementación de un buscador Web esto será después del punto A o después del punto C respectivamente como se muestra en la Figura 3; en el caso de una implementación de un cliente de correo electrónico será después del punto A o B respectivamente como se muestra en la Figura 5.
El control pasa a continuación a la etapa de decisión S252 en la cual se determina si, en el caso de un buscador Web, se ha negociado un enlace seguro entre el sitio que transmite los datos y el sitio que recibe los datos. Esto puede conseguirse preguntando por la dirección del URL a la que se ha conectado, como se ha mencionado anteriormente, o interrogando al buscador Web para ver si se está empleando cifrado. En el caso de un mensaje de correo electrónico esta etapa se omite y el control pasa directamente a la etapa S260. Como las transacciones del buscador Web en-línea usualmente involucran la transmisión de información personal, tal como el nombre y la dirección, el número de tarjeta de crédito u otra información que identifica la cuenta, usualmente se negocian enlaces seguros como cuestión de rutina. De este modo la presencia de un enlace seguro solo, es una buena indicación de que está teniendo lugar una transacción. Sin embargo, las conexiones seguras pueden negociarse por razones distintas que la transmisión de detalles de transacciones. De este modo, si en la etapa S252 se determina que la conexión es segura, el control pasa a la etapa S254, en la cual se comprueba la dirección del sitio remoto al cual se ha realizado la conexión frente a una lista de sitios conocidos que no proporcionan facilidades para dirigir transacciones en-línea pero que establecen conexiones seguras. Buscadores basados en sitios de correo electrónico de los cuales es un ejemplo el sitio de Hotmail de Microsoft. El control pasa a continuación a la etapa de decisión S256 donde se realiza una determinación basada en la comprobación anterior. Si la dirección del sitio se identifica como de un sitio no de comercio electrónico, éste es uno que no facilita la realización de transacciones, entonces se determina que se puede estar produciendo o no una transacción y el control pasa a la etapa de decisión S260 para realizar comprobaciones adicionales sobre el contenido de la transacción. Si en la etapa S256 la dirección del sitio no se identifica como un sitio conocido de no comercio electrónico, entonces se asume que se está produciendo una transacción en-línea, y el módulo sale en la etapa S258.
Si se encuentra que no se ha establecido una conexión segura en la etapa S252, o si la conexión segura se ha establecido pero a un sitio conocido de no comercio electrónico, como se determinó en la etapa S256, o la transmisión es un correo electrónico, entonces el control pasa a la etapa de decisión S260. En la etapa de decisión S260, se hace la primera de varias comprobaciones sobre el contenido de la transmisión para determinar si es parte o no de una transacción. En la etapa S260, se explora la transmisión para ver si contiene un número de tarjeta de crédito. El método para hacerlo se ha descrito con referencia a la Figura 8. Si se encuentra un número de una tarjeta de crédito en la transmisión entonces se asume que debe de estar ocurriendo una transacción y el control pasa a la etapa S258 en la cual el módulo sale. Si no se encuentra ningún número de tarjeta de crédito entonces el control pasa en cambio a la etapa de decisión S262 donde se explora la transmisión para ver si contiene un código de cuenta. Los códigos de cuenta pueden (por ejemplo) almacenarse en fichero separado que se accede por el módulo cuando se realiza esta etapa o como alternativa puede identificarse un número de cuenta a partir de los datos descriptivos en la transmisión tales como un nombre de campo como "Número de Cuenta" o caracteres similares apareciendo en el texto de un mensaje.
Si en la etapa de decisión S262 se encuentra un código de cuenta, entonces se asume que la transmisión constituye parte de una transacción y el control pasa a la etapa S258 donde el módulo sale. Si no se encuentra ningún código de cuenta entonces el control pasa a la etapa S264 donde, en el caso de un buscador Web, se compara el URL con una lista de URL conocidos de comercio electrónico almacenadas en un fichero o base de datos, En la etapa de decisión S266, se realiza una determinación sobre esa comparación. Si se encuentra que el URL es una página de comercio electrónico conocida, o dentro de un conjunto conocido de páginas de comercio electrónico, entonces se determina que está teniendo lugar una transacción de comercio electrónico y el control pasa a la etapa S258 donde el módulo sale. De forma similar, en el caso de un correo electrónico, la dirección de destino puede compararse frente a una lista de direcciones de correo electrónico de comercio electrónico conocidas, por ejemplo "pedidos@abc.com" y si se encuentra una coincidencia entonces se determina que está teniendo lugar una transacción de comercio electrónico y el control pasa a la etapa S258 donde el módulo sale.
Las comprobaciones que se han descrito sólo son representativas de las posibles comprobaciones que pueden realizarse para determinar si una transmisión es o no probablemente parte de una transacción de comercio electrónico y no se pretende ser exhaustivo. Además, el orden en el cual se han ilustrado las comprobaciones no tiene un significado especial. El orden simplemente depende de la estructura de los datos de directivas como se verá de la referencia a la Figura 13.
En la etapa S268, se ilustra una comprobación general que representa cualquier comprobación adicional para una indicación de una transacción, además de las que se han descrito anteriormente, que una compañía decida que es deseable emplear, además de las que se han descrito anteriormente, tal como por ejemplo buscar códigos de compra o códigos incorporados situados en los datos. Es preferible que el buscador Web o cliente de correo electrónico que se está usando en el sistema preferido permita al usuario marcar las transmisiones con un código incorporado para indicar que la transmisión es parte de una transacción y debe grabarse. También, el código incorporado podría situarse en los datos por el sitio Web o el cliente de correo electrónico que transmite algunos de los datos de transacción a la estación de trabajo del usuario.
El control pasa a esta etapa después de la etapa S266, si el sitio no se reconoce como un sitio de comercio electrónico conocido y si tal indicador de transacción se encuentra en la etapa S268, entonces se estima que se está produciendo una transacción y el control pasa a la etapa S258 donde el módulo sale. Si en la etapa S268, no se encuentra tal indicador entonces se estima que no se está produciendo una transacción y el módulo sale en la etapa S258. Siguiendo la salida, pueden transmitirse los datos, siguiendo la puntos C y B respectivamente en las Figuras 3 y 5, o procesarse siguiendo desde su recepción en el punto A en las Figuras 3 y 5.
En el ejemplo descrito, el objetivo es arrancar la grabación de las transmisiones y posibles detalles de las transacciones si hay sólo una sospecha de que se está produciendo una transacción. Se asume que grabar datos que no son parte de una transacción es preferible a la no grabación de una transacción en absoluto. La Figura 13 es una ilustración de los datos de directivas usadas para identificar que se está produciendo una transacción de comercio electrónico y para controlar el modo en el que se graban los datos de la transacción. Los datos de directivas se representan por una rama de Transacciones del árbol de datos de directivas que se subdivide en dos sub-ramas separadas llamadas "Identificación" y "Terminación". La rama de Identificación se divide a su vez en cinco sub-ramas que corresponden a las determinaciones realizadas en el proceso ilustrado en la Figura 12. La primera de estas sub-ramas se titula "SiConexiónVaASegura" permite al usuario especificar si la grabación debe comenzar cuando el módulo de expansión detecta que la conexión al servidor Web se ha hecho segura. Las condiciones especificadas sobre esta sub-rama corresponden a la etapa de decisión S252 mostrada en la Figura 12. Se apreciará con referencia a las Figuras 12 y 13 que el flujo de control mostrado en la Figura 12 corresponde a la distribución de las condiciones especificadas en las ramas del árbol de los datos de directivas mostrado en la Figura 13. La rama SitiosExcluídos de la rama SiConexiónVaASegura contiene una referencia a la tabla q en la cual se listan los sitios Web conocidos para negociar sitios seguros pero que son conocidos como sitios Web que no son de comercio electrónico. La tabla q se refiere en la etapa S256 del proceso mostrado en la Figura 12.
La siguiente sub-rama de la rama de identificación se titula "SiNúmeroTarjetaCréditoPresente" y permite al usuario especificar si la detección de un número de tarjeta de crédito debe o no debe usarse para iniciar una grabación de los datos que se están transmitiendo o recibiendo. Esta sub-rama corresponde a la etapa de decisión S260. La sub-rama PáginasAnteriores de la rama SiNúmeroTarjetaCréditoPresente lista el número de páginas Web, anteriores a la página Web en la que se detectó el número de tarjeta de crédito, que también deben grabarse. Como los números de tarjetas de crédito normalmente se envían al final de una transacción, la provisión de esta sub-rama posibilita que las páginas Web anteriores que probablemente contienen los detalles y petición de la transacción se recuperen y se almacenen. Estas páginas Web se pasan continuamente por una memoria caché por el sistema preferido de modo que si se identifica una transacción pueden recuperarse desde la memoria caché y almacenarse en la base de datos. Esto se explicará con más detalle con referencia a la Figura 14.
La siguiente sub-rama de la rama Identificación del árbol se titula "SiCódigoCuentaPresente" y permite a un usuario especificar si la detección de un código de cuenta en los datos que se están transmitiendo o recibiendo se tomará o no como un indicador para iniciar la grabación de los datos. Los códigos de cuenta se identifican en la etapa S262 mostrada en la Figura 12 con referencia a la tabla r. La referencia a esta tabla está contenida en la sub-rama CódigosCuenta de la rama SiCódigoCuentaPresente. Obsérvese que esta tabla también muestra el número de páginas anteriores a grabar, de forma similar a la descrita anteriormente para la identificación de una tarjeta de crédito, sin embargo en este caso el número de páginas anteriores a grabar se almacena en la tabla r permitiendo un número de páginas diferente a especificar para cada código de cuenta detectado.
La rama SiSitioComercioEConocido permite al usuario especificar una lista de URL correspondientes a sitios, partes de sitios, o incluso páginas únicas, en las que se sabe que tienen lugar transacciones de comercio electrónico. El URL de la página actual se compara frente a las entradas de esta lista para determinar si está teniendo lugar una transacción. La sub-rama SitiosConocidos contiene una referencia a la tabla s en la cual se almacenan los URL de los sitios de comercio electrónico conocidos. La determinación de si el URL del sitio Web es un sitio de comercio electrónico conocido se hace en la etapa de decisión S266 que sigue a la etapa S264 de la Figura 12. Por último, la rama SiOtroIndicadorPresente proporciona un modo para el usuario de especificar si debe usarse o no la determinación de otros indicadores como punto de arranque para la grabación de datos. Las dos sub-ramas de esta rama tituladas PalabrasClave y PáginasAnteriores especifican posibles indicadores que pueden detectarse en este caso las palabras clave listadas en la tabla t, y también el número de páginas anteriores que se requiere almacenar si se detectan las palabras clave.
La rama Terminación de la rama Transacciones se divide en cuatro sub-ramas que especifican las condiciones que deben usarse para terminar la grabación de los dados que se están transmitiendo o recibiendo. Cada una de las sub-ramas fija una condición por la cual puede definirse el final de la transacción. La primera rama titulada "SiConexiónVaAInsegura" permite al usuario especificar que la renuncia de una conexión segura por el buscador de la Web indica el final de la transacción de modo que puede pararse la grabación. Las otras sub-ramas especifican que cuando el sitio Web cambia puede pararse la grabación, si se recibe un recibo digital puede pararse la grabación y después de recibir 20 páginas Web siguientes a la identificación que se está produciendo una transacción puede pararse la
grabación.
Debe hacerse hincapié en que los datos de directivas mostrados en este diagrama, en particular, pero también otros diagramas son únicos para cada usuario. Un usuario no sólo puede especificar si unas condiciones particulares deben actuar fijando la variable Si o No consecuentemente, o cambiando el número de páginas que se deben grabar por ejemplo, sino también la estructura y disposición de las ramas y las condiciones especificadas sobre esas ramas pueden ser diferentes de usuario a usuario. Se apreciará que aunque las directivas de ejemplo describen la grabación de transacciones en un entorno de un buscador Web, unas directivas similares controlarían el entorno del correo electrónico, omitiendo la opción de conexión segura, pero permitiendo a las directivas a definir para grabar correos electrónicos sobre la detección de los números de tarjetas de crédito, códigos de cuentas u otra información identificable dentro de los mismos, o cuando se envían los correos electrónicos a direcciones conocidas de comercio electrónico.
El beneficio pleno del método para identificar una transacción se realiza cuando el método se utiliza junto con medios para grabar las transmisiones entre un usuario del sistema preferido y un sitio remoto. Esto permite una grabación de todas las transacciones realizadas por un usuario a guardar y mantener automáticamente. Las grabaciones pueden mantenerse hasta la fecha sin necesidad de realizar copias de papel de cada transmisión transmitida o recibida. De este modo, el mantenimiento de grabación de una compañía se hace considerablemente más fácil y más preciso.
La Figura 14 ilustra el funcionamiento de un módulo para grabar las transmisiones que comprenden una transacción. El módulo se inicia en la etapa 270.
Si el módulo se implementa como parte de un buscador Web, la etapa S270 se inicia en el punto A en la Figura 3 después de la recepción de los datos o después del punto C en la Figura 3 directamente antes de la transmisión de datos al sitio remoto. Si el módulo se implementa como parte de un cliente de correo electrónico, la etapa S270 se produce después del punto A en la Figura 5 después de que se haya recibido un correo electrónico o después del punto B justo antes de que un correo electrónico compuesto por el usuario se envíe a un receptor.
A continuación de la etapa S270, el control pasa a la etapa S272, en la cual se realiza la comprobación para identificar una transacción, descrita anteriormente con referencia a la Figura 9, y se realiza una determinación de si se está produciendo una transacción de comercio electrónico o no. El control pasa a continuación a la etapa S274 donde, si se determina que no se está produciendo una transacción el control pasa directamente a la etapa S276 donde el módulo sale.
Si se determina que se va a producir una transacción entonces el control pasa a la etapa S278 en la cual se consultan las directivas frente a uno o más medios de detección, la identificación del remitente, la cantidad de la transacción, u otros parámetros para determinar qué transmisiones anteriores, si las hubo, deben almacenarse con la transmisión identificada, y con cuánto detalle debe grabarse la transmisión. Las directivas podrían, por ejemplo, requerir que una transacción que involucra una gran suma de dinero se grabe con más detalle que una transacción por una suma pequeña. Un ejemplo de este funcionamiento podría ser grabar cada página Web accedida durante la realización de una grabación sobre un sitio Web del comerciante en línea para transacciones que involucran grande sumas de dinero, pero sólo grabar la transmisión que contiene un recibo electrónico para las transacciones para cantidades más pequeñas.
Así como se determina la cantidad de datos a almacenar, el fichero de directivas también determina la naturaleza de los datos a grabar. La transmisión entera o la página Web pueden grabarse como una serie de tomas instantáneas de la transacción, del mismo modo que las páginas Web se almacenan en memoria caché por ejemplo, o como alternativa, pueden extraerse de la transmisión o de la página Web elementos individuales de datos, tales como la fecha, la identidad del comerciante, la cantidad y así sucesivamente, y almacenarse o por si mismos o juntos con las datos de la toma instantánea.
De este modo, puede usarse la memoria para almacenamiento de forma más eficaz para asegurar que las transacciones más importantes tengan suficiente espacio para grabarse. La cantidad de datos de la transacción a grabar pueden depender también de la identidad del comerciante, la localización geográfica, la historia de comercio con la compañía del usuario, y los artículos y servicios en oferta.
En la Figura 13, los datos de directivas de ejemplo muestran un escenario simple en el que la cantidad de datos a grabar se especifica en términos del número de páginas Web que se recuperan de las páginas en la memoria caché. Los números difieren dependiendo de si se identifica un número de una tarjeta de crédito, un código de una cuenta o una palabra clave. Además, la tabla r muestra que con el reconocimiento de diferentes códigos de cuentas el número de páginas Web previas a almacenar podría ser diferente, reflejando la importancia relativa de la cuenta.
Extendiendo este simple caso a uno más sofisticado se puede conseguir proporcionar un nivel más alto de detalles en los datos de directivas. Ramas adicionales al árbol de los datos de directivas podrían especificar la compañía o nombre individuales, o palabras clave específicas relativas a artículos y/o servicios; también la cantidad de datos a grabar dependiendo de estas palabras clave y nombres.
También, las tablas podrían expandirse para referirse a la cantidad de tipos diferentes de datos que deben almacenarse. Datos tales como el nombre de la compañía, lo que está vendiendo, la cantidad y así sucesivamente podrían extraerse del texto del correo electrónico, a partir del texto de HTML que define la página Web, o desde la representación DOM de la página Web y almacenarse en la base de datos.
Todas las páginas Web o la información almacenada en la memoria caché puede recuperarse, o como alternativa el sistema puede recuperar sólo las páginas que tienen detalles en común con la página inicialmente identificada como parte de una transacción.
Como alternativa, puede presentarse al usuario una lista de todos los mensajes almacenados para que el usuario seleccione manualmente las transmisiones que están relacionadas con la transacción identificada.
Siguiendo la determinación de cuantos datos se graban, el control pasa a la etapa de decisión S280. En la etapa S280 si se deben almacenar las transmisiones anteriores, el control pasa a la etapa S282 donde se recuperan las transmisiones almacenadas en la memoria caché local. En el caso de un buscador Web, esto puede ser un número determinado de páginas anteriores, como se ha descrito anteriormente. Cuando se detectó la transición en un buscador Web, las directivas pueden dictar también que se busque en la memoria caché mensajes de correo electrónico anteriores relativas a la transacción, por ejemplo enviados a o recibidos desde la misma organización. Esto puede determinarse haciendo coincidir porciones del URL del buscador con porciones de la dirección de correo electrónico. De forma similar, las transacciones detectadas en los mensajes de correo electrónico pueden producir que tanto correos electrónicos anteriores como páginas Web anteriores se recuperen de la memoria caché. El control pasa a continuación a la etapa S284 en la cual se almacenan en la base de datos del sistema 42 la transacción identificada y cualesquiera transmisiones anteriores recuperadas.
En la etapa S280, si no se requieren las transmisiones anteriores, el control pasa directamente a la etapa S284 donde la transmisión identificada como una transacción se graba en la base de datos del sistema. Al mismo tiempo que las transmisiones se almacenan en la etapa S284, datos relativos tales como la identidad del usuario, la cantidad o la otra parte para la transacción también pueden grabarse en la base de datos del sistema para formar una grabación completa, aunque esto dependerá de las instrucciones de los datos de directivas. El control pasa a continuación a S286 y el módulo sale.
Siguiendo desde la etapa S276 después de que el módulo sale, pueden transmitirse los datos, siguiendo el punto A en las Figuras 3 y 5, o procesarse siguiendo a su recepción en los puntos C y B en las Figuras 3 y 5 respectivamente.
Una vez que se ha identificado que está teniendo lugar la transmisión pueden grabarse todas las transmisiones entre el usuario y la otra parte hasta que el sistema detecta que se ha completado la transacción. La detección del punto final de la transacción y la parada de la grabación pueden hacerse de un modo similar al descrito anteriormente para identificar si está teniendo lugar una transacción. La implementación más simple es grabar la información de la transmisión hasta que se recibe un recibo electrónico o una orden de envío. Como alternativa, puede hacerse que la grabación de transmisiones pare después de que se han producido un número predeterminado de transmisiones entre el usuario y la otra parte, o si ha transcurrido una cierta cantidad de tiempo desde que se identificó la transacción.
Las transmisiones pueden hacerse mas simples si cada vez que el usuario cambia el sitio de la Web se vacía la memoria caché. Esto mantiene la memoria requerida para una baja memoria caché, así como una reducción del número de transmisiones anteriores que se necesitan buscar si se emplean técnicas de búsqueda.
Se apreciará que los métodos descritos anteriormente pueden usarse también para grabar las transmisiones asociadas que se producen después de que se detecta y se graba una transacción. Por ejemplo, una transacción realizada usando un buscador Web típicamente irá seguida por un correo electrónico de confirmación enviado desde el remitente al comprador. Este correo electrónico puede detectarse como que forma parte de la transacción, ya que contendrá características comunes, tales como el número de pedido, el número de cuenta, la descripción de los artículos, el precio, etc. También puede enviarse desde una dirección similar a la dirección del sitio Web, por ejemplo "servicioclientes@abc.com" cuando el sitio Web original usado para realizar la compra fue "abc.com". Preferiblemente se usa un elemento de tiempo de modo que sólo se consideran que están asociadas con la transacción original, las transmisiones posteriores que ocurren dentro de un periodo de tiempo dado.
Además de grabar la información de transacción, puede ser ventajoso grabar otra información que proporciona la gestión con la capacidad de analizar el comportamiento de sus usuarios, por ejemplo para asegurar que la organización está en efecto obteniendo un beneficio de productividad real desde su adopción del comercio electrónico. Tal información no está limitada a la productividad del propio usuario, sino de todos los procesos, permitiendo por ejemplo una comparación de los sitios Web de compra para determinar cuáles son los más eficaces en términos del proceso de compra, y por lo tanto cuáles serán de mayor beneficio al reducir los costes de la compra. El sistema preferido provisto para esto graba información adicional, tal como la cantidad de tiempo que toma una compra, el número de pulsaciones de tecla y de clic de ratón requeridos para completar una compra, la cantidad de tiempo de "espera" mientras el usuario espera para bajar las páginas o recibir respuesta. Esta información puede grabarse con la grabación de la transacción en la base de datos, permitiendo realizar análisis estadísticos a través de un intervalo de transacciones.
El tiempo que se tarda para una transacción puede determinarse asociando un sello temporal con cada una de las transmisiones recibidas. Cuando se determina que la transacción está completa, el sello temporal asociado con la primera transmisión (que puede haberse recuperado de la memoria caché en la etapa S282) se resta del sello temporal asociado con la última transmisión, y el resultado, que será la duración total de la transacción, se almacena en la base de datos en la etapa S284. Como alternativa, los sellos temporales primero y último podrían grabarse en la base de datos y la duración de la transacción calcularse más tarde. El número de pulsaciones y de clic de ratón puede determinarse en un sistema basado en Windows de Microsoft usando el "hooks" de Windows normalizado dentro del sistema operativo. Tales técnicas se describen más enteramente en el documento "Win 32 Hooks" de Kyle Marsh del Grupo de Desarrolladores de Tecnología de Red de Microsoft, fechada el 29 de Julio de 1993 disponible en el sitio Web de la Corporación de Microsoft (http://msdn.microsoft.com/library/default.asp? url =/library/en- us/dnmgmt/html/msdn_hooks32.asp).
El sistema preferido mantiene contadores del número de pulsaciones del teclado (que usan el gancho WH-KEYBOARD) y los clic de ratón (usando el gancho WH-MOUSE) que se producen entre cada dos transmisiones recibidas, asociadas estos totales con la transmisión recibida. Las pulsaciones del teclado y los clic de ratón que se producen mientras que se enfoca otra aplicación (por ejemplo si el usuario conmuta temporalmente a otra aplicación) se ignoran. Cuando se determina que la transacción está completa, el total de pulsaciones de teclado y de clic de ratón que se producen entre la primera transmisión (que pueden recuperarse de la memoria caché en la etapa S282) y la última transmisión se suman juntos, y el resultado, que será el número total de pulsaciones de teclado y clic de ratón durante la transacción global, se almacena en la base de datos en la etapa S284. De forma similar, puede medirse el tiempo de respuesta de la transacción del sitio Web anotando el instante en el que se envía cada petición de transmisión de salida, y restándole a continuación del instante en el que se recibe la respuesta. Agregando los tiempos de respuesta entre el comienzo y fin de la transacción dará el tiempo total que el usuario invierte esperando del sitio Web. De forma similar, el sistema preferido también cuenta el tiempo de respuesta del usuario, que es el tiempo entre que se recibe una transmisión, y el tiempo en el cual se transmite una respuesta.
El sistema preferido también calcula cuanto del tiempo de respuesta del usuario se invierte en introducir los datos, y por lo tanto permite determinar el tiempo requerido por el usuario para "absorber" la transmisión de entrada (que es la diferencia). El tiempo invertido en introducir los datos se determina manteniendo un "reloj de parada". El reloj de parada se resetea cada vez que se recibe una nueva transmisión, y se re-arranca inmediatamente cada vez el usuario introduce una pulsación de teclado o un clic del ratón. En caso de que el usuario no introduzca una pulsación del teclado o un clic del ratón durante un periodo de tiempo predeterminado, por ejemplo 5 segundos, el sistema asume que el usuario está ahora absorbiendo los detalles de la transmisión anterior y para el reloj. El reloj se para también cuando la pulsación del teclado o el clic de ratón produce que se envíe una transmisión de salida. Agregando el tiempo invertido en introducir datos entre el comienzo y el final de la transacción dará el tiempo total que el usuario invierte en introducir los datos sobre el sitio Web. Los tiempos agregados pueden almacenarse en la base de datos en la etapa S284 para su análisis futuro.
El sistema preferido también proporciona un medio para monitorizar transacciones que se han realizado y suspende automáticamente la transacción para su aprobación si se estima necesario. Este proceso permite a una gran compañía monitorizar y controlar las transacciones que se están realizando por sus empleados usando un único conjunto de criterios fijados en los datos de directivas. Los datos de directivas pueden suspenderse cada vez que se identifica una transacción para determinar si el usuario está autorizado para realizar esa transacción el mismo o si necesita solicitar una autorización de un superior en la compañía. El proceso se ilustra en la Figura 15 a la cual se hará ahora referencia.
El módulo que incorpora este proceso se inicia en la etapa S290. Esta iniciación tiene lugar preferiblemente tan pronto como se han determinado todos los detalles relevantes de la transacción que necesitan considerarse, y antes de que se comprometa la transacción. En el caso de una transacción de correo electrónico, detalles tales como los artículos y el precio típicamente contenidos dentro de un único correo electrónico pueden considerarse antes de la transmisión de ese correo electrónico. En el caso de una transacción de un buscador Web, la existencia de la transacción puede detectarse antes de que se conozcan todos los detalles, en cuyo caso no tiene lugar la iniciación hasta que están. Esto normalmente no presenta un problema ya que el compromiso final no se produce hasta muy el final del proceso de transacción, o bien hasta que no se conocen todos los detalles relevantes. Puede determinarse la detección de la transacción y todos los detalles relevantes del modo descrito anteriormente con referencia a la Figura 12. Refiriéndonos brevemente a las Figuras 3 y 5, se verá que la etapa S290 ocurre después del punto C en la Figura 3 en el caso de una implementación de un buscador Web, o después del punto A en la Figura 5 en el caso de una implementación de un cliente de correo electrónico una vez que se conocen los detalles requeridos.
El control pasa desde la etapa S290 a la etapa de decisión S292 en la que los detalles de la transacción se comparan frente al escenario de directivas a determinar si se requiere o no la aprobación. La determinación puede basarse sobre la identidad de la posición del empleado que realiza la transacción, la cantidad de la transacción, o la otra parte en la transacción. En algunos casos, podría requerirse siempre la aprobación, tales como si el director financiero de la compañía desea revisar todas las transacciones antes de que se hagan.
La Figura 16 es una ilustración de datos de directivas de ejemplo que pueden usarse para determinar si una transacción requiere o no una aprobación desde una tercera parte y también para determinar la identidad del aprobador apropiado que se usará. En este caso, las condiciones en los datos de directivas estipulan si se requiere la aprobación dependiendo del importe de la transacción, y la dirección de URL de la otra parte de la transacción.
Los datos de directivas relevantes se fijan sobre la rama Aprobación de Transacciones del árbol de datos de directivas. Esta rama se subdivide en cuatro sub-ramas. La primer rama se titula "CantidadMáximaTransacción-SinAprobación" y define un cantidad umbral para las transacciones. Las transacciones por cantidades por encima del umbral deben aprobarse por un aprobador antes de hacerse.
La segunda sub-rama titulada "CantidadMáximaMensualSinAprobación" define una cantidad máxima para las transacciones que un usuario puede realizar dentro de un mes. En este caso, cualquier transacción realizada por el usuario que produjese que el total mensual excediese de 2.500 \textdollar requeriría la aprobación por una tercera parte, así como transacciones adicionales realizadas después de que se haya alcanzado ese umbral.
La tercera rama titulada "SitiosExcluidos" se refiere a una tabla que contiene los sitios Web y las direcciones de correo electrónico de todos los sitios que siempre requieren una aprobación de una tercera parte antes de realizar la transacción. Finalmente, la última rama titulada "Aprobadores" se refiere a una tabla en la que se listan los nombres de posibles aprobadores de tercera parte. Junto con cada nombre está la cantidad máxima de transacción para la cual ese aprobador tiene la autoridad de aprobar, y una lista de sitios excluidos para los cuales ese aprobador no puede aprobar una transacción. En el más simple de los casos, los aprobadores serán otros usuarios del ordenador dados de alta sobre la misma red que el usuario que está realizando la transacción tal como los gestores del departamento, o supervisores. Los aprobadores serán, por la propia naturaleza de su papel, miembros de la compañía comercial que asume y que tiene autoridad para asumir la responsabilidad por las transacciones financieras que realiza la compañía. Es también posible que los aprobadores pudieran sacarse de un grupo de personas que están empleadas principalmente en este papel, tal como personas sólo en el departamento financiero.
Si las condiciones sobre la primeras tres sub-ramas del árbol de la rama de transacción indican que se requiere esa aprobación puede encontrarse un aprobador apropiado explorando a través de la tabla de aprobadores hasta que se encuentre un aprobador cuyo límite de transacción sea igual o superior al de la transacción propuesta y que no está prohibido para la aprobación de las transacciones en el sitio relevante.
Se apreciará que los datos de directivas de ejemplo mostrados en la Figura 16 son los datos de directivas que se especifican a un usuario único de un ordenador, o grupo de usuarios, en al red. Otros usuarios, o grupos, pueden tener diferentes escenarios y diferentes listas de aprobadores.
Se apreciará que las condiciones para determinar un aprobador apropiado pueden introducirse creando unas nuevas sub-ramas del árbol de datos de directivas.
La operación del proceso de aprobaciones podría por ejemplo extenderse a cualquier clase de transmisiones, no sólo las que comprenden una transacción de comercio electrónico. Tal operación puede implementarse teniendo las condiciones definidas o las sub-ramas de los datos de directivas que especifican nombres de usuario, direcciones o palabras clave por ejemplo que se identificarán en la transmisión y se actuará sobre ellos. De este modo, todas las transmisiones de correo electrónico a una compañía particular o individual pueden producir que se requiera una aprobación, o todos los correos electrónicos que contienen una información predeterminada reconocida a través de la identificación de una palabra clave.
Si se determina en la etapa S292 que no se requiere ninguna aprobación, el control pasa directamente a la etapa S294 en la cual el módulo sale. Siguiendo la etapa S294 se permite la transmisión de la transacción y puede proseguir la transacción. El control vuelve desde la etapa S294 al punto C en la Figura 3 o al punto B en la Figura 5.
Sin embargo, si en la etapa S292, después de consultar el escenario de directivas, se determina que se requiere la aprobación de la transacción, el control pasa a la etapa S296 en la cual se usan los detalles de la transacción para determinar un aprobador apropiado para la transacción. El aprobador puede ser un empleado de la compañía con sesión iniciada en su estación de trabajo, o en una estación de trabajo con una función dedicada a aprobador tal como las Consolas de Operador 44, como se muestra en la Figura 2, o puede ser incluso un proceso automatizado. En el caso de una gran compañía con varios departamentos, puede ser ventajoso tener un grupo de aprobadores para cada departamento, monitorizando cada grupo las cuentas del departamento. Esto permite rechazar transacciones antes de que se realicen, por ejemplo si la dirección del departamento decide que desea suspender temporalmente las compras, o las compras de una naturaleza particular.
El control pasa desde la etapa S296 siguiendo la determinación de un aprobador apropiado a la etapa S298 donde se transmite una petición de aprobación al aprobador designado a través de la cola de aprobaciones del sistema 100. A continuación de la etapa S298 el control pasa a la etapa de decisión S300 donde se determina si se ha recibido una respuesta del aprobador. En el momento de emitir una petición de aprobación se arranca un temporizador. Si no se ha recibido una respuesta en la etapa 300 el control pasa a la etapa S302 donde se determina por el temporizador si ha transcurrido el periodo de espera o no. Suponiendo que el periodo no ha transcurrido el control pasa desde la etapa S302 de vuelta a la etapa S300 donde el sistema continúa esperando una respuesta del aprobador. De este modo las etapas S300 y S302 forman un bucle en el que el sistema espera hasta que se recibe una respuesta o hasta que expira la temporización. En la etapa de decisión S300 una vez que se recibe la respuesta, el control pasa a la etapa S304 en la cual se toma una acción dependiendo de si la transacción se aprobó o se rechazó.
Si la transacción se aprobó el control pasa desde la etapa S304 a la etapa S294 en la cual el módulo sale y se permite que prosiga la transmisión. Sin embargo si la transmisión no se aprueba entonces el control pasa desde la etapa S300 a la etapa S306 en la cual el módulo sale. La salida en la etapa S306 sin embargo impide que tenga lugar la transmisión de la transacción y devuelve al usuario al punto A en la Figura 3 en el caso de una implementación de un buscador Web o a la etapa S132 "componer un correo electrónico" en la Figura 5 en el caso de una implementación de un cliente de correo electrónico.
También, si en la etapa S302 se estima que ha expirado la "temporización" sin que se haya recibido una respuesta desde el aprobador el control pasa directamente a la etapa S306 en la cual el módulo sale.
El lado derecho de la Figura 15 muestra las etapas involucradas por el aprobador. El proceso del aprobador se inicia en la etapa 310, desde la cual el control pasa a la etapa S312 en la cual la máquina del aprobador indaga en la cola de aprobaciones del sistema por cualquier nueva petición de aprobación. El control a continuación pasa a la etapa de decisión S314. En la etapa S314 si no está pendiente ninguna petición, el control pasa de vuelta a la etapa S312 donde se interroga una vez de nuevo la cola del sistema. Estas etapas se repiten hasta que se recibe una petición de aprobación o hasta que el aprobador desactiva el proceso de aprobación.
En la etapa S314 si se recibe una petición de aprobación, el control pasa a la etapa S316 en la que la petición de aprobación se descarga desde la cola del sistema y el propio aprobador decide si aprobar la petición o rechazarla. El control pasa a continuación a la etapa S318 en la que la respuesta del aprobador se transmite de vuelta a la cola de aprobaciones del sistema y desde allí vuelve a la estación de trabajo de los usuarios.
El control pasa desde la etapa S318 de vuelta a la etapa S312 en la que el sistema indaga la cola de aprobaciones del sistema para nuevas peticiones de aprobación. Se apreciará que el proceso de aprobaciones podría automatizarse totalmente en algunas circunstancias. Por ejemplo, las transacciones pueden rechazarse automáticamente si la compañía no tiene suficientes fondos, si producirían que se excediesen las cantidades presupuestadas, o simplemente si están por encima de una cantidad máxima. Tal automatización podría proporcionarse alternativamente como parte del proceso de usuario, de modo que incluso no se hace la petición de aprobación.
Para determinar si aprobar una transacción determinada, el aprobador debería idealmente ser capaz de tener una visión completa del mismo, por ejemplo de modo que pueda ver exactamente lo que se está comprando, más que simplemente la información resumen, tal como el precio total y el suministrador. El sistema preferido se proporciona para esto combinando las características de la grabación de las transmisiones descrita anteriormente, con las características de las aprobaciones. La petición de aprobaciones enviada en la etapa S298 se suplementa con una referencia a la localización en la base de datos de la información de transacción almacenada en la Etapa S284. El aprobador recibe los detalles de la localización en la etapa S316 y el sistema recupera las transmisiones que constituyen la transacción desde la base de datos, presentándolas adecuadamente en pantalla de modo que el aprobador pueda considerarlas haciendo su determinación de la aprobación. La operación continúa luego normalmente en la etapa S318. Claramente es importante que la etapa de grabación S284 tenga lugar antes que se realice la petición de aprobación en la etapa S298, de lo contrario la información grabada no estará ya disponible. Como en la etapa 284 se habrá identificado la transacción, pero no se habrá completado aún (ya que no se ha aprobado aún), es necesario para la grabación en la base de datos realizada en la etapa S284 contener un indicador que identifica la transacción como "pendiente". Este indicador puede actualizarse en la Etapa S316 para mostrar que la transacción se ha aprobado o denegado, o como alternativa, si se deniega la aprobación la grabación de la base de datos puede borrarse ya que la transacción no tuvo lugar.
Seguridad
El sistema preferido proporciona un medio para asignar una clasificación apropiada de la seguridad a la transmisión dependiendo de la naturaleza identificada de los datos que se están transmitiendo. La clasificación de seguridad asignada puede fijarse por el usuario del sistema usando los datos de directivas para reflejar sus necesidades.
La implementación más simple de los datos de directivas en este caso es una lista que contiene una primera columna de posibles tipos de datos, tales como contraseñas de empleados, contraseñas de empleadores, números de tarjetas de crédito, detalles bancarios y así sucesivamente, y que contiene en una segunda columna, la fuerza de cifrado deseada (en bits de clave, por ejemplo) que se estima apropiada para cada tipo de datos. Se apreciará que pueden emplearse otros modos de asignar niveles de seguridad dependiendo de la naturaleza determinada de los datos que pueden emplearse también dentro del alcance de la invención.
La Figura 17 muestra una ilustración de ejemplo de los datos de directivas que definen la fortaleza de cifrado adecuado para los diversos tipos de datos. Los datos de directivas toman la forma de varios pares de valores clave dispuestos en ramas separadas del árbol de datos de directivas. La clave especifica el tipo de datos que se están transmitiendo tales como contraseñas, números de tarjetas de crédito, palabras clave enviadas y una clave general para cualesquiera otros datos enviados. Los valores que corresponden a estas claves son la fortaleza del cifrado en bits que se estiman apropiados para la transmisión de los datos especificados en la clave. Los pares de valores clave se disponen sobre varias ramas de la rama NivelRequeridoCifrado de la rama SeguridadDatosTransmitidos del árbol de datos de directivas. De esta forma, en el ejemplo, puede verse que las contraseñas tienen una fuerza de cifrado deseada de 40 bits, los números de tarjetas de crédito de la compañía y los números de las tarjetas de crédito personales tienen ambas una fortaleza de cifrado deseada de 128 bits, las palabras clave enviadas tienen una fortaleza de cifrado deseado de 40 bits y los otros datos enviados no requieren cifrado.
La rama de PalabrasClaveEnviadas se refiere a palabras particulares o cadenas de caracteres o texto que se han designado como sensibles y requieren alguna forma de cifrado. Estas pueden ser nombres de usuario, información de direcciones, información financiera o palabras preseleccionadas tales como "Confidencial o Secreto". Las palabras clave enviadas pueden detectarse por referencia a una tabla en la cual están almacenadas.
Además, cada rama de los datos de directivas puede, en lugar de dar una fortaleza de cifrado general, referirse a una tabla en la que las diferentes contraseñas o números de crédito, por ejemplo, se listan junto con las correspondientes fortalezas de cifrado específicas para cada contraseña o número.
Una vez que se ha asignado una clasificación de la seguridad, el módulo de expansión interroga bien al buscador Web para determinar la seguridad del enlace que se ha establecido por el buscador Web con el servidor Web para la transmisión de esa información, o en el caso de una transmisión de correo electrónico, el escenario de cifrado que el usuario o la aplicación han determinado que se aplicará al mensaje. Típicamente, esta será la fortaleza de cifrado del algoritmo de cifrado usado para codificar los datos para la transmisión. Tales detalles de la transmisión se reciben por el buscador Web como parte de la "secuencia de establecimiento electrónica" desde el proveedor del servicio Web.
Un enlace seguro se indica usualmente en la ventana del buscador por la presencia de un icono de un candado cerrado en la esquina superior derecha. El usuario puede hacer clic sobre el icono para interrogar el nivel de seguridad que se ha proporcionado por la secuencia de establecimiento. Al hacerlo puede recibir una notificación de la forma ASSL asegurada. (128 bits). La primera parte de la notificación describe el tipo de cifrado usado mientras que la segunda parte describe la fortaleza de cifrado. El módulo de expansión se implementa para obtener automáticamente estos datos desde el buscador de modo que puede usarse para determinar si el nivel de seguridad es adecuado o no para la transmisión propuesta. De forma similar, en el caso de un mensaje de correo electrónico, el módulo de expansión determina el escenario de cifrado que el usuario o la aplicación han especificado usar antes de la transmisión del mensaje.
El módulo compara la fortaleza de cifrado especificada con la del enlace o mensaje y dependiendo del resultado de la comparación realiza una de las siguientes actuaciones:
a) si la seguridad del enlace es apropiada para la naturaleza de la información a transmitir, el módulo permite que se transmita la información;
b) si la seguridad del enlace es mayor que la requerida para la transmisión de la información entonces, el módulo puede o permitir que la información se transmita a ese nivel de seguridad, renegociar automáticamente con el servidor de la Web y el buscador Web un nuevo nivel apropiado de seguridad y transmitir la información a ese nivel, o indicar al usuario que el presente nivel de seguridad es innecesario e invitarles a tomar una acción.
c) si la seguridad del enlace no es suficiente para la naturaleza de la información que se está transmitiendo entonces, el módulo puede o impedir que la transmisión tenga lugar y advertir al usuario, renegociar automáticamente con el servidor Web y el buscador Web un nuevo nivel apropiado de seguridad y transmitir a continuación la información a ese nivel, o en el caso de un correo electrónico aumentar automáticamente el escenario de fortaleza de cifrado, o indicar al usuario que el nivel presente de seguridad no es suficiente e invitarle a confirmar que aún desea que tenga lugar la transmisión.
Se apreciará que el módulo de expansión podría configurarse para responder a una diferencia en el nivel deseable determinado de seguridad y que está provisto de varios modos y que las acciones esbozadas anteriormente son sólo ilustrativas.
Acciones adicionales que pueden tomarse por el sistema podrían incluir solicitar una página Web diferente a descargar en la máquina del usuario o modificar los datos del campo enviado de modo que la información sensible no se transmita.
El funcionamiento de un módulo de expansión de buscador o de correo electrónico para monitorizar los datos que se están transmitiendo por un usuario del sistema preferido se ilustra en la Figura 18, a la cual se hará referencia. El módulo comienza la operación en la etapa S320 en el punto C en la Figura 3, justo antes de la transmisión de los datos al servidor Web o en el punto B en la Figura 5 junto antes de la transmisión de un correo electrónico. El control pasa a continuación a la etapa S322, en la cual el módulo pasa analiza sintácticamente los datos a punto de transmitir y busca números de tarjetas de crédito. Un posible método para hacerlo se describió anteriormente, con referencia a la Figura 8. Si no se detecta ningún número de tarjeta de crédito en los datos el control pasa a continuación a la etapa S314 en la cual el módulo busca contraseñas en los datos a punto de transmitir. Un método para hacer esto se ha descrito anteriormente con referencia a la Figura 6. Si no se encuentra ninguna contraseña en los datos, entonces el control pasa a la etapa S316 en la cual el módulo busca cuentas de la compañía o códigos de compra en los datos. El reconocimiento de cuentas o códigos de compra puede conseguirse almacenando los códigos de la compañía en un fichero y intentando hacer coincidir estos códigos con cualquier cadena de caracteres o dígitos encontrados en los datos de salida. Si no se encuentra ningún código de cuenta entonces el control pasa a la etapa S318, donde el módulo busca indicaciones de otros datos sensibles en los datos a transmitir. Tales indicaciones necesitarán definirse con anticipación preferiblemente en un fichero separado usado para la detección, y será dependiente de los requisitos de los usuarios del sistema preferido. Podrían especificarse ejemplos de palabras clave relativas a proyectos que la compañía está emprendiendo, los propios títulos de los proyectos, direcciones de detalles personales del receptor de los datos, o del remitente, o incluso la palabra "confidencial" o "privado" incluida en los propios datos.
Si no se encuentran tales indicaciones de que los datos son sensibles y requiere una protección más fuerte antes de transmitirse, entonces se permite que prosiga la transmisión en el nivel actual de cifrado. Esto puede significar que la transmisión tiene lugar sin que se aplique ningún cifrado.
Sin embargo si cualquiera de las comprobaciones en las etapas S322 a la etapa S328 revelan datos que se estiman sensibles a continuación el control pasa a la etapa S332 en la que se asigna una clasificación de seguridad a los datos detectados. Esto se consigue comparando los datos detectados con las entradas predeterminadas en los datos de directivas.
Cada entrada en la rama de los datos de directivas tiene un nivel preasignado de cifrado que es el nivel mínimo que puede usarse para la transmisión de esos datos. Las entradas en la tabla y el nivel asignado de cifrado, como con todo el escenario de directivas, se deciden por la compañía usando el sistema preferido dependiendo de sus requisitos. Asignar una clasificación de seguridad es entonces simplemente un asunto de buscar una contraseña, un número de tarjeta de crédito u otros datos en los datos de directivas y leer la clasificación correspondiente. Pueden usarse referencias a tablas sobre la sub-rama de datos de directivas para asignar diferentes fortalezas de cifrado a diferentes contraseñas, números de tarjetas de crédito y así sucesivamente.
Una vez que se ha determinado el nivel de seguridad apropiado en la etapa S332, el control pasa a la etapa S334 en la que el módulo determina el nivel de cifrado que se ha negociado con el servidor Web al que se están transmitiendo los datos, o a usar por la aplicación de correo electrónico antes de transmitir el mensaje. Esto puede conseguirse interrogando al buscador Web o a la aplicación de correo electrónico, o fijando las variables de la fortaleza de cifrado en el instante en que se establece el enlace o se determina los requisitos de cifrado del correo electrónico, ambos de los cuales se producirán antes de la transmisión.
El control pasa a continuación a la etapa de decisión S336 en la que el nivel deseado de seguridad, es decir la fortaleza de cifrado, se compara con la determinada en la etapa anterior. Si el nivel de cifrado deseado es menor o igual que el determinado en la etapa S334, entonces se estima que es suficiente protección para los datos a transmitir y el control pasa a la etapa final S330, donde el módulo sale. A continuación de la etapa S330, el control vuelve bien al punto C en la Figura 3 o al punto B en la Figura 5 dependiendo de si el módulo está implementado en un buscador Web o en un cliente de correo electrónico. La transmisión de los datos puede seguir a continuación en el modo usual.
Sin embargo si en la etapa S336, el nivel deseado de cifrado es mayor que el fijado actualmente, entonces el módulo no permite que prosiga la transmisión hasta que se haya negociado el nivel de cifrado adecuado. El control pasa a la etapa de decisión S338 en la cual el módulo determina si es capaz de incrementar la fortaleza de cifrado, y si es así el control pasa a la etapa S340 donde se negocia un nuevo enlace cifrado más fuertemente, o en el caso de un correo electrónico se fija una fortaleza de cifrado mayor.
El nivel mas alto de cifrado que está disponible depende del software que se esté usando tanto por el servidor Web como por el buscador Web, o en el caso de un correo electrónico por las aplicaciones que envían y reciben el correo electrónico. Puede entonces haber casos en los que el nivel apropiado de cifrado no esté disponible por una parte y nunca se permite que proceda la transmisión de los datos. Además, a ciertos tipos de datos pueden darse una clasificación de seguridad determinada que indica que ningún nivel de cifrado será nunca lo suficientemente elevado para protegerlos, es decir: impidiendo que los datos se transmitan nunca.
Habiendo intentado reestablecer el enlace, o cambiar el escenario de cifrado del correo electrónico, a una fortaleza de cifrado mayor, el control pasa de nuevo a la etapa S334 para asegurar que el enlace o las fijaciones son ahora de la fortaleza adecuada. Si no puede renegociarse el nivel apropiado de cifrado en la etapa S338, o un intento de aumentar la fuerza de cifrado en la etapa S340 no ha tenido éxito, entonces se estima inseguro transmitir los datos, y el control pasa a la etapa final S342 donde el módulo sale. A continuación de la salida en la etapa S342, el control vuelve al punto A en la Figura 3, o a la etapa S132 en la Figura 5 "componer correo electrónico", para que el usuario reconsidere y edite o aborte la transmisión. También puede presentarse en pantalla al usuario un mensaje adecuado explicando las razones por las que se ha impedido la transmisión.
El sistema preferido proporciona por lo tanto un modo de asegurar que la transmisión de datos es tan segura como sea posible. Esto descarta la posibilidad de que un usuario olvide asegurar una transmisión, y negocie un nivel de seguridad más apropiado, si el que se ha usado no es suficiente.
Los Buscadores Web pueden proporcionar facilidades similares para advertir a los usuarios que los datos introducidos están a punto de enviarse sobre un enlace inseguro o proporcionar facilidades para cifrar todos los mensajes por defecto. El sistema preferido sin embargo proporciona la capacidad de examinar el contenido de los datos a transmitir para determinar sus requisitos de seguridad, para permitir o impedir la transmisión en base a tales requisitos de seguridad, y sobre el nivel de seguridad determinado del enlace (fortaleza de cifrado). Se apreciará que el sistema preferido proporciona un sistema mejorado significativamente para transmisiones seguras que reduce la posibilidad del error humano.
Monitorización de los correos electrónicos salientes para información sensible
Además del problema de que los datos sensibles se intercepten por una tercera parte entre el remitente y el receptor, las organizaciones están en un riesgo considerable de la emisión deliberada de información sensible por sus usuarios. Por ejemplo, la práctica de robar "electrónicamente" copias de documentos confidenciales, tales como listas de clientes, antes de dejar el empleo de una organización se consigue fácilmente, virtualmente imposible de encontrar, y consecuentemente de amplia difusión. Todo lo que se requiere al usuario es enviar el documento con su propia dirección privada de correo electrónico para recuperarlo más tarde. El documento no necesita incluso enviarse a través del sistema de correo electrónico propio de la organización, ya que puede usarse un servicio de correo de Internet tal como "Hotmail", haciendo que el rastro de la "filtración" no autorizada virtualmente imposible por los medios actuales.
Además de proporcionar medios para asegurar que se aplica un nivel apropiado de cifrado a los mensajes, el sistema preferido permite que los mensajes identificados como potencialmente sensibles se redirijan o se copien automáticamente a otro destino sin conocimiento del usuario. Para determinar si redirigir tales mensajes el sistema preferido tiene en cuenta varios factores incluyendo la identidad del remitente, la identidad del receptor pretendido, la naturaleza de la dirección de los receptores pretendidos, la naturaleza del contenido del mensaje, la naturaleza y existencia de cualesquiera anexos al mensaje, el medio por el cual se intenta transmitir y si el mensaje, y/o los anexos están o no cifrados.
La naturaleza del mensaje puede determinarse explorándole para una o más palabras clave, o combinaciones de palabras clave, o usando las técnicas normalizadas de "preguntas naturales del lenguaje". La naturaleza de la dirección de los receptores pretendidos puede determinarse por referencia a una lista de dominios del servicio de correo de Internet. Por ejemplo, "hotmail.com", "yahoo.com" y "aol.com" se usan todos predominantemente por individuos, no por corporaciones. De forma similar, la dirección puede examinarse para similitudes con el nombre del remitente, por ejemplo un correo electrónico conocido a enviar por Fred Smith a la dirección "smith900@aol.com" podría considerarse sospechoso por la inclusión de ambos "smith" y "aol.com" en la dirección del receptor. Exámenes adicionales del mensaje pueden soportar la probabilidad de que sea una emisión no autorizada de datos confidenciales, por ejemplo si el mensaje consiste sólo de anexos con el mensaje de texto y el tema en blanco, un importante indicio ya que el remitente puede ser menos probable teclear un texto que sólo el leerá. El medio por el cual el mensaje se transmite es un factor importante, por ejemplo una transmisión enviada usando un servicio de correo de Internet tal como hotmail puede considerarse mucho más sospechoso que uno enviado a través del sistema de correo electrónico corporativo usual.
Es más, la "descarga" de ficheros al servicio de correo de Internet es potencialmente tan sospechosa que la realización preferida proporciona medios para prohibir absolutamente la descarga de ficheros a tales servios.
Cuando se redirige el correo, el sistema preferido añade texto adicional al comienzo del correo, por ejemplo
"- - -Correo Redirigido- - -", junto con la dirección de los receptores pretendidos originalmente, de modo que el nuevo receptor pueda determinar que le fue redirigido, y a quien se envió originalmente.
Si el mensaje enviado se va a cifrar, el sistema preferido puede redirigir el mensaje cifrado o descifrado a la tercera parte, preferiblemente, la clave de cifrado del remitente se transmite con el mensaje y se proporcionan medios a la tercera parte para descifrar el mensaje, si aún está cifrado, y cifrar el mensaje con la clave original del remitente para su transmisión.
El sistema preferido también identifica correos de entrada que se han redirigido (es decir enviados al usuario que no es originalmente el receptor pretendido), buscando el texto "- - -Correo Redirigido- - -". Tal correo puede señalarse para la atención por el nuevo receptor usando, por ejemplo, iconos especiales, o presentando una caja de mensaje para notificarlo. También puede proporcionarse un medio para permitir al nuevo receptor "aprobar" fácilmente el mensaje y enviarle al receptor originalmente pretendido. Esto puede conseguirse, por ejemplo proporcionando un botón de "Aprobar". Si se pulsa este botón, entonces el sistema preferido crea un nuevo mensaje del mismo modo que si el usuario hubiese presionado el botón normal de "Enviar". Sin embargo en lugar de añadir texto al mensaje para resaltar que se ha redirigido, en el caso del botón "Aprobar", el sistema extrae del mensaje la lista de receptores pretendidos originalmente, y a continuación desmonta los detalles de la redirección para dejar el mensaje en su estado original. Los campos "Para", "Cc" y "Bcc" se rellenan a continuación automáticamente con las direcciones de los receptores originales extraídos, y el campo "De" (que existe para cada mensaje incluso si se presenta en pantalla normalmente) se rellena con el nombre/dirección del remitente original. El campo de fecha/hora también puede ajustarse a la fecha/hora del mensaje original. El mensaje se envía a continuación, bien automáticamente, o cuando el usuario pulsa el botón "Enviar". De este modo, cuando con sólo pulsar uno o dos botones, el correo redirigido se puede aprobar y enviar, y cuando se entrega, parecerá que procede del receptor original como si la redirección no hubiese tenido lugar.
Los datos de directivas de muestra para controlar la operación de un módulo de expansión implementado para redirigir el correo electrónico se muestran en la Figura 19 y en la Figura 20 se muestra una ilustración esquemática de la operación de tal módulo de expansión. La Figura 19 es un árbol de datos de directivas que tiene varias ramas como corresponde a las etapas de decisión en la Figura 20.
El módulo de expansión se inicia en la etapa S350 que corresponde con el punto B en la ilustración del funcionamiento del cliente de correo electrónico en la Figura 5. Una vez iniciado, el módulo de expansión pasa a través de seis etapas que determinan particularidades diferentes del mensaje de correo electrónico de salida. En primer lugar, en la etapa S351 se comprueba la identidad de la persona que envía el correo electrónico frente a las entradas en una lista predeterminada de nombres o direcciones. Los correos electrónicos de usuarios de esta lista se estima que tienen la autoridad para transmitir correos electrónicos directamente al receptor pretendido independientemente del contenido del mensaje e independientemente del receptor. Cualquiera, no incluido en la lista puede tener su correo electrónico redirigido o no, dependiendo de su contenido. De este modo, en la etapa de decisión S351, si se encuentra el nombre o dirección del usuario en la lista entonces el control pasa a la etapa S364 donde se permite que se transmita el correo electrónico sin interacción adicional. Sin embargo, si el usuario no está en la lista, el control pasa a la etapa S253 para comprobaciones adicionales. En la etapa S352 se comprueba el receptor del mensaje de correo electrónico de salida frente a la tabla de búsqueda s, especificada en la rama Receptores de los datos de directivas mostrados en la Figura 19. En la siguiente etapa de decisión S354, el texto que comprende el mensaje del correo electrónico, y cualesquiera anexos adjuntos al mensaje de correo electrónico, se comparan con las entradas en la tabla de búsqueda t. La Tabla t se refiere a una rama de PalabrasClave de los datos de directivas y contiene palabras que indican la naturaleza del mensaje de correo electrónico que pueden ser sensibles para la compañía. En la siguiente etapa S356, el mensaje de correo electrónico se comprueba para ver si está o no cifrado. Se recordará que el cifrado no se produce hasta el momento que se transmite el correo electrónico, de modo que en esta etapa del correo electrónico sólo se señalará para cifrado. En la siguiente etapa de decisión S358, se determina si el mensaje de correo electrónico contiene o no anexos, y en la siguiente etapa de decisión S360 si el mensaje de correo electrónico contiene texto acompañando los anexos, esto es si el texto del cuerpo del mensaje de correo electrónico está en blanco.
En cualquiera de las etapas S352, S254 o S362 donde se consulta una tabla de búsqueda, una coincidencia entre una entrada en la tabla de búsqueda y una entrada en el correo electrónico indica que el correo electrónico debe redirigirse a una tercera parte para su comprobación antes de enviarlo fuera de la compañía. Por ejemplo, si en la etapa S354, se encuentra que el correo electrónico contiene las palabras "confidencial" o "secreto", serán suficientes para garantizar que el correo electrónico se compruebe por una tercera parte antes de enviarlo a su receptor pretendido. Esto asegura que la información sensible no se envía fuera de la compañía sin conocimiento de la compañía. El control fluye por lo tanto desde estas etapas a la etapa S364 donde el texto que indica que el correo electrónico se ha redirigido se añade al mensaje y se cambia la dirección del receptor a la de la parte de verificación a la cual se transmite el mensaje redirigido. El control pasa a continuación a la etapa S366 donde se transmite el correo electrónico. Si el mensaje de correo electrónico se ha marcado para redirección, en la etapa S336 se transmitirá en efecto a la parte de verificación para revisión en lugar del receptor original del mensaje.
En la etapa de decisión S356 si se detecta el cifrado del mensaje entonces se estima suficiente para garantizar la redirección del mensaje a una tercera parte para revisión. Por consiguiente, si el mensaje se va a cifrar, el control pasa de la etapa S356 a la etapa 364 donde se modifica el mensaje para la redirección. En el caso de un mensaje señalado para cifrado, la señal de cifrado preferiblemente se quita de forma que el mensaje se redirige sin que se haya cifrado, permitiendo al nuevo receptor leerlo. El texto de redirección, añadido al mensaje, incluye también preferiblemente la clave de cifrado (que es generalmente la clave pública del receptor pretendido, y por lo tanto no sensible) de modo que el mensaje pude volverse a cifrar antes de la transmisión.
Como alternativa, podría incluirse el certificado digital entero del receptor pretendido con el mensaje redirigido. La clave pública, o el certificado, como puede ser el caso, se eliminarían a continuación por el proceso de aprobación automático que se ha descrito anteriormente.
Si en la etapa S358 el correo electrónico no contiene anexos entonces se estima que es improbable que el correo electrónico contenga cualesquiera documentos o ficheros de información potencialmente sensible, y puede entonces permitirse la transmisión del correo electrónico sin ninguna intervención adicional en la etapa S364. Si el correo electrónico contiene anexos, y en la etapa S360 se determina que el correo electrónico no contiene ningún texto introducido dentro del cuerpo o en el tema del correo electrónico, entonces el mensaje se reconoce como que probablemente se está enviando a una cuenta diferente del remitente. Entonces el correo electrónico se redirige a una tercera parte para su comprobación en las etapas S362 y 364.
La figura 21 muestra el funcionamiento del módulo de expansión para bloquear la descarga de información del sistema de ordenadores de la compañía a un sitio externo. Se usa una simple comprobación de dos estados, comprendiendo una comprobación de la dirección del sitio externo en S372, siguiendo una iniciación en la etapa S370, y una comprobación de contraseñas sensibles en la información se están descargando en la etapa S374. Suponiendo que no se encuentra que la dirección del sitio externo sea un sitio prohibido en la etapa S372, y no se detectan palabras clave sensibles en la etapa S374, entonces se permite que continúe la descarga en la etapa S376. De lo contrario, se bloquea la descarga en la etapa S378.
Los datos de directivas para controlar la operación del módulo de expansión, para bloquear selectivamente la descarga de información son sencillos y se muestran en la parte superior de la Figura 19.
De este modo, las transmisiones de salida que contienen información sensible que se están transmitiendo por razones que no son del interés de la compañía pueden verificarse antes de la transmisión, y si es necesario puede impedirse la transmisión.
Gestión de Reenvío de Correos Electrónicos
Las aplicaciones de correo electrónico proporcionan un medio para "Reenviar" un correo de entrada a uno o más usuarios. Típicamente el usuario hace clic sobre un botón de "Reenviar", que produce que una copia del mensaje de entrada se introduzca automáticamente en la ventana de composición del correo, como si el usuario lo hubiese tecleado el mismo. Todo lo que requiere a continuación al usuario es introducir los nombres de los receptores pretendidos del correo reenviado y hacer clic sobre el botón de "Enviar". Esto es una característica útil que permite a un usuario compartir fácilmente los contenidos de un correo electrónico recibido con otros.
En el caso de correos que contienen información sensible puede presentarse un problema, particularmente si la naturaleza sensible del correo no es inmediatamente evidente, por ejemplo si la información sensible aparece en la pare inferior del correo, de modo que se requiere que el usuario desplace el cursor hacia abajo en la ventana que se está viendo para leerlo. Los usuarios frecuentemente reenvían los correos electrónicos después de explorar sólo unas pocas líneas del principio, o en algunos casos sólo la línea del tema, particularmente cuando tienen grandes cantidades de correos electrónicos para procesar. Como consecuencia, frecuentemente se revela información sensible inintencionadamente, tanto dentro de la organización, como más peligrosamente fuera de ella. Hay varios casos de alto perfil donde como resultado se pierden sumas considerables.
El sistema preferido proporciona por lo tanto un medio para controlar el reenvío de correos electrónicos. Tal control incluye proporcionar advertencias al usuario antes de transmitir un correo electrónico reenviado e impedir en absoluto el reenvío del correo electrónico. También podría proporcionarse un medio para aprobar el correo electrónico antes de la transmisión, o redirigirlo a otro usuario, como se ha descrito anteriormente.
Preferiblemente, el reenvío se produce de acuerdo con el contenido del correo electrónico, y la dirección de los receptores a los cuales se ha enviado ya. Por ejemplo, la naturaleza sensible del correo electrónico puede determinarse por varios métodos incluyendo explorarlo para palabras clave tales como "confidencial", o comprobando si el atributo de sensibilidad se ha fijado a "Personal", "Privado" o "Confidencial". También puede proporcionarse un medio para el compositor original del mensaje marcar como inadecuado para futuros reenvíos insertando cadenas de caracteres predefinidos, tales como "<NOREENVIAR>" (impidiendo cualquier reenvío), o "<NOREENVIAREXTERNOS>" (impidiendo los reenvíos al exterior de la organización). También podría proporcionarse tal medio en la forma de un atributo adicional al mensaje.
Además de factores basados en el contenido, el sistema preferido interroga la lista de receptores anteriores del mensaje. Si el correo electrónico se ha enviado ya fuera de la organización por el componedor original, entonces puede por ejemplo considerarse seguro permitir reenvíos adicionales externamente. De forma similar, si el correo electrónico original se envió sólo a un receptor único, entonces puede determinarse que el componedor original no pretendió que circulase ampliamente y se emite una advertencia apropiada. El curso de la acción en respuesta a estos factores descritos puede determinarse de acuerdo con las directivas.
El hecho de que un correo electrónico que está a punto de transmitirse sea un correo electrónico reenviado puede determinarse fácilmente explorando el correo electrónico por cadenas de caracteres tales como "- - - -Mensaje Original- - - -" que se añaden automáticamente al comienzo del correo original por el programa de correo electrónico. De forma similar, puede determinarse la lista de receptores previos explorando las cadenas de caracteres "Para:" y "CC:" que siguen la cadena del mensaje original. La lista de receptores se encuentra inmediatamente después de estas cadenas de caracteres. Puede distinguirse fácilmente los receptores internos y externos por referencia al nombre del dominio (si lo hay). Por ejemplo, un nombre de un receptor como "Fred Smith" es típicamente interno, mientras que "fsmith@xyz.com" es típicamente externo.
En la Figura 22 se muestran los datos de directivas para instruir el funcionamiento de un módulo de expansión implementado para controlar el reenvío de mensajes de correo electrónico, y el funcionamiento de tal módulo en la Figura 23.
El árbol de los datos de directivas contiene varias sub-ramas que especifican los parámetros frente a los que pueden fijarse valores de comandos. Por ejemplo, la primera sub-rama "ImpedirTodos" cuando se fija a "SI", instruye al módulo a impedir que se reenvíen para todos los correos electrónicos. La siguiente sub-rama AdvertirTodos cuando se fija a SI, requiere al módulo para que advierta al usuario del cliente de correo electrónico cada vez que un correo electrónico está a punto de reenviarse. Las dos siguientes sub-ramas ImpedirExternos y AdvertirExternos contienen los parámetros correspondientes sólo para correos electrónicos externos y permiten al usuario del cliente de correo electrónico distinguir entre los papeles que afectan al reenvío de correos electrónicos dentro de la compañía y el reenvío de correos electrónicos a gente fuera de la compañía. La rama "ImpedirPalabrasClave" especifica una tabla de búsqueda en la cual se almacenan las palabras clave de información sensible. Tales palabras clave pueden predefinirse como cadenas de caracteres como <NOREENVIAR> o <NOREENVIAREXTERNO>, o una o más palabras predeterminadas.
El correo electrónico se explora antes de la transmisión y si se encuentra tal palabra clave en el texto del correo electrónico o en cualesquiera anexos del correo electrónico, no se permitirá el reenvío del correo electrónico. La dos últimas sub-ramas ImpedirSiNoEnviadosExternamente cuando se fija a SI se inhibirá la transmisión del correo electrónico reenviado al exterior de la compañía si no se ha transmitido anteriormente al exterior de la compañía. En la práctica el correo electrónico reenviado puede transmitirse a todos los receptores internos de la compañía, simplemente borrando los receptores externos de la lista de receptores o como alternativa, antes de la transmisión, puede requerirse al usuario para que modifique la lista de direcciones de modo que no contenga receptores externos.
Finalmente, el parámetro fijado sobre la rama ImpedirSiReceptorUnico cuando se pone a SI impide el reenvío de cualesquiera mensajes de correo electrónico si el receptor original del mensaje era una única persona.
La operación del módulo de expansión se ilustra en al Figura 23. El módulo de expansión se inicia en la etapa S380, de nuevo en el punto B en la Figura 5. En la etapa de decisión S382, se hace una exploración preliminar del correo electrónico para ver si contiene la cadena de caracteres "- - - -Mensaje Original- - - -", ya que esta cadena de caracteres se añade automáticamente al comienzo del correo original por el programa de correo electrónico cuando se genera un mensaje para el reenvío. Si el mensaje de correo electrónico no contiene esta cadena de caracteres, entonces puede deducirse que el mensaje de correo electrónico es un mensaje original y no se está reenviando y el mensaje puede transmitirse en la etapa S384. Sin embargo, si en la etapa S382 se encuentra que contiene la cadena de caracteres "- - - -Mensaje Original- - - -", entonces el mensaje de correo electrónico es claramente un mensaje reenviado, y el módulo toma etapas adicionales para determinar si permitir o no que se transmita el mensaje reenviado. El control fluye entonces a la etapa S386 en la cual se comprueban los receptores del mensaje reenviado para ver si cualesquiera son externos a la compañía en-línea. Si hay un receptor externo, entonces en la etapa S388, el módulo de expansión explora el mensaje de correo electrónico para ver si el correo electrónico se ha reenviado antes a un receptor fuera de la compañía. Si no es así, se impide que el mensaje de correo electrónico se envíe en la etapa S390 y se notifica al usuario del cliente de correo electrónico. Sin embargo, si el mensaje de correo electrónico se ha enviado antes fuera de la compañía, entonces se emite una advertencia al usuario en la etapa S392, a continuación de lo cual el mensaje de correo electrónico puede o transmitirse por el usuario o puede devolverse al usuario para que revise los receptores pretendidos.
Si en la etapa S386 el mensaje reenviado no se envía a una dirección fuera de la compañía, entonces el control pasa a la etapa S394, en la cual se determina si el usuario era el único receptor del mensaje original. Si lo era, entonces puede ser el caso de que el componedor original del mensaje no pretendiera por ello que se transmitiese a una amplia audiencia. Por consiguiente, el control fluye a la etapa S390 donde se bloquea la transmisión del mensaje de correo electrónico reenviado. Esto está de acuerdo con los datos de directivas mostrados en la Figura 22, que especifican tomar tal acción. Como alternativa, puede emitirse una advertencia al usuario que está intentando reenviar el mensaje.
La última comprobación realizada es en la etapa de decisión S396 en la cual los contenidos del mensaje y cualquier anexo adjunto al mismo se comparan con entradas en una tabla de palabras clave. Si se encuentra cualquier coincidencia de las entradas en el correo electrónico con las de la tabla entonces se considera que el mensaje contiene información sensible y no se reenvía. El módulo entonces termina en la etapa S390. Si no se encuentran palabras clave sensibles entonces se permite el reenvío del correo electrónico en la etapa S384.
Gestión de Firma de las Transmisiones Salientes
La capacidad de usar un Certificado Digital para firmar un mensaje es claramente valiosa para el receptor del mensaje para establecer la identidad del usuario, y para ambas partes para asegurar que no se ha manipulado el mensaje. El remitente del mensaje puede sin embargo no ser consciente de que un mensaje firmado digitalmente potencialmente constituye un contrato vinculante, que no puede denegarse o revocarse una vez enviado. Es por lo tanto imperativo que se tenga precaución cuando se firma digitalmente un documento, igual que la que debe tenerse cuando se añade una firma escrita a un documento de papel. Las aplicaciones de correo electrónico tales como el "Outlook" de la Corporación Microsoft proporcionan un medio para firmar mensajes digitalmente de forma automática, y aunque esto puede ser valioso para confirmar la identidad del remitente al remitente, por las razones descritas anteriormente, es potencialmente peligroso, requiriendo que el usuario extreme la prudencia con el contenido del documento.
El sistema preferido proporciona un medio para controlar la firma de mensajes de salida, de acuerdo con los datos de directivas. En la Figura 24 se muestran datos de directivas de ejemplo. Tal control incluye:
forzar que se firme el mensaje;
sugerir al usuario que se firme el mensaje;
sugerir al usuario que NO debe firmarse el mensaje; e
impedir que el mensaje se firme.
Para determinar que acción a tomar, el sistema preferido tiene en cuenta varios factores, incluyendo la naturaleza del contenido del mensaje (incluyendo cualesquiera anexos), la identidad del receptor pretendido y/o su organización, la identidad del remitente, la naturaleza del certificado digital que se está usando (si el mensaje se ha señalizado para firmar), y la naturaleza del certificado digital disponible para firmar el mensaje.
La naturaleza del mensaje puede determinarse explorándolo para una o más palabras clave, o combinaciones de palabras clave, o usando las técnicas de "interrogación del lenguaje natural". De forma similar, la naturaleza de los certificados digitales pretendidos o disponibles puede determinarse por referencia al emisor y tipo de certificado.
La Figura 25 ilustra el funcionamiento de un módulo de expansión para asegurar que un correo electrónico está firmado digitalmente de forma apropiada o no. El modulo se inicia en la etapa S400, en el punto B en el funcionamiento del cliente de correo electrónico ilustrado en la Figura 5. El control pasa a continuación a la etapa de decisión S402 en la que se explora el correo electrónico de salida para ver si se ha marcado ya con la firma. La "firma" real del mensaje no se producirá hasta directamente antes de la transmisión. Si no está marcado para la firma el control pasa a la etapa a S404 donde el módulo consulta a la tabla de búsqueda de Receptores (tabla f) para determinar si el receptor del correo electrónico de salida se ha identificado como uno al cual los correos electrónicos deben firmase digitalmente siempre. Si el Receptor está en la tabla f, entonces el control pasa a la etapa S406 donde se notifica al usuario del cliente de correo electrónico que el correo electrónico no se enviará a menos que se firme digitalmente. Como alternativa, el módulo de expansión puede firmar digitalmente de forma automática el correo electrónico usando el certificado digital del autor del correo electrónico.
Si en la etapa S404, no se encuentra el receptor del correo electrónico de salida en la tabla de búsqueda, entonces el control pasa a la etapa de decisión S408 donde se consulta a continuación la Tabla de Palabras Clave sobre la rama ForzarFirma del árbol de directivas. En el caso de que cualquiera de las palabras clave en la tabla g se encuentre en el texto del correo electrónico o en cualquiera de los anexos del correo electrónico, se requerirá firmar digitalmente el correo electrónico, y el control pasará a la etapa S406 como anteriormente. Se apreciará que las etapas de decisión S404 y S406 corresponden a los comandos de búsqueda para consultar la búsqueda de Receptores y Palabras Clave sobre la rama de ForzarFirma de los datos de directivas.
Tales palabras clave pueden predeterminarse como "Confidencial", "Secreto", "Contrato", "Cotización", "Pedido" y así sucesivamente como se ilustra en la Figura 24.
Si los receptores del correo electrónico no se encuentran en la tabla f, y el correo electrónico no contiene Palabras Clave especificadas en la tabla g, entonces el control pasa a la etapa de decisión S410, correspondiente al comando de búsqueda sobre la rama SugerirFirma de los datos de directivas de ejemplo. En la etapa de decisión S410 se comprueba la dirección del receptor frente a las de la tabla de búsqueda h, para determinar si se aconseja la firma del correo electrónico. Si se encuentra el nombre del receptor en la tabla h, entonces el control pasa a la etapa S412, donde se notifica al usuario del cliente de correo electrónico de la conveniencia de firmar digitalmente el mensaje de correo electrónico de salida. Sin embargo no se requiere al usuario del cliente de correo electrónico para que firme digitalmente el mensaje de correo electrónico y el correo electrónico puede transmitirse a continuación sin firmar si el usuario así lo elige. A continuación de la etapa de decisión S410, si no se encuentra el nombre del receptor en la tabla h, el control pasa a la etapa de decisión S414, donde como antes, se buscan en el texto de correo electrónico varias palabras clave que podrían indicar que contienen datos sensibles y requerir una firma digital. Dependiendo de si el correo electrónico contiene tales palabras clave sensibles, o se notifica al usuario del cliente de correo electrónico en la etapa S412 de la conveniencia de firmar digitalmente el mensaje, o como alternativa, se transmite el mensaje de correo electrónico sin firmar en la etapa S416.
Si en la etapa S402 a continuación de la iniciación del módulo de expansión, se encuentra que el correo electrónico se ha marcado para firmar entonces el control pasa a la etapa de decisión S418. En la etapa de decisión S418 el módulo de expansión consulta la tabla de búsqueda m en la rama DenegarFirma especificada bajo la rama DenegarFirma de los datos de directivas. La tabla m se especifica sobre la rama CertificadosUsados bajo la rama DenegarFirma, y especifica el emisor, tipo, número de certificado o clave de firma del certificado digital que se estimen de interés. En caso de que el certificado digital o clave de firma que se va a usar para firmar el correo electrónico de salida se encuentra en la tabla m, se harán a continuación comprobaciones adicionales como el Receptor y la naturaleza del correo electrónico de salida para determinar si es apropiado firmar el mensaje o no. El control pasa a la etapa S420, donde se comprueba el receptor del correo electrónico de salida frente a la tabla n de Receptores y a continuación a la etapa de decisión S422 donde el texto del correo electrónico y cualesquiera anexos se exploran para varias palabras clave. Si en cualquiera de las etapas de decisión S420 o S422, el receptor o cualquier texto en el mensaje coincide con lo definido en las tablas de búsqueda, el control pasa a la etapa S424 donde se bloquea la transmisión del correo electrónico. El usuario del cliente de correo electrónico puede a continuación volver a la etapa de entrada del texto del correo electrónico, y puede requerir la retransmisión del mensaje sin firmarlo digitalmente.
Si en cualquiera de las etapas S418 o S422 no se encuentra que el certificado o la clave de firma sean de interés, y se no encuentra que el texto del correo electrónico contenga ninguna palabra sensible, el control pasa a la etapa S426 que corresponde a la primera sub-rama sobre la rama SugerirNoFirmar del árbol de datos de directivas. Como para la rama DenegarFirmar del árbol de datos de directivas, las tres etapas de decisión S426, S428 y S430, corresponden con los comandos de búsqueda para comprobar el certificado digital o la clave de firma usada con el correo electrónico, el receptor del correo electrónico de salida y el texto del correo electrónico de salida frente a entradas sensibles predeterminadas en las tablas de búsqueda j, k y l respectivamente. Si en la etapa S426 el certificado usado para firmar el correo electrónico de salida se encuentra que sea de interés, y en cualquiera de las etapas S428 o S430, el receptor o el texto del correo electrónico de salida se encuentra que coincide con las entradas en las tablas de búsqueda especificadas, el control fluirá a la etapa S432 en la que se notificará al usuario del cliente de correo electrónico de la conveniencia de no firmar digitalmente el mensaje de correo electrónico de salida. El usuario sin embargo puede aún ser libre para enviar el mensaje firmado si así lo desea.
Si en cualquiera de las etapas de decisión S426, S428 y S430 no se encuentra ninguna coincidencia entonces del correo electrónico se envía normalmente en la etapa S416.
Aplicaciones de Mensajería Instantánea y de Telefonía
Además de la actividad del buscador y el correo electrónico, aplicaciones adicionales tales como la Mensajería Instantánea (también conocida como "Chat") y las aplicaciones de telefonía digital tales como la "Voz Sobre IP" se están haciendo populares en situaciones de negocios. Las normativas de la Mensajería Instantánea se definen en la RFC 2778 y RFC 2779 y por el grupo de trabajo de IETF SIMPLE. Las normativas de Voz Sobre IP se definen en la recomendación H.323 (1998) de la ITU-T. Muchos aspectos de la presente invención pueden aplicarse a los datos transmitidos y recibidos por tales aplicaciones. La Mensajería Instantánea es conceptualmente similar a una serie de correos electrónicos enviados y recibidos, excepto que la "conversación" se realiza en "directo" con ambas partes presentes desde el principio hasta el fin. Para los propósitos de la presente invención sin embargo los procedimientos son idénticos. La Figura 5 en los dibujos puede representar Mensajería Instantánea reemplazando la palabra "correo electrónico" en las etapas S122, S124, S132 y S134 con la palabra "Mensaje". La descripción del "Servidor de correo electrónico" 95 se reemplaza con la palabra "RetransmisiónMensaje". La realización preferida se dispone de modo que intercepta en los puntos A y B como anteriormente, proporcionando una expansión a la aplicación de Mensajería de Internet, o desarrollando una aplicación de Mensajería Instantánea que contiene la funcionalidad de expansión. Como alternativa, se apreciará que la actividad de interceptar podría producirse en el nivel de protocolo, interceptando los paquetes de la red antes de que dejen la máquina del usuario, o cuando llegan a la máquina del usuario.
La Voz Sobre el Protocolo de Internet (VOIP) es conceptualmente similar a la Mensajería Instantánea, excepto que el contenido de los mensajes consiste de voz digitalizada, que se codifica y se transmite inmediatamente. El análisis del contenido de los mensajes no es práctico, sin embargo el medio para grabar el mensaje y situar controles en el nivel de la "llamada" son viables y se implementan de igual manera, o como una expansión a la aplicación de mensajería de voz, o al nivel del protocolo de red, cualquiera de ellos dentro de la máquina de usuario.
Aunque se ha descrito la implementación del sistema preferido con referencia a los módulos de expansión para aplicaciones existentes, la invención puede implementarse proporcionando buscadores Web, clientes de correo electrónico, aplicaciones de mensajería instantánea o aplicaciones de Voz Sobre IP en las cuales la funcionalidad de los módulos de expansión descritos en este punto esté ya está codificada desde el principio.

Claims (39)

1. Un sistema de gestión de información que comprende:
una pluralidad de estaciones de trabajo adaptadas para su conexión a una red de ordenadores, teniendo cada estación de trabajo una memoria;
una aplicación almacenada en dicha memoria de cada estación de trabajo para recibir mensajes de entrada desde dicha red y para transmitir un mensaje recibido como un menaje de salida a dicha red;
un analizador, integrado dentro de la aplicación, siendo operable dicho analizador junto con los datos de directivas para determinar uno o más detalles completos del mensaje de salida, según se inicia la transmisión del mensaje de salida, y para impedir selectivamente que el mensaje de salida se reenvíe a otro receptor, o emitir una advertencia antes de que el mensaje se reenvíe a otro receptor, en dependencia con las normas definidas en dichos datos de
directivas;
en el que los datos de directivas están definidos de modo centralizado para la pluralidad de estaciones de trabajo, conteniendo normas para determinar uno o mas detalles completos del mensaje de salida, y para controlar la transmisión de dicho mensaje de salida en dependencia con esos detalles.
2. El sistema de la reivindicación 1, en el que los datos de directivas definen una o más palabras clave predeterminadas, y en el que si el analizador determina que el mensaje contiene una o más de las palabras clave predeterminadas o combinaciones de las palabras clave, se impide el reenvío del mensaje a otro receptor o se emite una advertencia antes de que se reenvíe el mensaje.
3. El sistema de la reivindicación 1 ó 2, en el que el analizador es operable para impedir el reenvío de un mensaje a una o más de una lista predeterminada de direcciones o emitir una advertencia antes de que el mensaje se reenvíe a una o más de la lista de direcciones predeterminada.
4. El sistema de cualquiera de las reivindicaciones anteriores, en el que el analizador es operable para determinar, como uno o más de los detalles del mensaje saliente, los receptores del mensaje recibido a los que se va a transmitir como mensaje de salida.
5. El sistema de la reivindicación 4, en el que el analizador es operable para impedir que se reenvíe un mensaje a una dirección fuera de un grupo predeterminado de direcciones, o emitir una advertencia antes de reenviar el mensaje, si anteriormente el mensaje sólo se ha transmitido entre el grupo predeterminado de direcciones.
6. El sistema de la reivindicación 4 ó 5, en el que el analizador es operable para impedir el reenvío de un mensaje o emitir una advertencia antes de reenviar el mensaje, si el receptor que reenvía el mensaje fue el único receptor del mensaje original.
7. El sistema de cualquiera de las reivindicaciones anteriores, en el que el mensaje recibido tiene uno o más atributos configurables por el remitente del mensaje, siendo uno de esos atributos un atributo de "no reenviar", y el analizador es operable para impedir que un mensaje recibido se reenvíe como un mensaje de salida si el remitente del mensaje recibido fijó el atributo de "no reenviar".
8. El sistema de cualquiera de las reivindicaciones anteriores, en el que el analizador es operable además para producir que el mensaje saliente que se va a reenviar se redirija en primer lugar a una tercera parte para su aprobación, en el que si la tercera parte da su aprobación, el mensaje de salida se reenvía a los receptores pretendidos originalmente en el modo normal.
9. El sistema de cualquiera de las reivindicaciones anteriores, en el que dicha aplicación es un cliente de correo electrónico.
10. El sistema de la reivindicación 9, en el que dicho analizador es un módulo de expansión (74) de dicho cliente de correo electrónico.
11. El sistema de la reivindicación 10, en el que dicho cliente de correo electrónico es el cliente de correo electrónico Outlook de Microsoft y dicho analizador es una extensión del cliente Exchange de Microsoft.
12. El sistema de cualquiera de las reivindicaciones anteriores, en el que los datos de directivas definen una o más directivas para usuarios individuales o grupos de usuarios de las estaciones de trabajo.
13. El sistema de de cualquiera de las reivindicaciones anteriores que comprende un servidor central en el cual se almacenan los datos de las directivas.
\newpage
14. Un método para gestionar información que comprende las etapas de:
proporcionar una pluralidad de estaciones de trabajo adaptadas para su conexión a una red de ordenadores, teniendo cada estación de trabajo una memoria;
proporcionar una aplicación almacenada en dicha memoria de cada estación de trabajo para recibir mensajes de entrada desde dicha red y para transmitir un mensaje recibido como un menaje de salida a dicha red;
analizar por medio de un analizador, integrado dentro de la aplicación, dicho menaje de salida junto con dichos datos de directivas, para determinar uno o más detalles completos de dicho mensaje de salida según se inicia la transmisión del mensaje de salida; e
impedir selectivamente que el mensaje de salida se reenvíe a otro receptor, o emitir una advertencia antes de que el mensaje de salida se reenvíe a otro receptor, en dependencia con las normas definidas en dichos datos de directivas y en dependencia con dichos uno o más detalles completos;
en el que los datos de directivas están definidos de modo centralizado para la pluralidad de estaciones de trabajo, contiendo normas para determinar uno o mas detalles del mensaje de salida, y para controlar la transmisión de dicho mensaje de salida en dependencia con esos detalles.
15. El método de la reivindicación 14, en el que los datos de directivas definen una o más palabras clave predeterminadas, y en el que si se determina en la etapa de analizar que el mensaje contiene una o más de las palabras clave predeterminadas o combinaciones de las palabras clave, se impide el reenvío del mensaje a otro receptor o se emite una advertencia antes de que se reenvíe el mensaje.
16. El método de las reivindicaciones 14 ó 15, en el que se impide el reenvío del mensaje de salida, o se emite una advertencia antes del reenvío del mensaje de salida, si se determina que el mensaje de salida se va a reenviar a una o más de una lista predeterminada de direcciones.
17. El método cualquiera de las reivindicación 14 a 16, que comprende determinar, como uno o más de los detalles del mensaje de salida, los receptores del mensaje recibido que se va a transmitir como mensaje de salida.
18. El método de la reivindicación 17, en el que se impide el reenvío de un mensaje de salida, o se emite una advertencia antes de reenviar el mensaje de salida, si se determina que el mensaje de salida se va a reenviar a una dirección fuera de un grupo de direcciones predeterminado, y que anteriormente el mensaje sólo se transmitió entre ese grupo predeterminado de direcciones.
19. El método de la reivindicación 17 ó 18, en el que se impide el reenvío del mensaje de salida, o se emite una advertencia antes de reenviar el mensaje de salida, si se determina que el receptor que reenvía el mensaje de salida fue el único receptor del mensaje recibido.
20. El método cualquiera de las reivindicación 14 a 19, en el que el mensaje recibido tiene uno o más atributos configurables por el remitente del mensaje, siendo uno de esos atributos un atributo de "no reenviar", y se impide el reenvío del mensaje de salida, si se determina que el remitente del mensaje recibido fijó el atributo de "no reenviar".
21. El método de cualquiera de las reivindicaciones 14 a 20, que comprende causar que el mensaje de salida que se va a reenviar se redirija en primer lugar a una tercera parte para su aprobación, en el que si la tercera parte da su aprobación, el mensaje de salida se reenvía a los receptores pretendidos originalmente en el modo normal.
22. El método cualquiera de las reivindicación 14 a 21, en el que dicha aplicación es un cliente de correo electrónico.
23. El método de la reivindicación 22, en el que dicha etapa de analizar se realiza por un módulo de expansión (74) de dicho cliente de correo electrónico.
24. El método de la reivindicación 23, en el que dicho cliente de correo electrónico es el cliente de correo electrónico Outlook de Microsoft y dicho módulo de expansión es una extensión del cliente Exchange de Microsoft.
25. El método de cualquiera de las reivindicación 14 a 24, en el que los datos de directivas definen una o más directivas para usuarios individuales o grupos de usuarios de las estaciones de trabajo.
26. El método de cualquiera de las reivindicación 14 a 25, que comprende proporcionar un servidor central sobre el cual se almacenan los datos de las directivas.
27. Un producto software de ordenador, para controlar un ordenador en una pluralidad de estaciones de trabajo para gestionar información, estando conectado dicho ordenador a la red y teniendo acceso a los datos de directivas definidos de forma central para la pluralidad de estaciones de trabajo, conteniendo los datos de directivas normas para controlar la transmisión de datos de salida a la red, comprendiendo un medio de grabación legible por el ordenador, que tiene grabado sobre el mismo un código de programa que cuando se ejecuta sobre dicho ordenador configura el ordenador para:
analizar, por medio de una analizador integrado dentro de una aplicación que está corriendo sobre dicho ordenador y que es operable para transmitir mensajes de salida a dicha red y recibir mensajes de entrada desde dicha red, dichos mensajes de salida para determinar junto con dichas normas de dichos datos de directivas uno o más detalles completos de dicho mensaje de salida según se inicia la transmisión del mensaje de salida; e
impedir selectivamente que el mensaje de salida se reenvíe a otro receptor, o emitir una advertencia antes de que el mensaje se reenvíe a otro receptor, en dependencia con las reglas definidas en dichos datos de directivas.
28. El producto software de ordenador de la reivindicación 27, en el que los datos de directivas definen una o más palabras clave predeterminadas, y en el que si se determina que el mensaje contiene una o más de las palabras clave predeterminadas o combinaciones de las palabras clave, se impide el reenvío del mensaje a otro receptor o se emite una advertencia antes de que se reenvíe el mensaje.
29. El producto software de ordenador de la reivindicación 27 ó 28, en el que el código de programa es operable para impedir que se reenvíe un mensaje a una o más de una lista predeterminada de direcciones, o emitir una advertencia antes de reenviar el mensaje a una o más de la lista de direcciones predeterminada.
30. El producto software de ordenador de cualquiera de las reivindicaciones 27 a 29, en el que el código de programa es operable para determinar, como uno o más de los detalles del mensaje saliente, los receptores del mensaje recibido que se va a transmitir como mensaje de salida.
31. El producto software de ordenador de la reivindicación 30, en el que el código de programa es operable para impedir que se reenvíe un mensaje a una dirección fuera de un grupo predeterminado de direcciones, o emitir una advertencia antes de reenviar el mensaje, si anteriormente el mensaje sólo se ha transmitido entre el grupo predeterminado de direcciones.
32. El producto software de ordenador de la reivindicación 30 ó 31, en el que el código de programa es operable para impedir que se reenvíe un mensaje o emitir una advertencia antes de reenviar el mensaje, si el receptor que reenvía el mensaje fue el único receptor del mensaje original.
33. El producto software de ordenador de cualquiera de las reivindicaciones 27 a 32, en el que el mensaje recibido tiene uno o más atributos configurables por el remitente del mensaje siendo uno de esos atributos el atributo de "no reenviar", y el código de programa es operable para impedir que se reenvíe un mensaje recibido como mensaje de salida si el remitente del mensaje fijó el atributo de "no reenviar".
34. El producto software de ordenador de cualquiera de las reivindicaciones 27 a 33, en el que el código de programa es operable además para causar que el mensaje de salida que se va a reenviar se redirija en primer lugar a una tercera parte para su aprobación, en el que si la tercera parte da su aprobación, el mensaje de salida se reenvía a los receptores originalmente pretendidos en el modo normal.
35. El producto de programa de ordenador de cualquiera de las reivindicaciones 27 a 34, en el que dicha aplicación es un cliente de correo electrónico.
36. El producto de programa de ordenador de la reivindicación 35, en el que dicho código de programa cuando se ejecuta sobre dicho ordenador es un módulo de expansión de dicho cliente de correo electrónico.
37. El producto de programa de ordenador de la reivindicación 36, en el que el dicho cliente de correo electrónico es el cliente de correo electrónico Outlook de Microsoft y dicho módulo de expansión es una extensión del cliente Exchange de Microsoft.
38. El producto software de ordenador de cualquiera de las reivindicaciones 27 a 37, en el que los datos de directivas definen una o más directivas para usuarios individuales o grupos de usuarios de las estaciones de trabajo.
39. El producto software de ordenador de cualquiera de las reivindicaciones 27 a 38, en el que los datos de las directivas se almacenan sobre un servidor central.
ES03077587T 2000-11-08 2001-11-08 Un sistema de gestion de la informacion. Expired - Lifetime ES2299666T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0027280 2000-11-08
GBGB0027280.7A GB0027280D0 (en) 2000-11-08 2000-11-08 An information management system
US09/923,704 US7333956B2 (en) 2000-11-08 2001-08-07 Information management system
US923704 2001-08-07

Publications (1)

Publication Number Publication Date
ES2299666T3 true ES2299666T3 (es) 2008-06-01

Family

ID=9902787

Family Applications (5)

Application Number Title Priority Date Filing Date
ES01980761T Expired - Lifetime ES2299521T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077587T Expired - Lifetime ES2299666T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077570T Expired - Lifetime ES2299664T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077588T Expired - Lifetime ES2299667T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077585T Expired - Lifetime ES2299665T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES01980761T Expired - Lifetime ES2299521T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.

Family Applications After (3)

Application Number Title Priority Date Filing Date
ES03077570T Expired - Lifetime ES2299664T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077588T Expired - Lifetime ES2299667T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.
ES03077585T Expired - Lifetime ES2299665T3 (es) 2000-11-08 2001-11-08 Un sistema de gestion de la informacion.

Country Status (12)

Country Link
US (13) US7333956B2 (es)
EP (9) EP1376435B1 (es)
JP (5) JP4354182B2 (es)
AT (9) ATE377810T1 (es)
AU (2) AU1254902A (es)
CA (9) CA2565949A1 (es)
DE (9) DE60131300T2 (es)
DK (5) DK1360623T3 (es)
ES (5) ES2299521T3 (es)
GB (1) GB0027280D0 (es)
WO (1) WO2002039331A2 (es)
ZA (9) ZA200403539B (es)

Families Citing this family (328)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981028B1 (en) * 2000-04-28 2005-12-27 Obongo, Inc. Method and system of implementing recorded data for automating internet interactions
US8972590B2 (en) * 2000-09-14 2015-03-03 Kirsten Aldrich Highly accurate security and filtering software
FR2815204B1 (fr) * 2000-10-10 2003-01-10 Gemplus Card Int Procede de protection contre la fraude dans un reseau par choix d'une icone
GB0027280D0 (en) * 2000-11-08 2000-12-27 Malcolm Peter An information management system
US7346928B1 (en) * 2000-12-01 2008-03-18 Network Appliance, Inc. Decentralized appliance virus scanning
US7778981B2 (en) * 2000-12-01 2010-08-17 Netapp, Inc. Policy engine to control the servicing of requests received by a storage server
US6912582B2 (en) * 2001-03-30 2005-06-28 Microsoft Corporation Service routing and web integration in a distributed multi-site user authentication system
US7178024B2 (en) * 2001-04-05 2007-02-13 Sap Ag Security service for an electronic marketplace
US8095597B2 (en) 2001-05-01 2012-01-10 Aol Inc. Method and system of automating data capture from electronic correspondence
EP1410296A2 (en) * 2001-06-12 2004-04-21 Research In Motion Limited Method for processing encoded messages for exchange with a mobile data communication device
US7546453B2 (en) 2001-06-12 2009-06-09 Research In Motion Limited Certificate management and transfer system and method
EP2112625A3 (en) 2001-06-12 2010-03-10 Research in Motion Methods for pre-processing and rearranging secure E-mail for exchange with a mobile data communication device
US8725549B2 (en) * 2001-08-13 2014-05-13 Geologics Corporation System and business method for work-flow review and management
US20030037116A1 (en) * 2001-08-15 2003-02-20 Nolan Brendan Paul System and method for the analysis of email traffic
ATE368900T1 (de) * 2001-09-21 2007-08-15 Koninkl Kpn Nv Computersystem, datenübertragungsnetz, computerprogramm und datenträger, alle zur filterung von einen inhalt gemäss einer markierungssprache einschliessenden nachrichten
US7565683B1 (en) 2001-12-12 2009-07-21 Weiqing Huang Method and system for implementing changes to security policies in a distributed security system
US7921284B1 (en) 2001-12-12 2011-04-05 Gary Mark Kinghorn Method and system for protecting electronic data in enterprise environment
USRE41546E1 (en) 2001-12-12 2010-08-17 Klimenty Vainstein Method and system for managing security tiers
US8006280B1 (en) 2001-12-12 2011-08-23 Hildebrand Hal S Security system for generating keys from access rules in a decentralized manner and methods therefor
US8065713B1 (en) 2001-12-12 2011-11-22 Klimenty Vainstein System and method for providing multi-location access management to secured items
US7178033B1 (en) 2001-12-12 2007-02-13 Pss Systems, Inc. Method and apparatus for securing digital assets
US10360545B2 (en) 2001-12-12 2019-07-23 Guardian Data Storage, Llc Method and apparatus for accessing secured electronic data off-line
US7681034B1 (en) 2001-12-12 2010-03-16 Chang-Ping Lee Method and apparatus for securing electronic data
US10033700B2 (en) 2001-12-12 2018-07-24 Intellectual Ventures I Llc Dynamic evaluation of access rights
US7380120B1 (en) 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7930756B1 (en) 2001-12-12 2011-04-19 Crocker Steven Toye Multi-level cryptographic transformations for securing digital assets
US7921288B1 (en) 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7783765B2 (en) 2001-12-12 2010-08-24 Hildebrand Hal S System and method for providing distributed access control to secured documents
US7260555B2 (en) 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7950066B1 (en) 2001-12-21 2011-05-24 Guardian Data Storage, Llc Method and system for restricting use of a clipboard application
US7318238B2 (en) * 2002-01-14 2008-01-08 Microsoft Corporation Security settings for markup language elements
FI119454B (fi) * 2002-02-04 2008-11-14 Nokia Corp Menetelmä ja järjestelmä digitaalisen tallenteen käyttämiseksi päätelaitteessa ja päätelaite
US8176334B2 (en) 2002-09-30 2012-05-08 Guardian Data Storage, Llc Document security system that permits external users to gain access to secured files
FI20020367A0 (fi) * 2002-02-26 2002-02-26 Nokia Corp Jaetun verkkosolmun konfiguraation hallinta
US8566698B1 (en) * 2002-03-05 2013-10-22 Hyland Software, Inc. Document management system and method
US9092788B2 (en) * 2002-03-07 2015-07-28 Compete, Inc. System and method of collecting and analyzing clickstream data
US8095589B2 (en) 2002-03-07 2012-01-10 Compete, Inc. Clickstream analysis methods and systems
US9129032B2 (en) * 2002-03-07 2015-09-08 Compete, Inc. System and method for processing a clickstream in a parallel processing architecture
US10296919B2 (en) 2002-03-07 2019-05-21 Comscore, Inc. System and method of a click event data collection platform
US20080189408A1 (en) 2002-10-09 2008-08-07 David Cancel Presenting web site analytics
CA2642320A1 (en) * 2002-03-20 2003-09-25 Research In Motion Limited System and method for supporting multiple certificate status providers on a mobile communication device
GB0206552D0 (en) * 2002-03-20 2002-05-01 Koninkl Philips Electronics Nv Computer systems and a related method for enabling a prospective buyer to browse a vendor's webside to purchase goods or services
US8423763B2 (en) * 2002-03-20 2013-04-16 Research In Motion Limited System and method for supporting multiple certificate status providers on a mobile communication device
CN1672380B (zh) 2002-03-20 2010-08-18 捷讯研究有限公司 用于检验数字证书状态的系统和方法
CN100563242C (zh) * 2002-03-20 2009-11-25 捷讯研究有限公司 证书信息存储系统和方法
US7234158B1 (en) 2002-04-01 2007-06-19 Microsoft Corporation Separate client state object and user interface domains
US8613102B2 (en) 2004-03-30 2013-12-17 Intellectual Ventures I Llc Method and system for providing document retention using cryptography
US7523490B2 (en) * 2002-05-15 2009-04-21 Microsoft Corporation Session key security protocol
US7356711B1 (en) * 2002-05-30 2008-04-08 Microsoft Corporation Secure registration
WO2003102798A1 (en) * 2002-05-30 2003-12-11 America Online Incorporated Intelligent client-side form filler
US8271778B1 (en) * 2002-07-24 2012-09-18 The Nielsen Company (Us), Llc System and method for monitoring secure data on a network
US7107422B2 (en) 2002-08-23 2006-09-12 International Business Machines Corporation Method, computer program product, and system for global refresh of cached user security profiles
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US7673344B1 (en) * 2002-09-18 2010-03-02 Symantec Corporation Mechanism to search information content for preselected data
US7444522B1 (en) * 2002-09-18 2008-10-28 Open Invention Network, Llc Dynamic negotiation of security arrangements between web services
US7886359B2 (en) * 2002-09-18 2011-02-08 Symantec Corporation Method and apparatus to report policy violations in messages
US7472114B1 (en) * 2002-09-18 2008-12-30 Symantec Corporation Method and apparatus to define the scope of a search for information from a tabular data source
US8661498B2 (en) 2002-09-18 2014-02-25 Symantec Corporation Secure and scalable detection of preselected data embedded in electronically transmitted messages
US8041719B2 (en) * 2003-05-06 2011-10-18 Symantec Corporation Personal computing device-based mechanism to detect preselected data
US8225371B2 (en) * 2002-09-18 2012-07-17 Symantec Corporation Method and apparatus for creating an information security policy based on a pre-configured template
US7117528B1 (en) 2002-10-24 2006-10-03 Microsoft Corporation Contested account registration
US7836310B1 (en) 2002-11-01 2010-11-16 Yevgeniy Gutnik Security system that uses indirect password-based encryption
US7136856B2 (en) * 2002-12-04 2006-11-14 International Business Machines Corporation Multi-level security profile refresh
US6928526B1 (en) * 2002-12-20 2005-08-09 Datadomain, Inc. Efficient data storage system
US7334013B1 (en) 2002-12-20 2008-02-19 Microsoft Corporation Shared services management
US7890990B1 (en) 2002-12-20 2011-02-15 Klimenty Vainstein Security system with staging capabilities
FR2849233B1 (fr) * 2002-12-24 2005-05-20 Trusted Logic Procede de securisation des systemes informatiques par confinement logiciel
DE10300609A1 (de) * 2003-01-10 2004-07-29 Wincor Nixdorf International Gmbh Rückwirkungsfreie Geräteschnittstelle
US7685631B1 (en) * 2003-02-05 2010-03-23 Microsoft Corporation Authentication of a server by a client to prevent fraudulent user interfaces
US8098809B2 (en) 2003-02-11 2012-01-17 Computer Associates Think, Inc. System and method for self-supporting applications
US7624277B1 (en) 2003-02-25 2009-11-24 Microsoft Corporation Content alteration for prevention of unauthorized scripts
US7606915B1 (en) 2003-02-25 2009-10-20 Microsoft Corporation Prevention of unauthorized scripts
JP4346326B2 (ja) * 2003-02-27 2009-10-21 富士通株式会社 セキュリティシステム、情報管理システム、暗号化支援システム、およびコンピュータプログラム
US7856477B2 (en) * 2003-04-04 2010-12-21 Yahoo! Inc. Method and system for image verification to prevent messaging abuse
US7360092B1 (en) 2003-04-28 2008-04-15 Microsoft Corporation Marking and identifying web-based authentication forms
US8707034B1 (en) 2003-05-30 2014-04-22 Intellectual Ventures I Llc Method and system for using remote headers to secure electronic files
US7814128B2 (en) 2003-05-30 2010-10-12 Symantec Operating Corporation Multi-volume file support
US20050071630A1 (en) * 2003-08-15 2005-03-31 Imcentric, Inc. Processing apparatus for monitoring and renewing digital certificates
US7890585B2 (en) * 2003-09-03 2011-02-15 Lowe John C Second person review of email
US7703140B2 (en) 2003-09-30 2010-04-20 Guardian Data Storage, Llc Method and system for securing digital assets using process-driven security policies
US8127366B2 (en) 2003-09-30 2012-02-28 Guardian Data Storage, Llc Method and apparatus for transitioning between states of security policies used to secure electronic documents
US20050080861A1 (en) * 2003-10-14 2005-04-14 Daniell W. Todd Selectively displaying email folders
US7895094B2 (en) * 2003-12-15 2011-02-22 American Express Travel Related Services Company, Inc. Global account reconciliation tool
US8600845B2 (en) 2006-10-25 2013-12-03 American Express Travel Related Services Company, Inc. System and method for reconciling one or more financial transactions
US9191215B2 (en) * 2003-12-30 2015-11-17 Entrust, Inc. Method and apparatus for providing authentication using policy-controlled authentication articles and techniques
US20050154878A1 (en) * 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
WO2005070116A2 (en) * 2004-01-09 2005-08-04 Corestreet, Ltd. Communication-efficient real time credentials for ocsp and distributed ocsp
US7490242B2 (en) 2004-02-09 2009-02-10 International Business Machines Corporation Secure management of authentication information
US9589117B2 (en) * 2004-02-17 2017-03-07 Hewlett-Packard Development Company, L.P. Computer security system and method
US7293034B2 (en) 2004-02-23 2007-11-06 Microsoft Coporation Dynamically customizing a user interface for the aggregation of content
US20050193197A1 (en) * 2004-02-26 2005-09-01 Sarvar Patel Method of generating a cryptosync
US8583739B2 (en) 2004-03-02 2013-11-12 International Business Machines Corporation Facilitating the sending of mail from a restricted communications network
US7636941B2 (en) * 2004-03-10 2009-12-22 Microsoft Corporation Cross-domain authentication
US8140489B2 (en) * 2004-03-24 2012-03-20 Oracle International Corporation System and method for analyzing content on a web page using an embedded filter
US7437551B2 (en) * 2004-04-02 2008-10-14 Microsoft Corporation Public key infrastructure scalability certificate revocation status validation
ATE450950T1 (de) * 2004-04-30 2009-12-15 Research In Motion Ltd System und verfahren zur prüfung digitaler zertifikate
DE602005014225D1 (de) * 2004-04-30 2009-06-10 Research In Motion Ltd System und verfahren zum administrieren einer digitalen zertifikatprüfung
US8769671B2 (en) * 2004-05-02 2014-07-01 Markmonitor Inc. Online fraud solution
US8041769B2 (en) * 2004-05-02 2011-10-18 Markmonitor Inc. Generating phish messages
US7870608B2 (en) * 2004-05-02 2011-01-11 Markmonitor, Inc. Early detection and monitoring of online fraud
US20070107053A1 (en) * 2004-05-02 2007-05-10 Markmonitor, Inc. Enhanced responses to online fraud
US7457823B2 (en) 2004-05-02 2008-11-25 Markmonitor Inc. Methods and systems for analyzing data related to possible online fraud
US9203648B2 (en) * 2004-05-02 2015-12-01 Thomson Reuters Global Resources Online fraud solution
US7913302B2 (en) * 2004-05-02 2011-03-22 Markmonitor, Inc. Advanced responses to online fraud
EP1605330A1 (en) * 2004-06-11 2005-12-14 ARM Limited Secure operation indicator
US8234339B2 (en) 2004-06-21 2012-07-31 Research In Motion Limited System and method for handling electronic messages
US8484295B2 (en) * 2004-12-21 2013-07-09 Mcafee, Inc. Subscriber reputation filtering method for analyzing subscriber activity and detecting account misuse
US7953814B1 (en) 2005-02-28 2011-05-31 Mcafee, Inc. Stopping and remediating outbound messaging abuse
US7386752B1 (en) 2004-06-30 2008-06-10 Symantec Operating Corporation Using asset dependencies to identify the recovery set and optionally automate and/or optimize the recovery
US7360110B1 (en) 2004-06-30 2008-04-15 Symantec Operating Corporation Parameterization of dimensions of protection systems and uses thereof
US8261122B1 (en) 2004-06-30 2012-09-04 Symantec Operating Corporation Estimation of recovery time, validation of recoverability, and decision support using recovery metrics, targets, and objectives
US7360123B1 (en) 2004-06-30 2008-04-15 Symantec Operating Corporation Conveying causal relationships between at least three dimensions of recovery management
US7836448B1 (en) * 2004-06-30 2010-11-16 Emc Corporation System and methods for task management
US7325161B1 (en) 2004-06-30 2008-01-29 Symantec Operating Corporation Classification of recovery targets to enable automated protection setup
US7707427B1 (en) 2004-07-19 2010-04-27 Michael Frederick Kenrich Multi-level file digests
US20060036849A1 (en) * 2004-08-09 2006-02-16 Research In Motion Limited System and method for certificate searching and retrieval
US9094429B2 (en) 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US7549043B2 (en) * 2004-09-01 2009-06-16 Research In Motion Limited Providing certificate matching in a system and method for searching and retrieving certificates
US7631183B2 (en) * 2004-09-01 2009-12-08 Research In Motion Limited System and method for retrieving related certificates
US7640428B2 (en) 2004-09-02 2009-12-29 Research In Motion Limited System and method for searching and retrieving certificates
GB0419889D0 (en) * 2004-09-08 2004-10-13 Ibm Accessing a data item in a memory of a computer system
US7607006B2 (en) * 2004-09-23 2009-10-20 International Business Machines Corporation Method for asymmetric security
US7644266B2 (en) * 2004-09-23 2010-01-05 International Business Machines Corporation Apparatus, system, and method for message level security
JP2006094241A (ja) * 2004-09-24 2006-04-06 Fuji Xerox Co Ltd 暗号化装置、暗号化処理方法及びプログラム、並びに該暗号化装置を用いた情報保護システム
US20060070126A1 (en) * 2004-09-26 2006-03-30 Amiram Grynberg A system and methods for blocking submission of online forms.
NL1027274C2 (nl) * 2004-10-18 2006-04-19 Ebuzon B V Werkwijze en systeem voor het via een netwerk verzenden van elektronische post.
US7886144B2 (en) * 2004-10-29 2011-02-08 Research In Motion Limited System and method for retrieving certificates associated with senders of digitally signed messages
US7716139B2 (en) * 2004-10-29 2010-05-11 Research In Motion Limited System and method for verifying digital signatures on certificates
US9015472B1 (en) 2005-03-10 2015-04-21 Mcafee, Inc. Marking electronic messages to indicate human origination
US9160755B2 (en) * 2004-12-21 2015-10-13 Mcafee, Inc. Trusted communication network
US20140068409A1 (en) * 2004-12-21 2014-03-06 Signaturelink, Inc. Systems and Methods for Capturing Real Time Client Side Data and For Generating a Permanent Record
US8738708B2 (en) * 2004-12-21 2014-05-27 Mcafee, Inc. Bounce management in a trusted communication network
JP4695388B2 (ja) 2004-12-27 2011-06-08 株式会社リコー セキュリティ情報推定装置、セキュリティ情報推定方法、セキュリティ情報推定プログラム及び記録媒体
US7620974B2 (en) * 2005-01-12 2009-11-17 Symantec Distributed traffic scanning through data stream security tagging
US20090171847A2 (en) * 2005-01-24 2009-07-02 Microsoft Corporation Multi-merchant purchasing environment for downloadable products
US7548889B2 (en) * 2005-01-24 2009-06-16 Microsoft Corporation Payment information security for multi-merchant purchasing environment for downloadable products
US7617532B1 (en) * 2005-01-24 2009-11-10 Symantec Corporation Protection of sensitive data from malicious e-mail
US20060167811A1 (en) * 2005-01-24 2006-07-27 Microsoft Corporation Product locker for multi-merchant purchasing environment for downloadable products
US20060184549A1 (en) * 2005-02-14 2006-08-17 Rowney Kevin T Method and apparatus for modifying messages based on the presence of pre-selected data
US8011003B2 (en) 2005-02-14 2011-08-30 Symantec Corporation Method and apparatus for handling messages containing pre-selected data
US20060212696A1 (en) * 2005-03-17 2006-09-21 Bustelo Leugim A Method and system for selective information delivery in a rich client form
HU0500314D0 (en) * 2005-03-18 2005-05-30 Fon Telekommunikacios Kft B V Method and device for achieving and checking telephone calls, in particular to penitentiaries, prisons
US7743254B2 (en) * 2005-03-23 2010-06-22 Microsoft Corporation Visualization of trust in an address bar
JP4158927B2 (ja) * 2005-03-25 2008-10-01 インターナショナル・ビジネス・マシーンズ・コーポレーション 情報提示装置、情報提示方法、プログラム
US7353034B2 (en) 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
JP2006303963A (ja) * 2005-04-21 2006-11-02 Internatl Business Mach Corp <Ibm> 情報を管理するシステム、方法およびプログラム
WO2006116427A2 (en) * 2005-04-26 2006-11-02 Boloto Group, Inc. Creating or maintaining relationships within a private network or virtual private network of servers and clients
US9384345B2 (en) 2005-05-03 2016-07-05 Mcafee, Inc. Providing alternative web content based on website reputation assessment
US7562304B2 (en) 2005-05-03 2009-07-14 Mcafee, Inc. Indicating website reputations during website manipulation of user information
US8566726B2 (en) * 2005-05-03 2013-10-22 Mcafee, Inc. Indicating website reputations based on website handling of personal information
US8438499B2 (en) 2005-05-03 2013-05-07 Mcafee, Inc. Indicating website reputations during user interactions
US8078740B2 (en) 2005-06-03 2011-12-13 Microsoft Corporation Running internet applications with low rights
US10021062B2 (en) * 2005-07-01 2018-07-10 Cirius Messaging Inc. Secure electronic mail system
US20070028301A1 (en) * 2005-07-01 2007-02-01 Markmonitor Inc. Enhanced fraud monitoring systems
US8682979B2 (en) * 2005-07-01 2014-03-25 Email2 Scp Solutions Inc. Secure electronic mail system
JP4595728B2 (ja) * 2005-07-26 2010-12-08 富士ゼロックス株式会社 電子メール送信装置、プログラム、インターネットファックス送信装置、スキャン画像開示装置及び送信装置
US7756932B2 (en) * 2005-07-29 2010-07-13 Research In Motion Limited System and method for processing messages being composed by a user
EP1927060B1 (en) 2005-08-09 2019-10-09 Nexsan Technologies Canada Inc. Data archiving method and system
WO2007021868A2 (en) * 2005-08-10 2007-02-22 Compete, Inc. Presentation of media segments
US9105028B2 (en) 2005-08-10 2015-08-11 Compete, Inc. Monitoring clickstream behavior of viewers of online advertisements and search results
US20070047726A1 (en) * 2005-08-25 2007-03-01 Cisco Technology, Inc. System and method for providing contextual information to a called party
US7797545B2 (en) * 2005-09-29 2010-09-14 Research In Motion Limited System and method for registering entities for code signing services
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US20070083918A1 (en) * 2005-10-11 2007-04-12 Cisco Technology, Inc. Validation of call-out services transmitted over a public switched telephone network
US8572389B2 (en) * 2005-10-14 2013-10-29 Blackberry Limited System and method for protecting master encryption keys
US7953971B2 (en) * 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US7730187B2 (en) * 2006-10-05 2010-06-01 Limelight Networks, Inc. Remote domain name service
ATE396576T1 (de) * 2005-11-23 2008-06-15 Research In Motion Ltd E-mail mit sicheren nachrichtenteilen
US7987511B2 (en) 2005-11-23 2011-07-26 Research In Motion Limited E-mail with secure message parts
US8243895B2 (en) * 2005-12-13 2012-08-14 Cisco Technology, Inc. Communication system with configurable shared line privacy feature
US8005459B2 (en) * 2005-12-16 2011-08-23 Research In Motion Limited System and method of authenticating login credentials in a wireless communication system
US8244745B2 (en) * 2005-12-29 2012-08-14 Nextlabs, Inc. Analyzing usage information of an information management system
WO2007095157A2 (en) 2006-02-10 2007-08-23 Fair Isaac Corporation Consumer-driven secure sockets layer modulator
US8503621B2 (en) * 2006-03-02 2013-08-06 Cisco Technology, Inc. Secure voice communication channel for confidential messaging
US8468595B1 (en) * 2006-03-22 2013-06-18 Trend Micro Incorporated Content filtering prior to data encryption
US7912908B2 (en) * 2006-03-27 2011-03-22 Alcatel-Lucent Usa Inc. Electronic message forwarding control
US8701196B2 (en) 2006-03-31 2014-04-15 Mcafee, Inc. System, method and computer program product for obtaining a reputation associated with a file
ATE398884T1 (de) * 2006-04-04 2008-07-15 Mueller Marken Gmbh & Co Betr Automatische verifizierung von messenger- kontaktdaten
US20070274300A1 (en) * 2006-05-04 2007-11-29 Microsoft Corporation Hover to call
US20100017305A1 (en) * 2006-05-31 2010-01-21 Lawrence Edward Strodtman Systems and methods for wine tasting and the marketing of wine, and wine packaging useful therewith
US20070282696A1 (en) * 2006-05-31 2007-12-06 Lawrence Edward Strodtman Systems and methods for wine tasting and the marketing of wine, and wine packaging useful therewith
JP4290179B2 (ja) * 2006-06-15 2009-07-01 キヤノン株式会社 署名検証装置、及び、その制御方法、プログラム、記憶媒体
US8346265B2 (en) * 2006-06-20 2013-01-01 Alcatel Lucent Secure communication network user mobility apparatus and methods
US7814161B2 (en) 2006-06-23 2010-10-12 Research In Motion Limited System and method for handling electronic mail mismatches
US8185737B2 (en) 2006-06-23 2012-05-22 Microsoft Corporation Communication across domains
EP1879135B1 (en) 2006-07-11 2008-11-19 Research In Motion Limited System and method for dynamic modification of allowable electronic message properties
US8396211B2 (en) 2006-07-11 2013-03-12 Research In Motion Limited System and method for dynamic modification of allowable electronic message properties
JP4337853B2 (ja) * 2006-09-04 2009-09-30 コニカミノルタビジネステクノロジーズ株式会社 アプリケーションプログラム配布装置、画像処理装置、及びプログラム
EP1921560A1 (en) * 2006-11-10 2008-05-14 Nokia Siemens Networks Gmbh & Co. Kg Method and system for providing sensitive data
US8687785B2 (en) 2006-11-16 2014-04-01 Cisco Technology, Inc. Authorization to place calls by remote users
US20080133673A1 (en) * 2006-12-04 2008-06-05 Abdelhadi Sanaa F Method and apparatus to control contents in a document
US8423615B1 (en) * 2006-12-06 2013-04-16 Google Inc. System and method for restricting distribution of electronic messages
US7822851B2 (en) 2007-01-18 2010-10-26 Internet Probation and Parole Control, Inc. Remote user computer control and monitoring
US20080189767A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Accessing file resources outside a security boundary
US7870596B2 (en) * 2007-02-01 2011-01-11 Microsoft Corporation Accessing network resources outside a security boundary
US8255696B2 (en) * 2007-05-01 2012-08-28 Microsoft Corporation One-time password access to password-protected accounts
EP1990750A1 (en) * 2007-05-09 2008-11-12 Nokia Siemens Networks Oy Method and device for data processing and communication system comprising such device
US7823761B2 (en) * 2007-05-16 2010-11-02 The Invention Science Fund I, Llc Maneuverable surgical stapler
CA2688762C (en) * 2007-05-17 2016-02-23 Shift4 Corporation Secure payment card transactions
US7891563B2 (en) 2007-05-17 2011-02-22 Shift4 Corporation Secure payment card transactions
US7770789B2 (en) * 2007-05-17 2010-08-10 Shift4 Corporation Secure payment card transactions
US7841523B2 (en) * 2007-05-17 2010-11-30 Shift4 Corporation Secure payment card transactions
US8793801B2 (en) * 2007-05-18 2014-07-29 Goldman, Sachs & Co. Systems and methods to secure restricted information in electronic mail messages
US10019570B2 (en) * 2007-06-14 2018-07-10 Microsoft Technology Licensing, Llc Protection and communication abstractions for web browsers
US9305042B1 (en) * 2007-06-14 2016-04-05 West Corporation System, method, and computer-readable medium for removing credit card numbers from both fixed and variable length transaction records
US8068588B2 (en) * 2007-06-26 2011-11-29 Microsoft Corporation Unified rules for voice and messaging
US8135383B2 (en) * 2007-07-30 2012-03-13 Lsi Corporation Information security and delivery method and apparatus
EP2191599A4 (en) * 2007-08-22 2011-05-18 Ltd Cellocart SECURE ACQUISITION METHOD VIA A CREDIT CARD TERMINAL
US7783666B1 (en) 2007-09-26 2010-08-24 Netapp, Inc. Controlling access to storage resources by using access pattern based quotas
US9087427B2 (en) 2007-09-27 2015-07-21 Wayne Fueling Systems Llc Conducting fuel dispensing transactions
US7975308B1 (en) * 2007-09-28 2011-07-05 Symantec Corporation Method and apparatus to secure user confidential data from untrusted browser extensions
US8656489B1 (en) * 2007-09-29 2014-02-18 Symantec Corporation Method and apparatus for accelerating load-point scanning
US8359355B2 (en) * 2007-10-16 2013-01-22 International Business Machines Corporation System and method for verifying access to content
CN101836212B (zh) * 2007-10-25 2015-10-14 富士通株式会社 信息提供方法、中继方法、信息保持装置、中继器
US8539029B2 (en) 2007-10-29 2013-09-17 Microsoft Corporation Pre-send evaluation of E-mail communications
US9547870B1 (en) * 2007-11-02 2017-01-17 Fair Isaac Corporation System and methods for selective advertising
JP4935658B2 (ja) * 2007-12-11 2012-05-23 ブラザー工業株式会社 ブラウザプログラムおよび情報処理装置
JP4593615B2 (ja) * 2007-12-28 2010-12-08 キヤノンＩｔソリューションズ株式会社 情報処理システム、情報処理方法及びプログラム
US20090182647A1 (en) * 2008-01-15 2009-07-16 Ebay Inc. Systems and methods for enhancing product value metadata
US8250378B1 (en) 2008-02-04 2012-08-21 Crossroads Systems, Inc. System and method for enabling encryption
US20090204812A1 (en) * 2008-02-13 2009-08-13 Baker Todd M Media processing
US20090234851A1 (en) * 2008-03-14 2009-09-17 International Business Machines Corporation Browser Use of Directory Listing for Predictive Type-Ahead
US8065739B1 (en) 2008-03-28 2011-11-22 Symantec Corporation Detecting policy violations in information content containing data in a character-based language
US7996374B1 (en) 2008-03-28 2011-08-09 Symantec Corporation Method and apparatus for automatically correlating related incidents of policy violations
US7996373B1 (en) 2008-03-28 2011-08-09 Symantec Corporation Method and apparatus for detecting policy violations in a data repository having an arbitrary data schema
US8990313B2 (en) 2008-04-01 2015-03-24 Microsoft Technology Licensing, Llc Download of current portions of email messages
US8280963B2 (en) * 2008-04-10 2012-10-02 Microsoft Corporation Caching and exposing pre-send data relating to the sender or recipient of an electronic mail message
US8601258B2 (en) * 2008-05-05 2013-12-03 Kip Cr P1 Lp Method for configuring centralized encryption policies for devices
US8677129B2 (en) * 2008-05-13 2014-03-18 Fair Isaac Corporation Consumer-driven secure sockets layer modulator
US8095604B2 (en) * 2008-06-06 2012-01-10 International Business Machines Corporation Automatically modifying distributed communications
US8756284B2 (en) 2008-06-06 2014-06-17 International Business Machines Corporation Minimizing incorrectly addressed communications when working with ambiguous recipient designations
US8316100B2 (en) * 2008-06-06 2012-11-20 International Business Machines Corporation Autonomic correction of incorrect identities in repositories
US8171088B2 (en) * 2008-06-06 2012-05-01 International Business Machines Corporation Facilitating correction of incorrect identities in propagated electronic communications
US20090313101A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Processing receipt received in set of communications
US8788350B2 (en) * 2008-06-13 2014-07-22 Microsoft Corporation Handling payment receipts with a receipt store
US7523309B1 (en) * 2008-06-27 2009-04-21 International Business Machines Corporation Method of restricting access to emails by requiring multiple levels of user authentication
US8625799B2 (en) * 2008-07-18 2014-01-07 Absolute Software Corporation Privacy management for tracked devices
US8732455B2 (en) 2008-07-25 2014-05-20 Infotect Security Pte Ltd Method and system for securing against leakage of source code
US10354229B2 (en) 2008-08-04 2019-07-16 Mcafee, Llc Method and system for centralized contact management
US8843566B2 (en) * 2008-08-20 2014-09-23 First Data Corporation Securing outbound mail
US8826443B1 (en) 2008-09-18 2014-09-02 Symantec Corporation Selective removal of protected content from web requests sent to an interactive website
US10637832B2 (en) * 2008-09-30 2020-04-28 EMC IP Holding Company LLC Method and apparatus providing a framework for secure information lifecycle
US9569528B2 (en) * 2008-10-03 2017-02-14 Ab Initio Technology Llc Detection of confidential information
US8463897B2 (en) 2008-10-09 2013-06-11 At&T Intellectual Property I, L.P. Systems and methods to emulate user network activity
US8296563B2 (en) * 2008-10-22 2012-10-23 Research In Motion Limited Method of handling a certification request
US8644511B2 (en) 2008-11-05 2014-02-04 Comcast Cable Communications, LLC. System and method for providing digital content
US8613040B2 (en) * 2008-12-22 2013-12-17 Symantec Corporation Adaptive data loss prevention policies
US9444823B2 (en) * 2008-12-24 2016-09-13 Qualcomm Incorporated Method and apparatus for providing network communication association information to applications and services
US8386573B2 (en) * 2008-12-31 2013-02-26 International Business Machines Corporation System and method for caching linked email data for offline use
US8589502B2 (en) * 2008-12-31 2013-11-19 International Business Machines Corporation System and method for allowing access to content
US8935752B1 (en) 2009-03-23 2015-01-13 Symantec Corporation System and method for identity consolidation
US8584251B2 (en) * 2009-04-07 2013-11-12 Princeton Payment Solutions Token-based payment processing system
US9342697B1 (en) * 2009-04-09 2016-05-17 Trend Micro Incorporated Scalable security policy architecture for data leakage prevention
US9397981B2 (en) 2009-04-20 2016-07-19 International Business Machines Corporation Method and system for secure document exchange
DE102009038035A1 (de) * 2009-08-19 2011-02-24 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Konfiguration von Infotainmentanwendungen in einem Kraftfahrzeug
CN102014145A (zh) * 2009-09-04 2011-04-13 鸿富锦精密工业（深圳）有限公司 文件传输安全管控系统及方法
US9268954B2 (en) * 2009-10-07 2016-02-23 Ca, Inc. System and method for role discovery
US8578504B2 (en) * 2009-10-07 2013-11-05 Ca, Inc. System and method for data leakage prevention
US9077543B2 (en) * 2009-10-09 2015-07-07 Apple Inc. Methods and apparatus for digital attestation
JP5521479B2 (ja) * 2009-10-14 2014-06-11 富士通株式会社 プログラム、データ記憶装置及びデータ記憶システム
US8666812B1 (en) * 2009-11-10 2014-03-04 Google Inc. Distributing content based on transaction information
US9443227B2 (en) * 2010-02-16 2016-09-13 Tigertext, Inc. Messaging system apparatuses circuits and methods of operation thereof
US20110219424A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Information protection using zones
US9838349B2 (en) 2010-03-08 2017-12-05 Microsoft Technology Licensing, Llc Zone classification of electronic mail messages
US9406048B2 (en) * 2010-07-07 2016-08-02 Mark Meister Email system for preventing inadvertant transmission of propriety message or documents to unintended recipient
WO2012027385A1 (en) 2010-08-23 2012-03-01 Princeton Payment Solutions Tokenized payment processing schemes
US20120059663A1 (en) * 2010-09-03 2012-03-08 Kate Levesque Methods and apparatus for patient visit workflow
US10164922B2 (en) 2010-09-27 2018-12-25 International Business Machines Corporation Secure electronic message conveyance
US20120079043A1 (en) * 2010-09-27 2012-03-29 Research In Motion Limited Method, apparatus and system for accessing an application across a plurality of computers
US8656453B2 (en) * 2010-11-10 2014-02-18 Software Ag Security systems and/or methods for cloud computing environments
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
US8631460B2 (en) 2011-03-23 2014-01-14 CipherPoint Software, Inc. Systems and methods for implementing transparent encryption
US8627404B2 (en) * 2011-08-24 2014-01-07 Raytheon Company Detecting addition of a file to a computer system and initiating remote analysis of the file for malware
US8930492B2 (en) 2011-10-17 2015-01-06 Blackberry Limited Method and electronic device for content sharing
US8990266B2 (en) 2011-10-18 2015-03-24 CipherPoint Software, Inc. Dynamic data transformations for network transmissions
US8959425B2 (en) 2011-12-09 2015-02-17 Microsoft Corporation Inference-based extension activation
KR101236544B1 (ko) * 2012-01-12 2013-03-15 주식회사 엘지씨엔에스 결제 방법 및 이와 연관된 결제 게이트웨이 서버, 모바일 단말 및 시점 확인서 발행 서버
US9679163B2 (en) 2012-01-17 2017-06-13 Microsoft Technology Licensing, Llc Installation and management of client extensions
US9900395B2 (en) 2012-01-27 2018-02-20 Comscore, Inc. Dynamic normalization of internet traffic
US8954580B2 (en) 2012-01-27 2015-02-10 Compete, Inc. Hybrid internet traffic measurement using site-centric and panel data
US8843822B2 (en) 2012-01-30 2014-09-23 Microsoft Corporation Intelligent prioritization of activated extensions
US9256445B2 (en) 2012-01-30 2016-02-09 Microsoft Technology Licensing, Llc Dynamic extension view with multiple levels of expansion
US9449112B2 (en) 2012-01-30 2016-09-20 Microsoft Technology Licensing, Llc Extension activation for related documents
US20150127771A1 (en) * 2012-05-08 2015-05-07 Nokia Solutions And Networks Oy Method and Apparatus
US8837739B1 (en) * 2012-05-13 2014-09-16 Identillect Technologies, Inc. Encryption messaging system
US10068083B2 (en) * 2012-09-28 2018-09-04 International Business Machines Corporation Secure transport of web form submissions
WO2014061326A1 (ja) * 2012-10-15 2014-04-24 日本電気株式会社 セキュリティ機能設計支援装置、セキュリティ機能設計支援方法、およびプログラム
RU2635874C2 (ru) * 2013-03-04 2017-11-16 Селинко С.А. Способ обеспечения безопасных транзакций электронной коммерции
US9009815B2 (en) 2013-03-15 2015-04-14 International Business Machines Corporation Increasing chosen password strength
US10902081B1 (en) 2013-05-06 2021-01-26 Veeva Systems Inc. System and method for controlling electronic communications
WO2014182712A1 (en) * 2013-05-06 2014-11-13 Veeva Systems Inc. System and method for controlling electronic communications
US10140382B2 (en) 2013-05-06 2018-11-27 Veeva Systems Inc. System and method for controlling electronic communications
US9369488B2 (en) * 2013-05-28 2016-06-14 Globalfoundries Inc. Policy enforcement using natural language processing
US9210139B2 (en) * 2013-06-05 2015-12-08 The Boeing Company Secure relay system
CN104252479B (zh) * 2013-06-27 2018-05-18 华为技术有限公司 信息的处理方法、装置和系统
US10437903B2 (en) * 2013-09-20 2019-10-08 Jesse Lakes Redirection service profiling
WO2015053780A1 (en) * 2013-10-10 2015-04-16 Intel Corporation Anomaly detection on web client
DE102013020742A1 (de) * 2013-12-10 2015-06-11 Tobias Rückert Verfahren und System zur Übermittlung einer elektronischen Nachricht
US20150170084A1 (en) * 2013-12-12 2015-06-18 International Business Machines Corporation Augmenting business process execution using natural language processing
US9338137B1 (en) * 2015-02-13 2016-05-10 AO Kaspersky Lab System and methods for protecting confidential data in wireless networks
US9948633B2 (en) * 2015-10-28 2018-04-17 Citrix Systems, Inc. Systems and methods for policy driven fine grain validation of servers' SSL certificate for clientless SSLVPN access
CN105871584A (zh) * 2015-12-02 2016-08-17 乐视体育文化产业发展（北京）有限公司 一种键值对数据库中的客户端配置更新方法、设备及系统
CN105867837A (zh) * 2015-12-02 2016-08-17 乐视体育文化产业发展（北京）有限公司 一种分布式高速缓存系统中的客户端配置更新方法、设备及系统
US10841262B2 (en) * 2016-01-11 2020-11-17 Etorch, Inc. Client-agnostic and network-agnostic device management
US9559997B1 (en) * 2016-01-11 2017-01-31 Paul Everton Client agnostic email processing
US10979393B2 (en) * 2016-01-11 2021-04-13 Mimecast North America, Inc. Identity-based messaging security
US9824332B1 (en) 2017-04-12 2017-11-21 eTorch Inc. Email data collection compliance enforcement
US11323399B2 (en) * 2016-01-11 2022-05-03 Mimecast North America, Inc. Client-agnostic and network-agnostic device management
JP6677887B2 (ja) * 2016-03-28 2020-04-08 富士通クライアントコンピューティング株式会社 メール配信プログラム、メールサーバ及びメール配信方法
US10091235B1 (en) * 2016-06-07 2018-10-02 Juniper Networks, Inc. Method, system, and apparatus for detecting and preventing targeted attacks
US20180012190A1 (en) * 2016-07-06 2018-01-11 International Business Machines Corporation Automatic inference of meeting attendance
US10867358B2 (en) * 2016-10-28 2020-12-15 Flexiwage Limited Employee determined payroll payment processing method and system
CN106779369B (zh) * 2016-12-03 2020-09-25 安徽中医药大学第一附属医院 一种医院轮转排班方法
US10389743B1 (en) 2016-12-22 2019-08-20 Symantec Corporation Tracking of software executables that come from untrusted locations
US11393046B1 (en) * 2017-01-17 2022-07-19 Intuit Inc. System and method for perpetual rekeying of various data columns with a frequency and encryption strength based on the sensitivity of the data columns
US10303895B1 (en) 2017-01-19 2019-05-28 Intuit Inc. System and method for perpetual rekeying of various data columns with respective encryption keys and on alternating bases
US10127513B1 (en) * 2017-04-28 2018-11-13 Cyara Solutions Pty Ltd Automated multi-channel customer journey testing
WO2019005098A1 (en) * 2017-06-30 2019-01-03 Go Logic Decision Time, Llc METHODS AND SYSTEMS FOR PROJECTIVE ASSERTION SIMULATION
CN109118360B (zh) * 2018-07-19 2021-05-18 中国联合网络通信集团有限公司 区块链对账方法、装置、设备及存储介质
US11190573B2 (en) * 2018-07-25 2021-11-30 Vmware, Inc. Techniques for improving implementation of a remote browser within a local browser
CN109710671B (zh) * 2018-12-14 2023-05-30 国云科技股份有限公司 实现数据库操作数据引流的方法及其数据库防火墙系统
US11399020B2 (en) * 2019-06-28 2022-07-26 HCL Technologies Italy S.p.A System and method for authenticating server identity during connection establishment with client machine
US11100497B2 (en) * 2019-08-20 2021-08-24 Anchor Labs, Inc. Risk mitigation for a cryptoasset custodial system using a hardware security key
WO2021059852A1 (ja) * 2019-09-24 2021-04-01 日本電気株式会社 情報変換装置、情報変換システム、情報変換方法および記録媒体
US11070533B2 (en) * 2019-10-10 2021-07-20 Forcepoint Llc Encrypted server name indication inspection
CN110727670B (zh) * 2019-10-11 2022-08-09 北京小向创新人工智能科技有限公司 基于流程图的数据结构预测传递及自动化数据处理方法
CN113595864B (zh) 2020-04-30 2023-04-18 北京字节跳动网络技术有限公司 一种转发邮件的方法、装置、电子设备及存储介质
US20230205906A1 (en) * 2021-12-28 2023-06-29 Capital One Services, Llc Identification of sensitive content in electronic mail messages to prevent exfiltration

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2041992A1 (en) 1990-05-18 1991-11-19 Yeshayahu Artsy Routing objects on action paths in a distributed computing system
JP2865827B2 (ja) 1990-08-13 1999-03-08 株式会社日立製作所 会議システムにおけるデータ蓄積方法
US5235489A (en) * 1991-06-28 1993-08-10 Sgs-Thomson Microelectronics, Inc. Integrated solution to high voltage load dump conditions
CZ293613B6 (cs) * 1992-01-17 2004-06-16 Westinghouse Electric Corporation Způsob monitorování chodu zařízení pomocí CPU
US5325642A (en) * 1992-01-17 1994-07-05 Cooley Warren L Geodesic hazardous waste containment building
US5235642A (en) 1992-07-21 1993-08-10 Digital Equipment Corporation Access control subsystem and method for distributed computer system using locally cached authentication credentials
US5452099A (en) * 1993-04-12 1995-09-19 Faxguard Systems Corporation Method and system for storage and/or transmission of confidential facsimile documents
JPH07154615A (ja) 1993-11-26 1995-06-16 Mita Ind Co Ltd ファクシミリ装置の暗号化装置
US5835726A (en) * 1993-12-15 1998-11-10 Check Point Software Technologies Ltd. System for securing the flow of and selectively modifying packets in a computer network
GB2295299B (en) 1994-11-16 1999-04-28 Network Services Inc Enterpris Enterprise network management method and apparatus
US6035399A (en) 1995-04-07 2000-03-07 Hewlett-Packard Company Checkpoint object
JP3426428B2 (ja) * 1995-10-27 2003-07-14 富士通株式会社 トランザクションのトレース装置
US6006333A (en) * 1996-03-13 1999-12-21 Sun Microsystems, Inc. Password helper using a client-side master password which automatically presents the appropriate server-side password to a particular remote server
US5964839A (en) 1996-03-29 1999-10-12 At&T Corp System and method for monitoring information flow and performing data collection
US5884033A (en) * 1996-05-15 1999-03-16 Spyglass, Inc. Internet filtering system for filtering data transferred over the internet utilizing immediate and deferred filtering actions
US5907680A (en) 1996-06-24 1999-05-25 Sun Microsystems, Inc. Client-side, server-side and collaborative spell check of URL's
US5787177A (en) 1996-08-01 1998-07-28 Harris Corporation Integrated network security access control system
KR19980022833A (ko) 1996-09-24 1998-07-06 최승렬 정보 유출을 추적하기 위한 장치 및 방법
US5835725A (en) * 1996-10-21 1998-11-10 Cisco Technology, Inc. Dynamic address assignment and resolution technique
US5903882A (en) 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5987611A (en) * 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
US6009173A (en) * 1997-01-31 1999-12-28 Motorola, Inc. Encryption and decryption method and apparatus
US5917489A (en) 1997-01-31 1999-06-29 Microsoft Corporation System and method for creating, editing, and distributing rules for processing electronic messages
US5935249A (en) * 1997-02-26 1999-08-10 Sun Microsystems, Inc. Mechanism for embedding network based control systems in a local network interface device
US6085224A (en) * 1997-03-11 2000-07-04 Intracept, Inc. Method and system for responding to hidden data and programs in a datastream
US5944787A (en) * 1997-04-21 1999-08-31 Sift, Inc. Method for automatically finding postal addresses from e-mail addresses
US6073142A (en) 1997-06-23 2000-06-06 Park City Group Automated post office based rule analysis of e-mail messages and other data objects for controlled distribution in network environments
US6359557B2 (en) * 1998-01-26 2002-03-19 At&T Corp Monitoring and notification method and apparatus
US6012067A (en) * 1998-03-02 2000-01-04 Sarkar; Shyam Sundar Method and apparatus for storing and manipulating objects in a plurality of relational data managers on the web
US6141686A (en) 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
US6073242A (en) * 1998-03-19 2000-06-06 Agorics, Inc. Electronic authority server
US6182097B1 (en) 1998-05-21 2001-01-30 Lucent Technologies Inc. Method for characterizing and visualizing patterns of usage of a web site by network users
US6185614B1 (en) 1998-05-26 2001-02-06 International Business Machines Corp. Method and system for collecting user profile information over the world-wide web in the presence of dynamic content using document comparators
US6728757B1 (en) * 1998-06-04 2004-04-27 America Online, Incorporated Smart HTML electronic mail
US6735701B1 (en) 1998-06-25 2004-05-11 Macarthur Investments, Llc Network policy management and effectiveness system
CN1342278A (zh) * 1998-08-04 2002-03-27 机密保护公司 用于形成封装对象产品的设备和方法以及由此形成的封装对象产品
US6154747A (en) * 1998-08-26 2000-11-28 Hunt; Rolf G. Hash table implementation of an object repository
GB9828341D0 (en) 1998-12-22 1999-02-17 Content Technologies Limited Method and system for analyzing the content of encrypted electronic data
US6654787B1 (en) * 1998-12-31 2003-11-25 Brightmail, Incorporated Method and apparatus for filtering e-mail
JP3220104B2 (ja) 1999-02-16 2001-10-22 ケイディーディーアイ株式会社 Ｕｒｌ階層構造を利用した情報自動フィルタリング方法および装置
JP2000278260A (ja) 1999-03-24 2000-10-06 Hitachi Information Systems Ltd 暗号通信方法およびそのプログラムを記録した記録媒体
WO2000068811A1 (en) 1999-04-30 2000-11-16 Network Forensics, Inc. System and method for capturing network data and identifying network events therefrom
US6467052B1 (en) * 1999-06-03 2002-10-15 Microsoft Corporation Method and apparatus for analyzing performance of data processing system
US6819682B1 (en) * 1999-09-03 2004-11-16 Broadcom Corporation System and method for the synchronization and distribution of telephony timing information in a cable modem network
AU7998000A (en) 1999-10-08 2001-04-23 Freeworks Com., Inc. Method and apparatus for mapping a community through user interactions on a computer network
AU1797501A (en) 1999-11-22 2001-06-04 Avenue, A, Inc. Method and facility for capturing behavioral and profile data during a customer visit to a web site
US6754829B1 (en) * 1999-12-14 2004-06-22 Intel Corporation Certificate-based authentication system for heterogeneous environments
US6460074B1 (en) * 2000-02-10 2002-10-01 Martin E. Fishkin Electronic mail system
US7426750B2 (en) * 2000-02-18 2008-09-16 Verimatrix, Inc. Network-based content distribution system
US7017187B1 (en) * 2000-06-20 2006-03-21 Citigroup Global Markets, Inc. Method and system for file blocking in an electronic messaging system
US8972590B2 (en) * 2000-09-14 2015-03-03 Kirsten Aldrich Highly accurate security and filtering software
US7587499B1 (en) * 2000-09-14 2009-09-08 Joshua Haghpassand Web-based security and filtering system with proxy chaining
US20020087645A1 (en) * 2000-09-28 2002-07-04 Kent Ertugrul Automated initiation and propagation by means of electronic mail of devices to provide voice-over-IP and other advanced communications capabilities to recipients of such electronic mail
US6650890B1 (en) * 2000-09-29 2003-11-18 Postini, Inc. Value-added electronic messaging services and transparent implementation thereof using intermediate server
US6895426B1 (en) * 2000-10-17 2005-05-17 Microsoft Corporation Addresses as objects for email messages
GB0027280D0 (en) * 2000-11-08 2000-12-27 Malcolm Peter An information management system
US7320019B2 (en) * 2000-11-30 2008-01-15 At&T Delaware Intellectual Property, Inc. Method and apparatus for automatically checking e-mail addresses in outgoing e-mail communications
US6938065B2 (en) * 2000-12-12 2005-08-30 Ericsson Inc. System and method for controlling inclusion of email content
US8230018B2 (en) * 2001-05-08 2012-07-24 Intel Corporation Method and apparatus for preserving confidentiality of electronic mail
US20030037138A1 (en) * 2001-08-16 2003-02-20 International Business Machines Corporation Method, apparatus, and program for identifying, restricting, and monitoring data sent from client computers
US20030093483A1 (en) * 2001-11-13 2003-05-15 Allen Kram Henry System and method for facilitating email communications by providing convenient access to most recently and/or frequently used email addresses
US20030204722A1 (en) * 2002-04-26 2003-10-30 Isadore Schoen Instant messaging apparatus and method with instant messaging secure policy certificates
JP2007072526A (ja) * 2005-09-02 2007-03-22 Fuji Xerox Co Ltd リポジトリ及びデータ入力装置及びプログラム

Also Published As

Publication number Publication date
DE60132365T2 (de) 2009-01-08
CA2565876C (en) 2009-09-15
ATE382914T1 (de) 2008-01-15
US20020087479A1 (en) 2002-07-04
ATE377810T1 (de) 2007-11-15
DE60132254D1 (de) 2008-02-14
DE60132369T2 (de) 2009-01-08
JP2009146455A (ja) 2009-07-02
CA2565895A1 (en) 2002-05-16
US20050204172A1 (en) 2005-09-15
DE60131300T2 (de) 2008-08-28
CA2567147A1 (en) 2002-05-16
DE60132493D1 (de) 2008-03-06
CA2565949A1 (en) 2002-05-16
US9225553B2 (en) 2015-12-29
US7685626B2 (en) 2010-03-23
EP1360623B1 (en) 2008-01-02
DK1365340T3 (da) 2008-06-30
EP1376435A3 (en) 2004-01-07
DE60132365D1 (de) 2008-02-21
DE60132252T2 (de) 2009-01-15
ATE382915T1 (de) 2008-01-15
US20080301297A1 (en) 2008-12-04
DE60132251D1 (de) 2008-02-14
ATE382913T1 (de) 2008-01-15
CA2571516A1 (en) 2002-05-16
EP1369802B1 (en) 2008-01-16
EP1365340A2 (en) 2003-11-26
EP1378847A1 (en) 2004-01-07
CA2566201A1 (en) 2002-05-16
DK1378847T3 (da) 2008-04-28
DK1360623T3 (da) 2008-05-19
EP1372100B1 (en) 2008-01-16
US7836482B2 (en) 2010-11-16
EP1376435A2 (en) 2004-01-02
ATE383622T1 (de) 2008-01-15
DE60132252D1 (de) 2008-02-14
JP2009146454A (ja) 2009-07-02
ZA200403536B (en) 2005-01-26
US7669227B2 (en) 2010-02-23
EP1369800B1 (en) 2008-01-02
EP1360623A2 (en) 2003-11-12
ZA200403533B (en) 2005-01-26
DE60132495T2 (de) 2009-01-15
DE60132254T2 (de) 2008-12-18
US20080172338A1 (en) 2008-07-17
AU2002212549B2 (en) 2009-04-02
ZA200403534B (en) 2005-01-26
AU1254902A (en) 2002-05-21
ATE382912T1 (de) 2008-01-15
CA2565876A1 (en) 2002-05-16
CA2428238A1 (en) 2002-05-16
US7797240B2 (en) 2010-09-14
ZA200403537B (en) 2005-01-26
DE60132369D1 (de) 2008-02-21
ZA200303545B (en) 2004-06-22
CA2566262A1 (en) 2002-05-16
US20080301454A1 (en) 2008-12-04
DE60132493T2 (de) 2009-07-09
US20080172717A1 (en) 2008-07-17
US20080300904A1 (en) 2008-12-04
US20040078334A1 (en) 2004-04-22
JP4354182B2 (ja) 2009-10-28
WO2002039331A2 (en) 2002-05-16
ZA200403532B (en) 2005-01-26
US7908224B2 (en) 2011-03-15
WO2002039331A8 (en) 2003-09-18
US20050203855A1 (en) 2005-09-15
CA2566201C (en) 2008-10-14
EP1369801B1 (en) 2007-11-07
DE60132253T2 (de) 2009-01-02
ES2299521T3 (es) 2008-06-01
US9203650B2 (en) 2015-12-01
JP2009169960A (ja) 2009-07-30
ZA200403538B (en) 2005-01-26
ATE384309T1 (de) 2008-02-15
CA2567147C (en) 2008-06-03
EP1365340A3 (en) 2003-12-10
EP1376436B1 (en) 2008-01-09
GB0027280D0 (en) 2000-12-27
DE60132253D1 (de) 2008-02-14
US7333956B2 (en) 2008-02-19
DE60131300D1 (de) 2007-12-20
ZA200403535B (en) 2005-01-26
EP1369801A1 (en) 2003-12-10
EP1369800A1 (en) 2003-12-10
US8219815B2 (en) 2012-07-10
EP1376435B1 (en) 2008-01-02
US20080162225A1 (en) 2008-07-03
DK1376436T3 (da) 2008-05-26
ES2299665T3 (es) 2008-06-01
EP1372100A1 (en) 2003-12-17
ATE383623T1 (de) 2008-01-15
DK1376435T3 (da) 2008-05-19
DE60132495D1 (de) 2008-03-06
US20080301762A1 (en) 2008-12-04
US20080301761A1 (en) 2008-12-04
ES2299664T3 (es) 2008-06-01
CA2566262C (en) 2009-06-30
EP1376436A1 (en) 2004-01-02
CA2565929A1 (en) 2002-05-16
ATE384308T1 (de) 2008-02-15
EP1365340B1 (en) 2008-01-09
ZA200403539B (en) 2005-01-26
ES2299667T3 (es) 2008-06-01
JP2009146456A (ja) 2009-07-02
JP2004513460A (ja) 2004-04-30
EP1378847B1 (en) 2008-01-02
US20050216771A1 (en) 2005-09-29
EP1369802A1 (en) 2003-12-10
US7945519B2 (en) 2011-05-17
DE60132251T2 (de) 2008-12-24

Similar Documents

Publication Publication Date Title
ES2299666T3 (es) Un sistema de gestion de la informacion.
AU2002212549A1 (en) An information management system
AU2008201226A1 (en) An information management system