ES2245932T3 - Procedimiento y aparato para generar datos para facturar a un usuario el acceso a traves de un enlace de red de comunicaciones. - Google Patents
Procedimiento y aparato para generar datos para facturar a un usuario el acceso a traves de un enlace de red de comunicaciones.Info
- Publication number
- ES2245932T3 ES2245932T3 ES00900277T ES00900277T ES2245932T3 ES 2245932 T3 ES2245932 T3 ES 2245932T3 ES 00900277 T ES00900277 T ES 00900277T ES 00900277 T ES00900277 T ES 00900277T ES 2245932 T3 ES2245932 T3 ES 2245932T3
- Authority
- ES
- Spain
- Prior art keywords
- user
- computer system
- server
- intended
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Meter Arrangements (AREA)
- Telephone Function (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Procedimiento para generar datos de facturación en relación con el uso de un enlace de red de comunicaciones destinado a permitir el paso de información entre un sistema informático (10) utilizado por un usuario y un sistema informático (20, 30) destinado a proporcionar al usuario un contenido a través de dicho enlace de red de comunicaciones, implicando el enlace de red de comunicaciones por lo menos una relación cliente/servidor que comprende una pluralidad de conexiones lógicas, y comprendiendo el procedimiento las etapas siguientes: detección, en por lo menos una conexión lógica de dicha relación cliente/servidor, de por lo menos un evento que ocasiona el cambio de estado de por lo menos una conexión lógica definida por al menos una dirección de capa de red del cliente, una dirección de capa de transporte del cliente, una dirección de capa de red del servidor y una dirección de capa de transporte del servidor, registro de los datos (220) creados en respuesta a dicho por lo menos un evento detectado, y generación de datos de facturación en base a los datos registrados, estando caracterizado el procedimiento por: un sistema informático (20, 30) destinado a proporcionar al usuario acceso limitado a dicho enlace de comunicaciones, llevando a cabo las etapas siguientes: supervisión de los cambios de estado de las conexiones lógicas entre el sistema informático del usuario (10) y el sistema informático (20, 30) destinado a proporcionar un contenido al usuario, siendo proporcionado dicho contenido al usuario mediante la utilización de las conexiones lógicas, y creación de los datos (220) cuando la utilización del enlace de comunicaciones determina que por lo menos una de dichas conexiones lógicas supervisadas cambie de estado al ser generada y/o terminada.
Description
Procedimiento y aparato para generar datos para
facturar a un usuario el acceso a través de un enlace de red de
comunicaciones.
La presente invención se refiere a un
procedimiento y un aparato para generar datos para facturar a un
usuario de un sistema informático el acceso a través de un enlace
de red de comunicaciones. Más particularmente, pero no de forma
exclusiva, la presente invención se refiere a un procedimiento y un
aparato para generar datos para facturar a un usuario de un sistema
informático el acceso al contenido proporcionado por un proveedor
de contenido, ya sea directamente o por medio de un proveedor de
acceso.
En el campo de Internet, tanto el proveedor de
acceso como el proveedor de contenido se denominan en ocasiones
proveedores de servicios de Internet. En la presente memoria, el
término "proveedor de contenido" hace referencia a un operador
de sistema informático desde el cual un usuario de un sistema
informático puede desear recibir un contenido. El término
"proveedor de acceso" hace referencia a un operador de sistema
informático que, aunque tal vez no contenga ningún contenido útil
para el usuario, permite al usuario recibir el contenido de un
proveedor de contenido.
Existen varias tecnologías por medio de las
cuales el sistema informático de un usuario puede conectarse al
sistema informático de un proveedor de acceso o un proveedor de
contenido a través de un enlace de comunicaciones. Una tecnología
común es el módem de conexión telefónica. Los dos sistemas
informáticos de cada extremo del enlace se conectan a un módem que
sirve para modular o demodular los datos enviados o recibidos, de
tal forma que éstos puedan ser transmitidos a través de una línea
telefónica de voz común de la red telefónica pública conmutada
(PSTN). Esta tecnología, por lo tanto, exige que el usuario
establezca una conexión telefónica con el proveedor de acceso o el
proveedor de contenido. Otro ejemplo de tecnología de conexión
telefónica es la red digital de servicios integrados (ISDN). Esta
tecnología utiliza dos adaptadores de terminal ISDN en cada extremo
para dividir una línea telefónica de par trenzado de cobre
corriente en dos canales digitales, obteniendo de ese modo
velocidades de transferencia de datos superiores a las de los
enlaces de módem de voz habituales, aunque todavía sigue siendo
necesario que el usuario establezca una conexión telefónica
PSTN.
Entre otras tecnologías para enlaces físicos de
comunicaciones se incluyen los enlaces de comunicaciones
permanentemente activados, denominados también enlaces de
comunicaciones "always-on" (de conexión
permanente). Un ejemplo de enlace de conexión permanente es una
línea arrendada instalada por una compañía de telecomunicaciones.
Habitualmente, se instalan líneas arrendadas entre sistemas
informáticos separados geográficamente por una tarifa fija mensual
que da derecho a un enlace permanentemente activado o por lo menos
en potencia. Otro ejemplo de tecnología de enlace de comunicaciones
que puede establecerse como enlace de conexión permanente son las
líneas de abonado digitales, denominadas globalmente xDSL. Los
enlaces de comunicaciones xDSL ofrecen velocidades de transferencia
de datos a través de líneas telefónicas de par trenzado de cobre
superiores a las de, por ejemplo, los enlaces de comunicaciones
ISDN. La línea de abonado digital asimétrica (ADSL), perteneciente
a la familia xDSL, proporciona capacidades de transferencia de
datos asimétrica entre las dos unidades terminales conectadas a
través de líneas telefónicas de par trenzado de cobre u otras
líneas, de tal forma que la velocidad de transferencia de datos
aguas abajo desde el proveedor de contenido o el proveedor de acceso
puede ser relativamente alta comparada con la velocidad de
transferencia de datos aguas arriba desde el usuario.
Existen diversos procedimientos comunes para
facturar al usuario de un sistema informático conectado a través de
un enlace de red de comunicaciones a Internet, por ejemplo, por el
uso que hace de la conexión. Cuando el sistema informático del
usuario está conectado al sistema informático de un proveedor de
contenido o un proveedor de acceso por medio de un enlace de
comunicación de conexión telefónica, uno de los procedimientos
consiste en facturar al usuario una tarifa de abono mensual o anual
que le da derecho a cierto número de horas "en línea". Otro
procedimiento consiste en facturar al usuario una tarifa plana
mensual o anual para un tiempo "en línea" ilimitado. En ambos
de estos procedimientos comunes, el usuario normalmente abona
también a una compañía telefónica el importe de la duración de la
llamada telefónica al proveedor de contenido o de acceso.
Cuando el sistema informático del usuario está
conectado al sistema informático de un proveedor de contenido o de
acceso por medio de un enlace de comunicaciones de conexión
permanente, no se dispone de una medición válida del período de
tiempo que el usuario permanece "en línea". Un procedimiento
para facturar al usuario consiste en cobrar una tarifa plana,
complementada opcionalmente con un cargo basado en la cantidad de
datos que pasa a través del enlace de comunicaciones.
Una desventaja que comporta el cobro de una
tarifa plana de abono mensual o anual para una cierta cantidad de
horas "en línea" es que tampoco resulta preciso para el uso
que se ha realizado de la conexión. En particular, los importes
aplicados por estas soluciones comunes a los usuarios de uso elevado
y a los usuarios de uso reducido pueden ser desproporcionados.
La medición de la cantidad de paquetes de datos a
través de un enlace de comunicaciones tiene en cuenta la
utilización, pero adolece también de una serie de desventajas. Una
de las desventajas es que dicha medición es una tarea compleja para
el proveedor de contenido o de acceso y que consume bastante tiempo
del procesador, puesto que los paquetes de datos pueden ser
numerosos y presentar un tamaño variable.
En la técnica anterior, la publicación de patente
internacional nº WO97/01920 describe un procedimiento para facturar
al usuario de un sistema informático los servicios sujetos a cargo
utilizados, en el que el usuario efectúa una llamada telefónica
separada a un número de teléfono sujeto a cargo predeterminado que
permite la conexión entre el sistema informático del usuario y el
proveedor de acceso o de contenido. La facturación se lleva a cabo
basándose en la conexión telefónica.
La patente US nº 5.745.556 describe un mecanismo
de pago para el acceso a Internet de los usuarios. La compañía
telefónica proporciona un número de teléfono a un proveedor de
acceso o de contenido, y los cargos pueden ser establecidos por la
parte llamada. La facturación se lleva a cabo a través de una
llamada telefónica real o virtual efectuada a ese número de teléfono
y se carga al usuario.
La patente US nº 5.737.414 describe un
procedimiento para utilizar un ordenador de gestión de acceso y
controlar el acceso a los datos por el usuario. El usuario se
conecta al ordenador de gestión de acceso a través de un enlace de
comunicaciones de conexión telefónica y obtiene un mensaje de acceso
exclusivo en la página de inicio del proveedor de acceso o a través
de una llamada telefónica separada al proveedor de acceso. El
proveedor de acceso comunica también al usuario el importe por el
acceso a los datos basándose en la duración de la conexión "en
línea" o en cierta cantidad fija.
La publicación de patente internacional nº
WO97/41586 describe un sistema capaz de garantizar el acceso a
Internet a los usuarios cuando la conexión directa con el proveedor
de acceso habitual es imposible, poco práctica o tiene un precio
prohibitivo. El usuario se conecta a un proveedor de acceso
independiente, a través de un enlace de comunicaciones de conexión
telefónica, que proporciona acceso a Internet validando el derecho
del usuario por medio de un control de acceso remoto. La
facturación se efectúa enviando paquetes de información de
facturación a intervalos regulares a un coordinador.
La solicitud de patente europea
EP-A-0 866 596 describe un
procedimiento y un aparato para la facturación de telefonía de
Internet. Cuando el interlocutor que llama se conecta a un
proveedor de acceso a Internet para efectuar una llamada de voz con
otro interlocutor, el proveedor de acceso envía, a un servidor de
facturación, información referente a las identidades de los
llamantes, la hora inicial de la llamada, la identidad del
proveedor de acceso y diversos parámetros de configuración de la
llamada. Durante la llamada, el servidor de facturación recibe
información periódica actualizada, y el proveedor de acceso
notifica al servidor de facturación el final de la llamada. El
servidor de facturación aplica los cargos al interlocutor adecuado
basándose en la información proporcionada, que puede incluir
información sobre encaminamiento de llamada, densidad de paquetes y
realce de voz.
La patente US nº 5.790.548 describe un sistema y
un procedimiento para proporcionar acceso a servicios tales como
vídeo a petición a través de una línea de par trenzado de cobre
PSTN, mediante una conexión de tipo permanente, tal como la
conexión ADSL. El documento hace referencia a procedimientos de
facturación a los usuarios, tales como el cobro de una tarifa plana
o el seguimiento de la cantidad de tráfico de usuarios soportado
por la red.
En la patente US nº 5.862.335, publicada el 19 de
enero de 1999 (con posterioridad a la fecha de prioridad de la
presente solicitud), se da a conocer un procedimiento y un aparato
para supervisar conexiones lógicas y transferencias de archivos en
una red informática. Como consecuencia de esta supervisión, se
genera una base de datos en la que se registra información tal como
la identidad de los ordenadores terminales de una conexión lógica o
una transferencia de archivos, el momento en que se inician las
conexiones o las transferencias de archivos y la cantidad de
información que se intercambia. Esta información puede ser
utilizada para diversas funciones, incluida la facturación a los
usuarios informáticos.
El documento WO98/20646 describe un sistema y un
procedimiento para transferir información, que permite también el
acceso a Internet y a redes similares o partes de éstas desde el
ordenador del usuario, solicitando autorización al titular de los
derechos o similar durante una sesión terminal. Se describe una
interfaz por omisión que da derecho al usuario a pagar sólo por la
facturación correspondiente al uso verdadero, pudiendo ese uso ser
determinado solicitando acceso a la información por medio de un
cortafuegos. El usuario puede solicitar acceso al encaminador o al
conmutador (el cortafuegos) para recibir información, siendo
concedido el acceso únicamente en función de los derechos que posea
el usuario en ese momento, utilizando una tabla de consulta para
determinar si el usuario puede acceder a la dirección, el área o la
puerta IP de destino mediante el envío de su dirección IP.
La supervisión es llevada a cabo por un ordenador
de supervisión de red que está conectado por medio de una unidad de
interfaz a la red y que intercepta todos los paquetes de datos
intercambiados por la red y crea una copia de éstos para analizar.
Un procesador de gestión de red, que se ejecuta en el ordenador de
supervisión de red, analiza los paquetes de datos copiados para
determinar si forman parte de una conexión lógica/transferencia de
archivos existente o de una nueva, examinando los registros de la
base de datos. Para las nuevas conexiones lógicas/transferencias de
archivos se crean nuevos registros, mientras que para las conexiones
lógicas/transferencias existentes se actualizan los registros
existentes. Por lo tanto, el ordenador de supervisión de la red
recopila una base de datos histórica de información relativa a las
conexiones lógicas y transferencias de archivos en la red.
También cabe destacar el documento titulado
"Usage-Based Cost Recovery in Internetworks" de
Ruth y Mills, publicado en Business Communications Review, vol. 22,
nº 7, 1 de julio de 1992, páginas 38-42. Este
documento describe diversas propuestas para facturar el acceso a
Internet e indica las razones por las cuales los mecanismos de
contabilidad de tarifa plana son tan predominantes y que justifican
que la contabilidad basada en el uso resulte tan complicada.
Asimismo, se describen varias propuestas para la contabilidad basada
en el uso, todas de las cuales incluyen la supervisión o el
análisis de paquetes.
El documento presupone que Internet es
básicamente un entorno "sin conexión". Una cuestión
interesante es que, en la página 39, columna izquierda y párrafos 2
a 3, el autor menciona la existencia de unas conexiones
identificables utilizadas por protocolos tales como TCP/IP, pero
omite la posibilidad de la contabilidad basada en el uso mediante
estas conexiones, porque "las cabeceras de los protocolos de
nivel alto no son procesadas por el equipo de red en el que se
lleva la contabilidad".
Las formas de realización se exponen en las
reivindicaciones adjuntas. Un primer aspecto de la presente
invención se refiere a un procedimiento para generar datos de
facturación relativos al uso de un enlace de red de comunicaciones
destinado a permitir el paso de información entre un sistema
informático (10) utilizado por un usuario y un sistema informático
(20, 30) destinado a proporcionar al usuario un contenido a través
de dicho enlace de red de comunicaciones, incluyendo el enlace de
red de comunicaciones por lo menos una relación cliente/servidor que
comprende una pluralidad de conexiones lógicas, y comprendiendo el
procedimiento las etapas siguientes: detección, en por lo menos una
conexión lógica de dicha relación cliente/servidor, de por lo menos
un evento que ocasiona el cambio de estado de por lo menos una
conexión lógica definida por al menos una dirección de capa de red
del cliente, una dirección de capa de transporte del cliente, una
dirección de capa de red del servidor y una dirección de capa de
transporte del servidor, registro de los datos (220) creados en
respuesta a dicho por lo menos un evento detectado, y generación de
datos de facturación basados en los datos registrados, estando
caracterizado el procedimiento respecto al del documento WO
9820646, porque comprende además: un sistema informático (20, 30)
destinado a proporcionar al usuario acceso a dicho enlace de
comunicaciones llevando a cabo las etapas siguientes: supervisión de
los cambios de estado de las conexiones lógicas entre el sistema
informático del usuario (10) y el sistema informático (20, 30)
destinado a proporcionar un contenido al usuario, siendo
proporcionado dicho contenido al usuario mediante la utilización de
las conexiones lógicas, y creación de los datos (220) cuando la
utilización del enlace de comunicaciones determina que por lo menos
una de dichas conexiones lógicas supervisadas cambie de estado al
ser generada o terminada.
Un segundo aspecto de la presente invención,
expuesto en las reivindicaciones adjuntas, se refiere a un aparato
destinado a llevar a cabo un procedimiento para generar datos de
facturación relativos a la utilización de un enlace de red de
comunicaciones destinado a permitir el paso de información entre un
sistema informático (10) utilizado por un usuario y un sistema
informático (20, 30) destinado a proporcionar un contenido al
usuario a través de dicho enlace de red de comunicaciones,
incluyendo el enlace de red de comunicaciones por lo menos una
relación cliente/servidor que comprende una pluralidad de conexiones
lógicas y comprendiendo el aparato: medios informáticos para
detectar, en por lo menos una conexión lógica de dicha relación
cliente/servidor, por lo menos un evento que ocasiona un cambio en
el estado de por lo menos una conexión lógica definida por lo menos
por una dirección de capa de red del cliente, una dirección de capa
de transporte del cliente, una dirección de capa de red del servidor
y una dirección de capa de transporte del servidor, medios de
almacenamiento para registrar los datos creados en respuesta a dicho
por lo menos un evento detectado y medios para generar datos de
facturación basados en los datos registrados, estando caracterizado
el aparato respecto al del documento WO 98/20646 porque comprende
además: un sistema informático (20, 30) destinado a proporcionar a
dicho usuario el acceso al enlace de comunicaciones que incluye:
medios para supervisar los cambios de estado de las conexiones
lógicas entre el sistema informático del usuario (10) y el sistema
informático (20, 30) destinado a proporcionar un contenido al
usuario, siendo proporcionado dicho contenido al usuario mediante
la utilización de las conexiones lógicas y medios para crear los
datos (220) cuando la utilización del enlace de comunicaciones
determina que por lo menos una de dichas conexiones lógicas
supervisadas cambie de estado al ser generada o terminada.
Un tercer aspecto de la presente invención,
expuesto en las reivindicaciones adjuntas, se refiere a un programa
servidor destinado a implementar las etapas de un procedimiento
según el primer aspecto de la presente invención.
En particular, las conexiones lógicas
supervisadas son conexiones lógicas creadas entre el sistema
informático de un cliente y el sistema informático del servidor en
la red y las capas de transporte del modelo referenciado de
transmisión de datos de la Organización Internacional de
Normalización (modelo de referencia ISO). Estas conexiones lógicas
son definidas de forma exclusiva por cuatro direcciones del modelo
de referencia ISO. Estas direcciones son las siguientes: una
dirección de capa de red del cliente, una dirección de capa de
transporte del cliente, una dirección de capa de red del servidor y
una dirección de capa de transporte del servidor. Según la presente
invención, se registran datos en respuesta a los cambios del estado
de las conexiones detectados mediante la supervisión y, a
continuación, se generan datos de facturación basados en los datos
registrados.
En una arquitectura de dos partes, en la que el
usuario se conecta directamente a un proveedor de contenido, el
sistema informático del usuario actúa como cliente y el sistema
informático del proveedor de contenido actúa como servidor.
En una arquitectura de tres partes, en la que el
usuario se conecta a un proveedor de acceso que, a su vez, se
conecta a un proveedor de contenido, existen dos relaciones
cliente/servidor. Existe una primera relación entre el sistema
informático del usuario que actúa como cliente y el sistema
informático del proveedor de acceso que actúa como servidor, y una
segunda relación entre el sistema informático del proveedor de
acceso que actúa como cliente y el sistema informático del
proveedor de contenido que actúa como servidor. En esta
arquitectura, el sistema informático del proveedor de acceso se
denomina servidor intermediario o cliente intermediario.
En otra arquitectura, el usuario se conecta
directamente a un proveedor de contenido y de acceso a otros
proveedores de contenido. Este proveedor de contenido/acceso puede,
a su vez, conectarse a otro proveedor de contenido dependiendo de
la petición del usuario. En esta arquitectura, existen una o dos
relaciones cliente/servidor, según la petición del usuario.
Las conexiones lógicas se establecen entre un
cliente y un servidor para proporcionar un conducto lógico a través
del cual puede pasarse información. Habitualmente, el cliente envía
una petición al servidor, y éste satisface la petición y responde
al cliente. Las conexiones lógicas normalmente se establecen de
forma específica para una sola transacción de
petición-respuesta o para una pluralidad de
transacciones de petición-respuesta relacionadas, y
se terminan una vez que la transacción o las transacciones han
finalizado. A lo largo del tiempo de duración de una conexión
lógica, puede enviarse y recibirse cualquier número de paquetes de
datos a través de ésta, dependiendo de la naturaleza de la
transacción o transacciones de
petición-respuesta.
Mediante la supervisión de los cambios de estado
de las conexiones lógicas, tales como el establecimiento y la
terminación de las conexiones lógicas entre un cliente y un
servidor, es posible registrar datos, tales como el número de las
conexiones lógicas establecidas y terminadas, la hora y la fecha en
que dichas conexiones se establecen y terminan, la duración de
dichas conexiones y cualquiera de las cuatro direcciones que
identifican de forma exclusiva la conexión lógica, es decir, la
dirección de capa de red del cliente, la dirección de capa de
transporte del cliente, la dirección de capa de red del servidor y
la dirección de capa de transporte del servidor. Es posible
registrar datos adicionales, si ello resulta necesario, tales como
el número y el tamaño de los paquetes de datos enviados y recibidos
a través de dichas conexiones lógicas, y la información extraída de
la información de cabecera agregada al principio de los paquetes de
datos. A continuación, pueden generarse datos de facturación basados
en los datos registrados.
La presente invención presenta diversas ventajas
respecto de otras soluciones diferentes descritas en la técnica
anterior. Un problema al que se enfrentan los proveedores de
contenido y los proveedores de acceso, en particular los que operan
en el campo de Internet, es el de determinar cómo pueden aplicarse
correctamente los cargos al usuario por el uso que éste hace de una
conexión a través de un enlace de comunicaciones de conexión
telefónica. Otro problema para los proveedores de contenido y los
proveedores de acceso es el de determinar cómo pueden aplicarse
correctamente los cargos al usuario por el uso que éste hace de una
conexión a través de un enlace de comunicación de conexión
permanente.
En otra de las soluciones de técnica anterior
sugeridas tanto para las conexiones por medio de enlaces de
comunicación de conexión permanente como las de conexión
telefónica, el usuario debe efectuar una llamada telefónica PSTN
separada para poder acceder al contenido, proporcionar una medición
válida del tiempo "en línea" o permitir al proveedor de acceso
o contenido la aplicación de los cargos adecuados a través de un
mecanismo de facturación de número de teléfono especial.
La presente invención proporciona un mecanismo
flexible para generar datos de facturación dependiendo del uso
realizado de las conexiones a través del enlace de red de
comunicaciones, sin necesidad de efectuar la compleja y lenta tarea
de medir la cantidad de paquetes de datos ni de efectuar una
llamada de conexión telefónica PSTN. La presente invención puede
aplicarse a los enlaces de comunicaciones de conexión telefónica,
así como a los enlaces de comunicación de conexión permanente. No
obstante, las formas de realización preferidas de la presente
invención incluyen enlaces de comunicaciones de conexión permanente,
en los que el problema de aplicar cargos correctos por el uso es
más acusado.
A continuación, se describirán las formas de
realización de la presente invención, únicamente a título de
ejemplo, haciendo referencia a los dibujos adjuntos.
La Figura 1 es un diagrama que representa un
sistema de red de comunicaciones de técnica anterior;
la Figura 2 es un diagrama que representa una
forma de realización de un sistema de red de comunicaciones según
una forma de realización de la presente invención;
la Figura 3 es un diagrama que representa las
conexiones lógicas establecidas entre un grupo de sistemas
informáticos de cliente y un sistema informático servidor
multipuerta;
la Figura 4 es un diagrama de flujo que
representa las interacciones usuario/proveedor de acceso/proveedor
de contenido según la presente invención;
la Figura 5 es un diagrama que representa la
distribución temporal de varias de las conexiones lógicas de una
interacción cliente/servidor; y
la Figura 6 es un diagrama que representa un
registro común creado en respuesta a la supervisión de las
conexiones lógicas según la presente invención.
Las interfaces de programación de aplicaciones
(API) utilizadas para programar aplicaciones cliente y servidor para
el control de conexiones lógicas están muy establecidas y bien
documentadas.
En una forma de realización de la presente
invención, en el campo de Internet, las conexiones lógicas son
conexiones socket (conexiones por punto de comunicación) del
protocolo de control de transmisión/protocolo Internet (TCP/IP) y
las API son las API de sockets creadas originalmente por Computer
Systems Research Group de la Universidad de California en Berkeley.
Las API de sockets proporcionan rutinas bien documentadas para el
manejo de las conexiones socket TCP/IP. Para obtener una
descripción detallada de los protocolos TCP/IP y las API de
sockets, puede consultarse el documento de W. Richard Stevens
"TCP/IP Illustrated Vols. 1-3".
Cada conexión socket se define de forma exclusiva
mediante cuatro direcciones: la dirección IP del cliente (es decir,
la dirección de capa de red del cliente), el número de puerta del
cliente (es decir, la dirección de capa de transporte del cliente),
la dirección IP del servidor (es decir, la dirección de capa de red
del servidor) y el número de puerta del servidor (es decir, la
dirección de capa de transporte del servidor).
Las direcciones IP identifican de forma exclusiva
las interfaces de los sistemas informáticos particulares conectados
a Internet. Por ejemplo, si el usuario desea conectarse
directamente a un proveedor de contenido mediante un navegador tal
como Netscape Navigator™ o Microsoft Internet Explorer™, la
dirección de red del cliente será la dirección IP del sistema
informático del usuario y la dirección de red del servidor será la
dirección IP del sistema informático del proveedor de contenido (o
una de las direcciones IP del sistema del proveedor de contenido
cuando el proveedor de contenido funciona como un servidor
multipuerta).
Para identificar conexiones particulares, se
utilizan las direcciones de capa de transporte además de las
direcciones IP. Si el usuario conectado directamente al proveedor
de contenido desea acceder a documentos de hipertexto de la Web, la
dirección de capa de transporte del servidor será el número de
puerta TCP 80 que es la conocida puerta para el protocolo de
transferencia de hipertexto (HTTP). La capa de transporte del
usuario será un "número de puerta efímera", es decir, un
número exclusivo pero arbitrario de 1024 a 5000 asignado por el
sistema informático del usuario para identificar de forma exclusiva
una petición de conexión del cliente. Con algunos clientes de
navegador, se utilizan varias puertas efímeras simultáneamente para
agilizar el acceso a contenidos complejos, tales como páginas web
de varios archivos.
El TCP/IP es un paquete de protocolos que permite
a diferentes sistemas informáticos comunicarse entre sí a través de
Internet. Los diversos protocolos que componen el TCP/IP están
distribuidos en una estructura de capas. El paquete TCP/IP se
considera normalmente un paquete de protocolos de cuatro capas, en
el que la capa inferior es una capa de enlace, la capa situada
encima de ésta es una capa de red, la capa situada encima de la
capa de red es una capa de transporte y la capa superior es una
capa de aplicación. La capa de enlace normalmente incluye el
hardware de comunicación física y los controladores de los
dispositivos para utilizarlo. La capa de red se ocupa del movimiento
de los paquetes de datos por la red. El protocolo IP (protocolo
Internet) es el protocolo más importante de esta capa. Cada
interfaz de red de cada sistema informático conectado a Internet
presenta una dirección IP exclusiva. Esto permite al IP enviar datos
al destino correcto, aunque los datos puedan emprender muchas
trayectorias diferentes para llegar a éste. La capa de transporte
se ocupa de los datos que se van a enviar a través de Internet. Esta
capa es la encargada de dividir los datos en paquetes de tamaño
adecuado para la transmisión. Los dos protocolos dominantes de esta
capa son el TCP y el UDP. El protocolo TCP, o protocolo de control
de transmisión, proporciona un flujo de datos fiable solicitando al
sistema informático receptor que confirme la recepción de los
paquetes de datos enviados. No obstante, el UDP, o protocolo de
datagrama de usuario, proporciona un servicio más simple en el que
los paquetes de datos, denominados datagramas, se transmiten sin
garantía de que lleguen a su destino. La capa de aplicación se
ocupa del servicio particular que se está utilizando.
Existen numerosas aplicaciones TCP/IP
disponibles, por ejemplo, el protocolo de transferencia de archivos
(FTP), el protocolo de transferencia de correo simple (SMTP), el
protocolo de gestión de red simple (SNMP), el protocolo de
transferencia de archivos trivial (TFTP), el protocolo de
transferencia de hipertexto (HTTP) y el protocolo de transferencia
de noticias en red (NNTP). Las diferentes aplicaciones utilizan
protocolos de capa de transporte diferentes. El FTP, el SMTP, el
HTTP y el NNTP utilizan el TCP, por ejemplo, mientras que el TFTP y
el SNMP utilizan el UDP. El TCP y el UDP indican a qué aplicaciones
están destinados los paquetes de datos, mediante números de puerta
de 16 bits. Las aplicaciones están asociadas normalmente a números
de puerta muy conocidos. Por ejemplo, cada servidor TCP/IP que
ofrece FTP proporciona servicio por la puerta TCP 21, y cada
servidor que ofrece TFTP proporciona servicio por la puerta UDP
69.
Cuando una aplicación envía datos a través de
Internet, los datos son enviados hacia abajo por la pila de
protocolos. Cada capa añade la información de control necesaria
agregando cabeceras al principio de los datos que recibe. Por
ejemplo, el IP añade información de cabecera que incluye las
direcciones IP de origen y destino, y tanto el TCP como el UDP
añaden información que incluye los números de puerta de origen y
destino. El procedimiento de inserción de cabeceras sucesivas a los
datos se denomina encapsulado. El proceso de lectura y extracción
de las cabeceras en el extremo de recepción se denomina
demultiplexación.
La Figura 1 representa un ejemplo, según la
técnica anterior, de cómo el sistema informático de un usuario 10
puede conectarse a varios sistemas informáticos de proveedor de
contenido 20 a través de Internet 40, por medio del sistema
informático de un proveedor de acceso 30. El sistema informático del
usuario 10 está conectado al sistema informático del proveedor de
acceso 30 por medio de, por ejemplo, un par de módems 50 que
transmiten y reciben señales a través de líneas telefónicas de par
trenzado de cobre 60. En algunos ejemplos de la técnica anterior,
el usuario efectúa también una llamada telefónica PSTN corriente
desde un teléfono 70 hasta el proveedor de acceso 30 por medio de un
operador de telecomunicaciones 80. La información de facturación
puede ser generada por el proveedor de acceso 30 y almacenada en
medios de almacenamiento de datos 90.
La Figura 2 representa cómo se conecta el sistema
informático del usuario 10 a los sistemas informáticos de un
proveedor de contenido 20 por medio del sistema informático de un
proveedor de acceso 30, según una forma de realización de la
presente invención, de acuerdo con la arquitectura de tres partes
descrita anteriormente.
El sistema informático del proveedor de acceso 30
se conecta al sistema informático del proveedor de contenido 20 a
través de Internet 40, por ejemplo, u otra red de comunicaciones
general. El sistema informático del usuario 10 se conecta al
sistema informático del proveedor de acceso 30 por medio de un par
de unidades terminales xDSL 50 que transmiten y reciben señales
digitales a través de una línea telefónica de par trenzado 60, por
ejemplo. La unidad terminal remota xDSL se conecta al sistema
informático del proveedor de acceso 30 a través de una conexión
virtual permanente en una red de modalidad de transferencia
asincrónica (ATM) 70, por ejemplo. Las conexiones permanentes entre
el sistema informático del usuario 10 y el sistema informático del
proveedor de acceso 30 a través de la red ATM 70 son controladas por
el sistema de gestión de la red 80.
En otra forma de realización de la presente
invención, según la arquitectura de dos partes descrita
anteriormente, el sistema informático 30 es un proveedor de
contenido y es capaz de proporcionar contenido al sistema
informático del usuario 10 por medio de la conexión virtual
permanente a través de la red ATM 70, por ejemplo.
En otra forma de realización de la presente
invención, según la otra arquitectura descrita anteriormente, el
sistema informático 30 es un proveedor de contenido y de acceso. El
sistema informático 30 se conecta y es capaz de proporcionar
contenido al sistema informático del usuario 10 de la forma
descrita anteriormente en las formas de realización según la
arquitectura de dos y de tres partes.
En las tres formas de realización, el sistema
informático 30 supervisa las conexiones lógicas efectuadas entre el
sistema informático del usuario 10 y el sistema informático y puede
supervisar las conexiones lógicas efectuadas entre el sistema
informático y el sistema informático del proveedor 20, si es
necesario. En respuesta a los cambios de los estados de estas
conexiones lógicas detectados mediante la supervisión, se crean
datos que se registran en unos medios de almacenamiento de datos
90. Los datos de facturación generados de acuerdo con los datos
registrados se almacenan también en los medios de almacenamiento de
datos 90, o pueden registrarse en otros medios de almacenamiento de
datos (no representados).
La Figura 3 representa varias de las conexiones
lógicas que pueden crearse entre un servidor multipuerta 110 y un
grupo de clientes 120, 122, 124 y 126 en el campo de Internet. Con
un diseño de servidor multipuerta, el servidor 110 puede presentar
dos direcciones IP 112 y 114 en el mismo sistema informático.
Asimismo, el servidor 110 puede ofrecer un grupo de servicios
diferentes obtenidos por medio de diferentes puertas 150 y 152 que
tienen números de puerta diferentes. Asimismo, puesto que el
servidor 110 es un servidor multipuerta, tal vez ofrezca por la
puerta 154 uno de los mismos servicios que las puertas 150 ó 152, o
tal vez ofrezca un servicio diferente con un número de puerta
diferente. Además, el servidor 110 puede ofrecer el mismo servicio
obtenido por la misma puerta, por ejemplo la puerta 150, a un grupo
de clientes 120, 122 y 124.
Los servidores pueden ser concurrentes o
iterativos. Los servidores iterativos sólo se ocupan de las
peticiones de un cliente cada vez, mientras que los servidores
concurrentes pueden ocuparse de múltiples peticiones de múltiples
clientes a la vez. En la implementación API de sockets, un servidor
concurrente habitual creará un socket pasivo 130 y lo vinculará a
la puerta 150 de un servicio muy conocido. El socket 130 pasará al
estado de escucha y será capaz de aceptar peticiones para
establecer conexiones socket con otro socket 140 creado por el
cliente 120 y vinculado a la puerta 160, por ejemplo. La puerta 160
no está asociada a un servicio o petición particular, sino que es
una puerta "efímera" que tiene asignado un número de puerto
exclusivo en ese cliente.
Las conexiones socket 180 y 182 indican cómo dos
clientes 122 y 124 con las puertas 162 y 164 pueden conectarse al
servidor 110 utilizando un servicio muy conocido a través de la
puerta 150 por medio de dos sockets 132 y 134 del servidor, ambos
vinculados a la puerta 150, y por medio de dos sockets 142 y 144 de
los dos clientes. Los sockets del servidor 132 y 134 se denominan
sockets activos, porque están activamente conectados a los sockets
de los clientes. En un servidor concurrente, estos dos sockets de
servidor se controlan normalmente en procesos o subprocesos
separados. Cuando un socket pasivo 130 vinculado a una puerta 150
de un servicio muy conocido recibe una petición para establecer
conexiones con un socket de cliente 140, el servidor normalmente
inicia un nuevo proceso o subproceso con un nuevo socket para
proporcionar el servicio, quedando libre para aceptar otras
peticiones de otros clientes. Una vez que la petición del cliente
ha sido atendida, el socket activo entre el cliente y el servidor
es abandonado. Este sistema permite a los servidores concurrentes
prestar servicio a más de un cliente a la vez y en la misma puerta.
Los servidores concurrentes pueden ofrecer también más de un
servicio a la vez creando varios sockets pasivos vinculados a las
puertas más conocidas de los servicios ofrecidos. Normalmente, los
sockets individuales serán tratados en procesos o subprocesos
independientes.
Además, un servidor puede crear dos sockets 136 y
138 vinculados a la puerta 154 de un servicio muy conocido y
conectados a dos sockets 146 y 148 vinculados a dos puertas
efímeras 166 y 168 de un cliente 126. En este caso, las conexiones
socket 184 y 186 se identifican de forma exclusiva, a pesar de que
el mismo cliente ha establecido conexiones con el mismo servidor en
la misma puerta de servidor, porque las puertas efímeras del
cliente 166 y 168 están representadas por números de puerta
exclusivos.
La Figura 4 representa una interacción entre los
sistemas informáticos de un usuario, un proveedor de acceso y un
proveedor de contenido en una implementación de API de sockets. En
esta ilustración, el sistema informático del proveedor de acceso y
el sistema informático del proveedor de contenido están utilizando
un servicio orientado a conexión TCP, tal como el HTTP o el NNTP, y
están diseñados como servidores iterativos. Los recuadros
representan las llamadas a rutina efectuadas por las API de sockets
para llevar a cabo operaciones en los sockets TCP. Los recuadros
que aparecen debajo de columnas diferentes, pero situados en la
misma línea, representan eventos que se producen en sistemas
informáticos diferentes, pero más o menos al mismo tiempo.
En la arquitectura de tres partes, el sistema
informático del proveedor de acceso, que actúa como un servidor
intermediario, crea un socket efectuando una llamada a la rutina
socket() de la línea 1. En la línea 2, el sistema informático del
proveedor de acceso vincula el socket a una puerta. En la línea 3,
el sistema informático del proveedor de acceso pone el socket en
estado de escucha y, en la línea 4, el sistema informático del
proveedor de acceso efectúa una llamada a la rutina aceptar() que
bloquea el proceso hasta que se recibe una petición de conexión.
Hasta este momento, el socket creado por el sistema informático del
proveedor de acceso se halla en estado pasivo, es decir, no ha
establecido ninguna conexión con otro socket.
Análogamente, el sistema informático del
proveedor de contenido crea un socket, lo vincula a una puerta, lo
pone en estado de escucha y efectúa una llamada a la rutina
aceptar() para su propio socket (líneas 1
\hbox{a
4).}
Mientras, el sistema informático del usuario crea
un socket en la línea 5 y llama a la rutina conectar() de la línea
6. El cliente del navegador web puede vincular el socket a una
puerta por sí mismo, pero normalmente deja que lo haga el núcleo
del sistema operativo del sistema informático del usuario, puesto
que el socket debe vincularse a una puerta efímera exclusiva en
cualquier caso. La llamada del usuario a la rutina conectar() trata
de establecer una conexión socket con un servidor de una dirección
IP particular y de una puerta particular que representa un servicio
muy conocido al que el usuario desea acceder.
El programa de cliente del usuario estará
configurado para conectarse al servidor intermediario del proveedor
de acceso. Por ejemplo, con programas de cliente de navegador web,
tales como Netscape Navigator™ o Microsoft Internet Explorer™,
existen normalmente opciones para configurar las direcciones
adecuadas para los servidores intermediario dentro de las
configuraciones de los navegadores.
La llamada del usuario a la rutina conectar()
trata de establecer una conexión con el sistema informático del
proveedor de acceso enviando y recibiendo paquetes de datos
(correspondiente a una conexión en tres pasos). El sistema
informático del usuario envía en primer lugar un indicador
"SYN" (sincronización) TCP al sistema informático del
proveedor de acceso que responde con un indicador SYN propio y un
indicador "ACK" para confirmar el SYN del usuario. Por último,
el sistema informático del usuario responde con un indicador ACK
para confirmar el SYN del proveedor de acceso. El indicador SYN
sirve para sincronizar los números de secuencia de paquetes de datos
mantenidos en el cliente y el servidor. Estos números de secuencia
permiten a las pilas TCP/IP fragmentar los datos que se van a
transmitir en diversos paquetes de datos consecutivos de tamaño
adecuado, y reagruparlos de nuevo después de la transmisión.
Una vez que la conexión en tres pasos ha
concluido, se establece la conexión socket TCP. Cuando el sistema
informático del usuario ha establecido conexiones con el sistema
informático del proveedor de acceso, se produce el regreso de la
llamada a rutina aceptar() del proveedor de acceso, es decir,
termina el bloqueo y continúa la ejecución del proceso. En la línea
7, el sistema informático del usuario envía uno o más paquetes de
datos al sistema informático del proveedor de acceso, por ejemplo,
una petición para obtener una página web del proveedor de
contenido. Esto se consigue a través de una llamada a la rutina
escribir() en el sistema informático del usuario y una llamada a la
rutina leer() en el sistema informático del proveedor de acceso. En
la línea 8, el sistema informático del proveedor de acceso, que
esta vez actúa como cliente intermediario, crea un nuevo socket y,
en la línea 9, trata de conectarlo al sistema informático del
proveedor de contenido de la forma descrita anteriormente. Si la
conexión se establece satisfactoriamente, se produce entonces el
regreso de la llamada a la rutina aceptar() del sistema informático
del proveedor de contenido. Por lo tanto, el sistema informático del
proveedor de acceso tendrá entonces dos sockets conectados
activamente a los sockets del sistema informático del usuario y del
sistema informático del proveedor de contenido.
En la línea 10, el sistema informático del
proveedor de acceso envía los paquetes de datos del usuario, por
ejemplo, la petición de página web, al sistema informático del
proveedor de contenido. En la línea 11, el sistema informático del
proveedor de contenido envía como respuesta uno o más paquetes de
datos al sistema informático del proveedor de acceso, por ejemplo,
la página web solicitada. En la línea 12, el sistema informático
del proveedor de acceso envía los paquetes de datos al sistema
informático del usuario que, por ejemplo, presenta en pantalla la
página web.
En la línea 13, el sistema informático del
usuario y el sistema informático del proveedor de acceso cierran
los sockets y, por consiguiente, terminan la conexión entre éstos
y, en la línea 14, el sistema informático del proveedor de acceso y
el sistema informático del proveedor de contenido cierran los
sockets y terminan la conexión entre éstos. El TCP normalmente
termina las conexiones enviando un indicador "FIN"
(finalización) desde cada extremo de la conexión y un indicador ACK
para confirmar el FIN. A veces, el TCP termina las conexiones
enviando un indicador "RST" (reiniciación) en lugar de un
indicador FIN.
Este procedimiento es el habitual cuando tanto el
proveedor de acceso como el proveedor de contenido son servidores
iterativos en funcionamiento. Cuando los servidores son
concurrentes, se inicia un nuevo proceso después del regreso de la
llamada a la rutina aceptar(), en cada caso. En el nuevo proceso, se
crea un nuevo socket que se conecta al socket del cliente para
proporcionar el servicio al cliente, mientras el socket pasivo
queda libre para aceptar las peticiones de conexiones socket de
otros clientes.
La Figura 4 puede modificarse para representar
las interacciones habituales entre los sistemas informáticos de un
usuario y un proveedor de contenido en la arquitectura de dos
partes descrita anteriormente, eliminando las líneas 8 a 11,
eliminando la columna titulada "Proveedor de contenido" y
cambiando el título de la columna "Proveedor de acceso" por el
de "Proveedor de contenido".
La Figura 4 puede modificarse para representar
las interacciones habituales entre los sistemas informáticos de un
usuario, un proveedor de contenido/acceso y otro proveedor de
contenido de la otra arquitectura definida anteriormente, cambiando
el título de la columna "Proveedor de acceso" por el de
"Proveedor de contenido/acceso" y cerrando entre paréntesis
las líneas 8 a 11 para representar la conexión potencial entre el
sistema informático del proveedor de contenido/acceso y el sistema
informático del otro proveedor de contenido.
En todos los casos, tanto si la arquitectura es
una arquitectura de dos o tres partes como si es la otra
arquitectura, y tanto si los servidores son iterativos como si son
concurrentes, la presente invención se implementa mediante la
adición de ciertas rutinas de programa en un programa servidor.
En la arquitectura de tres partes, se insertan
rutinas en el programa servidor del proveedor de acceso entre las
etapas de las líneas 6 y 7 para registrar los datos relativos al
establecimiento de la conexión con el sistema informático del
usuario, y entre las etapas de las líneas 13 y 14 para registrar los
datos relativos a la terminación de la conexión con el sistema
informático del usuario. Del mismo modo, se insertan rutinas para
registrar datos relativos al establecimiento de una conexión con el
proveedor de contenido entre las etapas de las líneas 9 y 10, y
relativos a la terminación de la conexión con el proveedor de
contenido después de la línea 14, si es necesario.
En la arquitectura de dos partes, pueden
insertarse rutinas igualmente en lugares correspondientes del
programa servidor del proveedor de contenido para registrar los
datos relativos al establecimiento y la terminación de las
conexiones con el sistema informático del usuario.
En la otra arquitectura, pueden insertarse
rutinas igualmente en lugares correspondientes del programa servidor
del proveedor de contenido/acceso para registrar datos relativos al
establecimiento y terminación de las conexiones con el sistema
informático del usuario o el sistema informático del otro proveedor
de contenido.
Se insertan rutinas en los programas servidor
para registrar una diversidad de datos relativos al establecimiento
y la terminación de conexiones socket, tales como el número de
conexiones socket con el sistema informático del usuario
establecidas y terminadas, la fecha y la hora de establecimiento y
terminación de las conexiones con el sistema informático del
usuario y la duración de las conexiones socket con el sistema
informático del usuario. También puede registrarse información
acerca de la dirección IP del sistema informático del usuario y la
dirección IP y el número de puerta, que representan el servicio
proporcionado, del sistema informático del proveedor de contenido.
También puede extraerse y registrarse información de las cabeceras
TCP/IP agregadas al principio de los paquetes de datos
transmitidos. Las rutinas concretas y el número de dichas rutinas
que se insertan dependen de los datos deseados para implementar un
mecanismo de facturación particular.
La Figura 5 representa la distribución temporal
de varias conexiones lógicas de una interacción cliente/servidor de
dos partes habitual entre el navegador del usuario y un servidor
HTTP del proveedor de contenido a través de Internet. Cuando se
utiliza el HTTP versión 1.0, los navegadores tales como Netscape
Navigator crean a veces una serie de conexiones (comúnmente, hasta 4
a la vez) para descargar datos con rapidez. Aquí, por motivos
ilustrativos, el navegador ha creado 8 conexiones en total para
descargar una página web de inicio y 7 imágenes gráficas. Las 8
barras separadas de la Figura 5 representan las 8 conexiones. En la
fila A, la primera conexión se establece entre el navegador y el
servidor HTTP para obtener un archivo de página web de inicio HTTP,
por ejemplo. En este ejemplo, el archivo de página de inicio HTTP
se refiere a 7 fuentes de imágenes gráficas asociadas. Una vez que
se ha enviado el archivo de página de inicio HTTP, la conexión se
termina. Inmediatamente después, el navegador establece 4
conexiones en paralelo en las filas A, B, C y D para descargar los
archivos de imágenes gráficas desde el servidor HTTP. Tras
finalizar la descarga de estos archivos, las conexiones se terminan
de inmediato y se establecen nuevas conexiones para descargar el
resto de imágenes, si es necesario. El sistema informático del
proveedor de contenido supervisa los cambios de estado de estas
conexiones, tal como se ha descrito anteriormente, y registra datos
en respuesta a la supervisión, tal como se describirá en mayor
detalle más adelante.
En la arquitectura de tres partes, el navegador
establece conexiones con el servidor intermediario de un proveedor
de acceso que, a su vez, establece conexiones correspondientes con
el servidor HTTP del proveedor de contenido. Por lo tanto, en este
ejemplo, existirán 16 conexiones en total. El sistema informático
del proveedor de acceso supervisa los cambios de estado de estas
conexiones, de la forma descrita anteriormente, y registra datos en
respuesta a la supervisión, de la forma descrita en mayor detalle
más adelante. En una forma de realización de la presente invención,
el sistema informático del proveedor de acceso supervisa y registra
los datos relativos sólo a las conexiones con el navegador del
usuario, en otra forma de realización, los datos relativos sólo a
las conexiones con el servidor del proveedor de contenido y, en una
última forma de realización, los datos relativos a ambos grupos de
conexiones. La elección de la forma de realización dependerá del
mecanismo de facturación preferido.
En la otra arquitectura, el navegador establece
conexiones con el servidor intermediario de un proveedor de
contenido/acceso que, a su vez, puede (dependiendo de la petición
del usuario) establecer las correspondientes conexiones con el
servidor HTTP de otro proveedor de contenido. El sistema
informático del proveedor de contenido/acceso supervisa los cambios
de estado de estas conexiones, de la forma descrita anteriormente,
y registra datos en respuesta a la supervisión, de la forma descrita
en detalle más adelante. En una forma de realización de la presente
invención, el sistema informático del proveedor de contenido/acceso
supervisa y registra los datos relativos sólo a las conexiones con
el navegador del usuario y, en otra forma de realización, los datos
relativos tanto a las conexiones con el sistema informático del
usuario como a las conexiones con el servidor del otro proveedor de
contenido. La elección de la forma de realización dependerá del
mecanismo de facturación preferido.
El HTTP 1.1, una versión más reciente del HTTP
1.0, difiere del HTTP 1.0 en una serie de aspectos. Un aspecto de
importancia para la presente invención es la inclusión de
conexiones persistentes y de procesamiento segmentado.
El HTTP 1.1 define las conexiones persistentes
como el procedimiento por omisión para las conexiones en las
interacciones cliente/servidor. En lugar de abrir y cerrar una
conexión para cada transacción de petición-respuesta
entre un cliente y un servidor, un cliente o un servidor HTTP 1.1
mantendrá una conexión abierta para diversas transacciones de
petición-respuesta, hasta que el cliente o el
servidor envíe un testigo de "cierre" en la cabecera de
conexión HTTP. Esto indicará, pues, que la transacción de
petición-respuesta va a ser la última para esa
conexión y que, una vez finalizada la transacción, la conexión entre
el cliente y el servidor podrá abandonarse. Tanto el cliente como
el servidor pueden especificar intervalos de espera cuando se
utilizan conexiones persistentes en el HTTP 1.1, para que no se
mantengan conexiones inactivas por un tiempo indefinido.
Las conexiones persistentes HTTP 1.1 también
permiten el procesamiento segmentado de las peticiones y las
respuestas a las peticiones y, por esa razón, el cliente podrá
enviar varias peticiones a un servidor sin tener de esperar a que
llegue la respuesta a cada petición para poder enviar una nueva
petición.
Además, el HTTP 1.1 permite a los clientes y
servidores establecer varias conexiones en paralelo, aunque con
respecto al HTTP 1.0 esto supone pocas ventajas, ya que la
combinación de conexiones persistentes y el procesamiento
segmentado de las peticiones y las respuestas permite de por sí
mejorar el rendimiento de las conexiones. El número de conexiones
persistentes paralelas establecidas entre un cliente y un servidor
en HTTP 1.1 está limitado normalmente a un máximo de dos.
En la arquitectura de tres partes, cuando un
cliente se conecta a un servidor intermediario de un proveedor de
acceso mediante conexiones persistentes HTTP 1.1, y el servidor
intermediario, a su vez, se conecta al servidor de un proveedor de
contenido, el servidor intermediario del proveedor de acceso deberá
utilizar también conexiones persistentes para conectarse con el
servidor del proveedor de contenido.
En la otra arquitectura, cuando un cliente se
conecta a un servidor intermediario de un proveedor de
contenido/acceso mediante conexiones persistentes HTTP 1.1, y el
servidor intermediario, a su vez, se conecta con el servidor de
otro proveedor de contenido, el servidor intermediario del proveedor
de contenido/acceso deberá utilizar también conexiones persistentes
para conectarse con el servidor del otro proveedor de
contenido.
La supervisión de los cambios de estado de las
conexiones persistentes HTTP 1.1 en la arquitectura de dos partes o
de tres partes y en la otra arquitectura se lleva a cabo del mismo
modo que la supervisión de los cambios de estado de las conexiones
HTTP 1.0 descritas anteriormente.
La Figura 6 representa un registro de datos
habitual 220 que puede crearse en relación con una conexión lógica
individual. Los medios de almacenamiento de datos 210 pueden
utilizarse para almacenar dichos registros. Por ejemplo, en el
campo de Internet, el elemento "Identificador de usuario/proveedor
de contenido" representa la dirección IP del sistema informático
del usuario y, en la arquitectura de tres partes, la dirección IP
del sistema informático del proveedor de contenido. El elemento
"Identificador de servicio" representa el número de puerta del
servicio conocido ofrecido por el proveedor de acceso o de
contenido. El elemento "Hora/fecha inicial" representa el
momento en que se ha establecido la conexión lógica y el elemento
"Hora/fecha final" representa el momento en que ha finalizado
la conexión lógica. El elemento "Duración" representa el
período de tiempo durante el cual se ha establecido la conexión
lógica. El elemento "Información obtenida" representa otro tipo
de información que puede obtenerse de los paquetes de datos
enviados y recibidos a través de la conexión lógica. Este elemento
puede incluir, por ejemplo, información acerca del URL (Localizador
uniforme de recursos) de la página solicitada y recibida, el tamaño
de los paquetes de datos y otro tipo de información obtenida de las
cabeceras agregadas al principio de los paquetes de datos, según el
caso.
En otras formas de realización de la presente
invención se registran diversas combinaciones de los elementos
registrables enumerados más arriba.
En una forma de realización en la que se registra
sólo el identificador de usuario, los datos de facturación
generados dependerán simplemente del número de conexiones lógicas
creadas.
En otras formas de realización en las que se
registran otras combinaciones de los elementos registrables, los
datos de facturación generados pueden depender de otros factores,
tales como la duración de las conexiones lógicas, la hora y la
fecha inicial y la hora y la fecha final de dichas conexiones
lógicas y el tipo de servicio ofrecido al usuario. Por ejemplo, en
el campo de Internet, un proveedor de contenido o un proveedor de
acceso tal vez desee aplicar cargos diferentes por el servicio HTTP
y el servicio NNTP.
En una forma de realización, se registra por lo
menos el identificador de usuario, el identificador de servicio, la
hora/fecha inicial o la hora/Fecha final. A partir de estos datos,
es posible deducir la duración de cada conexión lógica. Con estos
datos, podrán generarse cargos basados en la duración total de las
conexiones lógicas y el tipo de servicio proporcionado al usuario,
siendo aplicadas posiblemente diferentes tarifas a diferentes
períodos del día u otros ciclos periódicos.
Además, si se requieren más datos de facturación,
es posible registrar información más detallada, tal como el número
y el tamaño de los paquetes de datos enviados y recibidos, y la
información extraída de las cabeceras agregadas al principio de
dichos paquetes de datos. Por ejemplo, puede extraerse información
de la cabecera IP, la cabecera UDP, la cabecera TCP, la cabecera
HTTP y la cabecera NNTP.
En otra forma de realización de la presente
invención, las rutinas de programa insertadas en el programa
servidor no registran de forma individual datos para cada conexión
lógica, sino que registran datos relativos la duración acumulada de
esas conexiones dentro de un período de tiempo predefinido.
En esta forma de realización, las rutinas
insertadas en el programa servidor entre las etapas de la Figura 4
de las líneas 6, 7, 9 y 10, 13 y 14 y después de la línea 14,
descritas anteriormente, inician y detienen un grupo de
temporizadores mantenidos por el sistema informático cuando se
establecen y terminan las conexiones lógicas, respectivamente. En
el caso en que se establece más de una conexión lógica entre el
sistema informático del usuario y el sistema informático del
proveedor de acceso o de contenido en un período de tiempo
predeterminado, por ejemplo, un período de 24 horas, será necesario
que el sistema informático del proveedor de acceso o de contenido
mantenga una cantidad equivalente de temporizadores. Por ejemplo,
varios sistemas informáticos de usuarios diferentes pueden
establecer conexiones lógicas con el sistema informático del
proveedor de acceso o de contenido y, además, cada sistema
informático de usuario puede establecer más de una conexión lógica
en paralelo con el sistema informático del proveedor de acceso o de
contenido.
Al final del período de tiempo predefinido, el
sistema informático del proveedor de acceso o de contenido creará
un registro de la duración acumulada de todas las conexiones
lógicas establecidas con el sistema informático de un usuario para
cada sistema informático de usuario individual. Por lo tanto, un
registro incluirá dos elementos de información: el identificador de
cliente y la duración acumulada. Al final de cada período de tiempo
predefinido, el sistema informático del proveedor de acceso o de
contenido reiniciará también todos los temporizadores que están
registrando el tiempo actualmente, para que los registros creados
para el siguiente período de tiempo predefinido no incluyan el
tiempo registrado para el final del período de tiempo.
Una de las ventajas de la forma de realización
anterior es que sólo se crea un registro para cada sistema
informático de usuario que establece conexiones lógicas con el
sistema informático del proveedor de acceso o de contenido en el
período de tiempo predefinido. Es probable que este número de
registros sea relativamente más bajo que el de las formas de
realización en las que se crea un registro para cada conexión
lógica establecida entre el sistema informático de cada usuario y
el sistema informático del proveedor de acceso o contenido, como se
ha descrito anteriormente.
Por último, se generarán datos de facturación
basados en los datos registrados por medio de un procesador de
tarifas que procesa los datos registrados, pudiéndose generar
cuentas o facturas, a continuación, por medio de un procesador de
cuentas o facturas.
Como resulta evidente, existen implementaciones
alternativas de la presente invención en las que se registran datos
en respuesta a la supervisión de los cambios de estado de las
conexiones lógicas en la capa de red y de transporte del modelo de
referencia OSI entre un cliente y un servidor, y en las que se
generan, a continuación, datos de facturación basados en los datos
registrados.
Las API de sockets constituyen las API estándar
para diseñar programas de comunicaciones de red de cliente y
servidor para Internet. No obstante, la presente invención puede
aplicarse a otras redes de comunicación de datos, en las que un
proveedor de acceso o un proveedor de contenido desea facturar al
usuario por el acceso. Por consiguiente, otras formas de realización
de la presente invención incluirán la supervisión de las conexiones
lógicas que utilizan el TCP/IP u otros protocolos y son controladas
mediante otras API de comunicaciones de red, incluida la API de
interfaz de capa de transporte (TLI), la API de interfaz de
programación común para comunicaciones (CPI-C) y la
API de conductos con nombre, por ejemplo.
Las comunicaciones que utilizan protocolos
distintos a TCP/IP también pueden ser supervisadas y cargadas
mediante la presente invención. Dichos protocolos distintos
incluyen el protocolo de Intercambio de Paquetes de
Internet/Intercambio Secuenciado de Paquetes (IPX/SPX ) o el
protocolo de aplicación inalámbrica (WAP), por ejemplo.
De todo lo anterior se infiere que la presente
invención proporciona una solución flexible a los problemas de
aplicación correcta de los cargos al usuario de un sistema
informático por el acceso al contenido proporcionado a través de
una red de comunicaciones, ya sea directamente o bien por medio de
un proveedor de acceso. La solución no presenta las desventajas de
la técnica anterior y proporciona un mecanismo para generar datos
de facturación, que es flexible, adecuado al nivel de utilización,
fácil de implementar, de bajo coste en términos de las operaciones
del procesador e invisible para el usuario.
Claims (23)
1. Procedimiento para generar datos de
facturación en relación con el uso de un enlace de red de
comunicaciones destinado a permitir el paso de información entre un
sistema informático (10) utilizado por un usuario y un sistema
informático (20, 30) destinado a proporcionar al usuario un
contenido a través de dicho enlace de red de comunicaciones,
implicando el enlace de red de comunicaciones por lo menos una
relación cliente/servidor que comprende una pluralidad de
conexiones lógicas, y comprendiendo el procedimiento las etapas
siguientes:
detección, en por lo menos una conexión lógica de
dicha relación cliente/servidor, de por lo menos un evento que
ocasiona el cambio de estado de por lo menos una conexión lógica
definida por al menos una dirección de capa de red del cliente, una
dirección de capa de transporte del cliente, una dirección de capa
de red del servidor y una dirección de capa de transporte del
servidor,
registro de los datos (220) creados en respuesta
a dicho por lo menos un evento detectado, y
generación de datos de facturación en base a los
datos registrados,
estando caracterizado el
procedimiento
por:
un sistema informático (20, 30) destinado a
proporcionar al usuario acceso limitado a dicho enlace de
comunicaciones, llevando a cabo las etapas siguientes:
supervisión de los cambios de estado de las
conexiones lógicas entre el sistema informático del usuario (10) y
el sistema informático (20, 30) destinado a proporcionar un
contenido al usuario, siendo proporcionado dicho contenido al
usuario mediante la utilización de las conexiones lógicas, y
creación de los datos (220) cuando la utilización
del enlace de comunicaciones determina que por lo menos una de
dichas conexiones lógicas supervisadas cambie de estado al ser
generada y/o terminada.
2. Procedimiento según la reivindicación 1, en el
que el uso de dicha conexión lógica comprende el uso de una
pluralidad de conexiones socket (180, 182, 184, 186).
3. Procedimiento según la reivindicación 2, en el
que en dicha etapa de registro de datos (220) se determina un
registro del número de todas las conexiones socket establecidas y
terminadas.
4. Procedimiento según la reivindicación 2 ó 3,
en el que dicha pluralidad de conexiones socket (180, 182, 184, 186)
son por lo menos parcialmente contemporáneas y se refieren a la
misma relación cliente/servidor.
5. Procedimiento según cualquiera de las
reivindicaciones 1 a 4, en el que la información se pasa a través
del sistema informático (30) destinado a proporcionar al usuario
acceso al sistema informático (20) destinado a proporcionar
contenido al usuario, y en el que el sistema informático (30) actúa
como cliente intermediario y servidor intermediario.
6. Procedimiento según la reivindicación 5, en el
que los datos de facturación son generados por el sistema
informático que proporciona acceso (30).
7. Procedimiento según la reivindicación 5 ó 6,
en el que una conexión lógica supervisada comprende por lo menos una
conexión socket creada entre el sistema informático (30) destinado
a proporcionar acceso al usuario que actúa como servidor
intermediario y el sistema informático del usuario que actúa como
cliente.
8. Procedimiento según cualquiera de las
reivindicaciones 5 ó 6, en el que una conexión lógica supervisada
comprende por lo menos una conexión socket (180, 182, 184, 186)
creada entre el sistema informático (30) destinado a proporcionar
acceso al usuario que actúa como cliente intermediario, y el sistema
informático (20) destinado a proporcionar contenido al usuario que
actúa como servidor.
9. Procedimiento según la reivindicación 1, en el
que el sistema informático (20, 30) destinado a proporcionar acceso
al usuario comprende el sistema informático (20) destinado a
proporcionar contenido al usuario.
10. Procedimiento según la reivindicación 9, en
el que los datos de facturación son generados por el sistema
informático (20) destinado a proporcionar contenido al usuario.
11. Procedimiento según cualquiera de las
reivindicaciones anteriores, en el que se selecciona por lo menos
una conexión lógica de entre el grupo que consta de: una conexión
socket del protocolo de control de transmisión (180, 182, 184,
186), una conexión socket del protocolo de datagrama del usuario
(180, 182, 184, 186) y una conexión socket del protocolo Internet
(180, 182, 184, 186).
12. Procedimiento según cualquiera de las
reivindicaciones anteriores, en el que los datos registrados
comprenden un registro de información extraído de por lo menos una
cabecera agregada al principio de la información que se pasa entre
el sistema informático (20) destinado a proporcionar contenido al
usuario y el sistema informático (10) del usuario durante la
subsistencia de la pluralidad de conexiones lógicas.
13. Procedimiento según la reivindicación 16, en
el que se selecciona por lo menos una cabecera de entre el grupo
que consta de:
todas las cabeceras de la capa de red del
protocolo de control de transmisión/protocolo Internet, todas las
cabeceras de la capa de transporte TCP/IP y todas las cabeceras de
la capa de aplicación TCP/IP.
14. Procedimiento según cualquiera de las
reivindicaciones anteriores, en el que el enlace de red de
comunicaciones comprende un enlace de red de comunicaciones
activado permanentemente.
15. Aparato destinado a llevar a cabo un
procedimiento para generar datos de facturación en relación con la
utilización de un enlace de red de comunicaciones destinado a
permitir el paso de información entre un sistema informático (10)
utilizado por un usuario y un sistema informático (20, 30) destinado
a proporcionar un contenido al usuario a través de dicho enlace de
red de comunicaciones, incluyendo el enlace de red de
comunicaciones por lo menos una relación cliente/servidor que
comprende una pluralidad de conexiones lógicas, comprendiendo dicho
aparato:
medios informáticos para detectar, en por lo
menos una conexión lógica de dicha relación cliente/servidor, por
lo menos un evento que ocasiona un cambio en el estado de por lo
menos una conexión lógica definida por al menos una dirección de
capa de red del cliente, una dirección de capa de transporte del
cliente, una dirección de capa de red del servidor y una dirección
de capa de transporte del servidor,
medios de almacenamiento para registrar los datos
creados en respuesta a dicho por lo menos un evento detectado,
y
medios para generar datos de facturación en base
a los datos registrados,
estando caracterizado el
aparato porque comprende
además:
un sistema informático (20, 30) destinado a
proporcionar a dicho usuario el acceso al enlace de comunicaciones,
que incluye:
medios para supervisar los cambios de estado de
las conexiones lógicas entre el sistema informático del usuario
(10) y el sistema informático (20, 30) destinado a proporcionar un
contenido al usuario, siendo proporcionado dicho contenido al
usuario mediante la utilización de las conexiones lógicas; y
medios para crear los datos (220) cuando la
utilización del enlace de comunicaciones determina que por lo menos
una de dichas conexiones lógicas supervisadas cambie de estado al
ser generada y/o terminada.
16. Aparato según la reivindicación 15, en el que
dichos datos de facturación se generan a partir de los datos
registrados, basándose en la cantidad de tiempo para la cual se ha
establecido dicha por lo menos una conexión lógica que comprende
una conexión socket (180, 182, 184 y 186).
17. Aparato según la reivindicación 16, en el que
el sistema informático destinado a proporcionar acceso al usuario
actúa como servidor intermediario y como cliente intermediario y
está destinado a permitir el paso de información entre el sistema
informático del proveedor de contenido (20) y el sistema
informático (20) del usuario.
18. Aparato según cualquiera de las
reivindicaciones 16 ó 17, en el que se selecciona por lo menos una
conexión lógica de entre el grupo que consta de: una conexión
socket del protocolo de control de transmisión (180, 182, 184 y
186), una conexión socket del protocolo de datagrama del usuario
(180, 182, 184 y 186) y una conexión socket del protocolo Internet
(180, 182, 184 y 186).
19. Aparato según cualquiera de las
reivindicaciones 17 y 18, en el que los datos registrados
comprenden además un registro de información extraída de por lo
menos una cabecera agregada al principio de la información que se
pasa entre el sistema informático (20) destinado a proporcionar
contenido al usuario y el sistema informático (10) del usuario
durante la subsistencia de las conexiones.
20. Aparato según la reivindicación 19, en el que
dicha por lo menos una cabecera comprende por lo menos una cabecera
seleccionada de entre el grupo que consta de: todas las cabeceras
de capa de red del protocolo de control de transmisión/protocolo
Internet, todas las cabeceras de capa de transporte TCP/IP y todas
las cabeceras de la capa de aplicación TCP/IP.
21. Aparato según cualquiera de las
reivindicaciones 15 a 20, en el que el enlace de red de
comunicaciones comprende un enlace de red de comunicaciones
activado permanentemente.
22. Programa servidor destinado a implementar las
etapas de un procedimiento según cualquiera de las reivindicaciones
1 a 14.
23. Procedimiento según cualquiera de las
reivindicaciones 1 a 14, en el que dicho contenido se transmite en
paquetes de datos.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9900920 | 1999-01-15 | ||
| GB9900920 | 1999-01-15 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2245932T3 true ES2245932T3 (es) | 2006-02-01 |
Family
ID=10845983
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00900277T Expired - Lifetime ES2245932T3 (es) | 1999-01-15 | 2000-01-13 | Procedimiento y aparato para generar datos para facturar a un usuario el acceso a traves de un enlace de red de comunicaciones. |
Country Status (8)
| Country | Link |
|---|---|
| EP (2) | EP1142195B1 (es) |
| JP (1) | JP2002535879A (es) |
| AT (1) | ATE300819T1 (es) |
| AU (1) | AU1994000A (es) |
| DE (1) | DE60021522T2 (es) |
| ES (1) | ES2245932T3 (es) |
| HK (1) | HK1043001A1 (es) |
| WO (1) | WO2000042735A1 (es) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AUPQ774000A0 (en) * | 2000-05-24 | 2000-06-15 | Telstra R & D Management Pty Ltd | A monitoring system |
| GB2364484B (en) * | 2000-06-30 | 2004-10-13 | Nokia Mobile Phones Ltd | Apparatus and methods for a client server system |
| US20020059090A1 (en) * | 2000-11-10 | 2002-05-16 | Noriyuki Yanagimachi | Working state administration system, job state administration system and working-job state administration system |
| FI112426B (fi) * | 2001-03-23 | 2003-11-28 | Nixu Oy | Välityspalvelin sisältöpalvelua varten |
| GB2387064B (en) * | 2002-03-26 | 2004-06-16 | Motorola Inc | Method and system for construction and communication of data on network access and service transactions in a telecommunication network |
| CN1540547A (zh) * | 2003-10-27 | 2004-10-27 | �Ϻ���ŵ���簲ȫ������չ�ɷ����� | 一种网络游戏接入控制与计费方法 |
| JP4746072B2 (ja) * | 2008-05-07 | 2011-08-10 | 富士通株式会社 | 課金システム |
| US8719780B2 (en) * | 2010-06-29 | 2014-05-06 | Oracle International Corporation | Application server with a protocol-neutral programming model for developing telecommunications-based applications |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5862335A (en) * | 1993-04-01 | 1999-01-19 | Intel Corp. | Method and apparatus for monitoring file transfers and logical connections in a computer network |
| FI103164B1 (fi) * | 1996-11-06 | 1999-04-30 | Ericsson Telefon Ab L M | Järjestelmä ja menetelmä palvelun käyttöönottamiseksi |
| US6104704A (en) * | 1997-03-20 | 2000-08-15 | At&T Corp. | Methods and apparatus for gathering and processing billing information for internet telephony |
-
2000
- 2000-01-13 DE DE60021522T patent/DE60021522T2/de not_active Expired - Lifetime
- 2000-01-13 AT AT00900277T patent/ATE300819T1/de not_active IP Right Cessation
- 2000-01-13 WO PCT/GB2000/000080 patent/WO2000042735A1/en not_active Ceased
- 2000-01-13 ES ES00900277T patent/ES2245932T3/es not_active Expired - Lifetime
- 2000-01-13 EP EP00900277A patent/EP1142195B1/en not_active Expired - Lifetime
- 2000-01-13 EP EP05076013A patent/EP1580956A2/en not_active Withdrawn
- 2000-01-13 AU AU19940/00A patent/AU1994000A/en not_active Abandoned
- 2000-01-13 JP JP2000594221A patent/JP2002535879A/ja active Pending
- 2000-01-13 HK HK02102412.4A patent/HK1043001A1/zh unknown
Also Published As
| Publication number | Publication date |
|---|---|
| EP1142195A1 (en) | 2001-10-10 |
| JP2002535879A (ja) | 2002-10-22 |
| WO2000042735A1 (en) | 2000-07-20 |
| DE60021522D1 (de) | 2005-09-01 |
| EP1142195B1 (en) | 2005-07-27 |
| EP1580956A2 (en) | 2005-09-28 |
| DE60021522T2 (de) | 2006-05-24 |
| AU1994000A (en) | 2000-08-01 |
| HK1043001A1 (zh) | 2002-08-30 |
| ATE300819T1 (de) | 2005-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FI113224B (fi) | Laskutuksen toteuttaminen tietoliikennejärjestelmässä | |
| US7254562B2 (en) | Rule-based packet selection, storage, and access method and system | |
| Cerf et al. | Issues in packet-network interconnection | |
| US6574335B1 (en) | Method for simulating a ring back for a call between parties in different communication networks | |
| US6836805B1 (en) | Scheduled alias resolution | |
| US6577718B1 (en) | Method for call forwarding without hairpinning and with split billing | |
| EP1718011A2 (en) | System for multi-layer provisioning in computer networks | |
| CN101110847B (zh) | 一种获取介质访问控制地址的方法、系统及装置 | |
| US20120137366A1 (en) | Techniques for network protection based on subscriber-aware application proxies | |
| KR20000069024A (ko) | 통신 시스템 아키텍쳐 | |
| JP2005507126A (ja) | 情報ネットワークを通じてのデータパケットの伝送を制御するためのシステム及び方法 | |
| KR20010006455A (ko) | 교환 전화 통신용 시스템, 방법 및 그 제조물 | |
| EP1493246B1 (en) | Monitoring of information in a network environment | |
| ES2245932T3 (es) | Procedimiento y aparato para generar datos para facturar a un usuario el acceso a traves de un enlace de red de comunicaciones. | |
| Calvert et al. | Lightweight network support for scalable end-to-end services | |
| CN101809982B (zh) | 互联网协议多媒体子系统中的呼叫计费和计费信息路由 | |
| KR20040055635A (ko) | 트래픽 흐름 관리 방법 및 그 장치와 트래픽 관리 디지털가입자 라인 액세스 멀티플렉서 | |
| US7353405B2 (en) | Method and systems for sharing network access capacities across internet service providers | |
| Hjalmtysson et al. | Control-on-demand: An efficient approach to router programmability | |
| Rybczynski et al. | Datapac X. 25 service characteristics | |
| CN1627697A (zh) | 一种流量计费方法 | |
| JP2001244961A (ja) | 電子私書箱方式 | |
| Mahmud | Improving Internet access in the UMMC-A Nadi it innovation | |
| JP3776366B2 (ja) | 複数フローから構成されるコンテンツ配信サービス向けゲートウェイ装置 | |
| JP2002525979A (ja) | データ接続を確立するための接続ユニットおよび方法 |