ES2335238T3 - Sistema de comunicacion y aparato de comunicacion y su procedimiento de control. - Google Patents
Sistema de comunicacion y aparato de comunicacion y su procedimiento de control. Download PDFInfo
- Publication number
- ES2335238T3 ES2335238T3 ES07115468T ES07115468T ES2335238T3 ES 2335238 T3 ES2335238 T3 ES 2335238T3 ES 07115468 T ES07115468 T ES 07115468T ES 07115468 T ES07115468 T ES 07115468T ES 2335238 T3 ES2335238 T3 ES 2335238T3
- Authority
- ES
- Spain
- Prior art keywords
- event
- notification
- request
- service provider
- occurrence
- 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.)
- Active
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/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/12—Digital output to print unit, e.g. line printer, chain printer
- G06F3/1293—Printer information exchange with computer
- G06F3/1294—Status or feedback related to information exchange
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Environmental & Geological Engineering (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Mathematical Physics (AREA)
- Data Mining & Analysis (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
Sistema de comunicaciones que comprende un aparato (100) cliente y un aparato (200) proveedor de servicios que proporciona un servicio al aparato cliente a través de un canal (300) de comunicaciones, dicho aparato cliente comprendiendo: medios (5) de solicitud de notificación configurados para emitir una solicitud de notificación para solicitar al aparato proveedor de servicios que notifique de la ocurrencia de un evento; medios (5) de procesamiento de eventos configurados para procesar un evento que ocurre en el aparato proveedor de servicios, medios (5) de determinación configurados para determinar un estado de dichos medios de procesamiento de eventos y unos primeros medios de notificación configurados para notificar, después de que dichos medios de solicitud de notificación emitan la solicitud de notificación, al aparato proveedor de servicios si dichos medios de procesamiento de eventos están activos o no, en base a un resultado de determinación desde dichos medios de determinación, y dicho aparato proveedor de servicios incluye o comprende: medios (12) de detección configurados para detectar la ocurrencia de un evento y unos segundos medios de notificación configurados para notificar a un aparato cliente en el cual dichos medios de procesamiento de eventos están activos la ocurrencia del evento, en base a una notificación desde dichos primeros medios de notificación, si dichos medios de detección detectan la ocurrencia del evento.
Description
Sistema de comunicación y aparato de
comunicación y su procedimiento de control.
La presente invención se refiere a aparatos de
comunicación por red, un sistema de comunicación que incluye los
aparatos y un procedimiento de control para el sistema y los
aparatos de comunicación.
Convencionalmente, es conocido un aparato
proveedor de servicios o un sistema que provee varios tipos de
servicios en respuesta a solicitudes de servicios de aparatos
clientes en una red. Por ejemplo, con la rápida expansión de la
comunicación a través de Internet, se han desarrollado varios tipos
de dispositivos, aparte de los ordenadores personales
convencionales, como dispositivos de red. Además de los dispositivos
interactivos con el usuario tales como PDAs (Asistentes Personales
Digitales) y teléfonos móviles, diversos tipos de aparatos de
procesamiento de imágenes y accesorios eléctricos para el hogar se
han hecho compatibles con redes.
Según esta tendencia, se ha propuesto software
para la búsqueda de dispositivos de red que proveen diversos tipos
de servicios con el fin de mejorar la comodidad y facilidad de uso
en la utilización de estos dispositivos de red. Además, se han
propuesto diversos tipos de protocolos y arquitecturas que
proporcionan medios automáticos de instalación para software de
aplicaciones, software de utilidades, sistemas operativos, y
similares para controlar dichos dispositivos de red (Patentes
Japonesas Abiertas a Inspección Pública Nos.
2004-038956 y 2004-362594).
Varias empresas y organizaciones de
estandarización han hecho esfuerzos para desarrollar
especificaciones a fin de extender la función "plug and play"
(conectar y usar), que se aplica a dispositivos con conexiones
locales de entrada/salida, así como a dispositivos de red. Estos
esfuerzos incluyen, por ejemplo, UPnp (marca registrada) (ver
Arquitectura de Dispositivos UPnP v1.0 en la dirección
http://www.upnp.org/specs/arch/UPnP-DevieArchitecture-v1.0-20060720.pdf)
que Microsoft se encuentra desarrollando principalmente, y
BM-Links ("BMLinks", la Asociación Japonesa de
Maquinaria de Oficina e Industrias de Sistemas de Información,
dirección de Internet (http://www.jbmia.or.jp/bmlinks/eng/index.htm)
que ha sido promovida por WSD: Servicios Web para Dispositivos
(WS-Discovery/WS-MetadataExchange/WS-Eventing,
Web Service Dynamic Discovery: dirección de WS-
Discovery: http://specs.xmlsoap.org/ws/2005/04/discovery/wsdiscovery.pdf dirección de WS-MetadataExchange:
http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf WS-Eventing http://msdn.microsoft.com/
webservices/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-eventing.asp).
Discovery: http://specs.xmlsoap.org/ws/2005/04/discovery/wsdiscovery.pdf dirección de WS-MetadataExchange:
http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf WS-Eventing http://msdn.microsoft.com/
webservices/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-eventing.asp).
Los sistemas de servicios de red ejemplificados
anteriormente utilizan protocolos para la notificación de eventos
tipificados por GENA: Notificación General de Eventos,
WS-Eventing y similares. Esto permite que un
dispositivo cliente detecte, en tiempo real, un cambio en el estado
de un dispositivo que proporciona un servicio, es decir, el estado
procesado de un trabajo que el dispositivo ha solicitado ejecutar,
un estado de error, un cambio de estado, tal como, la actualización
de la información de configuración ("ocurrencia de un evento"),
o similares.
Las técnicas convencionales anteriormente
mencionadas, sin embargo, presentan los siguientes problemas. Según
un protocolo de notificación de eventos, un dispositivo cliente
necesita emitir por adelantado una solicitud de notificación de
eventos a un dispositivo proveedor de servicios. El dispositivo
proveedor de servicios debe mantener y gestionar todas las partes
de información referentes a solicitudes de notificación recibidas
de todos los dispositivos clientes. Cuando ocurre un evento, el
dispositivo proveedor de servicios debe notificar a todos los
dispositivos clientes desde los que se hayan recibido solicitudes de
notificación de la ocurrencia del evento. De estos eventos, eventos
asociados con cambios en el estado que acompañan la ejecución de un
trabajo pueden incluir, posiblemente, un inicio de trabajo, avance
de trabajo, finalización de trabajo, error y similares. Con el fin
de transmitir las notificaciones de la ocurrencia de estos eventos a
los clientes de los que se han recibido solicitudes de
notificación, es necesario asegurar una conexión de red que incluya
recuperación de errores y similares. Esto supone una pesada carga
para los dispositivos proveedores de servicios. Además, esta pesada
carga ha provocado, por ejemplo, el problema de fallo al notificar
un evento importante y urgente que retardará en gran medida la
notificación del evento a las herramientas de gestión de la red.
Por otra parte, es posible que incluso si el
dispositivo proveedor de servicios notifica a un dispositivo
cliente, del que se ha recibido una solicitud de notificación de un
evento, el dispositivo cliente no tenga la función de procesamiento
del evento, es decir, no tenga la función de analizar el contenido
del evento y notificar al usuario de la información resultante.
Además, en el dispositivo cliente, una función, aplicación,
utilidad o similar que procesa un evento puede no estar activada
(por ejemplo estar invalidada). En ese caso, se desperdician la
información del evento notificado y el proceso realizado para la
notificación.
En un dispositivo proveedor de servicios con
recursos de hardware limitados, un dispositivo utilizado en entorno
de red doméstica, en particular, o en un entorno tal como una
oficina en la que existen varios dispositivos cliente, se requiere
alguna estrategia para minimizar el excesivo procesamiento de
eventos y la excesiva notificación de eventos.
\global\parskip0.950000\baselineskip
El documento US 6734985 da a conocer un sistema
que comprende una impresora y un ordenador principal en el que el
ordenador principal envía solicitudes de registro periódicas a la
impresora y la impresora registra el ordenador principal como
respuesta a las solicitudes de registro. Si la impresora no recibe
una solicitud de registro durante un tiempo de retención, la
impresora elimina el registro del ordenador principal.
Es un objetivo de la presente invención abordar
los problemas antes descritos de la tecnología convencional.
Una ventaja de la presente invención es que
notificaciones de eventos innecesarias son eliminadas
sustancialmente mediante la notificación a los aparatos clientes,
de aparatos clientes cuyas solicitudes de notificaciones de eventos
se han registrado, que están listos para realizar el procesamiento
de eventos.
Según la presente invención, es posible eliminar
la notificación innecesaria de la ocurrencia de eventos mediante la
notificación a los aparatos clientes, de aparatos clientes cuyas
solicitudes de notificaciones de eventos se han registrado, que
están listos para realizar el procesamiento de eventos. Esto puede
reducir la carga de un proceso de comunicación de eventos. Además,
esto puede mejorar el rendimiento en tiempo real de la notificación
de eventos que la notificación de eventos, supuestamente, debe
tener.
Según un primer aspecto de la presente
invención, se da a conocer un sistema de comunicaciones como se
especifica en la reivindicaciones 1-6.
Según un segundo aspecto de la presente
invención, se da a conocer un aparato de comunicación como se
especifica en las reivindicaciones 7 a 9.
Según un tercer aspecto de la presente
invención, se da a conocer un procedimiento de control como se
especifica en las reivindicaciones 10 a 17.
Las características adicionales de la presente
invención serán evidentes a partir de la siguiente descripción de
realizaciones a título de ejemplo en referencia a los dibujos
anexos.
Los dibujos adjuntos, que están incorporados y
constituyen parte de la descripción, ilustran una realización de la
invención y un ejemplo ilustrativo y, junto con la descripción,
sirven para explicar los principios de la presente invención.
La figura 1 es un diagrama de bloques que
muestra la disposición de un sistema de red plug and play según una
realización a título de ejemplo de la presente invención;
las figuras 2A y 2B son diagramas de flujo para
explicar el procesamiento de control en un dispositivo cliente
según la primera realización de la presente invención;
la figura 3 es un diagrama de flujo para
explicar el procesamiento de control en un dispositivo de red según
la primera realización;
la figura 4 muestra los datos XML que describen
el formato de una tabla de gestión según la realización;
la figura 5 muestra el formato de un mensaje de
notificación de estado según esta realización;
la figura 6 es un diagrama de flujo que muestra
un procedimiento de procesamiento de control en un caso donde ha
ocurrido un evento en el dispositivo de red según la primera
realización;
las figuras 7A y 7B son diagramas de flujo para
explicar el procesamiento de control en un dispositivo cliente
según el ejemplo ilustrativo; y
la figura 8 es un diagrama de flujo para
explicar el procesamiento de control en el dispositivo de red según
el ejemplo ilustrativo.
A continuación se describirán en detalle una
realización de la presente invención y un ejemplo ilustrativo en
referencia a los dibujos anexos. La siguiente realización no
pretende limitar las reivindicaciones de la presente invención, y
no todas las combinaciones de elementos descritos en la realización
son esenciales para la presente invención. Además, debe observarse
que no se pretende limitar el ámbito de la presente invención a
protocolos, versiones, direcciones, otros valores numéricos y
similares descritos en la realización, a menos que se especifique
lo contrario.
La figura 1 es un diagrama de bloques que
muestra la disposición de un sistema de red plug and play según una
realización a título de ejemplo de la presente invención.
\global\parskip1.000000\baselineskip
En referencia a la figura 1, el numeral de
referencia (100) indica un dispositivo cliente, que tiene un función
de comunicación que corresponde a Ethernet. El dispositivo cliente
(100) comprende una pila (1) de protocolos TCP/UDP/IP y un
procesador (2) HTTP en la pila (1) de protocolos. El dispositivo
cliente (100) analiza una solicitud HTTP y realiza un procesamiento
de respuesta. El dispositivo cliente (100) comprende un procesador
(3) SOAP (Protocolo Simple de Acceso a Objetos) en la capa superior
de la pila (1) de protocolos TCP/UDP/IP y del procesador (2) HTTP.
Además, un controlador (4) plug and play, un gestor (5) de eventos,
utilidades (6) y aplicaciones (7) implementan una comunicación
bidireccional de datos descritos en XML.
El controlador (4) plug and play ejecuta un
procesamiento de respuesta correspondiente a un mensaje "Hello"
notificado desde un dispositivo de red a través del procesador (3)
SOAP en base a las especificaciones de WS-Discovery
que se han desarrollado por Microsoft y otras compañías. Además, el
controlador (4) plug and play emite un mensaje de sondeo
"Probe" para buscar un dispositivo de red. El controlador (4)
plug and play también ejecuta el procesamiento de adquisición de la
información de los atributos de un dispositivo de red mediante la
emisión de un mensaje "GetMetadata" en base a las
especificaciones de WS-MetadataExchange.
Si un dispositivo (200) de red comprende una
función de notificación de eventos, la información de los atributos
del dispositivo (200) de red registra la información de destino del
registro de una solicitud de notificación de eventos. El gestor (5)
de eventos emite una solicitud de notificación de eventos (mensaje
"Subscribe") al destino del registro de esta solicitud de
notificación de eventos a través del procesador (3) SOAP en base a
las especificaciones de WS-Eventing que se han
desarrollado por Microsoft y otras compañías. Alternativamente, el
gestor (5) de eventos emite una solicitud de cancelación (mensaje
"UnSubscribe") para la notificación de eventos. El gestor (5)
de eventos verifica la presencia/ausencia de solicitudes de
notificación de eventos provenientes de las utilidades (6) y
aplicaciones (7). Si una de las utilidades (6) o aplicaciones (7)
que se encuentran en estado activo requiere una solicitud de
notificación de eventos, el gestor (5) de eventos emite un mensaje
de estado al dispositivo (200) de red a través del procesador (3)
SOAP. Además, el gestor (5) de eventos tiene una función para emitir
un mensaje de estado al dispositivo (200) de red a través del
procesador (3) SOAP cuando todas las utilidades (6) y las
aplicaciones (7) que requieren una notificación de eventos no se
encuentran en estado activo.
El gestor (5) de eventos recibe la información
de los eventos notificados provenientes del dispositivo (200) de
red a través del procesador (3) SOAP. A continuación, el gestor (5)
de eventos notifica las utilidades (6) y las aplicaciones (7), que
han emitido, previamente, solicitudes de notificación del evento. En
este caso las utilidades (6) y las aplicaciones (7) incluyen
software que tiene funciones de procesamiento de eventos
notificados desde el dispositivo (200) de red, por ejemplo, un
dialogo del controlador de la impresora, una vista de la cola de
impresión y una aplicación para la gestión de la red.
El dispositivo (200) de red se describirá a
continuación.
En esta realización, el dispositivo (200) de red
tiene una función de comunicación que corresponde a Ethernet. El
dispositivo (200) de red comprende una pila (8) de protocolos
TCP/UDP/IP y un procesador (9) HTTP en la pila (8) de protocolos.
El dispositivo (200) de red analiza las solicitudes HTTP y realiza
un procesamiento de respuesta. El dispositivo (200) de red (200)
incluye un procesador (10) SOAP en la capa superior de la pila (8)
de protocolos TCP/UDP/IP y del procesador (9) HTTP. Un módulo (11)
WSD, un gestor (12) de eventos y un controlador (13) de impresora
implementan una comunicación bidireccional de datos descritos en XML
a través del procesador (10) SOAP.
Cuando se conecta a una red (300), un módulo
(11) WSD transmite un mensaje "Hello" a través del procesador
(10) SOAP en base a las especificaciones de
WS-Discovery que se han desarrollado por Microsoft y
otras compañías. Además, el módulo (11) WSD ejecuta un
procesamiento de respuesta con respecto a un mensaje "Probe"
emitido por el dispositivo (100) cliente. El módulo (11) WSD
también devuelve información de atributos, que el dispositivo (200)
de red (una impresora de red en esta realización) tiene, de acuerdo
con el mensaje "GetMetadata" emitido desde el dispositivo
(100) cliente en base a las especificaciones de
WS-MetadataExchage.
El gestor (12) de eventos tiene una función de
gestionar una solicitud de notificación de eventos (Active) y una
solicitud de cancelación de notificación de eventos (InActive)
notificadas desde el dispositivo (100) cliente para cada una de una
serie de dispositivos clientes incluyendo el dispositivo (100)
cliente. El gestor (12) de eventos gestiona información del estado
de la impresora notificada desde el controlador (13) de la
impresora, y genera datos correspondientes al evento. El gestor (12)
de eventos también tiene una función de transmitir un mensaje de un
evento al dispositivo (100) cliente a través del procesador (10)
SOAP.
A continuación se describirá un procedimiento de
control del sistema de red plug and play según esta realización
haciendo referencia a los diagramas de flujo de las figuras 2A, 2B y
3.
Primera
Realización
Las figuras 2A y 2B son diagramas de flujo para
explicar el procesamiento de control en un dispositivo (100)
cliente según la primera realización. La figura 3 es un diagrama de
flujo para explicar el procesamiento de control en un dispositivo
(200) de red según la primera realización.
Primeramente, en la etapa (S101), un controlador
(4) plug and play del dispositivo (100) cliente busca un
dispositivo proveedor de servicios que pueda ser utilizado en una
red (300), esto es, el dispositivo de red (200). En este caso, el
controlador (4) plug and play emite un paquete de búsqueda de
dispositivo de red (paquete Probe) definido por las
especificaciones de WS-Discovery a través del
procesador (3) SOAP en la etapa (S101). En la etapa (S102), el
controlador (4) plug and play determina si se ha recibido o no una
respuesta. En caso afirmativo en la etapa (S102), el proceso avanza
hacia la etapa (S103) para obtener el perfil del dispositivo que ha
transmitido la respuesta.
Por otra parte, el dispositivo (200) de red
transmite un mensaje "Hello" en la etapa (S200) en la figura 3,
y a continuación en la etapa (S201), el dispositivo de red espera
la recepción del paquete "Probe" transmitido desde el
dispositivo (100) cliente en la etapa (S101) anteriormente descrito.
Cuando el dispositivo (200) de red recibe este paquete en la etapa
(S201), el proceso avanza hacia la etapa (S202), en la que el módulo
(11) WSD del dispositivo (200) de red transmite información de la
dirección para la adquisición de información de perfil al
dispositivo (100) cliente en respuesta al paquete. En este caso el
dispositivo (200) de red describe la información en una respuesta
"ProbeMatch" y la devuelve al dispositivo (100) cliente como un
paquete de respuesta definido por las especificaciones de
WS-Discovery a través del procesador (10) SOAP.
Mediante esta operación, el controlador (4) plug
and play del dispositivo (100) cliente, que ha recibido dicha
respuesta "ProbeMatch" en la etapa (S102) obtiene la
información de perfil del dispositivo (200) de red que ha emitido
la respuesta en la etapa (S202). En este caso, el dispositivo (100)
cliente emite una solicitud "GetMetadata" definida por las
especificaciones de WS-MetadataExchange para la
dirección descrita en la respuesta "ProbeMatch" previamente
recibida a través del procesador (3) SOAP. Se debe observar que
puede haber una serie de dispositivos de red en la red (300). Por
esta razón, el dispositivo (100) cliente selecciona los dispositivos
a utilizar de los dispositivos que han devuelto las respuestas
"ProbeMatch". El dispositivo (100) cliente obtiene,
posteriormente, la información de perfil de todos los dispositivos
de red seleccionados.
Mediante esta operación, si el dispositivo (200)
de red recibe la solicitud "GetMetadata" en la etapa (S203) de
la figura 3, el proceso avanza a la etapa (S204), en el que el
módulo (11) WSD provoca que el procesador (10) SOAP transmita la
información de perfil al dispositivo (100) cliente.
Mediante esta operación, el dispositivo (100)
cliente obtiene la información de perfil del dispositivo (200) de
red. El controlador (4) plug and play notifica posteriormente al
gestor (5) de eventos la dirección de registro de la solicitud de
notificación de eventos descrita en la información de perfil.
Mediante esta operación, el gestor (5) de eventos emite una
solicitud de registro de notificación de eventos (solicitud
"Subscribe") definida por las especificaciones de
WS-Eventing con respecto a la dirección a través del
procesador (3) SOAP (etapa -S104-).
Mediante esta operación, en la etapa (S205), el
dispositivo (200) de red recibe esta solicitud "Subscribe". El
proceso posteriormente avanza de la etapa (S205) a la etapa (S206),
en el que el gestor (12) de eventos genera un "SubscribeID"
para identificar de forma única el dispositivo (100) cliente. El
dispositivo (200) de red almacena el "SubscribeID" y la
información de la dirección del destino de la notificación de
eventos del dispositivo (100) cliente que está descrita en la
solicitud "Subscribe" como una tabla de gestión.
La figura 4 representa una vista que muestra
datos XML que describen el formato de esta tabla de gestión.
En este caso, el valor de "SubscribeID" que
el gestor (12) de eventos asigna al dispositivo (100) cliente se
describe en la etiqueta (400) <SubscribeID> en forma de valor
de un atributo. En la etiqueta (401) <EventPort>, se describe
la información de la dirección de notificación de un evento del
dispositivo (100) cliente en forma de URL. Además, se utiliza
<Status> (402) para almacenar el estado de operación del
software de procesamiento de eventos en el dispositivo (100) cliente
(el cual se describirá posteriormente) y está descrito como
"Active" (en servicio) o "InActive" (fuera de servicio) en
relación al estado de operación. Parte de la información
correspondiente a los respectivos dispositivos clientes registrados
se almacena como una tabla en dicho formato.
El proceso avanza a la etapa (S207), donde el
gestor (12) de eventos describe la "SubscribeID" generada en
el paquete de respuesta "Subscribe" definido por las
especificaciones de WS-Event. El gestor (12) de
eventos transmite posteriormente la respuesta "Subscribe" al
dispositivo (100) cliente a través del procesador (10) SOAP.
Mediante esta operación, en la etapa (S105), el
dispositivo (100) cliente recibe esta respuesta "Subscribe", y
el proceso avanza a la etapa (S106), donde el gestor (5) de eventos
almacena la "SubscribeID" descrita en este paquete.
Posteriormente, el proceso avanza a la etapa (S107).
En la etapa (S107) el gestor (5) de eventos del
dispositivo (100) cliente determina si las utilidades (6) y las
aplicaciones (7), que funcionan en la capa superior, están activas.
En este caso, el gestor (5) de eventos determina si por lo menos un
elemento del software, de las utilidades (6) o de las aplicaciones
(7), que procesan el evento notificado desde el dispositivo (200)
de red, por ejemplo, un diálogo de un controlador, una vista de la
cola de impresión y software para gestión de dispositivos de red, se
encuentra activa. En este caso, si por lo menos un elemento del
software se encuentra activo, ellos operan para registrar una
solicitud de notificación de eventos en el gestor (5) de
eventos.
Si el gestor (5) de eventos determina en la
etapa (S107) que una de las utilidades (6) o aplicaciones (7) se
encuentra activa y recibe el registro de la solicitud de
notificación de eventos desde estos elementos del software, el
proceso avanza hacia la etapa (S108), donde el gestor (5) de eventos
determina si se ha obtenido un "SubscribeID". Si ya se ha
obtenido el "UnSubscribeID" desde el dispositivo (200) de red,
el proceso avanza desde la etapa (S107) hacia la etapa (S109)
(figura 2B). En la etapa (S109), el gestor (5) de eventos determina
si el número total de utilidades (6) y aplicaciones (7) que han
emitido las solicitudes de notificación de eventos y que están
activas es igual o mayor a "1". Si la respuesta es SI en la
etapa (109), el proceso avanzo a la etapa (S110). En la etapa
(S110), el gestor (5) de eventos determina si un mensaje de
notificación de estado ha sido anteriormente emitido. Si la
respuesta es NO en la etapa (S110), el proceso avanza a la etapa
(S111), donde el gestor (5) de eventos emite un mensaje de
notificación de estado (Active) al dispositivo (200) de red a
través del procesador (3) SOAP. El proceso, posteriormente, avanza a
la etapa (S113).
Si el gestor (5) de eventos determina en la
etapa (S109) que el número total de utilidades (6) y aplicaciones
(7) que han emitido las solicitudes de notificación de eventos y que
están activas es "0", o determina en la etapa (S110) que un
mensaje de notificación de estado y ha sido emitido anteriormente,
el proceso avanza hacia la etapa (S113) sin emitir ningún mensaje
de notificación de estado. Si el gestor (5) de eventos determina en
la etapa (S108) (figura 2A) que no se ha obtenido el
"SubscribeID", el proceso avanza hacia la etapa (S112), en el
que el gestor (5) de eventos notifica un error a las utilidades (6)
o a las aplicaciones (7). Posteriormente, el proceso avanza hacia
la etapa (S113).
La figura 5 muestra una vista para la
explicación del formato de un mensaje de notificación de estado. El
procesador (3) SOAP convierte este mensaje en forma "envelope"
SOAP y posteriormente lo transmite al dispositivo (200) de red.
En este caso, en <"SubscribeID">
(500), se describe el identificador (SubscriptionID) obtenido del
dispositivo (200) de red en la etapa (S106) (figura 2A). En
<Status> (501), se describe el estado de operación de la
utilidad (6) o aplicación (7) que emitió la solicitud de
notificación de eventos. Cuando la utilidad (6) o la aplicación (7)
se encuentran en servicio, su estado de operación se define como
"Active".
Si el dispositivo (200) de red recibe este
mensaje de notificación de estado en la etapa (S208) en la figura
3, el proceso avanza a la etapa (S209), en el que el gestor (12) de
eventos se refiere al "SubscribeID" descrito en el mensaje de
notificación de estado mediante la utilización de la tabla de
gestión anteriormente mencionada. Posteriormente, el gestor (12) de
eventos busca, en la tabla de gestión, la información del
dispositivo cliente correspondiente y actualiza el campo
<Status> en la tabla de gestión según el contenido del
<Status> (501) recibido (figura 5). Posteriormente, el
proceso avanza a la etapa (S210).
Por otra parte, si el gestor (5) de eventos
determina en la etapa (S107) en la figura 2A que ninguno de los
elementos del software, de las utilidades y de las aplicaciones, que
procesan un evento desde un dispositivo de red, por ejemplo, un
diálogo de un controlador, vista de la cola de impresión y software
para gestión de dispositivos de red, están activos, el proceso
avanza a la etapa (S113) (figura 2B). El elemento de software
notifica al gestor (5) de eventos la cancelación del registro de la
solicitud de notificación del evento. Si el gestor (5) de eventos
recibe la cancelación del registro de la solicitud de notificación
de eventos desde cualquiera de las utilidades (6) y de las
aplicaciones (7) en la etapa (S113), el proceso avanza a la etapa
(S114). En la etapa (S114), el gestor (5) de eventos determina si el
número total de utilidades (6) y aplicaciones (7) que han emitido
las solicitudes de notificación de eventos y que están activas es
"0". Si el resultado es SI en la etapa (S114), el proceso
avanza a la etapa (S115) para emitir un mensaje de notificación de
estado al dispositivo (200) de red a través del procesador (3) SOAP
y posteriormente, el proceso avanza a la etapa (S116). En este
caso, el gestor (5) de eventos introduce "Inactive" en la
etiqueta (501) de <Status> mostrada en la figura 5
anteriormente descrita.
Si el gestor (5) de eventos determina en la
etapa (S114) que el número total de utilidades (6) y aplicaciones
(7) que requieren notificaciones de eventos y que están activas es
igual o mayor que "1", o si el gestor (5) de eventos no recibe
la cancelación del registro de la solicitud de notificación de
eventos de ninguna de las utilidades (6) y de las aplicaciones (7)
en la etapa (S113), el proceso avanza a la etapa (S116) sin emitir
ningún mensaje de notificación de estado. En la etapa (S116), el
gestor (5) de eventos determinar si es necesario cancelar el
registro de una solicitud de notificación de eventos. Si el
resultado es SI en la etapa (S116), el proceso avanza a la etapa
(S117). Si el resultado es NO en la etapa (S116), el proceso avanza
a la etapa (S118) (figura 2A).
Mediante esta operación, al recibir el mensaje
de notificación de estado emitido en la etapa (S115), el dispositivo
(200) de red recibe el mensaje de notificación de estado en la
etapa (S208) de la forma descrita anteriormente. En la etapa
(S209), el dispositivo (200) de red cambia el campo <Status>
en la tabla de gestión según el contenido del mensaje recibido.
De esta forma, el gestor (5) de eventos del
dispositivo (100) cliente repite el procesamiento de las etapas
(S107) a (S116) anteriormente descritos y monitoriza los estados de
operación de las utilidades (6) y de las aplicaciones (7) que
ejecutan el procesamiento de eventos.
Se debe observar que en caso de que el estado de
operación del dispositivo (100) cliente cambie a un estado de
reposo (standby) o se apague, el proceso avanza de la etapa (S116) a
la etapa (S117) en la figura 2B. En la etapa (S117), el gestor (5)
de eventos emite una solicitud de cancelación de registro (solicitud
"UnSubscribe") para una solicitud de notificación de eventos,
que se define por las especificaciones de
WS-Eventing, al dispositivo (200) de red a través
del procesador (3) SOAP.
Mediante esta operación, el dispositivo (200) de
red recibe esta solicitud "UnSubscribe" en la etapa (S210)
(figura 3). Posteriormente, el gestor (12) de eventos del
dispositivo (200) de red se remite al "SubscribeID" descrito
en la solicitud "UnSubscribe" en la tabla anteriormente
descrita en la etapa (S211). Posteriormente, el gestor (12) de
eventos busca en la tabla de gestión al dispositivo cliente
correspondiente, y borra la información del dispositivo cliente
correspondiente de la tabla de gestión.
Si el dispositivo (100) cliente no puede recibir
la respuesta "ProbeMatch" en la etapa (S102) en la figura 2A,
el proceso avanza a la etapa (S118). El controlador (4) plug and
play monitoriza en la etapa (S118) si el dispositivo (100) cliente
ha recibido el mensaje "Hello" transmitido desde el dispositivo
(200) de red que participa en la red (300). Si el resultado es SI
en la etapa (S118), el proceso avanza a la etapa (S103) para
ejecutar el siguiente procesamiento. Si el dispositivo (100) cliente
no ha recibido el mensaje "Hello" en la etapa (S118), el
proceso avanza a la etapa (S107).
Se debe observar que el mensaje "Hello" es
un paquete emitido cuando el dispositivo (200) de red se activa
para estar listo para proporcionar un servicio en la red (300). En
este caso, este paquete es definido por las especificaciones de
WS-Discovery y emitido en la etapa (S200) en la
figura 3.
La figura 6 es un diagrama de flujo que muestra
un procedimiento de procesamiento control en el caso de que ocurra
un evento en el dispositivo (200) de red según la primera
realización.
Este diagrama de flujo muestra el procesamiento
del dispositivo (200 de red, es decir, una impresora de red. El
procesamiento se activa en el momento de la ocurrencia de un evento
asociado con un cambio en el estado de transición referente a un
trabajo, un evento asociado a un error, un evento asociado con un
cambio de una opción de un aparato, un evento asociado con un
cambio en la configuración o similares. En primer lugar, en la
etapa (S301), se determina si ocurre o no algún tipo de evento. Si
ocurre algún tipo de evento, entonces el controlador (10) de la
impresora notifica al gestor (12) de eventos la ocurrencia del
evento. Posteriormente, el proceso avanza a la etapa (S302), donde
el gestor (12) de eventos que ha recibido esta notificación busca
en la tabla de gestión. En la etapa (S303), el gestor (12) de
eventos determina si la información "Subscribe" está descrita
y si <Status> se encuentra en estado "Active". Si el
resultado es SI en la etapa (S303), el proceso avanza a la etapa
(S304) para notificar la ocurrencia del evento con relación a la
dirección descrita en la tabla de gestión.
En este caso, el gestor (12) de eventos describe
el evento notificado mediante el controlador (13 de la impresora en
XML de acuerdo con el formato de notificaciones definido por las
especificaciones de WS-Eventing. El gestor (12) de
eventos transmite, además, la información resultante al dispositivo
(100) cliente a través del procesador (10) SOAP.
Si el controlador (13) de la impresora determina
en la etapa (S303) que la información "Subscribe" no está
descrita en la tabla de gestión, o si <Status> está
"InActive" aunque la información "Subscribe" esté
descrita en la tabla de gestión, el proceso se salta la etapa (S304)
y avanza a la etapa (S305). Mediante esta operación, el dispositivo
(100) cliente, que tenga inactivas todas las utilidades (6) y la
aplicación (7) que ejecuta el procesamiento de eventos, no será
notificado del evento.
En la etapa (S305), el gestor (12) de eventos
determina si el procesamiento de la notificación de un evento en
relación a todas las partes de la información de
"DescriptionID" almacenadas en la tabla de gestión, está
completa o no. Si el resultado es NO en la etapa (S305), el proceso
regresa a la etapa (S302) para buscar la tabla de gestión y
ejecutar el procesamiento antes descrito, de lo contrario se termina
el proceso.
Por otra parte, tras recibir la notificación del
evento desde el dispositivo (200) de red, el gestor (5) de eventos
del dispositivo (100) cliente notifica a la utilidad (6) o a la
aplicación (7) cuya solicitud de notificación de eventos ha sido
registrada, de la información recibida del evento.
Como se describió anteriormente, según la
primera realización, se ejecutan unas series de procesamientos de
control descritas en los diagramas de flujo de las figuras 2A y 2B,
3 y 6. Esto hace posible controlar el dispositivo (200) de red para
notificar un evento únicamente cuando una utilidad (6) o aplicación
(7) cualquiera, que ejecuta el procesamiento de eventos, esté
activa en el dispositivo (100) cliente, que es una característica
de esta primera realización.
Esto hace posible notificar la ocurrencia de un
evento a un único dispositivo cliente, de los dispositivos clientes
cuyas solicitudes de notificación de eventos han sido registradas,
lo cual es realizar el procesamiento de eventos. Por lo tanto,
pueden evitarse notificaciones innecesarias de la ocurrencia de
eventos.
Además, esto puede reducir la carga de un
proceso de comunicación de eventos y entregar la notificación de la
ocurrencia de un evento en tiempo real.
Ejemplo
Ilustrativo
En la primera realización anteriormente
descrita, el gestor (5) de eventos del dispositivo (100) cliente
emite una solicitud de notificación de estado al dispositivo (200)
de red de acuerdo con los estados de operación de las utilidades
(6) y aplicaciones (7) que funcionan en la capa superior.
Si el dispositivo (100) es un dispositivo
cliente en el que el número de utilidades (6) y aplicaciones (7)
que se encuentra inactivas es pequeño, es posible realizar un
control utilizando únicamente la información "Subscribe"
enviada al dispositivo (200) de red para determinar si se emite una
solicitud de notificación de eventos.
El ejemplo ilustrativo será descrito a
continuación haciendo referencia a las figuras 7A, 7B y 8. Se debe
observar que las configuraciones de una disposición del aparato y
del sistema según el ejemplo ilustrativo son las mismas que las
mencionadas en la primera realización, y se omitirá una descripción
repetitiva.
Las figuras 7A y 7B son diagramas de flujo para
explicar el procesamiento de control en un dispositivo (100)
cliente según el ejemplo ilustrativo. La figura 8 es un diagrama de
flujo para explicar el procesamiento de control en un dispositivo
(200) de red según el ejemplo ilustrativo. Los mismos numerales de
las etapas en las figuras 7A, 7B y 8 indican procesos comunes a los
de las figuras 2A, 2B y 3, y se omitirá una descripción
repetitiva.
Tras la adquisición de información del
dispositivo en la etapa (S401), el gestor (5) de eventos del
dispositivo (100) cliente monitoriza los estados de operación de
las utilidades (6) y de las aplicaciones (7) que funcionan en la
capa superior.
Si por lo menos un elemento del software, de las
utilidades (6) o de las aplicaciones (7), que procesan un evento
desde un dispositivo de red, por ejemplo, un dialogo de un
controlador, una vista de la cola de impresión, y software para
gestión de dispositivos de red, está activo, el elemento del
software registra una solicitud de notificación de eventos con
respecto al gestor (5) de eventos.
Cuando el gestor (5) de eventos recibe una
solicitud de registro para una solicitud de notificación de eventos
desde una utilidad (6) o aplicación (7) de esta forma en la etapa
(S107), el proceso avanza a la etapa (S109). En la etapa (S109), el
gestor de eventos (5) determina si el número total de las utilidades
(6) y de las aplicaciones (7) que han emitido solicitudes de
notificación de eventos y que están activas es igual o mayor que
"1". Si el resultado es SI en la etapa (S109), el proceso
avanza a la etapa (S402) para determinar si ha sido emitida una
solicitud de registro para una solicitud de notificación de eventos
(solicitud "Subscribe"). Si el resultado es NO en la etapa
(S402), el proceso avanza a la etapa (S403) para emitir una
solicitud de registro para una solicitud de notificación de eventos
(solicitud "Subscribe") definida por las especificaciones de
WS-Eventing al dispositivo (200) de red a través
del procesador (3) SOAP. Se debe observar que si el gestor (5) de
eventos determina en la etapa (S402) que se ha emitido una
solicitud "Subscribe", el proceso avanza a la etapa (S113)
(figura 7B).
Cuando el gestor (12) de eventos del dispositivo
(200) de red recibe esta solicitud "Subscribe" en la etapa
(S205) en la figura 8, el proceso avanza a la etapa (S501) (figura
8) para generar un "SubscribeID" para identificación única del
dispositivo cliente. Posteriormente, el gestor (12) de eventos
registra el "SubscribeID" y la información de dirección del
destino de la notificación del evento del dispositivo (100) cliente
descrito en la solicitud "Subscribe" en la tabla de gestión. A
continuación, en la etapa (S502), el gestor (12) de eventos describe
la "SubscribeID" generada en un paquete de respuesta
"Subscribe" definido por las especificaciones de
WS-Event. Posteriormente, el gestor (12) de eventos
transmite la respuesta "Subscribe" al dispositivo (100) cliente
a través del procesador (10) SOAP.
Mediante esta operación, el dispositivo (100)
cliente determina en la etapa (S404) si se ha recibido esta
respuesta "Subscribe". Si el resultado es NO en la etapa
(S404), el proceso avanza a la etapa (S405) para entregar una
notificación de un error. Posteriormente, el proceso avanza a la
etapa (S113) (figura 7B). Si el resultado es SI en la etapa (S404),
el proceso avanza a la etapa (S406), donde el gestor (5) de eventos
almacena el "SubscribeID" descrito en el paquete.
Posteriormente, el proceso avanza a la etapa (S113) (figura
7B).
En la etapa (S113) de la figura 7B, el gestor
(5) de eventos verifica los estados de los elementos de software,
de las utilidades (6) y de las aplicaciones (7), que procesan un
evento desde el dispositivo (200) de red, por ejemplo, un dialogo
de un controlador, una vista de la cola de impresión, y software
para gestión de dispositivos de red. Si todos los elementos de
software que procesan el evento están finalizados, entonces el
software notifica al gestor (5) de eventos de la cancelación del
registro de la solicitud de notificación de eventos.
Si el gestor (5) de eventos recibe la
cancelación del registro de la solicitud de notificación de eventos
desde una de las utilidades (6) y de las aplicaciones (7), el
proceso avanza de la etapa (S113) a la etapa (S114) (figura 7B). En
la etapa (S114), el gestor de eventos (5) determina si el número
total de las utilidades (6) y de las aplicaciones (7) que han
emitido las solicitudes de notificación de eventos y que están
activas es "0". Si la respuesta es SI en la etapa (S114), el
proceso avanza a la etapa (S407) (figura 7B) para emitir una
solicitud de cancelación de registro (solicitud "UnSubscribe")
para una solicitud de notificación de eventos que se define por las
especificaciones de WS-Eventing al dispositivo (200)
de red a través del procesador (3) SOAP.
Mediante esta operación, el gestor (12) de
eventos del dispositivo (200) de red recibe esta solicitud
"UnSubscribe" en la etapa (S210) de la figura 8, y el proceso
avanza a la etapa (S503). En la etapa (S503), el gestor (12) de
eventos se remite al "SubscribeID" descrito en la solicitud
"UnSubscribe" en la tabla de gestión anteriormente descrita.
Posteriormente, el gestor (12) de eventos busca en la tabla de
gestión la información del dispositivo cliente correspondiente, y
borra la información correspondiente al dispositivo cliente de la
tabla de gestión.
\newpage
De esta manera, en caso de que se produzca un
evento en el dispositivo (200) de red, el gestor (12) de eventos
busca en la tabla de gestión. Si la información "Subscribe"
está descrita en la tabla, el gestor (12) de eventos notifica la
ocurrencia del evento con respecto a la dirección descrita en la
tabla de gestión.
El procesamiento anterior permite emitir una
solicitud de notificación de eventos al dispositivo (200) de red
únicamente cuando por lo menos una de las utilidades (6) o de las
aplicaciones (7) que pueden ejecutar el procesamiento de eventos
está activa en el dispositivo (100) cliente.
Esto hace posible entregar una notificación de
la ocurrencia de un evento únicamente a un dispositivo cliente, de
los dispositivos clientes cuyas solicitudes de notificación de
eventos han sido registradas, que está listo para realizar el
procesamiento de eventos. Por lo tanto, se pueden evitar
notificaciones innecesarias de la ocurrencia de eventos.
Además, esto puede reducir la carga de un
proceso de comunicación de eventos y entregar la notificación de la
ocurrencia de un evento en tiempo real.
En la primera realización y en el ejemplo
ilustrativo anteriormente descrito, en las etapas (S111) y (S115)
en la figura 2B, el gestor (5) de eventos emite un mensaje de
notificación de estado al dispositivo (200) de red en relación a
los estados de operación de las utilidades (6) y aplicaciones (7)
que pueden procesar el evento.
Se supone que el dispositivo (100) cliente puede
ejecutar simultáneamente una serie de utilidades (6) y aplicaciones
(7), y cada programa de software tiene una función para mostrar una
interfaz de usuario en forma de ventana. En este caso, es posible
solicitar al gestor (5) de eventos registrar una solicitud de
notificación de eventos e, incluso si el software correspondiente
se encuentra activo, hacer que el gestor (5) de eventos monitorice
si una ventana para el software correspondiente se encuentra abierta
(por ejemplo, activa). Si el número total de elementos de software,
de utilidades (6) y de aplicaciones (7) que han emitido solicitudes
de notificación de eventos y cuyas ventanas se encuentran abiertas
es igual o mayor que "1", el gestor (5) de eventos emite un
mensaje de notificación de estado al dispositivo (200) de red. Esto
hace posible entregar una notificación de la ocurrencia de un
evento solicitado únicamente cuando al menos una de las utilidades
(6) y de las aplicaciones (7) que ejecutan el procesamiento del
evento está activa en el dispositivo (100) cliente y una ventana
como interfaz de usuario está abierta.
Según la primera realización y el ejemplo
ilustrativo, cuando todas las utilidades (6) y aplicaciones (7) que
ejecutan un procesamiento de un evento están inactivas en el
dispositivo (100) cliente, el dispositivo (200) de red no notifica
ningún evento al dispositivo (100) cliente. Sin embargo, es posible
notificar al dispositivo (100) cliente de la ocurrencia de eventos
predeterminados tales como un estado de error importante y un
cambio de estado asociado con un cambio en la disposición de un
dispositivo sin importar si las utilidades (6) o aplicaciones (7)
están activas.
Además, la primera realización y el ejemplo
ilustrativo anteriormente descritos utilizan los protocolos
definidos por las especificaciones de WS-Discovery
y WS-Eventing como medios para la búsqueda de un
dispositivo de red, la notificación de la participación de un
dispositivo de red en una red y el registro y la notificación de un
evento. Sin embargo, la presente invención no está limitada a esto.
Por ejemplo, es suficiente utilizar SSDP (Protocolo Simple de
Descubrimiento de Servicio) y GENA (Arquitectura General de
Notificación de Eventos) definidos por
UPnP(tm)v1.
Como protocolo de búsqueda para un dispositivo
de red, la presente invención puede utilizar cualquier protocolo
que pueda obtener una dirección para la adquisición de la
información de los atributos de un dispositivo de red y controlar
el destino de transmisión de la información para controlar el
dispositivo de red.
Como medios de registro/notificación de eventos,
la presente invención puede utilizar cualquier protocolo que pueda
emitir una solicitud de notificación de eventos y notificar un
destino de transmisión de eventos a través de una red, y además
pueda transmitir un evento ocurrido a una fuente de solicitud que
haya emitido una solicitud de notificación de eventos.
La primera realización y el ejemplo ilustrativo
han ejemplificado la impresora como un dispositivo de red. Sin
embargo, un dispositivo de red puede ser un equipo de oficina tal
como una máquina fotocopiadora, un escáner, un dispositivo de
almacenamiento, o un aparato electrodoméstico tal como un televisor,
un refrigerador o un aire acondicionado siempre y cuando sea un
dispositivo que pueda ser utilizado y controlado a través de un
canal de comunicaciones.
Las funciones de procesamiento respectivas en el
dispositivo (100) cliente y en el dispositivo (200) de red según
las realizaciones anteriormente descritas se implementan mediante la
lectura de programas para la implementación de las respectivas
funciones de procesamiento y causando que la CPU (Unidad Central de
Procesamiento) las ejecute. Sin embargo, la presente invención no
está limitada a esto, y todas o algunas de las funciones de
procesamiento pueden estar implementadas mediante hardware dedicado.
Además, la memoria anterior puede ser una memoria no volátil tal
como un disco magnetoóptico, un medio de almacenamiento legible tal
como un CD-ROM, una memoria volátil diferente a una
RAM, o medios de almacenamiento que permitan lectura/escritura por
ordenador que comprendan una combinación de éstos.
Es posible almacenar, en un medio de
almacenamiento legible por ordenador, programas para implementar las
funciones respectivas en el dispositivo (100) cliente y el
dispositivo (200) de red, y realizar los procesos respectivos
haciendo que el sistema de ordenador lea y ejecute los programas. Se
debe observar que el "sistema de ordenador" en este caso
incluye un OS (Sistema Operativo) y hardware, tales como los
dispositivos periféricos. Más específicamente, los programas leídos
del medio de almacenamiento están escritos en la memoria de una
tarjeta de expansión de funciones insertada en el ordenador o una
unidad de expansión de funciones conectada al ordenador.
Posteriormente, la CPU de la tarjeta de expansión de funciones o
unidad de expansión de funciones realiza parte o todo el
procesamiento actual en base a las instrucciones de los programas,
implementado así las funciones de las realizaciones anteriores.
Además, el "medio de almacenamiento legible
por ordenador" es un medio portátil tal como un disco flexible,
un disco magnetoóptico, una ROM, o un CD-ROM o un
dispositivo de almacenamiento tal como un disco duro integrado al
sistema de ordenador. Además, el "medio de almacenamiento legible
por ordenador" es un medio que mantiene programas por un periodo
predeterminado de tiempo, por ejemplo, un servidor al que se
transmiten los programas a través de una red tal como Internet, o
una línea de comunicación tal como una telefónica, o una memoria
volátil (RAM) en un sistema de ordenador que funcione como
cliente.
Es posible transmitir los programas anteriores
desde el sistema de ordenador que almacena los programas en un
dispositivo de almacenamiento o similar a otro sistema de ordenador
a través de un medio de transmisión u ondas portadoras en el medio
de transmisión. En este caso, el "medio de transmisión" es un
medio que tiene una función para transmitir información, por
ejemplo, una red tal como Internet o una línea de comunicación tal
como una línea telefónica.
Cada uno de los programas anteriores puede ser
uno que implemente una parte correspondiente a una de las funciones
anteriormente descritas o puede ser uno que implemente la función en
combinación con un programa que ya haya sido grabado en el
ordenador, es decir, un archivo diferencial (programa
diferencial).
Además, un producto de programa tal como un
medio de almacenamiento legible por ordenador, que almacena los
programas anteriores puede ser aplicado como una realización de la
presente invención. El alcance de la presente invención incorpora
los programas anteriores, medios de almacenamiento, medios de
transmisión y un producto de programa.
Aunque las realizaciones de la presente
invención han sido anteriormente descritas en detalle, las
disposiciones específicas de la presente invención no se limitan a
las realizaciones.
Mientras la presente invención ha sido descrita
en referencia a realizaciones a título de ejemplo, se debe entender
que la invención no está limitada a las realizaciones a título de
ejemplo descritas. El alcance de las siguientes reivindicaciones
debe interpretarse de la manera más amplia para así abarcar todas
las modificaciones y estructuras y funciones equivalentes.
Claims (17)
-
\global\parskip0.950000\baselineskip
1. Sistema de comunicaciones que comprende un aparato (100) cliente y un aparato (200) proveedor de servicios que proporciona un servicio al aparato cliente a través de un canal (300) de comunicaciones, dicho aparato cliente comprendiendo:- medios (5) de solicitud de notificación configurados para emitir una solicitud de notificación para solicitar al aparato proveedor de servicios que notifique de la ocurrencia de un evento;
- medios (5) de procesamiento de eventos configurados para procesar un evento que ocurre en el aparato proveedor de servicios,
- medios (5) de determinación configurados para determinar un estado de dichos medios de procesamiento de eventos y
- unos primeros medios de notificación configurados para notificar, después de que dichos medios de solicitud de notificación emitan la solicitud de notificación, al aparato proveedor de servicios si dichos medios de procesamiento de eventos están activos o no, en base a un resultado de determinación desde dichos medios de determinación, y dicho aparato proveedor de servicios incluye o comprende:
- medios (12) de detección configurados para detectar la ocurrencia de un evento y
- unos segundos medios de notificación configurados para notificar a un aparato cliente en el cual dichos medios de procesamiento de eventos están activos la ocurrencia del evento, en base a una notificación desde dichos primeros medios de notificación, si dichos medios de detección detectan la ocurrencia del evento.
- 2. Sistema, según la reivindicación 1, en el que el aparato proveedor de servicios incluye medios para gestionar una o mas de a) información de identificación de un aparato cliente que ha emitido una solicitud de notificación de eventos, b) una dirección del aparato cliente e c) información que representa un estado de dichos medios de procesamiento de eventos del aparato cliente.
- 3. Sistema, según la reivindicación 1, en el que dichos segundos medios de notificación notifican la ocurrencia del evento a un aparato cliente donde dichos medios de solicitud de notificación han emitido la solicitud de notificación y dichos primeros medios de notificación han notificado al aparato proveedor de servicios que dichos medios de procesamiento de eventos están activos, y dichos segundos medios de notificación no notifican la ocurrencia del evento a un aparato cliente en el que dichos medios de solicitud de notificación han emitido una solicitud de notificación y dichos primeros medios de notificación no han notificado al aparato proveedor de servicios que dichos medios de procesamiento de eventos están activos.
- 4. Sistema, según cualquiera de las reivindicaciones 1 a 3, en el que dichos primeros medios de notificación notifican al aparato proveedor de servicios que dichos medios de procesamiento de eventos están activos si por lo menos uno de los medios de procesamiento de eventos para el procesamiento de un evento ocurrido en el aparato de procesamiento de servicios está activo.
- 5. Sistema, según cualquiera de las reivindicaciones 1 a 3, en el que dichos primeros medios de notificación notifican al aparato proveedor de servicios que dichos medios de procesamiento de eventos están activos en caso de que al menos uno de los medios de procesamiento de eventos se encuentre en estado activo.
- 6. Sistema, según cualquiera de las reivindicaciones 1 a 3, en el que dichos primeros medios de notificación notifican al aparato proveedor de servicios que dichos medios de procesamiento de eventos están inactivos, en caso de que el número de dichos medios de procesamiento de eventos que están activos sea 0.
- 7. Aparato (100) de comunicación que se conecta a un aparato proveedor de servicios para proporcionar un servicio a través de un canal de comunicación, para recibir un servicio desde un aparato proveedor de servicios, el aparato de comunicación comprendiendo:
- medios (5) de solicitud de notificación configurados para emitir una solicitud de notificación para solicitar al aparato proveedor de servicios que notifique la ocurrencia de un evento;
- medios de procesamiento de eventos configurados para procesar la ocurrencia de un evento en el aparato proveedor de servicios;
- medios de determinación configurados para determinar un estado de dichos medios de procesamiento de eventos; y unos primeros medios de notificación configurados para notificar, después de que dichos medios de solicitud de notificación emitan la solicitud de notificación, al aparato proveedor de servicios si dichos medios de procesamiento de eventos están activos o no, en base a un resultado de determinación de dichos medios de determinación.
\global\parskip1.000000\baselineskip
- 8. Aparato (200) de comunicación que se conecta a un aparato (100) cliente a través de un canal (300) de comunicación, y proporciona un servicio al aparato cliente, el aparato de comunicación comprendiendo:
- unos primeros medios de recepción configurados para recibir, desde un aparato cliente, una solicitud de notificación para solicitar al aparato de comunicación que notifique la ocurrencia de un evento;
- unos segundos medios de recepción configurados para recibir, desde un aparato cliente, información que represente si se encuentran activos o no medios de procesamiento de eventos del aparato cliente, después de que dichos primeros medios de recepción reciban la solicitud de notificación;
- medios de detección configurados para detectar la ocurrencia de un evento; y
- medios de notificación para, en caso de que dichos medios de detección detecten la ocurrencia de un evento, notificar a un aparato cliente en el cual dichos medios de procesamiento de eventos estén activos, la ocurrencia del evento, en base a información recibida mediante dichos segundos medios de recepción.
- 9. Aparato, según la reivindicación 8, en el que dichos medios de notificación notifican al aparato cliente del cual dichos primeros medios de recepción han recibido la solicitud de notificación y del cual dichos segundos medios de recepción han recibido información indicando que dichos medios de procesamiento de eventos del aparato cliente están activos, de la ocurrencia del evento, pero dichos medios de notificación no notifican a un aparato cliente del cual dichos primeros medios de recepción han recibido la solicitud de notificación pero del cual dichos segundos medios de recepción no han recibido la información indicando que dichos medios de procesamiento de eventos del aparato cliente están activos, de la ocurrencia del evento.
- 10. Procedimiento de control de un sistema de comunicaciones que comprende un aparato (100) cliente y un aparato (200) proveedor de servicios que proporciona un servicio al aparato cliente a través de un canal (300) de comunicación, el procedimiento comprendiendo las siguientes etapas:
- el aparato cliente emite una solicitud de notificación solicitando al aparato proveedor de servicios que notifique la ocurrencia de un evento;
- determinar un estado de unos medios de procesamiento de eventos del aparato cliente, en el que los medios de procesamiento de eventos procesan una ocurrencia de un evento en el aparato proveedor de servicios;
- notificar, después de que se haya emitido la solicitud de notificación, al aparato proveedor de servicios si los medios de procesamiento de eventos del aparato cliente están activos o no, en base al resultado de dicha etapa de determinación;
- detectar la ocurrencia de un evento en el aparato proveedor de servicios; y notificar a través del aparato proveedor de servicios, a un aparato cliente en el que los medios de procesamiento de eventos del evento estén activos, en base a una notificación del aparato cliente, si se detecta la ocurrencia del evento en dicha etapa de detección.
- 11. Procedimiento, según la reivindicación 10, en el que el aparato proveedor de servicios notifica la ocurrencia del evento a un aparato cliente que ha notificado al aparato proveedor de servicios que los medios de procesamiento de eventos están activos, y no notifica la ocurrencia del evento a un aparato cliente que no ha notificado al aparato proveedor de servicios que los medios de procesamiento de eventos están activos.
- 12. Procedimiento, según cualquiera de las reivindicaciones 10 a 11, en el que el aparato cliente notifica al aparato proveedor de servicios que los medios de procesamiento de eventos están activos, si se encuentra activo al menos uno de los medios de procesamiento de eventos para procesar un evento ocurrido en el aparato proveedor de servicios.
- 13. Procedimiento, según cualquiera de las reivindicaciones 10 a 11, en el que el aparato cliente notifica al aparato proveedor de servicios que los medios de procesamiento de eventos están activos, si por lo menos uno de los medios de procesamiento de eventos se encuentra en estado activo.
- 14. Procedimiento, según cualquiera de las reivindicaciones 10 a 11, en el que el aparato cliente notifica al aparato proveedor de servicios que los medios de procesamiento de eventos están inactivos, si el número de medios de procesamiento de eventos del aparato cliente que están activos es 0.
- 15. Procedimiento de control de un aparato de comunicación que se conecta a un aparato proveedor de servicios para proporcionar un servicio a través de un canal de comunicación, para recibir un servicio del aparato proveedor de servicios, el procedimiento comprendiendo las etapas de:
- emitir una solicitud de notificación para solicitar al aparato proveedor de servicios que notifique la ocurrencia de un evento;
- determinar un estado de unos medios de procesamiento de eventos para procesar un evento que ocurre en el aparato proveedor de servicios; y
- notificar, después de que se haya emitido la solicitud de notificación, al aparato proveedor de servicios si los medios de procesamiento de eventos están activos o no, en base a un resultado de determinación dicha etapa de determinación.
- 16. Procedimiento de control de un aparato (200) de comunicación que se conecta a un aparato (100) cliente a través de un canal de comunicación, y proporciona un servicio a un aparato cliente, comprendiendo el procedimiento las etapas de:
- recibir, de un aparato cliente, una solicitud de notificación para solicitar al aparato de comunicación que notifique la ocurrencia de un evento;
- recibir, de un aparato cliente, información que represente si unos medios de procesamiento de eventos del aparato cliente están activos o no, después de recibir la solicitud de notificación;
- detectar la ocurrencia de un evento; y
- notificar un aparato cliente en el que un medio de procesamiento de eventos está activo, en base a la información recibida en dicha etapa de recepción, si se detecta la ocurrencia del evento en dicha etapa de detección.
- 17. Procedimiento, según la reivindicación 16, que comprende, además, una etapa de recepción de una solicitud de notificación de la ocurrencia de un evento de un aparato cliente,
- en el que en dicha etapa de notificación, el aparato de comunicación notifica a un aparato cliente la ocurrencia del evento, en caso de que el aparato cliente haya emitido la solicitud de notificación y la información indicando que los medios de procesamiento de eventos del aparato cliente están activos, y
- el aparato de comunicación no notifica al aparato cliente la ocurrencia del evento, en el caso de que el aparato cliente haya emitido la solicitud de notificación pero no haya emitido la información indicando que los medios de procesamiento de eventos del aparato cliente están activos.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006238173A JP5159071B2 (ja) | 2006-09-01 | 2006-09-01 | 通信システム及び通信装置とその制御方法 |
| JP2006-238173 | 2006-09-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2335238T3 true ES2335238T3 (es) | 2010-03-23 |
Family
ID=38922772
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07115468T Active ES2335238T3 (es) | 2006-09-01 | 2007-08-31 | Sistema de comunicacion y aparato de comunicacion y su procedimiento de control. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8935708B2 (es) |
| EP (1) | EP1895401B1 (es) |
| JP (1) | JP5159071B2 (es) |
| KR (1) | KR100975162B1 (es) |
| CN (1) | CN101136941B (es) |
| DE (1) | DE602007003644D1 (es) |
| ES (1) | ES2335238T3 (es) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8589866B2 (en) * | 2007-08-29 | 2013-11-19 | Ricoh Company, Ltd. | Automatically generating capability-based computer peripheral device drivers |
| US20090190150A1 (en) * | 2008-01-24 | 2009-07-30 | Selvaraj Senthil K | On-Demand Print Driver |
| US8271703B2 (en) * | 2008-10-17 | 2012-09-18 | Ricoh Company, Ltd. | Providing device defined user interface modifiers to a computer system |
| US8427675B2 (en) * | 2009-01-27 | 2013-04-23 | Ricoh Company, Ltd. | Automatically updating a printer driver with new printing device features |
| US8526020B2 (en) * | 2009-03-06 | 2013-09-03 | Ricoh Company, Ltd. | Paper size support for a print system |
| US8773687B2 (en) | 2009-03-06 | 2014-07-08 | Ricoh Company, Ltd. | Driverless architecture for printing systems |
| US8520225B2 (en) * | 2009-03-06 | 2013-08-27 | Ricoh Company, Ltd. | Print driver localization support from printing device to support multiple user profiles |
| US20100225958A1 (en) * | 2009-03-06 | 2010-09-09 | Selvaraj Senthil K | Approach For Printing To Web Services-Enabled Printing Devices |
| JP5537160B2 (ja) | 2010-01-05 | 2014-07-02 | キヤノン株式会社 | イベント代行通知装置及びその制御方法とそのプログラム |
| KR20120139574A (ko) * | 2011-06-17 | 2012-12-27 | 삼성전자주식회사 | ＵＰｎＰ 기반 디바이스 간 데이터 교환 장치 및 방법 |
| KR101334718B1 (ko) * | 2011-11-29 | 2013-11-29 | 한국과학기술정보연구원 | 이벤트 기반 서비스 제공 시스템 및 방법 |
| JP5378554B2 (ja) * | 2012-01-30 | 2013-12-25 | 京セラドキュメントソリューションズ株式会社 | ネットワークにおけるイベント通知システム |
| KR102138027B1 (ko) * | 2014-02-05 | 2020-07-27 | 애플 인크. | 제어기와 액세서리 사이의 통신을 위한 균일한 통신 프로토콜 |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0962524A (ja) * | 1995-08-18 | 1997-03-07 | Internatl Business Mach Corp <Ibm> | 分散演算環境におけるイベント管理方法及びシステム |
| US6734985B1 (en) * | 1998-08-25 | 2004-05-11 | Canon Kabushiki Kaisha | Printing apparatus, printing system and method of controlling same |
| US6859829B1 (en) * | 1999-02-23 | 2005-02-22 | Microsoft Corp. | Method and mechanism for providing computer programs with computer system events |
| JP3963057B2 (ja) * | 1999-07-29 | 2007-08-22 | カシオ電子工業株式会社 | プリンタシステム |
| US6751657B1 (en) * | 1999-12-21 | 2004-06-15 | Worldcom, Inc. | System and method for notification subscription filtering based on user role |
| US7594267B2 (en) * | 2001-06-14 | 2009-09-22 | Cisco Technology, Inc. | Stateful distributed event processing and adaptive security |
| US7207008B1 (en) * | 2001-09-12 | 2007-04-17 | Bellsouth Intellectual Property Corp. | Method, system, apparatus, and computer-readable medium for interactive notification of events |
| US7386859B2 (en) * | 2002-05-28 | 2008-06-10 | Microsoft Corporation | Method and system for effective management of client and server processes |
| US9886309B2 (en) | 2002-06-28 | 2018-02-06 | Microsoft Technology Licensing, Llc | Identity-based distributed computing for device resources |
| US7356540B2 (en) * | 2002-07-03 | 2008-04-08 | Smith David E A | Data storage and retrieval system |
| JP4040396B2 (ja) * | 2002-08-29 | 2008-01-30 | キヤノン株式会社 | 通知方法、情報処理装置及び制御プログラム |
| JP2004199382A (ja) * | 2002-12-18 | 2004-07-15 | Fuji Xerox Co Ltd | 通知源サーバ装置、クライアント装置、イベント通知制御方法 |
| US7418486B2 (en) | 2003-06-06 | 2008-08-26 | Microsoft Corporation | Automatic discovery and configuration of external network devices |
| US20060056285A1 (en) * | 2004-09-16 | 2006-03-16 | Krajewski John J Iii | Configuring redundancy in a supervisory process control system |
| US7633644B2 (en) * | 2004-10-08 | 2009-12-15 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device job management |
| US20060253593A1 (en) * | 2005-05-03 | 2006-11-09 | Jack Jachner | Communication system and method for determining next joint availability using presence information |
| US8194680B1 (en) * | 2009-03-11 | 2012-06-05 | Amazon Technologies, Inc. | Managing communications for modified computer networks |
| US9817695B2 (en) * | 2009-04-01 | 2017-11-14 | Vmware, Inc. | Method and system for migrating processes between virtual machines |
| US8533343B1 (en) * | 2011-01-13 | 2013-09-10 | Google Inc. | Virtual network pairs |
| JP5772395B2 (ja) * | 2011-08-29 | 2015-09-02 | 富士通株式会社 | 送信レート制御のためのプログラム、制御方法及び情報処理装置 |
-
2006
- 2006-09-01 JP JP2006238173A patent/JP5159071B2/ja not_active Expired - Fee Related
-
2007
- 2007-08-31 EP EP07115468A patent/EP1895401B1/en not_active Not-in-force
- 2007-08-31 CN CN200710147874XA patent/CN101136941B/zh not_active Expired - Fee Related
- 2007-08-31 KR KR1020070088660A patent/KR100975162B1/ko active IP Right Grant
- 2007-08-31 DE DE602007003644T patent/DE602007003644D1/de active Active
- 2007-08-31 US US11/848,681 patent/US8935708B2/en not_active Expired - Fee Related
- 2007-08-31 ES ES07115468T patent/ES2335238T3/es active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN101136941A (zh) | 2008-03-05 |
| EP1895401A1 (en) | 2008-03-05 |
| EP1895401B1 (en) | 2009-12-09 |
| KR100975162B1 (ko) | 2010-08-10 |
| JP5159071B2 (ja) | 2013-03-06 |
| DE602007003644D1 (de) | 2010-01-21 |
| JP2008059483A (ja) | 2008-03-13 |
| KR20080021561A (ko) | 2008-03-07 |
| US20080059978A1 (en) | 2008-03-06 |
| US8935708B2 (en) | 2015-01-13 |
| CN101136941B (zh) | 2011-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2335238T3 (es) | Sistema de comunicacion y aparato de comunicacion y su procedimiento de control. | |
| US8332538B2 (en) | Hierarchical application programming interface for communication middleware in partially connected mobile ad hoc networks | |
| US8060588B2 (en) | Home network apparatus and system for cooperative work service and method thereof | |
| EP1654831B1 (en) | System, method, and computer program product for centralized management of an infiniband distributed system area network | |
| RU2004117069A (ru) | Автоматическое обнаружение и конфигурирование внешних сетевых устройств | |
| EP2151095B1 (en) | Method and apparatus for discovering universal plug and play device using resource information | |
| JP2010282610A (ja) | ネットワークシステム及びその管理方法 | |
| JP4410608B2 (ja) | Ｗｅｂサービス提供方法 | |
| JP4799005B2 (ja) | 情報処理装置 | |
| US8291089B2 (en) | Image processing device, control method therefor, and program | |
| JP2007280114A (ja) | 情報処理装置及び情報処理方法 | |
| JP4970548B2 (ja) | ウェブサービス基盤の規則処理のためのデバイス及びその方法 | |
| US8725817B2 (en) | Service disclosure device, service disclosure method, and program | |
| Juszczyk et al. | A middleware for service-oriented communication in mobile disaster response environments | |
| JP2007293503A (ja) | デバイス、その制御方法、及びプログラム | |
| US20080139221A1 (en) | System for providing address using geocoding application programming interface in open service platform | |
| US10313254B1 (en) | Network management interface for a network element with network-wide information | |
| JP2013123126A (ja) | Ｄｌｎａ対応機器およびその探索方法 | |
| ES2594625T3 (es) | Descubrimiento y adición de servicios en un dispositivo multiservicio | |
| US20070198732A1 (en) | Object-oriented discovery framework | |
| US20040031033A1 (en) | Method and apparatus for inter-process communication management | |
| JP2003258901A (ja) | 管理装置、中継機器、通信システム、プログラム、及び管理方法 | |
| RU2746170C1 (ru) | Архитектура сетевого транслятора данных с автоматическим определением устройств с последовательным интерфейсом, поддерживающих выполнение ASCII команды идентификации | |
| JP2001216240A (ja) | ネットワークシステムおよびネットワークシステムのデバイス情報登録方法および記憶媒体 | |
| TWI467961B (zh) | 提供選擇家庭通信網路中的服務節點的方法及使用其的系統 |