Service provider architecture and method for delivering content services to mobile communication customers

[0001] The present invention is related to billing systems for billing customers, in particular prepay customers for mobile/cellular telecom services.

[0002] With the existing emerging new services such as Web originated SMS, WAP services and m-commerce, all accessed using cellular phones, billing of services becomes more and more complex. Further, a lot of services are only available to so-called postpaid customers, i.e. subscription customers, and tariffs for a specific service may be subscription-specific (e.g. free for high-end subscribers, paying for low-end subscribers). This usually leads to development of a different architecture per service to cope with these differences, as the content provider usually is not aware of the customer's privileges.

[0003] New ways of paying for products and services via mobile telecommunication means are currently being introduced. Products include for example drinks obtainable from a distributor in a public place, while services can be, e.g., parking spaces or movie tickets. Also, so-called mobile banking will be available soon. These systems rely on a subscriber account, which can be used to pay for products and/or services by using a cellular phone. The prior art document W098/21874 describes a system for revaluing, via a central network system, prepaid cards used by prepaid type customers of a mobile network. Such a prior art system is shown in the boxes 35,37 in FIG. 4, detailed in the sequel.

[0004] Currently, there is no available architecture that can handle all these services, and there is no architecture available that enables all these services in a transparent way for post- and prepaid customers. Furthermore, it should also be possible to settle a balance which may be due by the content provider to the telecommunication service provider.

[0005] The present invention aims to provide an architecture for the service provider which realizes payments and billing of content provided to a customer, independent of the type of customer (postpaid or prepaid), the platform or the content itself.

[0006] In a first aspect of the present invention a service mediator system is disclosed, the service mediator system being implementable on a computer environment and being arranged for delivering services to a customer of a company having at least two types of customers with different billing data, said system further being arranged for delivering said services or confirming the service for delivery only after verification of the billing data. The services can optionally include the determination of the location of the customer. The determination of the location of a customer can also be done through an additional module that is connected to or part of the service mediator system and that is further linked to a communication system such as telecommunication system, for instance a GSM or GPRS or UMTS or any cellular network, or a GPS/GLONASS system. The services can be taken from or be provided by a third party and be forwarded by the system to said customer. Said system can bill the customer separately from delivering said services to said customer. The services can in such case be payment confirmation messages followed by the signalling of predetermined events such as goals in a soccer game.

[0007] In a preferred embodiment of this first aspect of the present invention, said services can be content data being delivered by a third party content provider and the company can be a mobile telecommunications operator company. In such case, or also in other cases, as an option, said content data can be selected depending upon the location of the customer. For example, a customer can request through his mobile terminal information about traffic or about a restaurant location in the same area (or even region) to a content services company. Through the location service of the mobile telecommunications operator, the location of the customer is forwarded to the content services company, and based on that location information, the content services company will forward the location or area or regional specific data, such as the specific location dependent traffic or restaurant information.

[0008] Content data such as location data can also be sent from the customer to the third party content provider.

[0009] In a second aspect of the present invention, a service mediator system is disclosed, the system being implementable on a computer environment and being arranged for receiving via mobile communication techniques content from a content provider and being addressed to a customer, the system being arranged for verifying the customer's billing data, and for forwarding or confirming to the content provider the approval for delivery or refusing a transaction of the content to the customer based on the customer's billing data.

[0010] According to the first and second and further aspects of the present invention, the customer's billing data comprise data about the type of customer (prepaid or postpaid), and/or data about the account of said customer, and/or data about the subscriber account of said customer. The content service can be any kind of existing or future service that can be obtained with a mobile telephone. Preferably, the services are different from revaluing the amount on a prepaid card used by a customer for accessing a mobile network via a mobile telephone. This includes SMS, Web-originated SMS, WAP, i-Mode, banking services, credit services, on-site payment for services (e.g. parking lot) or products (e.g. drinks dispenser). The content service furthermore can include information about the weather forecast, traffic information, horoscope predictions, sweepstake information, flight information, financial and exchanges information, cultural and social events, nightlife in a city, etc. The service provider system of the invention can be used for any mobile communications technology such as UMTS, GSM, WAP, I-Mode GPRS, or any future mobile communications technology, and making use of any protocol such as XML or mobile html or UCP or other protocols. The content can be requested by the customer from the telecom service provider, possibly via the service mediator system, or can be requested by the customer directly from the content provider, possibly via the telecommunications network of the telecom service provider. The content can also be delivered by the content provider to the customer without a request of the customer or can be delivered on a regular basis based on a first request for content from the customer.

[0011] In a third aspect of the present invention, a service provider system for providing content services to a mobile communications customer is disclosed, said system comprising:

• • [0012] a telecom services provider system wherein or wherethrough a link is provided to a content provider system, and
  • [0013] a service mediator system,

[0014] and wherein said service mediator system is arranged to

• • [0015] receive said content from said content provider,
  • [0016] allow or refuse or confirm the transaction to the customer based on the customer's billing data,
  • [0017] and optionally, in case of allowance, provide said content service to the customer, and optionally
  • [0018] bill said customer for the content.

[0019] The content service can be any kind of existing or future service that can be obtained with a mobile telephone. This includes SMS, Web-originated SMS, WAP, i-Mode, banking services, credit services, on-site payment for services (e.g. parking lot) or products (e.g. drinks dispenser). The content service furthermore can include information about the weather forecast, traffic information, horoscope predictions, sweepstake information, flight information, financial and exchanges information, cultural and social events, nightlife in a city, etc. The service provider system of the invention can be used for any mobile communications technology such as UMTS, GSM, WAP, i-Mode, GPRS, or any other and/or future mobile communications technology, and making use of any protocol such as XML or mobile html or UCP or other protocols.

[0020] The content can be requested by the customer from the telecom service provider, possibly via the service mediator system (SMS or web based), or preferably can be requested by the customer directly from the content providers, possibly via the telecommunications network of the telecom service provider. The content can also be delivered by the content provider to the customer without a request of the customer or can be delivered on a regular basis based on a first request for content from the customer (push messages).

[0021] Preferably, the system according to this third aspect of the present invention is at least partly implemented on a computer environment.

[0022] The service provider system according to this third aspect of the present invention can be further arranged in that said service mediator comprises a payment/billing server arranged to perform validation of the customer's request and payment and/or billing for the content service. This payment/billing server is preferably a database, comprising customer data such as type of customer: (postpaid or prepaid); subscriber accounts: billing information (for postpaid customers) and prepaid account information (for prepaid customers). Thus the term billing data is to be understood as comprising data about the type of customer (postpaid or prepaid)and about the actual prepaid balance or the account information of the customer.

[0023] In a fourth aspect of the present invention, a method for providing content services to a mobile communications customer is disclosed, said method comprising the following steps:

• • [0024] receiving a customer request for a content service by a content provider, optionally comprising the step of receiving the customer request for the content service by a mediator and transferring it to the content provider,
  • [0025] delivering the content service to a service mediator, the service mediator optionally being the same as the mediator,
  • [0026] wherein said service mediator performs the following steps:
  • [0027] allowing or refusing of the transaction to the customer based on the customer's billing data,
  • [0028] in case of allowance, providing said content service to the customer or confirming to the content provider approval for delivery to the customer, and optionally billing the customer and/or content provider for the content.

[0029] The method can be further characterised in that the customer's billing data comprises data about the type of customer (prepaid or postpaid), data about the account of the customer, and optionally data about the subscriber account of the customer.

[0030] In case the customer is a prepaid customer, said step of billing the customer can comprise withdrawal of the required sum from the customer's account.

[0031] The customer can also be a postpaid customer. The method of the present invention can be further characterised in that the step of billing the customer comprises withdrawal of the required sum from an m-commerce account.

[0032] In a preferred embodiment, the method further comprises the step of billing the customer for the transport of the content.

[0033] The present invention thus provides a reliable and economically efficient method and system for delivering content services to mobile subscribers. The mobile subscribers may be both prepaid and postpaid subscribers. Also, using the present system and method, it is possible for a telecommunication service provider to settle balances due by the content provider, e.g. for using the service mediator functionality.

[0034] The different aspects and embodiments of the invention as described hereabove or in the detailed description can be combined according to the knowledge of the person of skill in the art as reading this patent text.

[0039] For the purpose of teaching of the invention, preferred embodiments of the method and systems 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 limited only by the appended claims as finally granted.

[0040] FIG. 1 describes the method of the present invention in the specific case of SMS billing. A customer 20 sends in a request for a content service, in this case an SMS message 1. This message is sent by the telecom service provider 22 to a content provider 23. This content provider 23 reacts to the message by sending the desired content to the service mediator 24 via message 2. The service mediator 24 will check whether the customer is entitled to the content service. If allowable, the content is sent to the customer using links 4,5. The Payment/Billing server 27 takes care of charging the customer's prepaid account, or sends an SDR (Service Detail Record) to the Telecom Service Provider's billing services to include the content service on the next bill for the postpaid customer. It is an option to include the converters 25, 26 which transform UCP messages to XML messages and vice versa into the service mediator module, as this allows for a unified standard language within the service mediator/payment/billing server module such as XML, and is also useful to deal with requests in different languages, as these requests will be translated by the converters 25, 26.

[0041] FIG. 2 describes the method of the present invention in the specific case of WAP services. Here again the request for a content service, a WAP request in this case, is sent to a content provider's site (CP Site) 23 via WML message link 6. These requests are direct and the customer 20 can select the information he needs by browsing the site of the content provider 23, or change content provider 23 when he does not find the information he needs. A request for a paying content service will transfer the customer 20 to a payment portal site 28 using WML message link 7. The payment portal site 28 receives data from the content provider 23 (e.g. amount, transaction identification number and content-provider code) via WML message link 8. The customer 20 will be authenticated at the payment portal site 28 and is requested to confirm the payment via link 7 or via another WML-link. When the customer agrees, the payment/billing server will be queried to check whether the customer is entitled to the service via XML link 9, converter 26 and XML link to the Service Mediator 24. If the answer is affirmative, the payment will be effected as described higher and the content provider 23 will receive a confirmation of the payment via WML message link 10. The customer will be redirected to the content provider's site to receive the requested content services via WML message link 6.

[0042] It is clear that the method and the system of the present invention can be easily adapted to other content services than those illustrated by the figures and examples. More particularly SMS, Web-originated SMS, UMTS, WAP, i-Mode banking services, credit services, on-site payment for services (e.g. parking lot) or products (e.g. drinks dispenser), . . . are easily implementable using a single architecture. Also subscriber accounts can be charged using the method of the invention, internal accounts (i.e. accounts that reside at the Telecom Service Provider) as well as external accounts (e.g. banks, credit card companies).

[0043] The Service Mediator 24 has as a goal to deal with providing the content service to the customer and with the payment issues. The Payment/billing server 27 allows to query customer data and effectuates the payment.

[0044] Preferably, the telecom transport costs for providing the service are billed separately. This can easily be implemented using a tariffing server. This is necessary because not all traffic generated by the content request will be normal traffic, billable by the telecom service provider but can be, e.g., internet traffic.

[0045] It is also possible to settle the costs for the content provider by the telecommunication provider (payment/billing server), possibly with inclusion of costs payable by the content provider to the telecommunication provider.

[0046] FIG. 3 shows a flow diagram of an embodiment of the present method as implemented for delivery by the service mediator of SMS messages from a content provider 23. The flow can be divided in two interrelated parts, the Service Switching Function (SSF) and the Service Control Function (SCF). The SSF part receives a message of the provider at block 40 and searches for the data which are necessary to properly process the message in an administrative manner. These data are sent to the SCF. The Service Control Function first checks whether the customer is a prepaid subscriber at decision block 50. If the customer is a prepaid subscriber, the balance value is looked-up in block 51 and in decision block 52, it is checked whether the balance is sufficient. If a sufficient balance is present, a ‘GO’ message is sent to the SSF (block 54). If an insufficient balance is present, a ‘NOGO’ message is sent to the SSF (block 53) and the SCF flow is ended. In the meantime, the SSF function has waited for a response from the SCE in block 41. In decision block 42, the response is checked. When the response is negative (NOGO), a negative acknowledgement (NACK) is sent to the provider in block 43 and the flow of the SSF ends. When the response is positive (GO), the message is converted and sent to an SMS center (SMSc) in block 44. After that, the SSF function will wait for a response from the SMS center in block 45, and after receiving the response, this response of the SMS center is sent to the SCF in block 46. When the response from the SMS center is positive (check in decision block 47), a positive acknowledgement (ACK) is sent to the provider in block 48 after which the flow ends. When the response from the SMS center is negative (check in decision block 47), a negative acknowledgement (NACK) is sent to the provider in block 49 after which the flow ends. When the SCF receives the response of the SMS center (after waiting in block 55) it checks in decision block 56 whether the response is positive. If the response is negative, the flow of the SCF ends. If the response is positive, it is again checked in decision block 57 whether the customer is a prepaid customer. If this is the case, the balance is decreased with the proper amount in block 58. When the customer is a postpaid subscriber, the flow directly continues to block 59, in which a call detail record (CDR) is written to the SMI, after which the flow ends. Thus, the amount for the service will only be charged when the message transaction has actually taken place.

[0047] In a best mode embodiment of the invention, as depicted in FIG. 4, a service mediator system that is implemented for a mobile telecommunications operator and that is on the basis of a Message Broker software module is described. In the existing situation, the content provider 23 communicates directly with the customer 20 via the SMS center (SMSc) 33, as indicated by arrow 30. The Message Broker can be any one of the commercially available message broker products of major software companies. An example can be the impact product of the company Sybase (NEON). The message broker is split in a protocol layer 31 and a message broker layer 32. The message broker layer 32 is connected to a SMSc module 33 and to the Operational Data Store of the customers database (ODS) 34, and to the Prepaid Billing System 35. The protocol layer 31 is arranged for communication with a content provider system 23 and can communicate therewith via a UCP or a XML protocol. The protocol layer 31 and message broker layer 32 can communicate among them via a fast internal protocol. The message broker layer 32 can communicate with the SMSc module 33 via UCP protocol and to the Operational Data Store of the customers database (ODS) 34 via LDAP (Lightweight Directory Access Protocol) protocol, and to the Prepaid Billing System 35 via a XML protocol. The message broker layer 32 can in a further embodiment also communicate with a location base server 36 using a suitable protocol. The SMS centre 33, the Operational Data Store of the customers database (ODS) 34, the prepaid billing system 35, and the location base server 36 can also communicate with a background server (BG) 37 of the telecommunication service provider. The background server 37 is arranged a.o. to control and update the other elements of the present system.

[0048] The service mediator 24 can check the status of the customer by querying the Operational Data Store 34. Using the MSISDN number of the customer 20 (country code, telecom provider code and serial number, e.g. 31653123456) as input, the Operational Data Store will respond with the status of the customer (prepaid, postpaid, none and blocked flags). When the Operational Data Store 34 responds with the status ‘none’, that particular customer is not a subscriber of the telecommunication provider operating the service mediator 24. It is also possible, that a known subscriber will be blocked from certain services for a number of reasons. This situation will be indicated by the Operational Data Store 34 using the blocked flags.

[0049] In FIG. 5, a schematic diagram is shown in which use can be made of location information of the customer for providing information by a content provider 23. A customer 20, using a cellular phone, contacts a content provider 23 to indicate that local information is needed. The content provider 23 forwards this request to the service mediator 24, as discussed earlier. The service mediator 24 may send a request for location information of a customer to a location base server 36, e.g., by using the MSISDN number of the customer as a reference. The location base server (LBS) 36 receives information on the present location of the customer 20, e.g., using information of the cellular network (transceivers 38, location database 39). Next, the service mediator 24 receives the co-ordinates (X,Y) of the associated customer and forwards this to the content provider 23. When it is checked that the content provider can supply proper local information, the content provider 23 will send the information to the service mediator 24 which will forward the content as described earlier to the customer 20. The service mediator 24 will send an acknowledgement to the content provider 23, if the customer could be billed.

[0050] The information provided by the content provider 23 may include information requested instantaneously by the customer 20, periodic information, such as traffic information, or event generated information, such as a stock value crossing a preset threshold.

[0051] As described with reference to FIG. 4, the service mediator 24 may provide a UCP, such as a UCP51, or XML interface for the content providers 23. Other messages will be replied to with an error message or ignored (unknown messages).

[0052] In a UCP51 type message, a tariff field may be included (preferably in the XSER field), which indicates the tariff the content provider 23 wants to charge for that specific service to the customer 20. The service mediator 24 will parse the received messages, by checking the type of message, the LEN field in the header and the checksum of the UCP message. After this, the service mediator 24 will remove the tariff field from the UCP message and send the UCP message onward (e.g. to the SMS center 33). In this way, the service mediator 24 is a transparent system for the content provider 23 with respect to UCP messages (with the exception of the tariff field.

[0053] The service mediator 24 will manage a provider profile file, in which it is indicated what actions are allowed for a specific content provider 23. This may relate to a specific interface which may be used by a specific content provider 23 (such as UCP, XML single destination or XML multiple destination), or to a specific function provided by the service mediator. The number of allowed functions for a content provider 23 may be equal to zero, thereby effectively blocking that content provider 23.

[0054] The service mediator is able to notify a subscriber (customer) when a message can not be delivered for some reason, such as insufficient funds in the prepaid account. Preferably, the text which is sent to the customer is dependent on the originating content provider. This function of the service mediator 24 can also be disabled for a specific content provider 23. In that case, it is assumed that the content provider 23 will itself inform the customer.

[0055] Also, in the provider profile, a maximum amount for a service can be set for each provider. When the service mediator 24 receives a message in which the tariff as indicated is higher than the maximum amount for that content provider, the service mediator 24 will not accept the message (and inform the sender of the message using an error code in the response message).

[0056] The service mediator 24 will also check the length of a message. In case of an alphanumeric message, the maximum number of characters in the message is 160. When it is larger, the message will not be accepted. Transparent messages are already limited to 140 characters and this will not conflict with further system requirements. For transparent messages, no check on length is necessary.

[0057] The throughput for each content provider 23 is measured by the service mediator 24. When a preset maximum is crossed for a certain content provider 23 (as stored in the provider profile) the throughput of that content provider will be limited by delaying the response to a message (ACK/NACK). The maximum throughput is defined as X messages in Y seconds.

[0058] In order to be able to control peak loads more efficiently, the service mediator 24 can define one or more time slots, in which a predetermined content provider 23 has access or no access to the system. This access time window function is relevant for a limited number of content providers 23 which have high throughput values. For ‘small’ content providers 23, this function is not relevant, and this can be indicated in the provider profile. The time window function can be implemented on the TCP/IP connection level. In that case, the service mediator 24 must be able to disconnect the TCP/IP connection to the specific content provider 23.

[0059] To be able to control the throughput of a content provider 23, it is also possible to set the maximum number of parallel connections for each content provider 23 in the provider profile. When a content provider 23 wants to open additional sessions, the service mediator 24 will ignore these messages and send an error code to the content provider 23.

[0060] The service mediator 24 will log various data concerning the processing of the transactions in log files. A number of generic requirements are set for the log files, i.e. starting time, maximum time that file is open, maximum size of the log file and manual closing of a log file to allow an operator to inspect the log file. As the service mediator 24 may be implemented in a parallel manner, i.e. a number of servers may run the service mediator functionality, the log files of each server may be copied periodically to a central logging server. It is also possible to post-process the log files, e.g. for data reduction or system analysis.