WO2003027933A1 - Billet et procede de facturation - Google Patents

Billet et procede de facturation Download PDF

Info

Publication number
WO2003027933A1
WO2003027933A1 PCT/SE2002/001742 SE0201742W WO03027933A1 WO 2003027933 A1 WO2003027933 A1 WO 2003027933A1 SE 0201742 W SE0201742 W SE 0201742W WO 03027933 A1 WO03027933 A1 WO 03027933A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
isp
provider
content
Prior art date
Application number
PCT/SE2002/001742
Other languages
English (en)
Inventor
Jakob EHRENSVÄRD.
Stina EHRENSVÄRD
Original Assignee
Cypak Ab
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Cypak Ab filed Critical Cypak Ab
Publication of WO2003027933A1 publication Critical patent/WO2003027933A1/fr

Links

Classifications

    • 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/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • 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/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/127—Shopping or accessing services according to a time-limitation
    • 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/14—Payment architectures specially adapted for billing systems
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention pertains to a method of attaching a billing ticket to a transfer protocol for communication over an open network for data and telecommunication between an end-user, a service provider and a content provider, and a ticket therefore.
  • the present invention aims to solve the problems mentioned and presents a reliable method for a transfer protocol and a ticket for the same.
  • the present invention sets forth a method of attaching a billing ticket in a transfer protocol for a communication requested by an end-user over an open network for data and telecommunication through at least one service provider to a content provider.
  • the invention is comprising: in the transfer protocol an identity to a provider of services or content, the ticket comprising at least, a time stamp, a counter and a random number; a message authentication code attached to the ticket, which verifies the validity of the ticket at a provider of services or content when successfully decoded; and the counter counting time periods in addition to the time stamp, thus making possible to differ between tickets with time stamps issued at a same time period.
  • a cost code field for a requested services is added to the ticket.
  • it is further comprising: storing content providers universal resource locator in a list in a database at the service provider, which indicates if a requested service is charged at the content provider; the service provider intercepting and analysing a transfer protocol data name server query for a requested universal resource locator, performing a look-up in the database for an indicated charge for the requested universal resource locator; buffering a response to the requesting end-user if the requested universal resource locator is charged; and transferring the end-user request with attached ticket and message authentication code to the content provider.
  • Still another embodiment comprises: the content provider receiving an end-user request; and transferring the end-user request with identity and attached first ticket and message authentication code to the service provider; the service provider analysing the identity and verifying the message authentication code, performing a look-up in a database for an indicated charge for the requested universal resource locator; the service provider sending a message with at least the first ticket with content provider identity and a second ticket issued by the service provider, the service provider identity, and message authentication code; and upon an accept by the end-user of the requested services, the message being sent to the content provider verifying the first ticket and identity and the service provider identity, second ticket and message authentication code, whereby a successful verification initiates a requested end-user services.
  • a further embodiment provides that a request from an end-user to be provided an universal resource locator to a content provider residing in the network of a different service provider than its own, the service providers issuing and checking tickets between themselves with their identifiers before clearing a connection to the sought content provider.
  • a still further embodiment comprises that an end-user not registered to utilize the method, requesting an universal resource locator to a content provider, is being redirected to an advertising home page in the network to be informed about the method.
  • Still another embodiment provides that each issued ticket has a limited lifetime of being in a pending state.
  • Yet one embodiment comprises that an internet service provider holds a list of ticket timeout values for different content providers. Yet another embodiment comprises that a non-responding content provider request rejected by the end-user or content providers, will provide a ticket timeout, hindering a billing to be recorded.
  • a billing ticket in a transfer protocol for a communication requested by an end-user over an open network for data and telecommunication through at least one service provider to a content provider.
  • the ticket thus comprises: in the transfer protocol an identity to a provider of services or content, the ticket comprising at least, a time stamp, a counter and a random number; a message authentication code attached to the ticket, which verifies the validity of the ticket at a provider of services or content when successfully decoded; and the counter counting time periods in addition to the time stamp, thus making possible to differ between tickets with time stamps issued at a same time period.
  • One embodiment of the ticket comprises that a cost code field for requested services is added to the ticket. Another embodiment provides that the counter is incremented at each access request, and reset at each current universal time coordinated timestamp increment.
  • a further embodiment provides that the ticket is a long arbitrary number, represented as a linear sequence, a random sequence or a combination of both.
  • Fig. 1 schematically illustrates a customer to content provider relationship over the Internet
  • Fig. 2 schematically illustrates ISP identifier and a ticket in accordance with the present invention
  • Fig. 3 schematically illustrates CP identifier and a ticket in accordance with the present invention
  • Fig.4 schematically illustrates an ISP approval ticket in accordance with the present invention.
  • FIG. 5 and 6 schematically illustrate a ticket in accordance with the present invention for an intra content payment. Description of preferred embodiments
  • an end-user 14 conventionally connects to the Internet 10 through an Internet 10 service provider (ISP) 12, typically a telephone- or network operator. Connection can either be performed through a switched fixed-network (PSTN, Public Switched Telephone Network; Integrated Services Digital Network, ISDN; x (generic) Digital Subscriber Line, xDSL) or through a fixed connection.
  • PSTN Public Switched Telephone Network
  • ISDN Integrated Services Digital Network
  • x (generic) Digital Subscriber Line, xDSL) or through a fixed connection.
  • service provider which acts as a gateway between a customer and the Internet 10. Independently if the connection is made from a person residing in its residential home, or over a high-capacity line, through a corporate LAN gateway 16, the service provider 12 can identify the connection to a specific end-user 14 account.
  • a residential end-user 14 that connects to a CP 18 (Content Provider) site.
  • the end-user 14 logs on through an Internet 10 browser and enters the Universal Resource Locator (URL) of the CP 18, in this example the URL http://www.xxx.com.
  • URL Universal Resource Locator
  • HTTP HyperText Transfer Protocol
  • GET/POST HyperText Transfer Protocol
  • the CP 18 is not able to reliably identify neither the ISP nor the end-user 14, but has enough information to pass the requested information back to the requesting end-user 14.
  • the ISP 12 intercepts all request operations of end-users 14 and performs a lookup of the URL.
  • the lookup table holds all URL of available CP 18, which the ISP 12 has established a billing agreement with. If the URL is found in the table list, the ISP 12 attaches a tag/ticket 22 to the request, containing, with reference to Fig. 2, an ISP 12 Identifier (SPID 20), a "ticket 22", within a bracket in Fig. 2, intended for a single use, and a Message Authentication Code (MAC), not shown.
  • the ticket 22 is typically a long arbitrary number, either represented as a linear sequence, a random sequence or a combination of both.
  • a playback operation is prevented by a time stamp 24 comprised in the ticket 22 of the present invention by using values from a system clock providing the actual system time.
  • the counter 26 provides accuracy, for example, if two tickets 22 are produced within the same UTC time stamp 24.
  • the present invention provides the ticket 22 in the transfer protocol an identity 20 to a provider of services 12 or content, whereby the ticket 22 comprises at least, a time stamp 24, a counter 26 and a random number 28.
  • a message authentication code attached to the ticket 22, which verifies the validity of the ticket 22 at a provider of services 12 or content 18 when it has been successfully decoded.
  • the counter 26 is counting time periods in addition to said time stamp 24, thus making possible to differ between tickets 22 with time stamps 24 issued at a same time period.
  • Implementation of MAC is the result of a cryptographic operation, operating on the SPID 20 identifier and ticket 22, using a secret key, shared by an ISP 12 and a CP 18.
  • the encryption billing scheme can either be symmetric, i.e. the ISP 12 and CP 18 holds the same secret key, or having an asymmetric key pair, where the ISP 12 typically holds the private and the CP 18 the public key.
  • the receiving CP 18 is able to analyse each HTTP GET/POST request and check for such a tag/ticket 22 and to verify an added SPID 20, ticket 22 and MAC in accordance with the present invention to determine if the end-user 14 is to be granted or rejected access to the service.
  • the HTTP response which is sent back to the client/end-user 14 through the ISP 12, contains the ticket 22, charging amount, in a currency specified by the ISP 12 CP 18 list, and a MAC.
  • the ISP 12 is able to use a lookup table, not shown, to match the received ticked with the list of issued tickets 22 to determine which account is to be charged, and which CP 18 is to receive the charged amount.
  • the information is removed, and a clean response (the HTML page sent is stripped of billing information) is sent to the client/end-user 14.
  • ISP 12 and CP 18 can periodically match their respective lists of tickets 22, sorted per ISP 12 and CP 18 to clear the balance due. This process could be automated.
  • the approach is, instead of rejecting a request with a missing ticket 22, to redirect the request to an advertising page, encouraging the end-user 14 to contact its ISP 12 to establish an agreement with the CP 18.
  • Another option is to let the end-user 14 attend a limited free service.
  • a more sophisticated billing scheme could be applied, where the first access to a certain CP 18 would pass back a request to the ISP 12 that this is a charged service, this would result in longer response time and additional network overhead.
  • the CP 18 should implement a billing scheme to keep the ticket 22 only when all data has been sent to the client. Furthermore, the ISP 12 is able to add additional features of removing billing tickets 22 if a communications failure occurs. Each issued ticket 22 practically has a limited lifetime in a pending state, as the response from the CP 18 is normally expected in seconds or less.
  • the ISP 12 can in one embodiment hold a list of ticket 22 timeout values for different CP 18, probably including information of expected peak times. Non-responding CP 18 or requests rejected by the end- user 14 or CP 18, will provide a ticket 22 timeout, which hinders any billing recordings.
  • the present invention is difficult to tamper with, thus avoiding fraud access.
  • One further aspect of the billing scheme is that the ISP 12 at any time can exclude groups of end-users 14 to access certain CP 18. Further, a CP 18 can at any time reject requests from a specific ISP 12, and an ISP 12 can at any given time entirely remove an entry from the list of valid CP 18.
  • Unreliable, or potential offensive CP 18, can be instantly controlled by the ISP 12.
  • the ISP 12 can hold a credit limit for individual end-users 14, automatically rejecting further requests until the end-user 14 has paid its outstanding debt.
  • Other billing schemes may include specific end-users 14 to prepay a retainer in order to use charged services.
  • a CP 18 can reject requests from an ISP 12, exceeding their credit limits.
  • the billing scheme of the ISP 12 is similar to an ordinary telephone network access as well as the usage of toll numbers, where the subscription itself is the identity for billing, rather than a specific end-user 14. This means, that any end-user 14 accessing a CP 18 from a specific subscription account, will result in that the owner of the account is charged. This corresponds to a family having telephone access, where the ISP 12 must include a non- repudiation statement in the terms of use for a customer.
  • a more sophisticated implementation would allow individual end-users 14 to explicitly enable only a specific CP 18, or group of CP 18. Moreover, end-users 14 can be allowed to explicitly block a specific CP 18 or groups of CP 18.
  • An ISP 12 is able to categorize a CP 18 into different groups, allowing end-users 14 to access or block specific content categories, where a typical scenario includes an account holder allowing family or employee access to education, financial or weather sites and disabling games, violence and pornographic sites.
  • several different models may apply between end-users 14 and ISP
  • An ISP 12 may have special tariff agreements with a specific CP 18, thus enabling billing structures between ISP 12 and CP 18 to be different from the billing structures between an end-user 14 and a CP 18.
  • a large national ISP 12 may have special agreements with the ISP 12 top-ten most visited CP 18, where a fixed billing rate applies, whereas the ISP 12 charges end-users 14 for each used ticket 22.
  • ISP-CP relationship regards a larger company, where employees access the Internet 10 via a Local Area Network (LAN) through a corporate Internet 10 gateway 16.
  • ISP 12 software as a proxy server, either on that gateway, or externally, could achieve the same functionality as previously described.
  • the grouping of CP 18 could be used to prevent employees to access non-business critical services.
  • companies are able to establish a corporate to CP 18 subscription of, for example, an on-line version of a financial news service.
  • a potential caveat from a CP 18 point of view is the presence of proxy servers caching static content information. Apart from the CP 18 inserting expiration and cache- control information in HTTP headers, the ISP 12-CP 18 relationship may apply different rules how this condition is to be handled and compensated.
  • HTTP file transfer protocol
  • POP3 post office protocol 3
  • an end-user 14 connects to the Internet 10 via an Internet 10 Service Provider 12, utilizing a dial-up connection.
  • An end- user 14 is going to visit a specific Content Provider 18 site on the Internet 10, using a web browser.
  • this request results in two operations, a Domain Name System (DNS) query and a HyperText Transfer Protocol (HTTP) GET/POST operation.
  • DNS Domain Name System
  • HTTP HyperText Transfer Protocol
  • the DNS query translates the end-user 14 URL into an Internet 10 Protocol (IP)-address, which more efficiently identifies the queried resource on the Internet 10.
  • IP Internet 10 Protocol
  • Large sites on the Internet 10 may have several IP numbers mapped to a single URL, resulting in a different IP number for subsequent DNS queries.
  • a following HTTP GET/POST operation uses a retrieved IP number to address the CP 18, where the request is routed through the ISP 12 and the routing mechanisms of the Internet 10, ending up at the CP 18 server.
  • the CP practically unaware of both the ISP 12 and the end-user's identities, processes the request and sends a response back to the requesting end-user 14.
  • the ISP 12 holds a list of CP 18, where each CP 18 is a part of a business relationship with the ISP 12.
  • the list, for each CP 18, further contains a list of URLs that are non-free services.
  • the ISP 12 intercepts and analyses each incoming DNS query, and performs a lookup in a table to determine if the requested URL is free to use or not. If the URL is found in the list, the IP response is buffered in a list linked to the requesting end-user 14.
  • the destination IP address of each HTTP GET/POST operation is intercepted and analysed by the ISP 12.
  • the ISP 12 For each request having an IP number present in the end-user's IP list, the ISP 12 attaches a tag/ticket 22 to the request, containing a ISP 12 Identifier (SPID 20), a single-use "ticket 22" and a Message Authentication Code (MAC).
  • the ticket 22 is provided a UTC time stamp 24 of, in this embodiment 32 bits, a microsecond counter of 24 bits and a random number 28 of 40 bits.
  • the SPID 20 is an identifier, uniquely identifying the ISP 12. Using one IP number held by the ISP 12, ensures its uniqueness by using a established and regulated infrastructure of issuing unique identifiers, rather than establishing one new for this purpose.
  • the ticket 22 constitutes in one embodiment of the invention a per ISP 12 and per CP 18 unique, long arbitrary number, uniquely identifying a request sent from the ISP 12 to the CP 18.
  • Current Universal Time Coordinated (UTC) time 32, a microsecond counter 26, and a random number 28 are concatenated into a 96 bit identifier, serving as a unique and statistically variant ticket 22.
  • a system without a reliable microsecond counter 26 could use a lower resolution sub-second counter and pad out unused bits with random number.
  • the counter 26 adds time to a UTC time stamp 24 in order to be able to differ between requests by end-users that have received the same UTC time stamp in their tickets 22.
  • the SPID 20 and ticket 22 are concatenated into a 128-bit value.
  • the MAC is a cryptographic checksum of the SPID 20 and ticket 22, used by the CP 18 to verify the integrity of these entries.
  • the MAC algorithm used is AES encryption of the 128-bit SPID 20 and ticket 22, using a 128 bit symmetric key, resulting in a 128-bit cipher text.
  • AES is used to achieve highest performance versus encryption strength ratio.
  • the extra payload now added to the request is 128 + 128 bits, and is appended as content in the HTTP request.
  • the CP 18 receiving the packet is now able to check the presence of the ticket
  • a billing scheme has to be implemented so that the end-user 14 is notified that the service is about to be charged for. An amount, and clear instructions and selection of how to proceed or cancel will be presented before the response is sent, and the ticket 22 is saved by the CP 18 for billing.
  • the CP 18 records an accepted ticket 22, and associated charging information is periodically sorted and batch-wise transferred to the respective ISP 12, so that the CP 18 can receive its outstanding debt.
  • a method of enhancing the billing scheme to address the concerns described involves adding a second-level ticket 22 to each response, holding charging information, where the ISP 12 is able to analyse and strip the response packets for tickets 22. This method would allow the ISP 12 to constantly monitor outstanding balance, and, when appropriate, reject end-user 14 requests when a specified credit limit has been reached.
  • the ISP 12 can implement a second-level of billing scheme, independently of the CP 18.
  • the end-user 14 logging to an ISP 12 account and view current balance on-line.
  • the ISP 12 can further recalculate billing information into local currencies for maximum end-user 14 convenience.
  • the ISP 12 can freely decide to classify each connected CP 18 by its own judgment, in terms of dependability, category, offensiveness, objectivity, political, social and religious values etc.
  • the ISP 12 could instantly shut-down impolite, or potential offensive CP 18, as well as impolite end-users 14.
  • An ISP 12 can also implement an end-user 14-accessible control panel, where settings filtering out certain type of content providers and further set maximum charge amount per week, per transaction, credit limits etc.
  • end-user 14-accessible control panel settings filtering out certain type of content providers and further set maximum charge amount per week, per transaction, credit limits etc.
  • Several scenarios may apply in terms of business relationships between end- users 14 and ISP 12, between ISP 12 and CP 18 and between end-users 14 and CP 18.
  • An obvious example is a large national newspaper having a fixed-monthly fee for access to its online services by a large national ISP 12. The ISP 12 could then either enable access to that newspaper as a part of its services to its customers, or add a second level of billing to end- users 14, independent of the agreement between the ISP 12 and the CP 18.
  • ISP 12 may include a fixed free amount of content into their fixed monthly fee. Different end-users 14 may also have different credit limits. New end-users 14, free-ISP 12 access end-users 14 etc. may need to insert a retainer in order to access content. When the retainer has been used up, further accesses are rejected until a new retainer has been paid.
  • Fig. 3 schematically illustrating a CP 18 identifier and a ticket in accordance with the present invention.
  • an end- user 14 requests a CP 18 service, which is charged.
  • the CP 18 responds with an approval form, typically using Hyper Text Markup Language (HTML) page description language.
  • HTML Hyper Text Markup Language
  • the form contains invisible fields, holding information about the CP 18, the session and the cost of the service.
  • the default behaviour of the HTML form is that it displays a message that the service is unavailable, as there is no agreement in place with the end-user 14 ISP 12.
  • the secret fields 24, 26, 28, 34 form a "ticket" 22, within bracket in Fig. 3, issued by the CP 18 is 256 bits in length, and contains the following information.
  • the CPID 30 is an identifier, uniquely identifying the content provider.
  • IP Internet Protocol 10
  • the UTC timestamp 24 is a one second resolution timestamp in this embodiment, taken from a reasonably reliable time source of the CP 18 server computer. A practical requirement is that the timestamp 24 should not ever move backwards over any specified amount of time.
  • the Linear counter 26 is used to guarantee uniqueness for tickets 22 issued at the same second or other possible time period. The counter 26 is incremented at each access, and reset at each UTC 24 timestamp increment.
  • a cost code 34 describes a CP 18 to ISP 12 defined cost for an issued request.
  • the Random number 28 is used to add statistical variance to the ticket 22. It is desirable that the random number algorithm is not deterministic, as that would allow an alien to issue invalid future tickets 22, with high probability of not being detected.
  • MAC as mentioned is a cryptographic checksum of the CPID 30, UTC Timestamp 24, Linear counter 26 and Random number fields 28. Practically, this is implemented using AES encryption of these fields, using a secret key, shared by the CP 18 and ISP 12. Although obvious benefits exist in using asymmetric encryption for non- repudiation purposes, the symmetric 128-bit AES encryption is used to achieve high performance and encryption strength. An off-line attack against the MAC to find the secret key is not a practical threat, as the 2 128 equally possible keys would take an enormous time in amount, even when hypothetically using millions of computers in parallel.
  • the ticket 22 forms a self-contained unique reference to the transaction, which can be verified by anyone sharing the secret key.
  • the CP 18 holds all issued tickets 22 in a list queue together with a timeout value, which when elapsed, discards the ticket 22 from the queue, considering the proposal is implicitly rejected.
  • the 256 bit binary value is encoded using Base64 encoding.
  • a response is designed to as default, for example, showing "Non-free service, request rejected (with the hidden field invisible to the end-user 14).
  • Fig. 4 schematically illustrates an ISP approval ticket in accordance with the present invention.
  • the ISP 12 monitors and analyses all received responses, searching for the presence of a hidden CP 18 ticket 22 field. If not found, or considered invalid, the response is passed unmodified to the requesting end-user 14.
  • the ISP 12 extracts the CPID 30 from the ticket 22 and searches for a matching entry in a list of CP 18, which the ISP 12 has a business agreement with.
  • the response is passed unmodified to the requesting end-user 14.
  • ISP 12 verifies the integrity of the ticket 22, by using a secret key for the found CP 18. If the result not matches, the response is passed unmodified to the requesting end-user 14.
  • the ISP 12 now considers the ticket 22 to be valid for billing, and modifies the default behaviour of the form to an approval form. This is practically implemented by the ISP 12 replacing the entire CP 18 default form with an ISP 12 predefined approval form.
  • the ISP 12 translates the cost code into a real cost in local currency terms, depending on the CP-ISP business models for billing.
  • the form further contains the CP 18 issued ticket 22 as a hidden field, invisible to the end-user 14.
  • the ISP 12 keeps the pending approval information in a list queue, where each entry has a timeout and is discarded when a timer has elapsed.
  • An ISP 12 may also check the cost with an accumulated outstanding debt, and if appropriate, send a predefined "Request rejected, credit limit exceeded" form to the end-user 14.
  • a requesting end-user 14 can now decide if to accept or reject the proposal from the CP 18 and ISP 12. This is practically performed by pressing either an, for example, Windows ® graphical "Accept” or "Reject” button or like. The proposal can also be rejected by simply not responding to it.
  • the end-users 14 selection is sent back to the ISP 12, typically using a submit HTTP POST operation. Its response to the ISP 12 is analysed for the end-users 14 selection, and if rejected, the form is passed back to the CP 18 unmodified.
  • the ISP 12 searches its list queue for the CP 18 issued ticket 22 and inserts an approval ISP 12 ticket 22 in the form having a layout in accordance with Fig. 4.
  • the ISPID 40 is an identifier, with the same characteristics as the CPID 30, with the difference that it identifies the ISP 12 rather than the CP 18.
  • ISP 12 can either pass back the CP 18 cost code or modify it to reflect a different cost, defined by an agreed ISP-CP business model.
  • the CP 18 receives the ISP-modified end-user 14 response, the CP analyzes the ISP 12 ticket 22 and verifies the ISP 12 and the ticket 22 authenticity in the same manner the ISP 12 verified the CP 18 ticket 22.
  • the CP may, for different reasons, decide to reject the accepted proposal. Either if the credit limit of the ISP 12 has been exceeded, or the cost proposed by the ISP 12 is not acceptable by the CP 18.
  • CP 18 refers to its queued list with issued tickets 22 to verify that the received
  • CP 18 ticket 22 has been correctly issued and not being timed out.
  • Associated request data stored with the queued ticket 22, is used to complete the end-user 14 content request.
  • the billing scheme described shows a straight-forward implementation of an ISP 12 handled batch-wise billing method for maximum end-user 14 convenience.
  • An ISP 12 may, according to its own ethical, social and religious objectiveness, classify each CP 18 signing up for a business agreement into different categories, also setting a quality standard for each CP 18, which can be presented for the end-user 14 prior to accepting a proposal.
  • End-user 14 feedback about concerned CP 18 can be collected and moderated by the ISP 12, creating a "popularity factor". Together with this factor, the end-user 14 can review other end-user 14 experience of the CP 18 prior to accepting a CP 18 proposal, probably increasing end-user 14 confidences about accepting or rejecting proposals from unknown CP 18.
  • the ISP 12 can further decide to terminate an agreement with a CP 18 receiving too many complaints from end-user 14.
  • the ISP 12 can assure end-user 14 confidence of the system, by allowing the end-user 14 to access a restricted private control panel page, where certain tasks can be automated and the end-user 14 personal preferences can be set, such as maximum allowed balance due, maximum purchases per day, per week etc.
  • Specific ISP 12 classifications can be enabled for access, such as financial information, news and weather, where others, like violence, pornographic, and game sites can be explicitly disabled or restricted for access. Restricted access may include ISP 12 initiated warning messages, or ISP 12 verified password entry to accept a CP 18 proposal.
  • New end-users 14 or other groups of end-users 14 may, depending on the ISP 12 judgment, be required to pre-pay an initial retainer for access to billed services. When the retainer has been exhausted, the ISP 12 will reject further access attempts until the retainer has been restored to a preferred limit.
  • ISP 12 may have special tariff agreements with a specific CP 18, allowing billing structures between ISP 12 and CP 18 to be different from the billing structures between the end-users 14 and the CP 18.
  • CP 12 may have special agreements with the SP's top-ten most visited CP 18, where a fixed billing rate applies, whereas the ISP 12 charges end-users 14 for each used ticket 22.
  • An ISP 12 may include a fixed free amount of content into their fixed monthly fee. On-line charity and aid organizations can act as CP 18, enabling a highly efficient method of collecting small funds, without the normal cost overhead involved.
  • Fig. 5 and Fig. 6 illustrate the ticket 22 of the present invention for an intra ISP 12 content payment.
  • the fields in the ticket 22 correspond to those depicted in Fig. 3 and Fig. 4.
  • the requested CP 18 service is not free of charge.
  • the CP 18 has a billing agreement with its ISP 12, i.e., the ISP2.
  • the CP 18 server normally responds.
  • the CP 18 places non-free services in a defined root catalogue, known by ISP2. included in the HTTP request is a Universal Resource Identifier (URI) part, which identifies the relative path of the root IP address obtained from the DNS query.
  • ISP2 analyses all incoming HTTP request to each CP 18 it has billing agreements with and verifies the URI, using a CP 18 provided list, to determine if the service is free to use or not.
  • URI Universal Resource Identifier
  • the ISP 12 intercepts the HTTP GET request and responds with a default response to the requester, optionally including ISP2 and/or CP 18 clear-text defined advertising and content description, stating that the requested service is not available, due to that there is no billing agreement in place between ISP1 and ISP2.
  • a default response to the requester optionally including ISP2 and/or CP 18 clear-text defined advertising and content description, stating that the requested service is not available, due to that there is no billing agreement in place between ISP1 and ISP2.
  • Embedded within the response is an invisible tag, such as a hidden field or a meta-tag, with an ISP 12 issued "ticket" 22.
  • the ISPED2 50 in Fig. 5 is an identifier, uniquely identifying the ISP 12. Practically, this can be any Internet Protocol (IP) number held by ISP2, as central authorities issue them and guarantees their uniqueness.
  • IP Internet Protocol
  • a central authority may issue phantom IP-numbers to uniquely identify ISP2. Any fraudulent issuer, trying to masquerade the IP address of an ISP 12, will not affect the security of the system, as will be obvious from the present description.
  • a default response, issued by ISP2 is addressed for requesters accessing through an ISP 12, which has no billing agreement with ISPl.
  • ISP2 analyses all incoming HTTP responses, and searches for the well-defined hidden field, holding a ticket 22. If an invalid, or no ticket 22 is found, the response is passed back, unmodified to the user. If ISPl finds a valid ticket 22, i.e. the identity and layout matches, then ISPl searches its list of known ISPs 12, to find out if it has a billing agreement with ISP2. If not, the response is passed back, unmodified to the user.
  • ISPl finds a valid billing agreement, it analyses the response and translates the cost-code into a cost in local currency, about to be billed to the user's ISPl account.
  • the actual cost is likely to be defined by an agreement between ISPl and ISP2. This agreement may be different from the agreement between ISP2 and the CP 18. Further; ISPl inserts a second ticket 22, similar to the one issued by ISP2.
  • ISPl ID 60 in Fig. 6, equivalent in scope to ISP2ID, holds a unique identifier, identifying ISPl.
  • ISPl inserts information and functionality in a response form, including easy-to- understand information how to accept or reject the offer proposed by CP 18, ISP2 and ISPl. This is typically made, presenting a text like "This request will cost you $0.10, which will be charged to your [ISPl] account. Do you want to proceed?" followed by an "Accept” and a "Reject” button or the like. Pressing "Accept” will typically result in a HTTP submit POST operation being passed back to ISP2, through ISPl.
  • ISP2 analyses incoming requests and searches for a valid issued ticket 22 in its issued tickets list. Typically, each ticket 22 has a limited lifetime, where ISP2 discards all tickets older than, for example, three minutes. If either ISPl or the user rejects the proposal, no response is being sent to ISP2, resulting in a ticket 22 timeout.
  • ISP2 If a valid ISP2 ticket 22 is found, a search for an ISPl ticket 22 is performed. If the ISP 1 ticket 22 is found, ISP2 verifies if it has a billing agreement with ISP 1 , which is the most likely situation, as ISPl would not issue a ticket 22 otherwise. If found, and verified correctly by ISP2, the request is passed back to the CP 18.
  • ISPl may at any moment decide to terminate its agreement with ISP2, as it can instantly determine the origin of the proposal, whereas the same applies to ISP2.
  • a negotiation process may be initiated between ISP2 and ISPl, where the cost proposal of ISP2 may be modified by ISPl and included in its ticket 22. ISP2 may decide if the proposal is to be accepted and rejected.
  • on-line account verification and clearing can be performed, as the cost of the request is known by each part. From ISPl's point of view, a cost proposal can be verified by the user's current balance due, and ISPl may decide to reject it if the user's credit limit is exceeded.
  • ISPl analyses the acceptance HTTP post, it is able to on-line update the user's current debt. From ISP2's point of view, the same rules may apply, and ISP2 may decide to reject an approved proposal if ISPl' s outstanding debt is too high or overdue.
  • the clearance process between ISP2 and ISPl may either be performed on-line or batch-wise, where both parties can verify their both lists of collected and issued tickets.
  • each ticket 22 may be extended to hold a content descriptor, originally supplied by the CP 18.
  • Each ISP 12 may decide to subclass each content class with information defining its own subjective classing, based on advertising content, objectiveness, offensiveness, violence content, social-, ethical- and cultural correctness etc. The receiving party may decide to rely on and to use that information or not.
  • ISP2 classifies one CP 18 as "news”, “medium objectiveness”, “low offensiveness”, “Christian values”. ISPl receives that information, and considers parts of the sub classing as “too subjective”, based on the own subjective classification of ISP2, but decides to keep "news” and "low offensiveness” as key elements, shown to the requesting user. ISPl may decide to fully, or partly, automate its sub classing process, based on user feedback, reflecting the median values of its customer base. An automated "Customer feedback survey form" may voluntary collect information, automatically updating ISPl records. The ISP2 sub-classification may in the same way be updated by feedback from ISPl etc.
  • a CP 18 ranking and politeness service may be implemented, where complaints sent back from users to ISPl, automatically, or semi- automatically updates a "Customer rank" figure maintained by ISP 1. This ranking may be presented to the user as a part of the approval process.
  • the described invention creates a fundament for an easy to understand, hard to circumvent, implementation straightforward structure for billing with a minimum of obstacles for an end-user 14.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention a trait à un procédé consistant à lier un billet de facturation (22) à un protocole de transfert, tel qu'un protocole HTTP, destiné à la communication sur un réseau ouvert (10), pour la transmission de données et la télécommunication entre un utilisateur final (14), un fournisseur de services (12) et un fournisseur de contenu (18). L'invention concerne également un billet (22) correspondant.
PCT/SE2002/001742 2001-09-24 2002-09-24 Billet et procede de facturation WO2003027933A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US32407001P 2001-09-24 2001-09-24
US60/324,070 2001-09-24
US32428001P 2001-09-25 2001-09-25
US60/324,280 2001-09-25
US32517501P 2001-09-28 2001-09-28
US60/325,175 2001-09-28

Publications (1)

Publication Number Publication Date
WO2003027933A1 true WO2003027933A1 (fr) 2003-04-03

Family

ID=27406310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2002/001742 WO2003027933A1 (fr) 2001-09-24 2002-09-24 Billet et procede de facturation

Country Status (1)

Country Link
WO (1) WO2003027933A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974309A (en) * 1996-05-03 1999-10-26 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for facilitating law enforcement agency monitoring of cellular telephone calls
WO2001009743A1 (fr) * 1999-08-02 2001-02-08 Tb Soft Inc. Procede pour le traitement de l'imputation comptable avec l'internet

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974309A (en) * 1996-05-03 1999-10-26 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for facilitating law enforcement agency monitoring of cellular telephone calls
WO2001009743A1 (fr) * 1999-08-02 2001-02-08 Tb Soft Inc. Procede pour le traitement de l'imputation comptable avec l'internet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LEI TANG ET AL.: "Chrg-http: a tool for micropayments on the world wide web", PROCEEDINGS OF THE SIXTH ANNUAL USENIX SECURITY SYMPOSIUM: FOCUSING ON APPLICATIONS OF CRYPTOGRAPHY, 1996, BERKELEY, CALIF., pages 123 - 129, XP002962811 *

Similar Documents

Publication Publication Date Title
US9805090B1 (en) System and method for processing database queries
JP4717886B2 (ja) 電子メールを規制する方法及びシステム
US9979830B2 (en) Clearinghouse server for internet telephony and multimedia communications
FI113224B (fi) Laskutuksen toteuttaminen tietoliikennejärjestelmässä
US6654779B1 (en) System and method for electronic mail (e-mail) address management
AU2002340207B2 (en) Verification of a person identifier received online
US6795919B1 (en) Unique digital signature
US20020194140A1 (en) Metered access to content
US20050254514A1 (en) Access control of resources using tokens
US20030233329A1 (en) System and method for providing subscription content services to mobile devices
US20070006286A1 (en) System and method for security in global computer transactions that enable reverse-authentication of a server by a client
US7788485B2 (en) Method and system for secure transfer of electronic information
WO1998024208A9 (fr) Systeme de communication de donnees
EP0940024A2 (fr) Systeme de communication de donnees
US7782881B1 (en) Method and apparatus for traffic quality and billing authorization by request token insertion
US7127231B2 (en) Method for operating a billing system associated with a mobile radio network for billing for tariffable use of data, and data transmission network
JP2000151811A (ja) インターネット接続装置
JP2003242117A (ja) アクセス管理方法及びシステム
US20050102526A1 (en) System governing the sending and delivery of electronic mail using an eMstamp
MXPA01013117A (es) Sistema y metodo para puesta en vigor de politica local para proveedores de servicio de internet.
WO2003027933A1 (fr) Billet et procede de facturation
JP2003258841A (ja) 料金還元システムおよび方法、ゲイトウェイ装置
CN117278192B (zh) 一种基于区块链的反垃圾邮件系统
EP1940120B1 (fr) Procédé et système pour fournir des publicités personnalisées aux utilisateurs de dispositifs de communications électroniques
CN1318246A (zh) 用于建立数据连接的连接单元和方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP