Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/26/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 6-8, filed 12/16/2025, with respect to the rejection(s) of claims 1-20 under 35 U.S.C. 103 over RAINA et al. (US 20160055428 A1—hereinafter—"RAINA”) in view of Bergdale et al. (US 20180293523 A1 –Hereinafter—Bergdale) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Kim et al. (Hereinafter US 20220232344 A1—hereinafter—"Kim”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9 and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over RAINA et al. (US 20160055428 A1—hereinafter—"RAINA”) in view of Kim et al. (Hereinafter US 20220232344 A1—hereinafter—"Kim”) in further view of Bergdale et al. (US 20180293523 A1 –Hereinafter—Bergdale).
As per claim 1:
RAINA discloses a computer method comprising:
receiving, at a first computing device, a request from a mobile computing device to perform an action ([0056] The zone computer 150a and the validation and enforcement application 132a may request additional data resulting in multiple exchanges. In another example, the mobile device may initiate the connection with the zone computer and then engage in authentication and then validation. Authentication in either case may include determination of keys for secure communication. [0057]The zone computer initiates a connection with the validation and enforcement application on the mobile device if the mobile device is in the area of validation and the mobile device is broadcasting or advertising or transmitting one or more unique IDs and/or has predetermined services and/or characteristics. Then message exchange may occur for validation. For example, the zone computer 150a and the validation and enforcement application 132a on the mobile device 130a may enter into authentication to establish the identity of both sides. After authentication, data is exchanged between the zone computer 150a and the validation and enforcement application 132a for validation. The zone computer 150a and the validation and enforcement application 132a may request additional data resulting in multiple exchanges. In another example, the mobile device may initiate the connection with the zone computer and then engage in authentication and then validation. Authentication in either case may include determination of keys for secure communication);
sending, by a first computing device, the location challenge with the radio beacon identifier to the mobile computing device ([0026] The beacons 140 are hardware that can broadcast beacon signals. The beacons 140 may be standalone devices or incorporated into another system. A zone computer and/or an enforcement computer may have a beacon. The beacons 140 broadcast beacon signals at a short distance, such as up to 10 meters or a much shorter distance, such as up to 4 centimeters. For example, the beacons 140 may be Bluetooth, Bluetooth Low Energy (BLE), or near-field communication (NFC) beacons. The beacons 140 may be part of a local positioning system, such as IBEACONS, that are used to wirelessly determine the position of the mobile devices 130 inside the restricted area 101. The beacons 140 may be positioned at strategic locations inside the validation and enforcement area 101 to facilitate accurate detection of a user within the validation and enforcement area 101. The broadcast range and power of the beacons can be tuned per the environment. For example, the broadcast range of the beacons is tuned to cover the boundaries of their respective zones. For example, the beacons 140 can broadcast towards the inside of their respective zone and may have a range to cover their zone but not much farther to prevent accidentally validating a mobile device that may be adjacent the validation and enforcement area 101 but not in it. Also, the validation and enforcement applications 132 running on the mobile devices 130 can filter out the beacons below a specific power range or accuracy or angle or azimuth or distance. Also, each of the zone computers 150 may be associated with a different zone in the validation and enforcement area 101, and a mobile device in a zone can identify the zone computer for the current zone based on location information determined from signals received from the beacons in the zone. The beacons 140 broadcast a signal that invokes a validation process between the mobile devices 130 and the zone computers 150. For example, after receiving signals from the beacons 140a-d, the mobile device 130a communicates with the zone computer 150a to validate the user 131a, and similarly, the mobile device 130b communicates with the zone computer 150b to validate the user 131a. [0035] The mobile devices 130 listen for the broadcasts from the beacons 140, which may contain the unique identifiers for each beacon, or inputs from which the unique identifiers may be calculated or computed or derived or looked up in an internal data store. When a mobile device is in range of one or more of the beacons 140, unique identifiers received from the beacons at the mobile device may invoke a detection mode in the mobile device to determine whether the mobile device is in proximity to at least one of the zone computers 150 or the enforcement computer 175 in the validation and enforcement area 101. This is referred to as detection or detection mode. In detection mode, to determine whether the mobile device is in proximity to a zone computer or the enforcement computer 175, the unique beacon identifiers, signal strength (such as received signal strength indicator (RSSI), transmission power, and/or received Power) of the beacon's broadcasts, broadcast zone, broadcast accuracy, azimuth and/or angle of the beacon signal (e.g., calculated from the received wireless broadcast) are used to identify the location of the mobile device);
receiving, at the first computing device, a location challenge response from the mobile computing device, the location challenge response comprising a beacon value obtained based on a radio beacon signal received by the mobile computing device ([0035] If the mobile device detects that it is in the validation and enforcement area 101, it may engage in communication with the zone computer or the enforcement computer 175 for validation or enforcement. This may involve the mobile device getting into a peripheral mode, wherein the mobile device may start sending message broadcasts over the wireless interface (e.g. Bluetooth 4.0), like a beacon. For example, the mobile device acts as a Bluetooth peripheral and advertises, broadcasts, transmits, and/or enables its services and/or characteristics using one or more of unique mobile IDs );
determining that the beacon value matches a beacon value ([0035] The zone computer or the enforcement computer 175 may use the unique mobile device ID to identify the mobile device or the services/characteristics advertised, broadcasted, transmitted, and/or supported by the mobile device or the fare payment application on the mobile device. In another example, the zone computer or the enforcement computer 175 broadcasts a message indicating that it is available for validation or enforcement and the mobile device ID which is calculated by the computer is included in the message. The mobile device receives the message, determines whether the mobile device ID in the message matches the mobile device ID calculated by the mobile device, and if it does match, initiating a message exchange for authentication and validation); and
based on the determining, permitting the action ([0036] The zone computers 150 include computers that may be provided in the validation and enforcement area 101 for authentication and validation of users in the validation and enforcement area 101. A zone computer may support an entire validation area or a zone in the validation area. The zone computers 150 engage in message exchange and validation processes with the mobile devices 130 for authentication and validation after the mobile devices enter peripheral mode, which may be invoked after the mobile devices 130 detect that they are in the validation and enforcement area 101 and that the mobile devices 130 are settled. For example, a process is executed to establish a secure communication channel between a mobile device and a zone computer through run-time key generation, which may be based on the ID of beacons and other information. Messages may be exchanged via the secure communication channel to perform validation. In one example, validation may include fare-based validation, such as when payment of a fare is required. [0037] Similarly, the enforcement computer 175 engages in secure message exchange and processes with the mobile devices 130 for authentication and to check validation, which is further described below. Both the zone computers 150 and the enforcement computer 175 may be connected to a back-end server via the Internet or another wide area network to provide updates and perform other functions which may include validation-related functions).
RAINA does not explicitly disclose choosing a radio beacon identifier at the first computing device for a location challenge, the radio beacon identifier identifying a radio beacon being transmitted by a second computing device. Kim, in analogous art however, discloses choosing a radio beacon identifier at the first computing device for a location challenge, the radio beacon identifier identifying a radio beacon being transmitted by a second computing device ([0089] The server may register the gateway as a logical network, and may assign the first logical network a network identifier (ID). The server may further generate a set of security keys, which may include one or more security keys. For example, the server may generate a unique key for the network device and a separate unique key for the access device. The server may associate the network device and the access device with the logical network by storing the network ID and the set of security keys in a record or profile. The server may then transmit the network ID and the set of security keys to the network device. The network device may store the network ID and its unique security key. The network device may also send the network ID and the access device's unique security key to the access device. In some embodiments, the server may transmit the network ID and the access device's security key directly to the access device. The network device and the access device may then communicate with the cloud server using the network ID and the unique key generated for each device. Each network device and access device may also be assigned a unique identifier (e.g., a universally unique identifier (UUID), a unique device identifier (UDID), globally unique identifier (GUID), or the like) by the cloud server that is separate from the network ID and the unique security key of each device. Accordingly, the access device may perform accountless authentication to allow the user to remotely access the network device via the cloud network without logging in each time access is requested. [0128] A network device may determine its location using an IP geolocation service using an IP address of a gateway (e.g., gateway 212). One of ordinary skill in the art will appreciate that any identifier may be used, such as a MAC address, radio frequency identifier (RFID), serial number, a universally unique identifier (UUID), a unique device identifier (UDID), a globally unique identifier (GUID), or other identifier. A network device may determine an IP address of a gateway, and may transmit the IP address to a network server (e.g., a cloud network server). A database may be maintained by the network and may include location information of various devices that are located throughout a region. The network server may query the database using the IP address to determine the location of the gateway. In one example, the network device 202 may determine an IP address of gateway 212. The network device 202 may transmit the IP address to the network server, which may query the database to determine the location of the gateway 212. The network device 202 may receive location information identifying the location of the gateway 212, and may then determine its location using the location information. In some embodiments, the location information obtained from the geolocation service may be used to supplement or enhance a location determined using other location determination techniques described herein. In some embodiments, the geolocation service may be used as an approximate starting location for the network device 202, which may be refined over time using one or more other location determination techniques described herein. [0145] FIG. 7 illustrates one example of a communication frame 700 including location information that may be transmitted by a device to one or more other devices. In some embodiments, the communication frame 700 may include a beacon frame, a probe response frame, or any other appropriate communication frame. In some cases, the communication frame 700 includes a communication frame defined in any of the 802.11 family of standards. The communication frame 700 may be transmitted by one or more devices, such as the network devices or access devices within network 100 or within a network associated with one or more venues (e.g., venue 200). For example, the communication frame 700 may be transmitted by one or more of the network devices 202, 204, 206, 208, 210 in order to share their location information. In some embodiments, the one or more devices may transmit their location information along with a unique identifier of each device. For example, a unique identifier may include a MAC address, a universally unique identifier (UUID), a unique device identifier (UDID), a globally unique identifier (GUID), a RFID, a serial number, or any other identifier that is unique to each device. In some embodiments, the communication frame 700 may be transmitted from a device to a gateway, such as gateways 110, 112, or 212. The gateway may then route and transmit the communication frame 700 to an intended destination device via a local area network (network 100, network 200, or the like) and/or via an external network (e.g., cloud network 114, external network 214, or the like). In some embodiments, the one or more devices may transmit the communication frame 700 directly to a destination device using, for example, a Bluetooth™ communication, a Zigbee™ communication, a UWB communication, a WiFi-Direct communication, a BLE communication, a cellular, another broadband communication, or some other communication using an appropriate communication protocol).
Kim, further discloses, the above limitation in ([0147] FIG. 8 illustrates an example of a body 704 of the communication frame 700. The body 704 may include a beacon interval field 802, a timestamp field 804, one or more service set identification (SSID) fields 806, a rates field 808 indicating supported rates, a parameter set field 810, a capability field 812, a traffic indication map (TIM) field 814, and a location field 816. The beacon interval field 802 may indicate the amount of time between communication frame 700 transmissions, which may allow devices that enter a low power mode to know when to wake up to receive the communication frame 700. The timestamp field 804 may be used by a device after it receives the communication frame 700 to update its local clock, enabling synchronization among multiple devices that are associated with the device transmitting the communication frame 700. The SSID field 806 identifies a specific network, such as the local area network for which the transmitter of the communication frame 700 is a part [0179] A communication or tracking device may be part of or integrated with the object to allow the object to be located. The communication or tracking device may include a network device, such as any of the network devices 102, 104, 106, 202, 204, 206, 208, 210 described above. For example, the device 1104 may be a communication or tracking device that is attached to a collar of the dog 1102, and may be used to locate the dog 1102 as it moves from points A to D illustrated in FIG. 11. In some embodiments, the devices 1104 may include an application or other program associated with the location service that allows the device 1104 to perform the location functionality described herein. The device 1104 may include one or more transceiver radios that can communicate using relatively short range communication protocols, such as a WiFi™, Bluetooth™, Zigbee™, IR, UWB, WiFi-Direct, BLE, and/or other appropriate transceiver radios. The device 1104, however, may not include long range communication capabilities. For example, the device 1104 may not include a cellular transceiver radio. Accordingly, the device 1104 may be unable to directly communicate with the user's client device due to the distance between the device 1104 and the user's client device. In some embodiments, the device 1104 also may not be able to communicate with the network server. For example, the device 1104 may be out of range of or may not have permission to access a WiFi™ network. In another example, the device 1104 may not have the communication capabilities to communicate with the network server. For example, the device 1104 may include only a Bluetooth™ transceiver radio, a Zigbee™ transceiver radio, an IR transceiver radio, a UWB transceiver radio, a WiFi-Direct transceiver radio, and/or a BLE transceiver radio. Thus, the device 1104 may rely on communication with the location devices 1106, 1108, 1110, 1112, 1116, 1118, 1120, 1122, and 1124 in order to determine its location and communicate its location back to the user's client device via the network server).
Kim, continues to teach the above limitation in ([0180] The request may include a unique identifier of the device that is attached to or integrated with the object that is to be located. The identifier may include a MAC address, a universally unique identifier (UUID), a unique device identifier (UDID), a globally unique identifier (GUID), a RFID, a serial number, or any other unique identifier of the device. The characters of the unique identifier may include letters and/or numbers. In one example, the device 1104 may be associated with a unique identifier. The unique identifier may be stored in the external network in which the network server is located and with which the user may be registered. Devices may register with the network and may be issued a unique identifier by the external network. An example of the registration process is described below with respect to FIG. 16. The external network may store a unique identifier for each of the registered devices so that communications can be directed to a device by referencing the device's unique identifier. For example, a communication, such as a location request, may include the unique identifier of a device in order to identify the device as the intended subject or recipient of the communication. In one example, the request from the user to locate the dog 1104 may include the identifier of the device 1104 so that the location devices 1106, 1108, 1110, 1112, 1116, 1118, 1120, 1122, or 1124 of the crowd sourced location data source are aware of which device to locate. In some embodiments, the device 1104 may periodically transmit or broadcast a tracking signal that includes the unique identifier of the device 1104 so that location devices 1106, 1108, 1110, 1112, 1116, 1118, 1120, 1122, 1124 are aware when the device 1104 is in proximity to location devices 1106, 1108, 1110, 1112, 1116, 1118, 1120, 1122, 1124. [0197] A communication or tracking device 1204 that is part of or integrated with the key 1202 may periodically or continuously transmit a tracking signal to allow the object to be located. The device 1204 and tracking signal may be similar to the device 1104 and tracking signals described above with respect to FIG. 11. The location devices 1206, 1208, 1210, 1212, 1214, 1216, or 1218 that are in proximity to the device 1204 or that pass by device 1204 may detect the tracking signal. The location devices 1206, 1208, 1210, 1212, 1214, 1216, or 1218 may detect the tracking signals in response to receiving the request from the network server. The request includes a unique identifier of the device 1204, such as a MAC address, a UUID, a UDID, a GUID, a RFID, a serial number, or any other unique identifier of the device 1204)).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the radio beacon identifier disclosed by RAINA to include choosing the radio beacon identifier at the first computing device for a location challenge, the radio beacon identifier identifying a radio beacon being transmitted by a second computing device. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide, techniques and systems are provided for determining a location of one or more devices using crowd sourced location data in a more open space or environment as suggested by Kim ([0002-0003]).
RAINA and Kim do not explicitly disclose the location challenge identifying the radio beacon being transmitted by a second computer device and the matched beacon value is an expected beacon value. Bergdale, in analogous art however, discloses the location challenge identifying the radio beacon being transmitted by a second computer device and the matched beacon value is an expected beacon value ([0051] 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. [0052] 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 iOS™, Android™, and other mobile operating systems).
Bergdale further discloses the radio beacon being transmitted by a second computer device and the matched beacon value is an expected beacon value in ([0064] 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 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.
Bergdale further discloses the radio beacon being transmitted by a second computer device and the matched beacon value is an expected beacon value in ([0070] 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).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the location challenge identifying the radio beacon disclosed by RAINA and Kim to include the radio beacon being transmitted by a second computer device and the matched beacon value is an expected beacon value. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to 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 as suggested by Bergdale ([0013]).
As per claim 2. RAINA discloses method of claim 1, further comprising:
sending a second location challenge to a second mobile computing device, the second location challenge identifying the radio beacon ([0026] The broadcast range and power of the beacons can be tuned per the environment. For example, the broadcast range of the beacons is tuned to cover the boundaries of their respective zones. For example, the beacons 140 can broadcast towards the inside of their respective zone and may have a range to cover their zone but not much farther to prevent accidentally validating a mobile device that may be adjacent the validation and enforcement area 101 but not in it. Also, the validation and enforcement applications 132 running on the mobile devices 130 can filter out the beacons below a specific power range or accuracy or angle or azimuth or distance. Also, each of the zone computers 150 may be associated with a different zone in the validation and enforcement area 101, and a mobile device in a zone can identify the zone computer for the current zone based on location information determined from signals received from the beacons in the zone. The beacons 140 broadcast a signal that invokes a validation process between the mobile devices 130 and the zone computers 150. For example, after receiving signals from the beacons 140a-d, the mobile device 130a communicates with the zone computer 150a to validate the user 131a, and similarly, the mobile device 130b communicates with the zone computer 150b to validate the user 131a);
receiving a second location challenge response from the mobile computing device, the second location challenge response comprising a second beacon value ([0035] When a mobile device is in range of one or more of the beacons 140, unique identifiers received from the beacons at the mobile device may invoke a detection mode in the mobile device to determine whether the mobile device is in proximity to at least one of the zone computers 150 or the enforcement computer 175 in the validation and enforcement area 101. This is referred to as detection or detection mode. In detection mode, to determine whether the mobile device is in proximity to a zone computer or the enforcement computer 175, the unique beacon identifiers, signal strength (such as received signal strength indicator (RSSI), transmission power, and/or received Power) of the beacon's broadcasts, broadcast zone, broadcast accuracy, azimuth and/or angle of the beacon signal (e.g., calculated from the received wireless broadcast) are used to identify the location of the mobile device);
determining that the second beacon value does not match the expected beacon value; and based on the determining, denying the action ([0035] The zone computer or the enforcement computer 175 may use the unique mobile device ID to identify the mobile device or the services/characteristics advertised, broadcasted, transmitted, and/or supported by the mobile device or the fare payment application on the mobile device. In another example, the zone computer or the enforcement computer 175 broadcasts a message indicating that it is available for validation or enforcement and the mobile device ID which is calculated by the computer is included in the message. The mobile device receives the message, determines whether the mobile device ID in the message matches the mobile device ID calculated by the mobile device, and if it does match, initiating a message exchange for authentication and validation).
As per claim 3. RAINA discloses the computing method of claim 1, wherein the beacon value comprises data within the radio beacon ([0026] The beacons 140 are hardware that can broadcast beacon signals. The beacons 140 may be standalone devices or incorporated into another system. A zone computer and/or an enforcement computer may have a beacon. The beacons 140 broadcast beacon signals at a short distance, such as up to 10 meters or a much shorter distance, such as up to 4 centimeters. For example, the beacons 140 may be Bluetooth, Bluetooth Low Energy (BLE), or near-field communication (NFC) beacons. The beacons 140 may be part of a local positioning system, such as IBEACONS, that are used to wirelessly determine the position of the mobile devices 130 inside the restricted area 101).
As per claim 4. RAINA discloses the computing method of claim 1, wherein the radio beacon is a Bluetooth or a Bluetooth Low Energy beacon ([0026] The beacons 140 are hardware that can broadcast beacon signals. The beacons 140 may be standalone devices or incorporated into another system. A zone computer and/or an enforcement computer may have a beacon. The beacons 140 broadcast beacon signals at a short distance, such as up to 10 meters or a much shorter distance, such as up to 4 centimeters. For example, the beacons 140 may be Bluetooth, Bluetooth Low Energy (BLE), or near-field communication (NFC) beacons. The beacons 140 may be part of a local positioning system, such as IBEACONS, that are used to wirelessly determine the position of the mobile devices 130 inside the restricted area 101).
As per claim 5. RAINA discloses the computing method of claim 4, wherein the beacon value comprises a major value and minor value transmitted within the radio beacon ([0034] The beacons 140 and beacon 176 may include small computers that may be attached to or embedded in a physical infrastructure. The beacons 140 and beacon 176 may broadcast a message every x milliseconds (ms), where x>1 ms and may be less than 200 ms but other intervals may be used and may be based on the environment and use cases. The message may include a unique ID or a set of unique IDs or a combination of generic IDs and unique IDs. In one example, at least one part of the ID is generic and the other part is unique. In one example, the ID may include a universally unique identifier (UUID) a major ID and/or a minor ID. For example, one of the identifiers is generic (e.g., UUID and/or the major ID) and may be the same for all beacons that belong to or are for a particular entity, such as for the same company or the same mass transit system, or may vary between different entities or restriction level within the same company or mass transit system. The other unique ID (e.g., minor ID) may help identify a particular location or sub-location. For example, the major ID may be the same for all beacons that belong to a particular location within the system, such as a specific rail station or a bus stop or train, and the minor ID may be different for each subway car or can be unique to the beacon and can be associated with a particular sub-location within a location. Also, the major ID or the minor ID may identify the beacon as an inspection beacon or a beacon for validation).
As per claim 6: Bergdale discloses the computing method of claim 1, wherein the radio beacon is a Wi-Fi signal ([0042] 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 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).
As per claim 7: RAINA discloses the computing method of claim 1, wherein the location challenge response comprises a plurality of beacon values, each associated with a received signal strength, and ([0035] In detection mode, to determine whether the mobile device is in proximity to a zone computer or the enforcement computer 175, the unique beacon identifiers, signal strength (such as received signal strength indicator (RSSI), transmission power, and/or received Power) of the beacon's broadcasts, broadcast zone, broadcast accuracy, azimuth and/or angle of the beacon signal (e.g., calculated from the received wireless broadcast) are used to identify the location of the mobile device. [0040] At the current location of user 131b, the mobile device 130b of user 131b receives beacon signals from beacons 140b and 140e-g. The beacon signals relative strength, angle, azimuth, etc. and the location information derived from the major ID or minor ID or carried in the payload of the signals from beacons 140b and 140e-g are used to determine the precise location of the user 131b. Based on this information, the validation and enforcement application 132b may determine that the user 131b is outside the validation and enforcement area 101 and not enter peripheral mode. For example, the validation and enforcement application 132b may determine that the signals are from beacons assigned to different zone computers, such as zone computers 150a-c. Also, from the signal strength, angle, and azimuth, the validation and enforcement application 132b may determine that the signals from beacons 140b and 140g have a signal strength below a threshold, and an angle and azimuth that are indicative of beacons associated with different zones and different zone computers. Thus, the validation and enforcement application 132b may ascertain that the closest beacons are beacons 140e-f. The validation and enforcement application 132b may further determine that since it is not receiving signals, or receiving signals that are too weak, from at least three or all four beacons for the same zone, that it is outside the validation and enforcement area 101. Therefore, the validation and enforcement application 132b does not enter peripheral mode and does not engage in validation);
wherein the determining uses triangulation to find a location of the mobile computing device ([0045] In one example, triangulation-based detection is performed to determine whether the mobile device 130a is in a zone. For example, the validation and enforcement application 132a running on the mobile device 130a registers for beacon notifications with a specific unique ID or IDs or part of the IDs, e.g. UUID and/or major ID and/or minor ID or a list of UUIDs, major IDs and/or minor IDs. For example, the UUIDs or the major IDs may be the same for all beacons provided by the same entity, such as all beacons for the same mass transit company or all beacons for the same train station. So, for example, the UUIDs broadcasted by the beacons 140 may be the same because they are for the same entity or same train station. The validation and enforcement application 132a stores a list of UUIDs, major IDs and minor IDs that it may respond to. The mobile device 130a listens for broadcasted unique IDs from beacons. If the unique IDs of the beacon signals that are received are registered, such as stored in the list, the validation and enforcement application 132a determines whether it is in a zone in the validation and enforcement area 101. For example, in response to recognizing broadcasts from beacons 140a-d or at least one of the beacons, using beacon signal attributes such as distance and azimuth, the validation and enforcement application 132a in mobile device 130a determines that it is within a predetermined distance (e.g., within 1 meter) to at least 1 of the beacons 140a-d. Thus, the validation and enforcement application 132a determines that it is in a zone, such as zone 1, and then proceeds to activation at step 111. [0051] Unique ID determination for the mobile device may vary depending on how detection was performed. For example, if triangulation-based detection was performed, the unique IDs (like major ID, minor ID and optional payload) from the beacons used for triangulation may be used to calculate the unique ID or IDs for the mobile device. If tap-based detection was performed, the unique ID or IDs may be calculated using the unique ID or IDs from the beacon that was tapped (e.g. major ID, minor ID and optional payload from the beacon that was tapped). The peripheral mode is enabled in the mobile device to communicate with the zone computer for the lane using the unique IDs for the services and/or characteristics. Examples of unique ID calculation functions are described below).
As per claim 8: RAINA discloses the computing method of claim 1, wherein the location challenge response comprises a received signal strength, and wherein the determining further finds whether the received signal strength is greater than a threshold ([0040] At the current location of user 131b, the mobile device 130b of user 131b receives beacon signals from beacons 140b and 140e-g. The beacon signals relative strength, angle, azimuth, etc. and the location information derived from the major ID or minor ID or carried in the payload of the signals from beacons 140b and 140e-g are used to determine the precise location of the user 131b. Based on this information, the validation and enforcement application 132b may determine that the user 131b is outside the validation and enforcement area 101 and not enter peripheral mode. For example, the validation and enforcement application 132b may determine that the signals are from beacons assigned to different zone computers, such as zone computers 150a-c. Also, from the signal strength, angle, and azimuth, the validation and enforcement application 132b may determine that the signals from beacons 140b and 140g have a signal strength below a threshold, and an angle and azimuth that are indicative of beacons associated with different zones and different zone computers. Thus, the validation and enforcement application 132b may ascertain that the closest beacons are beacons 140e-f. The validation and enforcement application 132b may further determine that since it is not receiving signals, or receiving signals that are too weak, from at least three or all four beacons for the same zone, that it is outside the validation and enforcement area 101. Therefore, the validation and enforcement application 132b does not enter peripheral mode and does not engage in validation. [0054] If triangulation-based detection was used at step 10, the following steps may be performed to calculate the unique ID or IDs for the mobile device. The detected beacons are sorted based on the signal strength (like RSSI, transmission power, received power, etc.) in descending order. Beacons may be filtered, e.g., removed from the list, if their received signal strength indicator does not fall within a predetermined value, or if they proximity is unknown or if the azimuth and angle doesn't meet predetermined requirements or a combination of these. For example, if the signal strength is too weak, such as determined by comparing the signal strength to a predetermined threshold, the corresponding beacon may be removed from the list. Then, the top “x” beacons from the list are identified where x>1. In one example, x is greater than or equal to 3. If a plurality of beacons from the top “x” beacons have the required signal strength, then, the major ID and minor ID are used to calculate the Row, Sequence, Location and Sub-location information from the beacon signals, which is in turn is used to generate the unique ID or IDs. Beacons in the same lane may have the same location, sub location and row value).
As per claim 9: RAINA discloses the computing method of claim 1, wherein the expected beacon value changes at defined time intervals ([0034] The beacons 140 and beacon 176 may include small computers that may be attached to or embedded in a physical infrastructure. The beacons 140 and beacon 176 may broadcast a message every x milliseconds (ms), where x>1 ms and may be less than 200 ms but other intervals may be used and may be based on the environment and use cases. The message may include a unique ID or a set of unique IDs or a combination of generic IDs and unique IDs. In one example, at least one part of the ID is generic and the other part is unique. In one example, the ID may include a universally unique identifier (UUID) a major ID and/or a minor ID. For example, one of the identifiers is generic (e.g., UUID and/or the major ID) and may be the same for all beacons that belong to or are for a particular entity, such as for the same company or the same mass transit system, or may vary between different entities or restriction level within the same company or mass transit system. The other unique ID (e.g., minor ID) may help identify a particular location or sub-location. For example, the major ID may be the same for all beacons that belong to a particular location within the system, such as a specific rail station or a bus stop or train, and the minor ID may be different for each subway car or can be unique to the beacon and can be associated with a particular sub-location within a location. Also, the major ID or the minor ID may identify the beacon as an inspection beacon or a beacon for validation. [0109] FIG. 11 illustrates another method for enforcement. At 1101, an inspection signal is transmitted by at least one inspection beacon. The inspection signal includes an enforcement variable for calculating an enforcement ID. The enforcement variable may be changed periodically. For example, the enforcement variable may be changed at predetermined intervals and/or at different locations (e.g., at different stops if the inspection area is mobile, such as in a vehicle).
As per claim 12: RAINA discloses the computing method of claim 1, wherein the location challenge response comprises a plurality of beacon values, each coming from a radio beacon signal having an identifier identified in the location challenge ([0075] The steps of FIG. 7 are described with respect to FIG. 1 and show the interaction between the mobile device 130a, the inspection beacon 176, and the enforcement computer 175. At step A, the inspection beacon 176 broadcasts an inspection signal. The inspection signal for example includes a UUID, a major ID and/or a minor ID, such as described above with respect to the signals broadcasted from the beacons 140. An inspection beacon for example announces that the enforcement individual 176 (e.g., an inspection officer that checks if fares have been paid) is in the vicinity by broadcasting the inspection signal. The inspection signal is distinguished from signals broadcasted from the beacons 140 for example based on information in the UUID, major ID and/or minor ID that identifies the signal as an inspection signal to the mobile devices 130).
As per claim 13: RAINA discloses the computing method of claim 1, wherein the method is performed by a server associated within an electronic commerce platform, and wherein the action is a location gated sale of a product or service ([0078] In one example, the inspection signal broadcasted from the inspection beacon 176 is a Bluetooth or BLE signal. In another example, tap-based detection is performed and the inspection signal may be a Bluetooth or BLE signal tuned for a shorter distance, such as 3-4 centimeters. For tap-based detection, the user 131a may tap the mobile device 130a on the enforcement computer 175 carried by the enforcement person 177 to receive the inspection signal. The inspection signal in both examples includes the UUID, major ID and/or the minor ID and may include other information, such as signal strength, location information, etc. [0096] If the zone computer 150a is used in a gated environment, such as shown in FIG. 3, it may include an actuator driver circuit 170 to control actuation of the physical barrier for the sub-location of the zone computer. In response to determining the user is validated, the zone computer 150a sends a signal to the actuator driver circuit 170 to invoke opening of the physical barrier, such as gate 160a for lane 110a. For example, the processor 612 validates a user associated with the mobile device 130a and sends a signal to the actuator driver circuit 170. The actuator driver circuit 170 drives an actuator of the gate 160a to open the gate 160a shown in FIG. 3. The processor 612 may also drive the circuit 170 to close the gate 160a. In one example, the global positioning system (GPS) sensor on the mobile device may be used to determine when the user enters and exits the mass transit system in order to determine the fare amount and open the gate 160a if the fare is paid when the user is exiting).
As per claim 14: RAINA discloses the computing method of claim 13, wherein the determining is performed both during access to the product or service, and at checkout for the product or service ([0087] At step J, the results of the validation check are displayed for example on the enforcement computer 175 so the enforcement person 177 can view the results and take appropriate action if needed. Appropriate action if the fare was not paid may include having the user 131a make payment, pay a penalty fee, issue a ticket indicating notice of failed validation to the user, and/or remove the user 131a from the validation and enforcement area 101. If the results indicate that the fare was paid, the enforcement computer 175 may mark the ticket as consumed and inspected if it is a single ride ticket, and send information of the marked ticket to the backend server).
As per claims 15-19: Claims 15-19 are directed to a computer system comprising: a processor; and a communications subsystem, wherein the computer system is configured to perform substantially similar features corresponding to respective limitations of claims 1-5 respectively and therefore claims 15-19 are rejected with the same rationale given above to reject corresponding limitation of claims 1-5 respectively.
As per claim 20 : Claims 15-19 are directed to a computer readable medium for storing instruction code, which, when executed by a processor of a computer system cause the computer system to perform substantially similar features corresponding to respective limitations of claims 1-5 respectively and therefore claims 15-19 are rejected with the same rationale given above to reject corresponding limitation of claims 1-5 respectively.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over RAINA et al. (US 20160055428 A1—hereinafter—"RAINA”) and Kim et al. (Hereinafter US 20220232344 A1—hereinafter—"Kim”) in view of Bergdale et al. (US 20180293523 A1 –Hereinafter—Bergdale) in further view of Brown et al. (US 20150356289 A1—hereinafter—" Brown”).
As per claim 10: RAINA, Kim and Bergdale do not explicitly disclose wherein the expected beacon value is based on a rolling code. Brown, in analogous art however, discloses wherein the expected beacon value is based on a rolling code ([0037] Configured to detect movement based on sensor data, the beacon device may be enabled to change information (e.g., the secure identifier and/or a movement indicator) that it periodically broadcasts in response to being moved. For example, the beacon device may roll a rolling identifier in response to detecting sensor data from an accelerator. The beacon device may increment/decrement a value, generate a new or random number as an identifier or movement indicator, or perform other algorithms for adjusting the information it transmits when sensor data is detected that indicates movement. For example, the beacon device may begin (or stop) rolling a device identifier in response to an internal switch opening due to the absence of a magnet. [0046] The term “wireless identity transmitter” is used herein to refer to a beacon device that is configured to periodically transmit broadcast via short-range wireless transmitters messages that include an identifier of the transmitter in addition to the movement indicator. The unique device identifier (i.e., a “deviceID”), such as a factory ID, may be a transmitted encoded number that can be correlated to the device through an algorithm or table lookup procedure by a receiver device or by a server receiving the identifier from a receiver device. In an embodiment, the unique device identifier may be a code 56-bits in length. In various embodiments, for security purposes, this unique device identifier, along with other data (e.g., nonce or counter values), may be encoded, encrypted, or otherwise obfuscated when included within broadcast messages as a “rolling identifier.” Wireless identity transmitters may be configured to maintain inaccurate time (e.g., UTC) information, such as by using a 30 ppm 16 kHz crystal oscillator as a clock. In various figures and diagrams of this disclosure, wireless identity transmitters may be referred to as “WIT” or “WITs.” [0076] The algorithm (or rolling identifier algorithm) used in block 208 may generate a rolling identifier which is very difficult to predict or recognize by a device or system that does not know either an identity of the wireless identity transmitter 110 (e.g., a media access control address (MAC) or Bluetooth ID), a decode key, and/or the algorithm used to generate the rolling identifier. As discussed below, the central server 120, configured with the algorithm (or a decoding algorithm) or a decode key, and in possession of the wireless identity transmitter 110 identities, can use the rolling identifier to determine a corresponding account or device identity. While method 200 shows the rolling identifier changing with every wake and broadcast cycle as one example, in other embodiments the identifier may be changed less frequently, such as once per minute, once per hour, etc. In such embodiments, the operation of generating a new identifier in block 208 may be performed only at the designated interval, so at other times upon waking (i.e., block 206) the wireless identity transmitter 110 may return to block 202 to broadcast the identifier. Various algorithms for generating rolling identifiers or other encoded identifiers are discussed in the related applications incorporated by reference above. In an embodiment, the rolling identifier and other information may be communicated within the payload of a Standard Bluetooth LE message packet format (or packet type)).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by RAINA, Kim and Bergdale to include wherein the expected beacon value is based on a rolling code. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to determine whether a proximity beacon device has detected movement, determine whether obtained information matches stored data corresponding to the proximity beacon device, performing an abbreviated authentication operations for a computing device to access functionalities when it is determined that the obtained information from a received signal matches a stored data, and performing a normal authentication operations for the computing device to access the functionalities when it is determined that the obtained information from the received signal does not match the stored data as suggested by Brown ([0003]).
As per claim 11: Brown discloses the computing method of claim 10, wherein the rolling code uses at least one of a Pseudorandom Number Generator (PRNG) and a Hash-Based Message Authentication Code (HMAC) based one-time password ([0134] In block 913, the wireless identity transmitter may broadcast a message (i.e., a broadcast message) that includes an encoded (or rolling) identifier. For example, the wireless identity transmitter may begin transmitting broadcast messages every few seconds. The wireless identity transmitter may generate rolling identifiers with the embodiment methods described in the related applications incorporated herein. In an embodiment, the broadcast message may include an initial or default movement indicator value. The broadcast message may include a payload that includes data generated by performing a pseudo-random function. For example, the wireless identity transmitter may perform a pseudo-random function to generate encoded data based on input values of the wireless identity transmitter's device ID, a nonce or counter value, and a secret key, seed, or other value known only to the wireless identity transmitter and the central server. In an embodiment, the pseudo-random function may be a polynomial time computable function that may utilize a randomly selected seed value only known to the wireless identity transmitter and the central server, such that the pseudo-random function may be computationally indistinguishable from a random function defined on the same domain with output to the same range as the pseudo-random function. In an embodiment, the keyed-hash Message Authentication Code (HMAC) or the cipher-based Message authentication Code (CMAC) may be used as the pseudo-random function).
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Daoura et al. (US 20160182170 A1) in its disclosed invention installs software on a nearby smart device that converts it into a background “soft switch” for beacon traffic. The device detects a qualified beacon signal, timestamps it, optionally adds proximity or geostamp data, and forwards it to a cloud host without exposing the content to the phone owner. The cloud host then applies rules, context, and owner information to generate a response such as an alert or machine command. This lets many ordinary phones or smart devices act as anonymous community relays for beacon-to-cloud communication.
Main et al. (US 20150221149 A1) discuses uses of a two-channel workflow: a short local WiFi interaction to identify the user and location, followed by secure back-channel authentication over a mobile network. The phone app automatically joins a branded SSID, sends only a minimal token to the server, and receives a temporary shopper or access token if the server approves the combination. Sensitive cardholder data stays with the issuer/server and is not exposed to the merchant or access point. The same token-based framework is then reused for payments, logins, and physical access control
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LINGLAN EDWARDS can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408
Prosecution Insights