ES2298429T3 - Sistema y metodo de facturacion en una red de comunicaciones y un servidor de facturacion de una red de comunicaciones. - Google Patents
Sistema y metodo de facturacion en una red de comunicaciones y un servidor de facturacion de una red de comunicaciones. Download PDFInfo
- Publication number
- ES2298429T3 ES2298429T3 ES02800816T ES02800816T ES2298429T3 ES 2298429 T3 ES2298429 T3 ES 2298429T3 ES 02800816 T ES02800816 T ES 02800816T ES 02800816 T ES02800816 T ES 02800816T ES 2298429 T3 ES2298429 T3 ES 2298429T3
- Authority
- ES
- Spain
- Prior art keywords
- billing
- service
- server
- amount
- protocol
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/141—Indication of costs
- H04L12/1414—Indication of costs in real-time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/141—Indication of costs
- H04L12/1421—Indication of expected costs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1432—Metric aspects
- H04L12/1439—Metric aspects time-based
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/28—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP with meter at substation or with calculation of charges at terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/28—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP with meter at substation or with calculation of charges at terminal
- H04M15/30—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP with meter at substation or with calculation of charges at terminal the meter or calculation of charges not being controlled from an exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/31—Distributed metering or calculation of charges
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/43—Billing software details
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/67—Transmitting arrangements for sending billing related information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/70—Administration or customization aspects; Counter-checking correct charges
- H04M15/775—Account specifications on parallel communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/82—Criteria or parameters used for performing billing operations
- H04M15/8228—Session based
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/83—Notification aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/83—Notification aspects
- H04M15/85—Notification aspects characterised by the type of condition triggering a notification
- H04M15/854—Available credit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/90—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/016—Billing using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/22—Bandwidth or usage-sensitve billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/48—Sending information over a non-traffic network channel or another connection than the one actually used, e.g. signalling, D-channel, data and voice
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/72—Account specifications
- H04M2215/7277—Account specifications on parallel communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/78—Metric aspects
- H04M2215/7833—Session based
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
- H04M2215/815—Notification when a specific condition, service or event is met
- H04M2215/8166—Available credit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/82—Advice-of-Charge [AOC], i.e. notify subscriber of charges/cumulative charge; meter at the substation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/92—Autonomous calculations of charges in terminal, i.e. meter not controlled from exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/96—Distributed calculation of charges, e.g. in different nodes like for mobiles between HLR and VLR, or between the terminal and the billing function
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13097—Numbering, addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13098—Mobile subscriber
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/1313—Metering, billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13345—Intelligent networks, SCP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13384—Inter-PBX traffic, PBX networks, e.g. corporate networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13399—Virtual channel/circuits
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- Development Economics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Meter Arrangements (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Telephonic Communication Services (AREA)
Abstract
Un sistema de facturación en una red de comunicaciones, que comprende un servicio IN (1) asociado con la red para proporcionar servicios a los abonados asociados con la red, caracterizado porque el sistema comprende un servidor (2) de facturación adaptado para gestionar información de la cuenta del abonado, dicho servicio IN (1) está adaptado para enviar un primer mensaje de petición de facturación para un servicio, al servidor (2) de facturación antes de proporcionar el servicio, utilizando un protocolo (3) de facturación en línea, dicho servidor (2) de facturación está adaptado para efectuar la pre-reserva de una cantidad de recursos en la cuenta del abonado, dependiendo dicha cantidad de la cantidad solicitada incluida en dicho mensaje; y para devolver un mensaje de respuesta que incluye información que indica si la cantidad de recursos está pre-reservada en dicha cuenta de abonado, para permitir el uso de dicho servicio al servicio IN (1), utilizando dicho protocolo (3) de facturación en línea.
Description
Sistema y método de facturación en una red de
comunicaciones y un servidor de facturación de una red de
comunicaciones.
La presente invención está relacionada en
general con redes de comunicaciones y, más específicamente, con un
sistema y un método de facturación en una red de comunicaciones, y
con un servidor de facturación de una red de comunicaciones.
En las redes de comunicaciones actuales, es
decir, en las redes de telecomunicaciones y en las redes de
comunicaciones de datos, no existen mecanismos del protocolo de
facturación en tiempo real, sobre los cuales un cliente que
proporcione servicios al abonado fuera capaz de efectuar un cargo en
la cuenta de un abonado que resida en un servidor de facturación,
basándose en los cargos calculados por el cliente.
Los mecanismos actuales del protocolo de
facturación en tiempo real no permiten a ningún cliente solicitar al
servidor de facturación evaluar un evento (o eventos) de servicios y
devolver el número de eventos que se permite proporcionar al
abonado.
Más aún, los mecanismos actuales del protocolo
de facturación en tiempo real no permiten a ningún cliente informar
al abonado, antes y después de la ejecución del Evento de Servicios,
sobre la cantidad monetaria a utilizar.
La nueva generación de redes especifica (por
ejemplo, los requisitos de Cargos y Facturación 3G) los requisitos
más críticos para las aplicaciones de Contabilidad (Sistemas de
Facturación) de las redes de comunicaciones. La aplicación de
Contabilidad debe ser capaz de evaluar en tiempo real la información
de Contabilidad. Por ejemplo, el entorno de servicios procesa la
información del evento de servicio, que ha de ser evaluado antes o
durante la entrega/ejecución del servicio.
Existen también requisitos sobre el control de
crédito del usuario final de la nueva generación de redes de
comunicaciones. La aplicación de Contabilidad debe ser capaz de
comprobar la cuenta del usuario final para cubrir los cargos del
Evento de Servicio solicitado, antes de la ejecución de ese evento
de servicio. Todos los eventos facturables relacionados con una
cuenta específica deben ser excluidos al usuario final cuando la
cuenta se ha agotado o ha expirado.
En las redes de la siguiente generación, el
número de servicios ofrecidos al usuario final y el número de
entidades que entregan estos servicios a los usuarios finales
crecerán. Para cumplir con todos estos nuevos requisitos, se
necesitan nuevos tipos de mecanismos para la facturación en una red
de comunicaciones de datos, que darán soporte a la comunicación
entre las aplicaciones/servidores de Control de Crédito y el entorno
de servicios.
Un problema particular surge con relación a los
servicios de las redes inteligentes (IN), tales como las llamadas a
precio especial, la Red Móvil Privada Virtual (VPN), los cargos por
Prepago y el Número Personal. Como el prepago es normalmente un
servicio IN por sí mismo, no es conveniente proporcionar el prepago
de otros servicios IN para los abonados. Para proporcionar el
prepago en otros servicios IN, la funcionalidad de prepago ha de
estar integrada con el otro servicio IN particular en un sistema de
comunicaciones de la técnica anterior. Por tanto, cada servicio IN
ha de ser rediseñado con la funcionalidad de prepago añadida, para
ser capaz de ofrecer el servicio como prepago.
El documento WO 00 05871 A1 divulga un sistema
de prepago y un método para permitir a un abonado de prepago del
sistema de telecomunicaciones inalámbricas revisar las
características de la llamada durante una llamada dentro del nodo
del operador, y desde los lugares de itinerancia para efectuar un
cargo en la cuenta de prepago del abonado, sobre la base de tiempo
real. El sistema incluye un nodo de conmutación que permite
establecer una llamada con el abonado de prepago cuando existe un
saldo positivo del servicio de prepago, y finalizar la llamada
cuando el saldo positivo del servicio de prepago es cero. El nodo de
conmutación genera continuamente mensajes formateados por el Gestor
de Mensajes de Datos (DMH) del evento de llamada en tiempo real,
relacionados con la llamada hecha por el abonado de prepago, y
reenvía estos mensajes de eventos de llamada a una red
administrativa de prepago. La red administrativa de prepago
almacena el saldo positivo del servicio de prepago del abonado de
prepago y genera en el establecimiento de la llamada una cantidad
inicial de adeudo del cargo utilizado durante la llamada para
reducir el saldo positivo del servicio de prepago. La red
administrativa de prepago, como respuesta a los mensajes del evento
de la llamada en tiempo real, recibidos desde los medios de
generación del evento de la llamada detallado, revisa la cantidad
inicial de adeudo del cargo para generar una cantidad de adeudo en
tiempo real, utilizada durante la llamada para reducir el saldo
positivo del servicio de prepago.
El documento US 2001 021 647 A divulga un método
de facturación de la tarifa de llamadas especiales, que comprende
los pasos de (a) hacer que un dispositivo de intercambio reciba una
señal de origen de la llamada desde una unidad de terminal del
abonado que origina la llamada; (b) hacer que el dispositivo de
intercambio solicite de un servidor especial de facturación si la
unidad de terminal de abonado es una unidad de terminal de abonado
de facturación especial; (c) hacer que el servidor de facturación
especial conteste al dispositivo de intercambio si la unidad de
terminal de abonado que originó la llamada es una unidad de terminal
de abonado con facturación especial; y (d) si la unidad de terminal
que originó la llamada es una unidad de terminal de llamada con
facturación especial, como resultado del paso (c), hacer que el
dispositivo de intercambio notifique a un servidor de facturación
general que a la unidad de terminal de abonado que originó la
llamada se le carga una tarifa de facturación especial.
El documento WO 98 59504 A1 divulga un punto de
control que administra un servicio de Facturación Aconsejada (AoC)
proporcionado a abonados de móviles. El punto de control es
informado de cada llamada que implique una estación móvil que esté
abonada al servicio de Facturación Aconsejada. El punto de control
determina uno o más parámetros del servicio AoC para la llamada, y
los envía a un nodo de conmutación que da servicio actualmente a la
estación móvil. La estación móvil recibe los parámetros del AoC
desde el nodo de conmutación que da el servicio y determina el coste
previsto asociado con la llamada, y presenta ese coste al abonado de
móviles. Los costes acumulados para esa llamada pueden ser
determinados y presentados también durante la llamada.
Es un objeto de la presente invención superar o
al menos mitigar las desventajas de la técnica anterior. La presente
invención proporciona un sistema y un método para facturar en una
red de comunicaciones y un servidor de facturación de una red de
comunicaciones.
De acuerdo con un primer aspecto de la presente
invención, se proporciona un sistema para facturación en una red de
comunicaciones, que comprende un servicio IN asociado con la red,
para proporcionar servicios a los abonados asociados con la red. El
sistema comprende además un servidor de facturación adaptado para
gestionar la información de la cuenta del abonado, donde el servicio
IN está adaptado para enviar un primer mensaje de solicitud de
facturación para un servicio, al servidor de facturación, antes de
proporcionar el servicio, utilizando un protocolo de facturación en
línea, estando adaptado el servidor de facturación para efectuar
una pre-reserva de una cantidad de recursos en la
cuente del abonado, dependiendo dicha cantidad de la cantidad
solicitada incluida en dicho mensaje; y para devolver un mensaje de
respuesta que incluye la información que indica si se hace la
pre-reserva de una cantidad de recursos en dicha
cuenta del abonado, para permitir la utilización de dicho servicio a
dicho servicio IN, utilizando dicho protocolo de facturación en
línea.
De acuerdo con un segundo aspecto de la presente
invención, se proporciona un método para facturación en una red de
comunicaciones que comprende un servicio IN asociado con la red,
para proporcionar servicios a los abonados asociados con la red, y
un servidor de facturación que tiene la información de la cuenta del
abonado y que está adaptado para gestionar la información de la
cuenta del abonado. El método está caracterizado por los pasos
de:
el envío desde dicho servicio IN de un primer
mensaje de solicitud de facturación para un servicio, al servidor
de facturación, antes de proporcionar el servicio, utilizando el
protocolo de facturación en línea,
efectuar por dicho servidor de facturación la
pre-reserva de una cantidad de recursos desde la
cuenta del abonado, donde dicha cantidad depende de la cantidad
solicitada incluida en dicho mensaje; y devolver un mensaje de
respuesta que incluye información que indica si la cantidad de
recursos está pre-reservada en dicha cuenta de
abonado, para permitir la utilización de dicho servicio al servicio
IN, utilizando dicho protocolo de facturación en línea.
De acuerdo con un tercer aspecto de la presente
invención, se proporciona un servidor de facturación para facturar
la utilización del servicio en una red de comunicaciones. El
servidor de facturación está caracterizado porque el servidor (2)
de facturación está adaptado para:
gestionar la información de la cuenta del
abonado;
recibir un primer mensaje de solicitud de
facturación para un servicio desde un servicio IN, antes de que el
servicio sea proporcionado, utilizando un protocolo de facturación
en línea, y
efectuar una pre-reserva de una
cantidad de recursos en la cuenta del abonado, dependiendo dicha
cantidad de la cantidad solicitada incluida en dicho mensaje sobre
dicho servicio, y devolver un mensaje de respuesta que incluye
información que indica si la cantidad de recursos está
pre-reservada en dicha cuenta de abonado, para
permitir la utilización de dicho servicio al servicio IN, utilizando
dicho protocolo de facturación en línea.
Las ventajas de la presente invención son que
cualquier red de cliente puede adeudar en la cuenta del abonado
especificado en el servidor de facturación, cualquier cliente puede
utilizar el servidor de facturación para evaluar el evento (o
eventos) del servicio sin conocimiento sobre el precio real y el
control de cuántos de esos eventos de servicio pueden ser
suministrados al usuario, y el cliente puede proporcionar una
estimación de coste a los abonados, antes de la ejecución del
servicio y un coste final de la utilización del servicio después de
la ejecución del servicio. Otra ventaja es que los servicios de red
inteligente (IN) pueden ser proporcionados con las tarifas de
prepago sin rediseñar por completo el servicio IN. Por tanto, cada
servicio IN no necesita ser rediseñado con la funcionalidad de
prepago añadida de ser capaz de ofrecer el servicio como
prepago.
Para una mejor comprensión de la presente
invención, y con el fin de mostrar cómo se puede llevar a efecto el
mismo, se hará referencia ahora los dibujos que se acompañan, en los
cuales:
La figura 1 ilustra el sistema de facturación en
una red de comunicaciones, de acuerdo con la presente invención,
La figura 2 ilustra la secuencia de mensajes
para el cargo en cuenta de unidades monetarias en el sistema de
facturación en una red de comunicaciones, de acuerdo con la presente
invención,
La figura 3 ilustra la secuencia de mensajes
para tarificar los eventos de servicios en el sistema de facturación
en una red de comunicaciones, de acuerdo con la presente
invención,
La figura 4 ilustra la secuencia de mensajes
para la estimación de costes para la facturación, en una red de
comunicaciones, de acuerdo con la presente invención,
La figura 5 ilustra un diagrama de bloques del
sistema de facturación, en una red de comunicaciones, de acuerdo
con la presente invención,
La figura 6 ilustra otro modo de realización del
sistema de la figura 1, y
La figura 7 ilustra la secuencia de mensajes
para el cargo en cuenta en el sistema de facturación en una red de
comunicaciones de la figura 6.
La solución de acuerdo con la presente invención
presenta un nuevo mecanismo para la facturación en una red de
comunicaciones. Este nuevo mecanismo de facturación permite a
cualquier red de cliente adeudar en la cuenta del abonado
especificado en un Servidor de Facturación en Línea. la cantidad
monetaria a adeudar está determinada por el cliente.
En el nuevo mecanismo de facturación, de acuerdo
con la presente invención, un cliente de la red puede utilizar el
servidor de facturación para tarificar el evento del servicio o
eventos del servicio, sin conocer el precio real y el control de
cuántos de esos eventos de servicio pueden ser proporcionados al
abonado. En el nuevo mecanismo de facturación de acuerdo con la
presente invención, el cliente puede proporcionar además al usuario
una estimación del coste antes de la ejecución del servicio, y el
coste final después de la ejecución del servicio.
La figura 1 ilustra el sistema de facturación en
una red de comunicaciones, de acuerdo con la presente invención. En
el sistema de facturación de acuerdo con la presente invención, hay
un cliente 1 que proporciona servicios al abonado y un servidor de
facturación o servidor 2 de control de facturación que tiene la
información de la cuenta del abonado. El cliente 1 y el servidor 2
de facturación se comunican utilizando el Protocolo 3 de
Facturación en Línea. El Protocolo 3 de Facturación en Línea es un
protocolo bidireccional que admite la facturación en tiempo real. La
facturación en tiempo real supone cargar en cuenta lo que se efectúa
como parte de los servicios que se han prestado. Preferiblemente,
el Protocolo 3 de Facturación en Línea está basado en un protocolo
IP, tal como el protocolo Diameter. Alternativamente, el Protocolo
de Facturación en Línea esta basado en el protocolo Parlay, en el
protocolo INAP CS1 o en SS7.
La figura 2 ilustra la secuencia de mensajes
para el cargo en cuenta de las unidades monetarias en el sistema de
facturación de una red de comunicaciones, de acuerdo con la presente
invención. El cliente puede reservar dinero para que un abonado
utilice servicios a facturar de manera controlada por el cliente 1,
enviando un mensaje de Petición de Cargo 4 al servidor 2 de
facturación. Un mensaje alternativo de Petición de Cargo está
marcado con la referencia numérica 6.
En la petición de cargo 4, 6, el abonado al que
se va a hacer el cargo está identificado por un Identificador de
Abonado específico, por ejemplo el IMSI, el MSISDN, la dirección IP
o el SIP_URL. El cliente 1 indica cuánto dinero quiere reservar
para utilizar los servicios controlados por él (Cantidad Monetaria
Reservada). El cliente 1 puede indicar también al servidor 2 de
facturación la duración esperada durante la cual se va a consumir la
cantidad monetaria (Duración de la Reserva). El servidor 2 de
facturación utiliza los parámetros del mensaje de la Petición de
Cargo 4, 6 para determinar cómo debe responder a la petición 4,
6.
El servidor 2 de facturación determina entonces,
incluso independientemente del valor solicitado por el cliente 1, la
cantidad monetaria a reservar en la cuenta del abonado. La cantidad
puede ser, por ejemplo, un valor predeterminado independiente del
valor solicitado. Por ejemplo, la cantidad puede igual al valor
solicitado en el caso de que haya suficiente dinero en la cuenta. De
igual manera, la cantidad puede ser menor que lo solicitado en el
caso en que no haya dinero suficiente en la cuenta del abonado, o en
el caso en que el abonado no sea fiable.
También puede ser que el cliente 1 no indique
una cantidad monetaria solicitada en la Petición de Cargo 4, 6. En
este caso, el servidor 2 de facturación necesita determinar la
cantidad monetaria a reservar, basándose en otros parámetros del
mensaje, tales como el servicio utilizado, por ejemplo la
Información del Evento del Servicio, tal como la hora, el volumen de
datos, los eventos específicos del servicio (por ejemplo, descargas
de páginas web, solicitudes de horarias, etc.) y dinero, de la
Petición de Cargo 4, 6, o basándose en los parámetros de
configuración en el servidor 2 de facturación. El servidor 2 de
facturación devuelve la cantidad monetaria reservada en un mensaje
de Respuesta del Cargo 5, al cliente 1. Un mensaje alternativo de
Respuesta al Cargo está marcado con la referencia numérica 7.
El servidor 2 de facturación determina también
la duración permitida a utilizar para el consumo de la cantidad
monetaria reservada. La duración puede ser un valor predeterminado
independiente del valor solicitado. Por ejemplo, la duración puede
ser mayor que el valor solicitado en caso de señalización de
problemas de capacidad, o la duración puede ser menor que lo que se
ha solicitado en caso de que el abonado no sea fiable.
En el caso en que el cliente 1 no indique una
Duración de la Reserva solicitada, el servidor 2 de facturación
necesita determinar la duración a reservar, basándose en otros
parámetros del mensaje de la Petición de Cargo 4, 6, o basándose en
los parámetros de configuración en el servidor 2 de facturación. El
servidor 2 de facturación devuelve la duración de la reserva en un
mensaje de Respuesta del Cargo 5, 7 al cliente 1.
El servidor 2 de facturación puede elegir
también no poner ningún tiempo límite en la utilización de la
cantidad monetaria, en cuyo caso no envía la Duración de la Reserva
como parámetro del mensaje. El servidor 2 de facturación puede
indicar también en el mensaje de Cargo 5, 7 al cliente 1, que la
reserva no ha tenido éxito, por ejemplo en el caso de que la cuenta
del abonado esté totalmente agotada.
Cuando la Respuesta del Cargo 5, 7 indique que
se ha reservado con éxito la cantidad monetaria, el cliente 1
permitirá al abonado iniciar las transacciones facturables en la red
del cliente. Cuando el abonado ha gastado toda la cantidad
monetaria reservada por el servidor 2 de facturación, el cliente 1
vuelve a solicitar más dinero del servidor 2 de facturación
enviando una nueva Petición de Cargo 6.
En el caso de que no se haya gastado la cantidad
monetaria reservada por el servidor 2 de cargo al expirar el tiempo
de reserva asignado por el servidor 2 de facturación, el cliente 1
contacta con el servidor 2 de facturación y efectúa una nueva
Petición de Cargo 6 que indica cuánto dinero se utilizó realmente
por el abonado (Cantidad Monetaria Utilizada). El nuevo mensaje de
Petición de Cargo 6 puede incluir también una petición de más
dinero.
Cuando el servidor 2 de facturación recibe el
conocimiento del dinero utilizado por el abonado, devuelve la
cantidad monetarias reservada inicialmente a la cuenta, y deduce de
la cuenta la cantidad monetaria utilizada. Después, el servidor 2
de facturación comienza a reservar la cantidad monetaria siguiente
en la cuenta. Si en el mensaje no se recibe el conocimiento del
dinero utilizado por el abonado, el servidor 2 de facturación
deduce la cantidad basándose en la cantidad reservada en la
recepción de la Petición de Cargo 4, 6, anterior.
En el caso de que la petición inicial 4 de
reserva no haya tenido éxito, el cliente 1 determinará si desea
volver a intentar la reserva, por ejemplo, con un valor menor de las
Unidades Monetarias Reservadas. El servidor 2 de facturación puede
ofrecer al cliente 1 alguna pista para determinar lo que puede hacer
en el caso de una reserva sin éxito. La sesión de facturación entre
el cliente y el Servidor de Facturación puede ser finalizada por el
cliente 1, de acuerdo con las instrucciones desde el servidor 2 de
facturación (Cerrar la Sesión de Facturación).
El servidor 2 de facturación incluye en cada
Respuesta del Cargo 5, 7, el coste acumulado (Coste Acumulado) para
la sesión de facturación. El mensaje final 5, 7 de respuesta incluye
también el coste total de la sesión de facturación.
La figura 3 ilustra la secuencia de mensajes
para tarificar eventos de servicio en el sistema de facturación de
una red de comunicaciones, de acuerdo con la presente invención. El
cliente 1 puede solicitar tarifas de eventos de servicio y reservar
dinero para que un abonado utilice el servicio mediante el envío de
un primer mensaje de Petición de Cargo 8 al servidor de facturación.
Se marca un segundo mensaje de Petición de Cargo con la referencia
numérica 10.
En la Petición de Cargo 8, 10, el abonado a
facturar está identificado por un identificador específico de
abonado, por ejemplo el IMSI, el MSISDN o el SIP_URL. El cliente 1
indica el tipo de evento del servicio (Información del Evento del
Servicio) y el número (Número de Eventos) de tales eventos, que
desea que sean tarificados. El cliente 1 puede indicar también al
servidor 2 de facturación la que es duración esperada, durante la
cual se van a consumir los eventos de servicio (Duración de la
Reserva). El servidor 2 de facturación utiliza los parámetros del
mensaje de la Petición de Cargo 8, 10, para determinar cómo debe
responder a la petición 8, 10.
El servidor 2 de facturación tarifica entonces
el servicio solicitado utilizando la información del evento del
servicio y el número de la información solicitada, y reserva la
correspondiente cantidad de dinero en la cuenta del abonado.
El servidor 2 de facturación determina entonces,
incluso independientemente del número de eventos solicitados por el
cliente 1, el número de eventos que están garantizados para ser
utilizados por el abonado. El número de eventos puede ser, por
ejemplo, un valor predeterminado independiente del valor solicitado.
Por ejemplo, el número de eventos puede ser igual al valor
solicitado por ejemplo en el caso de que haya suficiente dinero en
la cuenta. De igual manera, el número de eventos puede ser inferior
al solicitado en el caso de que no haya suficiente dinero en la
cuenta del abonado, o en el caso de que el abonado no sea
fiable.
El servidor 2 de facturación devuelve el número
de eventos que están garantizados para utilización del abonado, en
un mensaje de Respuesta del Cargo 9, al cliente 1. Un mensaje
alternativo de Respuesta del Cargo está marcado con la referencia
numérica 11.
El servidor 2 de facturación determina también
la duración permitida a utilizar para el consumo de la cantidad
monetaria reservada. La duración puede ser un valor predeterminado
independiente del valor solicitado. Por ejemplo, la duración puede
ser mayor que el valor solicitado en el caso de problemas de
capacidad de señalización, o la duración puede ser menos que la
solicitada en el caso de que el abonado no sea fiable.
En el caso de que el cliente 1 no indique la
Duración de la Reserva solicitada, el servidor 2 de facturación
necesita determinar la duración a reservar, basándose en otros
parámetros del mensaje, por ejemplo la Información de Eventos de
Servicio de la Petición de Cargo 8, 10, o basándose en los
parámetros de configuración del servidor 2 de facturación. El
servidor 2 de facturación devuelve la duración de la reserva en un
mensaje de Respuesta al Cargo 9, 11, al
cliente 1.
cliente 1.
Alternativamente, el Servidor de Facturación no
pone ningún límite de la duración en el uso de número de eventos
garantizados, en cuyo caso no envía la Duración de la Reserva como
parámetro del mensaje.
El servidor 2 de facturación puede elegir
también no poner límite en el uso de eventos con número
garantizados, en cuyo caso no envía la Duración de la Reserva como
parámetro del mensaje. El servidor 2 de facturación puede indicar
también en el mensaje de Respuesta al Cargo 9, 11, al cliente 1, que
la reserva no ha tenido éxito, por ejemplo, en el caso de que la
cuenta del abonado esté totalmente agotada.
Cuando la Respuesta al Cargo 9, 11, indique que
la tarificación del evento del servicio y la reserva de una cantidad
monetaria ha tenido éxito, el cliente 1 permite al abonado iniciar
transacciones facturables en la red del cliente. Una vez que el
abonado ha gastado todos los eventos garantizados reservados por el
servidor 2 de facturación, el cliente 1 vuelve a solicitar más
eventos de servicio del servidor 2 de facturación, enviando una
nueva Petición de Cargo 8, 10.
En el caso de no se haya gastado el número
garantizado de eventos reservados por el servidor 2 de facturación,
al expirar el tiempo de reserva asignado por el servidor 2 de
facturación, el cliente 1 entra en contacto con el servidor 2 de
facturación con una nueva Petición de Cargo 10, que indica cuántos
eventos fueron realmente utilizados por el abonado (Número de
Eventos de Servicio Utilizados). El nuevo mensaje de Petición de
Cargo 10 puede incluir también una petición de más eventos.
Cuando el servidor 2 de facturación recibe el
conocimiento de los eventos de servicio utilizados por el abonado,
devuelve a la cuenta la cantidad reservada inicialmente, es decir,
cancela la reserva, y deduce de la cuenta una cantidad monetarias
igual al número de eventos de servicio utilizado. De ahí en
adelante, el servidor 2 de facturación tarifica la nueva petición de
eventos de servicio y comienza a reservar la cantidad
correspondiente en la cuenta. Si en el mensaje no se recibe el
conocimiento sobre los eventos de servicio utilizados por el
abonado, el servidor 2 de facturación deduce la cantidad basada en
la cantidad ya reservada.
En el caso de que la petición 8 de reserva
inicial no tenga éxito, el cliente 1 determinará si desea volver a
intentar la reserva, por ejemplo con un número de eventos menor. El
servidor 2 de facturación puede dar alguna pista al cliente 1 para
determinar lo que debe hacer en el caso de una reserva sin éxito. La
sesión de facturación entre el cliente y el Servidor de Facturación
puede ser finalizada por el cliente 1, de acuerdo con las
instrucciones recibidas desde el servidor 2 de facturación (Cierre
de la Sesión de Facturación).
El servidor 2 de facturación incluye en cada
Respuesta de Cargo 9, 11 el coste acumulado (Coste Acumulado) para
la sesión de facturación. El mensaje 9 de respuesta final incluye
también el coste total de la sesión de facturación.
La figura 4 ilustra la secuencia de mensajes
para la estimación de costes para la facturación en una red de
comunicaciones, de acuerdo con la presente invención. El cliente 1
puede solicitar el precio del evento de servicios (Indicación de
Solicitud de Precios) antes de la ejecución del servicio, enviando
un mensaje de Petición de Cargo 12 al servidor 2 de facturación.
Al utilizar la información de eventos de
servicio y el número de la información solicitada, el servidor 2 de
facturación calcula el precio del servicio solicitado. El servidor 2
de facturación no efectúa ninguna comprobación del saldo de la
cuenta ni el ajuste de la cuenta. El servidor 2 de facturación
devuelve al cliente 1 la indicación de precio calculado en un
mensaje de Respuesta al Cargo 13. El cliente 1 puede informar
entonces al abonado el coste del servicio solicitado.
La figura 5 ilustra un diagrama de bloques del
sistema de facturación en una red de comunicaciones, de acuerdo con
la presente invención. En el sistema de facturación de acuerdo con
la presente invención, hay un Elemento 14 de Servicio/Red y
Consumidores 15, 16 de Servicios. El Elemento 14 de Servicio/Red
puede ser un Elemento 14 de Servicio que proporciona Servicios a los
Consumidores 15, 16 de Servicios o un Elemento 14 de Red que
permite a los Consumidores 15, 16 de Servicios acceder a la
utilización de la red.
\newpage
En el sistema de facturación de acuerdo con la
presente invención, hay también un Servidor 17 de Control de
Crédito. Antes de proporcionar el servicio, el Elemento 14 de
Servicio/red entra en contacto con el Servidor 17 de Control de
Crédito utilizando el Protocolo 18 de Control de Crédito con la
información de Eventos de Servicio incluida (como se ha descrito en
las figuras 1-4 anteriores). El Servidor 17 de
Control de Crédito, dependiendo de la información de Eventos de
Servicio y según lo define esta información, efectúa la tarificación
del Evento de Servicio, asigna un precio al Evento de Servicio,
comprueba el crédito y hace la pre-reserva.
En el sistema de facturación de acuerdo con la
presente invención, hay también un Servidor 19 de Contabilidad. El
Servidor 19 de Contabilidad es un servidor que gestiona la
contabilidad de diferentes eventos y servicios en la red del
cliente.
El Elemento 14 de Servicio/Red puede entregar
alternativamente la Información de Eventos de Servicio al Servidor
19 de Contabilidad, utilizando el Protocolo 20 de Contabilidad,
pudiendo este Servidor 19 de Contabilidad entrar en contacto con el
Servidor 17 de Control de Crédito. El Servidor 17 de Control de
Crédito y el Servidor 19 de Contabilidad son entidades lógicas. Una
implementación de configuración puede contener el Servidor 17 de
Control de Crédito y el Servidor 19 de Contabilidad formando un solo
ordenador central o servidor de facturación.
Cuando el Consumidor 15, 16 de Servicios
solicita un servicio, la petición es reenviada a un Elemento 14 de
Servicio/Red en el dominio doméstico, que es el mismo dominio
administrativo, en el cual está situado el Servidor 17 de Control
de Crédito del Consumidor 15, 16 de Servicios.
A continuación el Elemento 14 de Servicio/Red
autoriza al Consumidor 15, 16 de Servicios y envía una petición al
Servidor 17 de Control de Crédito. El Elemento 14 de Servicio/red
puede obtener la información de autorización de un servidor de
autorización. El servidor de autorización puede enviar también al
Elemento 14 de Servicio/Red instrucciones y datos de identificación
relativos al Protocolo 18 de Control de Crédito y al Protocolo 20
de Contabilidad.
El sistema de facturación en una red de
comunicaciones, de acuerdo con la presente invención, tiene dos
escenarios principales de servicios;
- un evento de una sola vez que se utiliza para
la petición de precios y control de créditos, y
- diversas preguntas que se utilizan para el
control de crédito basado en la sesión.
El evento de una sola vez se utiliza cuando el
Elemento 14 de Servicio/Red desea conocer el coste del Evento de
Servicios sin reserva de crédito. Puede ser utilizado también para
un control de crédito cuando ha tenido lugar el evento de una sola
vez en el entorno de servicios. Podrían existir servicios ofrecidos
por los proveedores de Servicios de Aplicaciones, cuyos precios no
son conocidos en el Elemento de Servicio/Red. El Usuario Final
podría desear saber también el precio exacto de un Evento de
Servicio antes de solicitar el Evento de Servicio.
Tras una petición 12 del cliente, el Servidor 17
de Control de Crédito calcula el coste del Evento de Servicio
solicitado, pero no efectúa ninguna comprobación del saldo de la
cuenta ni reserva del crédito en la cuenta. El precio del Evento
del Servicio solicitado es devuelto al Elemento 14 de Servicio/Red
con el mensaje 13 de respuesta.
Hay ciertos eventos de una sola vez para los
cuales la ejecución del servicio siempre tiene éxito en el entorno
de servicios. En estos casos, el Elemento 14 de Servicio/Red puede
utilizar el escenario de eventos de una sola vez para el Control
del Crédito real. El Elemento 14 de Servicio/Red envía un mensaje 4,
8 de petición de control de crédito al Servidor 17 de Control de
Crédito, antes de que el Elemento 14 de Servicio/Red permita el
Evento del Servicio al Consumidor 15, 16 de Servicios.
El Servidor 17 de Control de Crédito tarifica el
Evento de Servicio y deduce la cantidad monetaria correspondiente de
la cuenta del Consumidor 15, 16 de Servicios, y devuelve un mensaje
5, 9 de respuesta de control del crédito al Elemento 14 de
Servicio/Red.
En un Control de Crédito basado en la sesión,
hay diversas preguntas: la pregunta primera, la intermedia y la
final. El Elemento 14 de Servicio/Red envía un mensaje 4, 8 de la
primera pregunta al Servidor 17 de Control de Crédito antes de que
el Elemento 14 de Servicio/Red permita el Evento de Servicio al
Consumidor 15, 16 de Servicios.
El Servidor 17 de Control de Crédito tarifica el
Evento de Servicio y deduce la correspondiente cantidad monetaria de
la cuenta del Consumidor 15, 16 de Servicios, y devuelve un mensaje
5, 9 de respuesta de control de crédito al Elemento 14 de
Servicio/Red. El tipo de unidades de servicio concedidas puede ser
el tiempo, el volumen, el evento o el dinero, dependiendo del tipo
de Evento de Servicio.
La pregunta intermedia puede ser enviada como
sigue. Cuando el Consumidor 15, 16 de Servicios ha gastado todas las
unidades de servicio concedidas, el Elemento 14 de Servicio/Red
envía una nueva petición 6, 10 al Servidor 17 de Control de
Crédito. El servidor 17 de Control de Crédito tarifica el Evento de
Servicio y deduce la correspondiente cantidad monetaria de la cuenta
del Consumidor 15, 16 de Servicios, y devuelve un mensaje 7, 11 de
respuesta de control de crédito al Elemento 14 de Servicio/Red como
en la primera pregunta. Puede haber varias preguntas intermedias
dentro de una sesión.
Cuando el Consumidor 15, 16 de Servicios
finaliza el Evento de Servicio o cuando se han utilizado todas las
unidades concedidas, el Elemento 14 de Servicio/Red envía un mensaje
de Pregunta Final 6, 10 al Servidor 17 de Control de Crédito. Tras
la pregunta final, el Servidor 17 de Control de Crédito reembolsa la
cantidad de crédito reservada que no se ha utilizado a la cuenta del
Consumidor 15, 16 de Servicios, deduce de la cuenta la cantidad
monetaria utilizada y devuelve un mensaje 7, 11 de contestación.
La solución de acuerdo con la presente invención
propone un nuevo mecanismo de protocolo, por medio del cual un
cliente es capaz de cargar cierta cantidad de unidades monetarias
para el evento (o eventos) particulares que tienen lugar en la red
(com/servicio/multimedia) bajo el control del servidor de
facturación. La cantidad monetaria a cargar está determinada por el
cliente, el cual envía una petición de cargo al servidor que
mantiene la base de datos de las cuentas. El servidor reserva el
dinero en la cuenta y asigna una duración durante la cual se ha de
consumir el dinero o se ha de volver a contactar el servidor. Se
devuelve un mensaje de retorno al cliente. Cuando el abonado ha
gastado el dinero reservado, el cliente solicita del servidor que
retire la cantidad monetaria de la cuenta.
En la solución del nuevo mecanismo de protocolo,
de acuerdo con la presente invención, un cliente es capaz de
solicitar al Servidor de Facturación (servidor que mantiene una base
de datos de las cuentas) que tarifique un evento (o eventos) de
servicio particular que tiene lugar en la red
(com/servicio/multimedia), bajo el control del cliente. El servidor
reserva en la cuenta el dinero de acuerdo con la tarificación
resultante y asigna el número de eventos y la duración durante la
cual han de utilizarse los eventos o ha de volverse a contactar con
el servidor. Se devuelve un mensaje de retorno al cliente. Cuando el
abonado ha utilizado los eventos de servicio, el cliente solicita
del servidor que retire la cantidad monetaria de la cuenta.
En la solución del nuevo mecanismo de protocolo,
de acuerdo con la presente invención, un cliente es capaz de
proporcionar un mecanismo para calcular el coste total del evento (o
eventos) de servicio durante una sesión de servicio particular, de
acuerdo con la información proporcionada al Servidor de Facturación.
Esta solución aborda la posibilidad de devolver una estimación del
coste para el evento (o eventos) de servicio antes de que se ejecute
el evento (o eventos) de servicio, y el coste final exacto tras la
ejecución del evento (o eventos) de servicio para el abonado
servido. Este coste puede ser indicado en dinero.
La solución del nuevo mecanismo de protocolo, de
acuerdo con la presente invención, mejorará los sistemas de
facturación existentes al permitir el cargo en cuenta basado en los
cargos calculados por la red que lo inquiere. El mecanismo de
facturación presentado puede ser aplicado, por ejemplo, a la
facturación en línea de eventos que tienen lugar en la Red de
Servicios y en la Red Multimedia de IP. Sin embargo, obsérvese que
la solución no está restringida a esas redes, sino que el cliente
puede existir en cualquier red.
La solución del nuevo mecanismo de protocolo, de
acuerdo con la presente invención, mejorará también los sistemas de
facturación existentes al permitir la tarificación del servicio
basada en la información del evento de servicio recibida desde la
Red de Servicio o la red multimedia de IP o alguna otra red. La
solución del nuevo mecanismo de protocolo, de acuerdo con la
presente invención, mejorará aún más los sistemas de facturación
existentes al permitir proporcionar la estimación de coste antes de
la ejecución del servicio y el coste final después de la ejecución
del servicio.
En otro modo de realización de la invención
ilustrado en la figura 6, el sistema incluye una red inteligente IN
con una red de señalización, que efectúa la conmutación de mensajes
entre elementos de la red. En este modo de realización de la
invención, un tipo específico de protocolo de señalización, la Parte
de Aplicación de Camel (CAP) 21 para el GSM/UMTS, es utilizado como
portador para el intercambio de mensajes de información y
transporta muchos tipos de elementos de información que son útiles
para los servicios de redes inteligentes. Sin embargo, CAMEL es
solamente un ejemplo y el protocolo de señalización puede estar
basado en otro protocolo, tal como el Protocolo de Internet (IP),
el sistema 7 de señalización (SS7), la Parte de Aplicaciones de IN
(INAP) para redes fijas - donde CAP e INAP son transportados sobre
SS7/C7/SIGTRAN. Además, la red inteligente incluye una función de
conmutación de servicios (SSF) 22, que está situada normalmente en
el (G)MSC 23 de los sistemas GSM. La SSF 22 detecta eventos
que indican una llamada que requiere IN y, tras este
desencadenamiento, suspende el proceso de la llamada y comienza una
serie de transacciones con una función de control de servicios SCF
24. En este modo de realización, el SCF 24 está situado en un SCP
(Punto de Control del Servicio) 25, que gestiona los servicios IN,
es decir, los clientes 1, 14, tal como las llamadas de Tarifa
Especial, la Red Privada Virtual Móvil (VPN), facturación Prepago y
Número Personal. Con el fin de proporcionar la facturación de
prepago en los servicios IN, el servidor de facturación está
adaptado para gestionar la tarificación y facturación en línea. En
este modo de realización, el servidor de facturación es un CCN (Nodo
de Control de Facturación) 22. Por tanto, un servicio IN del SCP 25
envía datos de facturación al CCN 26, a través de otro modo de
realización 27 del protocolo de facturación en línea, de acuerdo con
la invención.
Un mensaje de petición de facturación desde el
SCP 25 al CCN 26 incluye un parámetro de servicio IN y un parámetro
de información del servicio IN. El parámetro de servicio IN
identifica el servicio IN y la información del servicio IN se
utiliza para distinguir entre el uso diferente del mismo servicio
IN, por ejemplo las llamadas en la red y fuera de la red en
VPN.
Otros mensajes desde el CCN 26 al SCP 25,
incluyen también parámetros para gestionar el control de llamadas y
la conexión de comunicaciones del usuario final, es decir, la parte
IN del servicio de prepago, con relación al estado de la cuenta
recibido desde el CCN 26. Un parámetro de estado de la cuenta tiene
distintos valores para transportar el estado de la cuenta del
abonado hacia el SCP 25. En este modo de realización, los distintos
valores son activo, supervisado o excluido. El activo implica que la
cuenta puede ser adeudada; el supervisado implica que la cuenta
puede ser adeudada pero que hay advertencias, por ejemplo que la
cuenta va a ser excluida pronto, y excluida implica que la cuenta no
puede ser adeudada.
Además, es necesario que el servicio IN sea
capaz de gestionar el control de llamadas y la comunicación del
usuario final con relación a la cantidad disponible en la cuenta,
que recibiría desde el CCN 26. Un parámetro de valor de la cuenta
tiene distintos valores para transportar la cantidad disponible de
la cuenta del abonado al SCP 25.
En este modo de realización, los distintos
valores son grande, mediano y pequeño. Estos valores implican que la
cuenta tiene fondos que cubrirán más que la duración o volumen de lo
normalmente asignado, cubrirá solamente la duración o volumen
asignado, o bien no cubrirá la duración o volumen normalmente
asignado, respectivamente.
La figura 7 ilustra una secuencia de mensajes
para adeudar en cuenta en el sistema de facturación de la red de
comunicaciones de la figura 6. Cuando se inicia una llamada VPN
desde un abonado, el MSC 23 notifica que la IN solamente debe ser
invocada para la llamada y el SSF 22 envía un DP inicial para
invocar el SCP 25 en el paso 28. El SCP 25 invoca el servicio IN
solicitado, es decir, el VPN en este ejemplo, y envía una petición
de tarificación al CCN 26 en el paso 29. El CCN 26 comprueba la
cuenta y notifica que el abonado necesita ser advertido sobre una
cuenta con saldo bajo y devuelve el resultado al SCP 25 en el paso
30. En el paso 31, el SCP 25 comprueba el resultado y notifica que
el abonado debe ser advertido, donde el SCP 25 instruye al SSF 22
para que se conecte a una SRF (función de tarificación del servicio)
22'. Además, el SCP 25 instruye a la SRF 22' para que reproduzca un
aviso al abonado en el paso 32. Cuando la llamada ha sido
desconectada, el SCP 25 requiere un informe desde la SSF 22 en el
paso 33. En el paso 34 siguiente, el SCP 25 instruye a la SSF 22
para que conecte la llamada VPN. Se conecta la llamada y se continúa
en el paso 35. Cuando la llamada ha sido desconectada, la SSF 22
informa al SCP 25 de la desconexión y vuelve a reproducir el informe
solicitado en el paso 36. El SCP 25 invoca el servicio IN y envía
una petición de facturación al CCN 26 a través del protocolo 27 de
facturación en línea en el paso 37. El CCN tarifica la llamada y
efectúa el cargo en la cuenta, tras lo cual devuelve el resultado
al SCP 25 en el paso 38. La desconexión continúa cuando el SCP 25
instruye a la SSF 22 que lo haga en el paso 39.
Claims (38)
1. Un sistema de facturación en una red de
comunicaciones, que comprende un servicio IN (1) asociado con la
red para proporcionar servicios a los abonados asociados con la red,
caracterizado porque
el sistema comprende un servidor (2) de
facturación adaptado para gestionar información de la cuenta del
abonado,
dicho servicio IN (1) está adaptado para enviar
un primer mensaje de petición de facturación para un servicio, al
servidor (2) de facturación antes de proporcionar el servicio,
utilizando un protocolo (3) de facturación en línea,
dicho servidor (2) de facturación está adaptado
para efectuar la pre-reserva de una cantidad de
recursos en la cuenta del abonado, dependiendo dicha cantidad de la
cantidad solicitada incluida en dicho mensaje; y para devolver un
mensaje de respuesta que incluye información que indica si la
cantidad de recursos está pre-reservada en dicha
cuenta de abonado, para permitir el uso de dicho servicio al
servicio IN (1), utilizando dicho protocolo (3) de facturación en
línea.
2. Un sistema de facturación, según la
reivindicación 1,
caracterizado porque el servicio IN (1,
14) está adaptado para enviar un segundo mensaje (6, 10) de petición
de facturación al servidor (2, 17) de facturación, utilizando dicho
protocolo (3, 18) de facturación en línea, incluyendo dicho mensaje
(6, 10) de petición la cantidad de recursos utilizados por el
abonado,
el servidor (2, 17) de facturación está adaptado
para deducir de la cuenta del abonado la cantidad de recursos
utilizados por el abonado, y para devolver un mensaje (7, 11) de
respuesta al servicio IN (1, 14), utilizando dicho protocolo (3, 18)
de facturación en línea, donde el mensaje (7, 11) de respuesta
incluye la cantidad de recursos utilizados para la utilización de
dicho servicio.
3. Un sistema de facturación, según la
reivindicación 1 o 2, caracterizado porque dicho primer
mensaje de petición de facturación incluye la identificación del
abonado y un valor de la cantidad de recursos solicitados.
4. Un sistema de facturación, según cualquiera
de las reivindicaciones precedentes, caracterizado porque
dicho primer mensaje de petición de facturación incluye la duración
permitida para el consumo de los recursos reservados.
5. Un sistema de facturación, según cualquiera
de las reivindicaciones precedentes, caracterizado porque el
primer mensaje de petición de facturación expresa la cantidad
requerida de recursos como un valor monetario, y porque el mensaje
de respuesta de facturación expresa la cantidad monetaria reservada
como valor monetario.
6. Un sistema de facturación, según cualquiera
de las reivindicaciones 1-4, caracterizado
porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como un número de eventos de
servicios,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicios, y
el mensaje de respuesta de facturación expresa
la cantidad pre-reservada como número de eventos de
servicios reservados.
7. Un sistema de facturación, según cualquiera
de las reivindicaciones 1-4, caracterizado
porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como tiempo de duración del
servicio,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicios, y
el mensaje de respuesta de facturación expresa
la cantidad pre-reservada como tiempo de duración
del servicio reservado.
8. Un sistema de facturación, según cualquiera
de las reivindicaciones 1-4, caracterizado
porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como volumen de la transferencia de
datos,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicios, y
el mensaje de respuesta de facturación expresa
la cantidad pre-reservada como volumen reservado de
la transferencia de datos.
9. Un sistema de facturación, según cualquiera
de las reivindicaciones precedentes, caracterizado porque el
protocolo (3) de facturación en línea está basado en el protocolo
Diameter.
10. Un sistema de facturación, según cualquiera
de las reivindicaciones 1-8, caracterizado
porque el protocolo (3) de facturación en línea está basado en el
protocolo Parlay.
11. Un sistema de facturación, según cualquiera
de las reivindicaciones 1-8, caracterizado
porque el protocolo (3) de facturación en línea está basado en el
protocolo SS7.
12. Un sistema de facturación, según cualquiera
de las reivindicaciones 1 - 8, caracterizado porque el
protocolo (3) de facturación en línea está basado en el protocolo
INAP CS1.
13. Un sistema de facturación, según la
reivindicación 12, en el que el servicio IN es una llamada de Tarifa
Especial, una llamada de la Red Privada Virtual Móvil (VPN), una
facturación de Prepago o un Número Personal.
14. Un sistema de facturación, según cualquiera
de las reivindicaciones precedentes, caracterizado porque
dicho servidor (2) de facturación está adaptado
para tarificar el servicio y devolver un mensaje (13) de respuesta
al servicio IN (1), utilizando un protocolo (3), (18), de
facturación en línea, incluyendo dicho mensaje (13) de respuesta la
indicación (o indicaciones) de precio del servicio solicitado.
15. Un método para facturar en una red de
comunicaciones, que comprende un servicio IN (1, 14) asociado con la
red, para proporcionar servicios a los abonados asociados con la
red, y un servidor (2, 17) de facturación que tiene información de
la cuenta del abonado, y que está adaptado para gestionar la
información de la cuenta del abonado, caracterizado por los
pasos de:
el envío por dicho servicio IN (1, 14) de un
primer mensaje de petición de facturación para un servicio, al
servidor (2, 17) de facturación, antes de proporcionar el servicio,
utilizando un protocolo (3, 18) de facturación en línea,
la realización de una
pre-reserva por dicho servidor (2, 17) de
facturación de una cantidad de recursos en la cuenta del abonado,
donde dicha cantidad depende de la cantidad solicitada incluida en
dicho mensaje; y devolver un mensaje de respuesta que incluye la
información que indica si se ha pre-reservado una
cantidad de recursos en dicha cuenta de abonado, para permitir el
uso de dicho servicio al servicio IN (1, 14), utilizando dicho
protocolo (3, 18) de facturación en línea.
16. Un método según la reivindicación 15,
caracterizado por los pasos adicionales de:
el envío por dicho servicio IN (1, 14) de un
segundo mensaje (6, 10) de petición de facturación al servidor (2,
17) de facturación, utilizando dicho protocolo (3, 18) de
facturación en línea, donde dicho mensaje (6, 10) de petición
incluye la cantidad de recursos utilizados por el abonado,
la deducción en la cuenta del abonado por parte
del servidor (2, 17) de facturación de la cantidad de recursos
utilizados por el abonado, y devolver un mensaje (7, 11) de
respuesta al servicio IN (1, 14) utilizando dicho protocolo (3, 18)
de facturación en línea, donde el mensaje (7, 11) de respuesta
incluye la cantidad de recursos utilizados para la utilización de
dicho servicio.
17. Un método según la reivindicación 15 o 16,
caracterizado porque dicho primer mensaje de petición de
facturación incluye la duración permitida para el consumo de los
recursos reservados.
18. Un método según cualquiera de las
reivindicaciones 15-17, caracterizado porque
el mensaje (4, 8) de petición de facturación expresa el valor
solicitado como valor monetario, y porque el mensaje (5, 9) de
respuesta de facturación expresa la cantidad monetaria reservada
como valor monetario.
19. Un método según cualquiera de las
reivindicaciones 15-17, caracterizado porque
el mensaje (4, 8) de petición de facturación expresa la cantidad
solicitada como número de eventos de servicio, y porque el mensaje
(5, 9) de respuesta de la facturación expresa la cantidad
pre-reservada, como el número de eventos de servicio
reservados.
20. Un método según cualquiera de las
reivindicaciones 15-17, caracterizado porque
el mensaje (4, 8) de petición de facturación expresa la cantidad
solicitada como duración del tiempo del servicio, y porque el
mensaje (5, 9) de respuesta de la facturación expresa la cantidad
pre-reservada, como el tiempo de duración del
servicio reservado.
21. Un método según cualquiera de las
reivindicaciones 15-17, caracterizado porque
el mensaje (4, 8) de petición de facturación expresa la cantidad
solicitada como volumen de la transferencia de datos, y porque el
mensaje (5, 9) de respuesta de la facturación expresa la cantidad
pre-reservada, como volumen de la transferencia de
datos.
22. Un método, según la reivindicación 15,
caracterizado por el paso adicional de: deducción en la
cuenta por el servidor (2, 17) de facturación de la cantidad de
recursos reservados.
23. Un método, según la reivindicación 22, en el
que el servicio IN es una llamada de Tarifa Especial, una llamada
de la Red Privada Virtual Móvil (VPN), una facturación de Prepago o
un Número Personal.
24. Un método, según cualquiera de las
reivindicaciones 15-23, caracterizado por los
pasos de:
enviar por parte de dicho servicio IN (1) un
mensaje de petición de facturación de un servicio, al servidor (2)
de facturación, antes de que se proporcione el servicio, utilizando
el protocolo (3) de facturación en línea,
tarificar el servicio por parte de dicho
servidor (2) de facturación, y devolver un mensaje (13) de respuesta
al servicio IN (1), utilizando un protocolo (3, 18) de facturación
en línea, donde dicho mensaje (13) de respuesta incluye la
indicación de precio del servicio solicitado.
25. Un método, según la reivindicación 24,
caracterizado porque el mensaje (12) de petición de
facturación expresa una petición del precio de un evento (o eventos)
de servicio, y porque el mensaje (13) de petición de facturación
expresa solamente indicaciones de precio del evento (o eventos) de
servicio solicitado.
26. Un servidor de facturación para facturar la
utilización de un servicio en una red de telecomunicaciones,
caracterizado porque
el servidor (2) de facturación está adaptado
para:
gestionar la información de la cuenta del
abonado,
recibir un primer mensaje de petición de
facturación para un servicio desde un servicio IN (1), antes de
proporcionar el servicio, utilizando un protocolo (3) de
facturación en línea, y
efectuar una pre-reserva de una
cantidad de recursos en la cuenta del abonado, dependiendo dicha
cantidad de una cantidad solicitada incluida en dicho mensaje, sobre
dicho servicio, y devolver un mensaje de respuesta que incluye
información que indica si se ha pre-reservado una
cantidad de recursos en dicha cuenta de abonado, para permitir el
uso de dicho servicio al servicio IN (1), utilizando dicho protocolo
(3) de facturación en línea.
27. Un servidor de facturación, según la
reivindicación 26, caracterizado porque el servidor (2, 17)
de facturación está adaptado para:
recibir un segundo mensaje (6, 10) de petición
de facturación desde el servicio IN (1, 14), utilizando dicho
protocolo (3, 18) de facturación en línea, incluyendo dicho mensaje
(6), (10) de petición la cantidad de recursos utilizados por el
abonado,
deducir de la cuenta del abonado la cantidad de
recursos utilizados por el abonado, y devolver un mensaje (7, 11) de
respuesta al servicio IN (1, 14) utilizando dicho protocolo (3, 18)
de facturación en línea, donde el mensaje (7, 11) de respuesta
incluye la cantidad de recursos utilizados para la utilización de
dicho servicio.
28. Un servidor de facturación, según la
reivindicación 26 o 27, caracterizado porque dicho primer
mensaje de petición de facturación incluye la identificación del
abonado y un valor de la cantidad de recursos solicitados.
29. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-28, caracterizado
porque dicho primer mensaje de petición de facturación incluye la
duración permitida del consumo de recursos reservados.
30. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-29, caracterizado
porque el primer mensaje de petición de facturación expresa la
cantidad solicitada de recursos como valor monetario, y porque el
mensaje de respuesta de la facturación expresa la cantidad monetaria
reservada, como valor monetario.
31. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-29, caracterizado
porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como un número de eventos de
servicio,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicio, y
el mensaje de respuesta de la facturación
expresa la cantidad pre-reservada como un número de
eventos de servicio reservados.
32. Un servidor de facturación, según
cualquiera de las reivindicaciones 26-29,
caracterizado porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como duración del tiempo de
servicio,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicio, y
el mensaje de respuesta de la facturación
expresa la cantidad pre-reservada como tiempo de
duración del servicio reservado.
\newpage
33. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-29, caracterizado
porque
el primer mensaje de petición de facturación
expresa la cantidad solicitada como volumen de la transferencia de
datos,
el servidor (2) de facturación está adaptado
para tarificar los eventos de servicio, y
el mensaje de respuesta de la facturación
expresa la cantidad pre-reservada como volumen
reservado para la transferencia de datos.
34. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-33, caracterizado
porque el servicio IN (1) es un elemento (14) de servicio/red y
porque el servidor (2) de facturación es un servidor (17) de
control de crédito, donde el servidor (17) de control de crédito
está adaptado para efectuar la comprobación del crédito y la
pre-reserva.
35. Un servidor de facturación según la
reivindicación 34, caracterizado porque el servidor (17) de
control de crédito está adaptado para efectuar la tarificación del
servicio.
36. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-35, caracterizado
porque el protocolo (3) de facturación en línea está basado en el
protocolo Diameter, el protocolo Parlay, el protocolo SS7 o el
protocolo INAP CS1.
37. Un servidor de facturación, según cualquiera
de las reivindicaciones 26-36, caracterizado
porque
el servidor (2) de facturación está adaptado
para:
gestionar la información de la cuenta del
abonado,
recibir un mensaje de petición de facturación
para un servicio, desde un servicio IN (1), antes de proporcionar
el servicio, utilizando un protocolo (3) de facturación en línea,
y
tarificar el servicio y devolver un mensaje (13)
de respuesta al servicio IN (1), utilizando el protocolo (3), (18)
de facturación en línea, incluyendo dicho mensaje (13) de respuesta
las indicaciones de precio del servicio solicitado.
38. Un servidor de facturación, según la
reivindicación 37, en el que el servicio IN es una llamada de Tarifa
Especial, una llamada de la Red Privada Virtual Móvil (VPN), una
facturación de Prepago o un Número Personal.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20011955A FI20011955A0 (fi) | 2001-10-08 | 2001-10-08 | Järjestelmä ja menetelmä veloittamiseksi tietoliikenneverkossa ja tietoliikenneverkon veloituspalvelin |
| FI20011955 | 2001-10-08 | ||
| FI20012023A FI20012023A0 (fi) | 2001-10-18 | 2001-10-18 | Järjestelmä ja menetelmä veloittamiseksi viestintäverkossa ja viestintäverkon veloituspalvelin |
| FI20012023 | 2001-10-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2298429T3 true ES2298429T3 (es) | 2008-05-16 |
Family
ID=26161222
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02800816T Expired - Lifetime ES2298429T3 (es) | 2001-10-08 | 2002-10-08 | Sistema y metodo de facturacion en una red de comunicaciones y un servidor de facturacion de una red de comunicaciones. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US8090652B2 (es) |
| EP (1) | EP1435182B1 (es) |
| CN (1) | CN1608387B (es) |
| AT (1) | ATE386404T1 (es) |
| DE (1) | DE60225035T2 (es) |
| ES (1) | ES2298429T3 (es) |
| PT (1) | PT1435182E (es) |
| WO (1) | WO2003032657A1 (es) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2855704B1 (fr) * | 2003-05-26 | 2005-10-14 | France Telecom | Procede et dispositif de connexion d'un terminal a un reseau |
| DE10335367B4 (de) * | 2003-07-30 | 2005-06-09 | Siemens Ag | Verfahren zum Reservieren von Ressourceneinheiten |
| DE10335368B4 (de) * | 2003-07-30 | 2005-06-16 | Siemens Ag | Verfahren zum Aufheben von Reservierungen an Ressourceneinheiten |
| CN1283073C (zh) | 2003-08-15 | 2006-11-01 | 华为技术有限公司 | 一种实现预付费用户进行虚拟专用网业务的方法 |
| DE10342558A1 (de) * | 2003-09-15 | 2005-04-14 | Siemens Ag | Verfahren zum Vergebühren und Vergebührungseinheiten |
| CN100388711C (zh) * | 2004-11-18 | 2008-05-14 | 中兴通讯股份有限公司 | 实现预付费用户虚拟专网业务的***和方法 |
| DE102005022341A1 (de) * | 2005-05-13 | 2006-11-23 | O2 (Germany) Gmbh & Co. Ohg | Vorrichtung und Verfahren zur Kommunikation zwischen einem mobilen Endgerät und dem Internet |
| GB0512557D0 (en) * | 2005-06-20 | 2005-07-27 | Nokia Corp | Controlling provision of services in a communications network |
| EP1802027B1 (en) * | 2005-12-23 | 2009-11-25 | Telefonaktiebolaget LM Ericsson (publ) | Method, apparatus and computer program product for online charging |
| EP1804478A1 (en) | 2005-12-30 | 2007-07-04 | Telefonaktiebolaget LM Ericsson (publ) | Optimised reservation of charges for multiple communication services and/or service types |
| CN1859534B (zh) * | 2006-03-21 | 2012-06-27 | 华为技术有限公司 | 一种业务服务的计费方法及*** |
| US7590596B2 (en) * | 2006-04-12 | 2009-09-15 | Nokia Corporation | Charging system and method for handling services within this system and entities thereof |
| CN100466523C (zh) * | 2006-06-09 | 2009-03-04 | 华为技术有限公司 | 在线计费和离线计费结合使用的计费***和方法 |
| DE602006019848D1 (de) * | 2006-07-05 | 2011-03-10 | Ericsson Telefon Ab L M | Verfahren und Vorrichtung zur Übertragung von Gebührenerhebung für 'non-charging' Dienst-Bereitstellung |
| WO2008075154A2 (en) * | 2006-12-18 | 2008-06-26 | Fundamo (Proprietary) Limited | Payment method and system for electronic data |
| CN101316175B (zh) * | 2008-06-11 | 2011-03-02 | 中兴通讯股份有限公司 | 在线计费方法 |
| CN101742457B (zh) * | 2008-11-21 | 2012-12-12 | ***通信集团安徽有限公司 | 一种用户的欠费催缴方法、***及装置 |
| CN101754157B (zh) * | 2008-12-01 | 2013-11-20 | ***通信集团安徽有限公司 | 一种信息提醒的方法、装置及*** |
| CN101841421B (zh) * | 2009-03-19 | 2013-09-25 | 华为技术有限公司 | 在线计费方法、装置和*** |
| CN101540986B (zh) * | 2009-04-16 | 2011-10-26 | 中兴通讯股份有限公司 | 一种预付费业务的计费方法及*** |
| EP2798865B1 (en) * | 2011-12-27 | 2017-11-01 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for controlling charging in a communication network |
| WO2013168093A2 (en) * | 2012-05-07 | 2013-11-14 | Digitata Limited | Billing method for consumption services |
| US10580002B2 (en) | 2012-11-09 | 2020-03-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Efficient service authorization and charging in a communication system |
| US20140372287A1 (en) * | 2013-06-13 | 2014-12-18 | Telefonaktiebolaget L M Ericsson (Publ) | Method and Apparatus for Subscriber Account Selection |
| CN104717627A (zh) * | 2013-12-13 | 2015-06-17 | ***通信集团公司 | 计费话单创建方法、数据业务计费方法及相关装置 |
| US11212124B2 (en) | 2018-09-30 | 2021-12-28 | Intel Corporation | Multi-access edge computing (MEC) billing and charging tracking enhancements |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5303297A (en) * | 1991-07-25 | 1994-04-12 | Motorola, Inc. | Dynamic pricing method and apparatus for communication systems |
| US5265155A (en) * | 1991-07-31 | 1993-11-23 | Integrated Communications, Ltd. | Method and apparatus for prepayment of telecommunication connections in a telecommunication switching network |
| CA2076433C (en) * | 1991-10-31 | 1998-08-18 | Brenda B. Amarant | Monitoring of charges debited to an account having an assigned limit |
| US5559871A (en) * | 1994-09-23 | 1996-09-24 | Lucent Technologies Inc. | Call charge control and notification |
| FI100075B (fi) * | 1994-11-11 | 1997-09-15 | Ericsson Telefon Ab L M | Järjestelmä tilaajatiedon hallitsemiseksi puhelinverkossa |
| US5812945A (en) * | 1995-12-22 | 1998-09-22 | Pitney Bowes Inc. | Metered payment cellular telephone communication system |
| US6058303A (en) * | 1996-08-30 | 2000-05-02 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for subscriber activity supervision |
| FI113224B (fi) * | 1996-11-11 | 2004-03-15 | Nokia Corp | Laskutuksen toteuttaminen tietoliikennejärjestelmässä |
| US6188752B1 (en) * | 1996-11-12 | 2001-02-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for providing prepaid telecommunications services |
| US5995822A (en) * | 1997-06-02 | 1999-11-30 | Telefonaktiebolaget L M Ericsson | Method for handling parallel transactions on telephone pre-paid accounts |
| US6195543B1 (en) * | 1997-06-20 | 2001-02-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for providing advice of charge parameters for mobile radio telephone calls |
| FI973787A (fi) * | 1997-09-25 | 1999-03-26 | Nokia Telecommunications Oy | Älyverkkopalvelujen yhteistoiminta |
| DE69811947T2 (de) * | 1997-12-15 | 2003-12-11 | British Telecomm | Datenübertragungen |
| US6058173A (en) * | 1998-02-19 | 2000-05-02 | Lhs Group Inc. | Real-time call rating and debiting system |
| US6480591B1 (en) * | 1998-02-19 | 2002-11-12 | Priority Call Management, Inc. | Real-time call rating and debiting system and method for multiple calls |
| EP1095499B1 (en) * | 1998-07-15 | 2011-04-20 | Eight Esemay DE L.L.C. | Method and apparatus for performing a charging limit control |
| US6185414B1 (en) * | 1998-07-24 | 2001-02-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless telecommunication system with prepaid architecture |
| US6704563B1 (en) * | 1998-08-11 | 2004-03-09 | Boston Communications Group, Inc. | Systems and methods for prerating costs for a communication event |
| ATE311713T1 (de) * | 1999-12-13 | 2005-12-15 | Markport Ltd | Wapdienst personalisierung, management und vergebührung objektorientierteplattform |
| US6952575B1 (en) * | 2000-02-25 | 2005-10-04 | Telecommunication Systems, Inc. | Prepaid call management in intelligent network |
| US6999943B1 (en) * | 2000-03-10 | 2006-02-14 | Doublecredit.Com, Inc. | Routing methods and systems for increasing payment transaction volume and profitability |
| JP3399436B2 (ja) * | 2000-03-13 | 2003-04-21 | 日本電気株式会社 | 通話料金課金システム |
| US6615034B1 (en) * | 2000-04-27 | 2003-09-02 | Sprint Communications Company L.P. | Communication billing system |
| JP2001326697A (ja) * | 2000-05-17 | 2001-11-22 | Hitachi Ltd | 移動体通信網、端末装置、パケット通信制御方法、及び、関門装置 |
| US7424446B2 (en) * | 2000-05-26 | 2008-09-09 | Comverse Network System, Ltd. | Apparatus and method for storing predetermined multimedia information |
| WO2002067156A1 (en) * | 2001-02-19 | 2002-08-29 | Nokia Corporation | Control of billing in a communications system |
| GB2372405A (en) * | 2001-02-20 | 2002-08-21 | Motorola Inc | Communications services charging and billing apparatus and method |
| US6950876B2 (en) * | 2001-03-19 | 2005-09-27 | Lucent Technologies Inc. | Multiple-protocol home location register and method of use |
| US6678364B2 (en) * | 2001-06-07 | 2004-01-13 | Bellsouth Intellectual Property Corporation | System and method for cost estimation of a long distance call |
-
2002
- 2002-10-08 CN CN02824155.XA patent/CN1608387B/zh not_active Expired - Fee Related
- 2002-10-08 AT AT02800816T patent/ATE386404T1/de not_active IP Right Cessation
- 2002-10-08 EP EP02800816A patent/EP1435182B1/en not_active Expired - Lifetime
- 2002-10-08 PT PT02800816T patent/PT1435182E/pt unknown
- 2002-10-08 US US10/492,045 patent/US8090652B2/en not_active Expired - Fee Related
- 2002-10-08 WO PCT/SE2002/001840 patent/WO2003032657A1/en active IP Right Grant
- 2002-10-08 DE DE60225035T patent/DE60225035T2/de not_active Expired - Lifetime
- 2002-10-08 ES ES02800816T patent/ES2298429T3/es not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE60225035T2 (de) | 2009-02-05 |
| EP1435182A1 (en) | 2004-07-07 |
| DE60225035D1 (de) | 2008-03-27 |
| WO2003032657A1 (en) | 2003-04-17 |
| CN1608387B (zh) | 2011-12-14 |
| EP1435182B1 (en) | 2008-02-13 |
| CN1608387A (zh) | 2005-04-20 |
| US20040247100A1 (en) | 2004-12-09 |
| ATE386404T1 (de) | 2008-03-15 |
| US8090652B2 (en) | 2012-01-03 |
| PT1435182E (pt) | 2008-03-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2298429T3 (es) | Sistema y metodo de facturacion en una red de comunicaciones y un servidor de facturacion de una red de comunicaciones. | |
| US8260254B2 (en) | Network billing | |
| CN101212532B (zh) | 一种融合的计费***和方法 | |
| ES2284662T3 (es) | Metodo y aparato para tarifar servicios de comunicaciones. | |
| US7764947B2 (en) | Online charging management server | |
| KR100945351B1 (ko) | 통신 시스템에서의 과금 | |
| ES2248108T3 (es) | Procedimiento y sistema para la tarificacion en redes de comunicaciones. | |
| RU2491632C1 (ru) | Система и способ предоставления дополнительной платной услуги | |
| US9307095B2 (en) | Prepaid short message services revenue capture | |
| EP1876808B1 (en) | A method and system for enabling charging of non-charging controlled services | |
| CN101183956B (zh) | 智能网在线计费交互***及方法 | |
| US8265663B2 (en) | Messaging services for pre-pay users | |
| US20070217581A1 (en) | System and Method for Implementing Prepaid Data Services | |
| EP1667417B1 (en) | A method and system for rewarding users of services in a communications system | |
| ES2336597T3 (es) | Sistema y aparato para el procesamiento de eventos de red. | |
| ES2386178B1 (es) | Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago | |
| CN103813289B (zh) | 实时在线计费方法和实时在线计费处理*** | |
| CN110300235A (zh) | 一种通信业务计费方法和装置 |