GB2550594A

GB2550594A - Presence detection and asset identification using bluetooth and hybrid-mode transmitters in dynamic assets such as rail trains and rail train vehicles

Info

Publication number: GB2550594A
Application number: GB1609094.6A
Authority: GB
Inventors: Shen Xingjie
Original assignee: Individual
Current assignee: Individual
Priority date: 2016-05-24
Filing date: 2016-05-24
Publication date: 2017-11-29
Also published as: GB201609094D0; WO2017203246A1

Abstract

A method, system, and computer program product comprises one or more transmitters which transmit an iBeacon (RTM) broadcast and a Bluetooth Low Energy (BLE) (RTM) broadcast, where at least one of the transmitted broadcasts includes an identifier specifying a train, where the transmitted broadcasts are captured by a handset and where the presence of the handset in the train is detected. The handset 100 detects broadcasts from the transmitters 102, and communicates with a server 106. The identifier may specify a carriage of the train. The iBeacon (RTM) and BLE broadcasts may be interleaved. The iBeacon (RTM) broadcast may wake up a handset application where major and minor iBeacon (RTM) identifiers prompt frequent application wake-ups and prevent third party wake-ups. The iBeacon (RTM) identifier is updated via the handset. Presence detection enables relevant content, such as rail journey updates, to be displayed on the handset when it is detected. Presence detection allows for automatic recognition of the identity of the train carriage when a customer is providing feedback to the transport provider. Feedback reports can include data about damage, cleanliness, and faulty components. The feedback enables the transport company to improve passenger journey experiences.

Description

TITLE

Presence detection and asset identification using Bluetooth and hybrid-mode transmitters in dynamic assets such as rail trains and rail train vehicles (carriages)

BACKGROUND OF INVENTION

Background

Rail train vehicles are dynamic assets, i.e. their geographic position is continually changing along their prescribed routes, hence using GPS (Global Positioning System) location data will not provide sufficient accuracy when cross-referencing between logged GPS co-ordinates of personal handheld devices and GPS co-ordinates of trains. Even if the live GPS data was superimposed between the rail train vehicle GPS identifier and the handheld device identifiers, the accuracy would not provide granularity to individual rail train vehicles (i.e. the individual carriages) within a set of rail train vehicles. Furthermore, current technologies within rail train vehicles for detecting presence suffer from limitations such as hardware installation (e.g. wifi triangulation).

Determining the status of transport vehicles is a valuable capability. For example, a transport operating company value knowing whether there is damage in or around their vehicles, or whether the aesthetic environment is of an acceptable standard. In both scenarios, being informed allow the transport operating companies to effect action to rectify shortcomings.

Knowledge of the types of shortcomings (e.g. interior damage, lack of cleanliness, defective components) within a transport vehicle (e.g. rail train vehicles) coupled with knowing which exact vehicle is being reported (e.g. rail train vehicle numbers, vehicle registration numbers) provide vital information on which a transport operating company can act to improve the passenger journey experience. Furthermore, the ability to exclusively communicate directly with the unique passenger providing the report will lead to further personalisation of the Journey experience.

Current technologies do not provide for a reliable reporting mechanism by passengers that additionally automatically identify the vehicles in which they are located, and allow the personalised individually directed response to the passenger.

Therefore, it would be useful to have better ways of reporting passenger concerns that are relevant to the vehicles in which they are located.

BRIEF DESCRIPTION OF DRAWINGS

Various embodiments of the Invention are disclosed In the following detailed description and the accompanying drawings. 1. FIG. 1 is a high level block diagram illustrating an embodiment of components that may be employed for presence detection. 2. FIG. 2 is a high level block diagram illustrating an embodiment of a transmitter. 3. FIG. 3 is a flow chart illustrating an embodiment of a process for broadcasting an identifier, and receipt at a server 4. FIG. 4 is a flow chart illustrating embodiments of a process to determine the rail train vehicle identity using server side computing

DETAILED DESCRIPTION OF THE INVENTION 5. The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, and/or a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. 6. A detailed description of one or more embodiments of the invention is provided below. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is not limited by these embodiments, and the invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example, and the invention may be practiced without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured. 7. Presence detection leading to asset identification, e.g., within a dynamic asset such as a rail train vehicle, can be used for a variety of purposes, such as presenting content relevant to the dynamic asset within which presence is detected (tailored commercial offerings from the transport provider) or allowing those present within the dynamic asset such as a rail train vehicle to provide opinions regarding their journey experience on the specific identified dynamic asset to the transport provider. 8. FIG. 1 is a high level block diagram illustrating an embodiment of components that may be used for presence detection and asset identification. In the provided example, handset 100 detects presence of transmitter 102 within the structure of the dynamic asset such as a rail vehicle 104 and reacts accordingly, e.g., by communicating with server 106 via a wireless network. Transmitter 102 may be configured for one or more of the following functionalities: to broadcast rail vehicle and carriage identifiers detectable by mobile users using both audio and Bluetooth technologies; to passively detect when a user enters a rail vehicle and notify the user of any relevant information, including, but not limited to, notifying the userto open an application to receive journey updates, ask the user for opinions regarding their journey experience. provide the user access to commercial offerings ; and to update the rail and carriage identifiers broadcast by the transmitter remotely and securely from a mobile handset. 9. The term “handset” as used herein may refer to any mobile computing device, such as a smartphone, a tablet, etc. A typical handset, such as handset 100 of FIG. 1, includes a microprocessor, a memory coupled to the microprocessor providing both code that the microprocessor executes and data under the control of the microprocessor, a display (e.g., a touch-sensitive display) through which the user may view and interact with user interface elements, a Bluetooth transceiver, a microphone, a cellular and/or wifi transceiver, and various other components. For the purposes of this exposition, when it is said that a handset performs a technique, this should be taken to mean that the microprocessor performs operations according to the code stored in its associated memory and interacts with other components within the handset, as necessary, to perform said technique. 10. In some embodiments, a transmitter, such as transmitter 102 of FIG. 1, incorporates a single technology: a Bluetooth Low Energy (BTLE) module that allow the transmitter to broadcast identifiers. Bluetooth and BTLE as used herein, as well as many Bluetooth specific terms known to those skilled in the art, are as set forth in the Specification of the Bluetooth System, version 4.0, dated Jun. 30, 2010, available online from the Bluetooth Special Interest Group at https://www.bluetooth.org/Technical/Specifications/adopted.htm and/or https://www. bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737, which are herein incorporated by reference in their entirety for all purposes, as if set forth in full herein. 11. FIG. 2 is a high level block diagram illustrating an embodiment of a transmitter. For example, transmitter 200 of FIG. 2 comprises transmitter 102 of FIG. 1. As depicted, transmitter 200 includes a microprocessor board 202. Note that use of the terminology “board” does not imply that a separate physical board is needed; all components (or all components except the tweeter) may be included in a single physical board. Microprocessor board 202 comprises a central processing unit (CPU) 204 and direct memory access (DMA) 206. Transmitter 200 further includes a Bluetooth Low Energy (BTLE) module 208. In some embodiments, BTLE module 208 comprises a standalone BTLE module that runs a minimalist stack and talks to microprocessor board 202 over universal synchronous/asynchronous receiver/transmitter (USART) link 210. 12. In some embodiments, a transmitter (e.g., transmitter 102 of FIG. 1 or transmitter 200 of FIG. 2) rail vehicle and/or carriage identifier(s) using Bluetooth channels. In some embodiments, for Bluetooth, an identifier is embedded in the advertisement parameters of a Bluetooth beacon and broadcast as a service that can be detected by mobile handsets using passive scanning of Bluetooth channels. 13. FIG. 3 is a flow chart illustrating an embodiment of a process for broadcasting and utilizing the identifier. Process 300 specifically employs a technique of the BTLE module beacon, that is to broadcast the service identifier which is a constant (e.g., 128 bit) universally unique identifier (UUID) to allow passive scanning under a handset operating system, such as iOS or Android.

In such cases, the secure identifier may be broadcasted as service parameters for the constant service. Thus, step 302 may include broadcasting the constant service UUID parameters via Bluetooth beacons. 14. As used herein, the rail train vehicle identifier may include a carriage identifier, either as a separate component of the rail train vehicle identifier, eras a single identifier that is associated, for example in a database, with separate rail vehicle and carriage identifiers. In an example, a single UUID is assigned to each rail train vehicle. 15. Process 300 of FIG. 3, for example, may be employed by a mobile handset. At step 302, UUID is broadcast. At step 304, the secure identifier is received by the handheld device. For example, the identifier may be sent to an associated (e.g. Transreport) server for comparison, as in step 306. In alternate embodiments, such processing may be performed on the handset. If the server is unavailable for any reason, the UUID identifier may be cached and relayed to the server when it becomes reachable. In order to support such offline situation, instance of the UUID identifier may be valid for a predetermined period of time (e.g., one hour). 16. Process 400 of FIG. 4, for example, may be employed server side, e.g., at a server associated with a mobile application that detects the UUID identifier at a handset. At step 402, a UUID is received from a mobile application. At step 404, the received UUID identifier is compared against a stored list of UUID identifiers on the server. Each UUID identifier on the stored list is mapped to an individual rail train vehicle, a match indicating the presence of the handheld device on a known rail train vehicle, step 406. In an example, rail train vehicle carriage with identity number 123456 (this number is for illustrative purposes only) has a BTLE beacon placed on it with UUID 1111111111111111 (this number is for illustrative purposes only); hence if the UUID received by the server is 1111111111111111 then after comparing against the master list, it is known to map onto rail vehicle carriage number 123456, hence it is determined the handset from which the UUID 1111111111111111 is transmitted to the server is located on rail carriage vehicle 123456. 17. In some embodiments, Bluetooth enabled transmitters may be used for fine-grained vehicle interior mapping. That is, the signal propagation properties of Bluetooth may be leveraged to perform fine-grained location mapping including, for example, accurate identification of a user when walking into a vehicle and tracking of the user as the user sits or stands within different sections in the vehicle. Such functionality may be achieved, for example, by placing one or more Bluetooth enabled transmitters in every vehicle of a train fleet and recording the signal strength of both audio and Bluetooth signals from all nearby transmitters on a mobile handset. In some such cases, clustering techniques (e.g., triangulation, sorting, etc.) may be employed to narrow the exact location of the mobile handset. Multiple signals from different transmitters can also be used as an authentication mechanism to safeguard against one-off transmitter thefts. 18. Many applications exist for the BTLE described herein. As described, the addition of a BTLE module to the transmitter allows several tasks to be performed efficiently. For example, update of the rail train and/or rail train vehicle identifier(s) of a transmitter may be remotely accomplished. Moreover, a transmitter may be detected while an associated application is in the background using passive scanning of Bluetooth services as supported in iOS and Android. Such passive Bluetooth detection may trigger multiple actions depending on the situation including, for example, reminding a user to open an application to get rewards, popping up alerts about transport provider specific offers, and using transport provider specific information from an associated application and the user's profile to show targeted advertisements and reminders. 19. Along with iOS 7, Apple introduced iBeacon. iBeacon comprises a specific format for broadcast messages that includes an identifier for the entity broadcasting as well as “major"’ and “minor” identifiers, which are capable of being used, for example, as train and/or vehicle identifier(s). The exact format of an iBeacon broadcast can be readily observed by one skilled in the art by capturing the BTLE broadcasts of an iBeacon with known “major"’ and “minor"’ identifiers. An advantage of iBeacons is that iOS 7 includes OS-level support for iBeacons so that applications can register for being waken up on detection of an iBeacon with a specific identifier. However, a downside of iBeacons is that the standard iBeacon implementation makes it very easy to free ride on infrastructure, e.g., by registering to get alerted to a particular entity's beacons and then using the “major” and “minor” identifiers for location identification. If the iBeacon protocol is used in its basic form, these beacons can be used to wake up an application. Moreover, there is no code rotation capability, and it is trivial to forge any transmission, so iBeacon broadcasts are open to fraud. 20. In some embodiments, iBeacon and proprietary BTLE broadcasts are interleaved. That is, in order to take advantage of the wake-up feature of iBeacon, but to avoid free-riding by competitors, iBeacon advertisement packets are interleaved with custom proprietary broadcasts. iBeacon signals just contain a 128 bit UUID, with nonsense major and minor identifiers. This is purposefully done to prevent competitors from using proprietary infrastructure for presence detection. As described in detail above, train and/or vehicle information in proprietary broadcasts is encrypted and/or digitally signed. In one example, iBeacon signals are interleaved with proprietary signals in a ratio of 3:1 (this value is tuned to minimize the latency of waking up but at the same time minimizing the time taken to decode the correct train and/or vehicle information from proprietary broadcasts), though other ratios are also workable. 21. In some embodiments, the major and/or minor iBeacon identifier(s) are rotated to prompt frequent application wake ups. In order to register for wake up, an application needs to specify either the iBeacon identifier or a combination of the iBeacon identifier and major and/or minor identifier(s). In the former case, iOS will only wake up an application once on entering a range of an iBeacon source that is broadcasting a desired iBeacon identifier. Hence even if multiple beacons broadcasting an iBeacon identifier exist, only the beacon that is encountered first by a device will wake up an application. The rest of the beacons do not lead to application wake ups. This can be a problem in larger deployments where it is desirable for an application to wake up to different beacons broadcasting the same iBeacon UUID. There exist multiple ways of solving this problem. One solution includes assigning different major and/or minor identifier(s) to every physical beacon and having an application then register to be woken up to all those combinations of IBeacon identifier and major and/or minor identifier(s). In this case, though, any third party application can identify the specific locations of all the beacons and can free ride on the beacon deployment. Thus, this solution or scheme may not be desirable. A more viable solution includes having every physical beacon broadcast the IBeacon identifier and rotating between a set of major and/or minor identifier(s). The application still registers to be woken up by all the set of major and/or minor identifiers, but there is no way for a competitor to map a particular beacon source to a major and/or minor identifier. The rotation scheme may be chosen such that probabilistically nearby beacons broadcast different major and/or minor identifiers, allowing an application to be woken up when it comes near different physical beacons. 22. In some embodiments, the IBeacon identifier is changed to prevent third party wake ups. In order to completely prevent third party applications from registering for wake ups from a prescribed, proprietary IBeacon identifier, the IBeacon identifier is updated from a client. Such an update can take place in phases. Until all the beacons are updated to the new IBeacon identifier, an associated application registers to be woken up by both the old and the new IBeacon identifiers, but once the update is complete, the application can switch to just the new IBeacon identifier. Depending on the frequency of this update, it can make any third party applications that are unaware of the new IBeacon identifier unreliable for wake ups. Thus, any commercial application that relies on a prescribed IBeacon identifier to be constant will experience poor wake ups and will need to constantly monitor and/or sniff Bluetooth signals in the field to be abreast of the latest IBeacon identifier. 23. In some embodiments, the IBeacon broadcast may be completely disabled for any specific periods of time. That is, IBeacon support can be turned off completely if desired so that third party applications cannot use proprietary beacons at all for wake ups. This can be enforced for any random period of time or can be permanent. It provides a final defense for private infrastructure deployment against any form of free riding. 24. Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

CLAIMS What is claimed is:

1. A method, comprising: creating an identifier that specifies a rail train vehicle; and configuring one or more transmitters to transmit an iBeacon broadcast and a proprietary Bluetooth Low Energy (BTLE) broadcast, wherein at least one of the transmitted broadcasts includes the identifier; wherein the transmitted broadcasts are captured by a handset and decoded to infer presence of the handset at the venue.

2. The method of claim 1, wherein the identifier comprises a train identifier that specifies a train.

3. The method of claim 1, wherein the identifier comprises a vehicle identifier that specifies a vehicle in a train.

4. The method of claim 1, wherein the iBeacon broadcast is employed to wake up a handset application configured to detect an associated service identifier.

5. The method of claim 1, further comprising interleaving the iBeacon broadcast and the proprietary BTLE broadcast.

6. The method of claim 1, further comprising rotating one or both of major and minor iBeacon identifiers to prompt frequent application wake ups.

7. The method of claim 1, further comprising changing the iBeacon identifier to prevent third party wake ups.

8. The method of claim 7, wherein the iBeacon identifier is updated via the handset.

9. The method of claim 1, wherein the identifier comprises a secure identifier.

10. The method of claim 1, further comprising updating at least one of the transmitters based on a directive received via the handset.

11. The method of claim 1, wherein the broadcasts captured at the handset are processed with respect to an application of the handset.

12. The method of claim 1, further comprising disabling the iBeacon broadcast for a prescribed period of time.

13. A system, comprising: a processor configured to generate an identifier that specifies a train; and one or more transmitters configured to transmit an iBeacon broadcast and a proprietary Bluetooth Low Energy (BTLE) broadcast, wherein at least one of the transmitted broadcasts includes the identifier; wherein the transmitted broadcasts are captured by a handset and decoded to infer presence of the handset within the vehicle of the train.

14. A computer program product, the computer program product being embodied in a non-transitory computer readable storage medium and comprising computer instructions for: generating an identifier that specifies a train vehicle; and configuring one or more transmitters to transmit an iBeacon broadcast and a proprietary Bluetooth Low Energy (BTLE) broadcast, wherein at least one of the transmitted broadcasts includes the identifier; wherein the transmitted broadcasts are captured by a handset and decoded to infer presence of the handset at the venue.