Patent Description:
Many transit stations, such as train platforms or bus terminals, routinely employ automatic fare validation (or ticket validation) systems to improve user experience and increase the throughput of passengers through, for example, fare gates to and from the train platforms. Modern technical advances, such as smartcards, two-dimensional (2D) barcodes, and Near Field Communication (NFC) capable mobile devices, have reduced passenger ingress and egress time through fare gates. Smartcards can be either contact or contactless, and can provide personal identification, authentication, data storage, and application processing. NFC-enabled portable devices can be provided with apps, for example, to read electronic tags or make a transaction when connected to an NFC- compliant apparatus.

<CIT> discloses a system and method for automated protocols between a mobile device and an electronic ticketing verification system, where proximity detection is used to automatically display the verification or to automatically control entry gates or turnstiles when the mobile device is verified as holding a valid ticket and being located in a specific location associated with the ticket.

<CIT> relates to an access control device having at least one access barrier element, to which at least one read unit and/or sensor unit for acquiring legitimation and/or security features is assigned, the access barrier elements and the read and sensor units each having a data connection to a computer unit, which compares the acquired or read features to stored data and opens or keeps closed the access barrier according to a preset. An additional operating element, which is assigned to the computer unit, is proposed, by which it is possible to select between various security steps by simply adjusting the operating element.

<CIT> discloses that a secure short-distance-based communication and access control system controls access to a restricted area, whereby zone computers validate users via their mobile devices to allow or deny access to the restricted area.

Although the above-mentioned technical advances have reduced passenger ingress and egress times through fare gates, passenger throughput is still hampered by passengers having to search for their smartcards or getting out their mobile phones (for example, to establish an NFC contact).

It is therefore desirable to improve the process of automated fare validation and to also improve the passenger throughput through a fare gate at a transit station. It is further desirable to perform ticket validation "hands free.

As a solution, particular embodiments of the present disclosure provide for a hands-free process of automated fare validation. In particular embodiments, the Bluetooth technology may be used in conjunction with a user application on a mobile device to facilitate such hands-free fare validation. In one embodiment, the solution may comprise a mobile app for the passenger and an add-on box that interfaces to a compliant fare gate. Bluetooth beacons may be used to determine a passenger's proximity to the gate and camera-like devices may interface to the add-on box to determine whether a passenger (perhaps without a smartphone) has entered the fare gate. According to particular embodiments of the present disclosure, a user with a valid ticket may simply walk through the fare gate "hands free" without the need to search for a physical ticket or a smartcard or a mobile phone. This hassle-free approach may significantly improve the user experience and passenger throughput through fare gates.

The Bluetooth LE-based automated fare validation system as per teachings of particular embodiments of the present disclosure may detect and provide feedback to the passenger, when the passenger enters into a "Paid Area" with a valid electronic ticket (which may be stored in the passenger's mobile device). A controller as per teachings of the present disclosure may also detect when a passenger, with a mobile ticket previously activated, exits from the Paid Area. Furthermore, in some embodiments, the system may detect, and provide external visual and audio alerts, when a passenger enters into the Paid Area without a valid permit for travel. The system may also detect, and provide external visual and audio alerts, when a passenger attempts to exit from the Paid Area without a valid permit for travel. Overall, passenger throughput into and out of the Paid Area may be increased, especially during peak periods, using the hands-free ticket validation approach disclosed herein.

The appended independent claims define the scope of protection of present invention. In one embodiment, the present disclosure is directed to a method in a mobile device as defined by independent claim <NUM> to facilitate hands-free fare validation when a user carrying the mobile device approaches a fare validation zone at a transit station. The method comprises: (i) receiving a Bluetooth beacon signal; (ii) based on the received beacon signal, determining that the mobile device is in the fare validation zone; (iii) transmitting electronic ticket information stored in the mobile device to a controller unit at the transit station, wherein the electronic ticket information is transmitted over a Bluetooth interface between the mobile device and the controller unit; (iv) receiving a ticket acceptance response from the controller unit over the Bluetooth interface indicating that the electronic ticket is valid for transit; and (v) informing the user to continue towards an entry gate at the transit station in a hands-free manner. In one embodiment, the Bluetooth interface may be a Bluetooth LE interface.

The mobile device may also determine that it is in proximity to an authorized transmitter of the beacon signal, thereby detecting that the user is present in the fare validation zone.

In one embodiment, the mobile device may receive a beacon Identifier (ID) transmitted using a Bluetooth interface between the mobile device and a transmitter of the beacon ID; identify the received beacon ID; and activate the hands-free fare validation feature in the mobile device based on the identified beacon ID.

In certain embodiments, the mobile device may provide a visible and/or an audible notification of the ticket acceptance. On the other hand, the mobile device may also generate an alert for the user when an electronic ticket stored in the mobile device is invalid or when no electronic ticket is stored in the mobile device.

In another embodiment, the present disclosure is directed to a method as defined by independent claim <NUM> to facilitate hands-free fare validation when a user carrying a mobile device approaches a fare validation zone at a transit station. The method comprises performing the following using a controller unit at the transit station: (i) receiving a notification that the user has entered the fare validation zone; (ii) identifying the mobile device carried by the user based on signals received from the mobile device over a Bluetooth interface; (iii) receiving electronic ticket information from the mobile device over the Bluetooth interface; (iv) determining that the electronic ticket is valid for transit; and (v) sending a ticket acceptance response to the mobile device over the Bluetooth interface, thereby informing the user of the mobile device to continue towards an entry gate at the transit station in a hands-free manner. In one embodiment, the Bluetooth interface may be a Bluetooth LE (BLE) interface.

In one embodiment, the controller unit may receive the notification from a digital camera connected to the controller unit.

The controller unit may determine the validity of the electronic ticket by: (i) sending the electronic ticket information received from the mobile device to an entry control gate at the transit station; and (ii) receiving a confirmation message from the entry control gate indicating that the electronic ticket sent by the controller unit is a valid ticket.

In particular embodiments, the controller unit may store various types of information in a memory. Such information may include, for example, operational statistics, a first count of users with valid electronic tickets, a second count of users with invalid electronic tickets, a third count of total number of users entering the transit station, a fourth count of total number of users exiting the transit station, and information about Bluetooth beacon signals transmitted to detect presence of mobile devices in the fare validation zone.

In one embodiment, the controller unit may determine that an electronic ticket received from the mobile device is invalid, and may send a ticket rejection response to the mobile device over the Bluetooth interface, thereby instructing the mobile device to generate an alert for the user.

In a further embodiment, the present disclosure is directed to a mobile device as defined by independent claim <NUM>. The mobile device comprises: (i) a transceiver operable to receive a Bluetooth beacon signal; (ii) a memory for storing program instructions and electronic ticket information; and (iii) a processor coupled to the transceiver and to the memory. In the mobile device, the processor is operable to execute the program instructions, which, when executed by the processor, cause the mobile device to perform the following to facilitate hands-free fare validation when a user carrying the mobile device approaches a fare validation zone at a transit station: (a) based on the received beacon signal, determine that the mobile device is in the fare validation zone; (b) transmit electronic ticket information stored in the memory to a controller unit at the transit station using the transceiver, wherein the electronic ticket information is transmitted by the transceiver over a Bluetooth interface between the mobile device and the controller unit; (c) receive a ticket acceptance response from the controller unit using the transceiver over the Bluetooth interface, wherein the ticket acceptance response indicates that the electronic ticket is valid for transit; and (d) inform the user to continue towards an entry gate at the transit station in a hands-free manner. In one embodiment, the Bluetooth interface may be a BLE interface.

In yet another embodiment, the present disclosure is directed to a controller unit that comprises: (i) an interface unit; (ii) a memory; and (iii) a processor coupled to the interface unit and to the memory. In the controller unit, the interface unit is operable to perform the following: (a) receive a notification that a user has entered a fare validation zone at a transit station, and (b) receive electronic ticket information from a mobile device carried by the user over a Bluetooth interface. In the controller unit, the memory is operable to store program instructions and the electronic ticket information. In the controller unit, the processor is operable to execute the program instructions, which, when executed by the processor, cause the controller unit to perform the following to facilitate hands-free fare validation when the user carrying the mobile device approaches the fare validation zone: (a) identify the mobile device carried by the user based on signals received from the mobile device over the Bluetooth interface, (b) determine that the electronic ticket is valid for transit, and (c) send a ticket acceptance response to the mobile device over the Bluetooth interface using the interface unit, thereby informing the user of the mobile device to continue towards an entry gate at the transit station in a hands-free manner. In one embodiment, the Bluetooth interface may be a BLE interface.

The mobile device and the controller unit may perform various operational aspects briefly mentioned above and further discussed in more detail later below.

Thus, the Bluetooth-based fare validation methodology as per teachings of the present disclosure may improve the passenger throughput through a fare gate by allowing the passenger to simply walk through the fare gate "hands free" so long as they have a valid, active ticket on their mobile device.

In the following section, the present disclosure will be described with reference to exemplary embodiments illustrated in the figures, in which:.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the present disclosure.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "according to one embodiment" (or other phrases having similar import) in various places throughout this specification are not necessarily all referring to the same embodiment. Also, depending on the context of discussion herein, a singular term may include its plural forms and a plural term may include its singular form. Similarly, a hyphenated term (e.g., "hands-free," "hassle-free", etc.) may be occasionally interchangeably used with its non-hyphenated version (e.g., "hands free," "hassle free", etc.), and a capitalized entry (e.g., "Fare Validation Application," "Fare Gate," "Controller Unit," etc.) may be interchangeably used with its non-capitalized version (e.g., "fare validation application," "fare gate," "controller unit," etc.). Such occasional interchangeable uses shall not be considered inconsistent with each other.

It is noted at the outset that the terms "coupled," "operatively coupled," "connected", "connecting," "electrically connected," etc., are used interchangeably herein to generally refer to the condition of being electrically/electronically connected in an operative manner. Similarly, a first entity is considered to be in "communication" with a second entity (or entities) when the first entity electrically sends and/or receives (whether through wireline or wireless means) information signals (whether containing address, data, or control information) to/from the second entity regardless of the type (analog or digital) of those signals. It is further noted that various figures (including component diagrams) shown and discussed herein are for illustrative purpose only, and are not drawn to scale.

The terms "first," "second," etc., as used herein, are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly defined as such.

<FIG> illustrates constituent components of a Fare Validation (FV) application <NUM> according to an exemplary embodiment of the present disclosure. The FV application <NUM> may be a software module having various distributed data processing functionalities discussed later below with reference to <FIG>. Some portion of data processing or computations may be performed locally in a mobile device whereas some other portion of data processing may be performed on a controller unit. The FV application <NUM> according to one embodiment of the present disclosure may include an FV User Application (user app) component <NUM> and an FV Controller Driver component (controller driver) <NUM>. The user app and controller driver components may be in bi-directional communication (preferably wireless, as discussed below with reference to <FIG>) with each other, and may together provide the hands-free fare validation functionality as discussed later below. It is noted here that, for ease of discussion, a computer software, program code or module may be referred to as "performing," "accomplishing," or "carrying out" a function or process. However, it is evident to one skilled in the art that such performance may be technically accomplished by a processor when the software or program code is executed by the processor. The program execution would cause the processor to perform the tasks or steps instructed by the software to accomplish the desired functionality or result. However, for the sake of convenience, in the discussion below, a processor or software component may be referred to interchangeably as an "actor" performing the task or action described, without technically dissecting the underlying software execution mechanism.

<FIG> depicts an exemplary system <NUM> for implementing the FV application <NUM> according to one embodiment of the present disclosure. The system <NUM> may include a mobile device <NUM> that is in wireless communication with a controller unit <NUM>, as symbolically illustrated by a wireless link <NUM>. As discussed later below, the wireless link <NUM> may be a Bluetooth-based communication interface. The FV user app <NUM> may reside in the mobile device <NUM>, whereas the FV controller driver <NUM> may reside at the controller unit <NUM> as shown in <FIG>. It is noted here that the terms "mobile device," "mobile handset," "wireless handset," and "User Equipment (UE)" may be used interchangeably hereinbelow to refer to a wireless communication device that is capable of voice and/or data communication. Some examples of such mobile handsets include cellular telephones or data transfer equipments, tablets, and smartphones (e.g., iPhone™, Android™, Blackberry™, etc.). It is observed here that, for ease of discussion, the controller unit <NUM> is shown as a separate device or apparatus. However, the controller unit <NUM> may not have to be a separate computing unit (in hardware or software form) dedicated to carry out the fare validation functionality. In one embodiment, the functionality of the controller unit <NUM> may be implemented in an already-existing physical computing/data processing unit or (non-physical) server software (not shown) at a transit station.

As shown in <FIG>, the UE <NUM> may include, inside its housing (not shown), a relatively low-powered Central Processing Unit (CPU) <NUM> executing a mobile operating system (or mobile OS) <NUM> (e.g., Symbian™ OS, Palm™ OS, Windows Mobile™, Android™, Apple iOS™, etc.). Because of the battery-powered nature of mobile handsets, the CPU <NUM> may be designed to conserve battery power and, hence, may not be as powerful as a full-functional computer or server CPU. As further shown in <FIG>, in addition to the user app <NUM>, the UE <NUM> may also have one or more mobile applications <NUM> resident therein. These mobile applications <NUM> are software modules that may have been pre-packaged with the handset <NUM> or may have been downloaded by a user into the memory (not shown) of the UE <NUM>. Some mobile applications <NUM> may be more user-interactive applications (e.g., a mobile game of chess to be played on the UE <NUM>, a face recognition program to be executed by UE <NUM>, etc.), whereas some other mobile applications may be significantly less user-interactive in nature (e.g., UE presence or location tracking applications, a ticketing application). The mobile applications <NUM> as well as the user app <NUM> may be executed by the processor <NUM> under the control of the mobile operating system <NUM>. As also shown in <FIG>, the UE <NUM> may further include a wireless interface unit <NUM> to facilitate UE's wireless communication with the controller unit <NUM> (discussed later) via a Bluetooth interface such as, for example, a Bluetooth LE (or Bluetooth) interface <NUM>. In particular embodiments, the wireless interface unit <NUM> may also support other types of wireless connections such as, for example, a cellular network connection, a Wi-Fi connection, and the like. The applications <NUM>, <NUM> may utilize the wireless interface <NUM> as needed.

It is noted here that the Bluetooth LE interface <NUM> is shown by way of an example only; the teachings of the present disclosure are not limited to a BLE interface alone. Thus, although the discussion below may frequently refer to a BLE interface, it is understood that such discussion remains applicable to other Bluetooth technologies as well, such as, for example, the Bluetooth technologies that comply with one or more Bluetooth Special Interest Group (SIG) standards. The hands-free fare validation solution as per teachings of the present disclosure may be implemented using a number of Bluetooth specifications, including BLE. Hence, the usage of the terms "BLE" or "Bluetooth LE" in the discussion below should be considered as a representative of (and inclusive of) the more general term "Bluetooth" or other non-BLE based Bluetooth technologies. Additionally, in certain embodiments, the Bluetooth-based proximity detection discussed below may be modified such that proximity may be detected using Bluetooth in conjunction with WiFi and/or cellular data connections, or some combination thereof. Thus, for example, a hybrid approach to proximity detection may use both WiFi and Bluetooth to detect where a person is at. The Bluetooth-based discussion below encompasses such variations and combinations, but each such hybrid approach is not discussed in detail for the sake of brevity.

In the embodiment of <FIG>, the controller unit <NUM> is shown to include a relatively high powered CPU <NUM> executing an operating system <NUM> (e.g., Windows™, Mac™ OSX, Linux, etc.). In addition to the controller driver <NUM>, the controller unit <NUM> may also store in its memory (not shown) other controller-specific applications <NUM> such as, for example, an application that facilitates NFC or Ethernet-based communication with an entry gate system (discussed later with reference to <FIG>), an application that facilitates communication with a "people counting" device (also discussed later), an application that interacts with a backend system, and the like. The controller <NUM> may wirelessly communicate with the UE <NUM> via its own wireless interface unit <NUM>. The interface units <NUM>, <NUM> may wirelessly transfer data or information between the mobile device <NUM> and the controller <NUM> using the Bluetooth interface <NUM> as shown. Thus, in operation, a UE-generated signal may be wirelessly sent (using the wireless interface <NUM>) over the Bluetooth interface <NUM> to the controller unit <NUM> for further processing by its CPU <NUM>. Any response or other signal from the controller unit <NUM> can be provided in the UE-recognized wireless format by the controller's wireless interface unit <NUM> and eventually delivered to UE's wireless interface <NUM> (and, hence, to the UE's processor <NUM> for further processing) via the Bluetooth interface <NUM>. The resulting wireless "link" between the interfaces <NUM> and <NUM> is symbolically illustrated by the bi-directional arrow <NUM>. In particular embodiments, the wireless interface unit <NUM> may also support other types of wireless connections such as, for example, a cellular network connection, a Wi-Fi connection, and the like. The applications <NUM>, <NUM> may utilize the wireless interface <NUM> as needed. It is observed here that, in particular embodiments, the mobile device <NUM> and/or the controller unit <NUM> may be coupled to other networks (not shown) via a wired or wireless connection (whether circuit-switched or packet-switched). Such networks may be voice networks, data networks, or both, and may include, for example, a cellular network, the Internet, a Local Area Network (LAN), a Public Land Mobile Network (PLMN), and the like.

<FIG> shows an exemplary flowchart <NUM> illustrating a mobile device-based hands-free fare validation methodology according to one embodiment of the present disclosure. Various operational tasks shown in <FIG> may be performed by the mobile device <NUM> when the user app <NUM> (and other relevant program code) is executed by the CPU <NUM>. Initially, the mobile device <NUM> may receive a Bluetooth beacon signal (block <NUM>). As discussed later, specific Bluetooth beacon signals may be transmitted as per teachings of the present disclosure for locating the presence of a passenger in the fare validation zone (also referred to below as "fare gate trigger zone"). Thus, based on the received beacon signal, the mobile device <NUM> may determine that it is in the fare validation zone (block <NUM>). At block <NUM>, the mobile device <NUM> may transmit electronic ticket information stored in the mobile device (as discussed later below) to a controller unit, such as the controller unit <NUM>, at the transit station. The electronic ticket information may be transmitted over a Bluetooth interface, such as the Bluetooth LE interface <NUM> between the mobile device <NUM> and the controller unit <NUM>. At block <NUM>, the mobile device <NUM> may receive a ticket acceptance response from the controller unit <NUM> over the Bluetooth interface <NUM> indicating that the electronic ticket is valid for transit. In response, at block <NUM>, the mobile device <NUM> may inform the user/passenger-for example, via a visible and/or an audible notification-to continue towards an entry gate at the transit station in a hands-free manner. Thus, the ticket submission and ticket validation operations may be performed without user involvement; a passenger is not required to search for their smartcards or mobile phones to validate their tickets.

<FIG> shows an exemplary flowchart <NUM> illustrating a controller unit-based hands-free fare validation methodology according to one embodiment of the present disclosure. Various operational tasks shown in <FIG> may be performed by the controller unit <NUM> when the controller driver <NUM> (and other relevant program code) is executed by the CPU <NUM>. Initially, at block <NUM>, the controller unit <NUM> may receive a notification that the user has entered the fare validation zone. In one embodiment, such notification may be received from a "people counting" device such as, for example, a digital camera, connected to the controller unit <NUM> as discussed later with reference to <FIG>. At block <NUM>, the controller unit <NUM> may identify the mobile device carried by the user-such as the mobile device <NUM>-based on the signals received from the mobile device over a Bluetooth interface, such as the Bluetooth LE interface <NUM>. Upon identifying the mobile device <NUM> and establishing a Bluetooth communication link with it, the controller unit <NUM> may receive electronic ticket information from the mobile device <NUM> over the Bluetooth interface <NUM> (block <NUM>). At block <NUM>, the controller unit <NUM> may determine that the electronic ticket is valid for transit. As discussed later, in one embodiment, the controller unit <NUM> may send the electronic ticket information to an entry control gate at the transit station to check the validity of the ticket. If the submitted ticket is valid and active, the controller unit <NUM> may receive a confirmation message from the entry control gate. At block <NUM>, the controller unit <NUM> may sent a ticket acceptance response to the mobile device <NUM> over the Bluetooth interface <NUM>. This informs the user/passenger (carrying the mobile device <NUM>) to continue towards an entry gate at the transit station in a hands-free manner. In other words, a passenger is not required to search for his/her smartcard or mobile phone to validate his/her ticket; the passenger can simply continue walking towards the entry gate because of the hands-free validation of the ticket through the interactions between the controller unit <NUM> and the passenger's mobile device <NUM>.

<FIG> shows an exemplary illustration of system components to implement the hands-free fare validation methodology at a transit station <NUM> according to one embodiment of the present disclosure. Prior to discussing the operational aspects of the system components in <FIG>, a brief overview of exemplary hardware features of these components is provided.

In particular embodiments, the mobile device <NUM> may be an Apple® iPhone <NUM> or a newer model. In other embodiments, the mobile device <NUM> may be a Google® Nexus <NUM> or similar model. In any event, the user app <NUM> may be configured to run on a variety of mobile devices-Android-based, Apple iOS-based, or any other mobile operating system-based. In particular embodiments, the mobile device <NUM> may support downloadable applications and Bluetooth LE <NUM> or higher protocols (or other applicable Bluetooth protocols) for communications, including Bluetooth Beacon scanning. The mobile device <NUM> may include a User Interface (UI) to facilitate various tasks in support of the hands-free fare validation. Such tasks may include, for example, purchase of an electronic ticket by the user, selection of the desired ticket from a group of pre-purchased tickets, intimation of acceptance of the electronic ticket for transit, and the like.

In particular embodiments, the controller unit <NUM> may be a computer such as, for example, a laptop or a desktop computer, a mobile device, a tablet computer, a single-board computer, or a modular controller such as a Raspberry Pi™ or Arduino™ unit. The controller unit <NUM> may support some or all of the following capabilities: a Bluetooth (including BLE) based radio communication, wired or wireless connectivity, Universal Serial Bus (USB) connectivity, non-volatile storage such as flash or disk storage, volatile storage using Random Access Memory (RAM) modules, Bluetooth LE <NUM> or higher stack (or other applicable Bluetooth protocols), video or Liquid Crystal Display (LCD) display, NFC reader, and a data input device such as a keyboard. It is noted here that, in certain embodiments, there may be more than one controller unit <NUM> installed at the transit station <NUM>, such as, for example, when multiple fare gates (discussed below) are present and "managed" by different controller units or when multiple wake-up beacons (discussed below) are associated with different controller units. Generally, the number of controller units or beacon transmitters (wake-up beacons or gate beacons) may be implementation-specific.

The transit station <NUM> may optionally employ one or more Wake-Up beacon transmitters <NUM> for launching and preparing the user app <NUM> on the mobile device <NUM> for proximity tracking. The number of wake-up beacons <NUM> may be based upon field conditions. In particular embodiments, the wake-up beacon <NUM> may provide Bluetooth LE (BLE) (or other type of Bluetooth) beacon signals using an omnidirectional antenna (not shown). The beacon signals transmitted by the transmitter <NUM> may be compatible with proprietary Bluetooth beacon standards such as, for example, the iBeacon standard for Apple® systems and similar Bluetooth beacon standards for Android™ systems. Thus, for iBeacon compatibility, for example, the wake-up beacon transmitter <NUM> may be capable of advertising a programmable <NUM>-byte Universal Unique Identifier (UUID) along with a <NUM>-byte Major Number and a <NUM>-byte Minor Number. The UUID may be used to uniquely identify an object-for example, the beacon transmitter <NUM>-across the internet. The <NUM>-bit Major Number may further subdivide iBeacons that have the same UUID. The <NUM>-bit Minor Number may further subdivide iBeacons within the same Major Number.

As noted above, a UUID is a unique number. With regard to BLE, each service may be represented by a UUID. The <NUM>-bit standardized BLE UUIDs allow for <NUM> unique services. BLE also supports <NUM> bit UUID numbers for custom services. A "service" can be almost anything such as, for example, a heart monitor, a proximity sensor, a temperature probe, and so on. Additional information about UUIDs for various "services" may be obtained at https://developer. org/gatt/services/Pages/ServiceHome. Although UUIDs are normally fixed, they may be dynamic in certain implementations.

The wake-up transmitter <NUM> may be considered a "Bluetooth Beacon" because it periodically transmits a fixed message-a Beacon Identifier (ID)-using Bluetooth or Bluetooth LE. In particular embodiments, a Bluetooth Beacon is usually incapable of receiving data. The Beacon ID may provide transmitter-specific identification information that the mobile operating system <NUM> may use to recognize the Bluetooth Beacon. For iBeacons, for example, the Beacon ID is the UUID along with the major and minor numbers. It is observed here that the Bluetooth LE (also referred to as "Bluetooth Smart") is a wireless communication protocol that permits short range (up to <NUM> meters) communications. Bluetooth LE functionality is found on many smartphones and tablets.

The beacons may be used for determining proximity of a mobile device to a particular location. Each beacons normally has a fixed ID, but, in certain implementations, a beacon can have a dynamic ID. With regard to Beacon IDs, the mobile device may read all of the beacon IDs transmitted in its vicinity. In certain embodiments, the beacon data (such as Beacon ID), signal strength of the received beacon, and a timestamp value (associated with the received beacon) may be forwarded-such as, for example, by the user app <NUM>-over WiFi to another computer or host-such as, for example, the controller unit <NUM>-that determines the location of the mobile device <NUM>. Thus, in particular embodiments, the user app <NUM> in the mobile device <NUM> may "listen" to the beacons and then connect over WiFi to an application-such as, for example, the controller driver <NUM>-that determines location. In some other embodiments, the user app <NUM> may connect to a different application to determine the location or may itself determine the location and send the location information to the controller driver <NUM>. Major beacon formats are supported by iOS™, Adroid™, and other mobile operating systems.

The transit station <NUM> may also employ two or more BLE (or other type of Bluetooth) Gate Beacons for locating a passenger in the Fare Gate Trigger Zone (also referred to as the "fare validation zone"). An exemplary fare gate trigger zone <NUM> is shown in <FIG> (discussed below). In <FIG>, two Gate Beacons are shown using reference numerals "<NUM>" and "<NUM>". Based upon the field conditions or to improve accuracy, more gate beacons may be installed as well. Operationally, the gate beacons <NUM>-<NUM> are also Bluetooth Beacons and may be similar to the wake-up beacon <NUM>, except that each gate beacon <NUM>-<NUM> may have a highly unidirectional external antenna (not shown) to specifically "track" the passengers who are present in the fare validation zone.

In one embodiment, all Bluetooth® communications between various entities in <FIG> may conform to the standards set forth in the Bluetooth® Core Specification <NUM>.

The transit station <NUM> may have a number of "people counting" devices <NUM>-<NUM> to determine when a person has entered the fare validation zone. In one embodiment, the "people counting" devices may include stereoscopic digital Infrared (IR) cameras. In some embodiments, the cameras <NUM>-<NUM> may be wirelessly connected to the controller unit <NUM> to notify the controller <NUM> when a person has entered the fare validation zone. In other embodiments, there may be an Ethernet-based connectivity between the controller unit <NUM> and the "people counting" devices <NUM>-<NUM>. Furthermore, to prevent "tailgating," the devices <NUM>-<NUM> may be configured to distinguish between one person and more than one person in the fare gate trigger zone.

An entry gate system <NUM> (also referred to herein as a "Fare Gate") may be deployed at the transit station <NUM> to function as an electronically-controlled access barrier. One fare gate is shown in <FIG> by way of an example. Many transit stations may have multiple such fare gates. In one embodiment, a fare gate may be a physical access barrier that is intended to permit only properly-ticketed passengers through into the "Paid Area," which may be a secured area that is designated for paying passengers. In one embodiment, the fare gate <NUM> may be directly connected to the controller unit <NUM> via an Ethernet interface <NUM>. In some embodiments, a standard Power Over Ethernet (POE) switch (or hub) may be used to facilitate multiple Ethernet connections or field conditions. A standard RJ-<NUM> connector may be used to provide the Ethernet-based network connectivity between the controller unit <NUM> and the fare gate <NUM>. In certain embodiments, the fare gate may be a virtual barrier, such as, for example, in case of a bus where such a virtual barrier may be used in conjunction with a controller unit as per teachings of the present disclosure to afford hands-free entry to the passengers wishing to board the bus. In other words, the physical barrier-based illustration in <FIG> is exemplary only; the teachings of the present disclosure are not limited to a physical gate barrier being present.

On the other hand, in some embodiments, the controller unit <NUM> may use an NFC interface <NUM> to initiate a transaction with the fare gate <NUM>. However, as noted before, an NFC interface may not support a fully hands-free transaction. An NFC interface may be primarily used where, for business or technical reasons, a fare gate that supports NFC cannot be easily modified to support direct connectivity with the controller unit <NUM> for completely hands-free fare validation. Thus, if the fare gate can be modified to support direct transaction initiation via another interface-such as, for example, an Ethernet based LAN-then the NFC interface may be eliminated. Hence, the NFC interface <NUM> is shown dotted in <FIG>. It is observed that, in particular embodiments, there may be two NFC interfaces associated with the entry gate system <NUM>-an NFC interface <NUM> at the entrance of the "Paid Area" and an NFC interface <NUM> at the exit from the "Paid Area. " In one embodiment, the Radio Frequency (RF) protocol between the NFC interface <NUM> and the fare gate <NUM> may be ISO (International Standards Organization) <NUM>-<NUM> compliant. More generally, the ISO <NUM>-<NUM> standard defines the RF communications between RFID based devices such as contactless smartcards and another device (such as a fare gate).

On the hardware side, the fare gate <NUM> may include a fare gate controller (not shown), which may be a microcontroller with appropriate logic to act as a fare gate. In one embodiment, the fare gate <NUM> may include some of all of the following: memory to store the control program and associated data; an NFC reader/writer; other media readers (optional); an Ethernet network hub or switch; a local display (LCD or similar) for each side-entry and exit; speaker(s); and remote display capability. Furthermore, in certain embodiments, the fare gate <NUM> may have an "Enter" indicator on its entry side and a "Don't Enter" indicator on its exit side.

Although not shown in <FIG>, the transit station <NUM> may also have one or more remote displays-for example, displays hanging over the fare gate entrance and exit. When passengers are moving quickly through a fare gate, these displays provide visual feedback to the users, such as, for example, a confirmation that their electronic ticket is valid and accepted and, hence, they should continue moving to the transit terminal or "Paid Area. " In particular embodiments, these remote displays may serve a user interfaces to allow the fare gate to indicate both normal and exceptional operating conditions to passengers and station personnel. For example, the remote display may have the ability to display a message when there is a valid transaction and accompany the message with a "valid transaction" sound. Similarly, the fare gate-affiliated user interface may have the ability to display a message when there is an invalid transaction attempt (such as, for example, submission of an invalid or expired ticket) and accompany the message with an "invalid transaction" sound. In some embodiments, the remote displays may have the ability to indicate the direction in which the fare gate is operating. For example, an "Entry" gate may have a red indicator visible from the "Paid Area" side and a blue or green indicator may be visible from the "Unpaid Area" side. The "paid" and "unpaid" areas are shown in the exemplary illustration of <FIG>.

In the embodiment of <FIG>, a transaction logger or backend system <NUM> is shown to be in wireless communication with the entry gate system <NUM>. In one embodiment, the backend system <NUM> may be a proprietary data processing system owned, operated, maintained, or controlled by the relevant transit authority or by the operator of the fare gate <NUM> at the transit station <NUM>. Various transactions and events (discussed later) may be logged in the transaction logger <NUM>, for example, for statistical analysis, record-keeping, and Operations and Maintenance (O&M) activity. In certain embodiments, the entry gate system <NUM> may communicate with the back-end system <NUM> using a wired connection.

In particular embodiments, the FV user app <NUM> installed in the mobile device <NUM> may support two modes of operation: (i) a Mobile Ticketing mode, and (ii) a Fare Gate Transaction mode. The system designer may determine whether the functionality offered by these modes is accessible from the same screen or requires selection of a menu item or clicking on an appropriate radio button from the choices presented on the display screen of the mobile device <NUM>.

In the mobile ticketing mode, the user app <NUM> may allow the user of the mobile device <NUM> to select and purchase a wide range of ticket types to numerous destinations using a mobile ticketing application provided by, for example, the transit station operator or train/bus service operating company. The user app <NUM> may further allow the user to see which transport tickets are electronically stored on the user's mobile device <NUM>. The user may initially have to deploy the mobile ticketing app on his/her mobile device <NUM> to avail of the electronic ticketing functionality. A user interface may be provided to enable the user to select and add a valid electronic ticket to the inventory of tickets stored on the device <NUM>. The user may also pay for the selected ticket online and the transit service (for example, train service or bus service) operator may confirm the purchase with a unique code, digital coupon, or electronic ticket itself. In one embodiment, any of these forms of "receipt" of purchase may be later used by the mobile device <NUM> for hands-free fare validation. The user may enter the mobile ticketing mode via an appropriate menu selection. Once in the ticketing mode, the user may press a corresponding on-screen/off-screen button for adding a ticket and the displayed count of valid tickets increases by one. In certain embodiments, the user may need to setup an online account with the transit service operator for automatic billing and payment facility, as well as for recurring ticket purchases. For the sake of present discussion, additional details of ticket generation, purchase, and delivery are not relevant and, hence, such details are not provided.

In the fare gate transaction mode, the user app <NUM> may allow the user to "tender" and activate a valid electronic ticket (stored on the mobile device <NUM>) by simply passing through the entry gate (fare gate) system <NUM>. Thus, the fare gate transaction mode may facilitate hands-free fare validation. In one embodiment, if the user account information is stored in a remote Host Operator or Processing System (HOPS), such as, for example, the backend system <NUM> in <FIG>, and if Internet-connectivity is available near the fare gate area, the user app <NUM> may retrieve such information from the remote host and make it available to the fare gate <NUM> through communication with the controller driver <NUM> in the controller unit <NUM>. However, if online connection to the remote host is not possible, the user app <NUM> may still provide hands-free fare validation as discussed below.

In one embodiment, the user may activate the user app <NUM> on the user's mobile device <NUM> prior to or at the time of entering/approaching the transit station <NUM>. The user app <NUM> may then configure the mobile device <NUM> to enable scanning for Bluetooth beacons transmitted by the weak-up beacon <NUM>. The user app <NUM> may then identify those Bluetooth beacons that have a specific UUID or other recognizable Beacon ID to, for example, ascertain that the received beacon signal is from an authorized Bluetooth transmitter and, hence, to conclude that the user device <NUM> is in the proximity of the authorized transmitter and, hence, near the fare validation zone. In one embodiment, based on the identified beacon ID (received from the wake-up beacon <NUM>), the user app <NUM> may activate the hands-free fare validation feature in the mobile device <NUM>. In response to determining that the mobile device <NUM> is in or near the fare gate trigger zone (the fare validation zone), the user app <NUM> may configure the mobile device <NUM> to send binary data of a specified size to the FV controller driver <NUM> in the controller unit <NUM>. The size of the transmitted data may be based on the Bluetooth LE (or other Bluetooth) protocol used to communicate with the controller driver <NUM>. The binary data may be used to send requests to the controller driver <NUM> to perform specific operations such as, for example, electronic ticket validation with the fare gate <NUM>. The user app <NUM> may also receive binary data of a specified size from the controller driver <NUM>. Such data may include, for example, a ticket confirmation/acceptance message or an invalid ticket/rejection message. When a ticket is accepted by the fare gate, the user app <NUM> may update the ticket information stored on the mobile device <NUM> to indicate that the specified ticket has been used. The user app <NUM> may also send a log message to the controller driver <NUM>, for example, to enable the driver <NUM> to keep a count of number of users with valid or invalid electronic tickets. More generally, the user app <NUM> may be able to open and close a Bluetooth (or BLE) communication session with the controller deriver <NUM>, as needed.

In one embodiment, the user app <NUM> may display a message or other visible notification on the mobile device <NUM> to inform the user that the user's electronic ticket has been accepted or rejected, as applicable. Instead of or in addition to such visible notification, the user app <NUM> may also provide an audible notification-such as, for example, play a valid transaction sound or an error sound-to the user through the mobile device <NUM>. The error sound may be specifically associated with an error condition, such as, for example, an invalid/expired ticket or no electronic ticket stored in the mobile device <NUM>.

In particular embodiments, the FV controller driver <NUM> installed in the controller unit <NUM> also may support two modes of operation: (i) a Transit Control mode, and (ii) a Maintenance mode. A system administrator or other transit service employee may be allowed to place the controller unit <NUM> in the appropriate mode of operation. In certain embodiments, the maintenance mode may be omitted.

In the transit control mode, the controller driver <NUM> may configure the controller unit <NUM> to initiate a ticket transaction with the fare gate <NUM>, and obtain a transaction response from the fare gate. As part of the fare validation transaction, the controller driver <NUM> may be able to detect the entry of a passenger into the fare validation zone. In one embodiment, the driver <NUM> may also detect the exit of a passenger from the fare gate trigger zone. In one embodiment, such entry and exit may be determined based on information received from the "people counting" devices <NUM>-<NUM>. Furthermore, the controller driver <NUM> may be able to identify the mobile device that has entered the fare gate trigger zone (and the device's proximity to the fare gate) based on the signals received from the mobile device over the Bluetooth interface <NUM> (<FIG>). In response, the driver <NUM> may send binary data to the mobile device-based user app and also receive binary data from the user app-such as the user app <NUM> operational on the mobile device <NUM>. As noted before, the binary data received from the mobile device <NUM> may include electronic ticket information, which the controller driver <NUM> may send to the fare gate system <NUM> for validation. Upon receiving a confirmation message from the entry gate system <NUM>, the controller driver <NUM> may send a ticket acceptance response to the user app <NUM> over the Bluetooth interface <NUM>, thereby informing the user of the mobile device <NUM> that the electronic ticket is valid for transit and the user may continue proceeding towards the entry gate <NUM> in a hands-free manner. On the other hand, if the submitted ticket is not accepted by the fare gate <NUM>-for example, if the ticket is invalid or expired, the controller driver <NUM> may send a ticket rejection message to the user app <NUM> over the Bluetooth interface <NUM>, thereby instructing the mobile device <NUM> to generate an alert for the user. In one embodiment, after validating or rejecting an electronic ticket, the controller driver <NUM> may close the existing communication session with the mobile device <NUM>.

The controller driver <NUM> may be configured to store a log message for every transit control-related transaction it performs and the log data may be stored either locally in the controller unit <NUM> or remotely, for example, in the transaction logging system <NUM> (<FIG>), subject to device storage constraints.

In the maintenance mode, the controller driver <NUM> may gather statistics to help improve the fare validation methodology or to aid administrators or service personnel from the transit company in their implementation of the fare validation approach. In the maintenance mode, the controller driver <NUM> may provide two sub-modes of operation: (i) Display Current Activity: This sub-mode allows display of the incoming data; and (ii) Display Statistics: This sub-mode allows display of statistics associated with the usage of the fare validation methodology as per particular embodiments of the present disclosure.

When a registered beacon is detected by the user app <NUM>, it may share the Beacon ID and the mobile device's proximity information with the controller driver <NUM>. In the Display Current Activity sub-mode, the controller driver <NUM> may display the Beacon ID and the proximity information. In one embodiment, the driver <NUM> may also log the Beacon information. In another embodiment, the driver <NUM> may disable such logging. Thus, when Beacon logging has been enabled and a registered beacon is detected, the Beacon ID and proximity information may be logged either locally or remotely, subject to device storage constraints.

To aid the transit service administrators, the controller driver <NUM> may keep statistics in any mode of operation. However, in particular embodiments, the statistics may be displayed only when in the Display Statistic sub-mode. The statistical information that may be displayed include, for example: (i) operational statistics, (ii) a count of the number of passengers entering through the fare gate into the "Paid Area" with a valid ticket while in the "Open Gate" mode (discussed later), (iii) a count of the number of passengers entering through the fare gate into the "Paid Area" with a valid ticket while in the "Closed Gate" mode (discussed later), (iv) a count of the number of passengers entering through the fare gate into the "Paid Area" without a valid ticket while in the "Open Gate" mode, (v) a count of the number of passengers entering through the fare gate into the "Paid Area" without a valid ticket while in the "Closed Gate" mode, (vi) a count of the number of passengers exiting through the fare gate into the "Unpaid Area" while in the "Open Gate" mode, and (vii) a count of the number of passengers exiting through the fare gate into the "Unpaid Area" while in the "Closed Gate" mode. All statistical counts may be reset to zero.

It is observed here that the fare gate <NUM> may be setup either has an "Entry" gate or an "Exit" gate. Thus, the maintenance personnel may need to indicate the "direction" of the fare gate (for example, an "Entry" gate or an "Exit" gate) to the controller driver <NUM>. Furthermore, in certain embodiments, the maintenance personnel may also need to specify to the controller driver <NUM> whether the fare gate <NUM> is operating in the "Open Gate" mode or the "Closed Gate" mode.

<FIG> is a simplified illustration of a fare validation zone (also referred to herein as a "fare gate trigger zone") <NUM> according to one embodiment of the present disclosure. Broadly, the fare validation zone <NUM> may refer to the area within or near the fare gate <NUM> where the presence of the mobile device <NUM> indicates its user's intent to pay a fare and proceed to the actual transit terminal. By way of an illustration, the fare gate <NUM> is shown as a dotted block in <FIG>. As shown in the exemplary illustration of <FIG>, a user may approach the fare gate trigger zone <NUM> from an entry lane or "Unpaid Area" <NUM> at the transit station <NUM> (<FIG>). An "unpaid area" may be an unsecured area of the transit station <NUM> where normal non-paying pedestrian traffic occurs. In contrast, when a user's electronic ticket submission is accepted by the fare gate system <NUM> as discussed before, the user may transition to a "Paid Area" <NUM> at the station <NUM>. From the "paid area," the user may proceed to boarding the appropriate transit service (for example, a train or a bus).

The fare gate <NUM> may be operated in an "open gate" mode or in a "closed gate" mode. In the "open gate" mode, the fare gate <NUM> may be a barrier-less system. For example, during peak hours when the passenger volume warrants the presence of inspectors (or other service personnel) at the transit station <NUM>, the fare gate (physical) barriers may be left open and the passengers may pass through the gates quickly in a single file. A remote sign for each fare gate may display a message, accompanied by an audible alert, informing the user and the inspectors should the user not have a valid or detectable ticket. However, during off-peak times when the availability of inspectors is decreased and the passenger volume does not hinder throughput, the fare gate barriers may be closed (or brought back in their place), thereby operating the fare gate <NUM> in the "closed gate" mode.

In certain embodiments, there may be four different transit situations: (<NUM>) A user enters the "paid area" <NUM> when the fare gate <NUM> is in the "open gate" mode, (<NUM>) a user enters the "paid area" <NUM> when the fare gate <NUM> is in the "closed gate" mode, (<NUM>) a user exits from the "paid area" <NUM> when the fare gate <NUM> is in the "open gate" mode, and (<NUM>) a user exits from the "paid area" <NUM> when the fare gate <NUM> is in the "closed gate" mode. Various operations discussed below with reference to these transit situations are exemplary in nature, and may be accomplished through interaction between the mobile device-based FV user app <NUM> and the controller unit-based FV controller driver <NUM>, as well as the controller driver's further interaction with other devices/systems-such as, for example, the "people counting" devices, the entry gate system, and the like-at the transit station <NUM>. In view of the earlier discussion of <FIG>, additional details of such device-to-device interactions or communication are not provided below.

If the user has a valid ticket, the user may simply walk through the gate hands-free and the remote display (not shown) may show a message indicating that a valid ticket was tendered and a "Ticket Accepted" beep may be emitted from the fare gate's speakers (not shown). The user's mobile device <NUM> may also display a notification indicating that the ticket was tendered and accepted. The mobile device may also emit a "Ticket Accepted" beep and a corresponding vibration pattern. The user app <NUM> may decrease the count of valid tickets stored on the mobile device <NUM> by one.

If the user's mobile device does not have the FV User Application-like the User App <NUM> in <FIG>-loaded, then, upon entering the Fare Gate Trigger Zone <NUM>, the remote display may display a message informing the user to either purchase a ticket or use a traditional ticket. This may be accompanied by a loud "Invalid Entry Attempt" alert through the Fare Gate speakers.

On the other hand, if the user app is loaded on the user's mobile device, but there is no ticket or no valid ticket stored in the device, the remote display may show a "No Ticket Available" message and the Fare Gate speakers may emit the "No Ticket Available" alert sound. The user may also receive a notification on the mobile device indicating that no valid tickets were available, accompanied by the corresponding audible alert and vibration pattern.

In particular embodiments, altering of the user's cadence, such as, for example, pausing to let the person ahead go through the fare gate before proceeding, may be necessary in the Open Gate mode.

(<NUM>) Entry in the "Closed Gate" mode: Initially, the user with the mobile device <NUM> may approach the fare gate <NUM> that is open for entry (for example, "Entry OK" indicator lights are lit on the Unpaid Area side <NUM>).

If the user has a valid ticket, as the user enters the Fare Gate Trigger Zone <NUM>, the barrier (not shown) opens up and the user may simply walk through the gate hands-free. The remote display may show a message indicating that a valid ticket was tendered and a "Ticket Accepted" beep may be emitted from the Fare Gate's speakers. The user's mobile device <NUM> may display a notification indicating that the ticket was tendered and accepted. The mobile device may also emit a "Ticket Accepted" beep and a corresponding vibration pattern. The user app <NUM> may decrease the count of valid tickets stored on the mobile device <NUM> by one.

If the user's mobile device does not have the FV User Application-like the User App <NUM> in <FIG>-loaded, then, upon entering the Fare Gate Trigger Zone <NUM>, the remote display may show a message informing the user that the FV user app was not detected and that a traditional ticket should be used. In that case, the fare gate barrier may remain closed until a valid ticket (electronic or traditional) is presented.

(<NUM>) Exit in the "Open Gate" mode: Initially, the user with the mobile device <NUM> may approach the fare gate <NUM> that is open for exiting (for example, "Entry OK" indicator lights are lit on the Paid Area side <NUM>).

If the user's mobile device has the FV user application loaded with a valid, active ticket, the user may simply walk through the fare gate and the remote display may show, for example, a "Thanks for Travelling with Us" message. The user's mobile device may also display a notification indicating that he or she has exited the system (or transit terminal). The mobile device may also emit an "Exiting" beep and a corresponding vibration pattern.

On the other hand, if the user's mobile device does not have the FV user app loaded (or has it loaded but without a valid, active ticket) and if the user enters the Fare Gate Trigger Zone, a message on the remote display may remind the user to use traditional media to "swipe out" for exit (if this is required by the transit service operator). This may be accompanied by a loud "Invalid Entry Attempt" alert through the Fare Gate's speakers. In certain embodiments, this "Invalid Entry Attempt" processing may also occur if the user's mobile device is not turned on (whether turned off by the user or as a result of a dead battery).

(<NUM>) Exit in the "Closed Gate" mode: Initially, the user with the mobile device <NUM> may approach the fare gate <NUM> that is open for exiting (for example, "Entry OK" indicator lights are lit on the Paid Area side <NUM>).

If the user's mobile device has the FV user application loaded, as the user enters the Fare Gate Trigger Zone, the gate's barrier may open and the user may walk through the gate to exit. The remote display may show a "Thanks for Travelling with Us" message. The user's mobile device may also display a notification indicating that he or she has exited the system (or transit terminal). The mobile device may also emit an "Exiting" beep and a corresponding vibration pattern.

On the other hand, if the user's mobile device does not have the FV user app loaded and if the user enters the Fare Gate Trigger Zone, a message on the remote display may remind the user to use traditional media to "swipe out" for exit (if this is required by the transit service operator). In particular embodiments, the fare gate's barrier may remain closed until a valid ticket (electronic or traditional) is presented. In some embodiments, this kind of processing may also occur if the user's mobile device is not turned on (whether turned off by the user or as a result of a dead battery).

It is noted that, typically, the fare gate <NUM> may be designated as either an "Entry" fare gate or an "Exit" fare gate. The entry or exit direction may be changed under the control of station personnel. For example, the gate <NUM> may be set in one direction in the morning as an "Entry" gate and as an "Exit" gate in the afternoon. However, if needed, the controller driver <NUM> may be configured to dynamically determine the direction of the gate based upon the direction of passenger movement. In certain embodiments, additional hardware (not shown), such as, for example, motion sensors or cameras, may be provided at the transit station <NUM> to assist the controller driver <NUM> in detection of such direction. Alternatively, the camera devices <NUM>-<NUM> may provide the needed input to the controller driver <NUM> to enable the detection of the direction of passenger movement.

In some embodiments, the controller driver <NUM> may operate in conjunction with suitable hardware to detect presence of more than one person at a time within the fare gate trigger zone <NUM>. Furthermore, both the user app <NUM> and the controller driver <NUM> may be configured to support may different types of tickets based upon the class of service (for example, regular, senior citizen, student, transit company employee, and the like), the time period (for example, peak time, off-peak time), and seasonal versus "pay-as-you-go" tickets. In certain embodiments, the controller driver <NUM> may be configured to detect if the same mobile device is used to tender tickets for more than one passenger. Such a situation may arise, for example, when a ticketed passenger pre-purchases more than one ticket and pays for a non-ticketed passenger by passing back the mobile device to the non-ticketed passenger after the ticketed passenger's ticket is validated.

<FIG> is an exemplary context diagram <NUM> for the FV user application <NUM> in <FIG> according to particular embodiments of the present disclosure. <FIG> shows an exemplary context diagram <NUM> for the FV controller driver <NUM> in <FIG> according to particular embodiments of the present disclosure. The context diagram <NUM> illustrates exemplary external and internal interfaces specific to the FV user app <NUM>. Similar interfaces specific to the controller driver <NUM> are shown in the context diagram <NUM> of <FIG>. For ease of discussion, <FIG> are discussed together and the entities common between <FIG> and <FIG> are identified using the same reference numerals. Furthermore, because of the earlier detailed discussion of various operational aspects of the FV user app <NUM> and the FV controller driver <NUM>, only a brief description of the data and control flows shown in <FIG> is provided. In the embodiments of <FIG>, solid arrows depict data flows and dashed arrows depict control flows. Furthermore, in <FIG>, blocks with solid lines-such as the blocks <NUM>-<NUM>-depict external interfaces, whereas blocks with dashed lines-such as the blocks <NUM> and <NUM>-depict internal sub-system interfaces.

Referring now to <FIG>, the "Controller Messages" are the messages sent between the use app <NUM> and the controller driver <NUM>. These messages may typically contain commands or data which will inform the controller driver <NUM> how close the mobile device <NUM> is to the fare gate <NUM>. The "Controller Responses" are responses sent by the controller driver <NUM> to the user app <NUM>. The "Gate Beacon Advertising Packets" in <FIG> refer to information sent from the gate beacon(s) <NUM>-<NUM>. This information may be used to detect the proximity of the mobile device <NUM> with the fare gate <NUM>. On the other hand, the "Wake-Up Beacon Advertising Packets" in <FIG> refer to information sent from the wake-up beacon(s) <NUM>. This information may be used to get the user app <NUM> into a ready state for entering through a fare gate-such as the fare gate <NUM>-that is enabled for hands-free fare validation as per teachings of the present disclosure. In <FIG>, the term "User Data In" refers to the data that a user <NUM> running the FV user app <NUM> (on the user's mobile device <NUM>) enters through a user interface provided by the user app <NUM>. On the other hand, the term "User Data Out" refers to the data that is displayed via the user interface to the user <NUM> running the FV user app <NUM>. The term "User Control" refers to the control information sent from the mobile device <NUM> running the FV user app <NUM>.

Referring now to <FIG>, the "People Counter Data" are the data sent to the FV controller driver <NUM> by the people-counting devices <NUM>-<NUM> to aid in determining the number of people in the fare gate trigger zone <NUM>. The "People Counter Control" is the control information for the people-counting device. This control information may include commands to enable or disable the sending of the "People Counter Data. " The "FG Data Req" is a fare gate data request and includes the data sent to the fare gate <NUM> from the controller driver <NUM>, typically during the processing of a transaction, such as, for example, a ticket validation transaction. The "FG Data Rsp" is a fare gate data response and includes the data returned from the fare gate <NUM> during the transaction processing or upon a command from the controller driver <NUM>. The "FG Control" is the fare gate control information.

If a fare gate communicates with the controller driver <NUM> via an NFC interface, such as, for example, the NFC interface <NUM> shown in <FIG>, then there may be an NFC reader/writer <NUM> present at the fare gate. The NFC reader/writer <NUM> may communicate with the controller driver <NUM> via the NFC interface <NUM>. In certain embodiments, there may be individual NFC readers/writers for the entrance NFC interface <NUM> and the exit NFC interface <NUM> in <FIG>. The "NFC Data Req" are data requests sent to the NFC reader/writer <NUM>, the "NFC Data Rsp" are responses received from the NFC reader/writer <NUM>, and the "NFC Control" is the control information associated with the NFC reader/writer <NUM> to facilitate various NFC-based transactions.

If the controller driver <NUM> supports the earlier-discussed maintenance mode, a maintenance user <NUM>-such as, for example, a service person or employee of the transit station <NUM> or a transit company-may interact with the system running the controller driver <NUM> to perform maintenance tasks. The controller unit <NUM> in <FIG> is an example of such a system. The system may provide a user interface to support maintenance-related content displays. In that regard, the "Maintenance User Data In" is the data that the maintenance user <NUM> enters through the user interface when in the maintenance mode, the "Maint. User Data Out" is the data that is displayed to the maintenance user <NUM> when in the maintenance mode, and the "Maint. User Control" is the control information sent to the controller driver <NUM> when in the maintenance mode.

<FIG> is a block diagram of an exemplary mobile device <NUM> according to one embodiment of the present disclosure. As noted earlier, the mobile or wireless device <NUM> may be a UE, a smartphone, or any other wireless device operable for hands-free fare validation as per particular embodiments of the present disclosure. The wireless device <NUM> may include a processor <NUM>, a memory <NUM> (which may, in some embodiments, also include memory on UE's Subscriber Identity Module (SIM) card), a transceiver <NUM>, and an antenna unit <NUM>. The memory <NUM> may include the program code for the FV user app <NUM>. The program code may be executed by the processor <NUM>. Upon execution of the user app's program code by the processor <NUM>, the processor may configure the mobile device <NUM> to perform various mobile device-specific tasks associated with the hands-free fare validation methodology as per the teachings of the present disclosure. In one embodiment, such tasks may include, for example, the process steps illustrated in <FIG>. Such tasks also may include, for example, mobile device-specific (or FV user app-based) operations discussed earlier with reference to <FIG>.

The memory <NUM> may store data or other related communications received from the controller unit <NUM> (<FIG>) as well as other content needed to facilitate hands-free fare validation. For example, in one embodiment, the memory <NUM> may store, for example, pre-purchased electronic ticket(s), itinerary information, electronic purchase receipts, Bluetooth beacon ID, and the like. The memory <NUM> also may store results of fare validation (for example, ticket activation status, valid/invalid transaction, and the like) received from the controller unit <NUM> as well as entry/exit notifications for the user.

The transceiver <NUM> may communicate with the processor <NUM> to perform transmission/reception of data, control, or other signaling information (via the antenna unit <NUM>) to/from the controller unit <NUM> with which the mobile device <NUM> may be in communication during hands-free fare validation. In particular embodiments, the transceiver <NUM> may support the Bluetooth based-such as, for example, the Bluetooth LE-based-communication with the controller unit <NUM> to implement the hands-free fare validation methodology as per the teachings of the present disclosure. The transceiver <NUM> may be a single unit or may comprise of two separate units-a transmitter (not shown) and a receiver (not shown). The antenna unit <NUM> may include one or more antennas. Alternative embodiments of the wireless device <NUM> may include additional components responsible for providing additional functionality, including any of the functionality identified herein, such as, for example, receiving Bluetooth beacon signals, transmitting electronic ticket information, communicating with the controller unit <NUM>, displaying various notifications or messages to the user of the device <NUM>, etc., and/or any functionality necessary to support the solution as per the teachings of the present disclosure. For example, in one embodiment, the wireless device <NUM> may also include an on-board power supply unit <NUM> (e.g., a battery or other source of power) to allow the device to be operable in a mobile manner.

In one embodiment, the mobile device <NUM> may be configured (in hardware, via software, or both) to implement device-specific aspects of hands-free fare validation as per teachings of the present disclosure. As noted before, the software or program code may be part of the FV user app <NUM> and may be stored in the memory <NUM> and executable by the processor <NUM>. For example, when existing hardware architecture of the device <NUM> cannot be modified, the functionality desired of the device <NUM> may be obtained through suitable programming of the processor <NUM> using the program code of the FV user app <NUM>. The execution of the program code (by the processor <NUM>) may cause the processor to perform as needed to support the hands-free fare validation solution as per the teachings of the present disclosure. Thus, although the wireless device <NUM> may be referred to as "performing," "accomplishing," or "carrying out" (or similar such other terms) a function/task or a process or a method step, such performance may be technically accomplished in hardware and/or software as desired.

<FIG> depicts a block diagram of an exemplary controller unit <NUM> according to one embodiment of the present disclosure. The controller unit or system <NUM> may be suitably configured-in hardware and/or software-to implement the hands-free fare validation methodology according to the teachings of the present disclosure. The controller unit <NUM> may include a processor <NUM> and ancillary hardware to accomplish hands-free fare validation discussed before. The processor <NUM> may be configured to interface with a number of external devices. In one embodiment, a number of input devices <NUM> may be part of the system <NUM> and may provide data inputs-such as user input, camera images, statistical data, and the like-to the processor <NUM> for further processing. The input devices <NUM> may include, for example, a touchpad, a camera, a proximity sensor, a GPS sensor, a computer keyboard, a touch-screen, a joystick, a physical or virtual "clickable button," a computer mouse/pointing device, and the like. In <FIG>, the processor <NUM> is shown coupled to a system memory <NUM>, a peripheral storage unit <NUM>, one or more output devices <NUM>, and a network interface unit <NUM>. A display screen is an example of an output device <NUM>. In some embodiments, the controller unit <NUM> may include more than one instance of the devices shown. In various embodiments, all of the components shown in <FIG> may be housed within a single housing. In other embodiments, the controller unit <NUM> may not include all of the components shown in <FIG>. Furthermore, the controller unit <NUM> may be configured as a standalone system, as a server system, as a client system, or in any other suitable form factor.

In particular embodiments, the controller unit <NUM> may include more than one processor (e.g., in a distributed processing configuration). When the controller unit <NUM> is a multiprocessor system, there may be more than one instance of the processor <NUM> or there may be multiple processors coupled to the processor <NUM> via their respective interfaces (not shown). The processor <NUM> may be a System on Chip (SoC) and/or may include more than one Central Processing Units (CPUs).

The system memory <NUM> may be any semiconductor-based storage system such as, for example, Dynamic Random Access Memory (DRAM), Static RAM (SRAM), Synchronous DRAM (SDRAM), Rambus® DRAM, flash memory, various types of Read Only Memory (ROM), and the like. In some embodiments, the system memory <NUM> may include multiple different types of semiconductor memories, as opposed to a single type of memory. In other embodiments, the system memory <NUM> may be a non-transitory data storage medium.

The peripheral storage unit <NUM>, in various embodiments, may include support for magnetic, optical, magneto-optical, or solid-state storage media such as hard drives, optical disks (such as Compact Disks (CDs) or Digital Versatile Disks (DVDs)), non-volatile Random Access Memory (RAM) devices, Secure Digital (SD) memory cards, Universal Serial Bus (USB) memories, and the like. In some embodiments, the peripheral storage unit <NUM> may be coupled to the processor <NUM> via a standard peripheral interface such as a Small Computer System Interface (SCSI) interface, a Fibre Channel interface, a Firewire® (IEEE <NUM>) interface, a Peripheral Component Interface Express (PCI Express™) standard based interface, a USB protocol based interface, or another suitable interface. Various such storage devices may be non-transitory data storage media.

As mentioned earlier, a display screen may be an example of the output device <NUM>. Other examples of an output device include a graphics/display device, a computer screen, an alarm system, or any other type of data output device. In some embodiments, the input device(s) <NUM> and the output device(s) <NUM> may be coupled to the processor <NUM> via an I/O or peripheral interface(s).

In one embodiment, the network interface unit <NUM> may communicate with the processor <NUM> to enable the controller unit <NUM> to couple to a network or a communication interface. In another embodiment, the network interface unit <NUM> may be absent altogether. The network interface <NUM> may include any suitable devices, media and/or protocol content for connecting the controller unit <NUM> to a network/interface-whether wired or wireless. In various embodiments, the network may include Local Area Networks (LANs), Wide Area Networks (WANs), wired or wireless Ethernet, telecommunication networks, or other suitable types of networks/interfaces. For example, the network may be a packet-switched network such as, for example, an Internet Protocol (IP) network like the Internet, a circuit-switched network, such as the Public Switched Telephone Network (PSTN), or a combination of packet-switched and circuit-switched networks. In another embodiment, the network may be an IP Multimedia Subsystem (IMS) based network, a satellite-based communication link, a Bluetooth or Bluetooth LE (BLE) based network/interface, an NFC based network/interface, a Worldwide Interoperability for Microwave Access (WiMAX) system based on Institute of Electrical and Electronics Engineers (IEEE) standard IEEE <NUM>. 16e, an IP-based cellular network such as, for example, a Third Generation Partnership Project (3GPP) or 3GPP2 cellular network like a Long Term Evolution (LTE) network, a combination of cellular and non-cellular networks, a proprietary corporate network, a Public Land Mobile Network (PLMN), and the like.

The controller unit <NUM> may include an on-board power supply unit <NUM> to provide electrical power to various system components illustrated in <FIG>. The power supply unit <NUM> may receive batteries or may be connectable to an AC electrical power outlet. In one embodiment, the power supply unit <NUM> may convert solar energy or other renewable energy into electrical power.

In one embodiment, a non-transitory, computer-readable data storage medium, such as, for example, the system memory <NUM> or a peripheral data storage unit, such as a removable memory, may store program code or software for the FV controller driver <NUM>. In the embodiment of <FIG>, the system memory <NUM> is shown to include such program code. The processor <NUM> may be configured to execute the program code, whereby the controller unit <NUM> may be operative to perform various controller-unit specific tasks associated with the hands-free fare validation methodology as per the teachings of the present disclosure. In one embodiment, such tasks may include, for example, the process steps illustrated in <FIG>. Such tasks also may include, for example, relevant controller driver-based operations discussed earlier with reference to <FIG>. The program code or software may be proprietary software or open source software which, upon execution by the processor <NUM>, may enable the controller unit <NUM> to perform controller unit-specific operations to support the hands-free fare validation approach as per teachings of the present disclosure as well as to support other non-validation related actions (such as, for example, operating in the maintenance mode).

In the preceding description, for purposes of explanation and not limitation, specific details are set forth (such as particular architectures, interfaces, techniques, etc.) in order to provide a thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology may be practiced in other embodiments that depart from these specific details. That is, those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the disclosed technology. In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the disclosed technology with unnecessary detail. All statements herein reciting principles, aspects, and embodiments of the disclosed technology, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, such as, for example, any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that block diagrams herein (e.g., in <FIG> and <FIG>) can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology. Similarly, it will be appreciated that the flowcharts in <FIG> represent various processes which may be substantially performed by a respective processor (e.g., the processor <NUM> in <FIG> and the processor <NUM> in <FIG>, respectively). Such a processor may include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. Some or all of the functionalities described above in the context of <FIG> also may be provided by a respective processor <NUM> or <NUM>, in the hardware and/or software. Any of the processors <NUM> and <NUM> may employ distributed processing in certain embodiments.

When certain inventive aspects require software-based processing, such software or program code may reside in a computer-readable data storage medium. As noted earlier with reference to <FIG>, such data storage medium may be part of the peripheral storage <NUM>, or may be part of the system memory <NUM>, or the processor's <NUM> internal memory (not shown). In case of the embodiment in <FIG>, such data storage medium may be part of the memory <NUM> or the processor's <NUM> internal memory (not shown). In certain embodiments, the processors <NUM> and <NUM> may execute instructions stored on a respective such medium to carry out the software-based processing. The computer-readable data storage medium may be a non-transitory data storage medium containing a computer program, software, firmware, or microcode for execution by a general purpose computer or a processor mentioned above. Examples of computer-readable storage media include a ROM, a RAM, a digital register, a cache memory, semiconductor memory devices, magnetic media such as internal hard disks, magnetic tapes and removable disks, magneto-optical media, and optical media such as CD-ROM disks and DVDs.

Alternative embodiments of the controller unit <NUM> according to inventive aspects of the present disclosure may include additional components responsible for providing additional functionality, including any of the functionality identified above and/or any functionality necessary to support the solution as per the teachings of the present disclosure. Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features. As mentioned before, various FV controller driver-based functions and FV user app-based functions discussed herein may be provided through the use of hardware (such as circuit hardware) and/or hardware capable of executing software/firmware in the form of coded instructions or microcode stored on a computer-readable data storage medium (mentioned above). Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented, and thus machine-implemented.

The foregoing describes a system and method in which the Bluetooth technology is used in conjunction with a user application on a mobile device to facilitate hands-free fare validation at a transit station. The user app communicates with a controller driver in a controller unit that interfaces with a compliant fare gate. Bluetooth beacons are used to determine a passenger's proximity to the gate and camera-like devices determine whether a passenger has entered a fare validation zone. A user with a valid and active electronic ticket on their mobile device may simply walk through the fare gate "hands free" without the need to search for a physical ticket or a smartcard or a mobile phone. This hassle-free approach may significantly improve the user experience and passenger throughput through fare gates. Furthermore, the Bluetooth-based or Bluetooth LE-based automated fare validation system may detect and provide feedback to the passenger, when a passenger enters into a "Paid Area" with a valid electronic ticket or when the passenger, with a mobile ticket previously activated, exits from the Paid Area. The system also may detect, and provide external visual and audio alerts, when a passenger enters into the Paid Area without a valid permit for travel or attempts to exit from the Paid Area without a valid permit for travel. Overall, passenger throughput into and out of the Paid Area is increased, especially during peak periods, using the disclosed hands-free ticket validation approach.

Claim 1:
A method in a mobile device (<NUM>) to facilitate hands-free fare validation when a user carrying the mobile device (<NUM>) is inside a fare validation zone at a transit station, the method comprising:
receiving (<NUM>) a Bluetooth beacon signal at a mobile device from a wake-up beacon transmitter (<NUM>);
based on the received beacon signal, determining (<NUM>) that the mobile device (<NUM>) is in the fare validation zone, and launching and preparing a user app (<NUM>) on the mobile device (<NUM>) for proximity tracking, wherein the user app (<NUM>) is configured to support different types of tickets based upon a class of services or a time period;
transmitting (<NUM>) electronic ticket information stored in the mobile device (<NUM>) to a controller unit (<NUM>) at the transit station, wherein the electronic ticket information is transmitted over a first Bluetooth interface between the mobile device (<NUM>) and the controller unit (<NUM>), and wherein the mobile device (<NUM>) is configured to tender tickets for more than one passenger;
receiving (<NUM>) a ticket acceptance response from the controller unit (<NUM>) over the first Bluetooth interface indicating that an the- electronic ticket is valid for transit; and
informing the user to continue towards an entry gate at the transit station in a hands-free manner,
wherein receiving the beacon signal includes:
receiving a beacon Identifier, ID, transmitted using a second Bluetooth interface between the mobile device (<NUM>) and a transmitter of the beacon ID;
identifying the received beacon ID; and
based on the identified beacon ID, activating a hands-free fare validation feature in the mobile device (<NUM>).