SE539872C2

SE539872C2 - Providing a service by a service terminal to a user of a mobile device

Info

Publication number: SE539872C2
Application number: SE1551557A
Authority: SE
Inventors: Samuelsson Joachim; Cronholm Paul
Original assignee: Crunchfish Ab
Priority date: 2015-11-30
Filing date: 2015-11-30
Publication date: 2017-12-27
Also published as: WO2017095307A1; SE1551557A1

Description

PROVIDING A SERVICE BY A SERVICE TERMINAL TO A USER OF A MOBILE DEVICE TECHNICAL FIELD The present invention generally relates to communication. More specifically, the invention relates to a method of providing a service by a service terminal to a user of a mobile device. The invention also relates to an associated communication system.

BACKGROUND Mobile communication devices, such as mobile terminals like smartphones or tablet computers ("surf pads"), have attracted enormous popularity during the last decades. The abbreviated notionmobile deviceswill be used herein when referring to such mobile communication devices.

Long gone are the days when mobile devices were used mainly for telephonic voice communication. Today, mobile devices are also used as a tool to access various digital services like messaging, presentation of content, streaming, banking, gaming, monitoring of physical exercise or medical status, etc.

In contrast, for real-life (physical world) services, users typically still have to use separate devices for instance when paying for a desired article or service in shops, restaurants, cultural venues or sport arenas. When making a payment for a purchased article or service at a service terminal such as a point-of-sales terminal, cash register or ticket desk, a customer may typically use a traditional wallet and pay in cash, write a check, or pay with a credit card.

Some attempts have been made to allow mobile device users to use a mobile device as a payment tool by way of electronic wallet( e- wallet)functionality in the mobile device. Existing solutions are however impractical in terms of user convenience, since they typically require extensive manual intervention by the user in the user interface of the mobile device.

SUMMARY It is accordingly an object of the invention to offer improvements in the technical field of mobile devices and to solve, eliminate, alleviate, mitigate or reduce at least some of the problems referred to above.

As a general inventive concept, the present inventors have realized that the manner in which a service by a service terminal is provided to a user can be made more convenient and efficient by introducing a beacon transmitter device for the service terminal. A system server is also introduced to register a report from the user's mobile device that a beacon signal from the beacon transmitter device has been received, wherein the mobile device also reports a received signal strength. The service terminal obtains an estimated distance between the service terminal and the mobile device by communicating with the system server, and then uses the estimated distance as a basis for the provision of the service.

A first aspect of the present invention therefore is a method of providing a service by a service terminal to a user of a mobile device without requiring the user of the mobile device to interact with a user interface of the mobile device. The method involves providing a beacon transmitter device which is capable of sending a short-range wireless beacon signal. The beacon signal identifies a beacon region, and the service terminal is associated with the beacon region.

The method also involves providing a system server having a communication interface for data communication. The system server registers data communication from the mobile device reporting that it (i.e. the mobile device) has received the beacon signal. The data communication includes information indicative of a received signal strength of the beacon signal as received by the mobile device.

Moreover, the method involves the service terminal communicating with the system server to obtain an estimated distance between the service terminal and the mobile device.

The method also involves the service terminal communicating with the system server to obtain user data from a mobile device record controlled by said system server. The mobile device record is associated with the mobile device and/or the user, and the mobile device record contains one or more of the following: • an identity of the mobile device (MD), 'an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, ? public and/or private cryptographic keys, • reference data for authentication.

The service terminal then provides the service to the user of the mobile device based on the estimated distance and using the obtained user data.

Hence, an improved, distance-based and beacon-triggered method of providing a service by a service terminal to a user of a mobile device has been provided.

Another aspect of the present invention is a communication system comprising: a service terminal, the service terminal being associated with a beacon region; a beacon transmitter device, the beacon transmitter device being capable of sending a short-range wireless beacon signal, the beacon signal identifying the beacon region; and a system server, the system server having a communication interface for data communication.

The system server is configured to register data communication from a mobile device reporting that it has received the beacon signal, the data communication including information indicative of a received signal strength.

The system operates without requiring the user of the mobile device to interact with a user interface of the mobile device.

The service terminal is configured to communicate with the system server to obtain an estimated distance between the service terminal and the mobile device.

Also, the service terminal is configured to communicate with the system server to obtain user data from a mobile device record controlled by said system server. The mobile device record is associated with the mobile device and/or the user, and the mobile device record contains one or more of the following: • an identity of the mobile device (MD), 'an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, 'public and/or private cryptographic keys, • reference data for authentication.

The service terminal is configured to provide a service to a user of the mobile terminal based on the estimated distance and using the obtained user data.

Accordingly, an improved, distance-based and beacon-initiated communication system for providing a service by a service terminal to a user of a mobile device has been provided.

Other aspects, objectives, features and advantages of the disclosed embodiments will appear from the following detailed disclosure, from the attached dependent claims as well as from the drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein.

All references to "a/an/the [element, device, component, means, step, etc]" are to be interpreted openly as referring to at least one instance of the element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF DRAWINGS Fig 1 illustrates an embodiment of a communication system for providing a service by a service terminal to a user of a mobile device, the system also comprising a beacon transmitter device and a system server. Fig 2 is a schematic flowchart diagram illustrating a method of providing a service by a service terminal to a user of a mobile device. Fig 3 illustrates another embodiment of a communication system for providing a service by a service terminal to a user of a mobile device. Fig 4 illustrates a first exemplary way of making the provision of the service dependent on an estimated distance between the service terminal and the mobile device. Figs 5A-5B illustrate a second exemplary way of making the provision of the service dependent on an estimated distance between the service terminal and the mobile device. Figs 6A and 6B are schematic views of a mobile device according to two respective embodiments. Fig 7 is a schematic view of components of the mobile device in Figs 6A or 6B.

Fig 8 is a schematic view of a computer-readable medium.

Fig 9 is a schematic view of components of a beacon transmitter device.

DETAILED DESCRIPTION The disclosed embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

A communication system 100 for providing a service by a service terminal ST to a user U of a mobile device MD is shown in Fig 1. The service may, for instance, involve a monetary transaction to be performed for a purchase at, for instance, a shop, restaurant, cultural venue or sport arena. The service terminal ST may then, for instance, be a point-of-sales terminal, cash register or ticket desk. This scenario will be used as a non-limiting example for the following detailed description.

Exemplary embodiments of the mobile device MD are described later in this section with reference to Figs 6A, 6B and 7.

The communication system 100 also comprises a system server SS. The system server SS may generally be implemented by any suitable computing resource, such as a stationary computer, a portable computer, a mobile device, or a cloud computing resource. The system server SS has a communication interface for data communication, in accordance with one or more standards or protocols that also mobile device MD is compliant with. Examples of such standards include IEEE 802.11, IEEE 802.15, ZigBee, WirelessHART, WiFi, WCDMA, HSPA, GSM, UTRAN, UMTS, and LTE. Such data communication is indicated in Fig 1 by way of thick double-ended arrows.

The communication system 100 also comprises a short-range wireless beacon transmitter device BTD. The beacon transmitter device BTD may be a stationary (static-location) beacon transmitter device, or a mobile beacon transmitter device for instance in the form of a mobile device which is enabled for beacon communication. Even though shown as separate devices in Fig 1, the wireless beacon transmitter device BTD and the service terminal ST may be implemented by one and the same physical device, such as a tablet computer, in some embodiments.

In one embodiment, the beacon transmitter device BTD is compliant with the iBeacon technology from Apple. The iBeacon technology is based on the Bluetooth Low Energy (BLE) standard, and more particularly on Generic Access Profile (GAP) advertising packets. An exemplary embodiment of the beacon transmitter device BTD is described later in this section with reference to Fig 9.

There are several other kinds of short-range wireless beacon technologies, for instance AltBeacon, URIBeacon and Eddystone, which are also based on BLE and GAP and which may implement the beacon transmitter device BTD in alternative embodiments.

The beacon transmitter device BTD repeatedly broadcasts a short-range wireless beacon signal (also known as a beacon advertisement signal) BA in a 31-byte GAP BLE packet. Such beacon-based communication is indicated in Fig 1 by way of a thin single-ended arrow.

The beacon signal BA contains a 128-bit universally unique identifier, UUID. The beacon signal BA may also include a 16-bit major portion and a 16-bit minor portion. The beacon signal BAi identifies a beacon region associated with the beacon transmitter device Bi. Whereas, as is commonly known, a geographical region is an area defined by a circle of a specified radius around a known point on the Earth's surface, a beacon region is in contrast an area defined by a mobile device's proximity to one or more beacon transmitter devices.

In some implementations, the beacon region is represented by the UUID, the major portion and the minor portion in the beacon signal BA. In other implementations, the beacon region is represented by the UUID and the major or minor portion in the beacon signal BA. In still other implementations, the beacon region is represented by the UUID alone.

Generally, beacon-enabled mobile devices, including mobile device MD, can receive the beacon signal BA and react accordingly. To this end, in some implementations, the mobile devices are provided with an application program, app, which is configured to detect and react on short-range wireless beacon signals, such as beacon signal BA, with support from the underlying operating system. In other implementations, this beacon functionality may be handled directly in the operating system.

Mobile devices (e.g. by means of an app or directly by the operating system) can generally detect and react on beacons in two ways,monitoringandranging.Monitoring enables the mobile device to detect movement in and out of the beacon region (i.e., whether the mobile device is within or outside of the range of any of the beacon transmitter devices with which the beacon region is associated). Hence, monitoring allows the mobile device to scan for beacon regions. Ranging is more granular and provides a list of beacon transmitter devices in range, together with their respective received signal strength, which may be used to estimate a distance to each of them. Hence, ranging allows the mobile device to detect and react on individual beacon transmitter devices in a beacon region.

A method of providing a service by the service terminal ST to a user U of the mobile device MD in the communication system 100 of Fig 1 will now be described with reference also to Fig 2.

In a first step 210, the beacon transmitter device BTD sends the beacon signal BA. This is also seen at 110 in Fig 1. If the mobile device MD is near the beacon transmitter device BTD, i.e. within the beacon region, it may receive the beacon signal BA in step 215 of Fig 2.

In step 220 of Fig 2, the mobile device MD reports to the system server SS that it has received the beacon signal BA. This is also seen at 120 in Fig 1. This report is also known as an "entry" event with respect to the beacon region identified in the beacon signal BA. The report includes a received signal strength (e.g. RSSI, Received Signal Strengh Indicator) of the beacon signal BA as received at the mobile device MD. The received signal strength may for instance, be expressed as a relative power value in dBm and may typically be obtained by the aforementioned ranging functionality.

In step 230 of Fig 2, the system server SS registers the report from the mobile device MD. This is also seen at 130 in Fig 1, the registration may be made in a database SSDB in or associated with the system server SS. In some embodiments, e.g. Fig 3, the registration 130, 230 is made by updating a mobile device record MDR which is kept in the database SSDB and is associated with the mobile device MD, the user U, or both. The registration may include making a note in the mobile device record MDR that the mobile device MD has now entered the beacon region, together with a note of the current date and time, and the RSSI.

The procedure according to steps 210-230/110-130 may be repeated each time the mobile device MD is capable of receiving the repeatedly transmitted beacon signal BA and reacting by reporting the respective receptions to the system server SS.

Thanks to the detection of the appearing mobile device MD through the beacon signaling and the subsequent reporting to and registration by the system server SS, the service terminal ST may initiate a service to the user of the mobile device MD without requiring the user U of the mobile device MD to interact with the user interface of the mobile device to make this initiative (as is the case in typical prior art e-wallet solutions). This is so, since the service terminal ST may communicate with the system server SS, see 140 in Fig 1 and 240 in Fig 2, and be informed not only of the presence of the mobile device MD in the beacon region associated with the service terminal ST, but in addition also of an estimated distance between the service terminal ST and the mobile device MD. A beacon-triggered, distance-based provision of service to the user U is therefore made possible, as will now be described in more detail.

As already mentioned, the service terminal ST communicates with the system server SS in step 240 in Fig 2. This is seen at 140 in Fig 1. As a result of the communication, the system server SS obtains an estimated distance between the service terminal ST and the mobile device MD. This distance may be obtained in different ways. For instance, the system server SS may retrieve the received signal strength registered in the mobile device record MDR upon the mobile device's reporting in steps 120-130/220-230, and convert it into a distance with respect to the location of the beacon transmitter device BTD. If the beacon transmitter device BTD is placed at or immediately near the service terminal ST, the converted distance may be used directly as the estimated distance between the service terminal ST and the mobile device MD. In cases where the beacon transmitter device BTD is not placed at or immediately near the service terminal ST, the converted distance may be combined with a known relative distance between the service terminal ST and the beacon transmitter device BTD to obtain the estimated distance between the service terminal ST and the mobile device MD.

In some implementations, the system server SS may convert the received signal strength values into distance values already at the registration step 130/230. In other implementations, the system server SS may send received signal strength values to the service terminal ST in the communication step 140/240, wherein the service terminal ST will itself make the necessary conversion and calculations to obtain the estimated distance between the service terminal ST and the mobile device MD.

In step 250 of Fig 2, the service terminal ST provides the service to the user U based on the obtained estimated distance. This is seen at 150 in Fig 1. The obtained estimated distance may be used to control whether or not the provision of the service to the user U shall be initiated. Hence, the service terminal ST may check the obtained estimated distance between the service terminal ST and the mobile device MD, and initiate the service only when the estimated distance meets a threshold criterion.

In one embodiment, the threshold criterion is that the estimated distance between the service terminal ST and the mobile device MD is less than a distance between the service terminal ST and another mobile device MD2. An example situation of this is shown in Fig 4. A rationale for this decision is that the service shall only be initiated to the nearest mobile device user in a first-come-first-served fashion representing a queue of customers at the service terminal ST.

In another embodiment, the threshold criterion is that the estimated distance between the service terminal ST and the mobile device MD is less than a certain distance, such as for instance 1 meter, 2 meters, etc. A rationale for this decision is that the service to the user U shall only be initiated when the user U is sufficiently near the service terminal ST; if the user U is strolling around in for instance a shop, the service shall not be initiated until the user U (as evidenced by the mobile device MD) has approached the point-of sales terminal/cash register/ticket desk, etc.

An example situation of this is shown in Figs 5 A and 5B. In Fig 5 A, the mobile device MD first enters into the beacon region of the beacon transmitter device BTD and detects the beacon signal BA at 110a. This may occur at a considerable distance from the beacon transmitter device BTD, such as 25-75 meters. The mobile device MD reports to the system server SS at 120a, and the system server SS makes a registration at 130a. The received signal strength given in the report from the mobile device MD results in step 140a in an estimated distance which exceeds the threshold value (e.g. 1-2 meters). Accordingly, the service terminal ST does not initiate the service.

The procedure is repeated at 110b/120b/13 Ob/140b and at 110c/120c/130c/140c as the mobile device MD is moved closer to the beacon transmitter device BTD; it is however still not close enough to yield a received signal strength which will result in an obtained estimated distance less than the threshold value. As a result, the service terminal ST will still not initiate the service.

Finally, as seen in Fig 5B, the mobile device MD is moved even closer to the beacon transmitter device BTD, and the obtained estimated distance becomes less than the threshold value. See 110d/120d/130d/140d in Fig 5B. As a result, the service terminal ST will indeed initiate the service at 150/250 to the user U of the mobile device MD. Particularly when the service involves a monetary transaction, since the service is performed only when the user U of the mobile device MD has been found to be present locally in the immediate proximity of the service terminal ST, the service provider of the service may beneficially categorize the transaction as being equivalent or corresponding to a "card present" type of transaction, i.e. a transaction with high confidence - in contrast to a less confident "card non present" type of transaction. As a result, the service provider may charge a lower service fee for the "card present" type of transaction.

For the performance of the service to the user U of the mobile device MD, the service terminal ST may communicate with the system server SS to obtain user data from the mobile device record MDR controlled by the system server. The mobile device record may, for instance, contain one or more of the following: • an identity of the mobile device MD, • an identity of the user U of the mobile device MD, • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, • public and/or private cryptographic keys, and • reference data for authentication.

The user data may be obtained at the same time as the estimated distance is obtained, i.e. in step 240/140, or in a separate communication 142 as seen in Figs 3 and 4.

The service terminal ST may use the obtained data from the mobile device record MDR when providing the service at 150/250 to the user U of the mobile device MD. For instance, when the service involves a monetary transaction, the service terminal ST may make beneficial use of for instance credit card information or payment account information for the user U, without requiring the user U to make an active effort to provide the information to the service terminal ST.

For improved security, public and/or private cryptographic keys in the mobile device record MDR can be used to protect sensitive data such as payment account information or credit card information by encryption. This may be useful both for active mobile devices and for passive mobile devices, as referred to later on in this document.

Alternatively or additionally, reliable authentication and secure identification of the beacon transmitter device BTD with respect to the mobile device MD may be provided in accordance with suitable technology which operates according to asymmetric encryption principles and has been developed by the present applicant. Details are disclosed in the Swedish patent application SE 1550357-6 'ASSET AUTHENTICATION IN A DYNAMIC, PROXIMITY-BASED NETWORK OF COMMUNICATION DEVICES", the contents of which are incorporated herein in their entirety. This may be particularly useful for active mobile devices as referred to later on in this document.

Hence, the mobile device MD may send an authentication request to the service terminal ST via a first communication interface for short-range wireless beacon broadcast messaging (such as interface 732 in Fig 7). The request may be sent via the beacon transmitter device BTD. The purpose of the authentication request may be to authenticate an asset being associated with the service terminal ST. The asset may, for instance, be or comprise an identity of the service terminal ST.

The service terminal ST may receive the authentication request via a first communication interface for short-range wireless beacon broadcast messaging (for instance via the beacon transmitter device BTD, such as via interface 932 in Fig 9) and in response communicate with the system server SS via a second communication interface (compliant with the system server's communication interface for data communication) to generate a digital signature by encrypting data which includes said asset with a private key for the service terminal ST.

As a result, the service terminal ST may send a signing completed report message about the generation of the digital signature to the mobile device MD via the first communication interface (for instance via the beacon transmitter device BTD).

The mobile device MD may then receive the signing completed report message via the first communication interface and in response communicate with the system server SS via the second communication interface to retrieve an authentication result.

The authentication result may be presented in the user interface of the mobile device MD or the service terminal ST, and the user may choose to proceed with the monetary transaction only if the authentication result indicates successful authentication.

Alternatively or additionally, for improved security, the service terminal ST may interact with the user U of the mobile device MD to let the user U acknowledge the monetary transaction.

In one embodiment, this involves receiving, by the service terminal ST, an input made by the user U, wherein the input comprises authentication control data such as, for instance, a passcode or a biometric sample (e.g. a fingerprint). The input may conveniently be made in a user interface of the service terminal ST. This is beneficial since it does not require the user U to activate the mobile terminal or an app therein. Hence, this may be particularly useful for passive mobile devices as referred to later on in this document. Since the user input is made in a user interface of the service terminal ST, the service provider may beneficially categorize the transaction as being equivalent or corresponding to a "card present" type of transaction, i.e. a transaction with high confidence, since the user is locally present and himself/herself makes the input of authentication control data.

Alternatively, the input of the authentication control data may be made in a user interface of the mobile device MD. In the latter case, the authentication control data will have to be sent by the mobile device MD to the service terminal ST. This may be particularly useful for active mobile devices as referred to later on in this document. Encryption or authentication of the authentication control data as transmitted by the mobile device MD to the service terminal ST may be employed for enhanced security, for instance as referred to above.

The service terminal ST then verifies the received authentication control data (as input either on the service terminal ST or on the mobile device MD) against reference data for authentication. These reference data are contained in the user data obtained from the system server SS in steps 140/240 or 142. The reference data may for instance contain a reference passcode or a biometric template, against which the received authentication control data can be compared.

The service (e.g. monetary transaction) will only be completed if the user U has acknowledged it by inputting the correct authentication control data which matches the reference data for authentication.

For the performance of the service to the user U, the service terminal ST may use a service provider server SP possibly having an associated database SPDB, as seen in Figs 3 and 4. For instance, in one embodiment, the service terminal ST communicates, 160, with the service provider server SP to customize a digital content to the user U. The customization may be based on one or more of the following parameters: • historic purchase behavior of the user U, • purchase behaviors of other users having made a same or related purchase as the user U intends to do, • a current calendar event, such as date, time, holiday, weekday, season, etc, • a waiting time for the user U before the service is initiated.

The service terminal ST will then interact with the user U of the mobile device MD to render the customized digital content available to the user U in a user interface of the service terminal ST or on the mobile device MD.

In an alternative embodiment, the service terminal ST is a digital signage terminal, and the service involves rendering a digital content available to the user U on the digital signage terminal. To this end, the service terminal ST may communicate, 160, with a service provider server SP to customize the digital content to the user U, for instance based on one or more of the parameters referred to immediately above.

The service terminal (digital signage terminal) ST may then interact with the user U of the mobile device MD to render the digital content available to the user U on the digital signage terminal.

The present inventors have identified certain shortcomings of a prior art beacon technology. This will now be explained.

As already described previously in this document, the beacon-enabled apps in the mobile devices may be handled by the operating system of the mobile device in different modes. The most prominent mode is theactive mode,in which the app executes in the foreground and is typically capable of interacting with the user through the user interface of the mobile device and also to communicate with an external device such as a server via the short-range wireless beacon interface and/or another communication interface. As regards short-range wireless beacon communication, ranging generally only works when the app is in active mode.

A mobile device where the app is in active mode is referred to as anactive mobile devicein this document. An active mobile device may receive and react to additional transmissions of a beacon signal from a beacon transmitter device; this may be useful for instance if a content associated with a host of the beacon transmitter device is updated or changed. Furthermore, an active mobile device may receive and react to beacon signals from other beacon transmitter devices nearby, provided of course that they are within range of the respective beacon transmitter device. This is so irrespective of whether the different beacon transmitter devices advertise the same beacon region (i.e. contain the same UUID and major/minor in the respective beacon signals), or different beacon regions (provided that the app is configured to monitor for such different beacon regions). It is to be noticed that the same beacon region (e.g. same UUID) is very often used for different beacon transmitter devices hosted by the same host, such as within the same supermarket, arena, fastfood restaurant, etc.

The operating system of the mobile devices may also handle apps ina passive mode.A purpose of the passive mode is power preservation, since the mobile devices are typically powered by batteries and since it is a general technical ambition to maximize the operational time of a mobile device between successive charging sessions. In the passive mode, the app executes in the background or is only installed on the mobile device. Unlike ranging which generally only works when the app is in active mode, monitoring works when the app is in active mode as well as when the app is in passive mode.

Transitions between active mode and passive mode may be based on user interaction, user preference settings in the app or the operating system, or program logic in the app or the operating system.

A mobile device where the app is in passive mode is referred to asa passive mobile devicein this document. In the passive mode, the app typically cannot interact with the user via the user interface, nor communicate with a server or another device - except for the following. Just like active mobile devices, a nearby passive mobile device may monitor for a beacon region and hence receive a short-range wireless beacon signal if it is within range of the beacon transmitter device in question. However, unlike active mobile devices, after a short beacon scanning period in the monitoring, during which the beacon transmitter device is discoverable, a received signal strength is determinable (e.g. by ranging functionality) and also communication with a server or another device is possible (e.g. to make a report to the system server SS as described above for step 220 in Fig 2), and unless it switches to active mode, the passive mobile device will then not be able to react to additional beacon signals for the same beacon region from the beacon transmitter device.

Instead, after the short beacon scanning period (which typically lasts for some seconds, such as about 10 seconds), the passive mobile device will be "ignorant" or "deaf to", i.e. not react on, additional beacon signals for the same beacon region for as long as it stays in passive mode and continues to detect such beacon signals, for instance because it remains within range of the beacon transmitter device and continues to detect its beacon signal. Only once the passive mobile device has not received the beacon signal, or any other beacon communication which advertises the same beacon region, for a certain time, such as 1-15 minutes, the passive mobile device will again be reactive to the beacon signal, or any other beacon communication which advertises the same beacon region.

This is potentially a severe problem in a beacon-based communication system like the system 100 as described herein. This is so, because if the mobile device MD is in passive mode, it will only be capable of reporting to the system server SS the first time it hears the beacon signal BA. Subsequent transmissions of the beacon signal BA will not be reacted upon if the mobile device MD is in passive mode. In the situation in Figs 5A-5B, this would have meant that the passive mobile device MD would have reacted properly on the first transmission 110a of the beacon signal BA by reporting to the system server SS at 120a, but would not have reacted on the subsequent transmissions 110b, 110c or 1 lOd. Hence, the system server SS would not have received any reports 120b, 120c or 120d, and the service terminal ST would not be able to determine at 140d/142d that the mobile device MD is close enough to initiate the service at 150.

Fortunately, however, the present applicant has developed solutions to this potentially severe problem.

According to one such solution, the beacon transmitter device BTD repeatedly transmits, 210, the short-range wireless beacon signal BA on a first beacon broadcast channel. The first beacon broadcast channel may be represented by a first value, e.g. UUID1, in the UUID Major+Minor portion of the wireless beacon signal BA.

The beacon transmitter device BTD, or another beacon transmitter device in the beacon region, then temporarily transmits a short-range wireless beacon refresh signal on a second beacon broadcast channel, different from the first beacon broadcast channel. The second beacon broadcast channel may be represented by a second value, e.g. UUID2, in the UUID Major+Minor portion of the wireless beacon signal BA. The beacon refresh signal is adapted to cause the mobile device MD, when being in a passive mode, to enter into a short-range wireless beacon scanning mode and thus become able to react properly on subsequent transmissions of the short-range wireless beacon signal BA on the first beacon broadcast channel.

Advantageously, the beacon transmitter device BTD may transmit the short-range wireless beacon signal BA on the first beacon broadcast channel at a first transmit power, whereas the beacon transmitter device BTD or said another beacon transmitter device may transmit the short-range wireless beacon refresh signal on the second beacon broadcast channel at a second transmit power being lower than the first transmit power. This is beneficial since it will limit the refresh activity (the awakening of deafened out passive mobile devices) to an area proximate to the service terminal ST but avoid awakening other mobile devices which are anyway not close enough to the service terminal ST to initiate the service to the user U.

Details of this solution are disclosed in the Swedish patent application 1551329-4 "IMPROVED ABILITY TO DETECT PASSIVE BEACON RECEIVER DEVICES IN A SHORT-RANGE WIRELESS BEACON COMMUNICATION SYSTEM", the contents of which are incorporated herein in their entirety.

According to another solution developed by the present applicant, the beacon transmitter device BTD makes a first transmission, 210, of the short-range wireless beacon signal BA. The beacon transmitter device BTD then waits during a beacon delay time period being sufficiently long to allow the mobile device MD, when being in a passive mode and having received the first transmission of the beacon signal, to receive and react on a second transmission of the beacon signal. The beacon transmitter device BTD then makes the second transmission of the short-range wireless beacon signal BA. The beacon delay time period is considerably longer (e.g. 30-45 seconds, if not longer) than the typical time period of the repeated broadcasting from existing beacon transmitter devices (where the transmissions of the beacon signals typically occur at an interval of about 1 second).

Details of this solution are disclosed in the Swedish patent application 1551516-6 "IMPROVED ABILITY TO INTERACT WITH PASSIVE BEACON RECEIVER DEVICES IN A SHORT-RANGE WIRELESS BEACON COMMUNICATION SYSTEM", the contents of which are incorporated herein in their entirety.

In the aforementioned prior art beacon technology, active mobile devices do ranging on a frequent basis, whereas passive mobile devices only do ranging during the short beacon scanning period but then not anymore for as long as they remain in passive mode and within the same beacon region. The teachings of the present invention are however generally applicable also to other beacon technologies, where passive mobile devices may do ranging throughout the passive mode, albeit perhaps less frequently than in active mode (to minimize the power consumption and save battery).

Generally, suitable beacon-based technology for use in implementing the beacon system 100 has been developed by the present applicant. This beacon-based technology considerably facilitates for users of mobile devices which are proximate to each other to interact by, for instance, sharing content or conducting social media interaction. The technology, which can be referred to as a "bubble" concept, is based on short-range wireless beacon broadcast messaging for establishing a dynamic, proximity-based network. Interaction between the users of the mobile devices in the network is supported by broadband communication with a server. Details are disclosed in the Swedish patent applications SE 1451203-2 "COMMUNICATION DEVICE FOR IMPROVED SHARING OF CONTENT", SE 1400535-9 "SELECTIVE USER INTERACTION IN A DYNAMIC, PROXIMITY-BASED GROUP OF WIRELESS COMMUNICATION DEVICES", SE 1451433-5 "DYNAMIC TIMING FOR IMPROVED COMMUNICATION HANDLING BETWEEN COMMUNICATION DEVICES", SE 1451509-2 "COMMUNICATION DEVICE FOR IMPROVED ESTABLISHING OF A CONNECTION BETWEEN DEVICES", and SE 1550486-3 "TEMPORARY PROXIMITY BASED LICENSE FOR APPLICATION ACCESS", the contents of which are incorporated herein in their entirety.

Figs 6A and 6B generally show a mobile, or wireless, communication device 600 which may implement the mobile device MD referred to above. Referring to Fig 6A, the wireless communication device is a mobile telecommunications terminal in the form of a smartphone or a tablet computer (arranged with a wireless communication interface), comprising a housing 610 in which a display 620 is arranged. In one embodiment the display 620 is a touch display. In other embodiments the display 620 is a non-touch display. Furthermore, the smartphone 600 comprises two keys 630a, 630b. In this embodiment there are two keys 630, but any number of keys is possible and depends on the design of the smartphone 600.

In one embodiment the smartphone 600 is configured to display and operate a virtual key 635 on the touch display 620. It should be noted that the number of virtual keys 635 depends on the design of the smartphone 600 and an application that is executed on the smartphone 600. The smartphone 600 may also be equipped with a camera 660. The camera 660 may be a digital camera that is arranged to take video or still photographs by recording images on an electronic image sensor (not shown). In one embodiment the camera 660 may be an external camera. In one embodiment the camera may alternatively be replaced by a source providing an image stream. The smartphone 600 may also be equipped with a loudspeaker 640 and a microphone 645.

Referring to Fig 6B, a laptop computer 600 comprises a display 620 and a housing 610. The housing comprises a controller or CPU (not shown) and one or more computer-readable storage media (not shown), such as storage units and internal memory. Examples of storage units are disk drives or hard drives. The laptop computer 600 further comprises at least one data port. Data ports can be wired and/or wireless. Examples of data ports are USB (Universal Serial Bus) ports, Ethernet ports or WiFi (according to IEEE standard 802.11) ports. Data ports are configured to enable the laptop computer 600 to connect with other computing devices or a server.

The laptop computer 600 further comprises at least one input unit such as a keyboard 630. Other examples of input units are computer mice, touch pads, touch screens or joysticks, to name a few.

The laptop computer 600 may further be equipped with a camera 660. The camera 660 may be a digital camera that is arranged to take video or still photographs by recording images on an electronic image sensor (not shown). In one embodiment the camera 660 may be an external camera. In one embodiment the camera may alternatively be replaced by a source providing an image stream. The laptop computer 600 may also be equipped with a loudspeaker 640 and a microphone 645. The wireless communication device 600 according to Fig 6A or Fig 6B may be configured to detect and track an object, for instance a hand of a user, via the camera 660.

Fig 7 shows a schematic view of the general structure of a communication device according to Fig 6A or Fig 6B. The device 700 comprises a controller 710 which is responsible for the overall operation of the wireless communication device 700 and is preferably implemented by any commercially available CPU ("Central Processing Unit"), DSP ("Digital Signal Processor") or any other electronic programmable logic device. The controller 710 is configured to read instructions from a memory 740 and execute these instructions to control the operation of the wireless communication device 200. The memory 740 may be implemented using any commonly known technology for computer-readable memories such as ROM, RAM, SRAM, DRAM, CMOS, FLASH, DDR, SDRAM or some other memory technology. The memory 740 is used for various purposes by the controller 710, one of them being for storing application data and program instructions 750 for various software modules in the wireless communication device 700. The software modules may include a real-time operating system, drivers for a user interface 720, an application handler as well as various applications 750.

The wireless communication device 700 further comprises the user interface 720, which in the devices 700 of Figs 6A and 6B is comprised of the display 620 and the keys 630, 635. The user interface may also comprise the microphone 645 and the loudspeaker 644.

The wireless communication device 700 further comprises wireless communication means 730, which is adapted to allow the wireless communication device 700 to communicate with other devices through the use of different radio frequency technologies. More specifically, the wireless communication means 730 comprises a first communication interface 732 for short-range wireless beacon broadcast messaging. The first communication interface 732 may implement the short-range wireless beacon transmitter as referred to previously in this document and may, advantageously, be implemented as an iBeacon and/or Bluetooth Low Energy (BLE)/Bluetooth 4.0 compliant communication interface.

Moreover, the wireless communication means 730 comprises a second communication interface 734 for communicating with a server like the system server SS and/or the service provider SP via the communication network NW. The communication with the server typically occurs at a substantially higher bandwidth than the short-range wireless beacon broadcast messaging. The server may be a standalone computing resource external to the wireless communication device 700, a cloud-based (distributed) computing resource, or, in alternative embodiments, implemented at least partly in and by the wireless communication device 700. The second communication interface 734 may, advantageously, be implemented as a communication interface compliant with IEEE 802.11, IEEE 802.15, ZigBee, WirelessHART, WiFi, Bluetooth<®>, WCDMA, HSPA, GSM, UTRAN, UMTS, and LTE, to name a few. It should be noted that, as is commonly known, the wireless communication means 730 may be arranged to communicate according to more than one technology and many different combinations may therefore be available; for example, a smartphone is commonly arranged to communicate according to the Bluetooth<®>standard, the WiFi standard and the LTE standard.

The wireless communication device 700 is further equipped with a camera 760. The camera 760 is a digital camera that is arranged to take video or still photographs by recording images on an electronic image sensor (not shown). The camera 760 is operably connected to the controller 710 to provide the controller with a video stream 765, i.e. the series of images captured, for further processing possibly for use in and/or according to one or several of the applications 750. In one embodiment the camera 760 is an external camera or source of an image stream.

Fig 9 shows a schematic view of the general structure of a communication device 900 which may implement the beacon transmitter devices BTD as described herein. The device 900 comprises a controller 910 which is responsible for the overall operation of the wireless communication device 900 and is preferably implemented by any commercially available CPU ("Central Processing Unit"), DSP ("Digital Signal Processor") or any other electronic programmable logic device. The controller 910 is configured to read instructions from a memory 940 and execute these instructions to control the operation of the wireless communication device 900. The memory 940 may be implemented using any commonly known technology for computer-readable memories such as ROM, RAM, SRAM, DRAM, CMOS, FLASH, DDR, SDRAM or some other memory technology. The memory 940 is used for various purposes by the controller 910, one of them being for storing application data and program instructions 750 for software which defines the device's 900 operating as a beacon transmitting device.

The wireless communication device 900 further comprises wireless communication means 930, which is adapted to allow the wireless communication device 900 to communicate with other devices. More specifically, the wireless communication means 930 comprises at least a first communication interface 932 which supports short-range wireless beacon broadcast messaging and may, advantageously, be implemented as an iBeacon<®>and/or Bluetooth Low Energy (BLE)/Bluetooth 4.0 compliant communication interface. The first communication interface 932 may implement a short-range wireless beacon transmitter.

The wireless communication means 930 may also comprise a second communication interface 934 for communicating with a server like the system server SS and/or the service provider SP via a communication network. The second communication interface 934 may, advantageously, be implemented as a communication interface compliant with IEEE 802.11, IEEE 802.15, ZigBee, WirelessHART, WiFi, Bluetooth<®>, WCDMA, HSPA, GSM, UTRAN, UMTS, and LTE, to name a few.

References to 'computer-readable storage medium', 'computer program product', 'tangibly embodied computer program' etc. or a 'controller', 'computer', 'processor' etc. should be understood to encompass not only computers having different architectures such as single /multi- processor architectures and sequential (Von Neumann)/parallel architectures but also specialized circuits such as field-programmable gate arrays (FPGA), application specific circuits (ASIC), signal processing devices and other devices. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

Fig 8 shows a schematic view of a computer-readable medium as described in the above. The computer-readable medium 830 is in this embodiment a data disc 830. In one embodiment the data disc 830 is a magnetic data storage disc. The data disc 830 is configured to carry instructions 831 that when loaded into a controller, such as a processor, executes a method or procedure according to the embodiments disclosed above. The data disc 830 is arranged to be connected to or within and read by a reading device 832, for loading the instructions into the controller. One such example of a reading device 832 in combination with one (or several) data disc(s) 830 is a hard drive. It should be noted that the computer-readable medium can also be other media such as compact discs, digital video discs, flash memories or other memory technologies commonly used.

The instructions 831 may also be downloaded to a computer data reading device 834, such as a laptop computer or other device capable of reading computer coded data on a computer-readable medium, by comprising the instructions 831 in a computer-readable signal 833 which is transmitted via a wireless (or wired) interface (for example via the Internet) to the computer data reading device 834 for loading the instructions 831 into a controller. In such an embodiment the computer-readable signal 833 is one type of a computer-readable medium 830. The instructions may be stored in a memory (not shown explicitly in Fig 8, but referenced as 740 in Fig 8) of the computer data reading device 834.

References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

The various functionality described in this document may be performed in part or fully in a wireless communication device 700 or 900 comprising a controller as disclosed above with reference to Figs 6A, 6B, 7 and 9, and/or caused to be performed by executing instructions stored on a computer-readable medium as disclosed with reference to Fig 8.

The location of applications programs, or apps, as referred to in this document with respect to a hierarchical software model is not critical; hence, they may be located at an application layer or alternatively at a lower layer, such as for instance being part of an operating system.

Even though the embodiments described above are based on beacon systems where a beacon region is represented by a universally unique identifier (UUID), the invention may be applied also to other types of beacon systems. For instance, the invention may be applied to beacon system like AltBeacon, URIBeacon and Eddystone, which do not use a UUID but another form of identity (such as a tiny URL) in the 31-byte GAP BLE packet for the beacon signal.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

1. A method of providing a service by a service terminal (ST) to a user (U) of a mobile device (MD) without requiring the user of the mobile device to interact with a user interface of the mobile device, the method involving: providing a beacon transmitter device (BTD), the beacon transmitter device being capable of sending (110, 210) a short-range wireless beacon signal (BA), the beacon signal identifying a beacon region, the service terminal being associated with the beacon region; providing a system server (SS), the system server having a communication interface for data communication; the system server registering (130, 230) data communication from the mobile device reporting (120, 220) that it has received the beacon signal, the data communication including information indicative of a received signal strength; the service terminal communicating (140, 240) with the system server to obtain an estimated distance between the service terminal and the mobile device; the service terminal (ST) communicating (140; 142) with the system server (SS) to obtain user data from a mobile device record (MDR) controlled by said system server, the mobile device record being associated with the mobile device (MD) and/or the user (U) and the mobile device record containing one or more of the following: • an identity of the mobile device (MD), • an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, • public and/or private cryptographic keys, • reference data for authentication; and the service terminal providing (150, 250) the service to the user of the mobile device based on the estimated distance and using the obtained user data.

2. The method as defined in claim 1, wherein the service terminal (ST): checks the obtained estimated distance between the service terminal (ST) and the mobile device (MD); and initiates the service only when the estimated distance meets a threshold criterion.

3. The method as defined in claim 2, wherein the threshold criterion is that the estimated distance between the service terminal (ST) and the mobile device (MD) is less than a certain distance.

4. The method as defined in claim 2, wherein the threshold criterion is that the estimated distance between the service terminal (ST) and the mobile device (MD) is less than a distance between the service terminal (ST) and another mobile device (MD2).

5. The method as defined in any preceding claim, wherein the service involves a monetary transaction.

6. The method as defined in claim 5, wherein the service terminal (ST) uses the user data obtained from the system server (SS) for performing the monetary transaction, said user data being one or more of the following: • an identity of the mobile device (MD), • an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, • public and/or private cryptographic keys, and • reference data for authentication;

7. The method as defined in claim 6, further comprising: the service terminal (ST) interacting with the user (U) of the mobile device (MD) to let the user acknowledge the monetary transaction.

8. The method as defined in claim 7, wherein letting the user (U) acknowledge the monetary transaction involves: receiving, by the service terminal (ST), an input made by the user (U), the input comprising authentication control data; and verifying, by the service terminal (ST), the received authentication control data against reference data for authentication in the user data obtained from the system server (SS).

9. The method as defined in claim 5 or 6, further comprising: the service terminal (ST) communicating (160) with a service provider server (SP) to customize a digital content to the user (U) based on one or more of the following: • historic purchase behavior of the user (U), • purchase behaviors of other users having made a same or related purchase as the user (U) intends to do, • a current calendar event, and • a waiting time for the user (U) before the service is initiated; and the service terminal (ST) interacting with the user (U) of the mobile device to render the digital content available to the user (U).

10. The method as defined in any of claims 1-4, wherein the service terminal (ST) is a digital signage terminal and the service involves rendering a digital content available to the user (U) on the digital signage terminal.

11. The method as defined in claim 10, further comprising: the service terminal (ST) communicating (160) with a service provider server (SP) to customize the digital content to the user (U) based on one or more of the following: • historic purchase behavior by the user (U), • purchase behaviors of other users having made a same or related purchase as the user (U) intends to do, • a current calendar event, and • a waiting time for the user (U) before the service is initiated; and the service terminal (ST) interacting with the user (U) of the mobile device (MD) to render the digital content available to the user (U).

12. A communication system comprising: a service terminal (ST), the service terminal being associated with a beacon region; a beacon transmitter device (BTD), the beacon transmitter device being capable of sending a short-range wireless beacon signal (BA), the beacon signal identifying the beacon region; and a system server (SS), the system server having a communication interface for data communication, wherein: the system operates without requiring the user (U) of the mobile device (MD) to interact with a user interface of the mobile device; the system server is configured to register (130, 230) data communication from a mobile device reporting (120, 220) that it has received the beacon signal, the data communication including information indicative of a received signal strength; the service terminal is configured to communicate (140, 240) with the system server to obtain an estimated distance between the service terminal and the mobile device; the service terminal is configured to communicate (140; 142) with the system server to obtain user data from a mobile device record (MDR) controlled by said system server, the mobile device record being associated with the mobile device (MD) and/or the user (U) and the mobile device record containing one or more of the following: • an identity of the mobile device (MD), • an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, • public and/or private cryptographic keys, • reference data for authentication; and the service terminal is configured to provide (150, 250) a service to a user (U) of the mobile terminal based on the estimated distance and using the obtained user data.

13. The communication system as defined in claim 12, wherein the service terminal (ST) is configured to: check the obtained estimated distance between the service terminal (ST) and the mobile device (MD); and initiate the service only when the estimated distance meets a threshold criterion.

14. The communication system as defined in claim 13, wherein the threshold criterion is that the estimated distance between the service terminal (ST) and the mobile device (MD) is less than a certain distance.

15. The communication system as defined in claim 13, wherein the threshold criterion is that the estimated distance between the service terminal (ST) and the mobile device (MD) is less than a distance between the service terminal (ST) and another mobile device (MD2).

16. The communication system as defined in any of claims 12-15, wherein the service involves a monetary transaction.

17. The communication system as defined in claim 16, wherein the service terminal (ST) is configured to use the user data obtained from the system server (SS) for performing the monetary transaction, said user data being one or more of the following: • an identity of the mobile device (MD), • an identity of the user (U) of the mobile device (MD), • payment account information for the user of the mobile device, • credit card information for the user of the mobile device, • public and/or private cryptographic keys, and • reference data for authentication;

18. The communication system as defined in claim 17, wherein the service terminal (ST) is configured to interact with the user (U) of the mobile device (MD) to let the user acknowledge the monetary transaction.

19. The communication system as defined in claim 18, wherein the service terminal (ST) is further configured to let the user (U) acknowledge the monetary transaction by: receiving an input made by the user (U), the input comprising authentication control data; and verifying the received authentication control data against reference data for authentication in the user data obtained from the system server (SS).

20. The communication system as defined in claim 16 or 17, wherein the service terminal (ST) is configured to communicate (160) with a service provider server (SP) to customize a digital content to the user (U) based on one or more of the following: • historic purchase behavior of the user (U), • purchase behaviors of other users having made a same or related purchase as the user (U) intends to do, • a current calendar event, and • a waiting time for the user (U) before the service is initiated; and wherein the service terminal (ST) is configured to interact with the user (U) of the mobile device to render the digital content available to the user (U).

21. The communication system as defined in any of claims 12-15, wherein the service terminal (ST) is a digital signage terminal and the service involves rendering a digital content available to the user (U) on the digital signage terminal.

22. The communication system as defined in claim 21, wherein the service terminal (ST) is configured to communicate (160) with a service provider server (SP) to customize the digital content to the user (U) based on one or more of the following: • historic purchase behavior by the user (U), • purchase behaviors of other users having made a same or related purchase as the user (U) intends to do, • a current calendar event, and • a waiting time for the user (U) before the service is initiated; and wherein the service terminal (ST) is configured to interact with the user (U) of the mobile device (MD) to render the digital content available to the user (U).