GB2430588A

GB2430588A - Multiple protocol platform for mobile applications

Info

Publication number: GB2430588A
Application number: GB0618530A
Authority: GB
Inventors: Alireza Mousavi Khalkhali; Thomas Andrew Colthurst; Christopher Michael Harcourt; Andrew Peter Cooper
Original assignee: Individual
Current assignee: Individual
Priority date: 2005-09-20
Filing date: 2006-09-20
Publication date: 2007-03-28
Anticipated expiration: 2026-09-20
Also published as: GB0618530D0; GB2430588B; GB0519182D0

Abstract

In a Mobile Information Device Profile (MIDP) device 10 providing a Java (RTM) based application platform for phones 30, PDA's 50 and set top boxes 40 which is compatible with various other devices and protocols, the prohibition on redirecting data to another hub is lifted by establishing additional channels to redirection locations. Graphical content from a webpage or other resource 15 is provided directly to eg. a phone platform 30 upon request, but content from a resource at a different server 15' is provided via a second channel 60 which communicates details of the redirected location. System 10 can also act as a portal to a secure system (110, Fig 2) via third party authentication, or as a web-based lottery ticket vendor (Fig. 3) via unique identifiers.

Description

1 2430588 Communication System and Method The present invention relates to

a communication system and method that is particularly applicable to mobile information device profile (MIOP) based platforms such as embedded systems.

In the computing industry, particularly in fields such as wireless technology, the speed at which a technology runs through its life cycle is much quicker than elsewhere. A brand new product can become obsolete within months due to an improved technology or platform. One of the major issues with this is that products are introduced and become subsequently outdated so quickly that standardisation of the technology or particular features is not always viable.

Indeed, by the time a group of developers is ready to sit down to discuss standards, the next evolution of a product or technology is often already under development or even on sale.

Many computing devices, particularly those designed to be portable or hand-held and also those branded as consumer electronics" intended for users with little or no computing expertise, are based around embedded systems. An embedded system is typically a special-purpose system in which the computer processing capabilities and software is completely encapsulated by the device it controls.

Unlike a general-purpose computer, such as a personal computer, an embedded system performs pre-defined tasks, usually with very specific requirements. Since the system is dedicated to a specific task, design engineers can optimize it, reducing the size and cost of the product. Embedded systems are often mass- produced, so the cost savings may be multiplied by millions of items.

The result of the rapid evolution of products, particularly in embedded systems, is that a software development team currently needs its staff to understand numerous system architectures, languages and processes in order to deploy a product onto multiple devices.

Whilst environments such as Java (RTM) are intended to provide a common platform independent environment from which software can be run, different implementations and standards applied to the environments make application and service provision extremely difficult and unpredictable to developers. Indeed, it is not at all uncommon for a developer to have to re-engineer his or her product or service for each platform or environment, even when they say they run Java (RTM) or a similar non-platform specific environment.

A recent development is that of MIDP (mobile information device profile), a Java (RIM) based runtime environment for mobile devices providing a platform for dynamic secure delivery of graphical networked applications to users.

Devices that are compliant with Mobile Information Device Profile (MIDP) are supposed to enable vendors to develop applications that can run on multiple wireless platforms without spending intensive amounts of energy customising or reworking for each platform. MIDP is intended for use with embedded devices such as cell phones and POAs and sits on top of a JAVA (RIM) environment.

However, whilst MIDP may solve incompatibility problems, it introduces other problems.

According to an aspect of the present invention, there is provided a communication system arranged to communicate with a client platform connecting to a first resource via a first communications channel, wherein the communications system is arranged to establish a second communications channel with the client platform for redirecting communications, a communication transmitted by the communications system via the second communications channel is operative to cause a client platform to connect to a second resource at a redirected location different to that of the first resource.

Environments based on the MIDP specification are a useful advance to embedded systems and the like but unfortunately introduce a prohibition on redirection of communications. This prevents a system acting as a central hub for connections and redirecting connections to an appropriate node after some initial processing. Redirection is an extremely common practice and prohibition by MIDP reduces the appeal of using MIDP significantly. Embodiments of the present invention enable redirection to be used on M1DP based systems without affecting other operations and therefore address this problem whilst retaining the advantages provided by MIDP.

The present invention seeks to provide an infrastructure and system that is applicable to embedded systems such as wireless/mobile devices and set top boxes. It is also applicable to telecommunication mediums such as land tines (ordinary telephone systems/satellite technology).

Embodiments of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic diagram of a communications system according to an embodiment of the present invention; Figure 2 is a schematic diagram illustrating a secure communications system according to an embodiment of the present invention; Figure 3 is a schematic diagram illustrating a web based gaming system according to another embodiment of the present invention; and, Figures 4 and 5 are screen shots of a client application for use in the system of Figure 3.

Figure 1 is a schematic diagram of a communications system according to an embodiment of the present invention.

The communication system 10 is connected to a communications network 20 and is arranged to accept connections from client platforms 30-50. The client platforms are MIOP based platforms such as mobile telephones 30, set top boxes and PDAs 50.

The communication system 10 is arranged to operate in a normal expected manner during a first communication session with (and initiated by) one of the client platforms 30. The client platform 30 would typically connect to the communication system 10 over a first communications channel with a request to access content from a particular resource 15 identified by a particular resource address such as: http://www.xyzserver. net/resourcel jsp Content from the resource 15 is provided to the client platform 30 for appropriate action. In this case, the content is Java (RTM) code and would be executed by S the client platform's Java environment and may result in a graphical user interface being presented to the user of the client platform 30 for interaction with the communication system 10. Should the client platform require access to different resources (for example due to a selection or navigation by the user at the client platform), an appropriate request is sent to the communication system 10 and content is returned accordingly.

Should the action of the client platform 30 or its user cause the communication system 10 to redirect the communication session (for example by telling the client platform to now obtain content from a resource 15' at http://www.abcserver.net/resource1.htm), this would normally fail on MIDP based platforms due to the prohibition on redirection.

In embodiments of the present invention, this issue is addressed by the communication system 10 by using a second communication channel 60 to establish a second communication session between the client platform 30 and the redirected resource 15'. In the embodiments discussed below, the example second communication channels 60 used are Short Messaging Service (SMS) messages and a satellite downlink channel, although it will be appreciated that any communications medium or system could be used.

In each case, the communication system 10 initiates the second communication session over the second communications channel 60 and communicates details of the location of the redirected resource 15' for the client platform 30 to connect ta The client platform 30 is then able to connect to the resource 15' using the location details received.

Whilst the communication network 20 and second communications channel 60 used for each of client platforms 30-50 illustrated above are the same for all client platforms 30-50, this need not be the case. Different communication networks 20 (optionally based on different communication mediums such as wired, wireless etc) may be used by the communications system 10. Similarly, different second communications channels 60 or channel types could be used for different client platforms or client platform types. Examples of differing implementations are discussed below.

Figure 2 is a schematic diagram illustrating a secure communications system according to an embodiment of the present invention.

In the illustrated embodiment, the communications system 10 operates as a portal to a secure system 100 enabling set top boxes to access an email system, banking facilities or the like. In the illustrated embodiment, the set top box 40 is a set top box for a satellite broadcasting system 60 and includes a first communications link 41 to a public switched telephone network 20 (PSTN) and a second communications link 42 for receiving encoded messages via the satellite broadcasting system 60.

The communications system 10 is arranged to allow the set top box 40 to connect and establish a first communications session via the PSTN 20. The communications system 10 obtains logon credentials from the set top box 40 and checks these against a local database 11. Upon authentication of the logon credentials, the communications system transmits a redirection message 61 via the satellite broadcasting system 60 to the set top box 40 causing a separate application to be run at the set top box 40 which connects to the secure system 100.

The redirection message 61 includes sufficient information to enable only the set top box to access corresponding data at the secure system 100. Optionally, the set top box may include an encryption key 43 that may be required for use in combination with the redirection message to enable access to the secure system 100. In this manner, even if the redirection message was intercepted, access to the secure system 100 would not be possible without the key 43.

Figure 3 is a schematic diagram illustrating a web based gaming system according to another embodiment of the present invention.

In the illustrated embodiment, the communications system 10 operates a web based gaming system enabling mobile phones 30 to purchase lottery tickets. In the illustrated embodiment, the mobile phone 30 is able to connect to the communications system 10 via a mobile data communications network 20 (such as a 2.5G or 3G data network) and also includes an SMS client 31 able to receive SMS messages.

A user is able to download a software application designed to suit most of the current available mobile phones via various routes available for electronic data exchange such as: direct installation at manufacture by the manufacturer of the device; download from a service provider such as mobile phone network operator; download via CD, DVD or other media; or download from a web server.

On running the application on the mobile phone 30, a graphical user interface is displayed as shown in Figure 4. No logon or authentication is required to play the game or register and as such the application is not server dependent.

Once the user has made his or her selection, the application establishes a connection via communications network 20 to the communications system 10.

The user's selection is communicated to the communications system 10.

In one embodiment, connection is achieved via http and/or https communication protocols. The communication to the communications system 10 may be in the form of a "redirect command" for example: "http://www.mobiI-Iotto.co.uk/redirect?tO&n2,6, 1 7,24,34, 44&d=O&w=O?p=44444444" where: * p is the mobile device's identifier (typically a phone number). The transaction is registered with this number, which will then be associated with a unique ticket number; and, * n is the user's parameter selection for the game (in this case lottery numbers).

In order to provide a receipt of the submission, the communication system 10 generates an SMS message 60 which it transmits back to the mobile phone 30.

The SMS message 60 includes the redirection message that, when received by the mobile phone and opened in an appropriate client application (for example the default or a custom SMS messaging client), causes the mobile phone to connect to a different (redirected) location 15' at the communication system 10 where the receipt data is stored, as is illustrated in figure 5.

As is illustrated in Figure 4, the application may enable the user to access multiple games.

For example, the SMS message 60 may include a URL as an attribute causing the mobile phone to open a jsp page when the SMS message is opened. The URL may be of the format: usedcore taglib:<c:import url="${requestScope. URL}"/> In this manner, the URL is not altered in anyway and implies the correct response code of 200. This satisfies the MIDP based platform because it doesn't experience a context change.

A system database will preferably record all transactions, optionally notify the user of wins via their phone or set top box. In the case of notification, some form of secure Java (RTM) based application could be used to receive a bar code or other identifier allowing a use to present their phone at a lottery retailer or the like and redeem their win by presenting the identifier. The secure Java (RTM) based application would prevent the identifier being extracted, transferred, faked or used more than once.

Billing will preferably be achieved by adding a section to the user's telephone bill, and based on direct debit. Also pay as you go vouchers can be introduced.

Authentication will be based on the mobile server provider registrations. A pin system may be used to ensure only the user will be responsible for transaction.

On crediting the user account with the wins, one can add a slip to the first lottery phone bill, enabling a user to provide details of the users' bank accounts so their accounts can be credited on a win. Alternatively by producing the phone bill to the banks along with a unique ticket no. will allow winning plays to be redeemed.

Whilst preferred client platforms are based on the J2ME, CLDC, CDC, MIDP technologies, it will be appreciated that other technologies such as Microsoft.Net mobile applications can also be used - indeed, MIDP and/or custom client applications are not required for operation of embodiments of the present invention. Whilst the present invention was developed to address problems with MIDP based platforms, embodiments are applicable to other platforms.

Set top boxes may optionally include a unique identifier such as a unique number issued on a card readable by the set top box. The unique identifier associates the set top box and user with a remote data record that instructs the communication system how and where to send redirection messages. The remote data record may also include data such that payments, credits etc can be applied. In the same way as the mobile phone number is submitted to the communications system 10 in the above example, the unique identifier may be used for set top boxes to Identify the submission. This is cross checked at the remote data record to identify how to send the redirection message (eg. Via satellite broadcast encrypted with a key xzyl) and its destination.

In some instances, the data record may be customised by the user to allow selection of the second channel. Preferably, the system is arranged to allow selection only of second channels that the client platform is capable of using.

The redirection message may optionally include a description of the transaction, a time/date stamp and other parameters dependent on application phone number, date, number of weeks to play in the case of the lottery game above.

Dedicated applications may be developed for client platforms, not only for communicating with specific locations such as in the gaming system of Figure 3 but also to enable custom handling of either messages received over the second communications channel or communications over both the first and second communications channels. For example, it would be possible to have an SMS client with web browsing capabilities (or vice versa) so that when browsing the web (first channel) redirection messages received via SMS (second channel) can be automatically used to affect the web browser and perform the redirection.

Claims

Claims 1. A communication system arranged to communicate with a client

platform via a first communications channel for connecting the client platform to a first resource, wherein the communications system is arranged to establish a second communications channel with the client platform for redirecting communications, a communication transmitted by the communications system via the second communications channel is operative to cause a client platform to connect to a second resource at a redirected location different to that of the first resource.
2. A communications system according to claim 1, wherein the second communications channel comprises a different communication medium to the first communication channel.
3. A communications system according to claim 1 or 2, wherein the second communications channel uses a different communications protocol to the first communications channel.
4. A communications system according to claim 1, 2 or 3, wherein the first communications channel comprises a voice/data communications network.
5. A communications system according to any preceding claim, wherein the second communications channel comprises a short messaging service.
6. A communications system according to any of claims I to 4, wherein the second communications channel comprises a satellite broadcasting system.
7. A communications system according to any preceding claim wherein the first and second resources comprise web pages.
8. A communications system according to claim 7, wherein the different location comprises a location on a same web server. ii
9. A communications system according to any of claims I to 7, wherein the second resource is at a physical location remote to the first location.
10. A communications system according to any preceding claim, wherein the client platform comprises one of: a mobile telephone; a set top box; a PDA; a computer; or a consumer electronics device.
Ii. A communications system according to any preceding claim, further comprising a database associating the or each client platform or client platform type with available second communication channels or channel types, the communications system being arranged to establish the second communications channel in dependence on the content of the database associated with the client platform or client platform type.
12. A system comprising a communications system as claimed in any preceding claim and a client platform, wherein the client platform includes a first application configured to connect to the communications system via the first communications channel and a second application configured to receive a communication via the second communications channel and connect the client platform to the second resource.
13. A system as claimed in claim 12, wherein the second application is arranged to control the first application and to connect the first application to the second resource.
14. A system as claimed in claim 12 or 13, wherein the first application and second application are sub-systems of a single application and operate transparently to said user.
15. A system as claimed in claim 12, 13 or 14, wherein the client platform comprises a mobile information device profile, MIDP, based device.
16. A method for communicating with a client platform comprising: connecting the client platform via a first communications channel to a first resource; establishing a second communications channel with the client platform for redirecting a communication; and, transmitting a communication via the second communications channel that is operative to cause the client plafform to connect to a second resource at a redirected location different to that of the first resource.
17. A method as claimed in claim 16, further comprising: maintaining database associating the or each client platform or client platform type with available second communication channels or channel types; establishing the second communications channel in dependence on the content of the database associated with the client platform or client platform type.
18. A communications system as herein described and as illustrated in the accompanying drawings.
19. A system as herein described and as illustrated in the accompanying drawings.
20. A method as herein described and as illustrated in the accompanying drawings.