Beacon network

P-0001[0001] The present invention relates to mobile communications devices, such as telephones and suitably equipped personal digital assistants (PDA's), and to infrastructure systems and protocols for use with the same.

P-0002[0002] Recent years have seen a great increase in subscribers world-wide to mobile telephone networks. Through advances in technology and the addition of functionalities, cellular telephones have become personal, trusted devices. In addition, advances in wireless networking technology now allow handheld computing devices to wirelessly communicate with networked resources. A result of this is that a mobile information society is developing, with personalised and localised services becoming increasingly more important. Such “Context-Aware” (CA) terminals such as mobile telephones, PDA's and other wireless devices, are used with low power, short range base stations in places like shopping malls to provide location-specific information. This information might include local maps, information on nearby shops and restaurants and so on. The user's CA terminal may be equipped to filter the information received according to pre-stored user preferences and the user is only alerted if an item of data of particular interest has been received.

P-0003[0003] Commonly-assigned International patent application EP 01/06948 filed with a priority date of Aug. 15, 2000 and unpublished at the priority date of the present invention, describes a CA terminal and puts forward the concept of broadcasting data before a connection is made according to BlueTooth protocols. It exploits the BlueTooth Inquiry phase by extending the very short ID packet sent out during this mode and using the extra space thus gained to carry a small amount of information. This information can be BlueTooth system related data or one-way application data. This scheme has the potentially useful feature of being backwards-compatible with legacy BlueTooth devices that are not able to understand this extra field.

P-0004[0004] HTML web browsers commonly use a number of intelligent caching schemes that reduce network traffic and page loading delays. For example, on a new page request, a browser may look in its local page cache first, then pass on request to a caching proxy server, where pages recently or frequently accessed by any user of the server are cached, then finally issue a request to the origin server for the missing content. Pages transmitted over HTTP (or WTP in WAP) can contain some information about how long they are valid for to help the proxy server decide whether to use the cached copy of the data or not.

P-0005[0005] Wireless Application Protocol (WAP) is now a well-known technology, which delivers content in a format similar to web HTML, namely WML (wireless mark-up language), in ‘cards’ from a server, via a WAP gateway to a mobile client, such as phone or PDA, where it can be viewed by a number of different WML browser variants. These cards may be delivered to the client in ‘decks’, anticipating the content that the browsers are next likely to require, so they can be cached on the client to reduce networking delays. WML links and A/V assets may be referenced by absolute address or relative to the current WML source directory. Proxy gateway addressing is dependent on the bearer type. WAP protocols are layered above the bearer level, from application (WAE), to Session (WSP), to Transaction (WTP), to Security (WTLS), to the Transport layer (WDP) which rides on the underlying bearer. At the WDP level, ‘management entities’ may notify events such as client or server node being lost.

P-0006[0006] There are on-going standardisation discussions, involving both the WAP Forum and the BlueTooth (BT) committees about very local delivery of WAP over a BlueTooth pico-network as a possible short-range RF bearer technology. Therefore the sole use of either a BT, or a wide-area, network for sourcing WML content is already known. Moreover, there is already discussion on WAP session handover, from BT as a WAP bearer to an alternate bearer (eg wide-area network). For example, where a WAP client device supporting multiple bearers leaves a BlueTooth access point's coverage or loses the BT pico-network connection, the client then may query an alternate (wide-area) address for the WAP server, that information being sent and cached during the BlueTooth connection. In one example, a smart kiosk having both BT and WAP communication capabilities provides an Internet address for the continuation of information delivery using cellular packet data to resume the client-server session (ref.: section 4.1.2 of BlueTooth Draft Specification Document Version 1.0B ‘Interoperability Requirements for BlueTooth as a WAP bearer).

P-0007[0007] Allowing network access from multiple bearers is well understood in a fixed (‘wired’) environment. Systems on IP-based networks regularly use ‘routing tables’ which allow them to access different remote servers (with particular IP addresses) via different network connections.

P-0008[0008] In systems to date, localised data delivery over BlueTooth from a cache on a beacon is provided solely as an alternative to data delivery over a WAN, such as by WAP. One or the other delivery mechanism is used depending on terminal configuration and network availability.

P-0009[0009] According to a first aspect of the present invention, there is provided a communications system comprising a beacon storing a portion of available data and having access to all of the available data over a first network, the beacon being arranged to communicate with a client terminal over a second network to supply data from said stored portion of available data, the client terminal having access to all of the available data over a third network, wherein upon a request by the client terminal for data of the available data not within the stored portion, a network is selected from the first network and the third network in dependence on one or more predetermined criteria, the requested data being accessed over the selected network.

P-0010[0010] The present invention utilises the most favourable aspects of data access over two or more different networks. In one embodiment, a BlueTooth beacon communicates with a wide area network (WAN) over a first network and a mobile device over a second, BlueTooth, network. The mobile device also has the capability of accessing the WAN over a third, WAP, network. By using the predetermined criteria, intelligent selection is possible between the first and third networks for data access where the data is not stored by the beacon itself. Further in accordance with the present invention there is provided a portable communications device for use as said client terminal in a system as recited above, said device being operable to communicate with said beacon, to access said available data over said third network, and to generate said request for data of the available data not within the stored portion.

P-0011[0011] According to a second aspect of the present invention, there is provided a data supply method for supplying data to a client terminal comprising:

P-0012[0012] maintaining a beacon storing a portion of available data and having access to all of the available data over a first network;

P-0013[0013] communicating between the beacon and the client network over a second network to supply data from the stored portion of available data;

P-0014[0014] wherein the client terminal has access to all of the available data over a third network; the method further comprising the steps of:

P-0015[0015] upon request by the clients terminal for data of the available data not within the stored portion, selecting a network from the first network and the third network in dependence on one or more predetermined criteria; and,

P-0016[0016] accessing the requested data over the selected network.

P-0017[0017] The present invention focuses on the simultaneous and intelligent use of both networks for content access to the client terminal by intelligent distributed caching and the optional tailoring of content addressing.

P-0018[0018] When initiating a network connection (from a desktop or mobile environment), the decision to open the connection is usually a combination of the client software and the user. The present invention also proposes a solution which allows this decision to be made by a combination of the client software, the user and an already networked server.

P-0019[0019] An example of the present invention will now be described in detail with reference to the accompanying Figures, in which:

P-0020[0020]FIG. 1 is a schematic diagram of a beacon network illustrating one embodiment of the present invention; and,

P-0021[0021]FIGS. 2 and 3 illustrate possible data supply source configurations; and,

P-0022[0022]FIG. 4 is the schematic diagram of FIG. 1 illustrating selected aspects in more detail.

P-0023[0023] The measures proposed are illustrated by reference to WAP and WML, but are relevant to any IP-based or similar browsing protocol (e.g. iMode, WAP, HTML/HTTP, etc). One or more subsets of main WAP WML content is delivered over a short-range RF or IR link (in a single initial data burst or broadcast, or through a number of short-range beacon/handset exchanges) in preference to sourcing that content over a wide-area network. In one embodiment, a part of the total WML or other content is mirrored in the beacon's cache (or on a server behind the beacon).

P-0024[0024]FIG. 1 is a schematic diagram of a beacon network illustrating one embodiment of the present invention. A beacon <b>10</b> hosts a cache <b>20</b> of data. The beacon <b>10</b> operates in a BlueTooth pico-network. The broadcast area of the beacon <b>10</b> within the pico-network is illustrated as the area <b>40</b>. A BlueTooth-enabled mobile device <b>30</b>, such as a CA terminal in the form of a mobile telephone, PDA or other device within the beacon's <b>10</b> broadcast area <b>40</b> is able to communicate with the beacon <b>10</b> and obtain data via the BlueTooth pico-network from the cache <b>20</b>. Data within the cache <b>20</b> is a subset of data available to the mobile device <b>30</b>. The beacon <b>10</b> can connect to a data network <b>50</b> via a network connection <b>60</b>. The available data, of which the data in the cache <b>20</b> is a subset, is held in one or more memory <b>70</b> that can be accessed via the data network <b>50</b>. Whilst the memory <b>70</b> is illustrated as a single entity in FIG. 1, it will be apparent to the reader that the data can be stored in a number of memories accessible from the data network <b>50</b>. Such memories could be hard disks of computers, online storage memories or other data storage media or services. Furthermore, the data network <b>50</b> could be one or more Intranets and/or the Internet. Additionally, the memory or memories could be websites or other web based resources.

P-0025[0025] The mobile device <b>30</b> is able to connect directly to the data network <b>50</b> via a portal <b>80</b>. The data connection <b>90</b> between the mobile device <b>30</b> and the portal <b>80</b> may, for example, be a WAP data connection.

P-0026[0026] When the mobile device <b>30</b> requires access to data it communicates with the beacon <b>10</b> via a BlueTooth connection <b>35</b>. In some situations data may be pushed from the beacon <b>10</b> via the BlueTooth connection <b>35</b> to the mobile device <b>30</b>, for example, at certain times or when it enters the broadcast area <b>40</b>. The beacon <b>10</b> supplies data from the subset of available data in the cache <b>20</b> to the mobile device via the BlueTooth connection <b>35</b>. If some or all of the data required by the mobile device <b>30</b> is not within the subset of available data, the data network <b>50</b> is accessed to obtain the necessary available data from the memory(s) <b>70</b>.

P-0027[0027] The supply source used to obtain the data network <b>50</b> is selected in dependence on a number of predetermined criteria. Examples of possible data supply configurations are illustrated with reference to FIGS. 2 and 3.

P-0028[0028]FIG. 2 is the schematic diagram of FIG. 1 illustrating a possible data supply source configuration according to an embodiment of the present invention. In this configuration the beacon <b>10</b> has no permanent connection to the data network <b>50</b>. A connection <b>60</b> may be established temporarily, for example over a PSTN, possibly by manual intervention, to occasionally update the beacon's cache <b>20</b>. In this manner, the beacon is effectively stand-alone and merely indicates data available from the data network <b>50</b>.

P-0029[0029] For example, the beacon <b>10</b> may be positioned so its broadcast area <b>40</b> covers the premises and immediate vicinity of a shop. When a mobile device enters the broadcast area <b>40</b>, the beacon <b>10</b> is a first supply source and transmits data from the cache <b>20</b> using BlueTooth to alert the mobile device <b>30</b> to, for example, products and/or services provided by the shop. In this example, detailed product and/or service information is not a part of the subset of data in the cache <b>20</b> and is instead held on a second data supply source in the form of a web site <b>70</b> accessible via the data network <b>50</b>. Links to the detailed product and/or service information are provided within the subset of data from the cache <b>20</b> and form at least part of the predetermined criteria in this example. The links in this example could be WML or HTML redirection links pointing to the web site <b>70</b>. When accessed by the mobile device, the links have the effect of instructing the mobile device to establish a WAP connection <b>90</b> to the portal <b>80</b> so that the mobile device can then access the data on the web site <b>70</b> associated with the link. In this configuration, the predetermined criteria would include the information and links embedded within the data from the beacon <b>10</b>.

P-0030[0030]FIG. 3 is the schematic diagram of FIG. 1 illustrating a possible data supply configuration according to an embodiment of the present invention. In this configuration, the beacon <b>10</b> is again the first data supply source but uses an available network connection <b>60</b> to access the data network <b>50</b> and therefore the second data supply source in the form of a storage area network <b>70</b> for all data that is not stored within the cache <b>20</b>. This may be the situation, for example, where an organisation owning the mobile device <b>30</b> also owns the beacon <b>10</b> and data network <b>50</b>.

P-0031[0031] For example, the mobile device <b>30</b> may be provided for use within an office. A network of beacons <b>10</b> are maintained for allowing the mobile device <b>30</b> to obtain data from the storage area network (SAN) <b>70</b> on the office's intranet <b>50</b>. In order to limit costs incurred by establishing connections to the portal <b>80</b>, where possible, all traffic from the mobile device <b>30</b> is routed over BlueTooth via the data connection <b>35</b> to one of the network of beacons <b>10</b>. Where data is requested that is not held within a cache <b>20</b>, the respective beacon <b>10</b> accesses the intranet <b>50</b> via its network connection <b>60</b> to obtain the data from the SAN <b>70</b>. The beacon <b>10</b> then relays the obtained data to the mobile device <b>30</b> via the BlueTooth data connection <b>35</b>.

P-0032[0032] In order to achieve a configuration in which all links are initially followed back to a beacon <b>10</b>, the links could be written (or rewritten if the data in the cache <b>20</b> is an actual copy of data from the SAN) to point to the beacon <b>10</b> instead of resources elsewhere. One alternative is for the mobile device <b>30</b> to be configured, or instructed by data received from the beacon <b>10</b>, to direct all communications, irrespective or the address of the link, to one of the beacons <b>10</b>.

P-0033[0033] When a beacon receives a request for a link that is not held within the cache <b>20</b>, the link is redirected to the SAN <b>70</b>. The data is then obtained by the beacon <b>10</b> and forwarded to the mobile device <b>30</b>.

P-0034[0034] Only in the event that a BlueTooth connection <b>35</b> cannot be established between the beacon <b>10</b> and mobile device <b>30</b> would the mobile device <b>30</b> seek the data via connection <b>90</b> with the portal <b>80</b> to obtain the data from the SAN <b>70</b> directly. However, the configuration of the mobile device <b>30</b> and/or data embedded within data provided from the cache <b>20</b> may limit or prevent access to the SAN <b>70</b> via the portal <b>80</b>.

P-0035[0035]FIGS. 2 and 3 illustrate extreme situations, where after receiving an alert from the beacon <b>10</b>, the mobile device <b>30</b> starts up a data connection using different data supply sources. Pointers or links within the alert from the beacon <b>10</b> provide the necessary instructions to the mobile device <b>30</b> to activate a relevant service over a wide-area, eg cellular link, or directly with the beacon <b>10</b>, the latter being supplied with the service content (eg WML). For commercial reasons (for example generating network operator traffic or connection charges) there may be preferences for either of these configurations.

P-0036[0036] Technically, the configuration illustrated with reference to FIG. 2 has the advantage that the WML, HTML or other content is maintained at one main server site <b>70</b>. However, delays may be experienced from the wide area network and gateway initialisation times before any content is seen on the mobile device <b>30</b>. In the configuration illustrated with reference to FIG. 3 on the other hand delays may be experienced when the beacon's cache <b>20</b> must retrieve additional content from its back-end network <b>50</b> via network connection <b>60</b>, or the fact that the beacon cache's content may become out of date, and so needs to track changes to that of the main content site <b>70</b>. In general, bandwidth limitations, connection costs, quality of service or network security of either the short-range RF link, or of the wide-area network may also dictate preferences for content delivery of short message, audio or video, commercial transactions etc over one, rather than the other network. These latter preferences may vary for different parts of the same complete body of a service's content and also be dependent on the device characteristics of the mobile handset. Each preference, mobile device configuration, network availability and policy decision may be a predetermined condition used in the present invention to determine the data source to be used.

P-0037[0037] In a typical WAP type data access scenario, the mobile device's content browser intelligently asks for the WML cards it is likely to need (when they are not held in the handset's own cache), either from the beacon <b>10</b> or from the network <b>50</b>, dependent on the predetermined conditions. For example, if delay times or cellular charges are paramount, then content may be initially requested from the beacon <b>10</b> (if it is known to be cached there and the beacon is still in range), then failing that from the wide-area network <b>50</b> via portal <b>80</b>. If a secure transaction could not be offered over the short-range link <b>35</b>, the mobile device <b>30</b> may continue that part of the service interaction with a secure wide-area link, and later return to the short-range interaction, eg for higher-bandwidth audio content delivery.

P-0038[0038] When the beacon <b>10</b> sends cached data to the mobile device <b>30</b>, it may also provide information about the data which allows the mobile device <b>30</b> to decide intelligently whether it should, for example:

P-0039[0039] Use this data directly

P-0040[0040] Request the original data over the wide area network <b>50</b> via portal <b>80</b>, or

P-0041[0041] Initiate a connection <b>90</b> to the wide area network <b>50</b> while using (for the moment) the locally cached data.

P-0042[0042] For example, the user could be interacting with first-level WML menus delivered from the beacon <b>10</b> while waiting for a wide-area WAP gateway <b>80</b> to get started, thus camouflaging the wide-area gateway <b>80</b> start-up delays. The top-level (‘keeping the user interested’) menus and WML content might be sent in the first burst from a beacon <b>10</b>, with the hanging ‘leaves’ of that WML link tree having altered WML absolute addresses. These leaves may then be followed by the mobile device's browser over the wide-area bearer <b>90</b>, even if the beacon <b>10</b> is still in range. (Subsequent beacon communication for interaction within those top-levels of WML is also possible at any stage). Some WAP browsers on mobile devices <b>30</b> already cache a ‘deck’ of WML cards locally on the mobile devices <b>30</b> and know when to update it from a server. There are now with 2 possible sources for the new cards/decks:

P-0043[0043] 1. beacon cache <b>20</b>; and,

P-0044[0044] 2. wide-area gateway <b>80</b>.

P-0045[0045] If content is to be cached by a beacon <b>10</b>, indirection to relative or absolute links contained within the content may be needed. Automatic or regular updating of the beacon's cached content against changes to the content on the main site <b>70</b> may also be utilised.

P-0046[0046] Intelligence may be included in the mobile device's browser to identify when the beacon connection <b>35</b> is still available and what content it can deliver in addition to preferences for sources of different types of content (these preferences will typically form part of the predetermined criteria).

P-0047[0047] An embodiment of the invention is shown in FIG. 4. Two basic approaches (which can be combined) to storing the data on the beacon are illustrated:

P-0048[0048] i) No caching model. The beacon <b>10</b> includes an optional server <b>15</b>. Content is stored on the beacon <b>10</b> with an address in the form of a URI (Universal Resource Identifier) that is unique to the beacon <b>10</b>. The mobile device <b>30</b> must receive the content from the beacon <b>10</b> (the URI is not accessible from another server on the wide-area network <b>50</b>).

P-0049[0049] ii) Caching model. The beacon <b>10</b> does not use the optional server <b>15</b>. Content from servers <b>70</b> on the network <b>50</b> is cached by the beacon <b>10</b>. The data, along with it's network URI and other meta-information, is copied from the network <b>50</b> onto the beacon <b>10</b>. When this data is accessed by the mobile device <b>30</b>, the data bears the same URI from the beacon <b>10</b> as it did when the beacon <b>10</b> obtained it from the origin server <b>70</b>.

P-0050[0050] The beacon <b>10</b> has its own unique IP address and server (This does not assume that the beacon is connected to any network). An example of the process for communication is then as follows:

P-0051[0051] a) Mobile device <b>30</b> comes in range <b>40</b>, short range (eg BT/Irda) connection <b>35</b> is started.

P-0052[0052] b) Beacon <b>10</b> does basic push of information (e.g. ‘cheap chocolate for sale’ WML page with profile information).

P-0053[0053] c) The mobile device <b>30</b> can then access the data in the form of pages on the beacon <b>10</b> (whether they are cached pages or pages from the local beacon server).

P-0054[0054] d) When the mobile device <b>30</b> requires a page having a URI outside the beacon <b>10</b> (i.e. on the network ‘at large’), the mobile device <b>30</b> must open a GSM/GPRS/3G or other suitable data connection <b>90</b> and continue to interact on this. This can also happen when the client requests a URI for data which is cached by the beacon <b>10</b>, but which has associated meta-information which implies the data is out of date (e.g. Expiration-date in the HTTP header).

P-0055[0055] Further areas in which the configuration of the mobile device <b>30</b> or beacon <b>10</b> could be improved for use in the present invention include:

P-0056[0056] 1. Predicting a request for a WAN connection in time to set it up (e.g. GSM-CSD requires approximately 20 seconds). The prediction is most suited to being done on the beacon <b>10</b> (it knows the layout of its own cached pages better than the mobile device <b>30</b>). Device profile information about the mobile device <b>30</b> could be provided to the beacon <b>10</b> in order to aid this decision making process. (eg. What is the alternative data connection type? How long does it take to setup a connection?).

P-0057[0057] Some possible strategies for prediction are:

P-0058[0058] ->User hits a ‘flag’ page (This could be first page or when user shows interest in browsing. It could also be a page which implies interest in purchasing something or searching for something which requires connection to an e-Commerce server).

P-0059[0059] ->User makes more than X requests for pages (implying the user has time to ‘surf’).

P-0060[0060] ->An explicit option is provided on a page (eg. ‘press button to initiate network connection’).

P-0061[0061] 2. Initiating setup of WAN connection. To initiate setup, you could simply get the mobile device <b>30</b> to make a background ‘dummy’ request for data from the WAN <b>50</b> (Ideally this is accomplished by a HTTP (or similar) header being sent from the beacon <b>10</b> to mobile device <b>30</b>. Alternatively the beacon <b>10</b> may include a ‘blank’ remote image URL in a cached page sent to the mobile device <b>30</b> causing the mobile device <b>30</b> to request the URL automatically). This could result in a message to user ‘Do you want to connect to network?’

P-0062[0062] 3. Controlling network configuration of the client. Typically, the client dynamically controls its connection to the beacon(s) <b>10</b> and the WAN <b>50</b>. Information Provider (IP) routing tables and DNS (Domain Name Servers—the system for mapping a domain name e.g. www.yule.org to an IP address e.g. 64.176.92.219) could therefore be intelligently used as part of the predetermined criteria. If the beacon <b>10</b> is networked, then this comes down to a decision on cost vs. bandwidth vs. latency vs. convenience (you can access the same URL via BlueTooth or via GPRS.) If the beacon <b>10</b> is not networked then the routing table should allow only requests to cache-based IP address(es) to go via the beacon <b>10</b>, and the beacon <b>10</b> should also provide a DNS service (name server) for itself. The mobile device <b>30</b> then requires intelligence so that if the request for a URL fails due to unknown domain name at the beacon <b>10</b>, it should initiate <b>1</b> WAN network connection <b>90</b> (if, and only if the routing table is ‘incomplete’=does not cover all possible IP addresses). Once connected, domain name servers at both the beacon and the network side are both accessible for future URL requests.

P-0063[0063] 4. Mobile device/cache communication. A wired cache assumes that the client routes all requests through it (the cache machine decides whether to, and then does the network request). In the beacon model, requests only get routed to the cache if the page is stored there—it will be the client which makes the network request. When the client makes a request, the cache returns the page (if stored) with meta-data (date stored, expiration date, does it require revalidation? etc.), the client then displays the page or starts network connection dependent on this information.

P-0064[0064] 5. Cache control extensions. HTTP1.1 (and so WTP) define a set of cache control primitives, these could be extended for the wireless (not always connected) world:

P-0065[0065] ->X-if-networked (e.g. expire-if-networked, revalidate-if-networked, . . . ) i.e. allow the behaviour of pages to be different dependent on the network status of client (and also allow behaviour to change when the client comes online)

P-0066[0066] ->revalidate-asynchronous. Request that the pages are checked for validity, but asynchronously. i.e. continue to display the page while the network is opened/checked.

P-0067[0067] 6. Setup/reconfiguration/teardown. Setup so that the beacon cache <b>20</b> is used on connection is fairly simple (e.g. WAP over BlueTooth is already being discussed &amp; demonstrated). However, reconfiguration when the mobile device connects to the wide-area network <b>50</b>, and also teardown when the client disconnects from either the beacon <b>10</b> or the wide-area network <b>50</b> must also be considered. This is made simple by combining points (iii) &amp; (iv) above:

P-0068[0068] When wide-area network connection is established, the mobile device <b>30</b> must access domain name servers at both the beacon <b>10</b> and the network side to be able to establish correctly IP addresses.

P-0069[0069] The web cache on the beacon <b>10</b> will still be accessible after network reconfiguration (and the mobile device <b>30</b>/user can decide whether to use it or not). Also, any web server on the beacon <b>10</b> will still be accessible.

P-0070[0070] When the beacon <b>10</b> is no longer in range <b>40</b>, the mobile device <b>30</b> can reconfigure to no longer attempt to use the beacon cache <b>20</b> or name server.

P-0071[0071] 7. Automatic update of the beacon cache <b>20</b>. When the mobile device <b>30</b> connects to the wide area network <b>50</b> to obtain an update of an out-of-date cached page, it can also send the data to the cache <b>20</b> to update its store (as a low-priority task). This assumes a reasonably high-bandwidth and free local connection to the beacon <b>10</b>.

P-0072[0072] Although the above embodiments have been described to specific hardware configurations, it will be apparent to the skilled reader that these could be varied without any inventive input. For example, the BlueTooth beacon could be a server or a network of beacons. The mobile device could be a PDA, mobile phone or other device capable of communication with a number of networks. Furthermore, whilst specific communication protocols have been discussed, these could easily be substituted for others (GPRS or UMTS instead of WAP; a LAN instead of a WAN etc.)