Note: Descriptions are shown in the official language in which they were submitted.
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
METHODS AND SYSTEMS FOR HANDS-FREE FARE VALIDATION
AND GATELESS TRANSIT
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of and claims the
priority benefit under
35 U.S.C. 120 of the United States Patent Application No. 15/228,232 filed on
August 4,
2016, which claims the priority benefit under 35 U.S.C. 119(e) of U.S.
Provisional
Application No. 62/206,196 filed on August 17, 2015, the disclosures of both
of these
applications are incorporated herein by reference in their entireties. This
application is also
a continuation-in-part of and claims the priority benefit under 35 U.S.C. 120
of the United
States Patent Application No. 15/692,503 filed on August 31, 2017.
TECHNICAL FIELD
[0002] 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).
BACKGROUND
[0003] Many transit stations, such as train platforms or bus terminals,
routinely employ
automatic fare validation (or ticket validation) systems to improve user
experience and
increase the throughput of passengers through, for example, fare gates to and
from the
train platforms. Modern technical advances, such as smartcards, two-
dimensional (2D)
barcodes, and Near Field Communication (NFC) capable mobile devices, have
reduced
passenger ingress and egress time through fare gates. Smartcards can be either
contact or
contactless, and can provide personal identification, authentication, data
storage, and
application processing. NFC-enabled portable devices can be provided with
apps, for
example, to read electronic tags or make a transaction when connected to an
NFC-
compliant apparatus.
1
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
SUMMARY
[0004] Although the above-mentioned technical advances have reduced
passenger
ingress and egress times through fare gates, passenger throughput is still
hampered by
passengers having to search for their smartcards or getting out their mobile
phones (for
example, to establish an NFC contact).
[0005] It is therefore desirable to improve the process of automated fare
validation and
to also improve the passenger throughput through a fare gate at a transit
station. It is
further desirable to perform ticket validation "hands free" and, in a gateless
environment, to
facilitate gateless entry/exit for a transit service in an automated, hands-
free manner.
[0006] As a solution, particular embodiments of the present disclosure
provide for a
hands-free process of automated fare validation and gateless entry/exit. In
particular
embodiments, the Bluetooth technology may be used in conjunction with a user
application
on a mobile device to facilitate such hands-free operations. In one
embodiment, the
solution may comprise a mobile app for the passenger and an add-on box that
interfaces to
a compliant fare gate. Bluetooth beacons may be used to determine a
passenger's
proximity to the gate and camera-like devices may interface to the add-on box
to determine
whether a passenger (perhaps without a smartphone) has entered the fare gate.
According
to particular embodiments of the present disclosure, a user with a valid
ticket may simply
walk through the fare gate "hands free" without the need to search for a
physical ticket or a
smartcard or a mobile phone. This hassle-free approach may significantly
improve the user
experience and passenger throughput through fare gates. In another embodiment,
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.
[0007] The Bluetooth LE-based automated fare validation system as per
teachings of
particular embodiments of the present disclosure may detect and provide
feedback to the
passenger, when the passenger enters into a "Paid Area" with a valid
electronic ticket
(which may be stored in the passenger's mobile device). A controller as per
teachings of
the present disclosure may also detect when a passenger, with a mobile ticket
previously
activated, exits from the Paid Area. Furthermore, in some embodiments, the
system may
2
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
detect, and provide external visual and audio alerts, when a passenger enters
into the Paid
Area without a valid permit for travel. The system may also detect, and
provide external
visual and audio alerts, when a passenger attempts to exit from the Paid Area
without a
valid permit for travel. Overall, passenger throughput into and out of the
Paid Area may be
increased, especially during peak periods, using the hands-free ticket
validation and
gateless entry approaches disclosed herein.
[0008] In one embodiment, 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; and (v)
informing the user to avail the transit service through the gateless entry
location. In one
embodiment, the Bluetooth interface may be a Bluetooth LE interface.
[0009] In another embodiment, 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
3
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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 gateless entry point for the transit
service; and (vii)
allowing the user to avail the transit service through the gateless entry
point. In one
embodiment, the Bluetooth interface may be a Bluetooth LE (BLE) interface.
[0010] In a further embodiment, 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. In the mobile device,
the
processor is operable to execute the program instructions, which, when
executed by the
processor, cause the mobile device to perform the following to facilitate
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
mobile device for the transit service; and (e) inform the user to avail the
transit service
through the entry location. In one embodiment, the Bluetooth interface may be
a BLE
interface. In another embodiment, the entry location may be a gateless entry
location. In a
further embodiment, the entry location may be a gated entry location.
[0011] In yet another embodiment, the present disclosure is directed to a
system to
facilitate entry for a transit service when a user carrying a mobile device
approaches a
4
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. In the system, 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.
In the system, 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. Furthermore, in the system, 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. In one embodiment, the Bluetooth interface may be a BLE
interface. The entry
point may be a gateless entry point or a gated entry point.
[0012] The mobile device and the controller unit may perform various
operational
aspects briefly mentioned above and further discussed in more detail later
below.
[0013] Thus, the Bluetooth-based fare validation methodology as per
teachings of the
present disclosure may improve the passenger throughput through a fare gate by
allowing
the passenger to simply walk through the fare gate "hands free" so long as
they have a
valid, active ticket on their mobile device. Furthermore, 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.
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] In the following section, the present disclosure will be described
with reference to
exemplary embodiments illustrated in the figures, in which:
[0015] FIG. 1 illustrates constituent components of a Fare Validation (FV)
application
according to an exemplary embodiment of the present disclosure;
[0016] FIG. 2 depicts an exemplary system for implementing the FV
application
according to one embodiment of the present disclosure;
[0017] FIG. 3 shows an exemplary flowchart illustrating a mobile device-
based hands-
free fare validation methodology according to one embodiment of the present
disclosure;
[0018] FIG. 4 shows an exemplary flowchart illustrating a controller unit-
based hands-
free fare validation methodology according to one embodiment of the present
disclosure;
[0019] 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;
[0020] 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;
[0021] FIG. 7 is an exemplary context diagram for the FV user application
in FIG. 1
according to particular embodiments of the present disclosure;
[0022] FIG. 8 shows an exemplary context diagram for the FV controller
driver in FIG. 1
according to particular embodiments of the present disclosure;
[0023] FIG. 9 shows an exemplary flowchart illustrating a mobile device-
based gateless
entry methodology according to one embodiment of the present disclosure;
[0024] FIG. 10 shows an exemplary flowchart illustrating a control unit-
based gateless
entry methodology according to one embodiment of the present disclosure;
[0025] 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;
[0026] 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;
6
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0027] FIG. 13 is a block diagram of an exemplary mobile device according
to one
embodiment of the present disclosure; and
[0028] FIG. 14 depicts a block diagram of an exemplary controller unit
according to one
embodiment of the present disclosure.
DETAILED DESCRIPTION
[0029] In the following detailed description, numerous specific details are
set forth in
order to provide a thorough understanding of the disclosure. However, it will
be understood
by those skilled in the art that the present disclosure may be practiced
without these
specific details. In other instances, well-known methods, procedures,
components and
circuits have not been described in detail so as not to obscure the present
disclosure.
[0030] Reference throughout this specification to "one embodiment" or "an
embodiment"
means that a particular feature, structure, or characteristic described in
connection with the
embodiment is included in at least one embodiment of the present disclosure.
Thus, the
appearances of the phrases "in one embodiment" or "in an embodiment" or
"according to
one embodiment" (or other phrases having similar import) in various places
throughout this
specification are not necessarily all referring to the same embodiment.
Furthermore, the
particular features, structures, or characteristics may be combined in any
suitable manner
in one or more embodiments. Also, depending on the context of discussion
herein, a
singular term may include its plural forms and a plural term may include its
singular form.
Similarly, a hyphenated term (e.g., "hands-free," "hassle-free", etc.) may be
occasionally
interchangeably used with its non-hyphenated version (e.g., "hands free,"
"hassle free",
etc.), and a capitalized entry (e.g., "Fare Validation Application," "Fare
Gate," "Controller
Unit," etc.) may be interchangeably used with its non-capitalized version
(e.g., "fare
validation application," "fare gate," "controller unit," etc.). Such
occasional interchangeable
uses shall not be considered inconsistent with each other.
[0031] It is noted at the outset that the terms "coupled," "operatively
coupled,"
"connected", "connecting," "electrically connected," etc., are used
interchangeably herein to
generally refer to the condition of being electrically/electronically
connected in an operative
manner. Similarly, a first entity is considered to be in "communication" with
a second entity
(or entities) when the first entity electrically sends and/or receives
(whether through wireline
7
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
or wireless means) information signals (whether containing address, data, or
control
information) to/from the second entity regardless of the type (analog or
digital) of those
signals. It is further noted that various figures (including component
diagrams) shown and
discussed herein are for illustrative purpose only, and are not drawn to
scale.
[0032] The terms "first," "second," etc., as used herein, are used as
labels for nouns that
they precede, and do not imply any type of ordering (e.g., spatial, temporal,
logical, etc.)
unless explicitly defined as such. Furthermore, items or features appearing in
different
figures may be identified using the same reference numeral for ease of
discussion.
However, such identification does not imply that the commonly-referenced
items/features
are identical across all embodiments.
[0033] 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
according to
one embodiment of the present disclosure 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. 2) with each other, and
may together
provide the hands-free fare validation and gateless entry/exit functionalities
as discussed
later below. It is noted here that, for ease of discussion, a computer
software, program
code or module may be referred to as "performing," "accomplishing," or
"carrying out" a
function or process. However, it is evident to one skilled in the art that
such performance
may be technically accomplished by a processor when the software or program
code is
executed by the processor. The program execution would cause the processor to
perform
the tasks or steps instructed by the software to accomplish the desired
functionality or
result. However, for the sake of convenience, in the discussion below, a
processor or
software component may be referred to interchangeably as an "actor" performing
the task
or action described, without technically dissecting the underlying software
execution
mechanism.
8
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0034] It is noted here that the embodiments in FIGs. 2-8 relate to the BLE-
based
hands-free fare validation methodology, whereas the embodiments in 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. Thus, no discussion of
gateless
entry/exit aspect is provided in the context of description of FIGs. 2-8
below. Similarly, no
discussion of 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.
Furthermore, the
configurations in the embodiments of FIGs. 9-12 allow for additional fraud
detection for
gateless systems.
[0035] 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. As discussed later below, 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. It is noted here that the terms "mobile device," "mobile
handset," "wireless
handset," and "User Equipment (UE)" may be used interchangeably hereinbelow to
refer to
a wireless communication device that is capable of voice and/or data
communication.
Some examples of such mobile handsets include cellular telephones or data
transfer
equipments, tablets, and smartphones (e.g., iPhoneTM, Android 1M,
BlackberryTm, etc.). In
certain embodiments, such as, for example, the embodiments in FIGs. 9-12, a
BLE tag may
be considered a "mobile device" or "mobile handset" as mentioned later below.
It is
observed here that, for ease of discussion, 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. In another
embodiment, the
functionality of the controller unit 18 may be accomplished using multiple
different units.
9
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0036] As shown in FIG. 2, 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., Symbian TM OS, Palm TM OS, Windows Mobile TM ,
Android 1M,
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. 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. 2,
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. In particular
embodiments, 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.
[0037] It is noted here that the 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. Thus,
although the discussion below may frequently refer to a BLE interface, it is
understood that
such discussion remains applicable to other Bluetooth technologies as well,
such as, for
example, the Bluetooth technologies that comply with one or more Bluetooth
Special
Interest Group (SIG) standards. The hands-free fare validation solution as per
teachings of
the present disclosure may be implemented using a number of Bluetooth
specifications,
including BLE. Hence, the usage of the terms "BLE" or "Bluetooth LE" in the
discussion
below should be considered as a representative of (and inclusive of) the more
general term
"Bluetooth" or other non-BLE based Bluetooth technologies. Additionally, in
certain
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
embodiments, the Bluetooth-based proximity detection discussed below may be
modified
such that proximity may be detected using Bluetooth in conjunction with WiFi
and/or cellular
data connections, or some combination thereof. Thus, for example, a hybrid
approach to
proximity detection may use both WiFi and Bluetooth to detect where a person
is at. The
Bluetooth-based discussion below encompasses such variations and combinations,
but
each such hybrid approach is not discussed in detail for the sake of brevity.
[0038] In the embodiment of FIG. 2, 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.). In addition to the controller driver 14, 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. Thus, in operation, 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. In particular embodiments, 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. It is observed here that, in particular embodiments, 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.
11
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0039] 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. Initially, the mobile device 17 may receive a Bluetooth beacon signal
(block 42). As
discussed later, specific Bluetooth beacon signals may be transmitted as per
teachings of
the present disclosure for locating the presence of a passenger in the fare
validation zone
(also referred to below as "fare gate trigger zone"). Thus, based on the
received beacon
signal, the mobile device 17 may determine that it is in the fare validation
zone (block 43).
In some embodiments, the mobile device can determine the proximity of a fare
gate trigger
zone based on geofence(s) and GPS data. At block 45, 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. At block
46, 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. In
response, at block 47, 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. Thus, the ticket submission and ticket
validation operations
may be performed without user involvement; a passenger is not required to
search for their
smartcards or mobile phones to validate their tickets.
[0040] 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. Initially, at block 52, the controller unit 18 may receive a
notification that the user
has entered the fare validation zone. In one embodiment, such notification may
be received
from a "people counting" device such as, for example, a digital camera,
connected to the
controller unit 18 as discussed later with reference to FIG. 5. At block 53,
the controller unit
18 may identify the mobile device carried by the user¨such as the mobile
device 17-
12
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. At block 58, 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. In other words, a passenger is not
required to
search for his/her smartcard or mobile phone to validate his/her ticket; the
passenger can
simply continue walking towards the entry gate because of the hands-free
validation of the
ticket through the interactions between the controller unit 18 and the
passenger's mobile
device 17.
[0041] 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. Prior to discussing the operational aspects of the
system
components in FIG. 5, a brief overview of exemplary hardware features of these
components is provided.
[0042] In particular embodiments, 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 i0S-
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 (UI) to facilitate various
tasks in support
of the hands-free fare validation. Such tasks may include, for example,
purchase of an
13
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
[0043] In particular embodiments, 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 ArduinoTM
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. It is noted here that, in certain
embodiments,
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. Generally, the number of
controller units or
beacon transmitters (wake-up beacons or gate beacons) may be implementation-
specific.
[0044] 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. In particular embodiments, the wake-up beacon 62 may provide
Bluetooth LE
(BLE) (or other type of Bluetooth) beacon signals using an omnidirectional
antenna (not
shown). The beacon signals transmitted by the transmitter 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 Android TM systems.
Thus, for
iBeacon compatibility, for example, 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. The UUID may be used to uniquely
identify an
object¨for example, the beacon transmitter 62¨across the internet. 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.
14
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0045] As noted above, a UUID is a unique number. With regard to BLE, each
service
may be represented by a UUID. The 16-bit standardized BLE UUlDs allow for
65536
unique services. 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 UUlDs for various
"services"
may be obtained at
https://developer.bluetooth.org/gatt/services/Pages/ServiceHome.aspx.
Although UUlDs are normally fixed, they may be dynamic in certain
implementations.
[0046] 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. In particular embodiments, a Bluetooth Beacon is usually
incapable of
receiving data. The Beacon ID may provide transmitter-specific identification
information
that the mobile operating system 24 may use to recognize the Bluetooth Beacon.
For
iBeacons, for example, the Beacon ID is the UUID along with the major and
minor
numbers. It is observed here that the Bluetooth LE (also referred to as
"Bluetooth Smart") is
a wireless communication protocol that permits short range (up to 30 meters)
communications. Bluetooth LE functionality is found on many smartphones and
tablets.
[0047] The beacons may be used for determining proximity of a mobile device
to a
particular location. Each beacons normally has a fixed ID, but, in certain
implementations, a
beacon can have a dynamic ID. With regard to Beacon IDs, the mobile device may
read all
of the beacon IDs transmitted in its vicinity. In certain embodiments, the
beacon data (such
as Beacon ID), signal strength of the received beacon, and a timestamp value
(associated
with the received beacon) may be forwarded¨such as, for example, by the user
app 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. Thus, in particular
embodiments, 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. In
some other embodiments, 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,
Android TM, and other mobile operating systems.
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0048] 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. 5, two Gate Beacons are shown using
reference
numerals "64" and "65". Based upon the field conditions or to improve
accuracy, more gate
beacons may be installed as well. Operationally, the 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.
[0049] In one embodiment, all Bluetooth communications between various
entities in
FIG. 5 may conform to the standards set forth in the Bluetooth Core
Specification 4.2.
[0050] 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. In one
embodiment, the
"people counting" devices may include stereoscopic digital Infrared (IR)
cameras. In some
embodiments, 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.
In other
embodiments, there may be an Ethernet-based connectivity between the
controller unit 18
and the "people counting" devices 67-68. Furthermore, to prevent "tailgating,"
the devices
67-68 may be configured to distinguish between one person and more than one
person in
the fare gate trigger zone.
[0051] 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.
One fare gate is shown in FIG. 5 by way of an example. Many transit stations
may have
multiple such fare gates. In one embodiment, a fare gate may be a physical
access barrier
that is intended to permit only properly-ticketed passengers through into the
"Paid Area,"
which may be a secured area that is designated for paying passengers. In one
embodiment, the fare gate 70 may be directly connected to the controller unit
18 via an
Ethernet interface 72. In some embodiments, a standard Power Over Ethernet
(POE)
switch (or hub) may be used to facilitate multiple Ethernet connections or
field conditions. A
standard RJ-45 connector may be used to provide the Ethernet-based network
connectivity
between the controller unit 18 and the fare gate 70. In certain embodiments,
the fare gate
16
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
may be a virtual barrier, such as, for example, in case of a bus where such a
virtual barrier
may be used in conjunction with a controller unit as per teachings of the
present disclosure
to afford hands-free entry to the passengers wishing to board the bus. In
other words, the
physical barrier-based illustration in FIG. 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.
[0052] On the other hand, in some embodiments, the controller unit 18 may
use an NFC
interface 74 to initiate a transaction with the fare gate 70. However, as
noted before, an
NFC interface may not support a fully hands-free transaction. An NFC interface
may be
primarily used where, for business or technical reasons, a fare gate that
supports NFC
cannot be easily modified to support direct connectivity with the controller
unit 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. Hence, the NFC interface 74 is
shown
dotted in FIG. 5. It is observed that, in particular embodiments, there may be
two NFC
interfaces associated with the entry gate system 70¨an NFC interface 76 at the
entrance
of the "Paid Area" and an NFC interface 77 at the exit from the "Paid Area."
In one
embodiment, 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).
[0053] On the hardware side, 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. In one
embodiment, 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. Furthermore, in certain
embodiments, the
fare gate 70 may have an "Enter" indicator on its entry side and a "Don't
Enter" indicator on
its exit side.
[0054] Although not shown in FIG. 5, the transit station 60 may also have
one or more
remote displays¨for example, displays hanging over the fare gate entrance and
exit. When
17
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
passengers are moving quickly through a fare gate, these displays provide
visual feedback
to the users, such as, for example, a confirmation that their electronic
ticket is valid and
accepted and, hence, they should continue moving to the transit terminal or
"Paid Area." In
particular embodiments, these remote displays may serve as user interfaces to
allow the
fare gate to indicate both normal and exceptional operating conditions to
passengers and
station personnel. For example, the remote display may have the ability to
display a
message when there is a valid transaction and accompany the message with a
"valid
transaction" sound. Similarly, the fare gate-affiliated user interface may
have the ability to
display a message when there is an invalid transaction attempt (such as, for
example,
submission of an invalid or expired ticket) and accompany the message with an
"invalid
transaction" sound. In some embodiments, the remote displays may have the
ability to
indicate the direction in which the fare gate is operating. For example, an
"Entry" gate may
have a red indicator visible from the "Paid Area" side and a blue or green
indicator may be
visible from the "Unpaid Area" side. The "paid" and "unpaid" areas are shown
in the
exemplary illustration of FIG. 6.
[0055] In the embodiment of FIG. 5, a transaction logger or backend system
80 is
shown to be in wireless communication with the entry gate system 70. In one
embodiment,
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 (discussed
later) may be
logged in the transaction logger 80, for example, for statistical analysis,
record-keeping,
and Operations and Maintenance (O&M) activity. In certain embodiments, the
entry gate
system 70 may communicate with the back-end system 80 using a wired
connection.
[0056] In particular embodiments, 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.
[0057] In the mobile ticketing mode, 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
18
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. In one embodiment, 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. In certain
embodiments,
the user may need to setup an online account with the transit service operator
for automatic
billing and payment facility, as well as for recurring ticket purchases. For
the sake of
present discussion, additional details of ticket generation, purchase, and
delivery are not
relevant and, hence, such details are not provided.
[0058] In the fare gate transaction mode, 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. Thus, the fare gate transaction
mode may
facilitate hands-free fare validation. In one embodiment, if the user account
information is
stored in a remote Host Operator or Processing System (HOPS), such as, for
example, the
backend system 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.
[0059] In one embodiment, 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
19
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. In one embodiment, based on the
identified
beacon ID (received from the wake-up beacon 62), the user app 12 may activate
the
hands-free fare validation feature in the mobile device 17. In response to
determining that
the mobile device 17 is in or near the fare gate trigger zone (the fare
validation zone), 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. When a ticket is accepted by
the fare gate,
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.
[0060] In one embodiment, 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. Instead of or in addition to such
visible
notification, 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.
[0061] In particular embodiments, 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
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
allowed to place the controller unit 18 in the appropriate mode of operation.
In certain
embodiments, the maintenance mode may be omitted.
[0062] In the transit control mode, 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. As part of the fare validation transaction, the
controller driver
14 may be able to detect the entry of a passenger into the fare validation
zone. In one
embodiment, 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. Furthermore,
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). In response, 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. As noted
before, 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. Upon
receiving a confirmation message from the entry gate system 70, 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. On the other hand, if the submitted ticket is not accepted by the fare
gate 70¨for
example, if the ticket is invalid or expired, 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.
[0063] 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.
21
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0064] In the maintenance mode, 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.
In the
maintenance mode, 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.
[0065] 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. 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.
[0066] To aid the transit service administrators, the controller driver 14
may keep
statistics in any mode of operation. However, in particular embodiments, the
statistics may
be displayed only when in the Display Statistic sub-mode. The statistical
information that
may be displayed include, for example: (i) operational statistics, (ii) a
count of the number
of passengers entering through the fare gate into the "Paid Area" with a valid
ticket while in
the "Open Gate" mode (discussed later), (iii) a count of the number of
passengers entering
through the fare gate into the "Paid Area" with a valid ticket while in the
"Closed Gate"
mode (discussed later), (iv) a count of the number of passengers entering
through the fare
gate into the "Paid Area" without a valid ticket while in the "Open Gate"
mode, (v) a count of
the number of passengers entering through the fare gate into the "Paid Area"
without a
valid ticket while in the "Closed Gate" mode, (vi) a count of the number of
passengers
exiting through the fare gate into the "Unpaid Area" while in the "Open Gate"
mode, and
(vii) a count of the number of passengers exiting through the fare gate into
the "Unpaid
Area" while in the "Closed Gate" mode. All statistical counts may be reset to
zero.
[0067] It is observed here that the fare gate 70 may be setup either has an
"Entry" gate
or an "Exit" gate. Thus, the maintenance personnel may need to indicate the
"direction" of
22
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
the fare gate (for example, an "Entry" gate or an "Exit" gate) to the
controller driver 14.
Furthermore, in certain embodiments, 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.
[0068] 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.
Broadly, 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. By way of an illustration, the fare
gate 70 is shown as
a dotted block in FIG. 6. As shown in the exemplary illustration of 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. In contrast, when a user's
electronic
ticket submission is accepted by the fare gate system 70 as discussed before,
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).
[0069] The fare gate 70 may be operated in an "open gate" mode or in a
"closed gate"
mode. In the "open gate" mode, the fare gate 70 may be a barrier-less system.
For
example, during peak hours when the passenger volume warrants the presence of
inspectors (or other service personnel) at the transit station 60, the fare
gate (physical)
barriers may be left open and the passengers may pass through the gates
quickly in a
single file. A remote sign for each fare gate may display a message,
accompanied by an
audible alert, informing the user and the inspectors should the user not have
a valid or
detectable ticket. However, during off-peak times when the availability of
inspectors is
decreased and the passenger volume does not hinder throughput, the fare gate
barriers
may be closed (or brought back in their place), thereby operating the fare
gate 70 in the
"closed gate" mode.
[0070] In certain embodiments, there may be four different transit
situations: (1) A user
enters the "paid area" 88 when the fare gate 70 is in the "open gate" mode,
(2) a user
enters the "paid area" 88 when the fare gate 70 is in the "closed gate" mode,
(3) a user
exits from the "paid area" 88 when the fare gate 70 is in the "open gate"
mode, and (4) a
23
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
user exits from the "paid area" 88 when the fare gate 70 is in the "closed
gate" mode.
Various operations discussed below with reference to these transit situations
are exemplary
in nature, and may be accomplished through interaction between the mobile
device-based
FV user app 12 and the controller unit-based FV controller driver 14, as well
as the
controller driver's further interaction with other devices/systems¨such as,
for example, the
"people counting" devices, the entry gate system, and the like¨at the transit
station 60. In
view of the earlier discussion of FIGs. 1-6, additional details of such device-
to-device
interactions or communication are not provided below.
(1) Entry in the "Open Gate" mode: Initially, the user with the mobile
device 17
may approach the fare gate 70 that is open for entry (for example, "Entry OK"
indicator
lights are lit on the Unpaid Area side 87).
If the user has a valid ticket, the user may simply walk through the gate
hands-free
and the remote display (not shown) may show a message indicating that a valid
ticket was
tendered and a "Ticket Accepted" beep may be emitted from the fare gate's
speakers (not
shown). The user's mobile device 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.
If the user's mobile device does not have the FV User Application¨like the
User App
12 in FIG. 1¨loaded, then, upon entering the Fare Gate Trigger Zone 85, 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.
On the other hand, if the user app is loaded on the user's mobile device, but
there is
no ticket or no valid ticket stored in the device, the remote display may show
a "No Ticket
Available" message and the Fare Gate speakers may emit the "No Ticket
Available" alert
sound. The user may also receive a notification on the mobile device
indicating that no val-
id tickets were available, accompanied by the corresponding audible alert and
vibration pat-
tern.
24
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
In particular embodiments, altering of the user's cadence, such as, for
example,
pausing to let the person ahead go through the fare gate before proceeding,
may be nec-
essary in the Open Gate mode.
(2) Entry in the "Closed Gate" mode: Initially, the user with the mobile
device 17
may approach the fare gate 70 that is open for entry (for example, "Entry OK"
indicator
lights are lit on the Unpaid Area side 87).
If the user has a valid ticket, as the user enters the Fare Gate Trigger Zone
85, 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.
If the user's mobile device does not have the FV User Application¨like the
User App
12 in FIG. 1¨loaded, then, upon entering the Fare Gate Trigger Zone 85, 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.
On the other hand, if the user app is loaded on the user's mobile device, but
there is
no ticket or no valid ticket stored in the device, the remote display may show
a "No Ticket
Available" message and the Fare Gate speakers may emit the "No Ticket
Available" alert
sound. The user may also receive a notification on the mobile device
indicating that no val-
id tickets were available, accompanied by the corresponding audible alert and
vibration pat-
tern.
(3) Exit in the "Open Gate" mode: Initially, the user with the mobile
device 17 may
approach the fare gate 70 that is open for exiting (for example, "Entry OK"
indicator lights
are lit on the Paid Area side 88).
If the user's mobile device has the FV user application loaded with a valid,
active
ticket, the user may simply walk through the fare gate and the remote display
may show,
for example, a "Thanks for Traveling with Us" message. The user's mobile
device may also
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
display a notification indicating that he or she has exited the system (or
transit terminal).
The mobile device may also emit an "Exiting" beep and a corresponding
vibration pattern.
On the other hand, if the user's mobile device does not have the FV user app
loaded
(or has it loaded but without a valid, active ticket) and if the user enters
the Fare Gate Trig-
ger Zone, a message on the remote display may remind the user to use
traditional media to
"swipe out" for exit (if this is required by the transit service operator).
This may be accom-
panied by a loud "Invalid Entry Attempt" alert through the Fare Gate's
speakers. In some
embodiments, 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).
(4)
Exit in the "Closed Gate" mode: Initially, the user with the mobile device
17
may approach the fare gate 70 that is open for exiting (for example, "Entry
OK" indicator
lights are lit on the Paid Area side 88).
If the user's mobile device has the FV user application loaded, as the user
enters the
Fare Gate Trigger Zone, the gate's barrier may open and the user may walk
through the
gate to exit. The remote display may show a "Thanks for 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.
On the other hand, if the user's mobile device does not have the FV user app
loaded
and if the user enters the Fare Gate Trigger Zone, a message on the remote
display may
remind the user to use traditional media to "swipe out" for exit (if this is
required by the
transit service operator). In particular embodiments, the fare gate's barrier
may remain
closed until a valid ticket (electronic or traditional) is presented. In some
embodiments, this
kind of processing may also occur if the user's mobile device is not turned on
(whether
turned off by the user or as a result of a dead battery).
[0071]
It is noted that, typically, 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. For example, the gate 70 may be set in one
direction in the
26
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
morning as an "Entry" gate and as an "Exit" gate in the afternoon. However, if
needed, the
controller driver 14 may be configured to dynamically determine the direction
of the gate
based upon the direction of passenger movement. In certain embodiments,
additional
hardware (not shown), such as, for example, motion sensors or cameras, may be
provided
at the transit station 60 to assist the controller driver 14 in detection of
such direction.
Alternatively, 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.
[0072] In some embodiments, 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. Furthermore, 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. In certain embodiments, 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.
[0073] 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. For ease
of discussion, FIGs. 7-8 are discussed together and the entities common
between FIGs. 5
and 7-8 are identified using the same reference numerals. Furthermore, because
of the
earlier detailed discussion of various operational aspects of the FV user app
12 and the FV
controller driver 14, only a brief description of the data and control flows
shown in FIGs. 7-8
is provided. In the embodiments of FIGs. 7-8, solid arrows depict data flows
and dashed
arrows depict control flows. Furthermore, in FIGs. 7-8, blocks with solid
lines¨such as the
27
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
blocks 97-98¨depict external interfaces, whereas blocks with dashed lines¨such
as the
blocks 62 and 70¨depict internal sub-system interfaces.
[0074] Referring now to FIGs. 7-8, 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. On the
other hand, 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. In FIG. 7, 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. On the other
hand, 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.
[0075] Referring now to FIG. 8, 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.
[0076] If 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
28
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
with the controller driver 14 via the NFC interface 74. In certain
embodiments, there may be
individual NFC readers/writers for the entrance NFC interface 76 and the exit
NFC interface
77 in FIG. 5. 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, and the
"NFC
Control" is the control information associated with the NFC reader/writer 102
to facilitate
various NFC-based transactions. In some embodiments, in addition to the NFC
reader 102,
there may be a barcode scanner (not shown) and a magnetic stripe reader (not
shown) in
communication with the controller driver 14 via a suitable interface.
[0077] If the controller driver 14 supports the earlier-discussed
maintenance mode, 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. In that regard, 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, and the "Maint. User Control" is the control information
sent to the
controller driver 14 when in the maintenance mode.
[0078] Prior to discussing the embodiments in FIGs. 9-12, it is noted here
that a BLE tag
may be considered a "mobile device" or "mobile handset" usable in the
embodiments of
FIGs. 9-12, as mentioned earlier. In the context of FIGs. 9-12, a BLE tag may
operate in a
manner similar to a mobile device such as a UE or a cell phone. For example,
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. Thus, although the discussion of 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
29
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
[0079] 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.
It is noted
that, 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.
Depending on the
desired application, the user app 12 may be configured to support gateless
entry/exit with
or without the hands-free fare validation functionality. The operational tasks
shown in FIG.
9 may be performed by a mobile device 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 the mobile
device approaches a transit facility for the transit service. As discussed
later, the transit
facility may be a transit station or a transit vehicle itself.
[0080] Initially, at block 110, the mobile device 17 may determine that it
is in proximity of
a gateless entry location for a transit service. As discussed in more detail
later, in the
context of the embodiments in FIGs. 9-12, the term "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. However, in
particular embodiments, these terms may be synonymous and may be
interchangeably
used. At block 112, 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. As discussed later, 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). In one embodiment, the gateway unit itself may
authenticate
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
the mobile device. In other embodiments, two or more system units may jointly
operate to
authenticate the mobile device.
[0081] As noted at block 116, upon authentication, 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. In one embodiment, 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. As discussed later, 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.
Subsequently, at block 118, the mobile device 17 may inform the user to avail
the transit
service through the gateless entry location. An alert (audible, visible, or
audiovisual) or "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.
[0082] FIG. 10 shows an exemplary flowchart 120 illustrating a control unit-
based
gateless entry methodology according to one embodiment of the present
disclosure. In
particular embodiments, the controller unit 18 itself may operate as the
control unit. In that
case, 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. In other embodiments, 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. In that case, the controller
driver 14 may be
suitably configured to accomplish the gateless entry functionality in a
distributed manner.
The operational tasks shown in FIG. 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
31
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
transit facility for the transit service. As discussed later, the transit
facility may be a transit
station or a transit vehicle itself.
[0083] Initially, at block 122, 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. Upon authentication of the mobile device, the control unit may
receive transit
data from the mobile device over the Bluetooth interface (block 124). In one
embodiment,
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). As discussed later, in one embodiment, the 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. At block 128, the 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. Thereafter, at block 130, 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). Based on
the earlier
validation of the user's electronic ticket (at block 126), the control unit
may allow the user to
avail the transit service through the gateless entry point, as noted at block
134. In one
embodiment, 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.
[0084] 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. On the other
hand, 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
32
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
one embodiment of the present disclosure. Although the configurations in FIGs.
11 and 12
are implemented in different environments¨stationary (FIG. 11) vs. mobile
(FIG. 12), they
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).
[0085] Referring now to FIG. 11, 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.
In particular
embodiments, 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. In one
embodiment,
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. As discussed in more detail later, 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. Although
not shown in FIG. 11, in certain embodiments, 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.
33
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[0086] 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.
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.
[0087] Prior to discussing the hardware features and operational aspects of
the system
components in FIGs. 11-12, a brief overview of the distinctions between a
"walk-in-walk-
out" (WiWo) configuration of FIG. 11 and a "be-in-be-out" (BiBo) configuration
of FIG. 12 is
provided. 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. In a traditional CiCo
configuration, 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. In
contrast, 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.
In a gateless
WiWo system, the coverage area may need to have sufficient device
locators¨such as the
locators 140, 142¨as well as full 3D camera coverage.
[0088] In contrast to a WiWo system, 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. In a
BiBo system like the one in the embodiment of FIG. 12, 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.
34
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
As discussed later, in a BiBo configuration, 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.
[0089] Generally, in the WiWo configuration, 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. Similarly, in the BiBo
configuration for gateless
entry, the user may simply walk into a "paid area" without performing any
action. In a BiBo
system, a user's presence in the paid area may be constantly monitored until
the user exits
the paid area. Like the WiWo case, the BiBo system also may perform the
validation of the
user's ticket autonomously in the background without any manual interaction by
the user.
[0090] Referring again to FIGs. 11-12, a brief description of the exemplary
hardware
features of the system components shown therein is provided. In particular
embodiments,
the BLE wake-up beacon 152 may be functionally similar to the wake-up beacon
62 in FIG.
and, hence, additional discussion of the hardware features of the wake-up
beacon 152 is
not provided. Briefly, 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.
Similarly, 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.
[0091] As mentioned before, in some embodiments, 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
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
collectively operate as a "control unit" of FIG. 10 to accomplish the gateless
entry/exit
functionality as per teachings of the present disclosure. In one embodiment,
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. In certain embodiments, 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. In
particular
embodiments, 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. 11-12 to collect the following data: (i) mobile device
positioning data from
the positioning engine 144, (ii) person location data from the 3D camera 146,
and (iii)
authentication data from the BLE gateway 138. 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. Thus,
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.
[0092] In the embodiments of FIGs. 11-12, 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). 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). Some examples of an RDBMS include an Oracle server, a
Microsoft
36
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
SQL server, a MySQL (open source) system, and IBM DB2 system, and so on. In
particular embodiments, 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. These database fields are
exemplary only. In
other embodiments, depending on the implementation of the gateless entry/exit
system, the
data fields may be more than, less than, or different from those listed above.
[0093] There may be a plurality of device locators 140, 142 utilized as
part of a gateless
entry/exit environment. The device locators 140, 142 may be placed at various
locations
throughout the transit station (for example, a train station or a bus stop) or
transit vehicle
(for example, a bus or a train) where the gateless entry/exit facility is
provided. 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. 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. In one embodiment, 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 Arduino 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. In that regard, 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
37
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. In one
embodiment,
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.
[0094] In particular embodiments, 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. It is noted here that in the embodiments of FIGs. 11-
12, a fare gate,
like the fare gate 70 in FIG. 5, may be optional. However, fare gate(s) also
may be provided
in some embodiments along with gateless entry/exit, as per desired
implementation. As
discussed earlier with reference to FIG. 5, a fare gate may be any physical
mechanism
used to prevent an unauthorized user from entering a paid area.
[0095] It is noted that, in one embodiment, all Bluetooth communications
between
various entities in FIGs. 11-12 may conform to the standards set forth in the
Bluetooth
Core Specification 4.2.
[0096] In FIG. 11, a proximity area 165 is shown to be "divided" into an
unpaid area 167
and a paid area 168. In the embodiment of FIG. 11, 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. 9-12, 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. Similarly,
in the context of the embodiments in FIGs. 9-12, 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. Generally, 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
38
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
the paid area 168. In the gateless entry configuration 174 of FIG. 12, 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. As mentioned before, 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. On
the other
hand, 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.
[0097] In the embodiments of 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. As noted before, the term
"gateless entry
location" may be analogized with the earlier-mentioned "fare gate trigger
zone" (or "fare
validation zone"). However, in the embodiments of FIGs. 9-12, the term
"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). However, in other
embodiments
(such as, for example, in transit locations having gated and/or gateless entry
options),
these terms may be used synonymously or interchangeably. It is noted here that
the mobile
device's 17 presence in a gateless entry location (165 or 176) may indicate
its user's 163
intent to pay a fare and proceed to the actual transit terminal or transit
vehicle.
[0098] Because of substantial similarity in the hardware configurations of
the
embodiments in FIGs. 11-12, these embodiments are jointly addressed in the
below-
described operational details of gateless entry/exit. In other words, the
discussion below
applies to both of the embodiments in FIGs. 11-12, unless specified otherwise.
The
following operations illustrate how gateless entry/exit may be accomplished in
particular
embodiments as per teachings of the present disclosure. The operations below
are
39
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
numbered for ease of discussion only; the numbering does not necessarily
reflect any
specific order of performance or execution of described tasks.
1. Initially, the user 163 may enter the relevant proximity area 165, 176 with
possession of the mobile device 17.
2. 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). The relevant aspects of BLE wake-up beacon
transmission/reception are already discussed before with reference to
discussion of FIG. 5.
Thus, based on the received Bluetooth beacon signal, 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. Alternatively (or additionally), 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.
3. Upon being triggered, 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. In case
of a gated entry location such as a fare gate, each advertisement packet may
contain data
indicating that the mobile device is configured for gated entry/exit for the
transit service. In
some embodiments, the transmission rate of these advertisement packets may be
slower in
order to conserve battery. It is noted here that, if the mobile device 17
operates on an
iOSTM operating system, in some embodiments, 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 Android Tm-based mobile
device.
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
5. Once connection has been established between the mobile device 17 and the
gateway unit 138, 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). In certain embodiments, 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.
6. If the mobile device 17 is authenticated, 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. In some embodiments, 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.
7. If the mobile device is authenticated, the user app 12 also 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.
Hence, upon receipt of the secure token, the BLE gateway 138 may communicate
the
token to the database 154 through the controller unit 148. In one embodiment,
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
41
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
8. In one embodiment, the manufacturer/provider of the device locators 140,
142
and the positioning engine 144 may be the same. In that case, 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.
9. It is noted here that, in FIG. 11, 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.
As also mentioned in sub-paragraph (6) above, in some embodiments, 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. Depending on the position of the locators
140, 142 and
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.
10. 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
42
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. 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. In some embodiments,
the
positioning engine 144 also may provide a three-dimensional (3D) version of
location data
in terms of x-y-z (height) coordinates. In certain embodiments, the controller
driver 14 may
be configured to collect and use such 3D location data instead of the 2D
location data.
11. When the user 163 enters the pre-determined region 170 (FIG. 11) or a
similar coverage location within the proximity area 176 (FIG. 12) with the
mobile phone 17
in possession, 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. In some embodiments, the camera 146 also may provide a three-
dimensional (3D) version of location data in terms of x-y-z (height)
coordinates. In certain
embodiments, the controller driver 14 may be configured to collect and use
such 3D
location data instead of the 2D location data.
12. 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
43
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
13. If there is a fare gate, like the fare gate 70 in FIG. 5, 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.
14. As mentioned before, the gateless entry facility may be provided without a
fare gate or along with it (as an additional alternative). In a gateless
entry/exit environment,
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.
For example, if the user has a valid ticket and the controller unit 148 has
authorized the
user to avail the transit service, 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. 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.
15. As mentioned before, in one embodiment, 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. In particular embodiments, 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
44
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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.
[0099] The embodiments in FIGs. 9-12 illustrate exemplary approaches to
facilitating
gateless entry/exit for a transit service. As discussed, 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. It is
noted here that although 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).
[00100] FIG. 13 is a block diagram of an exemplary mobile device 17 according
to one
embodiment of the present disclosure. As noted earlier, 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. 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. Upon execution of the user app's program
code by the
processor 180, 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. In
one
embodiment, 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.
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[00101] 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. 11-12) as well as other content needed to facilitate hands-free fare
validation and/or
gateless entry/exit. For example, in one embodiment, 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.
[00102] 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. In
particular embodiments, 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. For example, in one embodiment, 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.
[00103] In one embodiment, 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. As noted
before, the software
46
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
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. For example, when existing hardware
architecture of
the device 17 cannot be modified, 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. Thus,
although 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.
[00104] 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. In one embodiment, 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. In one embodiment, 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. In FIG. 14, 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. In
some embodiments, 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
47
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
be configured as a standalone system, as a server system, as a client system,
or in any
other suitable form factor.
[00105] In particular embodiments, the controller unit 188 may include more
than one
processor (e.g., in a distributed processing configuration). When the
controller unit 188 is a
multiprocessor system, there may be more than one instance of the processor
190 or there
may be multiple processors coupled to the processor 190 via their respective
interfaces
(not shown). The processor 190 may be a System on Chip (SoC) and/or may
include more
than one Central Processing Units (CPUs).
[00106] 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. In some embodiments, the system memory 194
may
include multiple different types of semiconductor memories, as opposed to a
single type of
memory. In other embodiments, the system memory 194 may be a non-transitory
data
storage medium.
[00107] The peripheral storage unit 196, in various embodiments, may include
support for
magnetic, optical, magneto-optical, or solid-state storage media such as hard
drives, optical
disks (such as Compact Disks (CDs) or Digital Versatile Disks (DVDs)), non-
volatile
Random Access Memory (RAM) devices, Secure Digital (SD) memory cards,
Universal
Serial Bus (USB) memories, and the like. In some embodiments, the peripheral
storage unit
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.
Various such storage devices may be non-transitory data storage media.
[00108] As mentioned earlier, 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. In some
embodiments,
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).
48
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
[00109] In one embodiment, 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. In
various embodiments, the network may include Local Area Networks (LANs), Wide
Area
Networks (WANs), wired or wireless Ethernet, telecommunication networks, or
other
suitable types of networks/interfaces. For example, the network may be a
packet-switched
network such as, for example, an Internet Protocol (IP) network like the
Internet, a circuit-
switched network, such as the Public Switched Telephone Network (PSTN), or a
combination of packet-switched and circuit-switched networks. In another
embodiment, the
network may be an IP Multimedia Subsystem (IMS) based network, a satellite-
based
communication link, a Bluetooth or Bluetooth LE (BLE) based network/interface,
an NFC
based network/interface, a Worldwide Interoperability for Microwave Access
(WiMAX)
system based on Institute of Electrical and Electronics Engineers (IEEE)
standard IEEE
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.
[00110] 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. In one
embodiment, the power supply unit 200 may convert solar energy or other
renewable
energy into electrical power.
[00111] In one embodiment, 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. In
the embodiment of FIG. 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
49
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
methodology as per the teachings of the present disclosure. In one embodiment,
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).
[00112] In the preceding description, for purposes of explanation and not
limitation,
specific details are set forth (such as particular architectures, interfaces,
techniques, etc.) in
order to provide a thorough understanding of the disclosed technology.
However, it will be
apparent to those skilled in the art that the disclosed technology may be
practiced in other
embodiments that depart from these specific details. That is, those skilled in
the art will be
able to devise various arrangements which, although not explicitly described
or shown
herein, embody the principles of the disclosed technology. In some instances,
detailed
descriptions of well-known devices, circuits, and methods are omitted so as
not to obscure
the description of the disclosed technology with unnecessary detail. All
statements herein
reciting principles, aspects, and embodiments of the disclosed technology, as
well as
specific examples thereof, are intended to encompass both structural and
functional
equivalents thereof. Additionally, it is intended that such equivalents
include both currently
known equivalents as well as equivalents developed in the future, such as, for
example,
any elements developed that perform the same function, regardless of
structure.
[00113] Thus, for example, it will be appreciated by those skilled in the art
that block
diagrams herein (e.g., in FIGs. 2 and 13-14) can represent conceptual views of
illustrative
circuitry or other functional units embodying the principles of the
technology. Similarly, it will
be appreciated that the flowcharts in 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
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
microprocessors in association with a DSP core, a controller, a
microcontroller, Application
Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs)
circuits,
any other type of integrated circuit (IC), and/or a state machine. Some or all
of the
functionalities described above in the context of 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.
[00114] When certain inventive aspects require software-based processing, such
software or program code may reside in a computer-readable data storage
medium. As
noted earlier with reference to FIG. 14, 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). In case of the embodiment in FIG. 13, such data
storage
medium may be part of the memory 182 or the processor's 180 internal memory
(not
shown). In certain embodiments, 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.
[00115] Alternative embodiments of the controller unit 188 according to
inventive aspects
of the present disclosure may include additional components responsible for
providing
additional functionality, including any of the functionality identified above
and/or any
functionality necessary to support the solution as per the teachings of the
present
disclosure. Although features and elements are described above in particular
combinations,
each feature or element can be used alone without the other features and
elements or in
various combinations with or without other features. As mentioned before,
various FV
controller driver-based functions and FV user app-based functions discussed
herein may
be provided through the use of hardware (such as circuit hardware) and/or
hardware
capable of executing software/firmware in the form of coded instructions or
microcode
51
CA 03094302 2020-09-17
WO 2019/182625 PCT/US2018/031552
stored on a computer-readable data storage medium (mentioned above). Thus,
such
functions and illustrated functional blocks are to be understood as being
either hardware-
implemented and/or computer-implemented, and thus machine-implemented.
[00116] The foregoing describes a system and method in which 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.
[00117] As will be recognized by those skilled in the art, the innovative
concepts
described in the present application can be modified and varied over a wide
range of
applications. Accordingly, the scope of patented subject matter should not be
limited to any
of the specific exemplary teachings discussed above, but is instead defined by
the following
claims.
52
