ES2244705T3 - Matriz, procedimiento y dispositivo de moldeo por inyeccion para moldear un disco optico. - Google Patents
Matriz, procedimiento y dispositivo de moldeo por inyeccion para moldear un disco optico.Info
- Publication number
- ES2244705T3 ES2244705T3 ES02019181T ES02019181T ES2244705T3 ES 2244705 T3 ES2244705 T3 ES 2244705T3 ES 02019181 T ES02019181 T ES 02019181T ES 02019181 T ES02019181 T ES 02019181T ES 2244705 T3 ES2244705 T3 ES 2244705T3
- Authority
- ES
- Spain
- Prior art keywords
- information
- type
- frequency
- protocol
- module
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
- H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
- Debugging And Monitoring (AREA)
Abstract
Un procedimiento para enviar información que corresponde a al menos un dispositivo de red desde un monitor remoto (911) a un monitor central (945), que comprende la etapa de: interrogar (S 1502) a una primera frecuencia al al menos un dispositivo de red por el monitor remoto (911) usando un protocolo de administración de red por un primer tipo de información que corresponde al al menos un dispositivo de red.
Description
Matriz, procedimiento y dispositivo de moldeo por
inyección para moldear un disco óptico.
La presente solicitud está relacionada con la
solicitud de patente de EE.UU. 09/190.460, presentada el 13 de
noviembre de 1998, titulada "Method and System for Translating
Documents Using Different Translation Resources for Different
Portions of the Documents", que es una continuación de la
solicitud de patente de EE.UU. 08/654.207, presentada el 28 de mayo
de 1996, titulada "Method and System for Translating Documents
Using Different Translation Resources for Different Portions of the
Documents", ahora patente de EE.UU. 5.848.386; la solicitud de
patente de EE.UU. 08/997.705, presentada el 23 de diciembre de 1997,
titulada "Object-oriented System and Computer
Program Product for Mapping Structured Information to Different
Structured Information", ahora patente de EE.UU. 6.085.196; la
solicitud de patente de EE.UU. 08/997.705, presentada el 23 de
diciembre de 1997, titulada "Method and Apparatus for Providing a
Graphical User Interface for Creating and Editing a Mapping of a
First Structural Description to a Second Structural Description";
la solicitud de patente de EE.UU. 09/756.120, presentada el 9 de
enero de 2001, titulada "Method and System of Remote Support Of
Device Using Email"; la solicitud de patente de EE.UU.
09/668.162, presentada el 25 de septiembre de 2000, titulada
"Method and System of Data collection and Mapping From a Remote
Position Reporting Device"; la solicitud de patente de EE.UU.
09/575.710, presentada el 25 de julio de 2000, titulada "Method
and System of Remote Diagnostic and Information Collection and
Service System"; la solicitud de patente de EE.UU. 09/575.702,
presentada el 12 de julio de 2000, titulada "Method and System of
Remote Position Report Device" la solicitud de patente de EE.UU.
09/453.934, presentada el 17 de mayo de 2000, titulada "Method and
System of Remote Diagnostic, Control and Information Collection
Using a Dynamic Linked Library for Multiple Formats and Multiple
Protocols"; la solicitud de patente de EE.UU. 09/453.935,
presentada el 17 de mayo de 2000, titulada "Method and System of
Remote Diagnostic, Control and Information Collection Using a
Dynamic Linked Library of Multiple Formats and Multiple Protocols
With Intelligent Protocol Processor"; la solicitud de patente de
EE.UU. 09/453.937, presentada el 17 de mayo de 2000, titulada
"Method and System of Remote Diagnostic Control and Information
Collection Using a Dynamic Linked Library of Multiple Formats and
Multiple Protocols With Restriction on Protocol"; la solicitud de
patente de EE.UU. 09/453.936, presentada el 17 de mayo de 2000,
titulada "Method and System of Remote Diagnostic, Control and
Information Collection Using a Dynamic Linked Library of Multiple
Formats and Multiple Protocols with Intelligent Formatter"; la
solicitud de patente de EE. UU 09/542.284, presentada el 4 de abril
de 2000, titulada "System and Method to Display Various Messages
While Performing the Tasks or While Idling"; la solicitud de
patente de EE.UU. 09/520.368, presentada el 7 de marzo de 2000,
titulada "Method and System for Updating the Device Driver of a
Business Office Appliance"; la solicitud de patente de EE.UU.
09/453.877, presentada el 4 de febrero de 2000, titulada "Method
and System for Maintaining a Business Office Appliance through Log
Files"; la solicitud de patente de EE.UU. 09/440.692, presentada
el 16 de noviembre de 1999, titulada "Method and System to Monitor
the Application Usage and Send Back the Information Using Connection
and Connectionless Mode"; la solicitud de patente de EE.UU.
09/440.693, presentada el 16 de noviembre de 1999, titulada
"Method and System of Remote Diagnostic, Control and Information
Collection Using a Dynamic Linked Library"; la solicitud de
patente de EE.UU. 09/440.647, presentada el 16 de noviembre de 1999,
titulada "Method and System to Monitor the Application Usage and
Send Back the Information Using Connection and Connectionless
Mode"; la solicitud de patente de EE.UU. 09/440.646, presentada
el 16 de noviembre de 1999, titulada "Method and System to Monitor
the Application Usage and Send Back the Information Using Connection
and Connectionless Mode"; la solicitud de patente de EE.UU.
09/440.645, presentada el 16 de noviembre de 1999, titulada
"Application Unit Monitoring and Reporting System and Method With
Usage Data Logged Into a Map Structure"; la solicitud de patente
de EE.UU. 09/408.443, presentada el 29 de septiembre de 1999,
titulada "Method and System for Remote Diagnostic, Control and
Information Collection Based on various Communication MOdes for
Sending Messages to a Resource Manager"; la solicitud de patente
de EE.UU. 09/407.769, presentada el 29 de septiembre de 1999,
titulada "Method and System for Remote Diagnostic, Control and
Information Collection Based on various Communication Modes for
Sending Messages to Users"; la solicitud de patente de EE.UU.
09/393.677, presentada el 10 de septiembre de 1999, titulada
"Application Unit Monitoring and Reporting System and Method";
la solicitud de patente de EE.UU. 09/311.148, presentada el 13 de
mayo de 1999, titulada "Application Unit Monitoring and Reporting
System and Method"; la solicitud de patente de EE.UU. 09/192.583,
presentada el 17 de noviembre de 1998, titulada "Method and System
for Communicating With a Device Attached to a Computer Using
Electronic Mail Messages"; la solicitud de patente de EE.UU.
08/883.492, presentada el 26 de junio de 1997, titulada "Method
and System for Diagnosis and Control of Machines Using
Connectionless Modes Having Delivery Monitoring and an Alternate
Communication Mode"; la solicitud de patente de EE.UU.
08/820.633, presentada el 19 de marzo de 1997, titulada "Method
and System to Diagnose a Business Office Device Based on Operating
Parameters Set by a User", ahora patente de EE.UU. 5.887.216; la
solicitud de patente de EE.UU. 08/733.134, presentada el 16 de
octubre de 1996, titulada "Method and System for Diagnosis and
Control of Machines Using Connectionless Modes of Communication",
ahora patente de EE.UU. 5.909.493; la solicitud de patente de EE.UU.
08/880.683, presentada el 23 de junio de 1997, las solicitudes de
patente de EE.UU. 09/107.989 y 09/108.705, las cuales fueron
presentadas el 1 de julio de 1998, tituladas las tres "Method and
System for Controlling and Communicating with Machines Using
Multiple Communication Formats", y las tres son divisiones de la
solicitud de patente de EE.UU. 08/624.228, presentada el 29 de marzo
de 1996, titulada "Method and System for Controlling and
Communicating with Machines Using Multiple Communication
Formats", ahora patente de EE.UU. 5.818.603; la solicitud de
patente de EE.UU. 09/457.669, titulada "Method and System for
Diagnosis and Control of Machines Using Connection and
Connectionless Modes of Communication", presentada el 9 de
diciembre de 1999, que es una continuación de la solicitud de
patente de EE.UU. 08/916.009, titulada "Method and System for
Diagnosis and Control of Machines Using Connection and
Connectionless Modes of Communication", presentada el 21 de
agosto de 1997, que es una continuación de las solicitudes de
patente de EE.UU. 08/738.659 y 08/738.461, presentadas el 30 de
octubre de 1996, tituladas las dos "Method and System for
Diagnosis and Control of Machines Using Connection and
Connectionless Modes of Communication", que son divisiones de la
solicitud de patente de EE.UU. 08/463.002, presentada el 5 de junio
de 1995, titulada "Method and System for Diagnosis and Control of
Machines Using Connection and Connectionless Modes of
Communication", ahora patente de EE.UU. 5.819.110; la solicitud
de patente de EE.UU. 08/852.413, presentada el 7 de mayo de 1987,
titulada "Method and System for Controlling and Communicating with
Business Office Devices", ahora patente de EE.UU. 5.774.678, que
es una continuación de la solicitud de patente de EE.UU. 08/698.068,
presentada el 15 de agosto de 1996, titulada "Method and Apparatus
for Controlling and Communicating with Business Office Devices",
ahora patente de EE.UU. 5.649.120, que es una continuación de la
solicitud de patente de EE.UU. 08/562.192, presentada el 22 de
noviembre de 1995, ahora patente de EE.UU. 5.568.618, titulada
"Method and Apparatus for Controlling and Communicating With
Business Office Devices", que es una continuación de la solicitud
de patente de EE.UU. 08/473.780, presentada el 6 de junio de 1995,
titulada "Method and Apparatus for Controlling and Communicating
With Business Office Devices", ahora patente de EE.UU. 5.544.289,
que es una continuación de la solicitud de patente de EE.UU.
08/426.679, presentada el 24 de abril de 1995, titulada "Method
and Apparatus for Controlling and Communicating With Business Office
Devices", ahora patente de EE.UU. 5.537.554, que es una
continuación de la solicitud de patente de EE.UU. 08/282.168,
presentada el 28 de julio de 1994, titulada "Method and Apparatus
for Controlling and Communicating With Business Office Devices",
ahora patente de EE.UU. 5.412.779; la solicitud de patente de EE.UU.
09/953.359, presentada el 17 de septiembre de 2001, publicación Nº
2003-0055963, titulada "SYSTEM, METHOD, AND
COMPUTER PROGRAM PRODUCT FOR SENDING REMOTE DEVICE CONFIGURATION
INFORMATION TO A MONITOR USING E-MAIL"; y la
solicitud de patente de EE.UU. 09/953.358, presentada el 17 de
septiembre de 2001, publicación Nº 2003-0055952,
titulada "SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR
TRANSFERRING REMOTE DEVICE SUPPORT DATA TO A MONITOR USING
E-MAIL".
Esta invención trata de sistemas, procedimientos,
y programas informáticos para monitorizar dispositivos
interconectados. Más específicamente, de sistemas, procedimientos y
programas informáticos para recoger y enviar diferentes tipos de
información relacionada con dispositivos conectados a múltiples
redes desde un monitor remoto a un monitor central. Los diferentes
tipos de información pueden ser recogidos en diferentes frecuencias.
La información recogida entre transmisiones posteriores de
información al monitor central es mantenida por el monitor remoto
para enviarla con la siguiente transmisión.
La solicitud de patente de EE.UU. pendiente de
tramitación Nº de serie 09/756.120, presentada el 09 de enero de
2001, describe un sistema para monitorizar a distancia dispositivos
interconectados usando correo electrónico. Según se describe en esa
solicitud, el Protocolo Simple de Administración de Redes (SNMP) es
usado por un monitor remoto para recoger información de dispositivos
interconectados. La información recogida se envía luego a un monitor
central usando, por ejemplo, correo electrónico.
La solicitud de patente europea
EP-0951155-A1 trata de un
procedimiento y un sistema para administración de redes y sistemas.
El procedimiento para administración de redes comprende al menos un
administrador adjunto situado en un árbol de contenido entre un
administrador principal y las unidades de equipo de una red de área
local. El administrador adjunto está situado en la red de área local
y está administrado por el administrador principal. Una subred
comprende diversos módulos que se comunican entre sí y con el
administrador principal a través de un núcleo. Los módulos
interrogan al equipo de la subred y reciben las alarmas enviadas por
agentes (SNMP) que operan en las unidades de equipo de la red.
Los dispositivos conectados a una red pueden ser
monitorizados por un monitor remoto para diferentes tipos de
información. Alguna o toda esa información puede ser enviada o no a
un monitor central a una misma frecuencia a medida que es recogida.
Por ejemplo, un monitor remoto puede interrogar a dispositivos para
un primer tipo de información más frecuentemente que la información
que es enviada a un monitor central. Por consiguiente, es posible,
por ejemplo, que pudieran haberse generado y corregido condiciones
de error durante el tiempo entre informes posteriores al monitor
central. Si la información enviada al monitor central incluye sólo
la información que fue recogida por le monitor remoto inmediatamente
antes de enviar la información, el monitor central no recibirá
información concerniente, por ejemplo, a condiciones que surgieron
desde la última transmisión de información y que fueron despejadas
antes de la transmisión actual de información.
Los inventores de la presente invención han
reconocido que sería ventajoso para un monitor remoto de
dispositivos conectados a una red almacenar un primer tipo de
información en una base de datos, de manera que al mandar
información a un monitor central, el monitor remoto puede enviar no
sólo información actual, sino también información en cuanto a
cambios que han ocurrido entre periodos de informe, según se indica
por el primer tipo de información almacenado en la base de
datos.
La presente invención proporciona un sistema,
procedimiento y programa informático mediante los cuales los
dispositivos que residen en una red son monitorizados por un monitor
remoto en la red y la información relacionada con esos dispositivos
es enviada a un monitor central. En una realización de la presente
invención, el monitor remoto interroga a los dispositivos
interconectados para un primer tipo de información más
frecuentemente que de lo que manda la información al monitor
central. El monitor remoto almacena el primer tipo de información
en una base de datos. Cuando el monitor remoto manda información al
monitor central, interroga a los dispositivos interconectados por le
primer tipo actual de información y un segundo tipo de información,
y manda no sólo esa información actual, sino que también envía el
primer tipo de información desde la base de datos. Cuando la
información es enviada al monitor central, la base de datos se pone
a cero de manera que pueda empezar la recogida del primer tipo de
información para el siguiente ciclo de monitorización. Una ventaja
de la presente invención es que el monitor central puede recibir
información de muchas redes remotas con un intervalo menos frecuente
sin sacrificar el nivel de detalle de la información recogida.
Almacenando en una base de datos el primer tipo de información
recogido más frecuentemente, el monitor remoto puede informar sobre
cambios en el primer tipo de información que ocurrieron entre
transmisiones de información al monitor central, permitiendo que el
monitor remoto mande información con una granularidad más fina para
algunos tipos de información que una granularidad de las
transmisiones de información al monitor central.
Consecuente con el título de esta sección, el
resumen anterior no pretende ser un análisis exhaustivo de todas las
características o realizaciones de la presente invención. Una
descripción más completa, aunque no necesariamente exhaustiva de las
características y realizaciones de la invención se encuentra en la
sección titulada "Descripción de las realizaciones
preferidas".
Se obtendrá fácilmente una apreciación más
completa de la invención y de muchas de las ventajas que conlleva la
misma a medida que la misma se entienda mejor por referencia a la
descripción detallada siguiente cuando se considera con relación a
los dibujos adjuntos, en los que:
La Figura 1 ilustra tres dispositivos
interconectados de oficina comercial conectados a una red de
ordenadores y bases de datos a través de Internet;
La Figura 2 ilustra los componentes de un
aparato de formación de imágenes digitales;
La Figura 3 ilustra los componentes electrónicos
del aparato de formación de imágenes digitales ilustrado en la
Figura 2;
La Figura 4 ilustra detalles de una interfaz de
comunicación multipuerto ilustrada en la Figura 3;
La Figura 5 ilustra una configuración de sistema
alternativo en que los dispositivos de oficina comercial están
conectados directamente a la red o conectados a un ordenador que
está conectado a la red;
La Figura 6A es un diagrama de bloques que
ilustra un flujo de información a y desde una unidad de aplicación
que usa correo electrónico;
La Figura 6B ilustra una manera alternativa de
comunicación que usa correo electrónico en la que un ordenador que
está conectado a la unidad de aplicación también sirve de agente de
transferencia de mensajes (MTA);
La Figura 6C ilustra una manera alternativa de
comunicación que usa correo electrónico en la que una unidad de
aplicación incluye un agente de transferencia de mensajes para
intercambiar correo electrónico;
La Figura 6D ilustra una manera alternativa de
comunicación que usa correo electrónico en la que un servidor de
correo hace de servidor POP3 para recibir correo para un aparato
/dispositivo y de servidor de protocolo simple de transferencia de
correo (SMTP) para enviar correo para el aparato /dispositivo;
La Figura 7 ilustra una manera alternativa de
enviar mensajes a través de Internet;
La Figura 8 ilustra un ordenador ejemplar que
puede ser conectado a un aparato /dispositivo y usado para comunicar
mensajes de correo electrónico;
La Figura 9 ilustra una configuración de sistema
global relacionada con la presente invención;
La Figura 10A ilustra una arquitectura de
software general de un módulo de envío de mensajes;
La Figura 10B ilustra una arquitectura de
software general de un módulo de recepción de mensajes;
La Figura 11 ilustra una arquitectura general de
un módulo de envío de mensajes;
La Figura 12 ilustra una arquitectura general de
un módulo de recepción de mensajes;
La Figura 13A es un organigrama que ilustra un
procedimiento implementado por el módulo de información de
dispositivos mostrado en la Figura 11;
La Figura 13B ilustra una estructura de clases
del módulo de información de dispositivos;
La Figura 14 es un diagrama de colaboración para
el módulo de información de dispositivos;
La Figura 15A es un organigrama que ilustra un
procedimiento implementado por el módulo monitor de dispositivos
mostrado en la Figura 11;
La Figura 15B ilustra una estructura de clases
del módulo monitor de dispositivos;
Las Figuras 16, 17 y 18 son diagramas de
colaboración para el módulo monitor de dispositivos;
La Figura 19A es un organigrama que ilustra un
procedimiento implementado para por el módulo de transferencia de
datos mostrado en la Figura 11;
La Figura 19B es un organigrama que ilustra un
procedimiento para enviar información según una realización de la
presente invención;
La Figura 19C ilustra una estructura de clases
del módulo de transferencia de datos;
Las Figuras 20A, 21, 22 y 23 son diagramas de
colaboración para le módulo de transferencia de datos al transferir
información al lugar de monitorización;
La Figura 20B ilustra un archivo adjunto MIME
(extensiones de correo de Internet multifunción) ejemplar que
incluye información de configuración según una realización de la
presente invención;
La Figura 20C ilustra un archivo adjunto MIME
ejemplar que incluye información de estado según una realización de
la presente invención; y
La Figura 24 ilustra un diagrama de clases del
módulo de interfaz de conectividad abierta de bases de datos
(ODBC).
Haciendo referencia ahora a los dibujos, y más
particularmente a la Figura 1 de los mismos, hay ilustradas (1)
diversas máquinas y (2) ordenadores para monitorizar, diagnosticar y
controlar el funcionamiento de las máquinas. En la Figura 1 hay una
primera red 16, como una red de área local (LAN) conectada a
estaciones de trabajo por ordenador 17, 18, 20 y 22. Las estaciones
de trabajo pueden ser cualquier tipo de ordenador, incluyendo, por
ejemplo, dispositivos compatibles con IBM Personal Computer,
ordenadores basados en UNIX, ordenadores basados en Linux u
ordenadores Apple Macintosh. También están conectados a la red 16
(1) un aparato de formación de imágenes digitales 24, (2) una
máquina de fax 28, y (3) una impresora 32. Como cualquier experto
normal en la materia apreciaría, pueden combinarse dos o más de los
componentes del aparato de formación de imágenes digitales 24 y la
máquina de fax 28 en un "aparato de formación de imágenes"
unificado. Se hace referencia a los dispositivos 24, 28 y 32 y las
estaciones de trabajo 17, 18, 20 y 22 como máquinas o dispositivos
monitorizados, y pueden usarse otros tipos de dispositivos como
máquinas o dispositivos monitorizados, incluyendo cualquiera de los
dispositivos analizados más adelante. En algunas configuraciones,
una o más estaciones de trabajo pueden ser convertidas en aparatos
de oficina comercial. Un ejemplo de tal aparato de oficina comercial
es eCabinet de Ricoh, del que se hizo una demostración en Fall
Comdex en 1999 en Las Vegas. También puede conectarse a la red 16 un
servidor de fax (no ilustrado) y tener una conexión telefónica, por
red digital de servicios integrados (ISDN), por cable o inalámbrica.
Además del aparato de formación de imágenes digitales 24, la máquina
de fax 28 y la impresora 32 que están conectados a la red 16, estos
dispositivos también pueden incluir teléfono convencional y/o
conexiones ISDN y/o por cable y/o inalámbrica 26, 30 y 34,
respectivamente. Como se explica más adelante, las máquinas de
oficina comercial, dispositivos comerciales o aparatos de oficina
comercial 24, 28 y 32 se comunican con una estación remota de
monitorización, diagnosis y control, a la que también se hace
referencia como dispositivo de monitorización, a través, por
ejemplo, de Internet por medio de la red 16 o mediante una conexión
directa telefónica, ISDN, inalámbrica o por cable.
En la Figura 1, una red de gran amplitud (WAN)
(por ejemplo, Internet o su sucesora) se designa en general por 10.
La WAN 10 puede ser una WAN privada, una WAN pública o un híbrido.
La WAN 10 incluye una pluralidad de ordenadores y encaminadores
interconectados designados por 12A-12I. La manera de
comunicarse sobre una WAN se conoce a través de una serie de
documentos de peticiones de comentarios (RFC) disponibles en el
Grupo de Trabajo de Ingeniería de Internet (IETF) en
http://www.ietf.org/rfc.html, que incluye RFC 821 titulado "Simple
Mail Transfer Protocol"; RFC 822 titulado "Standard for the
Format of ARPA Internet Text Message"; RFC 959 titulado "File
Transfer Protocol (FTP)"; RFC 2045 titulado "Multipurpose
Internet Mail Extensions (MIME)" Part One: Format of Internet
Message Bodies''; RFC 1894 titulado "An Extensible Message Format
for Delivery Status Notifications"; RFC 1939 titulado "Post
Office Protocol - Version 3"; y RFC 2298 titulado "An
Extensible Message Format for Message Disposition
Notifications".
La comunicación relacionada por el Protocolo de
Control de Transmisión/Protocolo Internet (TCP/IP) se describe, por
ejemplo, en el libro "TCP/IP Illustrated", Vol. 1, The
Protocols, de W. R. Stevens, de Addison-Wesley
Publishing Company, 1994, cuyo contenido entero se incorpora a este
documento por referencia. Los volúmenes 1-3 de
"Internetworking with TCP/IP" de Comer y Stevens también se
incorporan en su totalidad a este documento por referencia.
En la Figura 1, entre la WAN 10 y la red 16 está
conectado un cortafuego 50A. Un cortafuego es un dispositivo que
permite que sólo los ordenadores autorizados a un lado del
cortafuego accedan a una red, ordenadores o partes individuales a
otro lado del cortafuego. Los cortafuegos son dispositivos y/o
software conocidos y comercializados (por ejemplo, SunScreen de Sun
Microsystems Inc.). Igualmente, los cortafuegos 50B y 50C separan la
WAN 10 de una red 52 y una estación de trabajo 42, respectivamente.
Detalles adicionales sobre cortafuegos pueden encontrarse en
"Firewalls and Internet Security", de W. R. Cheswick y S. M.
Bellowin, 1994, Addison Wesley Publishing, y "Building Internet
Firewalls", de D. B. Chapman y E. D. Zwicky, 1995, O'Reilly &
Associates, Inc.
La red 52 es una red convencional e incluye una
pluralidad de estaciones de trabajo 56, 62, 68 y 74. Estas
estaciones de trabajo pueden estar en diferentes departamentos (por
ejemplo, departamentos de marketing, fabricación, ingeniería de
diseño y servicio de atención al cliente) dentro de una única
compañía. Además de las estaciones de trabajo conectadas por medio
de la red 52, hay una estación de trabajo 42 que no está conectada
directamente a la red 52. La información de una base de datos
almacenada en un disco 46 puede compartirse usando cifrado y
protocolos apropiados sobre la WAN 10 con las estaciones de trabajo
conectadas directamente a la red 52. También, la estación de trabajo
42 incluye una conexión directa a una línea telefónica y/o una red
ISDN y/o por cable y/o inalámbrica 44, y se puede acceder a la base
de datos del disco 46 a través de la línea telefónica, la ISDN, el
cable o por conexión inalámbrica. El cable usado por esta invención
puede implementarse usando un cable que se usa típicamente para
enviar programación de televisión, un cable que proporciona
comunicación a alta velocidad de datos digitales usado típicamente
con ordenadores o similares, o cualquier otro tipo de cable
deseado.
La información de las máquinas de oficina
comercial, dispositivos comerciales o aparatos de oficina comercial
24, 28 y 32 puede almacenarse en una o más de las bases de datos
almacenadas en los discos 46, 54, 58, 64, 70 y 76. Bases de datos
conocidas incluyen (1) bases de datos SQL de Microsoft, IBM, Oracle
y Sybase, (2) otras bases de datos relacionales, y (3) bases de
datos no relacionales (incluyendo bases de datos orientadas a
objetos de Computer Associates, JYD Software Engineering, y Orient
Technologies). Cada uno de los departamentos de servicio de atención
al cliente, marketing, fabricación e ingeniería puede tener su
propia base de datos o puede compartir una o más bases de datos.
Cada uno de los discos usados para almacenar bases de datos es una
memoria no volátil como un disco duro o un disco óptico.
Alternativamente, las bases de datos pueden almacenarse en cualquier
dispositivo de almacenamiento, incluyendo dispositivos de memoria de
estado sólido y/o semiconductor. Como ejemplo, el disco 64 contiene
la base de datos de marketing el disco 58 contiene la base de datos
de fabricación, el disco 70 contiene la base de datos de ingeniería
y el disco 76 contiene la base de datos del servicio de atención al
cliente. Alternativamente, los discos 54 y 46 almacenan una o más
bases de datos.
Además de las estaciones de trabajo 56, 62, 68,
74 y 42 que están conectadas a la WAN 10, estas estaciones de
trabajo incluyen una conexión a una línea telefónica, red ISDN, por
cable o inalámbrica que proporciona una conexión segura a la máquina
que se monitoriza, diagnostica y/o controla, y se usa durante la
comunicación. Además, si un medio de comunicación no está
funcionando correctamente, puede usarse automáticamente uno de los
otros para comunicación.
Una característica de la presente invención es el
uso de un modo de comunicación de "almacenamiento y
reexpedición" (por ejemplo, correo electrónico por Internet, al
que este documento también se refiere como correo electrónico) o
transmisión entre una máquina y un ordenador para diagnosticar y
controlar la máquina. Alternativamente, el mensaje que se transmite
puede implementarse usando un modo de comunicación que realiza
conexiones directas de extremo a extremo (por ejemplo, usando una
conexión por canal de comunicación al destino último) como FTP y
protocolo de transferencia de hipertexto (HTTP).
La Figura 2 ilustra una disposición mecánica del
aparato de formación de imágenes digitales 24 ilustrado en la Figura
1. En la Figura 2, 101 es un ventilador para el escáner, 102 es un
espejo poligonal usado con una impresora láser, y 103 designa una
lente F0 usada para colimar luz procedente de un láser (no
ilustrado). El número de referencia 104 designa un sensor para
detectar luz procedente del escáner. El número de referencia 105
designa una lente para enfocar luz procedente del escáner sobre el
sensor 104, y el número de referencia 106 designa una lámpara de
enfriamiento rápido usada para borrar imágenes en el tambor
fotoconductor 132. Hay una unidad de corona de carga 107 y un
rodillo de revelado 108. El número de referencia 109 designa una
lámpara usada para ilustrar un documento que va a ser escaneado y
110, 111 y 112 designan espejos usados para reflejar luz sobre el
sensor 104. Hay un espejo de tambor 113 usado para reflejar luz
hacia el tambor fotoconductor 132 procedente del espejo poligonal
102. El número de referencia 114 designa un ventilador usado para
enfriar el área de carga del aparato de formación de imágenes
digitales, y el número de referencia 115 designa un primer rodillo
alimentador de papel usado para alimentar papel desde la primera
cinta de papel 117, y el número de referencia 116 designa una mesa
de alimentación manual. Igualmente, el número de referencia 118
designa un segundo rodillo alimentador de papel para la segunda
cinta 119. El número de referencia 120 designa un rodillo repetidor,
121 designa un rodillo de registro, 122 designa un sensor de
densidad de imagen, y 123 designa una unidad de corona de
transferencia/separación. El número de referencia 124 designa una
unidad de limpieza, 125 designa un ventilador aspirante, 126 designa
una cinta transportadora, 127 designa un rodillo de presión, y 128
designa un rodillo de salida. El número de referencia 129 designa un
rodillo caliente usado para fijar tóner sobre el papel, 130 designa
un extractor de aire y 131 designa el motor principal usado para
accionar el aparato de formación de imágenes digitales.
La Figura 3 es un diagrama de bloques que ilustra
los componentes electrónicos del aparato de formación de imágenes
digitales de la Figura 2. La CPU 160 es un microprocesador y hace de
controlador del sistema. La memoria de acceso aleatorio (RAM) 162
almacena información que cambia dinámicamente que incluye parámetros
de funcionamiento del aparato de formación de imágenes digitales.
Una memoria no volátil (por ejemplo, una memoria de sólo lectura 10
(ROM) 164 o una memoria flash) almacena (1) el código de programa
usado para poner en funcionamiento el aparato de formación de
imágenes digitales y (2) datos de estado estático que describen la
copiadora (por ejemplo, el número de modelo, número de serie de la
copiadora, y parámetros por defecto).
Hay una interfaz de red multipuerto 166 que
permite que el aparato de formación de imágenes digitales se
comunique con dispositivos externos a través de al menos una red. El
número de referencia 168 representa una línea telefónica, ISDN o de
cable, y el número de referencia 170 representa otro tipo de red.
Detalles adicionales de la interfaz de red multipuerto se describen
en relación con la Figura 4. Se usa un controlador de interfaz 172
para conectar un panel de trabajo 174 a un bus de sistema 186. El
panel de funcionamiento 174 incluye dispositivos estándar de entrada
y salida encontrados en un aparato de formación de imágenes
digitales que incluyen un botón de copia, teclas para controlar el
funcionamiento de la copiadora, como número de copias,
reducción/aumento, oscuridad/claridad, etc. Además, dentro del panel
de funcionamiento 174 puede estar incluida una pantalla de cristal
líquido para mostrar a un usuario parámetros y mensajes del aparato
de formación de imágenes digitales.
Una interfaz de conexión local 171 es una
conexión a través de puertos locales como RS232, el puerto paralelo
de impresora, USB, e IEEE 1394. El puerto FireWire (IEEE 1394) se
describe en "The Facts About "FireWire"", de Wickelgren,
L, IEEE Spectrum, abril de 1997, Vol. 34, número 4, págs.
19-25. Preferentemente, se usa un protocolo de
comunicación "fiable" que incluye detección de errores y
retransmisión.
Una interfaz de almacenamiento 176 conecta
dispositivos de almacenamiento al bus de sistema 186. Los
dispositivos de almacenamiento incluyen una memoria flash 178, que
puede sustituirse por una memoria de sólo lectura programable
borrable eléctricamente (EEPROM) convencional, y un disco 182. El
disco 182 incluye un disco duro, disco óptico y/o disquetera. Hay
una conexión 180 conectada a la interfaz de almacenamiento 176 que
permite que sean conectados dispositivos de memoria adicionales al
aparato de formación de imágenes digitales. La memoria flash 178 se
usa para almacenar datos de estado semi-estático que
describen parámetros del aparato de formación de imágenes digitales
que rara vez cambian a lo largo de la vida de la copiadora. Tales
parámetros incluyen las opciones y la configuración del aparato de
formación de imágenes digitales. Una interfaz de opciones 184
permite que sea conectado hardware adicional, como una interfaz
externa, al aparato de formación de imágenes digitales. Se utiliza
un reloj/temporizador 187 para llevar el curso tanto de la hora como
de la fecha y también para medir el tiempo transcurrido.
En el lado izquierdo de la Figura 3 se ilustran
las diversas secciones que constituyen el dispositivo de formación
de imágenes digitales. El número de referencia 202 designa un
clasificador y contiene sensores y accionadores usados para
clasificar la salida del dispositivo de formación de imágenes
digitales. Hay un duplexor 200 que permite que sea realizada una
operación dúplex por el dispositivo de formación de imágenes
digitales e incluye sensores y accionadores convencionales. El
dispositivo de formación de imágenes digitales incluye una unidad
para bandejas de gran capacidad 198 que permite que se usen con el
dispositivo de formación de imágenes digitales bandejas para papel
que sostienen un gran número de hojas. La unidad para bandejas de
gran capacidad 198 incluye sensores y accionadores
convenciona-
les.
les.
Se usa un controlador de alimentación de papel
196 para controlar la operación de alimentación de papel a y a
través del dispositivo de formación de imágenes digitales. Se usa un
escáner 194 para escanear imágenes dentro del dispositivo de
formación de imágenes digitales e incluye elementos de escaneo
convencionales como una luz, espejo, etc. Además, se usan sensores
de escáner, como un sensor de posición inicial para determinar que
el escáner está en la posición inicial, y se usa un termistor de
lámpara para asegurar el funcionamiento correcto de la lámpara de
escaneo. Hay una impresora/dispositivo de imagen 192 que imprime la
salida del dispositivo de formación de imágenes digitales, e incluye
un mecanismo de impresión láser convencional, un sensor de tóner, y
un sensor de densidad de imagen. Se usa el fusor 190 para fundir el
tóner sobre la página usando un rodillo de alta temperatura e
incluye un sensor de salida, un termistor para asegurar que el fusor
190 no se está recalentando, y un sensor de aceite. Además, hay una
unidad de interfaz opcional 188 usada para conectarse a elementos
opcionales del dispositivo de formación de imágenes digitales, como
un alimentador automático de documentos, un tipo diferente de
clasificador/intercalador, u otros elementos que pueden añadirse al
dispositivo de formación de imágenes digitales.
La Figura 4 ilustra detalles de la interfaz de
red multipuerto 166. El dispositivo de formación de imágenes
digitales puede comunicarse a dispositivos externos a través de una
interfaz de red en anillo 220, una unidad de cable módem 222, que
tiene una alta velocidad de conexión por cable, una interfaz
telefónica convencional 224, que conecta a una línea telefónica
168A, una interfaz ISDN 226, que conecta a una línea ISDN 168B, una
interfaz inalámbrica 228, o una interfaz ethernet 230, que conecta a
una LAN 170. Otras interfaces pueden incluir, pero no están
limitadas a, una línea de abonado digital (DSL) (DSL original, DSL
concéntrica y DSL asimétrica). Un solo dispositivo que conecta tanto
a una red de área local como a una línea telefónica lo comercializa
Megahertz y se conoce como Módem-Ethernet.
La CPU u otro microprocesador o sistema de
circuitos ejecuta un procedimiento de monitorización para
monitorizar el estado de cada uno de los sensores del dispositivo de
formación de imágenes digitales, y se usa un procedimiento de
secuenciado para ejecutar las instrucciones del código usado para
controlar y hacer funcionar el dispositivo de formación de imágenes
digitales. Además, hay (1) un procedimiento de control de sistema
central ejecutado para controlar el funcionamiento global del
dispositivo de formación de imágenes digitales, y (2) un
procedimiento de comunicación usado para asegurar la comunicación
fiable hacia dispositivos externos conectados al dispositivo de
formación de imágenes digitales. El procedimiento de control de
sistema monitoriza y controla el almacenamiento de datos en una
memoria de estado estático (por ejemplo, la ROM 164 de la Figura 3),
una memoria semiestática (por ejemplo, la memoria flash 178 o el
disco 182), o la memoria de estado dinámico (por ejemplo, una
memoria volátil o no volátil (por ejemplo, la RAM 162 o la memoria
flash 178 o el disco 182)). Además, la memoria de estado estático
puede ser un dispositivo distinto de la ROM 164, como una memoria no
volátil que incluye la memoria flash 178 o el disco 182.
Los detalles anteriores han sido descritos en
relación con un dispositivo de formación de imágenes digitales, pero
la presente invención es igualmente aplicable a otras máquinas o
dispositivos de oficina comercial, como una copiadora analógica, una
máquina de fax, un escáner, una impresora, un servidor de fax u
otras máquinas de oficina comercial, un aparato de oficina
comercial, u otros aparatos (por ejemplo, un horno de microondas,
VCR, cámara digital, teléfono celular, ordenador de mano). Además,
la presente invención incluye otros tipos de dispositivos que
funcionan usando comunicación basada en almacenamiento y
reexpedición o en conexión directa. Tales dispositivos incluyen
sistemas de medición (que incluyen sistemas de medición de gas, agua
o electricidad), máquinas expendedoras, o cualquier dispositivo
mecánico (por ejemplo, automóviles) que tenga que ser monitorizado
durante el funcionamiento o diagnosis remota. Además de monitorizar
máquinas de propósito especial y ordenadores, la invención puede
usarse para monitorizar, controlar y diagnosticar un ordenador de
uso general que podría ser el dispositivo monitorizado y/o
controlado.
La Figura 5 ilustra un diagrama de sistema
alternativo de la presente invención en el que diferentes
dispositivos y subsistemas están conectados a la WAN 10. Sin
embargo, no hay necesidad de tener cada uno de estos dispositivos o
subsistemas como parte de la invención.
Cada componente o subsistema ilustrado en la
Figura 5 es individualmente parte de la invención. Además, los
elementos ilustrados en la Figura 1 pueden conectarse a una WAN 10
que se ilustra en la Figura 5. En la Figura 5 hay ilustrado un
cortafuego 50-1 conectado a una intranet
260-1. Una máquina de servicio 254 conectada a la
intranet 260-1 incluye en ella, o tiene conectados a
la misma, datos 256 que pueden almacenarse en un formato de base de
datos. Los datos 256 incluyen historial, rendimiento,
malfuncionamiento y cualquier otra información, como información
estadística del funcionamiento o fallo o configuración de los
dispositivos monitorizados, o información de configuración como qué
componentes o equipos opcionales están incluidos con los
dispositivos monitorizados. La máquina de servicio 254 puede
implementarse como el dispositivo u ordenador que solicita que los
dispositivos monitorizados transmitan datos, o que solicita que se
realice control remoto y/o pruebas de diagnóstico sobre los
dispositivos monitorizados. La máquina de servicio 254 puede
implementarse como cualquier tipo de dispositivo, y se implementa
preferentemente usando un dispositivo computerizado, como un
ordenador de uso general.
Otro subsistema de la Figura 5 incluye un
cortafuego 50-2, una intranet 260-2,
y una impresora 262 conectados al mismo. En este subsistema, las
funciones de enviar y recibir mensajes electrónicos por la impresora
262 (e igualmente por una copiadora 2869 son realizados por (1) un
sistema de circuitos, (2) un microprocesador , o (3) cualquier otro
tipo de hardware contenido o montado en la impresora 262 (es decir,
sin usar un ordenador de uso general sepa-
rado).
rado).
Un tipo alternativo de subsistema incluye el uso
de un proveedor de servicios de Internet 264 que puede ser cualquier
tipo de proveedor de servicios de Internet (ISP), incluyendo
compañías comerciales conocidas como America Online, Earthlink y
Niftyserve. En este subsistema, un ordenador 266 está conectado al
ISP 264 a través de un módem digital o analógico (por ejemplo, un
módem de línea telefónica, un cable módem, módems que usan cualquier
tipo de cables, como módems usados sobre una línea de red digital de
servicios integrados (ISDN) o una línea asimétrica de abonado
digital (ADSL), módems que usan comunicación por retransmisión de
tramas, módems inalámbricos, como un módem por radiofrecuencia, un
módem de fibra óptica, o un dispositivo que usa ondas de luz
infrarroja). Además, un dispositivo de oficina comercial 268 está
conectado al ordenador 266. Como alternativa al dispositivo de
oficina comercial 268 (o a cualquier otro dispositivo ilustrado en
la Figura 5), puede monitorizarse o controlarse un tipo diferente de
máquina, como una copiadora digital, cualquier tipo de aparato,
sistema de seguridad o medidor utilitario, como un medidor
utilitario de electricidad, agua o gas, o cualquier otro dispositivo
analizado en este documento.
También está ilustrado en la Figura 5 un
cortafuego 50-3 conectado a una red 274. La red 274
puede implementarse como cualquier tipo de red de ordenadores (por
ejemplo, una red ethernet o en anillo). El software de conexión en
red que puede usarse para controlar la red incluye cualquier
software de conexión en red deseado, incluyendo software
comercializado por Novell o Microsoft. Si se desea, la red 274 puede
implementarse como intranet. Puede usarse un ordenador 272 conectado
a la red 274 para obtener información de un dispositivo de oficina
comercial 278 y generar informes, como informes que informes que
muestran problemas que se produjeron en diversas máquinas conectadas
a la red, y un informe de uso mensual de los dispositivos conectados
a la red 274. En esta realización, entre el dispositivo de oficina
comercial 278 y la red 274 está conectado un ordenador 276. Este
ordenador recibe comunicaciones desde la red y reexpide las señales
de control o datos apropiados, o cualquier otra información, al
dispositivo de oficina comercial 278. La comunicación entre el
dispositivo de oficina comercial 278 y el ordenador 276 puede
lograrse usando procedimientos basados en cable o inalámbricos que
incluyen, pero no se limitan a, conexiones por radiofrecuencia,
conexiones eléctricas y conexiones por luz (por ejemplo, una
conexión infrarroja, o una conexión por fibra óptica). Igualmente,
cada una de las diversas redes e intranets ilustradas en la Figura 5
puede establecerse usando cualquier manera deseada incluyendo por el
establecimiento de redes inalámbricas, como redes por
radiofrecuencia. La comunicación inalámbrica descrita en este
documento puede establecerse usando técnicas de espectro ensanchado,
incluyendo técnicas que usan un código de ensanchamiento y técnicas
de salto de frecuencia como la técnica inalámbrica de salto de
frecuencia que se describe en la Bluetooth Specification LOA
(disponible en el sitio web www.bluetooth.com)
Otro subsistema ilustrado en la Figura 5 incluye
un cortafuego 50-4, una intranet
260-4, un ordenador 282 conectado a la misma, un
aparato de oficina comercial 285 y una copiadora 286. El ordenador
282 puede usarse para generar informes y solicitar procedimientos de
diagnóstico y control. Estos procedimientos de diagnóstico y control
pueden realizarse en relación con el aparato de oficina comercial
285 y la copiadora 286 o cualquiera de los otros dispositivos
ilustrados o usados en la Figura 5. Aunque la Figura 5 ilustra una
pluralidad de cortafuegos, los cortafuegos son equipos preferibles
pero opcionales, y, por lo tanto, la invención puede hacerse
funcionar sin el uso de cortafuegos, si se desea.
La Figura 6A ilustra un dispositivo/aparato 300
conectado a un sistema típico de intercambio de correo electrónico
que incluye componentes 302, 304, 306, 308, 310, 312, 314, 316 y
318, que pueden implementarse de manera convencional, y están
adaptados de la Figura 28.1 del documento de Stevens citado
anteriormente. Una interfaz de ordenador 302 conecta con cualquiera
de las unidades de aplicación o dispositivos/aparatos 300 descritos
en este documento. Aunque la Figura 6A ilustra que el
dispositivo/aparato 300 es el remitente, las funciones de envío y
recepción pueden invertirse en la Figura 6A. Además, si se desea, el
usuario puede no tener que comunicarse para nada con el
dispositivo/aparato 300. La interfaz de ordenador 302 interactúa
entonces con un agente de correo 304. Agentes de correo populares
para Unix incluyen MH, Berkeley Mail, Elm y Mush. Agentes de correo
para la familia de sistemas operativos Windows incluyen Microsoft
Outlook y Microsoft Outlook Express. A petición de la interfaz de
ordenador 302, el agente de correo 304 crea mensajes de correo
electrónico que van a enviarse y, si se desea, coloca estos mensajes
que van a enviarse en una cola 306. El correo que debe enviarse se
reexpide a un agente de transferencia de mensajes (MTA) 308. Un MTA
común para sistemas Unix es Sendmail. Típicamente, los agentes de
transferencia de mensajes 308 y 312 intercambian comunicaciones
usando una conexión TCP/IP 310. Particularmente, la comunicación
entre los agentes de transferencia de mensajes 308 y 312 puede
producirse sobre una red de cualquier tamaño (por ejemplo, WAN o
LAN). Además, los agentes de transferencia de mensajes 308 y 312
pueden usar cualquier protocolo de comunicación. En una realización
de la presente invención, los elementos 302 y 304 de la Figura 6A
residen en la biblioteca para monitorizar el uso de la unidad de
aplicación.
Desde el agente de transferencia de mensajes 312,
los mensajes de correo electrónico se almacenan en buzones de correo
del usuario 314 que se transfieren al agente de correo 316 y, por
último, se transmiten al usuario en un terminal 318 que funciona
como terminal de correo entrante.
El procedimiento de "almacenamiento y
reexpedición" libera al agente de correo saliente 304 de tener
que esperar hasta que se establece una conexión directa con el
destinatario de correo. Debido a los retrasos de la red, la
comunicación podría requerir una cantidad de tiempo sustancial
durante el cual la aplicación no respondería. Tal falta de respuesta
es generalmente inaceptable para usuarios de la unidad de
aplicación. Usando correo electrónico como el procedimiento de
almacenamiento y reexpedición, se producen automáticamente intentos
de retransmisión después de fallos durante un periodo de tiempo fijo
(por ejemplo, tres días). En una realización alternativa, la
aplicación puede evitar esperar pasando peticiones de comunicación a
uno o más hilos separados. Esos hilos pueden entonces controlar la
comunicación con el terminal de correo entrante 318 mientras la
aplicación comienza a responder de nuevo a la interfaz de usuario.
En otra realización más en la que un usuario desea haber completado
la comunicación antes de continuar, se usa comunicación directa con
el terminal de correo entrante. Tal comunicación directa puede
utilizar cualquier protocolo no bloqueado por un cortafuego entre
los terminales de correo saliente y de correo entrante. Ejemplos de
tales protocolos incluyen el protocolo de transferencia de archivos
(FTP) y el protocolo de transferencia de hipertexto (HTTP).
Las WAN públicas, como Internet, generalmente no
se consideran seguras. Por lo tanto, si se desea mantener los
mensajes confidenciales, los mensajes transmitidos sobre las WAN
públicas (y WAN privadas multicompañía) pueden ser cifrados. Hay
mecanismos de cifrado conocidos y comercializados que pueden usarse
con la presente invención. Por ejemplo, Sun Microsystems
comercializa una función de biblioteca de C++, crypt(), para uso con
el sistema operativo Unix. Hay otros paquetes de software de cifrado
y descifrado conocidos y comercializados y también pueden usarse con
esta invención. Uno de tales paquetes es PGP Virtual Private Network
(VPN) comercializado por Network Associates. Microsoft Corporation
comercializa otro software VPN.
Como alternativa a la estructura general de la
Figura 6A, puede usarse un solo ordenador que funciona como la
interfaz de ordenador 302, el agente de correo 304, la cola de
correo 306 y el agente de transferencia de mensajes 308. Según se
ilustra en la Figura 6B, el dispositivo/aparato 300 está conectado a
un ordenador 301 que incluye el agente de transferencia de mensajes
308.
En la Figura 6C se muestra una estructura
alternativa más en la que el agente de transferencia de mensajes 308
está formado como parte del dispositivo/aparato 300. Además, el
agente de transferencia de mensajes 300 está conectado al agente de
transferencia de mensajes 312 por una conexión TCP/IP 310. En la
realización de la Figura 6C, el dispositivo/aparato 300 está
conectado directamente a la conexión TCP/IP 310 con una capacidad de
correo electrónico. Un uso de la realización de la Figura 6C incluye
usar una máquina de fax con una capacidad de correo electrónico (por
ejemplo, según se define en RFC 2305 (un modo simple de fax que usa
correo Internet)) como el dispositivo/aparato 300.
La Figura 6D ilustra un sistema en que un
dispositivo/aparato 300 no tiene por sí mismo la capacidad de
recibir directamente correo electrónico, pero tiene una conexión 310
a un servidor de correo/servidor POP3 que incluye un agente de
transferencia de mensajes 308 y un buzón de correo 314 de manera que
el dispositivo/aparato 300 usa el protocolo POP3 para recuperar
correo recibido del servidor de correo.
La Figura 7 ilustra una implementación
alternativa de transferencia de correo y está adaptada de la Figura
28.3 del documento de Stevens al que se hace referencia previamente.
La Figura 7 ilustra un sistema de correo electrónico que tiene un
sistema de retransmisión en cada extremo. La disposición de la
Figura 7 permite que un sistema en una organización haga de
concentrador de correo. En la Figura 7, hay cuatro MTA conectados
entre los dos agentes de correo 304 y 316. Estos MTA incluyen el MTA
local 322A, el MTA de retransmisión 328A, el MTA de retransmisión
328B y el MTA local 322D. El protocolo más común usado para mensajes
de correo es SMTP (protocolo simple de transferencia de correo) que
puede usarse con esta invención, aunque puede utilizarse cualquier
protocolo de correo deseado. En la Figura 7, 320 designa un servidor
de correo saliente que incluye la interfaz de ordenador 302, el
agente de correo 304, y el MTA local 322A. El dispositivo/aparato
300 está conectado a, o alternativamente incluido en, el servidor de
correo saliente 320. Como otro caso, el dispositivo/aparato 300 y el
servidor 320 pueden estar en una máquina donde la capacidad del
servidor está incorporada al dispositivo/aparato 300.También pueden
estar incluidos otros MTA locales 322B, 322C, 322D y 322E. El correo
que va a ser transmitido y recibido puede ponerse en una cola de
correo 306B del MTA de retransmisión 328A. Los mensajes se
transfieren a través de la conexión TCP/IP 310 (por ejemplo, una
conexión de Internet o una conexión a través de cualquier otro tipo
de red).
Los mensajes transmitidos son recibidos por el
MTA de retransmisión 328B y, si se desea, son almacenados en una
cola de correo 306C. El correo se reexpide luego hacia el MTA local
322D de un servidor de correo entrante 342. El correo puede
colocarse en uno o más buzones de correo 314 del usuario y
posteriormente reexpedirse al agente de correo 316, y, por último,
reexpedirse al usuario en un terminal 318. Si se desea, el correo
puede reexpedirse directamente al terminal sin interacción con el
usuario.
Los diversos ordenadores usados en la presente
invención, incluyendo los ordenadores 266 y 267 de la Figura 5,
pueden implementarse como se ilustra en la Figura 8. Además,
cualquier otro ordenador usado en esta invención puede implementarse
de manera similar al ordenador ilustrado en la Figura 8, si se
desea, incluyendo la máquina de servicio 254, el ordenador 272 y el
ordenador 282 de la Figura 5. Sin embargo, no se requieren todos los
elementos ilustrados en la Figura 8 en cada uno de esos
ordenadores.
En la Figura 8, el ordenador 360 incluye una CPU
362 que puede implementarse como cualquier tipo de procesador,
incluyendo procesadores comercializados por compañías como Intel,
AMD, Motorola, Hitachi y NEC. Hay una memoria de trabajo como una
RAM 364, y una interfaz inalámbrica 366 que comunica con un
dispositivo inalámbrico 368. La comunicación entre la interfaz 366 y
el dispositivo 368 puede usar cualquier medio inalámbrico (por
ejemplo, ondas de radio u ondas de luz). Las ondas de radio pueden
implementarse usando una técnica de espectro ensanchado como
comunicación por acceso múltiple por división de código (CDMA) o
usando una técnica de salto de frecuencia como la descrita en la
especificación Bluetooth.
Hay una ROM 370 y una memoria flash 371, aunque
puede usarse cualquier otro tipo de memoria no volátil (por ejemplo,
ROM programable borrable, o una EEPROM) además o en lugar de la
memoria flash 371. Un controlador de entrada 372 tiene un teclado
374 y un ratón 376 conectados al mismo. Hay una interfaz en serie
378 conectada a un dispositivo en serie 380. Además, una interfaz
paralela 382 está conectada a un dispositivo en paralelo 384, una
interfaz de bus serie universal (USB) 386 está conectada a un
dispositivo de bus serie universal 388, y también hay un dispositivo
IEEE 1394 400, al que se alude comúnmente como dispositivo fire
wire, conectado a una interfaz IEEE 1394 398. Los diversos elementos
del ordenador 360 están conectados por un bus del sistema 390. Un
controlador de disco 396 está conectado a una disquetera 394 y a una
unidad de disco duro 392. Un controlador de comunicación 400 permite
que el ordenador 360 se comunique con otros ordenadores (por
ejemplo, enviando mensajes de correo electrónico) sobre una línea
telefónica 402 o una red 404. Un controlador I/O (de entrada/salida)
408 está conectado a una impresora 410 y a un disco duro 412 usando,
por ejemplo, un bus SCSI (interfaz de sistema de ordenadores
pequeños). También hay un controlador de pantalla 416 conectado a un
CRT (tubo de rayos catódicos) 414, aunque puede usarse cualquier
otro tipo de pantalla, incluyendo una pantalla de cristal líquido,
una pantalla de diodos emisores de luz, una pantalla de plasma,
etc.
La Figura 9 ilustra una aplicación de la presente
invención. Los dispositivos 901, 903, 905 y 907 que están conectados
a la Intranet 910 son los dispositivos que van a ser monitorizados
localmente por una estación de trabajo de monitorización remota 911
con su base de datos 913. Alternativamente, la estación de trabajo
de monitorización remota 911 puede funcionar para enviar la
información de estado del dispositivo a la estación de trabajo de
monitorización central 945 interrogando por la información
procedente de los dispositivos monitorizados 901, 903, 905 y 907 y
enviando la información a través del cortafuego 917. Por lo tanto,
la estación de trabajo de monitorización remota 911 puede funcionar
como dispositivo de monitorización o como dispositivo de
comunicación y administrativo entre los dispositivos monitorizados y
el dispositivo de monitorización. En la Figura 9, la estación de
trabajo de monitorización remota 911 usa el protocolo simple de
administración de redes (SNMP) definido por IETF para comunicarse
con los dispositivos conectados. El protocolo SNMP se describe en
"Managing Internetworks with SNMP, third edition", de Mark A.
Miller, P. E. , M & T Book, 1999. Si alguno de los dispositivos
que van a ser monitorizados no soporta SNMP, la estación de trabajo
de monitorización remota 911 puede usar un procedimiento distinto
para obtener la información necesaria. Después de obtener la
información necesaria, la estación de trabajo de monitorización
remota 911 usa el servidor de protocolo simple de transferencia de
correo (SMTP) 915 para enviar la información necesaria a la estación
de trabajo de monitorización central 945 a través del servidor de
correo 943 que soporta el protocolo de oficina de correos versión 3
(POP3) (IETF Networking Group Request For Comments [RFC]: 1939). La
estación de trabajo de monitorización remota 911 usa SMTP (el SMTP
se define en IETF RFC 821) y posiblemente extensiones de correo de
Internet multifunción (MIME) para enviar correos electrónicos. La
estación de trabajo de monitorización remota 911 genera el mensaje
de correo que está en y por encima de la capa de aplicación del
modelo TCP/IP o del modelo ISO de siete capas, como se muestra
después. Alternativamente, la estación de trabajo de monitorización
remota 911 puede incluir un procesador SMTP para enviar la
información necesaria usando correo electrónico.
La LAN 920 y la intranet 930 envían información
similar a la estación de trabajo de monitorización central 945.
Cuando los correos electrónicos que contienen la información de
monitorización de dispositivos llegan al cortafuego 941 de la
intranet 950, el correo es encaminado al servidor de correo 943 con
POP3. La estación de trabajo de monitorización central 945 accede
periódicamente al servidor de correo 943 para obtener el correo
electrónico que ha llegado, analizar sintácticamente el correo y su
contenido por medio de POP3 y almacena la información necesaria en
la base de datos 947. La base de datos 949 contiene la información
adicional de las características e historial del dispositivo
monitorizado. Los ordenadores 951 y 953 realizan el análisis de los
datos obtenidos para adoptar las acciones necesarias.
Alternativamente, la estación de trabajo de monitorización central
945 puede contener una capacidad de recepción de correo, y el
cortafuego puede encaminar el correo electrónico directamente a la
estación de trabajo de monitorización central 945.
Las Figuras 10A y 10B ilustran una arquitectura
de software global del sistema mostrado en la Figura 9 según una
realización de la presente invención. La Figura 10A ilustra la
arquitectura del software usado por las redes que envían los correos
electrónicos con la información sobre los dispositivos monitorizados
en la Figura 9 según una realización de la presente invención. El
módulo de servicio remitente 1001 es el software residente del
sistema que establece el destino para la información monitorizada
que va a enviarse, inicia el envío al destino de la información de
configuración y contacto, y monitoriza y envía periódicamente la
información al destino usando las tres funciones definidas en 1000
(es decir, establecer destino, obtener y actualizar estado, y enviar
configuración) para activar el módulo de envío, Monitor_Send DLL
1003. El módulo Monitor_Send DLL 1003 usa otros dos módulos, el
módulo Database 1005 para almacenar la información del dispositivo e
información relacionada con el dispositivo junto con la información
monitorizada que se almacena hasta que se envía, y el módulo
SNMP++DLL 1007 que se usa para obtener la información procedente de
los dispositivos.
La Figura 10B ilustra la arquitectura del
software usado por el lado de recepción (por ejemplo, la intranet
950) en la Figura 9 según una realización de la presente invención.
El módulo de Servicio Destinatario 1011 es el software residente del
sistema que establece el acceso al servidor de correo donde va a
enviarse la información monitorizada, y obtiene periódicamente la
información monitorizada procedente del servidor de correo a través
de las dos funciones definidas en 1010 (es decir, configurar
servidor POP3, y obtener correo y actualizar base de datos) para
activar el módulo Receive_Store DLL 1013. El módulo Receive_Store
DLL 1013 usa otros dos módulos, el módulo Database 1017 para
almacenar información del dispositivo e información relacionada con
el dispositivo junto con la información monitorizada, y el módulo
POP3 1015 para recuperar información del servidor de correo.
La Figura 11 ilustra la arquitectura general del
módulo Monitor_Send DLL 1003 según una realización de la presente
invención. Esta parte del sistema es responsable de monitorizar el
estado de los dispositivos y de enviar correos electrónicos que
contienen información de estado y configuración de los dispositivos
monitorizados. El módulo Interfaz 1101 permite que cualquier
aplicación use el módulo Monitor_Send 1003. Por ejemplo, el módulo
Servicio Remitente 1001 de la Figura 10A accede al módulo
Monitor_Send DLL 1003 a través del módulo Interfaz 1101. El módulo
Información de Dispositivo 1105 es responsable de obtener
información de configuración procedente de los dispositivos
monitorizados e iniciar el envío de la información de configuración.
El módulo Monitor de Dispositivos 1103 es responsable de obtener
información de estado procedente de los dispositivos monitorizados e
iniciar el envío de la información de estado. El módulo
Transferencia de datos 1107 es responsable de proporcionar un
procedimiento a través del cual se envía la información de estado y
configuración. El módulo Interfaz ODBC 1109 proporciona un
procedimiento para acceder a información y almacenarla en una base
de datos. Cada uno de los componentes del módulo Monitor_Send DLL
1003 proporciona funciones de interfaz que les permiten realizar sus
tareas. Por ejemplo, las funciones del módulo Transferencia de datos
1107 se ofrecen a través de cuatro funciones de interfaz, establecer
destino, comenzar envío, envío de datos y finalizar envío.
La Figura 12 ilustra una arquitectura general del
módulo Receive_Store DLL 1013 según una realización de la presente
invención. Esta parte del sistema es responsable de recuperar la
información que fue enviada a él por el módulo Monitor_Send DLL 1003
y de almacenar la información en la base de datos. El módulo
Interfaz 1101 permite que cualquier aplicación use el módulo
Receive_Store DLL 1013. Por ejemplo, el módulo Servicio Destinatario
1011 de la Figura 10B accede al módulo Receive_Store DLL 1013 a
través del módulo Interfaz 1101. El módulo Administrador
destinatario 1203 es responsable de obtener la información de
configuración e información de estado de los dispositivos
monitorizados desde el servidor POP3 y de almacenar esa información
en la base de datos. El módulo Recuperador de datos 1205 es
responsable de recuperar los datos desde el servidor POP3. El módulo
Procesador POP3 1207 es responsable de acceder a la información
enviada a él por el módulo Monitor_Sent DLL 1003. El módulo
Analizador sintáctico 1211 es responsable de analizar
sintácticamente la información obtenida del servidor POP3. El módulo
Interfaz ODBC 1109 es responsable de almacenar en una base de datos
la información enviada a él. Cada uno de los componentes del módulo
Receive_Store DLL 1013 proporciona funciones de interfaz que les
permiten realizar sus tareas.
La Figura 13A es un organigrama que proporciona
una vista general de las funciones realizadas por el módulo
Información de dispositivo 1105 en el contexto del diagrama de
sistema de la Figura 9. Este procedimiento se concentra en el envío
de información de configuración de los dispositivos monitorizados
desde la estación de trabajo de monitorización remota 911 a la
estación de trabajo de monitorización central 945, y no en el envío
de información de estado, que se describe más adelante en el
contexto del módulo Monitor de dispositivos 1103. La información de
configuración para los dispositivos monitorizados mantenida por el
monitor central puede ser enviada originalmente, o actualizarse, a
través de las funciones realizadas por el módulo Información de
dispositivos 1105, como se entenderá a la luz de la descripción
proporcionada en este documento.
Según se muestra en la Figura 13A, el
procedimiento comienza con la etapa S1301 donde la base de datos 913
es consultada por la estación de trabajo de monitorización remota
911 para obtener información de configuración e información de
dirección IP correspondientes a los dispositivos que son
monitorizados por esa estación de trabajo de monitorización remota
911 particular. El procedimiento pasa después a la etapa S1302
donde, usando la dirección IP obtenida de la base de datos 913, la
estación de trabajo de monitorización remota 911 consulta a los
dispositivos monitorizados individuales usando comandos SNMP para
obtener un identificador único de dispositivo (por ejemplo, una
dirección MAC) para cada uno de los dispositivos que son
monitorizados. El procedimiento pasa después a la etapa S1303 donde
la estación de trabajo de monitorización remota 911 almacena el
identificador único de dispositivo en la base de datos. El
procedimiento pasa después a la etapa S1304 donde la información de
configuración, que incluye la dirección IP obtenida de la base de
datos 913 y el identificador único de dispositivo obtenido mediante
comandos SNMP, es formateada a una estructura de mapa común. El
procedimiento pasa después a la etapa S1305 donde la información de
configuración que incluye el identificador único de dispositivo se
envía a la estación de trabajo de monitorización central 945 por
medio de un mensaje de correo electrónico a través del servidor SMTP
915. Una vez que ha sido enviada la información, el procedimiento
termina.
La Figura 13B es un diagrama de clases que
ilustra una realización del módulo Información de dispositivos 1105
de la Figura 11 según la presente invención. El módulo Información
de dispositivos 1105 es responsable de activar el módulo
Transferencia de datos 1107 para comenzar el envío de información de
configuración, obtener de la base de datos 913 la información de
configuración de dispositivos por medio del módulo Interfaz ODBC
1109, obtener un identificador único de dispositivo (por ejemplo,
una dirección MAC) de los dispositivos SNMP monitorizados y
actualizar la información de configuración de dispositivos en la
base de datos 913 para incluir el identificador único de
dispositivo, formatear la información de configuración de
dispositivos a una estructura de mapa, enviar la estructura de mapa
al módulo Transferencia de datos 1107, y terminar el envío de la
información de configuración por medio del módulo Transferencia de
datos 1107.
La base de datos 913 no está poblada inicialmente
con un identificador único de dispositivo para los dispositivos
monitorizados. El módulo Información de dispositivos 1105 es
responsable de obtener esta información de los dispositivos
monitorizados basándose en información que está almacenada
originalmente en la base de datos (por ejemplo, información de
dirección IP), por medio de comandos SNMP. El identificador único de
dispositivo, obtenido directamente de los dispositivos, es poblado
después por el módulo Información de dispositivos 1105 dentro de la
base de datos 913.
La estructura de mapa usada al almacenar la
información que va a ser enviada desde la estación de trabajo de
monitorización remota 911 a la estación de trabajo de monitorización
central 945 es una estructura estándar para almacenar datos clave/de
valor. Cada entrada en el mapa incluye una clave que indica qué
representan los datos, y un campo de datos que contiene el valor de
los datos. En una realización de la presente invención, la clave del
mapa es una cadena o un número asociado a un campo de datos
particular, y el campo de datos es un valor de cadena. Las
estructuras de mapas están incluidas con el lenguaje C++ estándar, y
estructuras similares, a veces llamadas estructura de diccionario,
están incluidas con otros lenguajes estándar. A continuación se
muestra un ejemplo de una estructura de mapa poblada como Tabla
1:
| Clave | Valor (Datos) |
| "Fabricante" (o 100) | "Xerox" |
| "Modelo" (o 101) | "DocuPrint N4025" |
| "Número de serie" (o 102) | "PF4-027955" |
| "Dirección MAC" (o 103) | "00 00 AA 79 07 76" |
| "Dirección IP" (o 104) | "172.30.4.53" |
| "Nombre de compañía" (o 105) | "Ricoh Corporation" |
| "Calle" (o 106) | "1996 Lundy Ave" |
| "Ciudad" (o 107) | "San José" |
| "Estado" (o 108) | "CA" |
| "Código postal" (o 109) | "95131" |
| "Ubicación" (o 110) | "Lab" |
| "Persona de contacto" (o 111) | "John Smith" |
| "Número de teléfono" (o 112) | "4085551212" |
El módulo Información de dispositivos 1105
contiene dos clases, CDeviceInformation 1301 y CIP_MACmap 1303. La
clase CDeviceInformation 1301 es responsable de obtener la
información de configuración de la base de datos 913, e iniciar el
envío de la información mediante correo electrónico desde la
estación de trabajo de monitorización remota 911 a la estación de
trabajo de monitorización central 945. La clase CDeviceInformation
1301 interactúa con la base de datos 913 por medio del módulo
Interfaz ODBC 1109 para obtener la información de configuración, y
usa el módulo Transferencia de datos 1107 para transmitir la
información de configuración a la estación de trabajo de
monitorización central 945.
La clase CIP_MACmap 1303hace uso de la clase
CSnmpResource 1305 para obtener una dirección física (por ejemplo,
una dirección MAC) de los dispositivos SNMP monitorizados. La
dirección MAC se usa para identificar de manera única los
dispositivos monitorizados dentro de la base de datos 947 mantenida,
por ejemplo, por la estación de trabajo de monitorización central
945. Aunque una dirección IP, por ejemplo, puede identificar de
manera única un dispositivo monitorizado entre los dispositivos
conectados a una red particular monitorizada por la estación de
trabajo de monitorización remota 911, esa dirección puede no ser
única entre todas las redes que son monitorizadas por la estación de
trabajo de monitorización central 945. Por esta razón es por lo que,
en este ejemplo, se usa una dirección MAC para proporcionar una
identificación única globalmente para un dispositivo particular en
la que puede confiar la estación de trabajo de monitorización
central 945.
Si se dispone de otra identificación única de
dispositivo, puede modificarse la estructura de clases mostrada en
la Figura 13B para tener en cuenta esa identificación única.
La Figura 14 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Información de
dispositivos 1105 mostrado en la Figura 13B para obtener y enviar
información de configuración de un dispositivo monitorizado desde la
estación de trabajo de monitorización remota 911 a la estación de
trabajo de monitorización central 945. Como se muestra en la Figura
14, el procedimiento se inicia mediante una llamada al procedimiento
sendConfig() de la clase CDeviceInformation 1403 por la interfaz
1101. En respuesta, la clase CDeviceInformation 1403 llama al
procedimiento startSend() de la clase CDataTransfer 1405 para
iniciar un enlace de comunicación para envío del mensaje de correo
electrónico que contendrá la información de configuración. La clase
CDeviceInformation 1403 llama entonces al procedimiento
getDeviceInformation() de la clase CSendODBCInterface 1411 para
obtener de la base de datos la información de configuración,
incluyendo la dirección IP, del dispositivo monitorizado. La clase
CDeviceInformation 1403 llama después al procedimiento getMACforIP()
de la clase CIP_MACmap 1407 para obtener una dirección física (por
ejemplo, la dirección MAC) para los dispositivos monitorizados
basada en la dirección IP que fue obtenida de la base de datos. A su
vez, la clase CIP_MACmap 1407 llama a los procedimientos
setIPAdressOfAgent() y getOctetStringValueForOID() de la clase
CSnmpResource 1409 para consultar al dispositivo monitorizado
basándose en su dirección IP para recibir su dirección física a
través de las funciones SNMP apropiadas. Después, la clase
CDeviceInformation 1403 llama al procedimiento
setDeviceInformation() de la clase CSendODBCInterface 1411 para
almacenar la información de configuración en la base de datos.
La clase CDeviceInformation 1403 llama luego al
procedimiento dataSend() de la clase CDataTransfer 1405 para enviar
la información de configuración, junto con la información de
dirección física, a la estación de trabajo de monitorización central
945. Por último, la clase CDeviceInformation 1403 llama al
procedimiento endSend() de la clase CDataTransfer 1405 para terminar
el envío de la información de configuración.
La Figura 15A es un organigrama que proporciona
una vista general de las funciones realizadas por el módulo Monitor
de dispositivos 1103 en el contexto del diagrama de sistema de la
Figura 9. Este procedimiento se centra en la recogida,
almacenamiento y envío de información de los dispositivos
monitorizados desde la estación de trabajo de monitorización remota
911 a la estación de trabajo de monitorización central 945 como
mensaje de correo electrónico por medio del servidor SMTP 915.
Como se muestra en la Figura 15A, el
procedimiento comienza con la etapa S1501 donde se determina si se
va a enviar información a la estación de trabajo de monitorización
central 945. En una realización de la presente invención, se envía
alguna información desde la estación de trabajo de monitorización
remota 911 a la estación de trabajo de monitorización central 945 a
una frecuencia diferente (por ejemplo, menos frecuentemente) de una
frecuencia a la que se interroga por el estado de los dispositivos
monitorizados. Si se determina que la información recogida no debe
enviarse a la estación de trabajo de monitorización central 945 (es
decir, "NO" en la etapa S1501), el procedimiento pasa a la
etapa S1502 donde se interroga a los dispositivos monitorizados sólo
por un primer tipo de información.
El primer tipo de información puede incluir, por
ejemplo, cierta información de estado que puede cambiar de estado
más frecuentemente de lo que la información es presentada a la
estación de trabajo de monitorización central. Un segundo tipo de
información puede incluir una clase diferente de información de
estado, por ejemplo, un contador, un indicador de nivel, o un ajuste
de configuración de un dispositivo monitorizado. Para este segundo
tipo de información, los valores intermedios entre periodos de
informe no son de interés. Como se entenderá, es bastante posible
que, dependiendo de la frecuencia con la que se envía información a
la estación de trabajo de monitorización central 945, la información
de estado que corresponde al primer tipo de información, por
ejemplo, una condición de error, podría haber sido corregida entre
transmisiones a la estación de trabajo de monitorización central
945. Por esta razón, es útil almacenar el primer tipo de
información, para que cuando se envíe información a la estación de
trabajo de monitorización central 945, pueda informársele de que, en
este ejemplo, se ha producido una condición de error particular,
aunque no necesariamente sigue presente, desde la última vez que se
envió información. Por consiguiente, cuando se envía la información,
incluyendo tanto el primer tipo como el segundo tipo de información,
a la estación de trabajo de monitorización central 945, se consulta
a la base de datos 913 por el primer tipo de información almacenada
en la base de datos 913 y se envía junto con la información más
reciente. Después, se ponen a cero esos valores de la base de datos
913 para despejar cualquier información que hubiera sido almacenada
precediendo a la transmisión a la estación de trabajo de
monitorización central 945.
Volviendo a la Figura 15A, una vez que el primer
tipo de información ha sido recogido del dispositivo de red, el
procedimiento pasa a la etapa S1503 donde el primer tipo de
información es almacenado en la base de datos 913 por la estación de
trabajo de monitorización remota 911. Después de que el primer tipo
de información es almacenado en la base de datos 913, el
procedimiento finaliza.
Por otra parte, si se determina que va a enviarse
información a la estación de trabajo de monitorización central 945
(es decir, "SÍ" en la etapa S1501), el procedimiento pasa a la
etapa S1504 donde se interroga a los dispositivos monitorizados
tanto por el primer como por el segundo tipo de información. Una vez
que se obtiene esta información, el procedimiento pasa a la etapa
S1505 donde se consulta a la base de datos por el primer tipo de
información almacenada previamente recogida. El procedimiento pasa
entonces a la etapa S1506 donde tanto el primero como el segundo
tipo de información acabados de recoger, así como el primer tipo de
información recuperada de la base de datos, son formateados a una
estructura de mapa común. Esta es la misma estructura de mapa que
fue usada por el módulo Información de dispositivos 1105 para enviar
la información de configuración. El procedimiento pasa después a la
etapa S1507 donde tanto el primero como el segundo tipo de
información son enviados por la estación de trabajo de
monitorización remota 911 a la estación de trabajo de monitorización
central 945 como mensaje de correo electrónico por medio del
servidor SMTP 915. Después de que la información de estado ha sido
enviada por la estación de trabajo de monitorización remota 911, el
procedimiento pasa a la etapa S1508 donde, como se analizó
anteriormente, la estación de trabajo de monitorización remota 911
pone a cero los valores que corresponden al primer tipo de
información almacenada en la base de datos 913 para despejar
cualquier condición que pudiera haber sido grabada precediendo al
envío de la información. Una vez que los valores de la base de datos
913 son puestos a cero, el procedimiento finaliza.
La Figura 15B es un diagrama de clases que
ilustra una realización del módulo Monitor de dispositivos 1103 de
la Figura 11 según la presente invención. El módulo Monitor de
dispositivos 1103 es responsable de registrar y mantener información
acerca de los dispositivos de red. Este módulo Monitor de
dispositivos 1103 también es responsable de asegurar que la
información se envía a la estación de trabajo de monitorización
central 945. Si no se va a enviar la información al ser recogida, el
módulo Monitor de dispositivos 1103 obtiene y almacena sólo ciertos
tipos de información (por ejemplo, no hay tóner, hay una puerta
abierta, se produce un atasco, etc.) en la base de datos 913. Si la
información debe enviarse al ser recogida, el módulo Monitor de
dispositivos 1103 obtiene otros tipos de información, incluyendo,
por ejemplo, información de estado menos volátil. El módulo Monitor
de dispositivos 1103 incluye tres clases,
CDeviceStatusMonitorAndSendManager 1601, CDeviceStatusLogger 1603, y
CSnmpResource 1607.
La clase CDeviceStatusMonitorAndSendManager 1601
es responsable de obtener la información procedente de los
dispositivos monitorizados y de enviar la información a la estación
de trabajo de monitorización central 945. La clase
CDeviceStatusMonitorAndSendManager 1601 usa el módulo Transferencia
de datos 1107 analizado anteriormente para enviar la información a
la estación de trabajo de monitorización central 945.
La clase CDeviceStatusLogger 1603 es responsable
de registrar y mantener la información de los dispositivos
monitorizados. La clase CDeviceStatusLogger 1603 obtiene y almacena
información de los dispositivos monitorizados en la base de datos
913 usando el módulo Interfaz ODBC 1109 analizado anteriormente. La
clase CDeviceStatusLogger 1603 incluye la estructura DevicePerStatus
para almacenar el primer tipo de información de los dispositivos
monitorizados en la base datos 913. En una realización de la
presente invención, sólo se almacena en la base de datos este primer
tipo de información.
La clase CSnmpResource 1607 es responsable de
proporcionar el protocolo de administración de red (por ejemplo,
SNMP) que proporciona la capacidad de recoger la información
procedente de los dispositivos monitorizados. La clase CSnmpResource
1607 usa el SNMP++DLL 1609 para implementar el protocolo simple de
administración de redes para reunir la información procedente de los
dispositivos monitorizados.
La Figura 16 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Monitor de
dispositivos 1103 para obtener y almacenar el primer tipo de
información procedente de los dispositivos monitorizados. Según se
analizó anteriormente, si la información recogida de los
dispositivos monitorizados no se va a enviar a la estación de
trabajo de monitorización central 945 al recogerse, sólo se recoge y
se almacena en la base de datos 913 este primer tipo de información.
Como se muestra en la Figura 16, el procedimiento es iniciado por la
clase CDeviceStatusMonitorAndSendManager 1601 invocando el
procedimiento logDevicePerStatus() de la clase CDeviceStatusLogger
1603 para iniciar la recogida y almacenamiento del primer tipo de
información de los dispositivos monitorizados. La clase
CDeviceStatusLogger 1603 llama después al procedimiento
getDevicePerStatus() del módulo Interfaz ODBC 1109 para obtener la
última información de los dispositivos monitorizados, incluyendo la
dirección IP de los dispositivos, de la base de datos 913. Después,
la clase CDeviceStatusLogger 1603 llama al procedimiento
setIPAddressOfAgent() de la clase CSnmpResource 1607 que, a su vez,
llama al procedimiento set_address() del SNMP++DLL 1609 para
establecer una dirección IP de un dispositivo del cual se va a
recoger el primer tipo de información. Después, la clase
CDeviceStatusLogger 1603 llama al procedimiento
getOctetStringValueForOID() de la clase CSnmpResource 1607 que, a su
vez, llama la procedimiento get() y al procedimiento get_value() del
SNMP++DLL 1609 para obtener la última información de los
dispositivos monitorizados por medio de SNMP usando la dirección IP
del dispositivo. Una vez que la información ha sido devuelta, la
clase CDeviceStatusLogger 1603 llama al procedimiento
setDevicePerStatus() del módulo Interfaz ODBC 1109 para almacenar la
información de los dispositivos monitorizados en la base de datos
913 usando la estructura DevicePerStatus 1505.
La Figura 17 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Monitor de
dispositivos 1103 para obtener tanto un primer tipo como un segundo
tipo de información de los dispositivos monitorizados y para poner a
cero los valores que corresponden al primer tipo de información
almacenado en la base de datos 913 para cada dispositivo
monitorizado. Según se analizó anteriormente, si la información
recogida de los dispositivos monitorizados va a enviarse a la
estación de trabajo de monitorización central 945 al ser recogida,
se recoge tanto el primer tipo de información como el segundo tipo
de información. Según se muestra en la Figura 17, el procedimiento
es iniciado por la clase CDeviceStatusMonitorAndSendManager 1601
invocando al procedimiento getNextDeviceStatus() de la clase
CDeviceStatusLogger 1603 para iniciar la recogida de la información
(tanto el primer tipo como el segundo tipo de información) de los
dispositivos monitorizados. Las etapas 2-8 al
recoger los dos tipos de información son las mismas que las etapas
2-8 descritas anteriormente (es decir, las llamadas
a getDevicePerStatus(), setIPAddressOfAgent(), set_Address(),
getOctetStringValueForOID(), get(), get_value(), y
setDevicePerStatus()) en el contexto de la Figura 16 para recoger
sólo el primer tipo de información. Sin embargo, la llamada al
procedimiento setDevicePerStatus() del módulo Interfaz ODBC 1109 en
este caso (es decir, la etapa 8) se usa para poner a cero los
valores que corresponden al primer tipo de información almacenado en
la base de datos.
Después de poner a cero los valores de la base de
datos, la clase CDeviceStatusLogger 1603 llama al procedimiento
getStringValueForOID() de la clase CSnmpResource 1607 que, a su vez,
llama a los procedimientos get() y get_printable_value() del módulo
SNMP++DLL 1609 para obtener el segundo tipo de información
procedente de los dispositivos monitorizados por medio de comandos
SNMP.
La Figura 18 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Monitor de
dispositivos 1103 para enviar tanto el primer tipo como el segundo
tipo de información de los dispositivos monitorizados a la estación
de trabajo de monitorización central 945. Según se muestra en la
Figura 18, el procedimiento es iniciado por la clase
CDeviceStatusMonitorAndSendManager 1601 invocando al procedimiento
getNextDeviceStatus() de la clase CDeviceStatusLogger 1603 para
obtener la información de los dispositivos monitorizados como se
analizó anteriormente en el contexto de la Figura 17. Después, la
clase CDeviceStatusMonitorAndSendManager 1601 llama a los
procedimientos startSend() y dataSend() del módulo Transferencia de
datos 1107 para iniciar el envío de la información a la estación de
trabajo de monitorización central 945. Luego, la clase
CDeviceStatusMonitorAndSendManager 1601 llama de manera iterativa al
procedimiento getNextDeviceStatus() de la clase CDeviceStatusLogger
1603 para obtener información procedente de un dispositivo
monitorizado, seguido de una llamada al procedimiento dataSend() de
la clase CDataTransfer 1405, mostrada en la Figura 19C, del módulo
Transferencia de datos 1107 para enviar la información para un
dispositivo monitorizado particular a la estación de trabajo de
monitorización central 945. Una vez que ha sido enviada información
para todos los dispositivos monitorizados, la clase
CDeviceStatusMonitorAndSendManager 1601 llama al procedimiento
endSend() de la clase CDataTransfer 1405, mostrada en la Figura 19C,
del módulo Transferencia de datos 1107 para terminar el envío de la
información.
La Figura 19A es un organigrama que proporciona
una vista general de las funciones realizadas por el módulo
Transferencia de datos 1107 en el contexto del diagrama de sistema
de la figura 9. Este procedimiento se centra en el módulo
Transferencia de datos 1107 responsable de enviar la información de
configuración y estado, y no de la recogida de la información de
configuración y estado que va a enviarse, como se describe
anteriormente en el contexto del módulo Información de dispositivos
1105 y del módulo Monitor de dispositivos 1103, respectivamente.
Según se muestra en la Figura 19A, el
procedimiento comienza con la etapa S1901 donde el registro de
sistema de la estación de trabajo de monitorización remota 911 está
poblado con una dirección de origen y una dirección de destino para
correos electrónicos que transfieren información de estado de los
dispositivos monitorizados. En este ejemplo, la dirección de origen
será la dirección de correo electrónico de la estación de trabajo de
monitorización remota 911, y la dirección de destino será la
dirección de correo electrónico de la estación de trabajo de
monitorización central 945. Una vez que las direcciones de origen y
destino han sido pobladas en el registro de sistema de la estación
de trabajo de monitorización remota 911, puede empezar la
transferencia de información.
El procedimiento pasa entonces a la etapa S1902
donde comienza una transferencia de información. En la etapa S1902,
la estación de trabajo de monitorización remota 911 accede a su
registro de sistema para obtener información de direcciones de
correo electrónico de origen y destino que se usarán para poblar
información de cabecera para un mensaje de correo electrónico que
tiene su origen en la estación de trabajo de monitorización remota
911 y que tiene un destino de la estación de trabajo de
monitorización central 945.
Una vez que se ha obtenido la información de
origen y destino, el procedimiento pasa a la etapa S1903 donde se
establece un enlace de comunicación entre la estación de trabajo de
monitorización remota 911 y un servidor de protocolo simple de
transferencia de correo (SMTP) 915. Una vez que ha sido establecido
el enlace de comunicación, el procedimiento pasa a la etapa S1904,
donde la información de configuración o estado se envía como mensaje
de correo electrónico desde la estación de trabajo de monitorización
remota 911 al servidor SMTP 915 por medio del enlace de
comunicación. El servidor SMTP 915 encaminará el mensaje de correo
electrónico al destinatario apropiado, en este caso la estación de
trabajo de monitorización central 945. En una realización de la
presente invención, la estación de trabajo de monitorización remota
911 envía la información de configuración o estado como archivo
adjunto de extensiones de correo de Internet multifunción (MIME) al
mensaje de correo electrónico por Internet. Según se analizó
anteriormente, la información de configuración o estado, antes de
enviarla a la estación de trabajo de monitorización central 945, es
mantenida en la base de datos 913. Una vez que se ha enviado la
información de configuración o estado, el procedimiento pasa a la
etapa S1905, donde la estación de trabajo de monitorización remota
911 desconectará el enlace de comunicación entre sí mismo y el
servidor SMTP 915. Una vez que ha sido desconectado el enlace de
comunicación, el procedimiento finaliza.
La Figura 19B es un organigrama que describe con
más detalle el procesamiento realizado al enviar información de
configuración o estado como archivo adjunto a un mensaje de correo
electrónico (por ejemplo, el procedimiento realizado en la etapa
S1904 de la Figura 19A) según una realización de la presente
invención. Como se muestra en la Figura 19B, el envío de la
información de configuración o estado comienza con la etapa S1910
donde se formatea la información de configuración o estado en la
estructura de mapa para ser enviada. La estructura del mapa es tal
que en el mapa pueden almacenarse datos de información de
configuración o estado. Una vez que han sido formateados lo datos
que van a ser enviados desde la estación de trabajo de
monitorización remota 911 a la estación de trabajo de monitorización
central 945, el procedimiento pasa a la etapa 911 donde los datos
son cifrados. El módulo Transferencia de datos 1107 se configura
para permitir que un nivel de cifrado para una aplicación particular
concuerde con las necesidades de la aplicación sin impactar con la
interfaz del módulo Transferencia de datos 1107. Una vez que los
datos están cifrados, el procedimiento pasa a la etapa S1912 donde
se codifican los datos. Una vez que los datos han sido cifrados y
codificados, el procedimiento pasa a la etapa 1913 donde los datos
son enviados por medio del enlace de comunicación descrito
anteriormente, por ejemplo, como archivo adjunto MIME a un mensaje
de correo electrónico. Una vez que los datos han sido enviados, el
procedimiento finaliza.
La transferencia de información de configuración
o estado desde la estación de trabajo de monitorización remota 911 a
la estación de trabajo de monitorización central 945 ha sido
descrita en el contexto de las Figuras 19A y 19B usando un protocolo
de almacenamiento y reexpedición. Usando un procedimiento de
almacenamiento y reexpedición, por ejemplo, SMTP y POP3, el mensaje
de correo electrónico es enviado por medio del servidor SMTP 915 a
un servidor de correo, por ejemplo el servidor de correo POP3 943 en
la Figura 9. El servidor de correo POP3 almacenará el mensaje de
correo electrónico hasta que sea recuperado por el destinatario
buscado que, en el ejemplo analizado anteriormente, es la estación
de trabajo de monitorización central 945. Cuando la estación de
trabajo de monitorización central 945 se conecta con el servidor de
correo POP3 943, el servidor de correo POP3 reexpedirá todos los
mensajes que ha almacenado que tienen a la estación de trabajo de
monitorización central 945 como destinatario buscado.
La Figura 19C es un diagrama de clases que
ilustra una realización del módulo Transferencia de datos 1107 de la
Figura 11 según la presente invención. El módulo Transferencia de
datos 1107 es responsable de formatear la información de
configuración o estado recogida de los dispositivos monitorizados, y
de enviar esa información como archivo adjunto a un mensaje de
correo electrónico desde una estación de trabajo de monitorización
remota 911 hasta una estación de trabajo de monitorización central
945 usando, por ejemplo, SMTP. En una realización de la presente
invención, la información de monitorización se envía como archivo
adjunto MIME a un mensaje de correo electrónico. El módulo
Transferencia de datos 1107 también es responsable de cifrar los
datos y codificar los datos cifrados usando, por ejemplo,
codificación Base64 antes de enviar los datos. El módulo
Transferencia de datos 1107 incluye seis clases: CDataTransfer 1405,
CsendManager 1903, CAbsEncrypter 1905, CNullEncrypter 1907,
CBase64Codifier 1909, y CSmtp 1911.
La clase CDataTransfer 1405 proporciona la
interfaz mediante la que se accede a la funcionalidad soportada por
el módulo Transferencia de datos 1107. En una realización de la
presente invención, la clase CDataTransfer 1405 incluye cuatro
procedimientos públicos mediante los que puede accederse a todas las
funcionalidades del módulo Transferencia de datos 1107. Estos
procedimientos incluyen un procedimiento setDestination(), un
procedimiento startSend(), un procedimiento dataSend(), y un
procedimiento endSend(). El procedimiento setDestination() se usa
para configurar tanto una dirección de origen como de destino para
un correo electrónico de una estación de trabajo de monitorización
remota 911 a una estación de trabajo de monitorización central 945.
El procedimiento startSend() se usa para iniciar comunicaciones
entre la estación de trabajo de monitorización remota 911 y un
servidor SMTP 915. El procedimiento dataSend() se usa para enviar la
información de monitorización como mensaje de correo electrónico
desde la estación de trabajo de monitorización remota 911 hasta la
estación de trabajo de monitorización central 945 por medio del
servidor SMTP 915. El procedimiento dataSend() soporta el envío de
información de configuración o información de estado. El
procedimiento endSend() se usa para desconectar el enlace de
comunicación después de que ha sido enviada la información de
configuración o estado. Aunque el módulo Transferencia de datos 1107
incluye considerablemente más capacidades, las complejidades de
estas capacidades están ocultas a la interfaz pública.
Volviendo a la Figura 19C, la clase CsendManager
1903 incluye clases que implementan cifrado, codificación y la
administración de un enlace de comunicación entre la estación de
trabajo de monitorización remota 911 y el servidor SMTP 915.
CAbsEncrypter 1905 es una clase abstracta que proporciona la
flexibilidad de añadir nuevos procedimientos de cifrado añadiendo
nuevas clases derivadas de CAbsEncrypter 1905 como, por ejemplo,
CNullEncrypter 1907. Esta estructura de clases proporciona a una
aplicación la flexibilidad de implementar el nivel deseado de
cifrado, o de cambiar un procedimiento de cifrado sin impactar con
la interfaz del módulo Transferencia de datos 1107.
La clase CBase64Codifyer 1909 proporciona
codificación de la información con base 64 antes de que se envíe la
información. La clase CSmtp 1911 es responsable de administrar el
enlace de comunicación entre la estación de trabajo de
monitorización remota 911 y el servidor SMTP 915. CSmtp 1911 hace
uso de la clase CSystemRegistry 1915 para acceder al registro de
sistema para determinar una dirección de correo electrónico de
origen y destino para la cabecera del mensaje de correo electrónico
que va a enviarse al servidor SMTP 915. Además, CSmtp 1911 hace uso
de la clase CSocket 1917 disponible en las Clases Fundamentales de
Microsoft (MFC) para establecer y quitar el enlace de comunicación
entre la estación de trabajo de monitorización remota 911 y el
servidor SMTP 915.
La Figura 20A es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Transferencia de
datos 1107 mostrado en la Figura 19C cuando una estación de trabajo
de monitorización remota 911 inicia la comunicación estableciendo un
enlace al servidor SMTP 915. En la Figura 20A, el usuario 2001
corresponde al módulo Monitor de dispositivos 1103 o al módulo
Información de dispositivos 1105. Como se muestra en la Figura 20A,
el procedimiento es iniciado por el usuario 2001 invocando el
procedimiento startSend() de la clase CDataTransfer 1405. Al llamar
al procedimiento startSend(), el usuario 2001 indica qué tipo de
información se enviará (por ejemplo, información de configuración o
información de estado).
La Figura 20B ilustra un archivo adjunto MIME
ejemplar que incluye información de configuración, como puede ser
determinada por la primera línea del archivo adjunto MIME. Por otra
parte, la Figura 20C ilustra un archivo adjunto MIME ejemplar que
incluye información de estado, como también está indicada por la
primera línea del archivo adjunto MIME. Según se describió
anteriormente, es el procedimiento startSend() el que asegura que la
primera línea está poblada apropiadamente. Los archivos adjuntos
MIME ejemplares mostrados en las Figuras 20B y 20C no están cifrados
ni codificados.
Volviendo a la Figura 20A, una vez que el usuario
2001 ha solicitado el inicio de comunicaciones, la clase
CDataTransfer 1405 llamará al procedimiento startSend() de la clase
CsendManager 1903. La clase CsendManager 1903 administra el
establecimiento de un enlace de comunicación entre la estación de
trabajo de monitorización remota 911 y el servidor SMTP 915 a través
de interacciones con la clase CSmtp 1913 que, a su vez, interactúa
con la clase CSocket 2013.
Para usar SMTP, la clase CsendManager 1903 llama
al procedimiento createSocket() de la clase CSmtp 1913 para crear un
canal de comunicación en el servidor SMTP 915 a través del que se
enviarán los comandos SMTP. Después, la clase CsendManager 1903
llama al procedimiento connectSocket() de la clase CSmtp 1913 para
conectar a ese canal de comunicación del servidor SMTP 915. En
respuesta, la clase CSmtp 1913 llamará a los procedimientos
Connect() y Receive() de la clase CSocket 2013 para conectar al
canal de comunicación.
Una vez que ha sido establecido el canal de
comunicación y se ha conectado a él, la clase CSendManager 1903
llama al procedimiento sendHeloCommand() de la clase CSmtp 1913 para
enviar el comando SMTP HELO al servidor SMTP 915. En respuesta, la
clase CSmtp 1913 llamará al procedimiento Send() de la clase CSocket
2013 para enviar el comando al canal de comunicación del servidor
SMTP 915, y posteriormente llamará al procedimiento Receive() de la
clase CSocket 2013 para recibir una respuesta procedente del canal
de comunicación del servidor SMTP 915. Usando el mismo
procedimiento, la clase CsendManager 1903 enviará los comandos MAIL,
RCPT y DATA SMTP al servidor SMTP 915 llamando respectivamente a los
procedimientos sendMailCommand(), sendRcptCommand(), y
sendDataCommand() de la clase CSmtp 1913. En respuesta a cada una
de las llamadas, la clase CSmtp 1913 llamará a los procedimientos
Send() y Receive() de la clase CSocket 2013 para enviar los comandos
y recibir una respuesta, respectivamente, del canal de comunicación
del servidor SMTP 915.
Como cualquier experto normal en la técnica SMTP
entendería, el comando SMTP HELO es usado por un cliente, por
ejemplo, la estación de trabajo de monitorización remota 911, para
identificarse a sí mismo ante el servidor SMTP 915, el comando SMTP
MAIL se usa para identificar el remitente de un mensaje de correo,
el comando SMTP RCPT se usa para identificar el destinatario de un
mensaje de correo, y el comando SMTP DATA se usa para enviar el
contenido de un mensaje de correo.
Después, la clase CSendManager 1903 llama al
procedimiento sendMailHeader() de la clase CSmtp 1913 para enviar la
cabecera de correo para el mensaje de correo electrónico. LA clase
CSmtp 1913 llama luego al procedimiento send() de la clase CSocket
2013 para enviar la cabecera al canal de comunicación del servidor
SMTP 915. En este punto, la información que va a ser incluida en el
mensaje de correo electrónico puede enviarse a través del canal de
comunicación del servidor SMTP 915. Los datos que corresponden al
tipo de información apropiada de los dispositivos monitorizados son
enviados por la clase CDataTransfer 1405 llamando al procedimiento
sendData() de la clase CSendManager 1903.
La Figura 21 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Transferencia de
datos 1107 mostrado en la Figura 19C para enviar datos de estado o
configuración mediante correo electrónico en respuesta al módulo
Monitor de dispositivos 1103 o al módulo Información de dispositivos
1105, respectivamente. En la Figura 21, el usuario 2001 corresponde
al módulo Monitor de dispositivos 1103 o al módulo Información de
dispositivos 1105. Como se muestra en la Figura 21, el procedimiento
es iniciado por el usuario 2001 llamando al procedimiento dataSend()
de la clase CDataTransfer 1405. El usuario 2001 envía el mapa que
contiene la información de configuración o estado como parámetro del
procedimiento dataSend(). El procedimiento dataSend() proporciona
una interfaz única, mediante la cual tanto el módulo Monitor de
dispositivos 1103 como el módulo Información de dispositivos 1105
proporcionan información que va a ser enviada al módulo
Transferencia de datos 1107. En respuesta, la clase CDataTransfer
1405 llama al procedimiento sendData() de la clase CSendManager 1903
para enviar la información al servidor SMTP 915. En una realización
de la presente invención, cada llamada al procedimiento sendData()
de la clase CSendManager 1903 envía al canal de comunicación un par
de valores clave/datos almacenado en el mapa (las etapas 8 y 9
mostradas en la Figura 21 son ilustrativas de este procedimiento).
Sin embargo, antes de enviar los datos la clase CSendManager 1903
llama al procedimiento encryptData() de la clase CNullEncrypter 1907
(o, como se describió anteriormente, otra clase derivada de la clase
abstracta CAbsEncrypter 1905) para cifrar los datos que deben
enviarse.
Después, la clase CSendManager 1903 llama a los
procedimientos encodeData() y getEncodedString() de la clase
CBase46Encoder 1911 para codificar los datos cifrados. Para enviar
los datos cifrados y codificados, la clase CSendManager 1903 llama
al procedimiento sendData() de la clase CSmtp 1913 que, a su vez,
llama al procedimiento Send() de la clase CSocket 2013.
La Figura 22 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Transferencia de
datos 1107 mostrado en la Figura 19C cuando se ha terminado el envío
de la información de configuración o estado a través de correo
electrónico. En la Figura 22, el usuario 2001 corresponde al módulo
Monitor de dispositivos 1103 o al módulo Información de dispositivos
1105. Como se muestra en la Figura 22, el procedimiento es iniciado
por el usuario 2001 llamando al procedimiento endSend() de la clase
CDataTransfer 1405. En respuesta, la clase CDtataTransfer 1405 llama
al procedimiento sendData() de la clase CSendManager 1903 para
enviar datos que indican el final de los datos que deben enviarse.
Aunque no se muestra en la Figura 22, los datos enviados serán
cifrados y codificados siguiendo el mismo procedimiento que el
descrito anteriormente en el contexto de la Figura 21. Después, la
clase CDataTransfer 1405 llama al procedimiento endSend() de la
clase CSendManager 1903 para terminar el envío. La clase
CSendManager 1903 termina el envío de datos llamando primero a los
procedimientos endOfData() y getEncodedString() de la clase
CBase64Encoder 1911 para obtener la última información codificada
que debe enviarse. Después, la clase CSendManager 1903 llama al
procedimiento sendData() de la clase CSmtp 1913 para enviar la
última cadena codificada que contiene datos. Para enviar la última
cadena codificada, la clase CSmtp 1913 llama al procedimiento Send()
de la clase CSocket 2013.
Después, la clase CSendManager 1903 llama al
procedimiento sendEndOfMail() de la clase CSmtp 1913 para enviar el
final de los datos de correo. A su vez, la clase Csmtp 1913 llama al
procedimiento Send() de la clase CSocket 2013 para enviar el final
de los datos de correo a través del canal de comunicación del
servidor SMTP 915 seguido de una llamada al procedimiento Receive()
de la clase CSocket 2013 para obtener una respuesta del canal de
comunicación. Después, la clase CSendManager 1903 llama al
procedimiento sendQuitCommand() de la clase CSmtp 1913 para enviar
el comando SMTP QUIT al canal de comunicación del servidor SMTP 915
para terminar la sesión de correo electrónico entre la estación de
trabajo de monitorización remota 911 y el servidor SMTP 915. En
respuesta, la clase CSmtp 1913 llama a los procedimientos Send() y
Receive() de la clase CSocket 2013 para enviar el comando QUIT y
obtener una respuesta del canal de comunicación.
La Figura 23 es un diagrama de colaboración que
ilustra la interacción entre las clases del módulo Transferencia de
datos 1107 mostrado en la Figura 19C para configurar el registro de
sistema de la estación de trabajo de monitorización remota 911 para
enviar información de configuración y estado de dispositivos
mediante correo electrónico a la estación de trabajo de
monitorización central 945. Como se muestra en la Figura 23, el
procedimiento es iniciado por una llamada de la Interfaz 1101 al
procedimiento setDestination() de la clase CDataTransfer 1405. En
respuesta, la clase CDataTransfer 1405 llama al procedimiento
setDestination() de la clase CSendManager 1403 que, a su vez, llama
al procedimiento setDestination() de la clase CSmtp 1913. Para
almacenar la información en el registro de sistema, la clase CSmtp
1913 llama a los procedimientos setSMTPServer(), setFromAddr(), y
setRcptAdd() de la clase CSystemRegistry 1915 para almacenar el
servidor SMTP, la dirección de remitente y la dirección de
destinatario que deben usarse al enviar información de configuración
o estado a la estación de trabajo de monitorización central 945,
respectivamente, en el registro de sistema de la estación de trabajo
de monitorización remota 911.
La Figura 24 es un diagrama de clases que ilustra
una realización del módulo Interfaz ODBC 1109 de la Figura 11 según
la presente invención. El módulo Interfaz ODBC 1109 es responsable
de hacer de interfaz con la base de datos 913 que mantiene la
información relacionada con los dispositivos SNMP que son
monitorizados por una estación de trabajo de monitorización remota
911 particular. En esta realización, la base de datos se registra en
una base de datos ODBC y, por lo tanto, la base de datos 913 dispone
de los controladores ODBC de soporte apropiados. El módulo Interfaz
ODBC 1109 incluye cinco clases: CSendODBCInterface 2401,
CDeviceInformationData 2403, CDeviceDatabase 2407,
CDevicePersistentStatus 2411, y CDevicePerDatabase 2413. La clase
CSendODBCInterface 2401
proporciona la interfaz mediante la que se accede a la funcionalidad soportada por el módulo Interfaz ODBC 1109.
proporciona la interfaz mediante la que se accede a la funcionalidad soportada por el módulo Interfaz ODBC 1109.
La clase CDeviceInformationData 2403 proporciona
procedimientos para obtener y almacenar en la base de datos 913
información de configuración de los dispositivos monitorizados. La
clase CDeviceDatabase 2407 proporciona una interfaz entre la clase
CDeviceInformationData 2403 y la base de datos real 913 que contiene
la información de configuración. La clase CDeviceInformationData
2403 usa la estructura DeviceInfo para almacenar la información de
configuración en la base de datos 913.
La clase CDevicePersistentStatus 2411 proporciona
procedimientos para obtener y almacenar en la base de datos el
primer tipo de información de los dispositivos monitorizados. La
clase CDevicePerDatabase 2407 proporciona una interfaz entre la
clase CDevicePersistentStatus 2411 y la base de datos real que
contiene el primer tipo de información. La clase
CDevicePersistentStatus 2411 usa la estructura DevicePerStatus para
almacenar el primer tipo de información en la base de datos 913.
Tanto la clase CDeviceDatabase 2407 como la clase
CDevicePerdatabase 2413 se derivan de la clase CRecordset 2417
disponible en las Clases Fundamentales de Microsoft (MFC).
Fig.
9
- 901
- Impresora láser Ricoh
- 903
- Impresora láser Ricoh
- 905
- Dispositivo SNMP genérico
- 907
- Impresora láser Ricoh
- 910
- Intranet
- 911
- Estación de trabajo
- 913
- Base de datos
- 915
- Servidor SNMP
- 917
- Cortafuego
- 920
- LAN
- 930
- LAN/Intranet
- 941
- Cortafuego
- 943
- Servidor de correo POP3
- 945
- Estación de trabajo
- 947
- Base de datos
- 949
- Base de datos
- 950
- Intranet
- a
- Datos
- b
- Comando SNMP
- c
- correo electrónico
- d
- correo electrónico
- e
- correo electrónico
- f
- recuperación de archivo de correo electrónico
\vskip1.000000\baselineskip
Fig.
10A
- a
- int setDestination(char*,char*,char*)
- \quad
- int obtainAndUpdateStatus(Int)
- \quad
- int sendConfig()
\vskip1.000000\baselineskip
Fig.
10B
- a
- int setupPOP3Server(char*,char*,char*)
- \quad
- int getMailAndUpdateDatabase()
\vskip1.000000\baselineskip
Fig.
12
- a
- bool getInformationType(InfoType &)
- \quad
- bool getDeviceInformation(DeviceInfo &)
- \quad
- bool getStatusData(DeviceStatus &)
- b
- bool setDeviceInformation(DeviceInfo &)
- \quad
- bool setStatusData(DeviceStatus &)
\vskip1.000000\baselineskip
Fig.
15B
- 1601
- CDeviceStatusMonitor
- \quad
- AndSendManager
- 1607
- CSnmpResource
- 1603
- CDeviceStatusLogger
- 1609
- SNMP++ DLL (de Monitor_Send)
- 1109
- Interfaz ODBC (de Monitor_Send)
- 1505
- DevicePerStatus
- 1107
- Transferencia de datos (de Monitor_Send)
Fig.
19C
- 1405
- CDataTransfer
- 1903
- CSendmanager
- 1905
- CAbsEncrypter
- 1909
- CBase64Encoder
- 1911
- CSmtp
- 1907
- CNullEncrypter
- 1915
- CSystemRegistry (de Común)
- 1917
- CSocket (de MFC)
\vskip1.000000\baselineskip
Fig.
24
- 2401
- CSendODBCInterface
- 2403
- CDeviceInformationdata
- 2411
- CDevicePersistentStatus
- 2405
- DeviceInfo (de Común)
- 2407
- CDeviceDatabase
- 2413
- CDevicePerDatabase
- 2415
- DevicePerStatus
- 2417
- CRecordset (de MFC)
Claims (39)
1. Un procedimiento para enviar información que
corresponde a al menos un dispositivo de red desde un monitor remoto
(911) a un monitor central (945), que comprende la etapa de:
- -
- interrogar (S 1502) a una primera frecuencia al al menos un dispositivo de red por el monitor remoto (911) usando un protocolo de administración de red por un primer tipo de información que corresponde al al menos un dispositivo de red;
caracterizado porque el procedimiento
comprende además las etapas de:
- -
- almacenar (S 1503) el primer tipo de información recogido por el monitor remoto (911) a la primera frecuencia en un depósito digital (913) a continuación de la etapa de interrogación a una primera frecuencia;
- -
- interrogar (S 1504) a una segunda frecuencia al al menos un dispositivo de red por el monitor remoto (911) usando dicho protocolo de administración de red por el primer tipo de información y un segundo tipo de información que corresponde al al menos un dispositivo de red;
- -
- enviar (S 1507) el primer tipo de información y el segundo tipo de información recogidos por el monitor remoto (911) a la segunda frecuencia y el primer tipo de información recogido a la primera frecuencia desde el depósito digital (913) por el monitor remoto (911) al monitor central (945) como archivo adjunto a un mensaje usando un protocolo de transferencia a continuación de la etapa de interrogación a una segunda frecuencia; y
- -
- poner a cero los valores (S 1508) en el depósito digital (913) que corresponden al primer tipo de información por el monitor remoto (911) a continuación de la etapa de envío (S 1507).
2. El procedimiento de la reivindicación 1, en el
que la primera frecuencia no es igual a la segunda frecuencia.
3. El procedimiento de la reivindicación 1, en el
que:
la etapa de interrogar (S 1504) a una segunda
frecuencia comprende almacenar el primer tipo de información y el
segundo tipo de información recogidos a la segunda frecuencia en una
estructura de mapa, y
la etapa de enviar (S 1507) comprende
- consultar (S 1505) al depósito digital por el primer tipo de información,
- almacenar el primer tipo de información procedente de la etapa de consulta en dicha estructura de mapa, y
- formatear (S 1506) el primer tipo de información y el segundo tipo de información recogidos por el monitor remoto (911) a la segunda frecuencia y almacenados en dicha estructura de mapa y el primer tipo de información recogido a la primera frecuencia y almacenado en dicha estructura de mapa antes de que se envíe el mensaje.
4. El procedimiento de la reivindicación 1, en el
que el primer tipo de información comprende al menos una de una
condición de alarma, un indicador de atasco de papel, y un indicador
de puerta abierta del al menos un dispositivo de red.
5. El procedimiento de la reivindicación 1, en el
que el segundo tipo de información comprende al menos una de un
recuento de páginas existentes, un indicador de tiempo útil del
sistema, un nivel de tóner del cartucho, un número de errores
encontrados, y un cambio de configuración realizado en al menos un
dispositivo de red.
6. El procedimiento de la reivindicación 1, en el
que el al menos un dispositivo de red comprende al menos uno de una
impresora, un dispositivo de fax, una copiadora, un escáner, un
aparato, una grabadora de cintas de vídeo, una cámara digital, un
teléfono celular, y un asistente de datos personales.
7. El procedimiento de la reivindicación 1, en el
que el protocolo de administración de red comprende un protocolo
simple de administración de redes.
8. El procedimiento de la reivindicación 1, en el
que el protocolo de transferencia comprende un protocolo de
almacenamiento y reexpedición.
9. El procedimiento de la reivindicación 1, en el
que el protocolo de transferencia comprende un protocolo simple de
transferencia de correo.
\newpage
10. El procedimiento de la reivindicación 1, en
el que el protocolo de transferencia comprende un protocolo de
conexión directa.
11. El procedimiento de la reivindicación 10, en
el que el protocolo de conexión directa comprende al menos uno de un
protocolo de transferencia de archivos y un protocolo de
transferencia de hipertexto.
12. El procedimiento de la reivindicación 1, en
el que:
el mensaje comprende un mensaje de correo
electrónico por Internet, y
el archivo adjunto comprende un archivo adjunto
de extensiones de correo de Internet multifunción al mensaje de
correo electrónico por Internet.
13. El procedimiento de la Reivindicación 1, en
el que:
el primer tipo de información recogido a la
segunda frecuencia comprende al menos una parte del primer tipo de
información recogido a la primera frecuencia, y
la etapa de enviar (S 1507) comprende enviar una
unión de información contenida en el primer tipo de información
recogido a la primera frecuencia y el primer tipo de información y
el segundo tipo de información recogidos a la segunda
frecuencia.
14. Un sistema implementado por ordenador para
enviar información que corresponde al por lo menos un dispositivo de
red desde un monitor remoto (911) hasta un monitor central (945),
que comprende:
un procesador; y
un medio legible por ordenador codificado con
instrucciones legibles por procesador que cuando son ejecutadas por
el procesador implementan
- un primer tipo de mecanismo de interrogación por información (S 1502) configurado para interrogar al al menos un dispositivo de red a una primera frecuencia por un primer tipo de información que corresponde al por lo menos un dispositivo de red,
- un mecanismo de informe de estado
caracterizado porque el medio legible por
ordenador implementa además
un mecanismo de almacenamiento de base de datos
(S 1503) configurado para almacenar en un depósito digital (913) el
primer tipo de información recogido por el primer tipo de mecanismo
de interrogación por información,
un mecanismo de interrogación por un primer y un
segundo tipo de información (S 1504) configurado para interrogar al
al menos un dispositivo de red a una segunda frecuencia por el
primer tipo de información y un segundo tipo de información que
corresponden al por lo menos un dispositivo de red,
y caracterizado además porque
el mecanismo de informe de estado está
configurado para enviar (S 1507) el primer tipo de información y el
segundo tipo de información recogidos por el mecanismo de
interrogación por el primer y segundo tipos de información (S 1504)
y el primer tipo de información recogido por el mecanismo de
interrogación por el primer tipo de información (S 1502) desde el
depósito digital (913) hasta el monitor central (945) como archivo
adjunto a un mensaje usando un protocolo de transferencia, y
un mecanismo de puesta a cero de la base de datos
(S 1508) configurado para poner a cero valores en el depósito
digital que corresponden al primer tipo de información después de
que el mecanismo de informe de estado envía el mensaje al monitor
central.
15. El sistema de la reivindicación 14, en el que
la primera frecuencia no es igual a la segunda frecuencia.
16. El sistema de la reivindicación 14, en el
que:
el mecanismo de interrogación por el primer y
segundo tipos de información (S 1504) está configurado además para
almacenar el primer tipo de información y el segundo tipo de
información recogidos a la segunda frecuencia en una estructura de
mapa, y
el medio legible por ordenador está codificado
además con instrucciones legibles por procesador que cuando son
ejecutadas por el procesador implementan además
un mecanismo de recuperación (S 1505) configurado
para consultar al depósito digital (913) por el primer tipo de
información y para almacenar el primer tipo de información en dicha
estructura de mapa, y
un mecanismo de formateo (S 1506) configurado
para formatear el primer tipo de información y el segundo tipo de
información recogidos por el mecanismo de interrogación por el
primer y segundo tipos de información (S 1504) y almacenados en
dicha estructura de mapa y el primer tipo de información recogido
por el mecanismo de interrogación por el primer tipo de información
(S 1502) y almacenado en dicha estructura de mapa antes de que el
mecanismo de informe de estado envíe (1507) el mensaje.
17. El sistema de la reivindicación 14, en el que
el primer tipo de información comprende al menos una de una
condición de alarma, un indicador de atasco de papel, y un indicador
de puerta abierta del al menos un dispositivo de red.
18. El sistema de la reivindicación 14, en el que
el segundo tipo de información comprende al menos una de un recuento
de páginas existentes, un indicador de tiempo útil del sistema, un
nivel de tóner del cartucho, un número de errores encontrados, y un
cambio de configuración realizado en al menos un dispositivo de
red.
19. El sistema de la reivindicación 14, en el que
el al menos un dispositivo de red comprende al menos uno de una
impresora, un dispositivo de fax, una copiadora, un escáner, un
aparato, una grabadora de cintas de vídeo, una cámara digital, un
teléfono celular, y un asistente de datos personales.
20. El sistema de la reivindicación 14, en el que
el protocolo de administración de red comprende un protocolo simple
de administración de redes.
21. El sistema de la reivindicación 14, en el que
el protocolo de transferencia comprende un protocolo de
almacenamiento y reexpedición.
22. El sistema de la reivindicación 14, en el que
el protocolo de transferencia comprende un protocolo simple de
transferencia de correo.
23. El sistema de la reivindicación 14, en el que
el protocolo de transferencia comprende un protocolo de conexión
directa.
24. El sistema de la reivindicación 23, en el que
el protocolo de conexión directa comprende al menos uno de un
protocolo de transferencia de archivos y un protocolo de
transferencia de hipertexto.
25. El sistema de la reivindicación 14, en el
que:
el mensaje comprende un mensaje de correo
electrónico por Internet, y
el archivo adjunto comprende un archivo adjunto
de extensiones de correo de Internet multifunción al mensaje de
correo electrónico por Internet.
26. El sistema de la reivindicación 14, en el
que:
el primer tipo de información recogido a la
segunda frecuencia comprende al menos una parte del primer tipo de
información recogido a la primera frecuencia, y
el mecanismo de informe de estado está
configurado además para enviar una unión de información contenida en
el primer tipo de información recogido a la primera frecuencia y el
primer tipo de información y el segundo tipo de información
recogidos a la segunda frecuencia.
27. Un programa informático, que comprende:
un medio de almacenamiento por ordenador; y
un mecanismo de codificación de programa
informático incluido en el medio de almacenamiento por ordenador
para hacer que un monitor remoto (911) recoja y envíe a un monitor
central información relacionada con al menos un dispositivo de red,
teniendo el mecanismo de codificación de programa informático
un primer módulo de código informático
configurado para interrogar (S 1502) al por lo menos un dispositivo
de red a una primera frecuencia por un primer tipo de información
que corresponde al al menos un dispositivo de red,
caracterizado porque el mecanismo de
codificación de programa informático comprende además:
un segundo módulo de código informático
configurado para almacenar (S 1503) el primer tipo de información
recogido por el primer módulo de código informático en un depósito
digital (913),
un tercer módulo de código informático
configurado para interrogar (S 1504) al al menos un dispositivo de
red a una segunda frecuencia por el primer tipo de información y un
segundo tipo de información que corresponde al al menos un
dispositivo de red,
un cuarto módulo de código informático
configurado para enviar (S 1507) el primer tipo de información y el
segundo tipo de información recogidos por el tercer módulo de código
informático y el primer tipo de información recogido por el primer
módulo de código informático desde el depósito digital (913) hasta
el monitor central (945) como archivo adjunto a un mensaje usando un
protocolo de transferencia, y
un quinto módulo de código informático
configurado para poner a cero (S 1508) valores en el depósito
digital (913) que corresponden al primer tipo de información después
de que el cuarto módulo de código informático envía el mensaje al
monitor central (945).
28. El programa informático de la reivindicación
27, en el que la primera frecuencia no es igual a la segunda
frecuencia.
29. El programa informático de la reivindicación
27, en el que:
el tercer módulo de código informático está
configurado además para almacenar el primer tipo de información y el
segundo tipo de información en una estructura de mapa, y
teniendo además el mecanismo de codificación de
programa informático
- un sexto módulo de código informático configurado para consultar al depósito digital (913) por el primer tipo de información y para almacenar (S 1503) el primer tipo de información en dicha estructura de mapa, y
- un séptimo módulo de código informático configurado para formatear (S 1506) el primer tipo de información y el segundo tipo de información recogidos por el tercer módulo de código informático y almacenados en dicha estructura de mapa y el primer tipo de información recogido por el primer módulo de código informático y almacenado en dicha estructura de mapa por el sexto módulo de código informático antes de que el cuarto módulo de código informático envíe (S 1507) el mensaje.
30. El programa informático de la reivindicación
27, en el que el primer tipo de información comprende al menos una
de una condición de alarma, un indicador de atasco de papel, y un
indicador de puerta abierta del al menos un dispositivo de red.
31. El programa informático de la reivindicación
27, en el que el segundo tipo de información comprende al menos una
de un recuento de páginas existentes, un indicador de tiempo útil
del sistema, un nivel de tóner del cartucho, un número de errores
encontrados, y un cambio de configuración realizado en al menos un
dispositivo de
red.
red.
32. El programa informático de la reivindicación
27, en el que el al menos un dispositivo de red comprende al menos
uno de una impresora, un dispositivo de fax, una copiadora, un
escáner, un aparato, una grabadora de cintas de vídeo, una cámara
digital, un teléfono celular, y un asistente de datos
personales.
33. El programa informático de la reivindicación
27, en el que el protocolo de administración de red comprende un
protocolo simple de administración de redes.
34. El programa informático de la reivindicación
27, en el que el protocolo de transferencia comprende un protocolo
de almacenamiento y reexpedición.
35. El programa informático de la reivindicación
27, en el que el protocolo de transferencia comprende un protocolo
simple de transferencia de correo.
36. El programa informático de la reivindicación
27, en el que el protocolo de transferencia comprende un protocolo
de conexión directa.
37. El programa informático de la reivindicación
36, en el que el protocolo de conexión directa comprende al menos
uno de un protocolo de transferencia de archivos y un protocolo de
transferencia de hipertexto.
38. El programa informático de la reivindicación
27, en el que:
el mensaje comprende un mensaje de correo
electrónico por Internet, y
el archivo adjunto comprende un archivo adjunto
de extensiones de correo de Internet multifunción al mensaje de
correo electrónico por Internet.
39. El programa informático de la reivindicación
27, en el que:
el primer tipo de información recogido a la
segunda frecuencia comprende al menos una parte del primer tipo de
información recogido a la primera frecuencia, y
el cuarto módulo de código informático está
configurado además para enviar una unión de información contenida en
el primer tipo de información recogido a la primera frecuencia y el
primer tipo de información y el segundo tipo de información
recogidos a la segunda frecuencia.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/953,357 US7490146B1 (en) | 2001-09-17 | 2001-09-17 | System, method, and computer program product for collecting and sending various types of information to a monitor using e-mail |
| US953357 | 2001-09-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2244705T3 true ES2244705T3 (es) | 2005-12-16 |
Family
ID=25493866
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02019181T Expired - Lifetime ES2244705T3 (es) | 2001-09-17 | 2002-09-02 | Matriz, procedimiento y dispositivo de moldeo por inyeccion para moldear un disco optico. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7490146B1 (es) |
| EP (1) | EP1294125B1 (es) |
| AT (1) | ATE299323T1 (es) |
| DE (1) | DE60204931T2 (es) |
| ES (1) | ES2244705T3 (es) |
| NO (1) | NO325646B1 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020004812A1 (en) | 1997-06-26 | 2002-01-10 | Tetsuro Motoyama | Method and system for diagnosis and control of machines using connectionless modes having delivery monitoring and an alternate communication mode |
| ES2338331T3 (es) | 2003-09-02 | 2010-05-06 | Nokia Corporation | Transmision de informacion integrada relacionada con calidad de servicio. |
| US7624147B2 (en) * | 2003-09-04 | 2009-11-24 | Sierra Wireless, Inc. | Efficient notification of new electronic mail arrival |
| US8250139B2 (en) * | 2007-02-20 | 2012-08-21 | Richrelevance, Inc. | Demand-driven, collaborative systems and processes for collecting structured information |
| US11811588B2 (en) * | 2020-04-22 | 2023-11-07 | Samsung Electronics Co., Ltd. | Configuration management and analytics in cellular networks |
Family Cites Families (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5909493A (en) | 1996-10-16 | 1999-06-01 | Ricoh Company, Ltd. | Method and system for diagnosis and control of machines using connectionless modes of communication |
| US5818603A (en) | 1996-03-29 | 1998-10-06 | Ricoh Company, Ltd. | Method and system for controlling and communicating with machines using multiple communication formats |
| US5887216A (en) | 1997-03-19 | 1999-03-23 | Ricoh Company, Ltd. | Method and system to diagnos a business office device based on operating parameters set by a user |
| US5819110A (en) | 1995-06-05 | 1998-10-06 | Ricoh Company, Ltd. | System for determining whether connection or connectionless modes of communication should be used to transmit information between devices in accordance with priorities of events |
| JP2707459B2 (ja) | 1988-12-26 | 1998-01-28 | 株式会社リコー | ファクシミリ装置 |
| JP3121002B2 (ja) | 1990-07-06 | 2000-12-25 | 株式会社リコー | プリンタシステム、プリンタおよび外部装置 |
| JPH08265367A (ja) * | 1995-03-20 | 1996-10-11 | Fujitsu Ltd | ネットワーク管理・情報収集方式 |
| US20030093522A1 (en) * | 1995-06-05 | 2003-05-15 | Tetsuro Motoyama | Method and system for diagnosis or control of machines |
| US5964837A (en) * | 1995-06-28 | 1999-10-12 | International Business Machines Corporation | Computer network management using dynamic switching between event-driven and polling type of monitoring from manager station |
| US5848386A (en) | 1996-05-28 | 1998-12-08 | Ricoh Company, Ltd. | Method and system for translating documents using different translation resources for different portions of the documents |
| US6192034B1 (en) * | 1997-06-30 | 2001-02-20 | Sterling Commerce, Inc. | System and method for network integrity management |
| US20020049693A1 (en) | 1997-11-21 | 2002-04-25 | Hewlett-Packard Company | Batch configuration of network devices |
| US6085196A (en) | 1997-12-23 | 2000-07-04 | Ricoh Company, Ltd. | Object-oriented system and computer program product for mapping structured information to different structured information |
| US6279015B1 (en) | 1997-12-23 | 2001-08-21 | Ricoh Company, Ltd. | Method and apparatus for providing a graphical user interface for creating and editing a mapping of a first structural description to a second structural description |
| JP3065053B2 (ja) | 1998-01-06 | 2000-07-12 | セイコーエプソン株式会社 | 機器監視システム、ローカル監視装置、統合監視装置、機器監視方法、及び、プログラムを格納したコンピュータ可読媒体 |
| JP3707233B2 (ja) * | 1998-02-26 | 2005-10-19 | ブラザー工業株式会社 | ネットワークアダプタ及びこれを備えた端末システム |
| FR2777723B1 (fr) | 1998-04-15 | 2000-06-23 | Bull Sa | Procede et systeme d'administration de reseaux et de systemes |
| US6327677B1 (en) * | 1998-04-27 | 2001-12-04 | Proactive Networks | Method and apparatus for monitoring a network environment |
| US6167448A (en) * | 1998-06-11 | 2000-12-26 | Compaq Computer Corporation | Management event notification system using event notification messages written using a markup language |
| US6501442B2 (en) * | 1998-06-15 | 2002-12-31 | Compaq Information Technologies Group, L.P. | Method and apparatus for graphical display of multiple network monitors over multiple intervals |
| US6437692B1 (en) | 1998-06-22 | 2002-08-20 | Statsignal Systems, Inc. | System and method for monitoring and controlling remote devices |
| US6449663B1 (en) * | 1998-07-08 | 2002-09-10 | International Business Machines Corporation | Method and apparatus for adjusting an interval of polling a network printer based on changes in working status of the network printer |
| US6453346B1 (en) * | 1998-07-17 | 2002-09-17 | Proactivenet, Inc. | Method and apparatus for intelligent storage and reduction of network information |
| US6317848B1 (en) | 1998-09-24 | 2001-11-13 | Xerox Corporation | System for tracking and automatically communicating printer failures and usage profile aspects |
| US6505248B1 (en) * | 1999-03-24 | 2003-01-07 | Gte Data Services Incorporated | Method and system for monitoring and dynamically reporting a status of a remote server |
| EP1045549A1 (en) | 1999-04-15 | 2000-10-18 | International Business Machines Corporation | System and method for non intrusive monitoring and management of distributed data networks |
| US6792455B1 (en) * | 2000-04-28 | 2004-09-14 | Microsoft Corporation | System and method for implementing polling agents in a client management tool |
| US6934749B1 (en) * | 2000-05-20 | 2005-08-23 | Ciena Corporation | Tracking distributed data retrieval in a network device |
| US6804712B1 (en) * | 2000-06-30 | 2004-10-12 | Cisco Technology, Inc. | Identifying link failures in a network |
| US6757714B1 (en) * | 2000-07-28 | 2004-06-29 | Axeda Systems Operating Company, Inc. | Reporting the state of an apparatus to a remote computer |
| US6662318B1 (en) * | 2000-08-10 | 2003-12-09 | International Business Machines Corporation | Timely error data acquistion |
| JP2002163163A (ja) * | 2000-09-12 | 2002-06-07 | Canon Inc | 遠隔サイト管理システム |
| AU2002240198B8 (en) * | 2001-01-31 | 2008-04-17 | Pharos Systems International, Inc. | Computer network and related methods for generating printer usage information |
| US6874036B2 (en) * | 2001-02-08 | 2005-03-29 | International Business Machines Corporation | Network management server combining PDUs to minimize bandwidth consumption at data link layer |
| US7536450B2 (en) * | 2001-09-17 | 2009-05-19 | Ricoh Company, Ltd. | System, method, and computer program product for sending remote device configuration information to a monitor using e-mail |
| US7302469B2 (en) * | 2001-09-17 | 2007-11-27 | Ricoh Company, Ltd. | System, method, and computer program product for transferring remote device support data to a monitor using e-mail |
-
2001
- 2001-09-17 US US09/953,357 patent/US7490146B1/en not_active Expired - Fee Related
-
2002
- 2002-09-02 AT AT02019181T patent/ATE299323T1/de not_active IP Right Cessation
- 2002-09-02 EP EP02019181A patent/EP1294125B1/en not_active Expired - Lifetime
- 2002-09-02 ES ES02019181T patent/ES2244705T3/es not_active Expired - Lifetime
- 2002-09-02 DE DE60204931T patent/DE60204931T2/de not_active Expired - Lifetime
- 2002-09-17 NO NO20024446A patent/NO325646B1/no not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| ATE299323T1 (de) | 2005-07-15 |
| DE60204931D1 (de) | 2005-08-11 |
| NO20024446D0 (no) | 2002-09-17 |
| NO325646B1 (no) | 2008-06-30 |
| DE60204931T2 (de) | 2006-06-01 |
| EP1294125B1 (en) | 2005-07-06 |
| US7490146B1 (en) | 2009-02-10 |
| EP1294125A1 (en) | 2003-03-19 |
| NO20024446L (no) | 2003-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2248465T3 (es) | Sistema y procedimiento para enviar informaciones de configuracion de dispositivo a un monitor mediante correo electronico. | |
| US7302469B2 (en) | System, method, and computer program product for transferring remote device support data to a monitor using e-mail | |
| US6839717B1 (en) | Method and system of remote monitoring and support of devices, extracting data from different types of email messages, and storing data according to data structures determined by the message types | |
| US7181619B2 (en) | Method and system of remote monitoring and support of devices, using POP3 and decryption using virtual function | |
| ES2271795T3 (es) | Procedimiento y sistema para extraer informacion de dispositivos de red en un sistema de vigilancia remoto multiprotocolo. | |
| US7519706B2 (en) | Method and system of remote monitoring and support of devices, including handling email messages having message types specified within the e-mail message | |
| US9674066B2 (en) | Method for parsing an information string to extract requested information related to a device coupled to a network in a multi-protocol remote monitoring system | |
| US7533167B2 (en) | Method for efficiently extracting status information related to a device coupled to a network in a multi-protocol remote monitoring system | |
| EP1519514B1 (en) | Method and system for supporting multiple protocols used to monitor networked devices in a remote monitoring system | |
| US7500003B2 (en) | Method and system for using vectors of data structures for extracting information from web pages of remotely monitored devices | |
| US7895321B2 (en) | Method and system for using data structures to store database information for multiple vendors and model support for remotely monitored devices | |
| US7289995B2 (en) | Method and system for using internal data structures for storing information related to remotely monitored devices | |
| US7447766B2 (en) | Method for efficiently storing information used to extract status information from a device coupled to a network in a multi-protocol remote monitoring system | |
| US7437452B2 (en) | Method and system for monitoring network connected devices with multiple protocols | |
| US20060031543A1 (en) | Method and system for initializing protocol information used to extract status information from networked devices | |
| EP1768311A2 (en) | Method and system for script processing in script implementation of http to obtain information from devices | |
| US20050165927A1 (en) | Method and system for managing vendor and model information in a multi-protocol remote monitoring system | |
| EP1785841A2 (en) | Database for multiple implementation of http to obtain information from devices | |
| EP1768025A2 (en) | Method and system for use of abstract classes for script implementation of HTTP to obtain information from devices | |
| EP1768309A2 (en) | Method and system for script implementation of HTTP to obtain information from remote devices | |
| JP2002041374A (ja) | 遠隔監視のためのコンピュータ・プログラム及び方法、記録媒体 | |
| ES2244705T3 (es) | Matriz, procedimiento y dispositivo de moldeo por inyeccion para moldear un disco optico. |