ES2211629T3 - Sistema y procedimiento de acceso y envio automatico de formularios. - Google Patents
Sistema y procedimiento de acceso y envio automatico de formularios.Info
- Publication number
- ES2211629T3 ES2211629T3 ES00970385T ES00970385T ES2211629T3 ES 2211629 T3 ES2211629 T3 ES 2211629T3 ES 00970385 T ES00970385 T ES 00970385T ES 00970385 T ES00970385 T ES 00970385T ES 2211629 T3 ES2211629 T3 ES 2211629T3
- Authority
- ES
- Spain
- Prior art keywords
- network
- database
- data
- user
- sent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/174—Form filling; Merging
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Marketing (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- Computational Linguistics (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Artificial Intelligence (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Health & Medical Sciences (AREA)
- Operations Research (AREA)
- General Health & Medical Sciences (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Storage Device Security (AREA)
- Control Of Multiple Motors (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Preparation Of Compounds By Using Micro-Organisms (AREA)
- Telephonic Communication Services (AREA)
- Input Circuits Of Receivers And Coupling Of Receivers And Audio Equipment (AREA)
- Non-Silver Salt Photosensitive Materials And Non-Silver Salt Photography (AREA)
- Circuits Of Receivers In General (AREA)
Abstract
Un usuario accede a una base de datos de archivos, tales como documentos de formularios estándar, usando un ordenador local, via una red. Los archivos están asociados con uno o más sistemas receptores. Entonces edita los archivos descargados en la pantalla, por ejemplo, cumplimentando los documentos de formularios, y los somete a un servidor notario vía la red. Cada archivo es sometido preferiblemente en un formato encriptado, e incluye preferiblemente una firma digital anexada. Se usa preferiblemente encriptaciópn de clave pública tanto para encriptar el formulario como para implementar la firma digital. Después del procesamiento en el servidor notario tal como la descriptación e identificación del usuario, el servidor notario expide el archivo sometido al sistema receptor apropiado.
Description
Sistema y procedimiento de acceso y envío
automático de formularios.
Esta invención se refiere a un sistema y a un
procedimiento para acceder, procesar y retransmitir automáticamente
registros de bases de datos tales como documentos a través de una
red.
El mundo moderno está lleno de formularios:
formularios de solicitud, formularios de pedido, formularios de
respuesta, formularios de seguros, hasta (lo que parece a menudo) el
infinito. De hecho, no obstante, el propio texto de esta patente
dará origen a uno de los cientos de miles de conjuntos de
formularios de este año bajo cuyo peso acumulado gemirán las
estanterías de la oficina de patentes y aquellos cuyo trabajo sea
procesarlos.
Junto a la llegada del ordenador de oficina,
apareció la promesa del paraíso edénico de la "oficina sin
papeles". Cualquier persona que lea este texto y que mire a su
alrededor en su propia área de trabajo no necesitará probablemente
más pruebas de que este paraíso electrónico está lejos de hacerse
realidad.
Un desarrollo que muestra grandes promesas no
sólo para reducir la cantidad de papeles sino también para hacer más
eficaz el encaminamiento de los papeles es el extendido uso de redes
tales como Internet. En general, los formularios basados en la red
se manejan de la misma manera que el correo electrónico. Por
ejemplo, al hacer un pedido, digamos, de un libro por Internet,
accedemos a y descargamos un formulario de pedido, a menudo
simplemente haciendo clic sobre un icono, rellenamos el formulario
y, a continuación, lo enviamos directamente de vuelta al mismo
servidor del que lo hemos descargado. Este procedimiento se
simplifica precisamente porque la dirección de retorno es
simplemente la dirección "responder" del formulario de correo
electrónico. En otras solicitudes, como por ejemplo, el envío de
formularios internos tales como informes de gastos de viaje a través
de una red específica de la empresa, puede ser que no tengamos la
dirección de retorno automáticamente. No obstante, en la medida en
la que los formularios se encuentran disponibles actualmente a
través de redes, se tratan de forma similar, es decir, como
cualquier otro mensaje de correo electrónico.
Esta disposición convencional tiene varias
desventajas. En primer lugar, a menudo tenemos que especificar
manualmente el receptor del correo electrónico. Esto conduce a
menudo al problema de escribir incorrectamente la dirección de
correo electrónico del receptor, especialmente debido a que las
direcciones normalmente no son intuitivas. Otra desventaja es que la
recuperación de datos en el lado del receptor, es decir, la
instalación donde se recibe y procesa el formulario transmitido,
tiene que manejarse manualmente.
Otro inconveniente más es que no existe
automatización en la recepción de los datos desde un formulario
adjunto a un correo electrónico. Esto es cierto incluso cuando el
formulario se transmite usando un formato de procesamiento de datos
desde el mismo proveedor que hace la aplicación de correo
electrónico, tal como cuando un archivo de Microsoft Word se adjunta
a un correo electrónico enviado a través de Microsoft Outlook. Esta
necesidad de volver a introducir o transcribir los datos enviados
aumenta la probabilidad de error de datos. Otra desventaja más es
que el éxito del sistema del usuario para transmitir un formulario
dependerá con frecuencia totalmente del software real del cliente de
correo. Además, no existe ninguna manera de manejar datos en un
mensaje adjunto de correo electrónico en línea.
Otro serio inconveniente de los sistemas
existentes es que el nivel de seguridad que ofrecen es a menudo
inadecuado. De hecho, muchos navegadores y paquetes de software de
correo electrónico incluyen la capacidad de encriptar el mensaje que
se está enviando, pero este encriptado se prevé en primer lugar para
evitar el "pinchado" de la red, es decir, la interceptación y
lectura no autorizada del mensaje transmitido por una parte distinta
del receptor previsto. Sin embargo, el receptor de un mensaje de
este tipo encriptado convencionalmente no tiene ninguna manera de
identificar de forma única al emisor real.
A partir del documento D1 =
"Super-forms: A security-enhanced
smart electronic form management system", A. Dayao y col.,
Global-telecommunications conference, 1990 and
exhibition. Communications: Connecting the future, Globecom '90,
IEEE',''
2//02-12-1990,1079-1083,
05-12-1990, se conoce un sistema
para acceder, procesar y transmitir archivos de datos que comprende
un servidor multifunción con un sistema de base de datos y un
sistema de seguimiento de las transacciones conectado a una red
local. Asimismo, existen también sistemas de procesamiento locales
conectados a la red. El sistema de base de datos forma un medio para
almacenar una pluralidad de formatos predefinidos. Por medio del
sistema, un usuario puede registrar cambios en un formato
descargado, formulario que a continuación se transfiere a través de
la red a un nodo predefinido de la red a través del servidor
central. Sin embargo, este sistema conocido presente varias
desventajas. En primer lugar, se encuentra restringido en su uso
mediante el uso de formularios/ archivos predefinidos y el uso de
una red/ redes de área local. Asimismo, el sistema es inflexible y
vulnerable debido al uso de un servidor multifunción.
Se necesita un sistema mejorado que permita a un
usuario acceder rápidamente a un formulario necesitado, para
rellenarlo, y a continuación enviarlo con los inconvenientes y
riesgo de error mínimos al usuario correcto. En el extremo receptor,
debería ser posible colocar los datos directamente en una base de
datos o sistema de flujo de trabajo, sin necesidad de volver a
introducir o transcribir los datos enviados. Este sistema debería
ser independiente del cliente de correo y del navegador web usado.
Preferiblemente, este sistema debería ser capaz de proporcionar un
recibo eficazmente inmediato de un formulario enviado y debería ser
posible preferiblemente no sólo encriptar los datos enviados, sino
también identificar y autentificar de forma única la identidad del
emisor de un formulario. Esta invención proporciona un sistema de
este tipo y un procedimiento de funcionamiento relacionado.
La invención proporciona un sistema para acceder,
procesar y transmitir archivos de datos, especialmente documentos,
usando una red de datos. Un sistema de base de datos, al menos un
sistema de procesamiento local, un servidor de certificación y al
menos un sistema receptor forman los componentes principales de la
invención. El sistema de base de datos, cada sistema de
procesamiento local, el servidor de certificación y cada sistema
receptor son preferiblemente sistemas independientes, todos
conectados a la red. El sistema de base de datos almacena una
pluralidad de archivos de datos, por ejemplo, documentos en
cualquier formato estándar. Cada archivo de datos se asocia con uno
correspondiente de los sistemas receptores y puede transferirse por
el sistema de base de datos a través de la red al sistema de
procesamiento local.
Usando uno de los sistemas de procesamiento
locales, el usuario se dirige al sistema de base de datos y
selecciona uno o más de los archivos almacenados, que se descarga a
través de la red desde el sistema de base de datos. A continuación,
el usuario edita (cambia, rellena, etc.) el archivo (los archivos)
descargado (descargados), y entonces, activando un "enviar" o
prestación similar insertado localmente dentro o junto al archivo,
el usuario envía el formulario a un servidor de certificación a
través de la red. El servidor de certificación recibe cada archivo
de datos enviado y, tras procesamientos adicionales tales como
verificación de usuario, copia de seguridad del archivo, estampación
de hora y fecha y transmisión de la recepción de vuelta al usuario,
envía el formulario verificado al respectivo sistema receptor.
Cada archivo de datos se envía preferiblemente
desde el sistema de procesamiento local al servidor de certificación
en un formulario encriptado. Una firma digital se adjunta también
preferiblemente a cada archivo enviado. El encriptado por clave
pública se usa preferiblemente tanto para encriptar los formularios
enviados como para generar la firma digital.
La Figura 1 es un diagrama de bloque de los
componentes principales de un sistema de acuerdo con la invención
para acceder, completar, enviar, verificar y encaminar formularios a
través de una red.
La Figura 1 muestra los componentes principales
de la forma de realización preferida del sistema de acuerdo con la
invención. En la explicación siguiente, el término "formulario"
se ha de entender como el significado de cualquier registro o
archivo de datos al que un usuario pueda desear acceder, ver, editar
o cambiar de cualquier forma y, a continuación, enviar a una
instalación o sistema receptor. En la mayoría de las aplicaciones de
la invención, los formularios serán documentos compuestos o
almacenados en cualquier formato de procesamiento de datos estándar
tal como Microsoft Word o Corel Word Perfect, o algún otro formato
que permita la entrada del usuario directamente en el texto del
documento, tal como archivos PDF de Adobe Acrobat. No obstante, la
invención no se encuentra restringida a cualquier formato
particular; de hecho, esta es una de las ventajas de la
invención.
Una base de datos 100 central contiene un
conjunto de formularios 102 almacenados electrónicamente, además del
hardware convencional (tal como un servidor) y el software necesario
para permitir que un sistema externo tenga acceso a los registros de
la base de datos, en particular, a través de una red. En la mayoría
de los casos, la invención se usará para permitir a un usuario
acceder a uno o más formularios, rellenarlo o cambiarlo y, a
continuación, enviarlo al receptor (receptores) respectivo
(respectivos). Los distintos receptores podrían subscribirse y, en
general, se subscribirán a y serán destinos para el sistema de
acuerdo con la invención. Cada receptor puede especificar su propio
formato de archivo de formulario; los formularios 102 se almacenan
en cualquier formato que use cada receptor respectivo.
Para componer la base de datos 100, el
administrador del sistema podría recibir los formularios
directamente (por ejemplo, en disco o haciendo que estén disponibles
para su descarga) de cualquier entidad que desee que sus formularios
sean accesibles o bien el sistema podría descargar de forma
convencional los formularios accesibles públicamente desde sitios
del receptor seleccionado, o ambos.
La entidad que proporciona o genera los
formularios será normalmente la misma entidad que espera recibirlos,
completados, de los usuarios. Sin embargo, esto no está
necesariamente de acuerdo con la invención. En lugar de eso, el
proveedor de formularios podría ser diferente del receptor previsto,
como ocurre, por ejemplo, con las empresas que proporcionan
formularios legales estándares para su envío a juzgados u otras
entidades gubernamentales. En otras palabras, las entidades que
proporcionan o generan los formularios almacenados en la base de
datos 100 no necesitan ser necesariamente las mismas que las
entidades receptoras previstas, aunque este será el caso más
común.
La base de datos 100 se conecta a una red 200. Un
usuario es también capaz de acceder a la red 200 usando cualquier
sistema de procesamiento local 300 tal como un ordenador personal
(PC). En la Figura 1, sólo se muestra un sistema de procesamiento
local meramente por motivos de simplicidad. La invención funcionará
(de hecho, es lo más ventajoso) incluso para grandes números de
usuarios, cada uno con acceso a la red 200 y, por tanto, a la base
de datos 100, usando un sistema de procesamiento local dedicado o
compartido.
En el uso más general de la invención, la red 200
será una red pública de área extensa, preferiblemente, Internet.
Tampoco esto es necesario; la red puede ser cualquier red de área
extensa o local y podría ser incluso una red unificada tal como las
redes de intranet encontradas en muchas empresas. Estas redes de
intranet pueden, a su vez, conectarse a través de servidores de
pasarela convencionales a la red pública. Lo necesario de acuerdo
con la invención es sencillamente que cada usuario debería ser capaz
de ponerse en contacto con la base de datos 100 a través de la red,
proyectar uno o más formularios y, a continuación, ser capaz de
recibir estos formularios, todo a través de la red 200.
En el caso preferido en el que la red sea
Internet, el servidor u otro sistema a través del que sea accesible
la base de datos, la base de datos o alguna pantalla de pasarela
dentro de ésta tendrán sencillamente una dirección de red estándar,
tal como un identificador uniforme de recursos (URL). El usuario
podría proyectar entonces un formulario que se ha de transferir
desde la base de datos bien seleccionándolo desde cualquier menú
estándar mostrado o, si se supiera, proyectando una subdirección
donde se encuentra el formulario. Un pedido de archivos de este tipo
es común en el diseño de sitios no sólo para la World Wide Web (www)
sino también para los archivos jerárquicos o vinculados de otro
modo, accesibles también a través de otras redes.
Existen diversas maneras por las que los usuarios
pueden informarse acerca de qué formularios se encuentran
disponibles para descargarse desde la base de datos 100. Por
ejemplo, el usuario puede sencillamente buscar un menú en línea de
formularios disponibles, organizado, por ejemplo, por áreas
temáticas o categorías de proveedor. El sitio o programa de pasarela
asociado con la base de datos 100 podría también proporcionarse con
un motor de búsqueda convencional para hacer más sencillo encontrar
el formulario deseado. Si cada formulario puede identificarse
mediante una URL concreta, un proveedor de formularios puede también
tener las diversas URL de los formularios disponibles conocidos en
su propio sitio web, enviando la dirección del formulario apropiado
al usuario, por ejemplo, a través del correo electrónico, como
respuesta a una consulta o de cualquier otra manera
convencional.
Esta invención incluye también un servidor de
certificación 400, que se conecta también a la red 200 para la
transferencia de datos bidireccional. La función del servidor de
certificación se explica a continuación.
Finalmente, uno o más servidores o sistemas
receptores 500 se conectan también a la red 200. Una vez más, sólo
uno de tales sistemas se ilustra en la Figura 1 meramente por
razones de simplicidad; en la mayoría de las aplicaciones de la
invención, habrá un gran número de receptores. Un receptor puede ser
cualquiera de los diferentes tipos de instalaciones que son capaces
de recibir documentos u otros archivos a través de la red 200.
Sistemas tales como bases de datos externas, sistemas de gestión de
flujo de trabajo o documentos o servidores de correo para empresas o
entidades gubernamentales son sólo algunos ejemplos.
Antes de ahondar en los detalles de la invención,
consideremos un ejemplo de un posible uso para hacernos una idea más
general del procedimiento de funcionamiento de la invención.
Asumamos que un usuario quiere enviar, por ejemplo, un cambio del
formulario de dirección postal para una patente de Estados Unidos. A
partir de ese momento, el usuario tiene que escribir una carta, o
descargar, imprimir, completar y enviar por correo o fax el
formulario de solicitud adecuado a la Oficina de patentes. Desde el
27 de agosto de 1999, en Estados Unidos, este es el formulario
PTO/SB/123, disponible en formato PDF y descargable desde la
dirección de la red
http://www.uspto.govlweb/forms/sb0123.pdf. Actualmente, es
necesario un formulario en papel porque la Oficina de patentes tiene
que ser capaz de confirmar, mediante el nombre y la firma del
solicitante, que la persona que solicita la copia está autorizada
efectivamente para recibirla.
Ahora, imaginemos (esperemos que la imaginación
no tenga que durar demasiado) que la Oficina de patentes tiene un
servidor que se conecta a la red 200, y que el formulario de
solicitud está incluido como uno de los formularios 102 de la base
de datos 100. Tengamos en cuenta que podría almacenarse como el
mismo archivo PDF y que el administrador de la base de datos
sencillamente podría haber descargado el formulario, junto a los
otros formularios de la Oficina de patentes disponibles
públicamente, desde el sitio web de la Oficina de patentes,
explorando en los formularios, o recibiéndolos en un medio legible
estándar desde la propia Oficina de patentes. Los proveedores de
formularios (que generalmente serán los receptores 500 de los
formularios) pueden elegir tener sus formularios incluidos en la
base de datos 100 (incluso si fuera necesario pagar una tasa de
suscripción al propietario/ administrador de la base de datos) por
cualquiera de varias razones. Podrían advertir que el suministro y
envío electrónico de formularios es más eficaz y, por tanto, reduce
su propia carga de trabajo administrativo; podrían preferir no tener
que mantener su propia base de datos en línea; o sencillamente
podrían querer tener sus formularios disponibles rápidamente para la
comodidad de sus clientes o del público.
De acuerdo con la invención, el usuario accede
("entra") a la red 200 a través del sistema de procesamiento
local 300 de cualquier manera convencional. A continuación,
especifica la dirección de red de la base de datos 100 y selecciona
el formulario que necesita descargar, por ejemplo, el cambio del
formulario de dirección. A continuación, este servidor de la base de
datos transfiere el archivo correspondiente al formulario solicitado
a través de la red 200 al procesador local 300, que entonces se lo
muestra al usuario, por ejemplo, en un monitor estándar 310.
Alternativamente, siempre que el archivo que contiene el formulario
incluya datos que permitan su uso en la invención (se describe a
continuación), entonces el usuario podrá recibir también el
formulario a través del correo electrónico o en un medio legible. Es
también posible que el usuario pueda recibir, a través de la red o
en un medio legible, un conjunto de formularios habilitados para su
uso en la invención. Por ejemplo, todos los formularios estándares
de la Oficina de patentes pueden ponerse a disposición de los
usuarios, de forma gratuita o pagando una tasa, junto a los datos
necesarios para incorporarlos para su uso en el sistema de acuerdo
con la invención.
Usando dispositivos estándares de entrada, tales
como un teclado 312 y un controlador del cursor 314 tales como un
ratón, bola de seguimiento, ratón táctil o similares, el usuario
introduce entonces la información necesaria en los campos de entrada
respectivos del formulario mostrado; completa o "rellena" el
formulario en pantalla. A continuación, el usuario activa una
prestación "enviar", por ejemplo, haciendo clic en un icono
"enviar" 316 mostrado como parte de o en combinación con el
formulario mostrado, o presionando una tecla de función asignada. A
continuación, el sistema local preferiblemente encripta y, luego,
transmite el formulario ahora completado de vuelta al servidor de
certificación 400 a través de la red 200, por ejemplo, reenviándolo
a la dirección de red predeterminada del servidor de
certificación.
Cuando el servidor de certificación 400 recibe un
formulario de un usuario, desencripta el formulario si estuviera
encriptado, verifica la identidad del usuario y, a continuación,
transmite (exporta) el formulario al receptor proyectado del
formulario. Como se describe detalladamente a continuación, se usa
preferiblemente el encriptado por clave pública durante la
transferencia de un formulario desde el usuario al servidor de
certificación. En estos casos, la etapa de verificar la identidad
del usuario puede incluir subetapas estándares tales como la
verificación de la autenticidad de la certificación de la clave
pública del usuario.
Estas funciones se llevan a cabo preferiblemente
en módulos de software respectivos para recepción 410, desencriptado
412, verificación de usuario/ emisor 414 y exportación de archivos
416 y podrían proyectarse de cualquier manera convencional. Antes de
exportar el formulario al receptor, el servidor de certificación
guarda también preferiblemente una copia de seguridad en una memoria
para copias de seguridad 418, junto a una estampación de fecha y
hora generada de cualquier manera convencional en un módulo de
estampación de fecha y hora 420. Podrían incluirse otros módulos de
software tales como aquellos para funciones administrativas como
facturación 422 (en las aplicaciones en las que los usuarios tienen
que pagar para enviar o recibir formularios usando la invención) si
fuera necesario.
Una vez que el servidor de certificación ha
exportado el formulario enviado al sistema receptor correspondiente
(por ejemplo, transmitiéndolo a la dirección de red
correspondiente), entonces el servidor de certificación transmite
preferiblemente un recibo de envío de vuelta a través de la red de
vuelta al sistema de procesamiento local 300. Este recibo de
transmisión identifica preferiblemente qué formulario se envió a qué
sistema receptor, por quién y a qué hora. Si el sistema receptor 500
incluye también la capacidad para generar y devolver un acuse de
recibo, entonces se puede devolver también una copia o indicación de
esto al usuario original como parte del recibo. Otra opción de
recibo es que el servidor de certificación devuelva al procesador
local del usuario una copia de correo electrónico del formulario
enviado, posiblemente ampliado con la información del envío
mencionada anteriormente.
La dirección de red del sistema receptor para
cada formulario puede registrarse de diferentes maneras. Por
ejemplo, un campo (quizá oculto, para reducir el riesgo de
equivocación con la dirección o errores como resultado de la edición
del usuario) puede incluirse en el propio archivo del formulario. En
la mayoría de las aplicaciones de la invención, el servidor de
certificación asignará algún identificador, tal como un código
alfanumérico, a cada formulario incluido en el sistema. A
continuación, el servidor de certificación podría mantener una tabla
que concuerde cada formulario con la dirección B de red correcta del
receptor cuando se recibe un formulario de un usuario; a
continuación, el servidor de certificación introduce la tabla de
direcciones usando el identificador correspondiente del formulario
como el argumento y recupera la dirección de red correspondiente y
adecuada del receptor.
Para que un usuario sea capaz de enviar un
formulario usando la invención, el formulario, es decir, el archivo
de datos que incluye el documento que se ha de enviar, tiene que
incluir ciertos datos que permitan su uso en la invención. Por
ejemplo, tiene que incluir al menos algún identificador que lo
asocie con su receptor adecuado. Tales adiciones se pueden hacer de
cualquier manera convencional, por ejemplo, sencillamente
añadiéndolas como anexo al archivo del formulario según cualquier
protocolo predefinido.
Para que el procesador local del usuario sea
capaz de reconocer tales datos anexos, de generar tales elementos
como un icono "enviar" (si no se hubiera incluido en el propio
archivo descargado) y de encriptar los datos enviados (si se incluye
esta prestación), entonces el procesador 300 tiene que cargarse con
al menos algún software de autorización dedicado. Este software de
autorización puede encontrarse disponible para su instalación en el
procesador local del usuario de cualquier manera convencional, por
ejemplo, proporcionando un disco al usuario o haciendo que el
programa se encuentre disponible para la descarga en el procesador a
través de la red.
Los módulos del software de autorización pueden
proyectarse de cualquier manera convencional. Incluirá una interfaz
de programación de aplicaciones estándar (API), que es
preferiblemente abierta. Los módulos de software incluirán un módulo
para generar una pantalla de base, es decir, la pantalla que el
usuario abre para identificar qué formato quiere; un motor para
conectar automáticamente el procesador local a la red 200 (o para
enviar una dirección si ya está abierta una conexión) y para
descargar un formulario deseado de la base de datos 100; un módulo
para dar formato y mostrar el formulario descargado, además de
elementos como un icono "enviar"; un módulo para insertar datos
introducidos por el usuario en los campos adecuados del formulario
mostrado; preferiblemente un módulo para encriptar el formulario
antes de su envío (si se incluye el encriptado); un módulo para
enviar el formulario a través de la red y un módulo para detectar y
presentar un recibo de transmisión al usuario.
Los diversos módulos pueden proyectarse usando
cualquiera de las diversas técnicas conocidas o en combinación con
el software existente en el procesador local. Por ejemplo, los
módulos que procesan el formulario pueden escribirse en Java, C++ o
en HTML (o XML) o incluso en HTML con applets de Java incrustados; y
la rutina de encriptado puede ser un software de terceros que ya se
encuentra disponible en el mercado. El software puede incluso
integrarse en un software de correo electrónico o de navegador
existente.
El tipo de software instalado en el procesador
local 300 determinará también de qué manera deberían almacenarse
preferiblemente los formularios en la base de datos 100. Por
ejemplo, si se asume que los formularios de la base de datos pueden
estar en los formatos de los proveedores de formularios, por
ejemplo, algunos en formato Microsoft Word, otros en formatos Corel
Word Perfect y otros en formato PDF, entonces todos los formularios
almacenados tienen que convertirse mediante el sistema de la base de
datos 100 a un formato común que pueda leer el software del
procesador local o bien el software de procesamiento local tiene que
incluir las rutinas necesarias para leer, mostrar y editar
formularios en los formatos que puede querer descargar el usuario.
Por motivos de facilidad de uso, es preferible por tanto que todos
los formularios del sistema de base de datos 100 estén en (o se
conviertan a) un formato predeterminado que pueda interpretar el
software de procesamiento local.
Los datos incluidos en los formularios enviados
(o sea, el hecho de que el usuario desee enviar un formulario
particular en todos los sentidos) serán normalmente un asunto
confidencial del usuario. Por tanto, la invención incluye
preferiblemente una prestación de encriptado para los formularios
enviados. En la forma de realización preferida de la invención, los
formularios se envían usando encriptado por clave pública. Esto
permite también que cada formulario sea identificado usando una
"firma digital" convencional.
El encriptado por clave pública como tal es
conocido. Usa dos "claves": una clave pública, que puede
ponerse a disposición de todos los emisores potenciales y una clave
privada correspondiente, que es mantenida en secreto por el
receptor. En la práctica, cada par de claves pública/ privada está
formada por grandes números primos con una relación predeterminada
funcional y única entre sí. La clave pública es suficiente para
encriptar un mensaje para su transmisión, pero la clave privada es
necesaria para desencriptarlo. En otras palabras, una vez que un
emisor encripta un mensaje usando la clave pública, no podrá
desencriptarlo.
Supongamos ahora que un proveedor de formularios
(o cualquier otra entidad) concede números de identificación a los
usuarios potenciales de la invención. Si estos números ID son además
claves de encriptado registradas a y asociadas de forma única con
los usuarios individuales, entonces una cadena de datos única
encriptada usando una de estas claves y transmitida junto al mensaje
real funcionaría como una "firma digital" en el extremo del
receptor. De acuerdo con esto, el sistema de procesamiento local 300
incluye preferiblemente un módulo de software que incluye una cadena
de datos encriptados de forma única de este tipo ("firma
digital") junto a cualquier formulario que se transmita a un
receptor a través de la red.
Debido a la naturaleza de las claves públicas y
privadas (a diferencias de las contraseñas comunes, son normalmente
cadenas de miles de palabras de datos de muchos bits, por ejemplo,
24 o más), no es práctico para el usuario memorizar simplemente las
claves. Si el sistema de procesamiento local 300 se dedica
únicamente a un usuario particular, entonces es posible almacenar la
clave para la firma digital en la memoria del propio sistema. Por
supuesto, no es necesario saberse las claves usadas para encriptar
los formularios transmitidos a receptores de formularios
particulares; por definición, estas claves serán públicas.
Sin embargo, el problema aparece en la mayoría de
las aplicaciones porque los ordenadores locales rara vez son tan
seguros como para poder almacenar una clave privada en ellos.
Además, si la clave de la firma digital de un usuario se almacena en
un único ordenador, entonces no será capaz de usar la invención en
otros ordenadores, al menos que no si desea o necesita incluir su
firma digital en un formulario enviado.
El encriptado de formularios se realiza
preferiblemente, por tanto, usando un lector 318 que se conecta a o
está incluido en el sistema de procesamiento local 300 para leer una
tarjeta inteligente 320 convencional o dispositivo de memoria
portátil similar. Los parámetros personales del usuario (que
incluyen, por ejemplo, las claves) o el algoritmo de encriptado se
codifican entonces en la tarjeta inteligente y pueden leerse cuando
se ha de enviar un formulario. Esto garantiza que sólo el usuario
será capaz de saber qué formularios se envían y qué datos personales
se incluyen en ellos, incluso si cualquier persona tiene acceso al
sistema de procesamiento local. Debido a que el encriptado por
claves públicas es una técnica conocida, por tanto, puede usarse
cualquier software convencional en combinación con la invención para
poner en práctica el módulo de encriptado en el sistema de
procesamiento local y el módulo de desencriptado 412 del servidor de
certificación.
La capacidad del usuario para acceder, completar
y enviar formularios de acuerdo con la invención se puede usar
también para permitir la comunicación con una base de datos
arbitraria accesible a través de la red. En este caso, cuando el
usuario completa y envía un formulario a través del servidor de
certificación, podrían introducir consultar en la base de datos en
los campos apropiados y predeterminados del formulario enviado.
Cuando el sistema receptor 500 recibe el formulario, podría
decodificar automáticamente la búsqueda (usando rutinas conocidas) y
transferir una respuesta de vuelta al emisor a través de la red.
Por ejemplo, supongamos que un cliente de un
banco quiere conseguir una copia de un extracto del mes anterior
para una de sus cuentas. A partir de ese momento, el cliente tiene
que llamar por teléfono para realizar esta solicitud a un centro de
atención al cliente, que autentificará oralmente el derecho del
cliente a esta información, factura en su cuenta alguna pequeña
cantidad y, a continuación, envía al cliente por correo o por fax el
extracto. Esto no sólo requiere tener un agente de atención al
cliente, sino que también implica normalmente una demora de varios
días, desde que se accede a la base de datos del banco y se imprime
y se envía por correo al cliente que realiza la solicitud una copia
en papel del extracto (que puede almacenarse como una imagen o puede
ser accesible sólo a través de una conversión desde
micropelícula).
Usando esta forma de realización de la invención,
en lugar de lo anterior, el usuario sería capaz de acceder a un
formulario de solicitud desde la base de datos 100, que actúa como
un archivo de formularios, y a continuación enviarlo de forma segura
al sistema receptor del banco, a través del servidor de
certificación. Si se programa el sistema receptor del banco (usando
rutinas estándares) para interpretar directamente y responder a las
consultas introducidas en el formulario enviado, entonces será capaz
de responder a la solicitud del usuario sin complicaciones
adicionales.
Sin embargo, en muchos casos, la base de datos
situada en el sistema receptor o se configurará para interpretar
formularios, sino más bien responderá sólo a consultas y comandos
presentados en un formato de comandos estándar de la base de datos,
tal como ODBC. Una manera de manejar esto sería tener instalado el
software ODBC en cada sistema de procesamiento local para cada
cliente/ usuario. Sin embargo, esto no sería práctico en la mayoría
de los casos y sería propenso al error. En su lugar, de acuerdo con
la invención, el software de acceso a la base de datos podría
incluirse en el servidor de certificación. Siempre que se destina un
formulario enviado a un sistema receptor identificado como una base
de datos que responde a consultas, el servidor de certificación
convierte simplemente (de nuevo usando rutinas conocidas) los campos
del formulario enviado correspondientes a las solicitudes de acceso
a la base de datos en comandos de la base de datos con el formato
apropiado, tal como ODBC. El cliente será capaz entonces de
comunicar con el servidor de certificación usando un formato más
común como html, mientras que la comunicación con la base de datos
del sistema receptor se realiza mediante protocolos de acceso a la
base de datos más especializados, sin necesidad de que se haya de
instalar software especializado en el sistema de procesamiento local
del cliente. Tengamos en cuenta que también sería posible el uso de
esta misma disposición para que el cliente introduzca datos en la
base de datos del sistema receptor así como para descargar
información de él.
Lógicamente, la seguridad es muy importante
cuando se accede a las bases de datos que contienen información
privada y privilegiada. Junto a la solicitud de acceso a la base de
datos del sistema receptor, el usuario incluirá por ello en el
formulario de solicitud enviado cualquier código de autenticación o
identificación previamente establecido, que el sistema receptor
comprobará contra registros prealmacenados para determinar si el
usuario que realiza la solicitud está autorizado a recibir la
información solicitada antes de transferirla al usuario.
Como otra extensión más de esta forma de
realización, el usuario podría solicitar acceso a la información de
la base de datos, pero dirigiéndola para que sea transferida a un
receptor diferente que se conecta a la red y forma parte del mismo
sistema. Por ejemplo, es común que un prestamista solicite copias de
los extractos bancarios de un solicitante de un préstamo antes de
aprobar un préstamo. Tal y como son las cosas ahora, el solicitante
del préstamo tiene normalmente que pedir al banco que envíe las
copias al prestamista o tiene que firmar algún tipo de autorización
para que el prestamista reciba estos registros. Usando la invención,
el solicitante potencial del préstamo puede descargar un formulario
para solicitar un extracto del banco, incluyendo en el campo
apropiado la dirección de red del prestamista al que se ha de
reenviar el extracto.
Este sistema permitiría también la transferencia
de registros a los que incluso el usuario no tenga acceso. Por
ejemplo, los centros médicos no entregan normalmente a un paciente
sus historiales médicos. Sin embargo, antes de aprobar una cobertura
las compañías de seguros de vida requieren estos historiales
médicos. Usando la invención, el usuario podría descargar un
formulario de solicitud de historial médico y enviarlo a través del
servidor de certificación al centro médico junto a la dirección de
red de la compañía de seguros. Esto aceleraría enormemente los
procedimientos de envío y solicitud sin comprometer la
confidencialidad.
Claims (10)
1. Un sistema para acceder, procesar y transmitir
archivos de datos que comprende:
un servidor (400);
una red (200);
un sistema de base de datos (100) y un sistema de
seguimiento de las transacciones conectados a la red, al menos un
sistema de procesamiento local (300) conectado de forma
independiente a la red, y
al menos un sistema receptor (500) conectado a la
red,
formando el sistema de base de datos (100) medios
para almacenar una pluralidad de archivos de datos (102),
comprendiendo cada uno de ellos un formulario,
y para transferir los archivos de datos (102) a
través de la red al sistema de procesamiento local;
formando cada sistema de procesamiento local
(300) medios para dirigir el sistema de base de datos, para
descargar a través de la red al menos un archivo de datos
seleccionado por el usuario almacenado en el sistema de base de
datos, para registrar los cambios introducidos por el usuario en el
archivo de datos descargado y para transferir el archivo de datos
cambiado como un archivo de datos enviado a través de la red;
y el servidor (400), que forma medios para
recibir cada archivo de datos enviado a través de la red y para
transferir cada archivo de datos enviado a un receptor con el que se
asocia el archivo de datos enviado,
caracterizado
porque dicha red (200) es una red de propósitos
generales y área extensa,
porque dicho sistema de base de datos (100) forma
un sistema independiente conectado a la red;
porque dicho sistema de seguimiento de las
transacciones se pone en práctica en dicho servidor (400) que
funciona como servidor de certificación (400) que forma un sistema
independiente conectado a la red, porque dicho al menos un sistema
receptor (500) se conecta independientemente a la red,
porque cada formulario (102) está en un formato
esencialmente arbitrario pero predeterminado que puede ser diferente
del formato de los otros formularios del sistema de base de datos
(100),
porque cada formulario (102) incluye un
identificador que lo asocia con su sistema receptor apropiado, y
porque cada archivo de datos enviado se
transfiere por medio de dicho servidor de certificación (400) al
servidor receptor (500) con el que se asocia.
2. Un sistema según la reivindicación 1,
caracterizado porque el sistema de procesamiento local (300)
forma además medios para encriptar archivos de datos (102) enviados
usando encriptado por clave pública.
3. Un sistema según la reivindicación 2,
caracterizado porque el sistema de procesamiento local (300)
forma además medios para colocar como anexo a cada formulario
enviado un código digital encriptado por clave pública que
identifica de forma única al usuario en el sistema receptor (500)
con el que se asocia el formulario enviado.
4. Un sistema según la reivindicación 3,
caracterizado por incluir además:
un dispositivo de memoria portátil (320) que
almacena parámetros de encriptado personales del usuario; y
un lector (318) que se adjunta al sistema de
procesamiento local (300) para leer los parámetros de encriptado del
usuario desde el dispositivo de memoria portátil (320).
5. Un sistema según la reivindicación 1 ó 2,
caracterizado porque los archivos de datos (102) son
documentos almacenados en cualquier formato de documentos
estándar.
6. Un sistema según la reivindicación 1 ó 2,
caracterizado porque el servidor de certificación (400)
comprende además un módulo de software para permitir la comunicación
con una base de datos arbitraria accesible a través de la red.
7. Un procedimiento para acceder, procesar y
transmitir archivos de datos dentro de un sistema según la
reivindicación 1, que comprende una pluralidad de archivos de datos
(102) almacenados en un sistema de base de datos (100), que se
conecta a una red (200) de área extensa, asociándose cada archivo
(102) con un sistema receptor (500) correspondiente;
caracterizado por las siguientes
etapas:
uso de un sistema de procesamiento local (300),
dirección al sistema de base de datos (100) a través de la red (200)
para seleccionar al menos uno de los archivos de datos almacenados
(102);
descarga a través de la red de los archivos de
datos (102) seleccionados por el usuario;
edición de los archivos de datos descargados
(102) en el sistema de procesamiento local (300); transferencia de
los archivos de datos (102) editados como archivos de datos (102)
enviados a un servidor de certificación (400) a través de la red
(200); y
transferencia de cada archivo de datos (102)
enviado desde el servidor de certificación (400) al sistema receptor
(500) con el que se asocian los archivos de datos (102).
8. Un procedimiento según la reivindicación 7,
que incluye además la etapa de encriptado de los archivos de datos
(102) enviados usando encriptado por clave pública.
9. Un procedimiento según la reivindicación 8,
que incluye además la etapa de colocar como anexo a cada formulario
enviado un código digital encriptado por clave pública que
identifica de forma única al usuario en el sistema receptor (500)
con el que se asocia el formulario enviado.
10. Un procedimiento según la reivindicación 7,
que incluye además las siguientes etapas:
inclusión en los archivos de datos (102) enviados
de una solicitud de acceso a la base de datos;
en el servidor de certificación (400), conversión
del acceso a la base de datos en un protocolo de acceso
predeterminado a la base de datos y transmisión del acceso a la base
de datos convertido al receptor; y
descarga desde la base de datos del receptor de
la información correspondiente a la solicitud de acceso a la base de
datos.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US43512999A | 1999-11-05 | 1999-11-05 | |
| US435129 | 1999-11-05 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2211629T3 true ES2211629T3 (es) | 2004-07-16 |
Family
ID=23727103
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00970385T Expired - Lifetime ES2211629T3 (es) | 1999-11-05 | 2000-10-03 | Sistema y procedimiento de acceso y envio automatico de formularios. |
Country Status (11)
| Country | Link |
|---|---|
| EP (2) | EP1383053A3 (es) |
| AT (1) | ATE256314T1 (es) |
| AU (1) | AU7977600A (es) |
| CA (1) | CA2376530C (es) |
| DE (2) | DE10084762T1 (es) |
| DK (1) | DK1228451T3 (es) |
| ES (1) | ES2211629T3 (es) |
| GB (1) | GB2367403B (es) |
| NO (1) | NO315588B1 (es) |
| SE (1) | SE0203745L (es) |
| WO (1) | WO2001033420A1 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6378221B1 (en) | 2000-02-29 | 2002-04-30 | Edwards Lifesciences Corporation | Systems and methods for mapping and marking the thickness of bioprosthetic sheet |
| GB2379146A (en) * | 2001-08-23 | 2003-02-26 | Inventec Corp | Transmission of encrypted and digitally signed files over the internet |
| FI20095685A0 (fi) * | 2009-06-17 | 2009-06-17 | Valtion Teknillinen | Laskentalaitteisto luotettavaa palveluhallintaa varten ja tähän liittyvä menetelmä |
| US9358107B2 (en) | 2011-06-30 | 2016-06-07 | Edwards Lifesciences Corporation | Systems, dies, and methods for processing pericardial tissue |
| EP3067850A1 (de) * | 2015-03-10 | 2016-09-14 | AUTOBAV GmbH & Co. KG | Verfahren und Vorrichtung zum vermitteln einer betrieblichen Altersvorsorge |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5812671A (en) * | 1996-07-17 | 1998-09-22 | Xante Corporation | Cryptographic communication system |
-
2000
- 2000-10-03 DK DK00970385T patent/DK1228451T3/da active
- 2000-10-03 CA CA002376530A patent/CA2376530C/en not_active Expired - Fee Related
- 2000-10-03 AU AU79776/00A patent/AU7977600A/en not_active Abandoned
- 2000-10-03 WO PCT/SE2000/001901 patent/WO2001033420A1/en not_active Ceased
- 2000-10-03 DE DE10084762T patent/DE10084762T1/de not_active Withdrawn
- 2000-10-03 GB GB0129000A patent/GB2367403B/en not_active Expired - Fee Related
- 2000-10-03 AT AT00970385T patent/ATE256314T1/de not_active IP Right Cessation
- 2000-10-03 EP EP03102731A patent/EP1383053A3/en not_active Withdrawn
- 2000-10-03 EP EP00970385A patent/EP1228451B1/en not_active Revoked
- 2000-10-03 DE DE60007171T patent/DE60007171T2/de not_active Revoked
- 2000-10-03 ES ES00970385T patent/ES2211629T3/es not_active Expired - Lifetime
-
2001
- 2001-12-06 NO NO20015975A patent/NO315588B1/no unknown
-
2002
- 2002-12-16 SE SE0203745A patent/SE0203745L/xx not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| DE10084762T1 (de) | 2003-01-16 |
| NO315588B1 (no) | 2003-09-22 |
| CA2376530C (en) | 2002-12-10 |
| DK1228451T3 (da) | 2004-03-08 |
| NO20015975L (no) | 2002-05-06 |
| NO20015975D0 (no) | 2001-12-06 |
| DE60007171T2 (de) | 2004-09-16 |
| GB2367403A (en) | 2002-04-03 |
| EP1228451B1 (en) | 2003-12-10 |
| GB2367403B (en) | 2002-10-09 |
| ATE256314T1 (de) | 2003-12-15 |
| GB0129000D0 (en) | 2002-01-23 |
| AU7977600A (en) | 2001-05-14 |
| SE0203745D0 (sv) | 2002-12-16 |
| WO2001033420A1 (en) | 2001-05-10 |
| CA2376530A1 (en) | 2001-05-10 |
| DE60007171D1 (de) | 2004-01-22 |
| EP1228451A1 (en) | 2002-08-07 |
| SE0203745L (sv) | 2002-12-16 |
| EP1383053A3 (en) | 2005-01-12 |
| EP1383053A2 (en) | 2004-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7237114B1 (en) | Method and system for signing and authenticating electronic documents | |
| US6539093B1 (en) | Key ring organizer for an electronic business using public key infrastructure | |
| US20020023213A1 (en) | Encryption system that dynamically locates keys | |
| US6807633B1 (en) | Digital signature system | |
| US7269635B2 (en) | File transfer system for secure remote file accesses | |
| US9280670B2 (en) | Siftsort | |
| US11848921B2 (en) | System for sending e-mail and/or files securely | |
| US20020016910A1 (en) | Method for secure distribution of documents over electronic networks | |
| US20030074315A1 (en) | System and apparatus for remotely printing certified documents | |
| US20070143835A1 (en) | Security tokens including displayable claims | |
| US20090025092A1 (en) | Secure online data storage and retrieval system and method | |
| JP2002057660A (ja) | 暗号化において署名、ディジタル印章およびディジタル署名として役割証明書を使用するためのシステムおよび方法 | |
| US20080235175A1 (en) | Secure Document Management System | |
| JP2005209181A (ja) | ファイル管理システム及び管理方法 | |
| US7162736B2 (en) | Remote unblocking with a security agent | |
| JP6807734B2 (ja) | 中継サーバ、及び中継プログラム | |
| JP2006059223A (ja) | 情報通信仲介装置、情報通信仲介装置の制御方法、及びプログラム | |
| EP1228451B1 (en) | Automatic form accessing and submission system and method | |
| WO2000046952A1 (en) | Method for sending secure email via standard browser | |
| CA2309463C (en) | Digital signature system | |
| KR20020084642A (ko) | 공개키 기반구조의 전자서명문서 발급/수신시스템 | |
| US20050138367A1 (en) | System and method for storing user credentials on a server copyright notice | |
| KR100508914B1 (ko) | 인터넷을 이용한 제증명서 발급 시스템 및 이를 이용한제증명서 발급방법 | |
| KR100467794B1 (ko) | 신용정보 서비스를 위한 민원처리 시스템 | |
| JP2000151582A (ja) | 認証システム及びその記憶媒体 |