METHOD OF, AND MEANS FOR, PAYMENT OF INFORMATION SERVICES
DELIVERED OVER THE AIR
The present invention relates to a method of, and means for, payment of information services delivered over the air.
Information services between an internet server and a personal computer (PC) have existed for some years.
Some of these services include information retrieval from information content providers specialising in topics, such as sports, stock exchange prices and weather, and business activities, such as banking, insurance and electronic commerce, so called e-commerce. More recently there have been developments to enable the information services to be available to users of portable telecommunications devices, such as cellular telephones. Normally the cost of providing services to a user has been done by periodic billing from a service provider. Billing individual users is time consuming and costs money to implement .
The present invention aims to facilitate the delivery of information to subscribers of portable telecommunications devices.
According to one aspect of the present invention there is provided a method of delivering subscription service information from an information content provider to a subscriber, comprising a subscriber forwarding an information request to a server, the server contacting
the information content provider having a data base holding the information being requested giving contact details of the subscriber, and the information content provider communicating directly with the subscriber to supply information requested by the subscriber.
According to a second aspect of the present invention there is provided an information service system comprising a plurality of subscriber units, a server, at least one information content provider and a communications link, the subscriber unit having communication means whereby a subscriber unit wanting to be supplied with information sends a request to the server, the server having means for alerting the at least one information content provider to the request and providing details of the subscriber unit making the request, the at least one information content provider having means whereby the information requested is transferred to the subscriber by way of the communications link.
According to a further aspect of the present invention there is provided a method of charging a user for use of an information service, comprising a user initiating a call with a server using a non-premium rate link and the server connecting the user to an information contend provider by way of a premium rate link for the duration of the time that they are connected, wherein a network provider determines the user's usage of the premium rate link and submits a charge to the user, the information content provider and/or the server being reimbursed by the network operator.
According to a further aspect of the present invention there is provided an information service system comprising a plurality of subscriber units, a server, and at least one information content provider, means for operatively coupling a subscriber unit to a server by way of a non-premium rate link, and at least one premium rate link selectable by the server for coupling the at least one information content provider to one of a plurality of subscribers .
According to a further aspect of the present invention there is provided an internet service comprising means for effecting communication with respective ones of a plurality of subscriber units, means for effecting communication with at least one information content provider, and means responsive to a request from a subscriber unit to be placed in communication with the at least one information content provider for effecting a connection by way of a premium rate link.
Other preferred features will be apparent from the following description of the appended claims.
The present invention will now be described, by way of example, with reference to the accompanying drawings, wherein:
Figure 1 is a diagram of an architecture of a service delivery model using various message delivery protocols,
Figure 2 is a simplified block schematic diagram of a mobile switching centre and base station and of a handset,
Figure 3 is a flow chart illustrating the processing of a short packet message signal by a client in a handset ,
Figure 4 is a diagram of a client,
Figure 5 illustrates an encoding format for media information, Figure 6 illustrates the GSM format of header information,
Figure 7 illustrates a SMS client software overview,
Figures 8A, 8B and 8C illustrate the command data flow in the client, Figure 9 is a diagram illustrating how a subscriber can obtain information from an information content provider, and
Figure 10 is a flow chart illustrating a user being routed to an information content provider by a premium rate link and for the user to be billed by the network provider.
In the drawings the same reference numerals have been used to indicate corresponding features.
Referring to Figure 1, the message delivery architecture comprises an internet based server 10 which is coupled by suitable links to an application data base 12 which in turn is coupled to an information content provider 14, a user profile store 16 and to a billing system 18 by which a user is charged for the services provided. The billing system 18 is also linked to the internet based server 10.
Users can fall in several categories depending on the method of delivery of messages from the internet based server 10.
One category of delivery is by using a short message service (SMS) over the GSM network to an SMS enabled phone 20 which contains or has access to a "client", that is, a software package capable of processing or parsing the SMS messages in a predetermined manner. More specifically the server 10 is coupled to a short message service centre (SMSC) 22 which in turn is coupled to a Mobile Switching Centre (MSC) 24 of the network. The MSC 24 is coupled to geographically distributed base station transceivers 26 which propagate/receive messages to/from the SMS enabled handset 20.
A second architecture is based on the messages from the server 10 being relayed to a Wireless Applications Protocol (WAP) server 28 which sends and receives WAP messages to a WAP enabled handset 30 containing, or having access to, a client.
A third architecture is based on a PC 32 equipped with a client and a two way radio link to a web site 34 which is coupled to the server 10.
The various messages are indicated by the letters (A) , (B) , (C) and (D) . Message (A) relates to the handset 20 or 30 or the PC 32 requesting delivery of a service through the SMSC 22, WAP server 28 or the website 34, respectively. Message (B) is passed to the server 10 which recognises a server enabled service. Message (C)
denotes the server 10 despatching the requested service to the device with added features and embedded commands. Message (D) relates to the content/service being delivered by way of the SMS, WAP or WE8 to the client device which creates the required enhanced end user experience .
Besides WAP and SMS message protocols other message protacols may be used such as USSD, GPRS (General Packet Radio System) , and UMTS (Universal Mobile Telephone System) .
Figure 2 is a much simplified block schematic diagram of the GSM network as represented by the short message switching centre (SMSC) 22, the mobile switching centre 24 and the base station transceiver 26 and a SMS enabled phone 20.
A message received by the SMSC 22 on an input 40 is stored in a message store 42. A processor 44 determines the nature of the message and what commands, stored in a command store 46, should be included in the message to be formatted in a formatting stage 48. The formatted message with commands and an appended users address is encrypted in an encryption stage 50 and then channel coded in an encoding stage 52. The encoded SMS message is transferred by the mobile switching centre 24 to the base station transceiver 26 of the service area or cell in which the SMS enabled phone 20 is registered. The transceiver 26 transmits the SMS message as a downlink signal DNL.
An uplink SMS signal UPL from the phone 20 is received by the transceiver 26 and is routed by the mobile switching centre 24 to the SMSC 22. The signal is decoded in a decoding stage 54 and the decoded signal is decrypted in a decryption stage 56. The output from the stage 56 is applied to a deformatting stage 58 and the recovered message is forwarded to an output 60.
The phone 20 comprises a transceiver 62 having an output coupled to a decoder 64 for decoding a received SMS message. The phone includes a client 66 which for convenience of illustration is shown as a series of stages but in reality the client is a software package stored in the processor 78. The decoded signal is decrypted in a decryption stage 68 and its output is deformatted in a deformatting stage 70. A parsing stage 72 parses any commands present in the deformatting stage 70 and directs these on a line 74 to the processor 78. The message data, without the commands, is applied by a line 76 to the processor 78. The message data is stored in a RAM 80. The processor 78 operates in accordance with a program stored in a ROM 82 but any software changes to the stored program are stored in a patch ROM 84 which may be implemented as an EEPROM. In the case of a phone being a GSM phone, a SIM card 79 is operatively coupled to the processor 78.
A man/machine interface in the form of a keypad 86 is coupled to the processor 78. An LCD driver 88 has an input coupled to the processor 78 and an output coupled to a LCD panel 90. A ringer 91 is also coupled to the processor 78.
In the event of a phone user wanting to send an uplink message signal, the message is compiled and formatted in a stage 92 and its output is encrypted in a stage 94. The encrypted signal is channel coded in an encoder 96 prior to being passed to the transceiver 62 for onward transmission as an uplink signal UPL.
Figure 3 illustrates the operations when the GSM network 22, 24, 26 sends a packet message to a SMS enabled phone 20 including an embedded client 66 on a downlink DNL and the phone 20 transmits a request or reply on an upLink UPL .
A block 100 denotes the handset receiving a message from the GSM network in accordance with say the SMS, USSD or GPRS protocol. The block 102 indicates the client carrying out a parse operation which includes recovering encrypted commands. The block 104 indicates the handset itself operating in accordance with the commands which may require the handset to generate a response which is sent as a short message.
If this is the case then block 106 relates to obtaining a result which in block 108 is formatted by the client for onward transmission by the relevant short message service such as SMS, USSD or GPRS.
Figure 4 illustrates in a broken line box an example of the client software 66 which is operatively coupled to a GSM stack 62, a message RAM 80, ROMs 82, 84, a SIM card
79, a display driver and LCD screen 88, 90 and a ringer
91. The client software (or client) 66 is intended for use with byte stream data packet messages.
A point of connection between the software of the GSM stack 62 and the client proper is a TP_PDU (Tag Parser- Protocol Data Unit) encoder 132. The encoder 132 is a translation layer for translating TP_PDUs into the byte stream representation required by a byte stream parser 134. The parser 134 parses the byte stream and fills in a command structure (comprising a doubly linked list of command elements) for each time discrete operation (or series thereof) in the transcribed SMS byte stream. An operation in this context is a collection of events, which occur, or appear to occur, at the same time to the user, for instance a play tone and an associated icon animation (referred to in the art as iconimation) .
The byte stream parser 134 delegates parsing of text information containing a forms mark-up language to a character based or forms parser 136. The parser 136 parses a stream of text generating a command element structure for each discrete prompt, that is, a reply pair in the form object and passes the element back to the tag parser where it is embedded in a command structure.
The parser 134 is also coupled to an engine 138 which presents an external API (Application Programming Interface) to the mobile phone software for the generation of SMS that include embedded media. A more important role of the engine 138 is to manage a queue of operations for incoming byte streams from the internet server 10, when in a receive mode. Each element of this
queue comprises a command structure. In the receive mode, the engine 138 is a very simple object which examines the control bits of the individual command elements and moves them either to the display server 140 or to the persistence server 142. The engine 138 will respond to call-backs from the display server 140 or persistence server 142 indicating that the operation has terminated
(successfully or unsuccessfully) . These call-backs will pass back ownership of the command to the engine 138 which may then place them into a queue as a new operation
(discarding any command elements with no control bits set) .
The display server 140 and the persistence server 142 interface directly with OME APIs in order to write to devices on the phone or the SIM.
A memory manager 144 is coupled on the one hand to the TP_PDU encoder 132, byte stream parser 134 and the forms parser 136 and on the other hand to the system RAM 80. The memory manager 144 serves for managing a dynamic memory allocation heap. Where a heap does not exist, the memory manager 144 will support a simple queue based dynamic allocation from a contiguous area in the phone's RAM. In one embodiment the dynamics of memory allocation is essentially two-fold, an allocation phase followed by a release phase. Heap usage generally falls to zero between messages. The fact that the client is essentially stateless means that there is no heap holdover from one message to another. This allows the use of a simple allocation algorithm in a small memory space.
Figure 5 illustrates a main tag format for encoded media information received by the client 66. The format comprises a repeating sequence of concatenated command elements EL 1, EL2. Each of these command elements comprises four fields, namely, a Tag byte 150, a control byte 152, a length of data field 154 which may be up to 4 bytes long and a data field 156. The Tag byte 150 can contain values from 0 to 255, giving 256 possible fundamental types of data, for example, text, graphics, banner (or logo) replacement, ring tone, sound and forms (used to manage the transfer of data between the phone and a service centre) . The control byte 152 includes various bit fields and flags for controlling how data is dealt with by the client. An example of the assignment of the respective bits is described as follows:
Bit 7 O -Operation toggle (a flag indicating the current operationO.
Bit 6 D - Display flag.
Bit 5 P - Persist flag.
Bit 4 R - Reply flag.
Bit 3 LI- Licence bit 1.
Bit 2 L2 -Licence bit 2. Bit 1 LL1-Length of length field 1.
Bit 0 LL2 -Length of length field 2.
Bit O -Operation toggle uses the concept of an operation to group events that must be simultaneous to the user, for example, the simultaneous playing of a ring tone with icon animation. Commands are grouped into operations
using the operation toggle. This is a simple switched bit in an incoming byte stream.
Initially set O, it is reset for every element of a new operation structure. For instance a sequence as follows :
Byte stream = {θ DPR 3210} + {θ DPR 3210} + (l DPR 3210}
+ {ODPR3210}
would evaluate to an operation queue as follows: Operation elements = {Command 1, Command 2} + {Command 3}
+ {Command 4 } . In each of the elements: D - represents a display flag which indicates to the engine 138 (Figure 4) that the data block following is displayed on the phone 20 (Figure 1) .
P - represents a persist flag which indicates to the engine 138 that the following block may be persisted upon the phone 20.
R - represents a reply flag which indicates to the client 66 that the following data block will invoke a SMS reply through the GSM stack 62 (Figure 4) to the MSC 24 (Figure 1) . L I and L2 - represent the licensing bits which allow tagging media as freely distributable, downloadable to a single phone or play and discard and so on. This licensing is mandated by the requirement for the client 66 to support point-to-point transmission of SMS containing embedded media.
LL 1 and LL2 - are 2 bits representing the length of the length field 154 in bytes. The indication of the length
of the length field 154 itself can range from 1 to 4 bytes. The bits LL1 and LL2 indicate the length of the following length field 154, for example [0,0] represents 1 byte ... [1,1] represents a 4 byte field which allows a maximum length of data field of 4.2 G bytes.
The data field depends on the fundamental data type indicated in the Tag byte 150.
The use of command context flags to control data flow in the client 66 is described below and an example of the various commands is given below.
On receipt of this byte stream, the client 66 moves along it examining the O bit of each tag byte for command element identifiers. It extracts linked command elements into a structure and adds this onto the engine's operation queue structure.
The tagged byte stream described above could arrive at the client 66 by any method, for instance it may just be a byte stream in a SMS body with an 8 bit user data coding stream. In an alternative arrangement the byte stream is embedded into the user-data-header field of a SMS .
A data field [up to 140 bytes] contains a number of characters indicated by the final field of the SMS header, the 1 byte user-data-length indicator (TP-UDL) . These characters are encoded according to the user-data- coding scheme (TP-UDCS) field of the SMS header. Therefore, if the user data coding scheme is default
(ASCII; 7 bit packed losing the most significant bit) 160 characters may be encoded in the user data area of 140 bytes. Accordingly the value of the TP-UDL field will alter if the data-coding scheme is 8 bit or UCS-2 (Unicode) to a maximum of 140 or 70 characters, respectively .
The GSM specification also allows some preamble to precede the text of the message, in the user data field, in the form of a user-data-header field. This field is present if an indicator bit is set in the SMS header (TP- UDHI) . Figure 6 shows the general structure of the user data field of a GSM SMS message. This field is present if an indicator bit is set in the SMS header (TPUDHI) irrespective of the data coding scheme for the appended text, these fields are always considered as octets (bytes) .
Referring to Figure 6, the general structure of the user data field comprises in sequence a user data length indicator 160, and a user data area of TP_PDU consisting of a user data header length indicator 162, a user data header element 1 identifier 164, a user data header element 1 length 166, user data header element 1 data 168, a user data header element 2 identifier 170, a user data header element 2 length 172, user data header element 2 data 174 and user data (plain text) 176. As indicated in Figure 6, the user data area of TP_PDU is a maximum of 140 bytes.
The SMS client software overview shown in Figure 7 illustrates the currently supported user-data-header
identifier in use which is OxOO and indicates a user- data-header of 4 bytes for SMS concatenation. It is proposed to use a reserved value (OxFF) for the command element identifiers. In such a scheme, a 1-byte length block, as indicated in Figure 7 represents the length of a data block in a single TP_PDU (in bytes) . Any plain (alternatively referred to as vanilla) text is appended to the end of the SMS. Data always follows the concatenation tag (OxOO) .
The overview shown in Figure 7 comprises a user data header length indicator 180 of 1 byte, which indicator is concatenated with SMS 182 of 5 bytes. A command element identifier OxFF 184 is concatenated with a length of data indicator 186 which comprises 1 byte. A data byte stream 188 is concatenated with the indicator 186. A user data field 190 which includes vanilla text concludes the overview.
Figures 8A, 8B and 8C illustrate three stages in the command data flow in the client 66 when in the receive mode. The number of actions contemplated using the client 66 is quite small, namely Display it, Save it and Reply to it (or DPR) and this enables the flow logic of the client to be kept as simple as possible.
Figures 8A, 8B and 8C comprise an upper section which represents the engine domain ED and a lower section which represents the server domain SD.
Referring to Figure 8A, an engine command queue is present on an input 192 which for convenience of
illustration is coupled to a command module 194 of the engine 138 (Figure 4) . The command module 194 examines the "ODPR" structure which for convenience is 0111 and despatches the structure to whichever device handles the highest priority request. As the "D" bit is set, the command module despatches a structure to the display server 140. On completion the server 140 sets the "D" bit to "0" so that the ODPR structure is now 0011 which is returned to the engine domain ED by way of a call -back function from where it is returned to the queue on the input 192 of the command module 194. As the P bit is set, the command is despatched to the persistence server 142. Upon completion the server 142 sets the "P" bit to "0" so that the ODPR structure is now 0001 which is returned to the engine domain ED by way of a call-back function from where it is returned to the queue on the input 192 of the command module 194. As the R bit is set, the command is despatched to the GSM stack 62 for a reply transmission. Upon completion, the "R" bit is set to "0" so that the ODPR structure is now "0000". The engine domain ED sees that the D, P and R bits are all zero and determines that it has finished handling the command and applies an input signal to a command erase module 196 which terminates the command flow.
In an alternative embodiment, instead of using byte stream data, the service provider creates the commands which may be included in the packet message to the handset. By way of example only, a set of embedded commands are as follows. The client 66 in the phone 20 parses the packet message to obtain the desired result. The commands are :
/F 22 Set Font size for text e.g ABC→ABC
/R x Repeat next operation e.g. Beep → Beep.Beep.Beep
/S GSM number Set Handset SMSC (Short message service centre) number, required to send packet .
/E Enable Feature (handset dependent)
/D&&&& Perform handset dependent test/diagnostic check
/Cx Set Channel For Cell Broadcast,
/M Define handset menu & application e.g. "Server"
Choice 1 → Command 1
Choice 2 Command 2
Choice 3 Command 3
Choice 4 Command 4 etc
/U Prepare for remote upgrade of handset firmware /F Apply Firmwave Fix /I Insert data record to Agenda/Address/Todo Alarm e.g. 00/03/13.meeting with client to set appointment on handset
/SCR Load standby screen to handset
The present invention is concerned with personal information services whereby users can subscribe to or pay for services that offer information on a variety of topics (weather, stock market, sports, horoscope, games etc.) via SMS. The SIM toolkit which is in a GSM handset can enable more sophisticated and attractive services to be implemented.
The deliver of subscription services can be effected in several ways, for example an internet server can be allocated a channel for its own use and can transmit a continuous subscription service message comprising repeating sequences of concatenated packets, each packet in a sequence being allocated to a particular topic such as sport, weather, stock exchange prices and so on. One way of offsetting the cost of subscription services would be to provide advertising which would be carried as one packet in each of the repeating sequences. Thus a subscriber having an enabled client would periodically receive advertisements in a manner similar to UK commercial television. A similar principle may be used to carry local news, local road traffic information or for emergency messages.
Other ways of providing subscription services will now be described with reference to Figure 9.
A SMS enabled phone 20 is coupled by a GSM link to an in-range SMS Centre (SMSC) , several SMSCs, SMSC1, SMSC2 and SMSCn, being shown in a cluster. The SMSCs communicate with a server having a server back office 200. A server managed data base 202 may be coupled to the server back office 200.
In this example, a personal computer PC is coupled by a web server 204 to the server back office 200. The server back office 200 is able to establish communication with a plurality of content providers 14A, 14B ... 14n which are able to provide information on a variety of topics such as sport, weather, share prices and so on.
In one embodiment, when a subscriber 206 wants to obtain, e.g. uptodate sports information using his/her SMS enabled phone, he/she enters a code to display subscriber services as a list of menu items and selects "sport" . The client 66 composes a message which is relayed as a SMS message to e.g. SMSCn which forwards the message to the server back office 200. The server back office 200 checks if the information requested is present in the server managed data base 202 and if so the information is relayed to the SMSCn which encrypts the message as a SMS message which is forwarded to the phone 20.
If the information is not in the server managed data base 200, the server back office 200 forwards the request to a content provider using the respective content provider's address e.g. a URL (Uniform Resource Locator). Once the server back office 200 has obtained the information it is related to the enabled phone 20 by way of the in-range SMSCn.
By providing the or each content provider 14A, 14B ... 14n with a developers tool kit 208, a content provider can establish a link, shown in broken lines, with the* SMSCn, which in turn communicates using SMS messages with the SMS enabled phone 20, the telephone number of which was included in the originating SMS message. Using this method avoids the need for routing signals by way of the server back office 200 thus saving system capacity.
Billing of the subscriber may be effected by way of the billing system 18 (Figure 1) which composes a monthly bill for all the services provided during the preceding month and submits it to the subscriber.
An alternative method of billing is for the subscriber to have the costs of the usage of the subscription services added automatically to his/her telephone bill . A technique for doing this can be based on the use of premium rate telephone lines or numbers. A subscriber uses his/her handset 20 to initially contact the server back office 200 (Figure 9) on e.g. a free number (in the UK, e.g. an 0800 prefix number) . On determining that the subscriber wants a subscription service the server back office 200 checks its server managed data base 202 and/or contacts the relevant one of the information content provider 14A, 14B ... 14n. Thereafter the data link is treated as a higher e.g. premium rate number (in the UK, e.g. an 0870 number) and the information is supplied to the subscriber's SMS enabled phone 20 at the higher rate. At termination of the call, the server back office 200 resets the link to a free number in readiness for another call. The subscriber receives a telephone bill and remits the cost to the network provider (or telephone company) which in turn pays the internet server 10 and the information content providers 14A, 14B ... 14n.
Figure 10 is a flow chart illustrating the sequence of operations from the initiation of the call by a user to the reimbursement of the information content provider.
Block 220 represents a user making a call to an internet server by way of a non-premium rate, for example free, link such as an 0800 number. Block 222 represents the internet server receiving the call and examining it. Block 224 represents checking if the call is a request for a subscription service. If the answer is No (N) then
the call is referred to block 226 which represents other services which the user can access. If the answer is Yes
(Y) then the internet server selects a premium rate link, such as a 0845 number, by which to establish contact with an information content provider and for the latter to supply information to the user either directly as shown in Figure 9 or indirectly via the server back office.
Block 230 represents the internet server sending the information content server's URL and the latter responding by transmitting the information requested.
Block 232 represents the internet server checking to see if the call has ended. If the answer is No (N) then the flow chart reverts to the input of the block 232. If the answer is Yes (Y) then in block 234 the call is terminated and the internet server resets the link with the user to a non-premium rate link.
Block 236 denotes the network provider billing the user for the use of the premium rate links and block 238 denotes the reimbursement of the information content provider by the network provider or internet server.
In the present specification and claims the word "a" or "an" preceding an element does not exclude the present of a plurality of such elements. Further, the word "comprising" does not exclude the presence of other elements or steps than those listed.
From reading the present disclosure, other modifications will be apparent to persons skilled in the art. Such modifications may involve other features which are already known in the design, manufacture and use of information delivery systems and component parts therefor and which may be used instead of or in addition to features already described herein. Although claims have
been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present application also includes any novel feature or any novel combination of features disclosed herein either explicitly or implicitly or any generalisation thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom.