ES2225536T3 - Dispositivo de supervision de terminales. - Google Patents
Dispositivo de supervision de terminales.Info
- Publication number
- ES2225536T3 ES2225536T3 ES01929771T ES01929771T ES2225536T3 ES 2225536 T3 ES2225536 T3 ES 2225536T3 ES 01929771 T ES01929771 T ES 01929771T ES 01929771 T ES01929771 T ES 01929771T ES 2225536 T3 ES2225536 T3 ES 2225536T3
- Authority
- ES
- Spain
- Prior art keywords
- stage
- page
- subscriber
- multiplexing
- access
- 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
- 238000004891 communication Methods 0.000 claims abstract description 18
- 238000012806 monitoring device Methods 0.000 claims abstract description 3
- 230000004927 fusion Effects 0.000 claims description 36
- 230000003993 interaction Effects 0.000 claims description 13
- 230000004044 response Effects 0.000 claims description 11
- 238000011282 treatment Methods 0.000 claims description 8
- 230000003068 static effect Effects 0.000 claims description 7
- 230000000875 corresponding effect Effects 0.000 description 19
- 230000006870 function Effects 0.000 description 14
- 230000011664 signaling Effects 0.000 description 8
- 230000000694 effects Effects 0.000 description 7
- 238000013519 translation Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000000034 method Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 102100024412 GTPase IMAP family member 4 Human genes 0.000 description 1
- 101000833375 Homo sapiens GTPase IMAP family member 4 Proteins 0.000 description 1
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 1
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000011900 installation process Methods 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Telephonic Communication Services (AREA)
- Alarm Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Arrangements For Transmission Of Measured Signals (AREA)
- Monitoring And Testing Of Exchanges (AREA)
- Selective Calling Equipment (AREA)
Abstract
Dispositivo de supervisión de terminales conectados a una red de comunicación (300) para proporcionar a los abonados que utilizan los terminales (100-103) diferentes servicios gestionados por varios servidores dedicados (200-204), comprendiendo el dispositivo (400) medios (440) de interfaz con la red, una etapa (430) de presentación de servicios a los terminales a través de los citados medios de interfaz, una etapa (420) de multiplexión de servicios en comunicación con la etapa de presentación, y una etapa (410) de acceso a los servicios en comunicación con la etapa de multiplexión y que comporta varios módulos de acceso (4100-4104), estando asociado cada uno de ellos a un servidor dedicado.
Description
Dispositivo de supervisión de terminales.
La presente invención hace referencia al campo de
las comunicaciones en empresas, y más en particular a los sistemas
de comunicaciones en empresas que ofrecen servicios diversificados,
por ejemplo de tipo multimedia.
El desarrollo de las telecomunicaciones en
empresas se ha llevado a cabo en torno a dos ejes: las redes de
telefonía de conmutación de circuitos y las redes informáticas de
conmutación de paquetes.
La arquitectura de las redes privadas de
telefonía se ha organizado tradicionalmente en torno a un sistema de
conmutación que comprende uno o varios autoconmutadores o PABX
("Private Automate Branch eXchange") conectados a un conjunto
de terminales telefónicos. El empleo de los servicios telefónicos se
realiza mediante informaciones de señalización intercambiadas entre
un servidor de llamada, formado por una o varias entidades del
sistema de conmutación, el o los PABX y los terminales telefónicos.
Para el establecimiento de tales intercambios, resulta necesaria
una familia de protocolos de comunicación que soporte en general
varios servicios de telefonía. Los protocolos RNIS ("Red Numérica
de Integración de Servicios") proporcionan un ejemplo tal de
familia de protocolos.
El desarrollo de nuevos servicios ha llevado a
integrar en los sistemas de conmutación servidores suplementarios
dedicados a estos nuevos servicios (por ejemplo, un servidor de
mensajes de voz, un servidor de guía telefónica, etc.). Los
protocolos de señalización concebidos inicialmente para funciones
de tratamiento de llamada, por ejemplo el protocolo H.323
normalizado por la Unión Internacional de Telecomunicaciones, han
evolucionado de manera natural hacia una integración de los nuevos
servicios.
Se han desarrollado otros protocolos de
señalización específicos para determinados servicios, como por
ejemplo los protocolos DAP ("Directory Access Protocol") y
LDAP ("Lightweight Directory Access Protocol") específicos
para los servicios de guía telefónica, los protocolos SMTP
("Simple Mail Transfer Protocol") e IMAP ("Internal Message
Access Protocol"), específicos para el correo, o el protocolo
HTTP ("Hypertext Transfer Protocol") específico para la
navegación Web, etc. Habitualmente, estos protocolos sólo se
utilizan para los servicios correspondientes en el interior de
redes informáticas de transmisión de datos. Su interacción con
protocolos de señalización de tipo telefonía precisa que servidores
de naturaleza diferente sean capaces de comunicarse entre sí, es
decir, que determinados servidores tengan al menos un conocimiento
de las "actividades" de los otros servidores. La consecuencia
es una gran complejidad de los protocolos, junto con una falta de
flexibilidad cuando se desea hacer evolucionar las funciones
ofrecidas.
Por otra parte, la utilización de servidores
múltiples dedicados a actividades diferentes lleva a menudo a los
abonados a dialogar sucesivamente con varios servidores para llevar
a cabo una función dada, lo que afecta a la eficacia y a la
ergonomía del sistema.
En el marco del servicio Web, se conoce el
proceso de tratar las peticiones del usuario interrogando a fuentes
de información heterogéneas, traducir las diferentes respuestas y
reagruparlas en una página de datos de un lenguaje de etiquetado
tal como el HTML ("Hypertext Markup Language") o el XML
("eXtended Markup Language"), que se devuelve al programa de
navegación Web del usuario. Esto puede realizarse mediante
arquitecturas de tres capas ("three-tier
architecture"), tal y como se describe en el artículo de C.
Petrou y otros, "An XML-based,
3-tier Scheme for Integrating Heterogeneous
Information Sources to the WWW", Proc. of the IEEE 10^{th}
International Workshop on Database and Expert Systems Applications,
1999, páginas 706-710. Ello permite tratar
individualmente las peticiones del usuario, pero no presentarle los
servicios diversificados a los que tiene acceso.
Un objetivo principal de la invención consiste en
hacer más flexibles las arquitecturas de las redes de comunicación
existentes, en el sentido de que permitan integrar fácilmente
nuevos servicios o modificar los servicios existentes, librándose
del carácter específico de las interfaces con los servidores de
diferentes actividades, aunque ofreciendo una gran riqueza
funcional a los abonados.
La invención propone asimismo un dispositivo de
supervisión de terminales conectados a una red de comunicación para
proporcionar a los abonados que utilizan los terminales diferentes
servicios gestionados por varios servidores dedicados,
comprendiendo el dispositivo medios de interfaz con la red, una
etapa de presentación de servicios a los terminales a través de los
citados medios de interfaz, una etapa de multiplexión de servicios
en comunicación con la etapa de presentación, y una etapa de acceso
a los servicios en comunicación con la etapa de multiplexión y que
comporta varios módulos de acceso, estando asociado cada uno de
ellos a un servidor dedicado respectivo. Cada módulo de acceso se
halla dispuesto para entregar páginas de datos etiquetados a la
etapa de multiplexión en respuesta a mensajes entrantes emitidos
por el servidor dedicado asociado y/o a peticiones de página
emitidas por la etapa de multiplexión, y para entregar los datos de
fusión a la etapa de multiplexión en respuesta a peticiones de
fusión, estando cada página entregada asociada a un abonado con el
cual la etapa de multiplexión tiene abierta una sesión de
comunicación a través de la etapa de presentación, conteniendo al
menos determinadas páginas de las entregadas a la etapa de
multiplexión códigos de fusión relacionados con los servicios. La
etapa de multiplexión comprende medios de tratamiento de cada
página recibida desde la etapa de acceso para detectar los códigos
de fusión, dirigir una petición de fusión al módulo de acceso
asociado al servidor dedicado que gestiona el servicio al que se
refiere cada código de fusión detectado, realizar la sustitución de
los datos de fusión entregados por el citado módulo de acceso en
respuesta a la petición de fusión en un campo de la página que
incluye el código de fusión detectado, y proporcionar la página
tratada a la etapa de presentación en el marco de la sesión en
curso con el abonado asociado. Cada página proporcionada a la etapa
de presentación contiene datos etiquetados que describen, de
acuerdo con un formato independiente de los terminales, elementos
de interacción con el abonado asociado. La etapa de presentación
comprende medios de control de terminales que interpretan cada
página recibida desde la etapa de multiplexión en el marco de una
sesión en curso con un abonado que utiliza uno de los terminales,
con el fin de generar órdenes adaptadas a la presentación en el
terminal de elementos de interacción descritos por los datos
etiquetados de la página. La etapa de multiplexión comprende además
medios de enrutamiento para recibir direcciones de página desde la
etapa de presentación en el marco de una sesión en curso con un
abonado, identificar un módulo de acceso al que está destinada la
dirección de la página recibida, y transmitir una petición de página
correspondiente al módulo de acceso identificado.
El dispositivo posee una arquitectura de tres
capas, y representa un papel de agente "proxy" frente a los
terminales para los diferentes servicios gestionados por los
servidores dedicados. Estos servicios son multiplexados por una
etapa central que mantiene sesiones con los abonados sin poseer un
conocimiento particular sobre los servicios gestionados por los
servidores dedicados ni sobre las características físicas de los
terminales.
La etapa de multiplexión combina elementos
dependientes de diferentes actividades dentro de los datos
proporcionados para la presentación de los servicios a los
abonados. Para ello, asocia simplemente códigos de fusión
determinados a módulos de acceso a los que dirige las peticiones que
permiten completar las páginas recibidas anteriormente. Son estos
módulos de acceso los que, de manera autónoma o conjuntamente con
servidores dedicados asociados, incorporan un conocimiento de las
actividades correspondientes para proporcionar los datos requeridos
por la etapa de multiplexión.
Por tanto, resulta relativamente fácil enriquecer
o hacer evolucionar el sistema. El añadido o la sustitución de
nuevos servidores dedicados funcionando según protocolos
específicos no implica una reconsideración de los protocolos
utilizados en otros lugares del sistema.
En una realización preferente del dispositivo,
los datos etiquetados contenidos en al menos determinadas páginas de
las proporcionadas a la etapa de presentación describen, además de
los elementos de interacción con el abonado asociado, como mínimo un
vínculo entre uno de los citados elementos de interacción y una
dirección de página. Los medios de control de terminales de la
etapa de presentación se disponen entonces para asociar cada vínculo
de una página recibida desde la etapa de multiplexión, en el marco
de una sesión en curso con un abonado que utiliza uno de los
terminales, con un evento que puede producirse en el nivel del
terminal, y para devolver la dirección de página del citado vínculo
a la etapa de multiplexión en el marco de la citada sesión en
respuesta a un suceso del citado evento.
Otras particularidades y ventajas de la presente
invención se harán evidentes en la posterior descripción de ejemplos
de realización no limitativos, en referencia a los dibujos
adjuntos, en los cuales:
- la figura 1 es un esquema que muestra un
ejemplo de red de telecomunicaciones que integra un dispositivo
según la invención;
- la figura 2 es un esquema general de un
dispositivo según la invención;
- la figura 3 es un esquema sinóptico de un
módulo de la etapa de acceso del dispositivo;
- la figura 4 es un esquema sinóptico de la etapa
de multiplexión del dispositivo;
- la figura 5 muestra un ejemplo de señal de
visualización que puede visualizarse en un terminal conectado a la
red.
En el ejemplo de realización descrito a
continuación, equipos terminales de diferentes tipos tienen acceso,
a través de una red de comunicación de empresa y de un dispositivo
según la invención, a servicios diversificados de telefonía, de
registro diario de llamadas, de guía telefónica, de mensajería
unificada (es decir, de voz y electrónica) y de navegación Web en
una red Internet o intranet, proporcionados por un conjunto de
servidores dedicados conectados a la red.
La figura 1 muestra los terminales de diferentes
tipos (por ejemplo, un puesto móvil (100), un microordenador (101),
un puesto RNIS (102) dotado de un adaptador IP, un puesto IP nativo
(103)) conectados a una red de comunicaciones (300) en modo de
paquetes que funciona según el protocolo IP ("Internet
Protocol"). La red (300) puede ser una red local (LAN, "Local
Area Network") de la que se provee una organización para
proporcionar servicios de transmisión de datos a los detentores de
los terminales (100) a (103). Por ejemplo, se halla constituida por
varias subredes Ethernet entre las que la conmutación de los
paquetes IP se lleva a cabo de manera clásica mediante enrutadores
no representados.
Por otro lado, hay varios servidores dedicados a
los servicios considerados conectados a la LAN (300): un servidor de
telefonía (200), un servidor de guía telefónica (201), un servidor
de mensajería unificada (202), un servidor de navegación Web (203),
así como un servidor de registro diario de llamadas (204).
Un dispositivo (400) según la invención
denominado "servidor proxy" se halla igualmente conectado a la
LAN (300). Este dispositivo cumple una función de proxy, es decir,
para acceder a los servicios gestionados por los servidores
dedicados (200) a (204) de la red (300), los terminales (100) a
(103) sólo pueden abrir una sesión con el dispositivo (400). Por
otra parte, la señalización entrante referente a estos servicios
sólo puede ser dirigida a los terminales a través del dispositivo
(400).
Por supuesto, es posible que determinados de los
servidores (200) a (204), (400) estén realizados en una plataforma
común. Por ejemplo, los servidores de telefonía (200) y de registro
diario (204) se encontrarán frecuentemente en el mismo equipo de la
red. El servidor proxy (400) podrá asimismo encontrarse en el mismo
equipo que uno de los servidores dedicados, por ejemplo el servidor
de telefonía (200).
El servidor proxy (400) presenta una arquitectura
de tres capas de la que la figura 2 muestra las tres etapas: etapa
de acceso a los servicios (410), etapa de multiplexión de servicios
(420) y etapa de presentación de servicios (430).
La etapa de acceso (410) (entidad de actividad)
agrupa el conjunto de los tratamientos específicos de los
diferentes servicios gestionados por los servidores dedicados (200)
a (204). También lleva a cabo la interfaz del servidor proxy (400)
con los diferentes servidores dedicados (200) a (204), e
intercambia datos procedentes de y dirigidos a la entidad de
servicio (420) de acuerdo con un formato unificado.
La etapa (410) comporta módulos de acceso (4100)
a (4104) asociados respectivamente a los servidores dedicados (200)
a (204) con los que son capaces de dialogar. Cada módulo de acceso
(4100) a (4104) lleva a cabo los tratamientos referentes a la
provisión de un servicio por parte del servidor dedicado asociado
(200) a (204) a los usuarios de la red que integra el servidor proxy
(400). Se encuentra así, en el ejemplo considerado, un módulo de
acceso (4100) asociado al servidor dedicado de telefonía (200), un
módulo de acceso (4101) asociado al servidor dedicado de guía
telefónica (201), un módulo de acceso (4102) asociado al servidor
dedicado de mensajería (202), un módulo de acceso (4103) asociado
al servidor dedicado de navegación (203) y un módulo de acceso
(4104) asociado al servidor dedicado de registro diario de llamadas
(204).
En un modo de realización de la invención, cada
módulo de acceso (4100) a (4104) gestiona una conexión a nivel de la
aplicación del modelo OSI con su servidor dedicado asociado (200) a
(204). La estructura de los datos intercambiados y el protocolo de
intercambio de estos datos dependen del servicio implicado (por
ejemplo, H.323 para la telefonía, LDAP para el servicio de guía
telefónica, IMAP4 para la mensajería electrónica, HTTP para la
navegación, etc.).
En otro modo de realización, una parte o la
totalidad de los servidores dedicados (200) a (204) dialogan
directamente con los módulos de acceso correspondientes (4100) a
(4104) de acuerdo con una conexión mediante un protocolo de la capa
de transporte, típicamente TCP ("Transmission Control
Protocol"), e intercambian páginas de datos etiquetados que
proporcionan descripciones semánticas de elementos de acuerdo con
el lenguaje XML ("eXtended Markup Language"). También pueden
utilizarse versiones de XML, cuyas descripciones de tipos de
documentos (DTD, "Document Type Description") se han
desarrollado para adaptarse a diferentes actividades, para los
intercambios entre el servidor proxy (400) y los servidores de las
actividades correspondientes.
La etapa de multiplexión (420) (entidad de
servicio) lleva a cabo la interacción entre los diferentes servicios
gestionados por los servidores dedicados (200) a (204), enruta las
peticiones procedentes de la etapa de presentación (430) hacia los
módulos de la etapa de acceso (410), y transmite a la etapa de
presentación los datos procedentes de la etapa de acceso (410). Por
otra parte, administra las sesiones abiertas con los diferentes
terminales gestionados por el servidor proxy (400). Los
tratamientos llevados a cabo por la etapa (420) no toman en
consideración ningún conocimiento de los servicios de los que
retransmite información, ni de las características de los terminales
conectados a la red (300).
La etapa de presentación (430) (entidad de
presentación) contiene el conjunto de los medios de conexión y de
diálogo con los diferentes tipos de terminales compatibles con el
servidor proxy (400), y cumple la función de presentación de los
datos recibidos desde la etapa de multiplexión (420) hacia el
terminal desde el cual el abonado destinatario de los datos ha
abierto una sesión con el servidor proxy (400). Según sus
características, los terminales (100) a (103) pueden estar
dispuestos para comunicar de acuerdo con diferentes tipos de
protocolos de comunicación. Para cada uno de estos protocolos, la
etapa de presentación (430) comprende un módulo de interfaz (431),
(432) que organiza la emisión y la recepción de los mensajes
correspondientes.
Los módulos de acceso (4100) a (4104) y los
módulos de interfaz de terminal (431), (432) de la etapa de
presentación se conectan a un módulo (440) de interfaz con la LAN
(300) que cumple las funciones de las capas 1 a 4 del modelo OSI.
En el ejemplo considerado, el módulo (440) gestiona los intercambios
del servidor proxy (400) de acuerdo con los protocolos TCP, IP y
Ethernet. Por supuesto, si el servidor proxy (400) se halla
incorporado en el mismo equipo que uno de los servidores dedicados
(200) a (204), el módulo de acceso correspondiente podrá dialogar
directamente con este servidor dedicado sin pasar por el módulo de
interfaz (440).
La etapa de acceso (410) genera páginas de datos
etiquetados, es decir, conjuntos de descripciones de elementos cuya
sintaxis es común al conjunto de los módulos de acceso (4100) a
(4104), y las transmite a la etapa de multiplexión. En un modo
preferente de realización de la invención, se utilizan páginas de
descripción de datos estructurados al estilo XML. En una variante,
podrían utilizarse objetos del tipo COM ("Component Object
Model") tales como los propuestos por la compañía Microsoft. El
interés de estas páginas reside en su flexibilidad de uso y en la
posibilidad de presentar datos en un formato que puede ser adaptado
a todo tipo de terminal mediante una simple operación de
filtrado.
Las páginas XML entregadas por la etapa de acceso
(410) son objeto de un tratamiento en la etapa de multiplexión
(420), que se describirá más adelante, antes de ser transmitidas a
la etapa de presentación (430). Las páginas XML tratadas
transmitidas a la etapa de presentación (430) contienen datos
etiquetados que describen, en un formato independiente de los
terminales, elementos de interacción con los abonados. Determinados
de estos elementos de interacción deben presentarse de manera
dinámica al abonado implicado en la página, definiéndose el modo de
presentación en la etapa (430) en función del tipo de interfaz
hombre-máquina de que está provisto el terminal
utilizado (visualización en pantalla de un determinado tipo o un
tamaño, señalización sonora, mensajes de voz, etc.), y
eventualmente en función de parámetros de configuración de la
interfaz hombre-máquina definidos por el
abonado.
Estos elementos presentes de manera dinámica
pueden representar un contexto de abonado (por ejemplo, llamada
entrante, puesto ocupado, mensaje recibido, etc.), información
proporcionada en el marco de un servicio (por ejemplo, número de
guía telefónica, contenido de un mensaje, página Web, etc.), campos
de entrada que permiten al abonado introducir información útil para
los servidores (por ejemplo, número de llamada, identificación de
la ficha de la guía telefónica, mensaje a emitir, etc.), o acciones
que el abonado puede seleccionar con la ayuda de un evento
programable en la etapa de presentación (accionamiento de una tecla
virtual, orden de voz, etc.). Para este último tipo de elemento,
los datos etiquetados de la página XML corresponden a un vínculo
dinámico que apunta a una dirección de página.
Otros elementos de interacción descritos en las
páginas XML transmitidas a la etapa de presentación (430) pueden
estar relacionados con determinados eventos susceptibles de
producirse en el nivel de los terminales y definidos de manera
estática, es decir, independientemente del contexto de abonado y de
los elementos dinámicos presentes. Estos eventos, definidos en el
nivel de la etapa de presentación (430), comprenden por ejemplo el
accionamiento por el abonado de una tecla especial, la finalización
de una temporización, etc. Los datos etiquetados de la página XML
que describen este tipo de elemento corresponden a un vínculo
estático que apunta a una dirección de página.
En los vínculos anteriormente citados, es posible
utilizar direcciones de páginas similares a las direcciones URL
("Uniform Resource Locator") habitualmente empleadas en las
aplicaciones de navegación, por ejemplo de la forma
"process_id://page_id", donde el campo "process_id"
designa un proceso relevante de un módulo de acceso (4100) a
(4104), y el campo "page_id" designa una página gestionada por
el citado proceso. Determinadas direcciones se completan con uno o
varios campos de parámetros útiles para la generación de la página
designada, pudiendo proporcionarse explícitamente los parámetros
correspondientes en la página XML transmitida a la etapa de
presentación (430) o bien recuperarse en campos de entrada
descritos en esta página XML.
La figura 2 muestra que la etapa de presentación
(430) comporta un navegador XML (433) que analiza las páginas
recibidas desde la etapa de multiplexión (420) en unión con una
memoria (434) que contiene la DTD que define la sintaxis común de
estas páginas. El navegador (433) extrae los elementos dinámicos de
cada página recibida por un abonado y los proporciona al módulo
(435), (436), (437) de control de la interfaz
hombre-máquina del terminal utilizado por el
abonado. Están previstos varios módulos de control (435) a (437) en
la etapa (430) para tomar en consideración los diferentes tipos de
IHM con los que pueden estar equipados los terminales. Estos
módulos (435) a (437) generan las órdenes apropiadas para la
presentación de los elementos requeridos en los terminales, órdenes
que se entregan a través de los módulos de interfaz (431), (432) y
(440). Los módulos de control (435) a (437) supervisan además el
suceso de eventos correspondientes a los vínculos de acción
definidos en la página XML, y avisan al navegador (433) de la
detección de dicho evento. En respuesta a la detección de dicho
evento, el navegador (433) devuelve a la etapa de multiplexión, en
el marco de la sesión en curso con el abonado implicado, una
primitiva GET_URL que incluye la dirección de página del vínculo
correspondiente.
La figura 3 muestra esquemáticamente los
componentes de un módulo (410x) de la etapa (410) de acceso a los
servicios del servidor proxy (400). Una unidad de traducción (411)
lleva a cabo la interfaz con el servidor dedicado (20x)
correspondiente al módulo de acceso considerado (410x). La unidad
(411) gestiona específicamente el conjunto del diálogo con el
servidor dedicado, y transcribe los datos recibidos desde el
servidor en un formato uniforme correspondiente a las páginas
intercambiadas en el interior del servidor proxy (400). Para ello,
dispone de una tabla de traducción (412) que le permite asociar a
los datos intercambiados, según un formato específico con el
servidor dedicado, etiquetas ("tags") comunes al conjunto de
los módulos del servidor proxy (400). Una vez traducidos, los datos
recibidos son transmitidos a una unidad de construcción de páginas
dinámicas (413) o a otra unidad (414) del módulo (410x) denominada
servidor de datos de fusión.
La unidad de construcción de páginas dinámicas
(413) organiza los datos etiquetados dentro de una página XML de
acuerdo con la estructura común definida en la DTD (415). La página
constituida de este modo se transmite a una unidad (416) denominada
servidor de páginas, que la asocia a informaciones que identifican
al abonado para el que ha sido construida.
Dos tipos de mensaje pueden desencadenar el envío
de una página XML desde el módulo de acceso (410x) a la etapa de
multiplexión:
- un mensaje procedente del servidor asociado
(20x) con destino un abonado identificado. En este caso, la unidad
(413) construye la página a emitir a partir de elementos contenidos
en el mensaje de señalización entrante, de conformidad con la
estructura común definida en la DTD (415),
- una petición de página recibida desde la etapa
de multiplexión por un abonado identificado. Al recibir una
petición de página, el servidor de paginas (416) determina en
primer lugar si la página solicitada es una página estática
contenida en la biblioteca de páginas (417). Si éste es el caso, no
es necesario interrogar al servidor dedicado: el servidor de
páginas (416) construye la página a partir de la pagina estática
memorizada y de eventuales parámetros proporcionados junto con la
petición, y a continuación dirige la página así obtenida hacia la
etapa de multiplexión (420) indicando el abonado implicado. Si no,
la página es construida por la unidad (413), que interroga al
servidor dedicado (20x) a través de la unidad de traducción (411)
cuando se precisan datos exteriores para construir la página. La
unidad (413) puede igualmente extraer peticiones de página y/o de
datos de la página en construcción, eventos o parámetros que se
transmiten a la unidad de traducción (411) para hacer que la
señalización vuelva al servidor dedicado (20x).
Por otra parte, el módulo de acceso (410x) puede
recibir de la etapa de multiplexión (420) peticiones de fusión que
son tratadas por el servidor de datos de fusión (414). Una petición
de fusión comprende un código de fusión asociado a un tipo de datos
de fusión, y eventualmente parámetros asociados. Los servidores
(416) y (414) tienen funcionamientos similares, si bien el servidor
(414) manipula datos de fusión que no se encuentran en general
organizados en forma de páginas. Al recibir una petición de fusión,
el servidor (414) determina en primer lugar si los datos
solicitados son datos estáticos contenidos en la biblioteca (418).
Si éste es el caso, no es necesario interrogar al servidor
dedicado: el servidor (414) recupera los datos de fusión de la
biblioteca (416), los completa con los eventuales parámetros
proporcionados con la petición, y luego los devuelve a la etapa de
multiplexión (420) indicando el abonado implicado. Si no, el
servidor de datos de fusión (414) interroga al servidor dedicado
(20x) a través de la unidad de traducción (411), indicando los
eventuales parámetros proporcionados con la petición, para obtener
los datos exteriores requeridos y devolver los datos de fusión
resultantes a la etapa de multiplexión (420).
Los códigos de fusión se hallan presentes en
determinadas páginas de las devueltas por los servidores de páginas
(416) de los módulos de acceso (4100) a (4104). Vienen generalmente
acompañados de parámetros que permiten elaborar los datos de
fusión. A fin de facilitar su identificación en las páginas XML,
pueden comprender una etiqueta especial y un nombre de función que
permita identificar un puerto lógico de la etapa de acceso (410)
para el enrutamiento de la petición de fusión correspondiente (este
nombre se asocia a uno de los módulos de acceso (4100) a (4104) y a
un puerto lógico de éste al que debe enviarse la petición de fusión
correspondiente). Su sintaxis es, por ejemplo, la siguiente:
"función (para1, ..., paraN)", donde "%" es la etiqueta
característica de los códigos de fusión, "función" es el nombre
de la función, y para1, ..., paraN designan los N parámetros
asociados (N \geq 0). Algunos de estos parámetros asociados
pueden ser ellos mismos códigos de fusión, permitiendo los
paréntesis separar los códigos de fusión de acuerdo con una
estructura en árbol.
La figura 4 muestra esquemáticamente los
componentes de la etapa de multiplexión de servicios (420) del
servidor proxy (400). Cada página recibida desde la etapa de acceso
(410) es analizada por un motor de análisis y de fusión (421). La
operación de fusión consiste en remplazar los códigos de fusión,
presentes en asociación con eventuales parámetros en una página
recibida desde un módulo de acceso (4100) a (4104), por datos de
fusión que consisten en datos etiquetados o un vínculo.
Esta operación de fusión no precisa ningún
conocimiento de la organización de los servicios tratados en el
nivel de la etapa de multiplexión (420). Los códigos de fusión
pueden ser identificados sin llevar a cabo un análisis detallado
("parsing"), detectando simplemente las etiquetas "%"
eventualmente presentes en la página recibida. Cuando el motor de
análisis (421) identifica de este modo un código de fusión,
consulta una tabla de correspondencia (422) sobre la base de un
nombre de función de dicho código, lo que le permite identificar el
puerto lógico de la etapa de acceso (410) al que direccionar la
petición de fusión. Éste puede ser formulado de manera muy simple
volviendo a copiar el código de fusión con sus parámetros e
identificando el abonado implicado. Al recibir los datos de fusión
devueltos a este abonado por el servidor de datos de fusión (414)
del módulo de acceso interrogado, el motor de análisis y de fusión
(421) hace que sustituyan al código de fusión anteriormente
identificado.
Las correspondencias (nombre de función del
código de fusión, puerto lógico de la etapa de acceso) se introducen
en la tabla (422) durante un proceso de instalación de los módulos
de acceso (4100) a (4104), en el curso del cual éstos declaran a la
etapa de multiplexión (420) los nombres de función de los códigos
de fusión tratados por sus servidores de datos de fusión respectivos
(414) indicando los puertos lógicos asociados. Si un código de
fusión detectado no figura en la tabla de correspondencia (422), el
motor de análisis y de fusión (421) simplemente suprime este código
de la página XML tratada.
A lo largo del mismo procediendo de instalación,
los módulos de acceso (4100) a (4104) declaran en la etapa de
multiplexión (420) las identidades "process_id" de los
procesos tenidos en cuenta por sus servidores de páginas
respectivos (416), indicando los puertos lógicos asociados. Esto
permite, en la etapa de multiplexión (420), registrar las
correspondencias entre dichas identidades "process_id" y
dichos puertos lógicos en otra tabla (423).
La etapa de multiplexión (420) comporta un módulo
de enrutamiento (424) que recibe las direcciones de páginas
recibidas desde la etapa de presentación (430) con los primitivos
GET_URL tras los eventos detectados en el nivel de los terminales.
El módulo de enrutamiento (424) consulta la tabla de
correspondencia (423) sobre la base de las identidades
"process_id" contenidas en estas direcciones para determinar
el puerto lógico de la etapa de acceso (410) al que debe
direccionarse la petición de página, y transmite esta petición
acompañada de los parámetros correspondientes.
Cada creación de una asociación de un par
(terminal físico, abonado) por la etapa de presentación (430) da
lugar a una petición de apertura de sesión de abonado recibida por
un módulo de gestión de abonados (425) de la etapa de multiplexión
(420) (primitiva OPEN_SESSION). Este módulo (425) funciona con una
tabla (426) de registro de abonados para los que hay una sesión
abierta. La petición de apertura de sesión de abonado contiene
informaciones que indican, entre otras cosas, un identificador de
abonado (por ejemplo, su número de llamada telefónica) y un puerto
lógico de la etapa de presentación para el envío de páginas
destinadas al abonado. Además, contiene información relativa a la
autentificación del abonado, tal como, por ejemplo, una contraseña
escogida por éste último. El módulo (425) consulta la tabla (426)
con el fin de asegurarse de que el abonado no se encuentra ya
registrado, en cuyo caso devuelve un acuse de recibo negativo NACK
que se transmite a la etapa de presentación (430). En caso
contrario, crea un registro en la tabla (426) que incluye la
información contenida en la petición de apertura de sesión, y a
continuación envía un acuse de recibo positivo ACK destinado a la
etapa de presentación y al terminal. También hay previsto un
mecanismo de supresión de un registro, por ejemplo, en el caso de
una disolución de un par (terminal, abonado) que da lugar al envío
por parte de la etapa de presentación de una petición de cierre de
sesión de abonado destinada al módulo (425) (primitiva
CLOSE_SESSION).
La recepción de un acuse de recibo positivo ACK
en la etapa de presentación (430) desencadena una petición de página
de inicio predeterminada hacia la etapa de multiplexión (420). Esta
petición puede ser formulada en forma de dirección de la página
solicitada acompañada de parámetros correspondientes al abonado
(número de abonado, contraseña) y de parámetros de direccionamiento
de su terminal en la LAN para el direccionamiento de la voz y de los
datos (parámetros de red tales como la dirección IP, los puertos
UDP, etc.), y puede ser retransmitida como las otras direcciones de
página por el módulo de enrutamiento (424) hacia la etapa de acceso
(410).
Esta página de inicio predeterminada puede ser
generada específicamente por el módulo de acceso (4100) asociado al
servidor de telefonía (200). Puede describir una señal fija de
inicio que ofrece, por ejemplo, los diferentes servicios ofrecidos
por los servidores dedicados conectados (200) a (204), precisando
al abonado su contexto telefónico actual. La información (vínculos)
relativa a los servicios disponibles contiene específicamente
direcciones de páginas destinadas a ser transmitidas por los módulos
de acceso (4100) a (4104) bajo una petición del servicio. De este
modo, cuando el abonado selecciona, por ejemplo, el servicio de
telefonía, la etapa de presentación (430) transmite a la etapa de
multiplexión (420), en el marco de la sesión abierta con el
abonado, la dirección de página contenida en el vínculo
seleccionado. Conociendo esta sesión, el módulo de gestión de los
abonados (425) puede dar instrucciones al módulo de enrutamiento
(424) para que la petición de página sea transmitida al módulo de
acceso (4100) indicando la identidad del abonado, habiendo obtenido
el puerto lógico en la tabla (423).
Los módulos de gestión de abonados (425) y de
enrutamiento (424) intervienen de la misma manera para las
diferentes peticiones de páginas que surgen de la etapa de
presentación.
Así, el tratamiento de estas peticiones por parte
de la etapa de multiplexión (420) no precisa ningún conocimiento del
servicio al que hace referencia la petición. El módulo de
enrutamiento (424) se contenta con solicitar un puerto lógico
pasando en forma de argumentos la información contenida en los
datos de dirección recibidos desde la etapa de presentación, así
como la identificación del abonado, sin analizar el contenido de la
petición o la identidad del servicio que la trata. Una vez la
petición ha llegado al módulo (4100) a (4104) de la etapa de acceso
(410), ésta es entregada tal y como se explica a continuación, lo
que da lugar al envío por parte de este módulo de acceso de una
nueva página XML acompañada de información de identificación del
abonado. Esta página XML es recibida por el motor de análisis y de
fusión (421), que la analiza y ejecuta las fusiones requeridas
según sea el caso, tal y como se ha indicado anteriormente.
El módulo de gestión de abonados (425) coopera
igualmente con el módulo de análisis y de fusión (421) para
direccionar las páginas tratadas en el marco de las sesiones
abiertas con los diferentes abonados. El módulo (425) consulta la
tabla (426) para determinar, a partir de la información de
identificación de abonado que acompaña a cada página XML, el puerto
lógico correspondiente a la sesión en curso con el abonado hacia el
que direcciona la página tratada (primitiva SEND_PAGE).
A título de ejemplo, una página XML generada por
el módulo de acceso (4101) asociado al servidor de guía telefónica
(201) puede incluir datos etiquetados tales como:
\textdollarlabel/name=DUPONT
\textdollarlabel/firstname=PAUL
\textdollarlabel/phonenumber=73778
\textdollarlabel/mailaddress=DUPONT@MATRANORTEL
%call{73778, MakeCall)
%mail(DUPONT@MATRANORTEL, SendMail).
En este ejemplo, las cuatro primeras líneas
describen elementos a presentar al abonado, identificados por la
etiqueta "\textdollarlabel", a saber, el apellido de un
abonado incluido en la guía telefónica (Dupont), su nombre de pila
(Paul), su número de teléfono (73778) y su dirección de mensajería
(dupont@matranortel). La etapa de presentación adoptará el modo de
representación de estos elementos que convenga al terminal utilizado
por el abonado. Las dos últimas líneas comportan códigos de fusión
identificados por la etiqueta "%". El código "%call (73778,
MakeCall)" detectado por el motor de análisis y de fusión (421)
genera una petición de fusión dirigida al módulo de acceso (4100)
asociado al servidor de telefonía, que responde a ella, por
ejemplo, devolviendo los datos de fusión:
<link href =
"cs_server//1049600?phonenumber=73778"
title = \textdollarlabel/MakeCall''>,
que representan un vínculo entre el
dato etiquetado "\textdollarlabel/MakeCall", que generará la
presentación al abonado de una orden de llamada (tecla virtual), y
la dirección de página "cs_server://1049600", que corresponde
a una página de llamada telefónica gestionada por el módulo de
acceso (4100) asociado al servidor de telefonía (200), con el
parámetro de llamada "phonenumber=73778" designando el número
al que se llama. Igualmente, el código "%mail (DUPONT@MATRANORTEL,
SendMail)" detectado por el motor de análisis y de fusión (421)
genera una petición de fusión dirigida al módulo de acceso (4102)
asociado al servidor de mensajería, que responde a ella, por
ejemplo, devolviendo los datos de
fusión:
<link href =
"mail_server://1249600?mailaddress=DUPONT@MATRANORTEL"
title = \textdollarlabel/SendMail''>,
que representan un vínculo entre el
dato etiquetado "\textdollarlabel/SendMail", que generará la
presentación al abonado de una orden de envío de mensaje (tecla
virtual), y la dirección de página "mail_server://1249600",
que corresponde a una página de envío de mensaje gestionada por el
módulo de acceso (4102) asociado al servidor de mensajería (202),
con el parámetro "mailaddress=DUPONT@MATRANORTEL" designando la
dirección a la que se envía el
mensaje.
La figura 5 muestra un ejemplo de visualización
generada en la pantalla de un terminal tras la generación de la
página precedente, tratada por el motor de análisis y de fusión
(421). La activación por parte del abonado de una de las teclas
virtuales T desencadenará el envío de vuelta de la dirección de
página "cs_server://1049600" o "mail_server://1249600"
desde la etapa de presentación (430) hacia la etapa de multiplexión
(420), y a continuación una petición de página hacia el módulo de
acceso (4100) o (4102) para inicializar el establecimiento de la
llamada solicitada o el envío del mensaje.
La operación de fusión puede implicar varias
peticiones de fusión sucesivas cuando hay códigos de fusión
entrelazados presentes en la página. En tal caso, la jerarquía de
los paréntesis permite al motor de análisis (421) separar los
códigos de fusión y comenzar por generar las peticiones de fusión
para los códigos interiores, consistiendo entonces los datos de
fusión intermedios en parámetros que el motor de análisis y de
fusión (421) hace que sustituyan a los códigos de fusión
correspondientes.
A título de ejemplo, una página XML generada por
la etapa de acceso (410) puede incluir el siguiente código de
fusión:
%call(%last_outgoing_call, Bis).
En este ejemplo, el código de fusión
"%last_outgoing_call", tratado en primer lugar, corresponde a
un puerto lógico del servidor de datos de fusión (414) del módulo
de acceso (4104) asociado al servidor de registro diario. Al
recibir la petición de fusión dirigida a este puerto lógico, el
módulo de acceso (4104) consulta el servidor de registro diario
(204) para recuperar el último número de teléfono al que ha llamado
el abonado, y este número se devuelve a la etapa de multiplexión en
forma de datos de fusión, por ejemplo "78722". El código de
fusión "%call (78722, Bis)" resultante de esta primera etapa se
trata a continuación, por su parte, por medio de una petición de
fusión al módulo de acceso (4100), que devuelve, de la misma manera
que en el ejemplo anterior, los datos etiquetados:
<link href =
"cs_server://1049600?phonenumber=78722"
title = \textdollarlabel/Bis''>,
los cuales permiten presentar al
abonado una tecla virtual correspondiente a la función de repetición
de la última llamada (tecla
Bis).
Se puede ver que el motor (421) permite a la
etapa de multiplexión (420) fusionar objetos correspondientes a
servicios diferentes sin que tenga conocimiento a priori de los
servicios implicados. De esta manera, una página recibida desde la
etapa (410), procedente de un primer módulo de acceso y que
contenga una acción correspondiente a un servicio cuyo tratamiento
tiene lugar en el interior de un segundo módulo de acceso, es
tratada por la etapa de multiplexión (420) de tal manera que, en
lugar de contener códigos de fusión, contiene vínculos y/o datos
etiquetados que describen los elementos a presentar, y de tal
manera que sea explotable por la etapa de presentación (430) sin que
sea necesario establecer un diálogo entre los diferentes servidores
(200) a (204) o módulos de acceso (4100) a (4104).
La incorporación de códigos de fusión a las
páginas XML entregadas por la etapa de acceso no implica tampoco que
un módulo de acceso conozca la estructura de los servicios ofrecidos
por los servidores dedicados a los cuales no está asociado. En el
primero de los anteriores ejemplos, para insertar los códigos
"%call(73778, MakeCall)" y "%mail (DUPONT@MATRANORTEL,
SendMail)", el servidor de páginas (416) del módulo de acceso
(4101) asociado al servidor de guía telefónica (201) simplemente
necesita saber que "73778" es un número de teléfono al que
puede llamar y que "DUPONT®MATRANORTEL" es una dirección de
mensajería (lo que forma parte de la actividad guía telefónica), sin
saber cómo los servidores (200) y (202) tratan las llamadas
telefónicas y el envío de mensajes.
Claims (11)
1. Dispositivo de supervisión de terminales
conectados a una red de comunicación (300) para proporcionar a los
abonados que utilizan los terminales (100-103)
diferentes servicios gestionados por varios servidores dedicados
(200-204), comprendiendo el dispositivo (400) medios
(440) de interfaz con la red, una etapa (430) de presentación de
servicios a los terminales a través de los citados medios de
interfaz, una etapa (420) de multiplexión de servicios en
comunicación con la etapa de presentación, y una etapa (410) de
acceso a los servicios en comunicación con la etapa de multiplexión
y que comporta varios módulos de acceso
(4100-4104), estando asociado cada uno de ellos a un
servidor dedicado respectivo,
en el que cada módulo de acceso
(4100-4104) se halla dispuesto para entregar páginas
de datos etiquetados a la etapa de multiplexión (420) en respuesta
a mensajes entrantes emitidos por el servidor dedicado asociado
(200- 204) y/o a peticiones de página emitidas por la etapa de
multiplexión, y para entregar los datos de fusión a la etapa de
multiplexión en respuesta a peticiones de fusión, estando cada
página entregada asociada a un abonado con el cual la etapa de
multiplexión tiene una sesión de comunicación en curso por medio de
la etapa de presentación, conteniendo al menos determinadas páginas
entregadas a la etapa de multiplexión códigos de fusión relacionados
con los servicios,
en el que la etapa de multiplexión (420)
comprende medios (421) de tratamiento de cada página recibida desde
la etapa de acceso (410) para detectar los códigos de fusión,
dirigir una petición de fusión al módulo de acceso (4100- 4104)
asociado al servidor dedicado que gestiona el servicio al que se
refiere cada código de fusión detectado, realizar la sustitución de
los datos de fusión entregados por el citado módulo de acceso en
respuesta a la petición de fusión en un campo de la página que
incluye el código de fusión detectado, y proporcionar la página
tratada a la etapa de presentación (430) en el marco de la sesión
en curso con el abonado asociado, conteniendo cada página
proporcionada a la etapa de presentación datos etiquetados que
describen, de acuerdo con un formato independiente de los
terminales (100-103), elementos de interacción con
el abonado asociado,
en el que la etapa de presentación (430)
comprende medios de control de terminales (433-437)
que interpretan cada página recibida desde la etapa de multiplexión
(420) en el marco de una sesión en curso con un abonado que utiliza
uno de los terminales (100-103), con el fin de
generar órdenes adaptadas a la presentación en el terminal de
elementos de interacción descritos por los datos etiquetados de la
página,
y en el que la etapa de multiplexión (420)
comprende además medios de enrutamiento (424) para recibir
direcciones de página desde la etapa de presentación en el marco de
una sesión en curso con un abonado, identificar un módulo de acceso
(4100-4104) al que está destinada la dirección de
página recibida, y transmitir una petición de página correspondiente
al módulo de acceso identificado.
2. Dispositivo, según la reivindicación 1, en el
que los datos etiquetados contenidos en al menos determinadas
páginas de las proporcionadas a la etapa de presentación (430)
describen, además de los elementos de interacción con el abonado
asociado, al menos un vínculo entre uno de los citados elementos de
interacción y una dirección de página, y en el que los medios de
control de terminales (433-437) de la etapa de
presentación se hallan dispuestos para asociar cada vínculo de una
página recibida desde la etapa de multiplexión (420), en el marco
de una sesión en curso con un abonado que utiliza uno de los
terminales (100-103), con un evento que puede
producirse en el nivel del terminal, y para devolver la dirección
de pagina del citado vínculo a la etapa de multiplexión en el marco
de la citada sesión, en respuesta a un suceso del citado
evento.
3. Dispositivo, según la reivindicación 2, en el
que los vínculos descritos en los datos etiquetados contenidos en
las páginas proporcionadas a la etapa de presentación (430)
comprenden vínculos estáticos que los medios de control
(433-437) asocian a eventos predeterminados,
pudiendo producirse en el nivel de los terminales
(100-103), y vínculos dinámicos asociados a
elementos presentes de manera dinámica en el nivel de los
terminales (100-103).
4. Dispositivo, según la reivindicación 2 ó 3,
que comprende medios para generar una página de inicio tras una
apertura de sesión entre la etapa de multiplexión (420) y un abonado
que utiliza uno de los terminales (100-103), siendo
tratada la página de inicio por la etapa de presentación (430), y
conteniendo vínculos con direcciones de página destinadas a
diferentes módulos de la etapa de acceso (410).
5. Dispositivo, según la reivindicación 4, en el
que los medios para generar la página de inicio se hallan
comprendidos dentro de uno de los módulos de acceso
(4100-4104).
6. Dispositivo, según cualquiera de las
reivindicaciones precedentes, en el que las citadas páginas de
datos etiquetados son páginas XML establecidas de acuerdo con un
formato común al conjunto del dispositivo.
7. Dispositivo, según cualquiera de las
reivindicaciones precedentes, en el que la etapa de multiplexión
(420) comprende medios de gestión de abonados (425) que cooperan
con una memoria (426) en la que se almacenan datos referentes a los
abonados.
8. Dispositivo, según la reivindicación 7, en el
que los datos referentes a un abonado almacenados en la citada
memoria (426) comprenden un identificador de abonado y parámetros
de autentificación que los medios de gestión de abonados (425)
comparan con parámetros proporcionados por el abonado durante una
apertura de sesión con el citado abonado.
9. Dispositivo, según cualquiera de las
reivindicaciones precedentes, en el que los medios de enrutamiento
(424) de la etapa de multiplexión (420) cooperan con una memoria
(423) que contiene una tabla de correspondencia entre partes de las
direcciones de página recibidas desde la etapa de presentación
(430) y puertos lógicos respectivos de la etapa de acceso (410)
asociados a los módulos de acceso (4100-4104) a los
que deben transmitirse las peticiones de página
correspondientes.
10. Dispositivo, según cualquiera de las
reivindicaciones precedentes, en el que los medios de tratamiento
(421) de la etapa de multiplexión (420) cooperan con una memoria
(422) que contiene una tabla de correspondencia entre partes de los
códigos de fusión y puertos lógicos respectivos de la etapa de
acceso (410) asociados a los módulos de acceso
(4100-4104) a los que deben transmitirse las
peticiones de fusión correspondientes.
11. Dispositivo, según cualquiera de las
reivindicaciones precedentes, en el que al menos uno de los módulos
de acceso (4100-4104) comprende una biblioteca de
páginas estáticas (417) de donde se extraen, al menos en parte,
páginas de datos etiquetados entregadas a la etapa de multiplexión
(420) en respuesta a peticiones de página, sin que se produzca
ningún intercambio con el servidor dedicado asociado
(200-204).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0005824A FR2808640B1 (fr) | 2000-05-05 | 2000-05-05 | Dispositif de supervision de terminaux |
| FR0005824 | 2000-05-05 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2225536T3 true ES2225536T3 (es) | 2005-03-16 |
Family
ID=8849974
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01929771T Expired - Lifetime ES2225536T3 (es) | 2000-05-05 | 2001-05-02 | Dispositivo de supervision de terminales. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7286523B2 (es) |
| EP (1) | EP1279298B1 (es) |
| AT (1) | ATE272927T1 (es) |
| AU (1) | AU2001256457A1 (es) |
| DE (1) | DE60104672T2 (es) |
| ES (1) | ES2225536T3 (es) |
| FR (1) | FR2808640B1 (es) |
| WO (1) | WO2001086969A1 (es) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2818854B1 (fr) | 2000-12-22 | 2003-03-28 | Matra Nortel Communications | Procede d'etablissement de chemins de communication entre des points d'acces d'un systeme de commutation, et systeme de commutation mettant en oeuvre le procede |
| US7216117B2 (en) * | 2001-06-15 | 2007-05-08 | Qwest Communications Inc. | System and method for address book customization for shared emessaging |
| US20100241664A1 (en) * | 2007-11-07 | 2010-09-23 | Dialplus, Inc. | Smart web pages provisioning system and method for mobile devices |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| GB9603582D0 (en) * | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
-
2000
- 2000-05-05 FR FR0005824A patent/FR2808640B1/fr not_active Expired - Fee Related
-
2001
- 2001-05-02 US US10/275,090 patent/US7286523B2/en not_active Expired - Fee Related
- 2001-05-02 AU AU2001256457A patent/AU2001256457A1/en not_active Abandoned
- 2001-05-02 AT AT01929771T patent/ATE272927T1/de not_active IP Right Cessation
- 2001-05-02 ES ES01929771T patent/ES2225536T3/es not_active Expired - Lifetime
- 2001-05-02 WO PCT/FR2001/001339 patent/WO2001086969A1/fr active IP Right Grant
- 2001-05-02 EP EP01929771A patent/EP1279298B1/fr not_active Expired - Lifetime
- 2001-05-02 DE DE60104672T patent/DE60104672T2/de not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7286523B2 (en) | 2007-10-23 |
| US20030103493A1 (en) | 2003-06-05 |
| FR2808640A1 (fr) | 2001-11-09 |
| WO2001086969A1 (fr) | 2001-11-15 |
| EP1279298A1 (fr) | 2003-01-29 |
| ATE272927T1 (de) | 2004-08-15 |
| DE60104672T2 (de) | 2005-08-11 |
| FR2808640B1 (fr) | 2002-07-19 |
| DE60104672D1 (de) | 2004-09-09 |
| EP1279298B1 (fr) | 2004-08-04 |
| AU2001256457A1 (en) | 2001-11-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2258065T3 (es) | Sistema de comunicacion para un equipo de automatismo basado en el lenguaje wsdl. | |
| Bonaventure | Computer Networking: Principles, Protocols and Practice | |
| US6393467B1 (en) | Network interconnected computing device, server and notification method | |
| US6873620B1 (en) | Communication server including virtual gateway to perform protocol conversion and communication system incorporating the same | |
| SE503752C2 (sv) | System och värdanordning för överföring av elektronisk post över ett mobiltelenät | |
| EP1040626B1 (en) | Apparatus and method for electronic mail address portability | |
| EP1562347A1 (en) | Methods and apparatus for utilizing user software to communicate with network-resident services | |
| JP2004194330A (ja) | 通信ネットワーク上の目標エンティティへのアクセス方法 | |
| CA2356679A1 (en) | Extended number portability database services | |
| CA2364974C (en) | Automatic conversion of telephone number to internet protocol address | |
| US9007966B2 (en) | Accessing a communications network | |
| CN109922148B (zh) | 跨平台服务方法、装置和系统 | |
| ES2225536T3 (es) | Dispositivo de supervision de terminales. | |
| ES2318216T3 (es) | Analisis de operaciones relacionadas con servicios de red. | |
| ES2294913A1 (es) | Sistema de mensajeria y metodo para el mismo. | |
| KR20180059385A (ko) | 복수개의 저전력 장거리 통신(lpwa) 인터페이스를 통해 전송되는 메시지를 클라우드 시스템에 접속시키기 위한 공통 콘테이너 생성 장치 | |
| ES2256973T3 (es) | Tratamiento de datos de abonado, en redes de telecomunicaciones. | |
| CN1706204B (zh) | 用于信令事件的业务逻辑环境高速缓存 | |
| Cisco | NAT Support of H.323 v2 RAS | |
| FI110225B (fi) | Menetelmä interaktiivisten palveluiden tuottamiseksi | |
| FI116871B (fi) | Tiedonvälitysjärjestelmä, menetelmä tiedon välittämiseksi, palvelutuote sekä palvelutuotteen käyttö | |
| ES2396226T3 (es) | Seguimiento de datos relativos a cursos de aprendizaje por ordenador | |
| EP1095525A1 (en) | Hypertext transport protocol interface in an intelligent network node | |
| EP1533960A1 (en) | Providing to the sender of a message an identifier of the service provider associated with the recipient of the message | |
| ES2300721T3 (es) | Servidor de perfil y aplicacion a las redes de comunicacion. |