Field of the invention
[0001] The invention relates to event-based billing and content delivery. More specifically
the invention relates to billing and delivery of event-based premium content by a
portal.
Background of the invention
[0002] Many existing billing models for premium content are based on subscriptions. The
need for event-based billing and content delivery solutions is growing, especially
for content delivered via portals for mobile data networks such as GPRS and UMTS.
[0003] US patent US6373933 describes a method for implementing transaction-based billing
for telephone services. US6373933 is applicable to telephony networks comprising an
intelligent network component, but cannot be used for data networks such as the Internet
or mobile data networks.
Problem definition
[0004] A solution capable of handling millions of event-based billing and content delivery
requests per month, the solution moreover being able to allow in some cases subsequent
delivery of the same premium content without the customer having to pay for it again,
is not available.
Aim of the invention
[0005] The aim of the invention is to provide a solution for event-based billing and content
delivery capable of handling millions of event-based billing and content delivery
requests per month, the solution moreover being able to allow in some cases subsequent
delivery of the same premium content without the customer having to pay for it again.
Summary of the invention
[0006] According to an aspect of the invention a method and system for event-based billing
and content delivery are provided for a content requested from a terminal user.
[0007] The method can comprise the following steps or a subset of the following steps, where
the system can comprise means to handle these steps:
- Determining whether or not the content is already delivered but deliverable again,
which can be based on the existence of a ticket and/or whether or not a time-out is
reached and/or whether or not a predefined number of downloads is reached. The ticket
can be deleted when the time-out is reached and/or when the predefined number of downloads
is reached.
If the content is not already delivered or not deliverable again:
- Verifying a credit of the terminal user. This verification step can comprise reading
a credit threshold variable and checking if the credit threshold variable is at a
predetermined value. If the credit threshold variable is at the predetermined value,
a credit check can be requested and it can be verified if the credit of the terminal
user is at a predetermined minimum level. The event-based billing and content delivery
can be stopped if the credit of the terminal user is at the predetermined minimum
level.
- Validating the request for content. This validation step can comprise retrieving an
information about the content. The information can comprise a price for the content.
An acceptation page can be sent to the terminal user and can comprise the price for
the content and/or means for returning an acceptation statement for the price of the
content. The acceptation statement can be retrieved from the terminal user and/or
checked. The acceptation statement can include a pin code. The event-based billing
and content delivery can be stopped if the acceptation statement is negative or invalid.
A ticket can be created if the acceptation statement is positive and valid.
- Delivering the content to the terminal user. This delivery step can comprise retrieving
the content from a content provider and/or sending the content to the terminal user.
It can be checked whether or not the content is retrieved correctly from the content
provider. The event-based billing and content delivery can be stopped if the content
is not retrieved correctly from the content provider. A variable keeping track of
a number of downloads can be changed.
- Billing the content. This billing step can comprise sending an electronic data record
to a billing system and/or checking whether or not the credit of the terminal user
is at the predetermined minimum level. The credit threshold variable can be set to
the predetermined value if the credit of the terminal user is at the predetermined
minimum level. The event-based billing and content delivery can be stopped if the
credit of the terminal user is not at the predetermined minimum level.
If the content is already delivered but deliverable again:
- Delivering the content to the terminal user. This delivery step can comprise the steps
described for de delivery step above.
The System can comprise a portal. The portal can be connected to the terminal user,
a content provider, a billing system, a storage and/or a database. The portal can
comprise a front-end part and a back-end part. The front-end part can be connected
to the terminal user and/or the content provider. The back-end part can be connected
to the billing system, the storage and/or the database.
[0008] The system can comprise one or more modules. One or more modules can be provided
to determine whether or not the content is already delivered but deliverable again
based on whether or not a time-out is reached. One or more modules can be provided
to delete the ticket if the time-out is reached. One or more modules can be provided
to determine whether or not the content is already delivered but deliverable again
based on whether or not a predefined number of downloads is reached. One or more modules
can be provided to delete the ticket if the predefined number of downloads is reached.
One or more modules can be provided to verify the credit of the terminal user by reading
a credit threshold variable from the storage and/or checking if the credit threshold
variable is at a predetermined value and/or requesting a credit check from the billing
and/or verifying if the credit of the terminal user is at a predetermined minimum
level and/or stopping the event-based billing and content delivery if the credit of
the terminal user is at the predetermined minimum level. One or modules can be provided
to validate the request for content by retrieving an information about the content
from the database and/or sending an acceptation page to the terminal user and/or retrieving
the acceptation statement from the terminal user and/or checking the acceptation statement
and/or stopping the event-based billing and content delivery if the acceptation statement
is negative or invalid and/or creating the ticket if the acceptation statement is
positive and valid. One or more modules can be provided to deliver the content to
the terminal user by retrieving the content from the content provider and/or sending
the content to the terminal user. One or more modules can be provided to deliver the
content to the terminal user by checking whether or not the content is retrieved correctly
from the content provider and/or stopping the event-based billing and content delivery
if the content is not retrieved correctly from the content provider. One or more modules
can be provided to change a variable keeping track of a number of downloads. one or
more module can be provided for the billing of the content by sending an electronic
data record to the billing system and/or checking whether or not the credit of the
terminal user is at the predetermined minimum level and/or setting the credit threshold
variable to the predetermined value if the credit of the terminal user is at the predetermined
minimum level and/or finishing the event-based billing and content delivery if the
credit of the terminal user is not at the predetermined minimum level.
Brief description of the drawings
[0009] The invention will be explained in greater detail by reference to exemplary embodiments
shown in the drawings, in which:
Fig.1 shows the steps of the event-based billing process according to an exemplary
embodiment of the invention;
Fig.2 shows the steps within the first step of Fig.1 according to an exemplary embodiment
of the invention;
Fig.3 shows the steps within the second step of Fig.1 according to an exemplary embodiment
of the invention;
Fig.4 shows the steps within the third step of Fig.1 according to an exemplary embodiment
of the invention;
Fig.5a shows the steps within the fourth step of Fig.1 according to an exemplary embodiment
of the invention;
Fig.5b shows alternative steps within the fourth step of Fig.1 according to an exemplary
embodiment of the invention;
Fig.6 shows the steps within the fifth step of Fig.1 according to an exemplary embodiment
of the invention;
Fig.7 shows a system for event-based billing according to an exemplary embodiment
of the invention.
Detailed description of the invention
[0010] For the purpose of teaching of the invention, preferred embodiments of the method
and system of the invention are described in the sequel. It will be apparent to the
person skilled in the art that other alternative and equivalent embodiments of the
invention can be conceived and reduced to practice without departing from the true
spirit of the invention, the scope of the invention being only limited by the claims
as finally granted.
[0011] In Fig.7 a portal (200) is shown, including its connections to a terminal user (100),
a content provider (600), a billing system (300), a storage (400) and a database (500).
The terminal user uses a terminal capable of sending and retrieving data, e.g. via
Internet or a GPRS/UMTS mobile network. Examples of such terminals are a pc, laptop,
wap mobile phone, i-mode phone or set-top box. The terminal user (100) retrieves content
from content providers (600) via the portal (200). The portal (200) makes sure that
the content is paid for when delivering it to the terminal user (100). Often the content
provider (600) is a third party specialized in content provisioning, but it is also
possible that the content provider is part of the portal. A special kind of content
is event-based content, for which there is payment obliged per event such as a page
retrieval, access to content for a specific period of time, a maximum number of downloads,
etcetera. The method and system of the invention provide a solution for event-based
billing and event-based content delivery from the content provider (600) to the terminal
user (100).
[0012] In the best mode embodiment the portal is separated into two parts: a front-end part
(201) and a back-end part (202). This increases security by separating terminal users
(100) and content providers (600), both parties possibly residing outside the controlled
and secured environment of the portal company, from critical internal systems such
as the billing system (300), storage equipment (400) and databases (500).
[0013] With a request for event-based content the process as shown in Fig.1 starts. The
request is a HTTP request:
GET http://
portal/
get?user_id&content_id.
In this request the id of the terminal user and the id of the requested event-based
billing is included.
[0014] The request can be a first request, but is can also be a request after a failed previous
request, a request because of a reload command at the terminal, or a valid subsequent
request because a period of time has not elapsed yet or a maximum number of downloads
is not reached yet. Therefore in a first step the status of the request is determined
(1). If a ticket, a digital proof of payment stored in the portal, for the terminal
user (100) exists for the requested content, a time-out value and the number of downloads
are checked (11, 12, 13). Both are stored within the ticket. If all three checks are
positive, the content can be delivered (4) to the terminal user (100) immediately.
Other criteria for determining the status of the request could be applied. As soon
as the maximum time for using the content is reached, thus the time-out value is reached,
the ticket is deleted. Also when the maximum number of downloads is reached the ticket
is deleted. If at least one of the three checks is negative the process continues
with the verification step (2).
[0015] In the verification (2) step first checks (21, 22) a credit threshold variable by
reading (22) its value from a speed-optimized LDAP storage (400). The credit threshold
value indicates whether or not e.g. 90% of the credit of the terminal user (100) is
used. It is stored as:
credit_threshold_reached=
false|
true.
Only when the threshold of 90% is reached a credit check (23) is requested from the
billing system. This credit check (23) is more resource and time consuming and should
be performed as less as possible. If the outcome of the credit check (23, 24) is that
there is not enough credit left, the event-based billing and content delivery process
is stopped (6) and a sorry-page is send to the terminal user (100).
[0016] In the next step the content request is validated (3). Therefore content pricing
information is retrieved (31) from an Oracle database (500) and send (32) to the terminal
user (100) in a HTML page. The HTML page includes a form for a pin code and an accept
button. After retrieving (34) response from the terminal user (100) the pin code is
verified. If the pin code is invalid the terminal user (100) is not allowed to retrieve
the content and the event-based billing and content delivery process is stopped (6).
A sorry page is then sent to the terminal user (100). If the pin code is valid then
a ticket is created (35) by storing the user_id/content_id in the portal. If there
is a validity period defined for the content in the Oracle database (500), e.g. a
validity period of one day, then that value is stored within the ticket. Otherwise
a default validity period of 60 seconds is stored. Likewise a maximum number of allowed
downloads is stored, with a default of 1.
[0017] Next the content can be delivered (4) to the terminal user (100). After the content
is received (41) in the front-end part (201) of the portal (200) from the content
provider (600), the content retrieval is checked (42). If the content did not reach
the portal intact, the event-based billing and content delivery process is stopped
(6) and a sorry-page is sent to the terminal user (100). Otherwise the content is
sent to the terminal user (100) and the maximum number of downloads stored in the
ticket is decreased with 1.
[0018] Only if the request from the terminal user (100) was a first request the billing
step (4) follows. An electronic data record containing the user_id, content_id and
timestamp is sent to the billing system (600) where the price of the content is deducted
from the credit. If the credit reaches the 90% threshold, thus only 10% of the credit
is left, a notification is received back from the billing system (600) and the credit
threshold value is set (52, 53) in the LDAP storage (400). Otherwise the event-based
billing and content delivery is finished (7).
1. Method for event-based billing and content delivery for a content requested from a
terminal user (100), the method comprising the steps of
determining (1) whether or not the content is already delivered but deliverable
again based on the existence of a ticket;
if the content is not already delivered or not deliverable again,
verifying (2) a credit of the terminal user (100);
validating (3) the request for content;
delivering (4) the content to the terminal user (100);
billing (5) the content;
if the content is already delivered but deliverable again,
delivering (4) the content to the terminal user (100).
2. Method according to claim 1 in which the determining (1) whether or not the content
is already delivered but deliverable again is also based on whether or not a time-out
is reached (12).
3. Method according to claim 2 in which the method further comprises the step of
deleting the ticket if the time-out is reached.
4. Method according to claims 1-3 in which the determining (1) whether or not the content
is already delivered but deliverable again is also based on whether or not a predefined
number of downloads is reached (13).
5. Method according to claim 4 in which the method further comprises the step of
deleting the ticket if the predefined number of downloads is reached.
6. Method according to any of the preceding claims in which the verifying (2) of the
credit of the terminal user (100) comprises the steps of
reading (21) a credit threshold variable;
checking (22) if the credit threshold variable is at a predetermined value;
if the credit threshold variable is at the predetermined value,
requesting (23) a credit check;
verifying (24) if the credit of the terminal user (100) is at a predetermined minimum
level, stopping (6) the event-based billing and content delivery if the credit of
the terminal user (100) is at the predetermined minimum level.
7. Method according to any of the preceding claims in which the validating (3) of the
request for content comprises the steps of
retrieving (31) an information about the content, the information comprising a
price for the content;
sending (32) an acceptation page to the terminal user (100), the acceptation page
comprising the price for the content, the acceptation page also comprising means for
returning an acceptation statement for the price of the content;
retrieving (33) the acceptation statement from the terminal user (100);
checking (34) the acceptation statement, stopping (6) the event-based billing and
content delivery if the acceptation statement is negative or invalid;
creating (35) the ticket if the acceptation statement is positive and valid.
8. Method according to claim 7 in which the acceptation statement includes a pin code.
9. Method according to any of the preceding claims in which the delivering (4) of the
content to the terminal user (100) comprises the steps of
retrieving (41) the content from a content provider (600);
sending (43) the content to the terminal user (100).
10. Method according to claim 9 in which the delivering (4) of the content to the terminal
user (100) further comprises the step of
checking (42) whether or not the content is retrieved correctly from the content
provider (600), stopping (6) the event-based billing and content delivery if the content
is not retrieved correctly from the content provider (600).
11. Method according to claims 9-10 in which the delivering (4) of the content to the
terminal user further comprises the step of
changing a variable keeping track of a number of downloads.
12. Method according to any of the claims 6-11 in which the billing (5) of the content
comprises the steps of
sending (51) an electronic data record to a billing system (600);
checking (52) whether or not the credit of the terminal user (100) is at the predetermined
minimum level;
setting (53) the credit threshold variable to the predetermined value if the credit
of the terminal user (100) is at the predetermined minimum level;
finishing (7) the event-based billing and content delivery if the credit of the
terminal user (100) is not at the predetermined minimum level.
13. System for event-based billing and content delivery for a content requested from a
terminal user (100), the system comprising a portal (200), the portal (200) connected
to
the terminal user (100),
a content provider (600),
a billing system (300),
a storage (400) and
a database (500),
the system comprising
means for determining (1) whether or not the content is already delivered but deliverable
again based on the existence of a ticket;
means for verifying (2) a credit of the terminal user (100);
means for validating (3) the request for content;
means for delivering (4) the content to the terminal user (100);
means for billing (5) the content.
14. System according to claim 13 in which the portal (200) comprises a front-end part
(201) and a back-end part (202), the front-end part (201) connected to
the terminal user (100) and
the content provider (600),
the back-end part (202) connected to
the billing system (300),
the storage (400) and
the database (500).
15. System according to claims 13-14 in which the system comprises one or more modules.
16. System according to claim 15 in which one or more modules are provided to determine
(1) whether or not the content is already delivered but deliverable again based on
whether or not a time-out is reached (12).
17. System according to claim 16 in which one or more modules are provided to delete the
ticket if the time-out is reached.
18. System according to claims 16-17 in which one or more modules are provided to determine
(1) whether or not the content is already delivered but deliverable again based on
whether or not a predefined number of downloads is reached (13).
19. System according to claim 18 in which one or more modules are provided to delete the
ticket if the predefined number of downloads is reached.
20. System according to any of the claims 16-19 in which one or more modules are provided
to verify (2) the credit of the terminal user (100) by
reading (21) a credit threshold variable from the storage (400);
checking (22) if the credit threshold variable is at a predetermined value;
requesting (23) a credit check from the billing system (300);
verifying (24) if the credit of the terminal user (100) is at a predetermined minimum
level, stopping (6) the event-based billing and content delivery if the credit of
the terminal user (100) is at the predetermined minimum level.
21. System according to any of the claims 16-20 in which one or more modules are provided
to validate (6) the request for content by
retrieving (31) an information about the content from the database (500), the information
comprising a price for the content;
sending (32) an acceptation page to the terminal user (100), the acceptation page
comprising the price for the content, the acceptation page also comprising means for
returning an acceptation statement for the price of the content;
retrieving (34) the acceptation statement from the terminal user (100);
checking (35) the acceptation statement, stopping the event-based billing and content
delivery if the acceptation statement is negative or invalid;
creating the ticket if the acceptation statement is positive and valid.
22. System according to claim 21 in which the acceptation statement includes a pin code.
23. System according to any of the claims 16-22 in which one or more modules are provided
to deliver (4) the content to the terminal user (100) by
retrieving (41) the content from the content provider (600);
sending (43) the content to the terminal user (100).
24. System according to claim 23 in which one or more modules are provided to deliver
(4) the content to the terminal user (100) by
checking (42) whether or not the content is retrieved correctly from the content
provider (600), stopping (6) the event-based billing and content delivery if the content
is not retrieved correctly from the content provider (600).
25. System according to claims 23-24 in which one or more modules are provided to change
a variable keeping track of a number of downloads.
26. System according to any of the claims 20-25 in which one or more module are provided
for the billing (5) of the content by
sending (51) an electronic data record to the billing system (300);
checking (52) whether or not the credit of the terminal user (100) is at the predetermined
minimum level;
setting (53) the credit threshold variable to the predetermined value if the credit
of the terminal user (100) is at the predetermined minimum level;
finishing (7) the event-based billing and content delivery if the credit of the
terminal user (100) is not at the predetermined minimum level.