WO2019182625A1 - Procédés et systèmes de validation de passe mains libres et transit sans porte - Google Patents

Procédés et systèmes de validation de passe mains libres et transit sans porte Download PDF

Info

Publication number
WO2019182625A1
WO2019182625A1 PCT/US2018/031552 US2018031552W WO2019182625A1 WO 2019182625 A1 WO2019182625 A1 WO 2019182625A1 US 2018031552 W US2018031552 W US 2018031552W WO 2019182625 A1 WO2019182625 A1 WO 2019182625A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile device
transit
user
entry
bluetooth
Prior art date
Application number
PCT/US2018/031552
Other languages
English (en)
Inventor
Micah Bergdale
Edward DONOVAN
Michael O'haire
Nicholas Ihm
Ross Smith
Original Assignee
Bytemark, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/927,305 external-priority patent/US20180211188A1/en
Application filed by Bytemark, Inc. filed Critical Bytemark, Inc.
Priority to GB2016588.2A priority Critical patent/GB2587509B/en
Priority to CA3094302A priority patent/CA3094302A1/fr
Priority to AU2018414521A priority patent/AU2018414521A1/en
Publication of WO2019182625A1 publication Critical patent/WO2019182625A1/fr
Priority to AU2023203911A priority patent/AU2023203911A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H04W12/64—Location-dependent; Proximity-dependent using geofenced areas
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the present disclosure generally relates to automated fare validation at transit stations. More particularly, and not by way of limitation, particular embodiments of the present disclosure are directed to a system and method of hands-free fare validation and gateless entry/exit for a transit service using Bluetooth® such as, for example, Bluetooth Low Energy (LE).
  • Bluetooth® such as, for example, Bluetooth Low Energy (LE).
  • the Bluetooth technology may be used in conjunction with a user application on a mobile device to facilitate such hands-free operations.
  • 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.
  • 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.
  • positioning locators and camera(s) may be used to detect the movement of a user carrying the mobile device and to facilitate the user's entry into (or exit from) a transit service in a gateless environment for a truly hassle-free experience.
  • the Bluetooth LE-based automated fare validation system 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.
  • 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.
  • passenger throughput into and out of the Paid Area may be increased, especially during peak periods, using the hands-free ticket validation and gateless entry approaches disclosed herein.
  • the present disclosure is directed to a method in a mobile device to facilitate gateless entry for a transit service when a user carrying the mobile device approaches a transit facility for the transit service.
  • the method comprises: (i) determining that the mobile device is in proximity of a gateless entry location for the transit service; (ii) transmitting a plurality of Bluetooth advertisement packets to a gateway unit at a first transmission rate over a Bluetooth interface, wherein each advertisement packet contains data indicating that the mobile device is configured for gateless entry for the transit service; (iii) communicating with the gateway unit receiving the plurality of Bluetooth advertisement packets to facilitate authentication of the mobile device; (iv) upon authentication of the mobile device, transmitting transit data to the gateway unit using a plurality of Bluetooth data packets at a second transmission rate over the Bluetooth interface, wherein the transit data includes: (a) a device-specific value to uniquely identify the mobile device and determine a location thereof, and (b) a secure token to facilitate validation of an electronic ticket stored in the mobile device for the transit service;
  • the present disclosure is directed to a method to facilitate gateless entry for a transit service when a user carrying a mobile device approaches a transit facility for the transit service.
  • the method comprises performing the following using a control unit: (i) authenticating the mobile device using Bluetooth-based messaging with the mobile device over a Bluetooth interface; (ii) upon authentication of the mobile device, receiving transit data from the mobile device over the Bluetooth interface, wherein the transit data includes: (a) a device-specific value to uniquely identify the mobile device and determine a location thereof, and (b) a secure token to facilitate validation of an electronic ticket stored in the mobile device for the transit service; (iii) based on the secure token, determining that the electronic ticket is valid for transit; (iv) providing the device- specific value to a positioning unit to enable the positioning unit to uniquely identify the mobile device and determine the location thereof; (v) receiving a timestamped location data for the mobile device from the positioning unit; (vi) based on the timestamped location data, determining that the user is entering a
  • the present disclosure is directed to a mobile device that comprises: (i) a transceiver operable to wirelessly communicate over a Bluetooth interface; (ii) a memory for storing program instructions and an electronic ticket; and (iii) a processor coupled to the transceiver and to the memory.
  • 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 entry for a transit service when a user carrying the mobile device approaches a transit facility for the transit service: (a) determine that the mobile device is in proximity of an entry location for the transit service; (b) transmit a plurality of Bluetooth advertisement packets to a gateway unit at a first transmission rate over the Bluetooth interface using the transceiver, wherein each advertisement packet contains data indicating that the mobile device is configured for entry for the transit service; (c) using the transceiver, communicate with the gateway unit receiving the plurality of Bluetooth advertisement packets to facilitate authentication of the mobile device; (d) upon authentication of the mobile device, transmit transit data to the gateway unit using a plurality of Bluetooth data packets at a second transmission rate over the Bluetooth interface using the transceiver, wherein the transit data includes: (1 ) a device-specific value to uniquely identify the mobile device and determine a location thereof, and (2) a secure token to facilitate validation of the electronic ticket stored in
  • the present disclosure is directed to a system to facilitate entry for a transit service when a user carrying a mobile device approaches a transit facility for the transit service.
  • the system comprises: (i) a gateway unit; (ii) a positioning unit operatively coupled to the gateway unit; and (iii) a controller unit operatively coupled to the gateway unit and the positioning unit.
  • the gateway unit is operable to perform the following: (a) authenticate the mobile device using Bluetooth-based messaging with the mobile device over a Bluetooth interface; (b) upon authentication of the mobile device, receive transit data from the mobile device over the Bluetooth interface, wherein the transit data includes: (1 ) a device-specific value to uniquely identify the mobile device and determine a location thereof, and (2) a secure token to facilitate validation of an electronic ticket stored in the mobile device for the transit service; (c) provide the device- specific value to the positioning unit; and (d) provide the secure token to the controller unit.
  • the positioning unit is operable to perform the following: (a) uniquely identify the mobile device and determine the location thereof based on the device-specific value received from the gateway unit; and (b) send a timestamped location data for the mobile device to the controller unit.
  • the controller unit is operable to perform the following: (a) based on the secure token received from the gateway unit, determine that the electronic ticket is valid for transit; (b) based on the timestamped location data received from the positioning unit, determine that the user is entering an entry point for the transit service; and (c) allow the user to avail the transit service through the entry point.
  • the Bluetooth interface may be a BLE interface.
  • the entry point may be a gateless entry point or a gated entry point.
  • the mobile device and the controller unit may perform various operational aspects briefly mentioned above and further discussed in more detail later below.
  • 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.
  • the Bluetooth-based gateless entry/exit facility may provide additional improvement in passenger throughput in a gateless transit environment where fare gates may be absent or non-operational.
  • FIG. 1 illustrates constituent components of a Fare Validation (FV) application according to an exemplary embodiment of the present disclosure
  • FIG. 2 depicts an exemplary system for implementing the FV application according to one embodiment of the present disclosure
  • FIG. 3 shows an exemplary flowchart illustrating a mobile device-based hands- free fare validation methodology according to one embodiment of the present disclosure
  • FIG. 4 shows an exemplary flowchart illustrating a controller unit-based hands- free fare validation methodology according to one embodiment of the present disclosure
  • FIG. 5 shows an exemplary illustration of system components to implement the hands-free fare validation methodology at a transit station according to one embodiment of the present disclosure
  • FIG. 6 is a simplified illustration of a fare validation zone (or a fare gate trigger zone) according to one embodiment of the present disclosure
  • FIG. 7 is an exemplary context diagram for the FV user application in FIG. 1 according to particular embodiments of the present disclosure
  • FIG. 8 shows an exemplary context diagram for the FV controller driver in FIG. 1 according to particular embodiments of the present disclosure
  • FIG. 9 shows an exemplary flowchart illustrating a mobile device-based gateless entry methodology according to one embodiment of the present disclosure
  • FIG. 10 shows an exemplary flowchart illustrating a control unit-based gateless entry methodology according to one embodiment of the present disclosure
  • FIG. 11 shows an exemplary illustration of system components to implement a walk-in-walk-out configuration of gated or gateless entry/exit at a transit station according to one embodiment of the present disclosure
  • FIG. 12 shows an exemplary illustration of system components to implement a be-in-be-out configuration of gated or gateless entry/exit in a transit vehicle according to one embodiment of the present disclosure
  • FIG. 13 is a block diagram of an exemplary mobile device according to one embodiment of the present disclosure.
  • FIG. 14 depicts a block diagram of an exemplary controller unit according to one embodiment of the present disclosure.
  • a hyphenated term e.g.,“hands-free,”“hassle-free”, etc.
  • its non-hyphenated version e.g., “hands free,”“hassle free”, etc.
  • a capitalized entry e.g.,“Fare Validation Application,” “Fare Gate,”“Controller Unit,” etc.
  • its non-capitalized version e.g., “fare validation application,” “fare gate,”“controller unit,” etc.
  • Coupled operatively coupled
  • connected connecting
  • electrically connected electrically connected
  • 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.
  • various figures (including component diagrams) shown and discussed herein are for illustrative purpose only, and are not drawn to scale.
  • FIG. 1 illustrates constituent components of a Fare Validation (FV) application 10 according to an exemplary embodiment of the present disclosure.
  • the FV application 10 may be a software module having various distributed data processing functionalities discussed later below with reference to FIGs. 2-12. 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 10 may include an FV User Application (user app) component 12 and an FV Controller Driver component (controller driver) 14.
  • the user app and controller driver components may be in bi-directional communication (preferably wireless, as discussed below with reference to FIG.
  • a computer software, program code or module may be referred to as“performing,”“accomplishing,” or“carrying out” a function or process.
  • 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.
  • 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.
  • FIGs. 2-8 relate to the BLE-based hands-free fare validation methodology
  • FIGs. 9-12 relate to the BLE-based fare gate-agnostic entry/exit methodology applicable to transit systems that have fare gates or are completely/partially gateless.
  • gateless entry/exit aspect is provided in the context of description of FIGs. 2-8 below.
  • the fare validation aspect is provided in the context of description of FIGs. 9- 12. It is understood, however, that the fare validation approach discussed in FIGs. 2-8 remains applicable— albeit with suitable modifications, as needed— to the gateless (or gated) entry/exit methodologies discussed with reference to FIGs. 9-12.
  • the configurations in the embodiments of FIGs. 9-12 allow for additional fraud detection for gateless systems.
  • FIG. 2 depicts an exemplary system 16 for implementing the FV application 10 according to one embodiment of the present disclosure.
  • the system 16 may include a mobile device 17 that is in wireless communication with a controller unit 18, as symbolically illustrated by a wireless link 20.
  • the wireless link 20 may be a Bluetooth-based communication interface.
  • the FV user app 12 may reside in the mobile device 17, whereas the FV controller driver 14 may reside at the controller unit 18 as shown in FIG. 2.
  • 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.
  • UE User Equipment
  • a BLE tag may be considered a "mobile device” or “mobile handset” as mentioned later below.
  • the controller unit 18 is shown as a separate device or apparatus. However, the controller unit 18 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 18 may be implemented in an already-existing physical computing/data processing unit or (non- physical) server software (not shown) at a transit station.
  • the functionality of the controller unit 18 may be accomplished using multiple different units.
  • the UE 17 may include, inside its housing (not shown), a relatively low-powered Central Processing Unit (CPU) 22 executing a mobile operating system (or mobile OS) 24 (e.g., SymbianTM OS, PalmTM OS, Windows MobileTM, AndroidTM, Apple iOSTM, etc.). Because of the battery-powered nature of mobile handsets, the CPU 22 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. 2, in addition to the user app 12, the UE 17 may also have one or more mobile applications 26 resident therein.
  • a mobile operating system or mobile OS 24
  • the UE 17 may also have one or more mobile applications 26 resident therein.
  • These mobile applications 26 are software modules that may have been pre-packaged with the handset 17 or may have been downloaded by a user into the memory (not shown) of the UE 17. Some mobile applications 26 may be more user-interactive applications (e.g., a mobile game of chess to be played on the UE 17, a face recognition program to be executed by UE 17, 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 26 as well as the user app 12 may be executed by the processor 22 under the control of the mobile operating system 24. As also shown in FIG.
  • the UE 17 may further include a wireless interface unit 28 to facilitate UE’s wireless communication with the controller unit 18 (discussed later) via a Bluetooth interface such as, for example, a Bluetooth LE (or Bluetooth) interface 29.
  • a Bluetooth interface such as, for example, a Bluetooth LE (or Bluetooth) interface 29.
  • the wireless interface unit 28 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 12, 26 may utilize the wireless interface 28 as needed.
  • Bluetooth LE interface 29 is shown by way of an example only; the teachings of the present disclosure are not limited to a BLE interface alone.
  • BLE Bluetooth Special Interest Group
  • the hands-free fare validation solution as per teachings of the present disclosure may be implemented using a number of Bluetooth specifications, including BLE.
  • BLE Bluetooth LE
  • 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.
  • 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.
  • 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.
  • the controller unit 18 is shown to include a relatively high powered CPU 30 executing an operating system 32 (e.g., WindowsTM, MacTM OSX, Linux, etc.).
  • an operating system 32 e.g., WindowsTM, MacTM OSX, Linux, etc.
  • the controller unit 18 may also store in its memory (not shown) other controller-specific applications 34 such as, for example, an application that facilitates NFC or Ethernet-based communication with an entry gate system (discussed later with reference to FIG. 5), 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 18 may wirelessly communicate with the UE 17 via its own wireless interface unit 36.
  • the interface units 28, 36 may wirelessly transfer data or information between the mobile device 17 and the controller 18 using the Bluetooth interface 29 as shown.
  • a UE-generated signal may be wirelessly sent (using the wireless interface 28) over the Bluetooth interface 29 to the controller unit 18 for further processing by its CPU 30.
  • Any response or other signal from the controller unit 18 can be provided in the UE-recognized wireless format by the controller's wireless interface unit 36 and eventually delivered to UE’s wireless interface 28 (and, hence, to the UE’s processor 22 for further processing) via the Bluetooth interface 29.
  • the resulting wireless “link” between the interfaces 28 and 36 is symbolically illustrated by the bi-directional arrow 29.
  • the wireless interface unit 36 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 14, 34 may utilize the wireless interface 36 as needed.
  • the mobile device 17 and/or the controller unit 18 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.
  • LAN Local Area Network
  • PLMN Public Land Mobile Network
  • FIG. 3 shows an exemplary flowchart 40 illustrating a mobile device-based hands-free fare validation methodology according to one embodiment of the present disclosure.
  • Various operational tasks shown in FIG. 3 may be performed by the mobile device 17 when the user app 12 (and other relevant program code) is executed by the CPU 22.
  • the mobile device 17 may receive a Bluetooth beacon signal (block 42).
  • 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").
  • the mobile device 17 may determine that it is in the fare validation zone (block 43).
  • the mobile device can determine the proximity of a fare gate trigger zone based on geofence(s) and GPS data.
  • the mobile device 17 may transmit electronic ticket information stored in the mobile device (as discussed later below) to a controller unit, such as the controller unit 18, at the transit station.
  • the electronic ticket information may be transmitted over a Bluetooth interface, such as the Bluetooth LE interface 29 between the mobile device 17 and the controller unit 18.
  • the mobile device 17 may receive a ticket acceptance response from the controller unit 18 over the Bluetooth interface 29 indicating that the electronic ticket is valid for transit.
  • the mobile device 17 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.
  • 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. 4 shows an exemplary flowchart 50 illustrating a controller unit-based hands-free fare validation methodology according to one embodiment of the present disclosure.
  • Various operational tasks shown in FIG. 4 may be performed by the controller unit 18 when the controller driver 14 (and other relevant program code) is executed by the CPU 30.
  • the controller unit 18 may receive a notification that the user has entered the fare validation zone.
  • such notification may be received from a "people counting" device such as, for example, a digital camera, connected to the controller unit 18 as discussed later with reference to FIG. 5.
  • the controller unit 18 may identify the mobile device carried by the user—such as the mobile device 17— based on the signals received from the mobile device over a Bluetooth interface, such as the Bluetooth LE interface 29. Upon identifying the mobile device 17 and establishing a Bluetooth communication link with it, the controller unit 18 may receive electronic ticket information from the mobile device 17 over the Bluetooth interface 29 (block 55). At block 57, the controller unit 18 may determine that the electronic ticket is valid for transit. As discussed later, in one embodiment, the controller unit 18 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 18 may receive a confirmation message from the entry control gate.
  • a Bluetooth interface such as the Bluetooth LE interface 29.
  • the controller unit 18 may sent a ticket acceptance response to the mobile device 17 over the Bluetooth interface 29. This informs the user/passenger (carrying the mobile device 17) to continue towards an entry gate at the transit station in a hands-free manner.
  • 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 18 and the passenger's mobile device 17.
  • FIG. 5 shows an exemplary illustration of system components to implement the hands-free fare validation methodology at a transit station 60 according to one embodiment of the present disclosure.
  • FIG. 5 shows an exemplary illustration of system components to implement the hands-free fare validation methodology at a transit station 60 according to one embodiment of the present disclosure.
  • the mobile device 17 may be an Apple® iPhone 4S, iPhone 6, or a newer model. In other embodiments, the mobile device 17 may be a Google® Nexus 4, Nexus 5, or a newer model. In any event, the user app 12 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 17 may support downloadable applications and Bluetooth LE 4.2 or higher protocols (or other applicable Bluetooth protocols) for communications, including Bluetooth Beacon scanning.
  • the mobile device 17 may include a User Interface (Ul) 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.
  • Ul User Interface
  • the controller unit 18 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 PiTM or iOSTM unit.
  • the controller unit 18 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 4.0 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.
  • a Bluetooth (including BLE) based radio communication such as, 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 4.0 or higher stack (or other applicable Bluetooth protocols), video or Liquid Crystal Display (LCD) display, NFC
  • controller unit 18 there may be more than one controller unit 18 installed at the transit station 60, 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.
  • controller units or beacon transmitters may be implementation-specific.
  • the transit station 60 may optionally employ one or more Wake-Up beacon transmitters 62 for launching and preparing the user app 12 on the mobile device 17 for proximity tracking.
  • the number of wake-up beacons 62 may be based upon field conditions.
  • the wake-up beacon 62 may provide Bluetooth LE (BLE) (or other type of Bluetooth) beacon signals using an omnidirectional antenna (not shown).
  • BLE Bluetooth LE
  • the beacon signals transmitted by the transmitter 62 may be compatible with proprietary Bluetooth beacon standards such as, for example, the iBeacon standard for Apple® systems and similar Bluetooth beacon standards for AndroidTM systems.
  • the wake-up beacon transmitter 62 may be capable of advertising a programmable 16-byte Universal Unique Identifier (UUID) along with a 2-byte Major Number and a 2-byte Minor Number.
  • UUID Universal Unique Identifier
  • the 16-bit Major Number may further subdivide iBeacons that have the same UUID.
  • the 16-bit Minor Number may further subdivide iBeacons within the same Major Number.
  • a UUID is a unique number.
  • each service may be represented by a UUID.
  • the 16-bit standardized BLE UUIDs allow for 65536 unique services.
  • a BLE also supports 128 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.bluetooth.org/gatt/services/Pages/ServiceHome.aspx. Although UUIDs are normally fixed, they may be dynamic in certain implementations.
  • the wake-up transmitter 62 may be considered a "Bluetooth Beacon” because it periodically transmits a fixed message— a Beacon Identifier (ID)— using Bluetooth or Bluetooth LE.
  • a Bluetooth Beacon is usually incapable of receiving data.
  • the Beacon ID may provide transmitter-specific identification information that the mobile operating system 24 may use to recognize the Bluetooth Beacon.
  • the Beacon ID is the UUID along with the major and minor numbers.
  • the Bluetooth LE also referred to as "Bluetooth Smart” is a wireless communication protocol that permits short range (up to 30 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.
  • the mobile device may read all of the beacon IDs transmitted in its vicinity.
  • 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 12— over WiFi to another computer or host— such as, for example, the controller unit 18— that determines the location of the mobile device 17.
  • the user app 12 in the mobile device 17 may "listen" to the beacons and then connect over WiFi to an application—such as, for example, the controller driver 14— that determines location.
  • an application such as, for example, the controller driver 14— that determines location.
  • the user app 12 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 14.
  • Major beacon formats are supported by iOSTM, AndroidTM, and other mobile operating systems.
  • the transit station 60 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 85 is shown in FIG. 6 (discussed below). In FIG.
  • gate beacons 64-65 are also Bluetooth Beacons and may be similar to the wake-up beacon 62, except that each gate beacon 64- 65 may have a highly unidirectional external antenna (not shown) to specifically "track" the passengers who are present in the fare validation zone.
  • all Bluetooth® communications between various entities in FIG. 5 may conform to the standards set forth in the Bluetooth® Core Specification 4.2.
  • the transit station 60 may have a number of "people counting” devices 67-68 to determine when a person has entered the fare validation zone.
  • the "people counting” devices may include stereoscopic digital Infrared (IR) cameras.
  • the cameras 67-68 may be wirelessly connected to the controller unit 18 to notify the controller 18 when a person has entered the fare validation zone.
  • the devices 67-68 may be configured to distinguish between one person and more than one person in the fare gate trigger zone.
  • An entry gate system 70 (also referred to herein as a "Fare Gate”) may be deployed at the transit station 60 to function as an electronically-controlled access barrier.
  • a fare gate is shown in FIG. 5 by way of an example. Many transit stations may have multiple such fare gates.
  • 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.
  • the fare gate 70 may be directly connected to the controller unit 18 via an Ethernet interface 72.
  • a standard Power Over Ethernet (POE) switch (or hub) may be used to facilitate multiple Ethernet connections or field conditions.
  • POE Power Over Ethernet
  • a standard RJ-45 connector may be used to provide the Ethernet-based network connectivity between the controller unit 18 and the fare gate 70.
  • 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.
  • the physical barrier-based illustration in FIG. 5 is exemplary only; the teachings of the present disclosure are not limited to a physical gate barrier being present, as discussed below with reference to the gateless entry/exit aspect in the embodiments of FIGs. 9-12.
  • the controller unit 18 may use an NFC interface 74 to initiate a transaction with the fare gate 70.
  • 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 18 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.
  • the NFC interface 74 is shown dotted in FIG. 5.
  • the Radio Frequency (RF) protocol between the NFC interface 74 and the fare gate 70 may be ISO (International Standards Organization) 14443-2 compliant. More generally, the ISO 14443-2 standard defines the RF communications between RFID based devices such as contactless smartcards and another device (such as a fare gate).
  • the fare gate 70 may include a fare gate controller (not shown), which may be a microcontroller with appropriate logic to act as a fare gate.
  • the fare gate 70 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.
  • the fare gate 70 may have an "Enter” indicator on its entry side and a "Don't Enter” indicator on its exit side.
  • the transit station 60 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.”
  • these remote displays may serve as user interfaces to allow the fare gate to indicate both normal and exceptional operating conditions to passengers and station personnel.
  • 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.
  • 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.
  • 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. 6.
  • a transaction logger or backend system 80 is shown to be in wireless communication with the entry gate system 70.
  • the backend system 80 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 70 at the transit station 60.
  • Various transactions and events may be logged in the transaction logger 80, for example, for statistical analysis, record-keeping, and Operations and Maintenance (O&M) activity.
  • the entry gate system 70 may communicate with the back-end system 80 using a wired connection.
  • the FV user app 12 installed in the mobile device 17 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 17.
  • the user app 12 may allow the user of the mobile device 17 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 12 may further allow the user to see which transport tickets are electronically stored on the user's mobile device 17.
  • the user may initially have to deploy the mobile ticketing app on his/her mobile device 17 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 17.
  • 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.
  • any of these forms of "receipt" of purchase may be later used by the mobile device 17 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.
  • 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.
  • the user app 12 may allow the user to "tender” and activate a valid electronic ticket (stored on the mobile device 17) by simply passing through the entry gate (fare gate) system 70.
  • the fare gate transaction mode may facilitate hands-free fare validation.
  • the user account information is stored in a remote Host Operator or Processing System (HOPS), such as, for example, the backend system 80 in FIG. 5, and if Internet-connectivity is available near the fare gate area, the user app 12 may retrieve such information from the remote host and make it available to the fare gate 70 through communication with the controller driver 14 in the controller unit 18. However, if online connection to the remote host is not possible, the user app 12 may still provide hands-free fare validation as discussed below.
  • HOPS Host Operator or Processing System
  • the user may activate the user app 12 on the user's mobile device 17 prior to or at the time of entering/approaching the transit station 60.
  • the user app 12 may then configure the mobile device 17 to enable scanning for Bluetooth beacons transmitted by the wake-up beacon 62.
  • the user app 12 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 17 is in the proximity of the authorized transmitter and, hence, near the fare validation zone.
  • the user app 12 may activate the hands-free fare validation feature in the mobile device 17.
  • the user app 12 may configure the mobile device 17 to send binary data of a specified size to the FV controller driver 14 in the controller unit 18.
  • the size of the transmitted data may be based on the Bluetooth LE (or other Bluetooth) protocol used to communicate with the controller driver 14.
  • the binary data may be used to send requests to the controller driver 14 to perform specific operations such as, for example, electronic ticket validation with the fare gate 70.
  • the user app 12 may also receive binary data of a specified size from the controller driver 14. Such data may include, for example, a ticket confirmation/acceptance message or an invalid ticket/rejection message.
  • the user app 12 may update the ticket information stored on the mobile device 17 to indicate that the specified ticket has been used.
  • the user app 12 may also send a log message to the controller driver 14, for example, to enable the driver 14 to keep a count of number of users with valid or invalid electronic tickets. More generally, the user app 12 may be able to open and close a Bluetooth (or BLE) communication session with the controller driver 14, as needed.
  • the user app 12 may display a message or other visible notification on the mobile device 17 to inform the user that the user's electronic ticket has been accepted or rejected, as applicable.
  • the user app 12 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 17.
  • 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 17.
  • the FV controller driver 14 installed in the controller unit 18 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 18 in the appropriate mode of operation.
  • the maintenance mode may be omitted.
  • the controller driver 14 may configure the controller unit 18 to initiate a ticket transaction with the fare gate 70, and obtain a transaction response from the fare gate.
  • the controller driver 14 may be able to detect the entry of a passenger into the fare validation zone.
  • the driver 14 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 67-68.
  • the controller driver 14 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 29 (FIG. 2).
  • the driver 14 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 12 operational on the mobile device 17.
  • the binary data received from the mobile device 17 may include electronic ticket information, which the controller driver 14 may send to the fare gate system 70 for validation.
  • the controller driver 14 may send a ticket acceptance response to the user app 12 over the Bluetooth interface 29, thereby informing the user of the mobile device 17 that the electronic ticket is valid for transit and the user may continue proceeding towards the entry gate 70 in a hands-free manner.
  • the controller driver 14 may send a ticket rejection message to the user app 12 over the Bluetooth interface 29, thereby instructing the mobile device 17 to generate an alert for the user. In one embodiment, after validating or rejecting an electronic ticket, the controller driver 14 may close the existing communication session with the mobile device 17.
  • the controller driver 14 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 18 or remotely, for example, in the transaction logging system 80 (FIG. 5), subject to device storage constraints.
  • the controller driver 14 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.
  • the controller driver 14 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.
  • a registered beacon When a registered beacon is detected by the user app 12, it may share the Beacon ID and the mobile device's proximity information with the controller driver 14.
  • the controller driver 14 In the Display Current Activity sub-mode, the controller driver 14 may display the Beacon ID and the proximity information. In one embodiment, the driver 14 may also log the Beacon information. In another embodiment, the driver 14 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.
  • the controller driver 14 may keep statistics in any mode of operation.
  • 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
  • the fare gate 70 may be setup either has an "Entry” gate or an "Exit” gate.
  • 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 14.
  • the maintenance personnel may also need to specify to the controller driver 14 whether the fare gate 70 is operating in the "Open Gate” mode or the "Closed Gate” mode.
  • FIG. 6 is a simplified illustration of a fare validation zone (also referred to herein as a "fare gate trigger zone”) 85 according to one embodiment of the present disclosure.
  • the fare validation zone 85 may refer to the area within or near the fare gate 70 where the presence of the mobile device 17 indicates its user's intent to pay a fare and proceed to the actual transit terminal.
  • the fare gate 70 is shown as a dotted block in FIG. 6.
  • a user may approach the fare gate trigger zone 85 from an entry lane or "Unpaid Area" 87 at the transit station 60 (FIG. 5).
  • An "unpaid area” may be an unsecured area of the transit station 60 where normal non-paying pedestrian traffic occurs.
  • the user may transition to a "Paid Area” 88 at the station 60. From the "paid area,” the user may proceed to boarding the appropriate transit service (for example, a train or a bus).
  • the fare gate 70 may be operated in an "open gate” mode or in a "closed gate” mode.
  • the fare gate 70 may be a barrier-less system.
  • 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.
  • the fare gate barriers may be closed (or brought back in their place), thereby operating the fare gate 70 in the "closed gate” mode.
  • 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 17 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 12 may decrease the count of valid tickets stored on the mobile device 17 by one.
  • the remote dis play may display a message informing the user to either purchase a ticket or use a tradi tional ticket. This may be accompanied by a loud“Invalid Entry Attempt” alert through the Fare Gate speakers.
  • 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 val- id tickets were available, accompanied by the corresponding audible alert and vibration pat- tern.
  • 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 nec- essary in the Open Gate mode.
  • 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 17 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 12 may decrease the count of valid tickets stored on the mobile de- vice 17 by one.
  • the remote dis play 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.
  • 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 val- id tickets were available, accompanied by the corresponding audible alert and vibration pat- tern.
  • the user's mobile device may simply walk through the fare gate and the remote display may show, for example, a“Thanks for Traveling 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.
  • 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 accom- panied by a loud“Invalid Entry Attempt” alert through the Fare Gate’s speakers.
  • such remote display and speaker based reminders/alerts also may be im- plemented in the "Open Gate” and “Closed Gate” entry modes (1 ) and (2), respectively, discussed above. 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 re- sult of a dead battery).
  • the gate's barrier may open and the user may walk through the gate to exit.
  • the remote display may show a“Thanks for Traveling 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 cor- responding vibration pattern.
  • 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).
  • 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).
  • the fare gate 70 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.
  • the gate 70 may be set in one direction in the morning as an "Entry” gate and as an "Exit” gate in the afternoon.
  • the controller driver 14 may be configured to dynamically determine the direction of the gate based upon the direction of passenger movement.
  • additional hardware such as, for example, motion sensors or cameras, may be provided at the transit station 60 to assist the controller driver 14 in detection of such direction.
  • the camera devices 67-68 may provide the needed input to the controller driver 14 to enable the detection of the direction of passenger movement.
  • the controller driver 14 may operate in conjunction with suitable hardware to detect presence of more than one person at a time within the fare gate trigger zone 85.
  • both the user app 12 and the controller driver 14 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.
  • the controller driver 14 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. 7 is an exemplary context diagram 95 for the FV user application 12 in FIG. 1 according to particular embodiments of the present disclosure.
  • FIG. 8 shows an exemplary context diagram 100 for the FV controller driver 14 in FIG. 1 according to particular embodiments of the present disclosure.
  • the context diagram 95 illustrates exemplary external and internal interfaces specific to the FV user app 12. Similar interfaces specific to the controller driver 14 are shown in the context diagram 100 of FIG. 8.
  • FIGs. 7-8 are discussed together and the entities common between FIGs. 5 and 7-8 are identified using the same reference numerals.
  • FIGs. 7-8 only a brief description of the data and control flows shown in FIGs. 7-8 is provided.
  • solid arrows depict data flows and dashed arrows depict control flows.
  • the "Controller Messages” are the messages sent between the use app 12 and the controller driver 14. These messages may typically contain commands or data which will inform the controller driver 14 how close the mobile device 17 is to the fare gate 70.
  • the “Controller Responses” are responses sent by the controller driver 14 to the user app 12.
  • the "Gate Beacon Advertising Packets” in FIG. 7 refer to information sent from the gate beacon(s) 64-65. This information may be used to detect the proximity of the mobile device 17 with the fare gate 70.
  • the "Wake-Up Beacon Advertising Packets” in FIG. 7 refer to information sent from the wake- up beacon(s) 62 .
  • This information may be used to get the user app 12 into a ready state for entering through a fare gate—such as the fare gate 70— that is enabled for hands-free fare validation as per teachings of the present disclosure.
  • a fare gate such as the fare gate 70— that is enabled for hands-free fare validation as per teachings of the present disclosure.
  • the term “User Data In” refers to the data that a user 97 running the FV user app 12 (on the user's mobile device 17) enters through a user interface provided by the user app 12.
  • the term “User Data Out” refers to the data that is displayed via the user interface to the user 97 running the FV user app 12.
  • the term "User Control” refers to the control information sent from the mobile device 17 running the FV user app 12.
  • the "People Counter Data” are the data sent to the FV controller driver 14 by the people-counting devices 67-68 to aid in determining the number of people in the fare gate trigger zone 85.
  • 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 70 from the controller driver 14, 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 70 during the transaction processing or upon a command from the controller driver 14.
  • the "FG Control” is the fare gate control information.
  • a fare gate communicates with the controller driver 14 via an NFC interface, such as, for example, the NFC interface 74 shown in FIG. 5, then there may be an NFC reader/writer 102 present at the fare gate.
  • the NFC reader/writer 102 may communicate with the controller driver 14 via the NFC interface 74.
  • the "NFC Data Req" are data requests sent to the NFC reader/writer 102
  • the "NFC Data Rsp" are responses received from the NFC reader/writer 102
  • the "NFC Control” is the control information associated with the NFC reader/writer 102 to facilitate various NFC-based transactions.
  • a maintenance user 104 such as, for example, a service person or employee of the transit station 60 or a transit company— may interact with the system running the controller driver 14 to perform maintenance tasks.
  • the controller unit 18 in FIG. 2 is an example of such a system.
  • the system may provide a user interface to support maintenance-related content displays.
  • the "Maintenance User Data In” is the data that the maintenance user 104 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 104 when in the maintenance mode
  • the "Maint. User Control” is the control information sent to the controller driver 14 when in the maintenance mode.
  • a BLE tag may be considered a "mobile device” or “mobile handset” usable in the embodiments of FIGs. 9-12, as mentioned earlier.
  • a BLE tag may operate in a manner similar to a mobile device such as a UE or a cell phone.
  • the BLE tag may transmit BLE advertisement packets to a BLE gateway, advertise a unique ID and/or a secure token to the device locators, and perform other actions similar to a "typical" mobile device (such as a cell phone, smartphone, or UE) to facilitate the gateless entry/exit discussed with reference to FIGs. 9-12.
  • a "typical" mobile device such as a cell phone, smartphone, or UE
  • FIGs. 9-12 primarily focuses on the mobile device 17 being a "typical" UE, smartphone, or tablet, such discussion remains equally applicable when the mobile device 17 is a BLE tag. Furthermore, as noted before, the discussion of FIGs. 9-12 is fare gate-agnostic. In other words, the methodologies discussed with reference to FIGs. 9-12 apply to a gateless entry/exit location as well as a gated entry/exit location. Thus, although the discussion of FIGs. 9-12 primarily focuses on the gateless entry/exit aspect, it is understood that such discussion remains applicable— albeit with suitable modifications, as needed— to the gated entry/exit aspect as well. However, for the sake of brevity, the discussion of FIGs. 9-12 is not repeated to cover the gated entry/exit aspects.
  • FIG. 9 shows an exemplary flowchart 108 illustrating a mobile device-based gateless entry methodology according to one embodiment of the present disclosure.
  • Various operational tasks shown in FIG. 9 may be performed by the mobile device 17 when the user app 12 (and other relevant program code) is executed by the CPU 22.
  • the FV user app 12 may be suitably configured to provide the gateless entry/exit functionality discussed in the context of the embodiments in FIGs. 9-12.
  • the user app 12 may be configured to support gateless entry/exit with or without the hands-free fare validation functionality.
  • the transit facility may be a transit station or a transit vehicle itself.
  • the mobile device 17 may determine that it is in proximity of a gateless entry location for a transit service.
  • a gateless entry location may be used instead of the earlier-mentioned “fare gate trigger zone” (or “fare validation zone”) to emphasize the gateless entry/exit aspect instead of the fare validation aspect.
  • these terms may be synonymous and may be interchangeably used.
  • the mobile device 17 may transmit a plurality of Bluetooth advertisement packets to a gateway unit over a Bluetooth interface, such as the Bluetooth LE interface.
  • the gateway unit may be at a stationary location, such as a transit station, or may be operated in a mobile environment, such as inside a transit vehicle.
  • the advertisement packets may be transmitted at a first transmission rate and each packet may contain data indicating that the mobile device is configured for gateless entry for the transit service.
  • the mobile device 17 also may communicate with the gateway unit receiving the plurality of Bluetooth advertisement packets to facilitate authentication of the mobile device (block 114).
  • the gateway unit itself may authenticate the mobile device.
  • two or more system units may jointly operate to authenticate the mobile device.
  • the mobile device 17 may transmit transit data to the gateway unit using a plurality of Bluetooth data packets over the Bluetooth interface, such as the BLE interface.
  • the data packets may be transmitted at a second transmission rate, which, in some embodiments, may be higher than the first transmission rate mentioned at block 112. In other embodiments, the first and the second transmission rates may be the same.
  • the transit data may include: (i) a device-specific value to uniquely identify the mobile device and determine the location thereof, and (ii) a secure token to facilitate validation of an electronic ticket stored in the mobile device for the transit service.
  • the device-specific value and the secure token may be processed by the relevant processing entities to authorize the user- carrying the mobile device to proceed to the "paid area" in a gateless entry environment.
  • the mobile device 17 may inform the user to avail the transit service through the gateless entry location.
  • An alert audible, visible, or audiovisual
  • "OK for transit” or a similar message may be displayed on the mobile device (or played as an audio clip) to inform the user to continue proceeding into the transit vehicle or a designated boarding area (or "paid area”) for the transit service in a gateless entry environment.
  • FIG. 10 shows an exemplary flowchart 120 illustrating a control unit-based gateless entry methodology according to one embodiment of the present disclosure.
  • the controller unit 18 itself may operate as the control unit.
  • various operational tasks shown in FIG. 10 may be performed by the controller unit 18 when the controller driver 14 (and other relevant program code) is executed by the CPU 30.
  • the controller unit 18 may operate in conjunction with other units (as discussed later with reference to the exemplary embodiments in FIGs. 11-12) to provide the functionality of the control unit in FIG. 10.
  • the controller driver 14 may be suitably configured to accomplish the gateless entry functionality in a distributed manner.
  • the control unit 10 may be performed by a control unit to facilitate gateless entry for a transit service—like a bus service, a ferry service, a train service, and so on— when a user carrying a mobile device, such as the mobile device 17, approaches a transit facility for the transit service.
  • a transit service like a bus service, a ferry service, a train service, and so on— when a user carrying a mobile device, such as the mobile device 17, approaches a transit facility for the transit service.
  • the transit facility may be a transit station or a transit vehicle itself.
  • the control unit may authenticate the mobile device using Bluetooth-based messaging with the mobile device over a Bluetooth interface, such as a BLE interface.
  • a Bluetooth interface such as a BLE interface.
  • the control unit may receive transit data from the mobile device over the Bluetooth interface (block 124).
  • the transit data may include: (i) a device-specific value to uniquely identify the mobile device and determine the location thereof, and (ii) a secure token to facilitate validation of an electronic ticket stored in the mobile device for the transit service. Based on the secure token, the control unit may determine that the electronic ticket is valid for transit (block 126).
  • control unit may access a database containing a record of purchased tickets to validate the electronic ticket associated with the secure token received from the mobile device 17.
  • control unit may provide the device-specific value (received at block 124) to a positioning unit to enable the positioning unit to uniquely identify the mobile device 17 and determine the location of the mobile device 17.
  • the control unit may receive a timestamped location data for the mobile device 17 from the positioning unit. Based on the timestamped location data, the control unit may determine that the user (of the mobile device 17) is entering a gateless entry point for the transit service (block 132).
  • the control unit may allow the user to avail the transit service through the gateless entry point, as noted at block 134.
  • the control unit may actuate one or more indicators prompting the user to avail the transit service through the gateless entry location.
  • the indicators may include one or more audible indicators, one or more visible signs/indicators, or both. This informs the user (carrying the mobile device 17) to continue proceeding into the transit vehicle or a designated boarding/paid area for the transit service in a gateless entry environment.
  • FIG. 11 shows an exemplary illustration 136 of system components to implement a walk-in-walk-out configuration of gated or gateless entry/exit at a transit station (not shown) according to one embodiment of the present disclosure.
  • FIG. 12 shows an exemplary illustration 174 of system components to implement a be-in-be-out configuration of gated or gateless entry/exit in a transit vehicle (not shown) according to one embodiment of the present disclosure.
  • FIGs. 11 and 12 are implemented in different environments— stationary (FIG. 11 ) vs. mobile (FIG.
  • FIGs. 11-12 are substantially similar in the sense that they employ essentially the same type of system components, albeit in different environments, and also provide substantially similar functionality to facilitate gateless entry as per teachings of the present disclosure. Therefore, for ease of discussion, the system components common between the embodiments in FIGs. 11-12 are identified using the same reference numerals. It is understood, however, that, such common reference does not imply that the implementations in FIGs. 11-12 are identical or interchangeable. Rather, as mentioned before, these two implementations are distinct and devised for different operating environments— stationary (FIG. 11 ) vs. mobile (FIG. 12).
  • the system components in the operating configuration 136 may primarily include a Bluetooth gateway (such as a BLE gateway) 138; a positioning unit comprising a first set of device locators 140, a second set of device locators 142, and a positioning engine 144; at least one camera such as a three-dimensional (3D) camera 146; a gateless entry controller 148; and a router such as an Ethernet router 150.
  • the operating configuration 136 also may optionally include at least one BLE (or other type of Bluetooth) wake-up beacon 152 and a database 154.
  • the router 150 may be connected to or operatively/communicatively coupled to the system components 138, 140, 142, 144, 146, and 148 via respective wired connections, as shown by unbroken, bi-directional arrows in FIG. 11. In particular embodiments, some or all of these wired connections may be Ethernet connections.
  • the router 150 also may be connected to the Internet 156 or a similar packet-switched (or IP) network through a wired connection, such as an Ethernet connection.
  • the entry controller 148 may be coupled to or operatively connected to the database 154 through a respective wired connection, such as an Ethernet connection.
  • the BLE gateway 138 may communicate with the mobile device 17 using a wireless connection, such as a BLE interface, as indicated by a broken (dashed), bi-directional arrow 158 in FIG. 11.
  • a wireless connection such as a BLE interface
  • the wake-up beacon 152 and/or the controller 148 also may communicate with the mobile device 17 using a wireless connection, such as a BLE connection.
  • the system components in the operating configuration 174 of FIG. 12 are similarly identified, but not individually listed/mentioned here for the sake of brevity. Based on a comparison of FIGs. 11 and 12, it is observed that the positioning unit in case of FIG.
  • FIGs. 11-12 may not include the first set of device locators 140 because they may not be needed in a transit vehicle-based implementation in certain embodiments. In other words, less number of device locators may suffice for a transit vehicle-based implementation. Furthermore, it is noted that the number and placement of components in FIGs. 11-12 are for illustration only. In different embodiments, multiple devices of the same type—for example, multiple 3D cameras— may be needed depending on the desired coverage and physical geometry of the area to be covered for gateless entry operations.
  • WiWo walk-in-walk- out
  • BiBo be-in-be-out
  • the WiWo configuration may be implemented in a stationary location—such as, for example, a train station, a bus stop, a ferry dock, and so on— where a traditional "check- in-check-out” (CiCo) configuration is applicable.
  • a user may be required to perform an action—such as, for example, swipe fare media, present a barcode to a barcode reader, tap a contactless card, and the like— at least once to enter a paid area that allows boarding a transit vehicle, and the user also may be required to perform an action to exit the paid area when leaving the transit vehicle.
  • the WiWo configuration may be used without fare gates because the controller driver 14 in the gateless entry controller 148 could track multiple users across a large area.
  • the coverage area may need to have sufficient device locators—such as the locators 140, 142— as well as full 3D camera coverage.
  • the BiBo configuration may be implemented in a mobile environment such as, for example, in trains, buses, ferries, or other transit vehicles.
  • a BiBo system may be part of a gateless environment and installed in a transit vehicle.
  • the device locators 142 and the BLE gateway 138 may be mounted physically inside the transit vehicle, whereas the BLE wake-up beacon 152 can be at the transit station or in the transit vehicle.
  • the inside area of the transit vehicle may need a sufficient number of device locators 142 for proper coverage.
  • the boundaries of the "paid area" may be the perimeter of the transit vehicle.
  • the 3D camera(s) 146 may be mounted at the entry/exit points of the transit vehicle with the camera field-of-view covering the width of the passageway.
  • the WiWo and BiBo arrangements shown in FIGs. 11-12, respectively, may be suitably modified in particular use cases to accomplish the gateless entry/exit functionality in a given implementation environment— stationary vs. mobile— without departing from the teachings of the present disclosure.
  • a user may walk into and/or leave a pre- designated "paid area" in a gateless environment without performing any action.
  • the validation of the user's ticket may be performed autonomously in the background without any manual interaction required by the user.
  • the BiBo configuration for gateless entry the user may simply walk into a "paid area" without performing any action.
  • a user's presence in the paid area may be constantly monitored until the user exits the paid area.
  • the BiBo system also may perform the validation of the user's ticket autonomously in the background without any manual interaction by the user.
  • the BLE wake-up beacon 152 may be functionally similar to the wake-up beacon 62 in FIG. 5 and, hence, additional discussion of the hardware features of the wake-up beacon 152 is not provided.
  • the wake-up beacon 152 may be a connectionless (wireless) BLE beacon that advertises data to indicate to a mobile device with the user app 12, such as the mobile device 17, that the user 163 of the mobile device is approaching a hands-free ticketing platform that has automatic fare validation and gateless entry/exit.
  • the 3D camera(s) 146 may be functionally substantially similar to one or more of the "people counting devices" 67-68 and, hence, the hardware features of the 3D camera(s) 146 are not discussed in further details here. In some embodiments, however, the 3D camera 146 may be an infrared camera that uses time-of-flight (TOF) technology to detect and track objects in the camera's field of view 160.
  • TOF time-of-flight
  • the controller 148 may operate as a "control unit" discussed with reference to the flowchart 120 in FIG. 10. However, in the embodiments of FIGs. 11-12, the BLE gateway 138 and the entry controller 148 may collectively operate as a "control unit" of FIG. 10 to accomplish the gateless entry/exit functionality as per teachings of the present disclosure.
  • the controller unit 148 may be functionally similar to the earlier-discussed controller unit 18 in FIGs. 2 and 5, except that the controller unit 148 may include a modified version of the controller driver 14 to accomplish the gateless entry/exit functionality associated with the embodiments in FIGs. 9-12 in addition to the hands-free fare validation functionality offered by the earlier- discussed controller unit 18.
  • the gateway 138 may operate as a "client” whereas the entry controller 148 may operate as a "server” in a client-server configuration.
  • the gateway 138 may communicate with the controller driver 14 to authenticate the mobile device 17, receive a secure token from the mobile device 17, and set mobile device advertisement transmission rate (discussed later).
  • the gateway 138 may be a BLE gateway operable to wirelessly communicate with the mobile device 17 through a BLE interface, as indicated by the broken arrow 158 in FIGs. 11-12.
  • the controller driver application 14 may enable the gateless entry controller 148 to communicate with appropriate entities— for example, via the Ethernet router 150— shown in FIGs.
  • the controller driver application 14 may further enable the gateless entry controller 148 to use the collected data to validate that a user, such as the user 163 in FIGs. 11-12, has a valid ticket on the user's mobile device 17 and also to determine which user is attempting ingress into a paid area.
  • automatic fare validation and gateless entry (or exit, as applicable) aspects may be supported through the controller driver application 14 running on the entry controller 148.
  • the database 154 may store various types of digital content using a relational model of data organization.
  • the relational database 154 may be developed, maintained and/or managed by a software system known as a Relational Database Management System (RDBMS).
  • RDBMS Relational Database Management System
  • the RDBMS may maintain the database 154 as a field-searchable database (DB) containing a plurality of different data fields that can be searched by the controller 148— under operative control of the controller driver 14— using a query-response scheme based on, for example, the Structured Query Language (SQL).
  • SQL Structured Query Language
  • RDBMS RDBMS
  • potential database fields may include some or all of the following: (i) a data field for unique transit vehicle/station identifier, (ii) a data field for transit vehicle stop/route information including station name and Global Positioning System (GPS) location, (iii) a data field for configuration information for each transit vehicle-based BLE gateway, (iv) a data field for the controller driver 14 configuration information, and (v) a data field for 3D camera configuration information.
  • GPS Global Positioning System
  • Each device locator 140, 142 may be a BLE receiver configured to "listen" for BLE advertisements (discussed below) from a mobile device, such as the mobile device 17, and send the Received Signal Strength Indicator (RSSI) and phase data to the positioning engine 144 to enable the positioning engine 144 to determine the position of the mobile device 17.
  • RSSI Received Signal Strength Indicator
  • the locators 140, 142 may not themselves connect or communicate with the mobile device 17, but may rather passively "listen” for BLE advertisements from the mobile device. In other words, unlike the BLE gateway 138, the locators 140, 142 may not establish a two-way communication channel with the mobile device 17.
  • the positioning engine 144 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 PiTM or TM unit.
  • the positioning engine 144 may operate on a software that collects data from the device locators 140, 142, analyzes the collected data, and then determines the position of a mobile device, such as the mobile device 17, in a user-defined site map.
  • the positioning engine 144 may be communicatively coupled to the device locators 140, 142 through, for example, the Ethernet router 150.
  • the user-defined site map may be generated in software and may be a map of the relevant site—such as, for example, a transit station or a transit vehicle where the gateless entry/exit system is implemented— that defines different regions within the map to pinpoint the location or position of a mobile device-carrying user, such as the user 163 in FIGs. 11-12.
  • the combination of device locators 140, 142 and the positioning engine 144 may function as a BLE-based real-time locating system with high accuracy positioning.
  • the device locators 140, 142, and the positioning engine 144 (and its operating software) may be the products of Quuppa, LLC (quuppa.com) of Arlington, VA, having headquarters in Espoo, Finland.
  • the Ethernet router 150 may be a router capable of routing Transmission Control Protocol/Internet Protocol (TCP/IP) data or User Datagram Protocol (UDP) data over multiple Ethernet connections.
  • the router 150 may or may not have Wi-Fi capabilities.
  • a fare gate like the fare gate 70 in FIG. 5, may be optional.
  • fare gate(s) also may be provided in some embodiments along with gateless entry/exit, as per desired implementation.
  • a fare gate may be any physical mechanism used to prevent an unauthorized user from entering a paid area.
  • all Bluetooth® communications between various entities in FIGs. 11-12 may conform to the standards set forth in the Bluetooth® Core Specification 4.2.
  • a proximity area 165 is shown to be "divided" into an unpaid area 167 and a paid area 168.
  • the paid and unpaid areas are shown to be non-overlapping. However, these areas may be overlapping in some embodiments as shown, for example, in FIG. 12.
  • a "proximity area” may be an area defined by geo-location or by the proximity to a BLE wakeup beacon that covers the path a user would need to take to a paid area in a gateless (or gated) entry/exit system. In the context of the embodiments in FIGs.
  • an "unpaid area” may be an area where a user may not have yet paid for transit fare or the user's pre-purchased electronic ticket has not been verified yet.
  • a "paid area” may refer to an area where only users who have paid the transit fare or who have valid electronic tickets are allowed to be.
  • a "paid area” may represent a portion of the transit facility (for example, a transit station or a transit vehicle) allocated mainly for the authorized users of the transit service.
  • a pre-defined region 170 is also shown in FIG. 11 referring to an area covered by the 3D camera's field of view 160 and located directly in the path for the user 163 to enter the paid area 168.
  • the proximity area 176 itself may be the unpaid area— as indicated by the usage of the same reference numeral "176" for both, whereas the paid area 178 may be a portion of (or subset of) the proximity area 176, as shown.
  • the gateless entry configuration 174 of FIG. 12 may be primarily implemented inside a transit vehicle such that the boundaries of the paid area 178 may be the perimeter of the transit vehicle whereas the unpaid area 176 may be the area surrounding the entry and exit points of the transit vehicle. Therefore, there may be an overlap between the paid area 178 and the unpaid area 176, as shown.
  • the gateless entry configuration 136 of FIG. 11 may be primarily implemented at a stationary location such as a transit station. Therefore, the unpaid area 167 (farther from a transit vehicle) may be distinct (non-overlapping) from the paid area 168 (closer to the transit vehicle), as shown.
  • the respective "proximity area" 165, 176 may be considered a "gateless entry location" through which a user may avail a transit service—such as, for example, a bus service, a train service, a ferry service, and the like— or enter/exit a transit vehicle in a gateless manner.
  • a transit service such as, for example, a bus service, a train service, a ferry service, and the like
  • the term "gateless entry location” may be analogized with the earlier-mentioned "fare gate trigger zone” (or “fare validation zone”).
  • FIGs. 11-12 the respective "proximity area" 165, 176 may be considered a "gateless entry location” through which a user may avail a transit service—such as, for example, a bus service, a train service, a ferry service, and the like— or enter/exit a transit vehicle in a gateless manner.
  • the term “gateless entry location” may be analogized with the earlier-mentioned “fare
  • gateless entry location is used instead of the earlier term “fare gate trigger zone” to emphasize the gateless entry/exit aspect instead of the fare validation aspect (even though fare validation also may be performed in the embodiments of FIGs. 9-12).
  • these terms may be used synonymously or interchangeably.
  • the mobile device's 17 presence in a gateless entry location may indicate its user's 163 intent to pay a fare and proceed to the actual transit terminal or transit vehicle.
  • the user 163 may enter the relevant proximity area 165, 176 with possession of the mobile device 17.
  • the device-based user app 12 may be triggered to run in the background by either the mobile device's 17 detection of a BLE wake-up beacon signal from the beacon transmitter 152 and/or sensing of the transit service's geo-location through the mobile device's GPS (not shown).
  • BLE wake-up beacon transmission/reception are already discussed before with reference to discussion of FIG. 5.
  • the user app 12 in the mobile device 17 may determine that the mobile device 17 is in the proximity of a gateless entry location 165 or 176.
  • the user app 12 may evaluate geo-location data from the mobile device's 17 GPS receiver (not shown) to determine that the mobile device is in the proximity of the gateless entry location 165 or 176.
  • the user app 12 may command the mobile device 17 to transmit BLE advertisement packets over a BLE interface, such as the interface 158.
  • Each advertisement packet may contain data indicating that the mobile device 17 contains the user app 12 and is configured for gateless entry/exit for the relevant transit service.
  • each advertisement packet may contain data indicating that the mobile device is configured for gated entry/exit for the transit service.
  • the transmission rate of these advertisement packets may be slower in order to conserve battery.
  • the BLE gateway 138 may be required to advertise data packets and/or be discoverable to the mobile device 17 before authenticating the mobile device 17 (discussed below). However, the iOS mobile device may still need to advertise BLE packets to enable the device locators 140 and/or 142 to determine its position (discussed below). In other words, in case of iOS-based mobile devices, the BLE gateway 138 may need to command the iOS mobile device— via the BLE interface 158— to start transmitting BLE advertisement packets instead of just commanding it to increase the transmission rate of BLE packets (discussed below). These iOSTM device- related additional steps may be optional in case of an AndroidTM-based mobile device. 4. The BLE gateway 138 may detect one or more of the BLE advertisement packets and initiate a connection with the mobile device 17 over the BLE interface 158.
  • the BLE gateway 138 may authenticate the mobile device 17 using Bluetooth-based messaging with the mobile device 17 over the BLE interface 158.
  • Such messaging may include a scheme such as "challenge-response" in which the user app 12 may communicate with the gateway unit 138 to facilitate authentication of the mobile device 17.
  • the authentication may be performed by the gateway unit 138 alone or through communication with the controller driver 14 in the entry controller 148 or with any other unit(s) (not shown).
  • a mobile device may need to be authenticated to make sure that the mobile device attempting to utilize a transit service is indeed an authorized mobile device and is not otherwise prohibited from availing the transit service.
  • the BLE gateway 138 may command— via the BLE interface 158— the mobile device 17 to now increase the transmission rate of the BLE advertisement packets and, within those packets, transmit a device-specific value that uniquely identifies the mobile device 17 and facilitates determination of its location, for example, collectively by the device locators 140 and/or 142 and the positioning engine 144.
  • the BLE gateway 138 may not require increased transmission rate. In that case, the mobile device 17 may transmit the new BLE packets at the same transmission rate as the BLE packets mentioned under sub- paragraph (3) above.
  • the user app 12 may transmit a secure token over the BLE interface 158 to the BLE gateway 138.
  • the secure token may facilitate validation of an electronic ticket stored in the mobile device for the transit service.
  • the BLE gateway 138 may communicate the token to the database 154 through the controller unit 148.
  • the database 154 may contain a record of purchased tickets to enable the controller unit 148 to determine if the user's 163 ticket (associated with the secure token) is valid or not.
  • the controller unit 148 may send the secure token to the database 154, which may search its records and return a confirmation message to the controller unit 148 indicating that the secure token represents a valid ticket.
  • the validation decision may be stored in the controller unit 148 (by the controller driver 14) for the access decision at a later time.
  • the manufacturer/provider of the device locators 140, 142 and the positioning engine 144 may be the same.
  • the device-specific value mentioned above may include a manufacturing value and unique manufacturer data/keys provided by that manufacturer for the mobile device 17. This device-specific value (containing unique manufacturer keys) may have been pre-stored in the mobile device 17 (for example, by the user app 12).
  • the gateway 138 may provide the device-specific value to the positioning engine 144 over the Ethernet to enable the positioning engine 144 to uniquely identify the mobile device 17 from among a plurality of mobile devices in the proximity area 165 or 176 and to also determine/confirm its location.
  • the device locators 140 and 142 are shown separated by the camera 146 simply for the sake of illustration. In particular embodiments, all of the device locators 140 and 142 may be placed in a spread-out cluster without any intervening device/unit. Based on BLE signaling from the mobile device 17, one or more of the device locators 140 and/or 142 may detect the mobile device 17 (without actively connecting or communicating with the device 17, as noted earlier). For example, the device locators 140 and/or 142 may passively "listen" to the BLE advertisement packets mentioned in sub-paragraph (6) above to determine the location of the mobile device 17.
  • the BLE gateway 138 may instruct the mobile device 17 to increase the post-authentication transmission of BLE packets. Such increased rate of transmission may provide as much data as possible to the locators 140, 142 within a short period of time, thereby expediting the determination of location of the mobile device 17.
  • the mobile device-detecting locators may use angle-of-arrival or triangulation to determine the precise location of the mobile device 17.
  • the location information of the mobile device 17 may be conveyed to the positioning engine 144 for further processing.
  • the positioning engine 144 may receive the mobile device location information from the device-detecting locators 140, 142, and analyze that information in view of the unique manufacturer keys received from the BLE gateway 138 as part of the device-specific value mentioned before. As a result, the positioning engine 144 may affirmatively identify the mobile device 17 and associate it with the location data received from the device locators 140, 142. The positioning engine 144 may generate a two- dimensional (2D) version of the location data indicating a respective x-y position of the mobile device within the proximity area 165 or 176.
  • 2D two- dimensional
  • the positioning engine 144 may timestamp the 2D location data for each unique mobile device, such as the device 17, and send the timestamped location data to the controller unit 148 (and, hence, to the controller driver 14) via the Ethernet router 150.
  • the controller driver 14 may collect this location data as an x-y position with a timestamp and may optionally smooth the received data using techniques such as Kalman filtering and cubic splines.
  • the positioning engine 144 also may provide a three-dimensional (3D) version of location data in terms of x-y-z (height) coordinates.
  • the controller driver 14 may be configured to collect and use such 3D location data instead of the 2D location data.
  • the 3D time-of-flight camera 146 may detect the person 163 as an object in the camera's field of view 160.
  • the camera 146 may generate a 2D version of the location of this "object” indicating the x-y position of the user 163 within the pre-defined region 170 (or a similar coverage location within the proximity area 176).
  • the camera 146 may then communicate the presence and position of this "object” to the controller driver 14 by sending a timestamped version of the 2D "object” location data to the entry controller 148.
  • the controller driver 14 may collect this location data as an x-y position with a timestamp and may optionally smooth the received data using techniques such as Kalman filtering and cubic splines.
  • the camera 146 also may provide a three- dimensional (3D) version of location data in terms of x-y-z (height) coordinates.
  • the controller driver 14 may be configured to collect and use such 3D location data instead of the 2D location data.
  • the user 163 may then exit the camera field 160 (and, hence, the pre-defined region 170 or a similar coverage location within the proximity area 176), at which point the controller driver 14 in the controller unit 148 may compare the device-specific timestamped location data from the positioning engine 144 with the device-specific timestamped location data from the 3D camera 146 to determine if the user 163 is attempting to ingress into the paid area 168 (or 178). In case of multiple users proceeding towards the paid area, such comparison of device-specific timestamped location data (for each mobile device) from two different sources may allow the controller unit 148 to determine which user is attempting ingress into the paid area. The validity of the electronic ticket on the user's mobile device 17 will have already been determined (as discussed before) prior to any decision based on this data comparison.
  • the controller driver 14 in the controller unit 148 may send the appropriate command to the gate to either open if the user's ticket is valid or remain closed if the user's ticket is invalid. In one embodiment, when the gate opens, the user can enter a "paid area" to avail the transit service.
  • the gateless entry facility may be provided without a fare gate or along with it (as an additional alternative).
  • audible and/or visible indicators may be provided in the paid area 168, 178 to guide the user 163. If there are indicators (not shown), the controller driver 14 may command the indicators to actuate in a manner that corresponds to the access decision—that is, whether the user should be allowed to avail the transit service through a gateless entry point or not.
  • one or more Light Emitting Diode (LED) lights may be turned on illuminating the gateless entry point, a speaker may be actuated to emit a specific sound or instructions, a flashing arrow sign pointing towards the gateless entry may be actuated, and so on.
  • LED Light Emitting Diode
  • the user can continue walking into a transit vehicle or a pre- designated boarding area for the transit service in a gateless manner. This hassle-free approach may significantly improve the user experience and passenger throughput, especially during peak periods.
  • the controller unit 148 may transmit its access decision— gateless entry granted or denied— to the mobile device 17 via a BLE message to the mobile device 17 to present a notification to the user 163 of the status of the relevant transit ticket.
  • the controller unit 148 may occasionally communicate with the mobile device 17 via a Bluetooth interface, as discussed before with reference to FIG. 5.
  • the access decision may include a ticket acceptance response indicating that the electronic ticket associated with the secure token received from the mobile device 17 is valid for transit.
  • the user app 12 may present the received information as an audible and/or visible notification on the mobile device 17.
  • FIGs. 9-12 illustrate exemplary approaches to facilitating gateless entry/exit for a transit service.
  • various system components such as, for example, the BLE gateway 138, the device locators 140, 142, the 3D camera 146, the entry controller 148, and the like— may operate in a coordinated manner to determine the validity of an electronic ticket stored in the user's mobile device 17 and to track the movement of the user 163 to determine the user's position vis-a-vis a pre-designated "paid area" in the system to facilitate the user's entry/exit into/out of a gateless transit point.
  • the gateless entry aspect predominates in the above discussion of FIGs. 9-12, the teachings of the present disclosure can be suitably applied— with relevant modifications, as needed— to manage gateless exit locations as well as gated entry/exit locations (for example, locations having fare gates).
  • FIG. 13 is a block diagram of an exemplary mobile device 17 according to one embodiment of the present disclosure.
  • the mobile or wireless device 17 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 17 may include a processor 180, a memory 182 (which may, in some embodiments, also include memory on UE’s Subscriber Identity Module (SIM) card), a transceiver 184, and an antenna unit 185.
  • SIM Subscriber Identity Module
  • the memory 182 may include the program code for the FV user app 12.
  • the program code may be executed by the processor 180, which, in one embodiment, may be similar to the CPU 22 in FIG. 2.
  • the processor may configure the mobile device 17 to perform various mobile device-specific tasks associated with the hands-free fare validation and gateless entry/exit methodologies as per the teachings of the present disclosure.
  • such tasks may include, for example, the process steps illustrated in FIG. 3 and/or the process steps illustrated in FIG. 9.
  • Such tasks also may include, for example, mobile device-specific (or FV user app-based) operations discussed earlier with reference to FIGs. 5-12.
  • the memory 182 may store data or other related communications received from the controller unit 18 (FIG. 2) or the controller unit 148 (in case of a gateless environment in FIGs.
  • the memory 182 may store, for example, pre-purchased electronic ticket(s), itinerary information, electronic purchase receipts, Bluetooth beacon ID, and the like.
  • the memory 182 also may store results of fare validation (for example, ticket activation status, valid/invalid transaction, and the like) received from the controller unit 18 (or the controller unit 148) as well as entry/exit notifications for the user.
  • the transceiver 184 may communicate with the processor 180 to perform transmission/reception of data, control, or other signaling information (via the antenna unit 185) to/from the controller unit 18 (or the controller unit 148) with which the mobile device 17 may be in communication during hands-free fare validation or gateless entry/exit.
  • the transceiver 184 may support the Bluetooth based— such as, for example, the Bluetooth LE-based— communication with the controller unit 18 (or the controller unit 148) to implement the hands-free fare validation methodology (and also the gateless entry methodology in some embodiments) as per the teachings of the present disclosure.
  • the transceiver 184 may be a single unit or may comprise of two separate units— a transmitter (not shown) and a receiver (not shown).
  • the antenna unit 185 may include one or more antennas.
  • Alternative embodiments of the wireless device 17 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 18 (or the controller unit 148), displaying various notifications or messages to the user of the device 17, etc., and/or any functionality necessary to support the solution as per the teachings of the present disclosure.
  • the wireless device 17 may also include an on-board power supply unit 186 (e.g., a battery or other source of power) to allow the device to be operable in a mobile manner.
  • the mobile device 17 may be configured (in hardware, via software, or both) to implement device-specific aspects of hands-free fare validation and gateless entry/exit as per teachings of the present disclosure.
  • the software or program code may be part of the FV user app 12 and may be stored in the memory 182 and executable by the processor 180.
  • the functionality desired of the device 17 may be obtained through suitable programming of the processor 180 using the program code of the FV user app 12.
  • the execution of the program code (by the processor 180) may cause the processor to perform as needed to support the hands-free fare validation and gateless entry/exit aspects as per the teachings of the present disclosure.
  • the wireless device 17 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. 14 depicts a block diagram of an exemplary controller unit 188 according to one embodiment of the present disclosure.
  • the controller unit 188 represents any of the earlier-discussed controller units 18 (FIG. 2) or 148 (FIGs. 11-12).
  • the controller unit or system 188 may be suitably configured— in hardware and/or software— to implement the hands-free fare validation methodology and/or the gateless entry/exit methodology according to the teachings of the present disclosure.
  • the controller unit 188 may include a processor 190 and ancillary hardware to accomplish hands-free fare validation and/or gateless entry/exit discussed before.
  • the processor 190 may be similar to the CPU 30 in FIG. 2.
  • the processor 190 may be configured to interface with a number of external devices.
  • a number of input devices 192 may be part of the system 188 and may provide data inputs—such as user input, camera images, statistical data, and the like— to the processor 190 for further processing.
  • the input devices 192 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.
  • the processor 190 is shown coupled to a system memory 194, a peripheral storage unit 196, one or more output devices 197, and a network interface unit 199.
  • a display screen is an example of an output device 197.
  • the controller unit 188 may include more than one instance of the devices shown. In various embodiments, all of the components shown in FIG. 14 may be housed within a single housing. In other embodiments, the controller unit 188 may not include all of the components shown in FIG. 14. Furthermore, the controller unit 188 may be configured as a standalone system, as a server system, as a client system, or in any other suitable form factor.
  • the controller unit 188 may include more than one processor (e.g., in a distributed processing configuration).
  • processor 190 may be a System on Chip (SoC) and/or may include more than one Central Processing Units (CPUs).
  • SoC System on Chip
  • CPUs Central Processing Units
  • the system memory 194 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.
  • DRAM Dynamic Random Access Memory
  • SRAM Static RAM
  • SDRAM Synchronous DRAM
  • Rambus® DRAM flash memory
  • ROM Read Only Memory
  • the system memory 194 may include multiple different types of semiconductor memories, as opposed to a single type of memory.
  • the system memory 194 may be a non-transitory data storage medium.
  • the peripheral storage unit 196 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.
  • hard drives such as Compact Disks (CDs) or Digital Versatile Disks (DVDs)
  • CDs Compact Disks
  • DVDs Digital Versatile Disks
  • RAM non-volatile Random Access Memory
  • SD Secure Digital
  • USB Universal Serial Bus
  • the peripheral storage unit 196 may be coupled to the processor 190 via a standard peripheral interface such as a Small Computer System Interface (SCSI) interface, a Fibre Channel interface, a Firewire® (IEEE 1394) interface, a Peripheral Component Interface Express (PCI ExpressTM) standard based interface, a USB protocol based interface, or another suitable interface.
  • a standard peripheral interface such as a Small Computer System Interface (SCSI) interface, a Fibre Channel interface, a Firewire® (IEEE 1394) interface, a Peripheral Component Interface Express (PCI ExpressTM) standard based interface, a USB protocol based interface, or another suitable interface.
  • SCSI Small Computer System Interface
  • Fibre Channel interface such as Fibre Channel interface
  • Firewire® (IEEE 1394) interface such as a Peripheral Component Interface Express (PCI ExpressTM) standard based interface
  • USB protocol based interface such as USB protocol based interface
  • Various such storage devices may be non-transitory data storage media.
  • a display screen may be an example of the output device 197.
  • 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.
  • the input device(s) 192 and the output device(s) 197 may be coupled to the processor 190 via an I/O or peripheral interface(s).
  • the network interface unit 199 may communicate with the processor 190 to enable the controller unit 188 to couple to a network or a communication interface. In another embodiment, the network interface unit 199 may be absent altogether.
  • the network interface 199 may include any suitable devices, media and/or protocol content for connecting the controller unit 188 to a network/interface— whether wired or wireless.
  • 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.
  • 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.
  • IP Internet Protocol
  • PSTN Public Switched Telephone Network
  • 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 802.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), an Ethernet connection, and the like.
  • IMS IP Multimedia Subsystem
  • BLE Bluetooth or Bluetooth LE
  • NFC network/interface
  • WiMAX Worldwide Interoperability for Microwave Access
  • IEEE Institute of Electrical and Electronics Engineers
  • IEEE Institute of Electrical and Electronics Engineers
  • IP-based cellular network such as, for example, a Third Generation Partnership
  • the controller unit 188 may include an on-board power supply unit 200 to provide electrical power to various system components illustrated in FIG. 14.
  • the power supply unit 200 may receive batteries or may be connectable to an AC electrical power outlet.
  • the power supply unit 200 may convert solar energy or other renewable energy into electrical power.
  • a non-transitory, computer-readable data storage medium such as, for example, the system memory 194 or a peripheral data storage unit, such as a removable memory, may store program code or software for the FV controller driver 14.
  • the system memory 194 is shown to include such program code.
  • the processor 190 may be configured to execute the program code, whereby the controller unit 188 may be operative to perform various controller-unit specific tasks associated with the hands-free fare validation methodology and/or the gateless entry/exit methodology as per the teachings of the present disclosure.
  • such tasks may include, for example, some or all of the process steps illustrated in any of the FIGs. 4 and 10.
  • Such tasks also may include, for example, relevant controller driver-based operations discussed earlier with reference to FIGs. 5-12.
  • the program code or software may be proprietary software or open source software which, upon execution by the processor 190, may enable the controller unit 188 to perform controller unit-specific operations to support the hands-free fare validation and gateless entry/exit aspects as per teachings of the present disclosure as well as to support other related actions (such as, for example, operating in the maintenance mode).
  • FIGs. 2 and 13-14 can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology.
  • FIGs. 3-4 and 9-10 represent various processes which may be substantially performed by a respective processor (e.g., the processor 180 in FIG. 13 or the processor 190 in FIG. 14, as applicable).
  • 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 (1C), and/or a state machine.
  • DSP digital signal processor
  • ASICs Application Specific Integrated Circuits
  • FPGAs Field Programmable Gate Arrays
  • Some or all of the functionalities described above in the context of FIGs. 1-12 also may be provided by a respective processor 180 or 190, in the hardware and/or software. Any of the processors 180 and 190 may employ distributed processing in certain embodiments.
  • such software or program code may reside in a computer-readable data storage medium.
  • such data storage medium may be part of the peripheral storage 196, or may be part of the system memory 194, or the processor’s 190 internal memory (not shown).
  • such data storage medium may be part of the memory 182 or the processor's 180 internal memory (not shown).
  • the processors 180 and 190 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.
  • controller unit 188 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.
  • 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.
  • 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.
  • 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).
  • functions and illustrated functional blocks are to be understood as being either hardware- implemented and/or computer-implemented, and thus machine-implemented.
  • a user application on a mobile device facilitates hands-free fare validation and gateless entry/exit at a transit facility like a transit station or a transit vehicle.
  • the user application communicates with a Bluetooth gateway to authenticate the device and provides device-specific information for device identification and location determination.
  • the user application also sends a secure token to the gateway to validate an electronic ticket stored in the device.
  • a positioning unit uses the device-specific information to generate a timestamped location data for the device.
  • a camera monitors the device user's movement and generates another timestamped location data for the device.
  • a controller driver compares these two timestamped location data to determine that the user of the device is approaching a gateless entry point and allows the user to avail a transit service through the gateless entry point when the electronic ticket is valid and active.
  • the user can continue walking into a transit vehicle or a pre-designated boarding area for the transit service in a gateless manner. This hassle-free approach may significantly improve the user experience and passenger throughput, especially during peak periods.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système et un procédé dans lesquels une application d'utilisateur d'un dispositif mobile facilite une validation de passe mains libres et une entrée/sortie sans porte au niveau d'un équipement de transit tel qu'une gare de transit ou un véhicule de transit. L'application utilisateur communique avec une passerelle Bluetooth pour authentifier le dispositif et fournit des informations propres au dispositif pour une identification de dispositif et pour une détermination de localisation. L'application d'utilisateur envoie également un jeton sécurisé à la passerelle pour valider un ticket électronique stocké dans le dispositif. Une unité de positionnement utilise les informations propres au dispositif pour générer des données de localisation horodatées pour le dispositif. Une caméra surveille le mouvement de l'utilisateur du dispositif et génère une autre donnée de localisation horodatée pour le dispositif. Un pilote de dispositif de commande compare deux données de localisation horodatées, afin de déterminer que l'utilisateur du dispositif s'approche d'un point d'entrée sans porte, et permet à l'utilisateur d'accéder à un service de transit par l'intermédiaire du point d'entrée sans porte lorsque le ticket électronique est valide et actif.
PCT/US2018/031552 2018-03-21 2018-05-08 Procédés et systèmes de validation de passe mains libres et transit sans porte WO2019182625A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
GB2016588.2A GB2587509B (en) 2018-03-21 2018-05-08 Methods and systems for hands-free fare validation and gateless transit
CA3094302A CA3094302A1 (fr) 2018-03-21 2018-05-08 Procedes et systemes de validation de passe mains libres et transit sans porte
AU2018414521A AU2018414521A1 (en) 2018-03-21 2018-05-08 Methods and systems for hands-free fare validation and gateless transit
AU2023203911A AU2023203911A1 (en) 2018-03-21 2023-06-21 Methods and systems for hands-free fare validation and gateless transit

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/927,305 2018-03-21
US15/927,305 US20180211188A1 (en) 2015-08-17 2018-03-21 Methods and systems for hands-free fare validation and gateless transit

Publications (1)

Publication Number Publication Date
WO2019182625A1 true WO2019182625A1 (fr) 2019-09-26

Family

ID=67987477

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2018/031552 WO2019182625A1 (fr) 2018-03-21 2018-05-08 Procédés et systèmes de validation de passe mains libres et transit sans porte
PCT/US2018/056829 WO2019182646A1 (fr) 2018-03-21 2018-10-22 Fusion de capteurs destinée à des applications de transport

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/US2018/056829 WO2019182646A1 (fr) 2018-03-21 2018-10-22 Fusion de capteurs destinée à des applications de transport

Country Status (4)

Country Link
AU (4) AU2018414521A1 (fr)
CA (2) CA3094302A1 (fr)
GB (2) GB2587509B (fr)
WO (2) WO2019182625A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111769885B (zh) 2020-06-29 2022-02-11 北京小米移动软件有限公司 一种超声数据传输方法、装置、系统、终端设备及介质
CN112530154B (zh) * 2020-11-13 2022-07-01 北京小米移动软件有限公司 信息传输方法、信息传输装置、以及电子设备
SI26249A (sl) * 2021-09-07 2023-03-31 Margento R&D D.O.O Pametni sistem za avtomatsko validacijo in obveščanje
CN115018511B (zh) * 2022-03-04 2024-07-09 浪潮工业互联网股份有限公司 一种用于农用机械的防伪方法、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8457354B1 (en) * 2010-07-09 2013-06-04 Target Brands, Inc. Movement timestamping and analytics
US20140086125A1 (en) * 2012-09-24 2014-03-27 Broadcom Corporation Enhanced rate physical layer for bluetooth™ low energy
WO2016105322A1 (fr) * 2014-12-25 2016-06-30 Echostar Ukraine, L.L.C. Visualisation simultanée d'angles de prise de vue multiples
US20170055157A1 (en) * 2015-08-17 2017-02-23 Bytemark, Inc. Short range wireless translation methods and systems for hands-free fare validation

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5797330A (en) * 1996-07-31 1998-08-25 Li; Zhengzhong Mass transit system
US6697730B2 (en) * 2000-04-04 2004-02-24 Georgia Tech Research Corp. Communications and computing based urban transit system
FR2953476B1 (fr) * 2009-12-03 2015-04-24 Denis Creissels Consultant Telepherique avec controle du nombre admissible de passagers en cabine
RU94931U8 (ru) * 2009-12-28 2014-02-27 Общество с ограниченной ответственностью Научно Производственное Предприятие "Циркон Сервис" Система учета фактического количества пассажиров в пассажирском вагоне
US10453067B2 (en) * 2011-03-11 2019-10-22 Bytemark, Inc. Short range wireless translation methods and systems for hands-free fare validation
WO2016029168A1 (fr) * 2014-08-21 2016-02-25 Uber Technologies, Inc. Organisation d'un service de transport pour un utilisateur d'après le temps d'arrivée estimé de l'utilisateur

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8457354B1 (en) * 2010-07-09 2013-06-04 Target Brands, Inc. Movement timestamping and analytics
US20140086125A1 (en) * 2012-09-24 2014-03-27 Broadcom Corporation Enhanced rate physical layer for bluetooth™ low energy
WO2016105322A1 (fr) * 2014-12-25 2016-06-30 Echostar Ukraine, L.L.C. Visualisation simultanée d'angles de prise de vue multiples
US20170055157A1 (en) * 2015-08-17 2017-02-23 Bytemark, Inc. Short range wireless translation methods and systems for hands-free fare validation

Also Published As

Publication number Publication date
WO2019182646A1 (fr) 2019-09-26
CA3105335A1 (fr) 2019-09-26
AU2023203911A1 (en) 2023-07-13
AU2018414542A1 (en) 2020-10-08
CA3094302A1 (fr) 2019-09-26
GB2586929A (en) 2021-03-10
AU2023204670B2 (en) 2024-08-15
GB202016588D0 (en) 2020-12-02
GB2587509A (en) 2021-03-31
GB202016577D0 (en) 2020-12-02
AU2023204670A1 (en) 2023-08-03
GB2587509B (en) 2023-01-11
AU2018414521A1 (en) 2020-10-08

Similar Documents

Publication Publication Date Title
US12108252B2 (en) Short range wireless translation methods and systems for hands-free fare validation
US20180211188A1 (en) Methods and systems for hands-free fare validation and gateless transit
US11803784B2 (en) Sensor fusion for transit applications
US10453067B2 (en) Short range wireless translation methods and systems for hands-free fare validation
AU2023204670B2 (en) Sensor fusion for transit applications
US20180061145A1 (en) Parking space management system and method
CA3063582A1 (fr) Antenne reseau a commande de phase a faisceaux multiples permettant un acces en transit
CN104769972A (zh) 在不进行网络下载的情况下获得地理围栏
US20210304210A1 (en) Information processing method, information processing system, and information processing apparatus
EP3338253B1 (fr) Procédés de traduction sans fil à courte portée et systèmes pour validation de tarif de transport mains libres
JP6375139B2 (ja) 無線周波数識別通知システム
EP3603037B1 (fr) Procédés de translation sans fil à courte portée et systèmes de validation de tarif de voyage mains libres
CN111665727A (zh) 用于控制家居设备的方法、装置和家居设备控制系统
KR20160023983A (ko) 비콘을 이용한 택시 이용 서비스 시스템
WO2019060738A1 (fr) Validation de jeton biométrique inverse crypté
AU2017268497A1 (en) Parking space management system and method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18911080

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3094302

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018414521

Country of ref document: AU

Date of ref document: 20180508

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 202016588

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20180508

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 18/12/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18911080

Country of ref document: EP

Kind code of ref document: A1