Description of Invention Embodiments of the present invention relate to systems and methods for use in locating a mobile device and/or reporting on the condition or status of assets.

Organisations often own and/or manage a large number of assets and these assets may be geographically distributed. In some instances, particularly in relation to organisations involved in transportation services (such as rail transportation, air transportation, bus/coach transportation, and the like) the assets may be mobile, such that they are not in the same geographical location at all times.

Determining the status of assets is a valuable capability. For example, an organisation may wish to know the health status or condition of their assets that cannot be

automatically monitored, or an organisation may be keen to know the cleanliness of their assets. Having such information available to them will allow organisations to take action to rectify shortcomings. Knowledge of the types of shortcomings of an asset, coupled with knowing which asset is being reported, provide vital information on which an organisation can act to improve the user experience of the asset.

For example, an organisation involved in rail transportation services may operate a number of trains, each including multiple carriages. There may be a plurality of seats, doors, and windows, provided in each of the carriages - along with other facilities such as rubbish bins (i.e. trash bins), toilets, telephones, display screens, tables, and the like. The train carriages may be cleaned and inspected at intervals - e.g. at the end of each day. However, the condition of the assets in each carriage may not be known at any given time between inspections. Accordingly, users may encounter assets in poor condition - which detracts from their experience of using the organisation's services. In addition, a periodic inspect may identify a fault or other condition which requires specialist operators to rectify. Such specialist operators may be not be available to rectify the issue before the carriage is required again. The reporting, by users, of faults or assets in a poor condition is problematic due to a need to identify the asset correctly. This is particularly true in relation to assets which are very similar (such as train carriages), seats, and the like. Even knowing the geographical location of the asset (e.g. using a satellite positioning system, such as the Global Positioning System or GLONASS) is of little assistance in some instances due to poor accuracy relative to the size of the asset. This is exasperated in relation to moving (i.e. dynamic) assets - as may be encountered in the provision of transportation services, for example.

Even cross-referencing between logged co-ordinates from a satellite positioning system and co-ordinates of dynamic assets may not provide sufficient accuracy to, for example, identify in which carriage of a train the asset is located. This also, of course, requires detailed information to be gathered about the location of the train, and its carriages, at all times. Other technologies, such as Wi-Fi triangulation are computationally expensive, require expensive equipment, and are generally problematic.

The status of an asset may include whether there is a fault and/or the condition of the asset. So, for example, the status may be whether the asset is non-functional, damaged, unclean, in an aesthetically unpleasant condition, or defective, for example.

Knowledge this status information for assets allows an organisation (such as a transportation service provider) to address the shortcomings and improve the user's experience (e.g. improve a user's journey). This is especially effective if the asset can be correctly identified and the status determined with sufficient detail to allow the organisation to know what action needs to be taken to rectify the problem.

In addition, if the location of a user relative to assets of an organisation (or managed by an organisation) can be determined, then the organisation can tailor how information is delivered to that user - e.g. in the form of pushed messages or the like.

There is a need, therefore, to provide effective ways of determining the location of a user relative to one or more assets, determining the identity of an asset, and conveying the status of the asset. Accordingly, an aspect of the present invention provides a system for reporting on the status or condition of assets, the system including: a beacon device configured to broadcast a beacon identifier; a mobile device configured to receive the beacon identifier broadcast by the beacon device, and to receive information entered by a user; a remote device, wherein the mobile device is further configured to transmit the entered information and location information derived from the beacon identifier to the remote device, such that a user can report on the status or condition of an asset which is identifiable using the location information.

The location information may be the beacon identifier. The beacon device may be configured to broadcast the beacon identifier using a radio frequency communication channel. The mobile device may be a mobile telephone and/or the remote device may be a server. The beacon device may be configured to broadcast a plurality of beacon identifiers in a cycle and/or to encrypt the beacon identifier and/or to cycle at least part of the beacon identifier. The beacon device may be configured to be secured to a transportation unit.

The information entered by the user may include an image captured by a camera of the mobile device. The information entered by the user may include alphanumeric text. The mobile device may be further configured to determine additional location information and to transmit the additional location information to the remote device in association with the information entered by the user. The additional location information may include a geographic location.

Another aspect provides a mobile device for reporting on the status or condition of mobile assets, the mobile device being configured to: receive a beacon identifier broadcast by a beacon device; receive information entered by a user; derive location information from the beacon identifier; and transmit the entered information and location information to a remote device, such that a user can report on the status or condition of an asset which is identifiable using the location information.

The location information may be the beacon identifier. The mobile device may be configured to receive the beacon identifier using a radio frequency communication channel. The mobile device may be a mobile telephone and/or the remote device may be a server. The mobile device may be configured to decrypt the beacon identifier. The information entered by the user may include an image captured by a camera of the mobile device. The information entered by the user may include alphanumeric text. The mobile device may be further configured to determine additional location information and to transmit the additional location information to the remote device in association with the information entered by the user. The additional location information may include a geographic location. Another aspect provides a computer implemented method for reporting on the status or condition of assets, the method including: broadcasting a beacon identifier from a beacon device; receiving, at a mobile device, the beacon identifier broadcast by the beacon device; receiving, at the mobile device, information entered by a user; and transmitting, from the mobile device to a remote device, the entered information and location information derived from the beacon identifier to the remote device, such that a user can report on the status or condition of an asset which is identifiable using the location information.

Another aspect provides a system for use in determining a location of a mobile device, the system including: a beacon device configured to broadcast a beacon identifier; and a mobile device configured to receive the broadcast beacon identifier, wherein the beacon identifier includes at least a portion which is changed between broadcasts and/or encrypted. The beacon identifier may include a main portion, a first sub-portion, and a second sub- portion, and at least one of the main portion, the first sub-portion and the second sub- portion are changed between consecutive broadcasts. The main portion may be a UUID, the first sub-portion may be a major identifier, and the second sub-portion may be a minor identifier. The entire beacon identifier may be changed between consecutive broadcasts. The beacon device may be configured to broadcast the beacon identifier using a radio frequency communication channel. The beacon device may be further configured to broadcast one or more additional beacon identifiers, wherein at least one of the beacon identifier and the one or more additional beacon identifiers may be broadcast using different identifier protocols. Another aspect provides a beacon device for use in determining the location of a mobile device, the beacon device configured to: broadcast a beacon identifier, wherein the beacon identifier includes at least a portion which is cycled between broadcasts and/or encrypted.

The beacon identifier may include a main portion, a first sub-portion, and a second sub- portion, and at least one of the main portion, the first sub-portion and the second sub- portion may be changed between consecutive broadcasts. The main portion may be a UUID, the first sub-portion may be a major identifier, and the second sub-portion may be a minor identifier. The entire beacon identifier may be changed between consecutive broadcasts. The beacon device may be configured to broadcast the beacon identifier using a radio frequency communication channel. The beacon device may be further configured to broadcast one or more additional beacon identifiers, wherein at least one of the beacon identifier and the one or more additional beacon identifiers are broadcast using different identifier protocols.

Embodiments are described, by way of example only, with reference to the

accompanying drawings, in which:

Figure 1 shows a system of some embodiments;

Figure 2 shows a beacon device of some embodiments;

Figure 3 shows a mobile device of some embodiments; and

Figures 4-7 show processes of some embodiments.

With reference to figures 1 -3, some embodiments include a communication system 1 which includes one or more mobile devices 1 and one or more beacon devices 2. The one or more beacon devices 2 are each configured to communicate with at least one of the one or more mobile devices 2.

This communication may include the provision, by the or each beacon device 2 of a beacon identifier to the at least one of the one or more mobile devices 2. This may be achieved, for example, by the or each beacon device 11 broadcasting its beacon identifier. The or each beacon device 2 may be associated with its own unique or substantially unique beacon identifier, such that the provision of a beacon identifier may allow the identity of the providing beacon device 2 to be determined. The or each beacon device 2 may include, for example, a transmitter 1 1 1 (see figure 2, for example). The transmitter 1 1 1 may be a wireless transmitter which is configured to transmit a wireless signal using, for example, a radio frequency communication channel. In some embodiments, the transmitter 1 1 1 is configured to transmit a relatively short range wireless signal (e.g. a range of less than 100m). In some embodiments, the transmitter 1 1 1 is configured to output a radio frequency signal of around 2.4GHz. In some embodiments, the transmitter 1 1 1 is configured to transmit a signal using a wireless communication protocol such as the Bluetooth protocol.

In some embodiments, the transmitter 1 1 1 is a Bluetooth transmitter. In some embodiments, the transmitter is a Bluetooth Low Energy transmitter.

In some embodiments, the transmitter 1 1 1 may incorporate a single technology: a Bluetooth Low Energy (BTLE) module that allows the transmitter 1 1 1 to broadcast one or more 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 which are herein incorporated by reference in their entirety for all purposes, as if set forth in full herein.

The transmitter 1 1 1 may be communicatively coupled to a processor 1 12 of the beacon device 1 1 . The processor 1 12 may be configured to control one or more aspects of the operation of the transmitter 1 1 1 and this may include, for example, determining one or more signals to be sent by the transmitter 1 1 1 (such as the beacon identifier). The processor 1 12 may be communicatively coupled to a computer readable medium 1 13 (such as a memory module) of the beacon device 1 1. The computer readable medium 113 may be configured to store, for example, the beacon identifier. In some embodiments, the computer readable medium 113 may be configured to store a program to control the operation of the processor 1 12.

The communicative coupling between the processor 1 12 and the transmitter 1 11 may be provided over a wired communication line which may be in the form of a bus. The computer readable medium 1 13 may also be communicatively coupled to the transmitter 1 1 1. In some embodiments, the communicative coupling between the computer readable medium 1 13 and the transmitter 1 1 1 is such that the communication need not be (or need not be entirely) via the processor 1 12. Accordingly, in some embodiments, the computer readable medium 113 may be in the form of a direct memory access module (and may, as will be understood, include a controller to manage direct memory access operations).

The communicative coupling between the processor 1 12 and the transmitter 1 11 may be via a universal synchronous/asynchronous receiver/transmitter (USART) link 1 14 of the beacon device 1 1 .

The processor 1 12 and the computer readable medium 113 may be provided as part of a single processor module or board 1 15 of the beacon device 1 1. The transmitter 1 1 1 may be provided as part of the single processor module or board 1 15 or may be provided separately and connected to the board 1 15 via a wired connector of the beacon device 1 1.

Accordingly, in some embodiments, the beacon device 11 is referred to as a

"transmitter" 1 1 . The beacon device 11 may include a microprocessor board 1 15. Note that use of the terminology "board" does not imply that a separate physical board is needed in all embodiments; all components (or all components except the transmitter 1 1 1 (which may be a "tweeter")) may be included in a single physical board 1 15 (which may be the single processor module or board 1 15 and which may be a microprocessor board 1 15). The microprocessor board 1 15 may comprises a central processing unit (CPU) 1 12 (which may be an example of the processor 112) and direct memory access (DMA) 1 13 (which may be an example of the computer readable medium 1 13). The beacon device 1 1 may further include a Bluetooth Low Energy (BTLE) module 1 1 1 (which may be an example of the transmitter 1 1 1 ). In some embodiments, BTLE module 11 1 comprises a standalone BTLE module 11 1 that runs a minimalist stack and talks to the microprocessor board 1 15 (or other board 1 15) over the universal

synchronous/asynchronous receiver/transmitter (USART) link 1 14 (which is an example of the communicative coupling as described above).

The beacon device 1 1 may be provided in a housing 1 1a, which may be a single housing 1 1 a which contains the aforementioned components of the beacon device 1 1. The housing 1 1 a may be configured to be secured to another object. This other object may include, for example, part of a transportation unit 100 - as described herein.

The beacon device 1 1 may include or may be coupled to a power supply which is configured to provide electrical power for use in powering the operations of the processor 1 12, the computer readable medium 1 13, the USART link 1 14, and/or the transmitter 1 1 1. The power supply may be in the form of a battery. In some

embodiments, the beacon device 1 1 is configured to be coupled to receive electrical power from the transportation unit 100. In some embodiments, the beacon device 1 1 is coupled to receive electrical power in this manner, and also has a battery. The battery, if provided, may be located in the housing 11 a. The or each mobile device 12 may be a mobile computing device such as a mobile (i.e. cellular) telephone, a tablet computer, a laptop, a smart watch, an electronic book reader (such as a Kindle(RTM) device), or the like.

The or each mobile device 12 (see figure 3, for example) may be a user owned and/or operated device 12 (in contrast to the beacon device 1 1 which is owned and/or operated by another entity (which may be a transportation services organisation or some other organisation)). In some embodiments, the or each mobile device 12 may be owned and/or operated by the same entity as the beacon devices 11 (e.g. with the mobile device 12 used by an operative of the transportation organisation).

As described, the system 1 may include one or more mobile devices 12 and not all mobile devices 12 need be identical. Therefore, there may be a plurality of mobile devices 12 wherein the various devices 12 are different forms of computing device and/or are owned/operated by different entities. Accordingly, the or each mobile device 12 is described with reference to various embodiments of a mobile device 12 and the system 1 may include a myriad of different such embodiments.

The mobile device 12 may include a processor 121 which is configured to execute one or more instructions. The mobile device 12 may further include a computer readable medium 122 which is communicatively coupled to the processor 121 and is configured to store one or more instructions for execution by the processor 121. The computer readable medium 122 may be configured to store data for access by the processor 121 in accordance with one or more instructions executed by the processor 121.

The mobile device 12 may include a communication unit 123 which is configured to communicate with one or more devices external to the mobile device 12. The communication unit 123 may communicate, for example, with one or more networks such as a cellular network, the internet (or other wide area network), a local area network, and the like. The communication unit 123 may be provided as a plurality of modules which each provide connectivity to a different network, for example. The communication unit 123 may be configured, for example, to communicate with a local area network over a wireless communication channel - such as a Wi-Fi network - which, in turn, is connected to a wide area network - such as the internet. Similarly, the communication unit 123 may be configured to communicate with a cellular network over a wireless communication network which, in turn, is connected to a wide area network (such as the internet).

The communication unit 123 may include a local wireless communication sub-unit 123a which is configured to receive data (and may, in some embodiments, be configured to transmit data) wirelessly from (and to) a local device, such as the mobile device 12. The local wireless communication sub-unit 123a may, for example, be configured to receive a short range radio frequency communication signal - such as a Bluetooth or BTLE signal as may be output by a beacon device 1 1 , as described herein.

The mobile device 12 may include an input/output system 124 which is configured to output information to a user and to receive one or more inputs from the user. For example, the input/output system 124 may include a physical keyboard, a virtual keyboard (implemented via a touchscreen), a touchscreen, a display (which is not touch sensitive), a speaker, a microphone, and the like. The mobile device 12 may include a geographic location module 126 which is configured to determine a geographical location of the mobile device 12. The geographic location module 126 may be, for example, a satellite positioning system receiver (such as a Global Positioning System receiver or GLONASS receiver, or the like).

The mobile device 12 may include a power supply 125 - e.g. in the form of a battery - to provide electrical power to one or more other components of the mobile device 12.

In some embodiments, the mobile device 12 runs an Android(RTM) operating system, or a Microsoft(RTM) operating system (such as WINDOWS(RTM)), or an Apple (RTM) operating system (such as iOS(RTM)).

The mobile device 12 may, therefore, be a "handset". 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 12, may include a microprocessor (which may be an example of the processor 121 ), a memory (which may be an example of the computer readable medium 122) 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) (which may be an example of the input/output system 124) through which the user may view and interact with user interface elements, a Bluetooth transceiver, a microphone, a cellular and/or wifi transceiver (which may be examples of the input/output system 124 and/or communication unit 123 and/or local communication sub-unit 123a), 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. The mobile device 12 may have stored thereon (e.g. in the computer readable medium 122) or accessible thereto (e.g. via the communication unit 123), an application (i.e. a computer program). As will be appreciated, the application may include computer executable instructions which, when executed by the processor 121 of the mobile device 12 or by a remote device 13 (as described herein) cause the operations, steps, and/or processes described herein to be performed. In other words, mobile device 12 may have contained within it a mobile application. This mobile application may encompass the digital capabilities of the functionality described herewithin. The application may, therefore, cause the presentation of a user interface to the user via the input/. output system 124 (e.g. on a display (which may be touch sensitive or not)). This user interface may enable the user to enter information into one or more fields (e.g. using a keyboard or virtual keyboard or microphone or camera of the input/output system 124). The application may associate that information with location information - as described herein - and may compile a message from that information and the location information. The mobile device 12 may be configured to cause the transmission of the entered information and the location information (i.e. the message) to the remote device 13 - see figure 4, for example. In some embodiments, the application will start on selection by a user (e.g. using the input/output system 124) - i.e. a user may firstly start the app. In some embodiments, as described herein, the application may start automatically on detection of a trigger event. Once the mobile application or "app" is operating on the mobile device 12, the user can use the mobile application to compile information to be sent as a message (data packet) to the remote device 13 (which may be a central server).

The information can take the form of alphanumeric text using an alphanumeric input function found on the mobile device 12 (e.g. using the keyboard or virtual keyboard or through voice recognition using the microphone, for example). Additional media can then be added to the message with the use of additional sensors (of the mobile device 12) and functions found within the mobile device 12. The additional sensors and functions of the mobile device 12 may include the input/output system 124. Therefore, the additional media may include one or more photographs taken using the camera of the input/output system 124, one or more videos taken using the camera (and microphone if sound is included in the video) of the input/output system 124, one or more audio recordings taken using the microphone of the input/output system 124, or the like.

The message may be compiled, therefore, by the mobile device 12 under the instruction of the application.

The compiled message may be made up of essentially any one or more of the following combination: alphanumeric text and/or media file. Singly or in combination this data comprises the information which may be sent to the remote device 13. Once compiled the message may be sent automatically by the application to the remote device 13 or the application may prompt the user to trigger the sending of the message to the remote device 13.

Therefore, in some embodiments, the user may then decide to send the message from their mobile device 13 to the central server (an example of the remote device 13) associated with the app.

The mobile device 12 may be configured to determine the location information and may send the location information (or information derived from the location information) to the remote device 13 with the message. The determining of location information may be performed when the message is to be sent to the remote device 13 or may be performed based on some other trigger (such as on detection of the trigger event (which may be the receipt of a beacon identifier, for example) or periodically). Determining the location information may include the mobile device 12 receiving one or more beacon identifiers from the one or more beacons 11 . In some embodiments, the mobile device 12 receives a single beacon identifier and in some embodiments the mobile device receives a plurality of beacon identifiers (which each of the plurality is from a different beacon 1 1 of the one or more beacons 1 1 ). The receipt of a beacon identifier by the mobile device 12 may include using the communication unit 122 to receive the wireless transmission of the beacon identifier from the beacon 1 1 . This may include, for example, use of the local communication sub-unit 123a of the mobile device 12 and may be the trigger event.

The mobile device 12, e.g. under instruction by the application, may be configured to include this location information in the message which is sent to the remote device 13. The mobile device 12, e.g. under instruction by the application, may be configured to append this location information to the message which is sent to the remote device 13 or to associate the location information with the message in some other manner (e.g. by sending the location information to the remote device 13 using a message identifier for the associated message). In some embodiments, the mobile device 12 has stored thereon (e.g. in the computer readable medium 122) a lookup table which associates beacon identifiers with other identity information for the beacon device 1 1 . For example, a beacon identifier may be associated, in the lookup table, with a particular carriage or part of a carriage of a train (or other transportation unit 100). In such embodiments, the location information which is sent by the mobile device 12 to the remote device 13 may include (instead of or as well as the beacon identifier) this other identity information. In embodiments, in which the beacon identifier is sent to the remote device 13 then the remote device 13 may include a similar lookup table to associate the identifier with the other identity information (see figure 5, for example). The other identity information may include an identity of a transportation unit 100, for example (such as a code for a carriage of a train).

In some embodiments, the location information which is determined by the mobile device 12 may include other location information (such as coordinates determined by the use of the geographic location module 126).

In some embodiments, the location information may include other location information which is gathered by determining one or more travel plans associated with the user. This may be achieved, for example, by the application communicating with one or more other applications - such as travel booking or ticket purchasing applications, or an email application - to identify one or more likely journeys which the user of the mobile device 13 plans to undertake. The beacon identifier may otherwise be referred to as a transponder ID, in some embodiments. The message (without the location information) may be referred to as the user message.

Accordingly, in some embodiments, when an action to send the information (e.g. the message) to the central server (as an example of the remote device 13) is effected by the user, then the app may automatically undertake one or more of the following actions: the app may direct the mobile device 12 to acquire the transponder IDs; the transponder IDs may be stored within the app through utilising volatile memory of the mobile device 12 (which may be the computer readable medium 122); all the collected transponder IDs may be sent with the user message to the central server (as an example of the remote device 13); in addition to the user compiled information sent within the message to the central server (e.g. the remote device 13), and the

automatically acquired transponder IDs, further information may also be sent from the mobile device 12 automatically such as times and dates and geo-location co-ordinates.

Therefore, in some embodiments, three sets of information may be contained within each message sent to the central server (or other remote device 13). The distinction for three sets of information may be based on how the information is acquired or

determined.

1. information that comes from the user e.g. alphanumeric text and media;

2. specific Information that is automatically acquired through the mobile device 12 and/or the beacon 1 1 , such as the transponder IDs; and

3. information that is automatically obtained from the mobile device 12, i.e. the current date, the current time, the current geo-location co-ordinates.

The remote device 13 (which may be a central server, for example), may be configured to receive the data which is sent to it by the mobile device 12. The remote device 13 may be configured to receive such data from a plurality of mobile devices 12. The remote device 13 may be configured to collate and log condition and status information for assets. The remote device 13 may be configured to deliver collated and/or logged information to a scheduling service which is configured to generate, automatically, instructions from one or more operatives to attend to one or more issues identified. This scheduling service may include the automatic identification of operatives with availability and the in a suitable geographic location. For example, the scheduling service may identify an operative which has the requisite skills and/or equipment to attend to an issue with an asset. The scheduling service may then send a message to a mobile device (which may be similar to the mobile devices 12 described herein) to direct the operative to the asset. This may include the scheduling service determining the current location of the asset (which may have moved since the issue was reported) and identifying a future location of the asset at which the operative may access the asset. So, for example, an operative may be directed to board a train carriage (or other transport unit 100) at a particular location to attend to an issue. That operative may be one of many such operatives located along the intended travel route of the transport unit 100. The remote device 13 may track the locations of the operatives and the assets. The operatives may be able, using their mobile devices, to indicate whether the issue has been rectified. In some embodiments, the trigger event is the detection of a beacon device 1 1 by the mobile device 12. This trigger event may cause the application to start to perform one or more functions or operations as described herein.

In some embodiments, these one or more functions or operations includes the delivery (e.g. the pushing) of travel information to the mobile device 12 based on the beacon identifier or identifiers detected by the mobile device 12. This may be, for example, travel information associated with the transport unit 100 with which the beacon device or devices 1 1 are associated. Travel information may include, for example, information regarding delays, arrival times, departure times, local amenities, transport unit 100 facilities (such as toilets and shops), and the like.

In some embodiments, these one or more functions or operations includes the delivery (e.g. the pushing) of advertisements. The advertisements may be based on the beacon identifier or identifiers such that the advertisements are targeted for that transportation unit, for example.

In some embodiments the data which is sent by the mobile device 12 to the remote device 12 includes a user identifier (e.g. a user login or identification code) and/or a mobile device identifier. This may enable the remote device 13 to associate the data with a particular user and/or mobile device 12. This may be used in the recording of reported issues but may also be used in relation to the delivery of targeted advertising to the user.

The remote device 13 may form part of the system 1 of some embodiments (as may mobile devices which are used be operatives, as described herein).

In some embodiments, there is a desire to provide additional security in relation to the beacon identifiers. Therefore, the beacon identifiers may be encrypted. In some embodiments, the beacon identifiers are cycled such that a particular beacon device 1 1 may be configured to transmit a plurality of different beacon identifiers in turn. In some embodiments, the beacon identifier may be provided as part of the transmission which is intended to be used for an identifier - e.g. using a standardised protocol for use with beacon devices 1 1 (such as Apple's (RTM) iBeacon devices). In some embodiments, the beacon identifier is hidden within other data (i.e. non-identification data) of a standardised protocol. In some such embodiments, the beacon identifier may be cycled or otherwise changed between consecutive broadcasts. In some embodiments, the part of the data which is intended to be a beacon identified may be random data or may be the same identifier for all beacon devices 1 1 in the system. In some embodiments, the beacon identifier is interleaved with other identifiers or data.

In some embodiments, a beacon device 1 1 (e.g. the transmitter 11 1 , thereof) may be configured to transmit a 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 (such as the one or more mobile devices 12) using passive scanning of Bluetooth channels. Figure 6 is a flow chart illustrating an embodiment of a process for broadcasting and utilising the beacon identifier.

The process of figure 6 may specifically employ a technique of the BTLE module beacon, that is to broadcast the service identifier (which may be a beacon identifier) which is a constant (e.g. , 128 bit) universally unique identifier (UUID) to allow passive scanning under a handset operating system (i.e. an operating system of the mobile device 12), such as iOS(RTM) or Android(RTM). In such cases, the service identifier (which may be a secure identifier) may be broadcasted as service parameters for the constant service. Thus, the process may include a step of broadcasting the constant service UUID parameters via Bluetooth beacons. The beacon identifier may include a rail train vehicle identifier of this rail train vehicle identifier may be determined by the mobile device 12 or remote device 13 (e.g. using lookup tables as described herein)/.

As used herein, the rail train vehicle identifier may include a carriage identifier, either as a separate component of the rail train vehicle identifier, or as a single identifier that is associated, for example, in a database, with separate rail vehicle and carriage identifiers. In an example, a single UUID may be assigned to each rail train vehicle.

The process of Figure 7, for example, may be employed by a mobile handset (i.e. a mobile device 12). The process may include a step in which a UUID is broadcast. The process may include a step in which the secure identifier (e.g. the UUID or other beacon identifier) is received by the handheld device (e.g. the mobile handset or other mobile device 12). For example, the identifier may be sent to an associated (e.g. Transreport) server (which is an example of the remote device 13) for comparison in another step of the process. In some embodiments, such processing (of the identifier) may be performed on the handset (i.e. on the handset device). If the server (or other remote device 13) is unavailable for any reason, the identifier (e.g. the UUID identifier) may be cached (e.g. by the mobile device 12) and relayed to the server (or other remote device 13) when it (i.e. the remote device 13) becomes reachable (by the mobile device 12). In order to support such offline situations, an instance of the identifier (e.g. the UUID identifier) may be valid for a predetermined period of time (e.g. one hour).

In some embodiments, if an identifier (i.e. a beacon identifier) is no longer valid then it is not sent to the remote device 13.

Figure 5 depicts a process which may be employed server side (i.e. on the remote device 13), e.g., at a server associated with a mobile application that detects the beacon identifier (e.g. the UUID identifier) at a handset (i.e. mobile device 12). The process may include a step in which a beacon identifier (e.g. a UUID) is received from a mobile application. The process may include a step in which the received beacon identifier (e.g. UUID identifier) is compared against a stored list of beacon identifiers (e.g. UUID identifiers) on the server (or other remote device 13). Each beacon identifier (e.g. UUID identifier) in the stored list may be mapped to an individual rail train vehicle (or other transportation unit), a match indicating the presence of the handheld device (e.g. mobile device 12) on a known rail train vehicle (i.e. on that transportation unit).

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

"1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 " (this number is for illustrative purposes only); hence if the UUID received by the server is "1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 " 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 "1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 " is transmitted to the server is located on rail carriage vehicle "123456".

In some embodiments, Bluetooth (or other wireless) enabled transmitters may be used for fine-grained vehicle interior (i.e. transportation unit) mapping. That is, the signal propagation properties of Bluetooth (or other wireless signal) may be leveraged to perform fine-grained location mapping including, for example, accurate identification of a user when walking into a vehicle (i.e. transportation unit) and tracking of the user as the user sits or stands within different sections in the vehicle (i.e. transportation unit). Such functionality may be achieved, for example, by placing one or more Bluetooth (or other wireless) enabled transmitters (i.e. beacon devices 1 1 ) in every vehicle of a train fleet (i.e. in every transportation unit of the fleet) and recording the signal strength of one or both of an audio and Bluetooth (or other wireless) signals from the beacon devices 1 1 (e.g. from all nearby transmitters (i.e. beacon devices 1 1 ) on a mobile handset (i.e. on a mobile device 12). In some such cases, clustering techniques (e.g. , triangulation, sorting, etc.) may be employed to narrow the exact location of the mobile handset (i.e. mobile device 12). Multiple signals from different transmitters (i.e. beacon devices 1 1 ) can also be used as an authentication mechanism to safeguard against one-off transmitter (i.e. beacon device 1 1 ) thefts.

Accordingly, location information may include information which is derived from a signal strength associated with the signal received by a mobile device 12 from one or more beacon devices 1 1 . In some embodiments, the location information may include information which is derived from the strength of signals associated with a plurality of signals received by a mobile device 12 from a corresponding plurality of beacon devices 1 1 . In some embodiments, a signal strength map may be used to determine this location information - which may be stored in the mobile device 12 (e.g. in the computer readable medium 122) or which may be stored in the remote device 13. In

embodiments in which a signal strength map is stored in the remote device 13, then the location information or other data sent by the mobile device 12 to the remote device 13 may include signal strength information associated with the or each beacon identifier which was received.

Many applications exist for the BTLE described herein. As described, the addition of a BTLE module to the transmitter (i.e. to the beacon device 1 1 ) allows several tasks to be performed efficiently. For example, update of the rail train and/or rail train vehicle identifier(s) (i.e. beacon identifier) of a transmitter (i.e. of a beacon device 1 1 ) may be remotely accomplished. Moreover, a transmitter (i.e. a beacon device 1 1 ) may be detected while an associated application (on the mobile device 12) is in the background using passive scanning of Bluetooth (or other wireless) services as supported in, for example, iOS and Android.

Such passive Bluetooth (or other wireless signal) detection may trigger multiple actions (on the mobile device 12) depending on the situation (and may be the trigger event) 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.

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) - i.e. transportation unit 100 identifiers or beacon identifiers.

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.

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 (e.g. by competitors or fraudsters), iBeacon advertisement packets may be interleaved with custom proprietary broadcasts. iBeacon signals just contain a 128 bit UUID, with nonsense major and minor identifiers. This may be purposefully done in some embodiments to prevent competitors (or fraudsters) from using proprietary infrastructure for presence detection. As described in detail above, train and/or vehicle information (e.g. identifiers such as a beacon identifier) 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 may be tuned to minimise the latency of waking up but at the same time minimising the time taken to decode the correct train and/or vehicle information (i.e. identifier) from proprietary broadcasts), though other ratios are also workable. 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 in all embodiments. Another 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.

In some embodiments, the iBeacon identifier may be 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 may be updated from a client (such as a mobile device 12). 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.

As will be understood, some embodiments have been described with reference to iBeacons. Some embodiments which do not use iBeacons may implement similar processes and procedures. Therefore, the above description is to be viewed as encompassing the use of other beacon protocols using beacon identifiers which are not necessarily iBeacon identifiers and other parts of the data which those other protocols include. The use of the terms major and minor identifiers may, therefore, be applied equally to the equivalent identifiers in one or more other beacon protocols other than iBeacon protocols. In some embodiments, therefore, a beacon identifier includes a main portion (which may be referred to above as a UUID (or iBeacon identifier), for example), a first sub-portion (which may be referred to above as a major identifier in relation to an iBeacon), and a second sub-portion (which may be referred to as a minor identifier in relation to an iBeacon). The first and second sub-portions may be parts, therefore, of the beacon identifier, along with the main portion. The description above in relation to the use of these parts of an identifier for an iBeacon may be implemented in relation to other embodiments more generally, including embodiments which do not use iBeacons. In some embodiments, the first sub-portion of the beacon identifier may be intended to be a high level location identifier, and the second sub-portion of the beacon identifier may be intended to be a more specific location identifier.

In some embodiments, the iBeacon broadcast (or other beacon device 1 1 broadcast) may be completely disabled for any specific periods of time. That is, iBeacon support (or equivalent) 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.

As will be understood, some embodiments of the present invention relate to the juncture of mobile and the physical world, and specifically, to the use of mobile communication devices to facilitate improved user experiences in transportation environments. Some embodiments, include, for example presence detection and asset identification using Bluetooth and hybrid-mode transmitters in dynamic assets such as rail trains and rail train vehicles (carriages). As will be appreciated, 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. As will be understood, the mobile device 12 (e.g. the handset) may detect the presence of a beacon device 1 1 (e.g. a transmitter) within the structure of the dynamic asset such as a rail vehicle (or other transportation unit) and reacts accordingly, e.g., by communicating with server (or other remote device 13) via a wireless network. The beacon device 1 1 (e.g. the transmitter) 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 user to 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. Some embodiments may provide presence detection and asset identification using Bluetooth and hybrid-mode transmitters in dynamic assets such as rail trains and individual rail train vehicles (also known as carriages). In some embodiments, one or more

transmitters may be configured to transmit an iBeacon broadcast and a proprietary Bluetooth Low Energy (BTLE) broadcast, wherein at least one of the transmitted broadcasts may include an identifier that specifies a rail train vehicle. The broadcasts may be captured by a handset and decoded to infer presence of the handset within the rail train vehicle (also known as a carriage). Some embodiments provide a system for enabling a user of an asset to automatically identify the asset to provide contextually correct information upon further action relating to the asset.

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. A detailed description of one or more embodiments of the invention is provided herein. 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 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. 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.

Aspects

1. A computer-implemented method, comprising: receiving, by a computing system from a mobile device, data that at least specifies a particular carriage within a transit vehicle based upon the acquiring of unique transponder ID when the mobile device is located within or near the transit vehicle; 2. The method of aspect 1 , further comprising:

acquiring, by the mobile device, through the use of its sensor capability, transponder IDs, when the mobile device is located within or near the transit vehicle; 3. The method of aspect 1 or 2, further comprising: conveying, through a software application, commonly known as an app, on the mobile device, user perceptions and opinions of the transit vehicle, examples include (but not limited to) any damage observed by the user of the app, any defective components identified by the user of the app, the level of cleanliness of the transit vehicle identified by the user of the app; 4. The method of any preceding aspect, further comprising capturing, through the use of the embedded sensors and input devices commonly found on a mobile device, the user perceptions and opinions of the transit vehicle; examples of sensors and input. 5. A method, comprising: creating an identifier that specifies a rail train vehicle; and configuring one or more transmitters to transmit an i Beacon 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. 6. The method of aspect 5, wherein the identifier comprises a train identifier that specifies a train. 7. The method of aspect 5 or 6, wherein the identifier comprises a vehicle identifier that specifies a vehicle in a train. 8. The method of any of aspects 5 to 7, wherein the iBeacon broadcast is employed to wake up a handset application configured to detect an associated service identifier. 9. The method of any of aspects 5 to 7, further comprising interleaving the iBeacon broadcast and the proprietary BTLE broadcast. 10. The method of any of aspects claim 5 to 9, further comprising rotating one or both of major and minor iBeacon identifiers to prompt frequent application wake ups. 1 1. The method of any of aspects 5 to 10, further comprising changing the iBeacon identifier to prevent third party wake ups. 12. The method of any of aspects 5 to 1 1 , wherein the iBeacon identifier is updated via the handset. 13. The method of any of aspects 5 to 12, wherein the identifier comprises a secure identifier. 14. The method of any of aspects 5 to 13, further comprising updating at least one of the transmitters based on a directive received via the handset. 15. The method of any of aspects 5 to 14, wherein the broadcasts captured at the handset are processed with respect to an application of the handset. 16. The method of any of aspects 5 to 15, further comprising disabling the iBeacon broadcast for a prescribed period of time. 17. 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. 18. 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. When used in this specification and claims, the terms "comprises" and "comprising" and variations thereof mean that the specified features, steps or integers are included. The terms are not to be interpreted to exclude the presence of other features, steps or components. The features disclosed in the foregoing description, or the following claims, or the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for attaining the disclosed result, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.