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 .
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”) view of Brown et al. (US 20150356289 A1—hereinafter—" Brown”) 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 in view of Bergdale et al. (US 20180293523 A1 –Hereinafter—Bergdale).
Based on amendment to claim 20, the rejected of claim under 35 U.S.C. 101 as being non-statutory subject matter has been withdrawn.
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 Bergdale et al. (US 20180293523 A1 –Hereinafter—Bergdale).
As per claim 1:
RAINA discloses a computer method comprising:
Sending, by a first computing device, a location challenge to a mobile computing device, the location challenge identifying a 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. 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 an 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 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 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”) 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 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 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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