Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
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 02/09/2026 has been entered.
This Office Action is in response to the communication and claim amendment filed on 02/09/2026; claims 1, 2, 8, 9, 12, and 17 have been amended; claims 1, 9, and 17 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 01/26/2024, with respect to limitations listed below, have been fully considered but they are not persuasive.
A. Applicants argue: Ulewicz does not disclose or suggest “generating, by a computing device, one or more hashes for a set of authenticated regions, wherein the one or more hashes are generated using a key associated with the computing device, and wherein the one or more hashes are provided to a server as part of a region registration process; … wherein the server authenticates the computing device based on a comparison of the corresponding hash of the plurality of hashes and the one or more hashes generated for the set of authenticated regions.” (Remarks page 8).
The Examiner respectfully disagrees with the Applicants.
Ulewicz teaches generating, by a computing device, one or more hashes for a set of authenticated regions (Ulewics: par. 0078: "generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations"; par. 0030), wherein the one or more hashes are generated using a key associated with the computing device (Ulewics: par. 0043, The secret key 128 may be private to the client 120 such that the secret key 128 is known only by the client 120 or entities granted access by the client 120, such the end user devices 120 [] the secret key 128 may be the same as the secret key 118 to maintain consistency between the format, encoding, or encryption of the encrypted geospatial index 119 and the encrypted device location identifier 129; par. 0089, the secret key used by the user device is the same as the secret key used by the client device such that the same secret key is shared by the user device and the client device; par. 0078, generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations of the one or more locations according to a secret key, at 606), and wherein the one or more hashes are provided to a server as part of a region registration process (Ulewicz: par. 0028, The client 110 may establish one or more geofence locations 112"; par. 0035, The client 110 may send a request to establish a geofence with the geofence service 130 [] the client 110 may send the encrypted geofence locations in addition to the encrypted geospatial index 119 as part of the request to establish the geofence; par. 0019, The geofence service may receive the encrypted identifiers and store the encrypted identifiers to a data store or a database for the geofence of the client; par. 0082, par. 0084, storing or updating the encrypted geospatial index at a data store according to the geofence identifier; par. 0019,.. The geofence service may then determine whether another device is located within the geofence based on querying the database).
Ulewicz further discloses wherein the server authenticates the computing device based on a comparison of the corresponding hash of the plurality of hashes and the one or more hashes generated for the set of authenticated regions (Ulewicz: par. 0023: "The geofence service may receive an encrypted geospatial index for a specified geofence comprising a geofence location hash value generated based on application of a hash function to respective ones of a plurality of locations for the specified geofence...determine whether the user device is located in a location of the plurality of locations based on a query of the encrypted geospatial index according to the encrypted device location identifier"; par. 0031, "the hashed representation of the geofence locations 112 may include a plurality of hash values that represent a hierarchical structure"; par. 0078: "generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations"; par. 0046: "the geofence logic 132 may determine whether the end user device 120 is currently located within one or more of the geofence locations 112 based on querying the geofence database 142 according to the encrypted device location identifier"; par. 0047: "The geofence logic 132 may be configured to determine whether there is a match or an inclusion of the encrypted device location identifier 129 within the encrypted geospatial index 146"; par. 0048: "the geofence logic 132 may implement a query of the encrypted geospatial index 146 according to the encrypted device location identifier 129...determine whether hash values of the encrypted device location identifier 129 are included within the encrypted geospatial index 146"; par. 0049: "If the encrypted geospatial index 146 for the specified geofence includes at least a portion of the encrypted device location identifier...then the geofence logic 132 may determine that the end user device 120 is within one or more of the geofence locations 112"; pars. 0096-0097, Fig. 9 steps 906-908: "querying the encrypted geospatial index according to the encrypted device location identifier...determining whether the encrypted device location identifier is included in the encrypted geospatial index; See also, par. 0019, The geofence service may receive the encrypted identifiers and store the encrypted identifiers to a data store or a database for the geofence of the client; par. 0084, storing or updating the encrypted geospatial index at a data store according to the geofence identifier).
B. Applicants argue: Ulewicz individually and asserts that each paragraph 0019, 0028, 0030, 0043, 0078, and 0088-0089 standing alone, does not teach the claimed comparison (Remarks, pages 9-10).
The Examiner respectfully disagrees with the Applicants.
Applicant's approach of isolating individual paragraphs and arguing that each paragraph alone does not teach the comparison is not persuasive. It is well established that a reference must be considered as a whole, not on a paragraph-by-paragraph basis. See MPEP § 2141.02. The paragraphs cited in the rejection were not cited for the proposition that each individually teaches the comparison. Rather, they were cited collectively to establish the complete system: paragraphs 0019, 0028, 0030, 0078, and 0084 establish the registration side (generating and storing hashes for authenticated regions); paragraphs 0043, 0088, and 0089 establish the authentication side (generating hashes from the device's current location); and paragraphs 0046-0049, 0096-0097, and FIG. 9 steps 906-908 establish the comparison and authentication determination by the server.Notably, the paragraphs that most directly teach the claimed comparison — pars. 0046-0049 and 0096-0097 — are not addressed by Applicant's paragraph-by-paragraph analysis. These paragraphs teach:
Par. 0047: "The geofence logic 132 may be configured to determine whether there is a match or an inclusion of the encrypted device location identifier 129 within the encrypted geospatial index 146."Par. 0048: "the geofence logic 132 may implement a query of the encrypted geospatial index 146 according to the encrypted device location identifier 129...determine whether hash values of the encrypted device location identifier 129 are included within the encrypted geospatial index 146."
Par. 0049: "If the encrypted geospatial index 146 for the specified geofence includes at least a portion of the encrypted device location identifier...then the geofence logic 132 may determine that the end user device 120 is within one or more of the geofence locations 112."
Pars. 0096-0097, FIG. 9 steps 906-908: "querying the encrypted geospatial index according to the encrypted device location identifier...determining whether the encrypted device location identifier is included in the encrypted geospatial index."
These paragraphs teach the server-side comparison between the device's location hashes and the stored geofence hashes to make an authentication determination.
C. Applicants argue: Regarding paragraphs 0088 and 0089, "this section of ULEWICZ specifically refer applying the hash function to the current location of the user device. This section of ULEWICZ does not refer to a region. In fact, ULEWICZ discloses a distinction between a current location and a region. Additionally, and more specifically, this section of ULEWICZ does not disclose or suggest applying a hash function to a region." (Remarks, page 10).
The Examiner respectfully disagrees with the Applicants.
Ulewicz does not hash a raw location coordinate as a single point. Rather, par. 0088 teaches that the device first converts the current location into "one or more numerical representations of the current location of the user device, individual ones of the one or more numerical representations have different levels of precision of location tracking, at 804." Par. 0088 further teaches that "The one or more numerical representations may correspond to the cells 402 of FIG. 4, according to some embodiments," and that "The cells may be expressed as numerical values of varying levels of precision, such as zoom levels per cell." Par. 0059 confirms: "The cells 402 may represent different resolutions of cells corresponding to different degrees of precision in identifying the current location." These cells are geographic areas, not points. A cell at lower level covers a large geographic area (e.g., an entire city), while a cell at a high precision level covers a small geographic area (e.g., a single building or street block). Each cell, regardless of its precision level, defines a bounded geographic area — which is, by definition, a region.The hash function is then applied to these cell representations, not to raw point coordinates. Par. 0089 teaches: "generating an encrypted device location identifier for the current location based on applying a hash function to the one or more numerical representations of the current location according to a secret key." The "one or more numerical representations" are the cells — geographic regions at varying precision levels. Under BRI, there is no meaningful distinction between a "location" expressed as a geographic cell at a given precision level and a "region." Both refer to a bounded geographic area. The claim term "region" does not require any particular size, shape, or method of definition. Ulewicz's cells at multiple precision levels — each representing a geographic area of a different size — read on the claimed "plurality of regions associated with the location information" and the data for each cell constitutes "region data." Furthermore, the same cell-based representation applies to both sides of the system. The geofence locations are also represented as cells at multiple precision levels (par. 0031: "the hashed representation of the geofence locations 112 may include a plurality of hash values that represent a hierarchical structure"; par. 0023: "a plurality of locations for the specified geofence"). Ulewicz uses the same geospatial indexing approach for both the registration side (geofence locations → cells → hashes → stored in encrypted geospatial index) and the authentication side (current location → cells → hashes → encrypted device location identifier). Both sides operate on cells representing geographic regions, not on raw coordinates. Therefore, when the server performs the comparison of the corresponding hash of the plurality of hashes and the one or more hashes generated for the set of authenticated regions, it is comparing hashes of regions against hashes of regions.
D. Applicants argue: In the conclusion of Applicant's argument, Applicant draws a distinction between Ulewicz's disclosure and the claimed comparison. Applicant states: "Rather, and in stark contrast, ULEWICZ discloses 'determining whether the encrypted device location identifier [generated based on the current location of the user device] is included in the encrypted geospatial index.'" (Remarks, page 11).
The Examiner respectfully disagrees with the Applicants.
Claim 1 recites "the server authenticates the computing device based on a comparison of the corresponding hash of the plurality of hashes and the one or more hashes generated for the set of authenticated regions." The claim does not specify any particular mechanism, algorithm, or data structure for performing the comparison. Under BRI, "comparison" encompasses any process for determining correspondence between received data and stored reference data. Determining whether hash values are "included within" other hash values necessarily requires comparing those hash values. An inclusion determination is, by its very nature, a comparison — the system must evaluate the device's hash values against the stored hash values to determine whether a match exists. There is no way to determine "inclusion" without comparing the values.Ulewicz's own language confirms this is a comparison. Par. 0047 teaches that the geofence logic determines "whether there is a match or an inclusion" — the word "match" itself denotes a comparison operation. Par. 0048 teaches the server "determine[s] whether hash values of the encrypted device location identifier 129 are included within the encrypted geospatial index 146." This is an operation where the server takes one set of hash values (from the device) and evaluates them against another set of hash values (stored from registration) to produce a yes/no determination. That is a comparison of hash values. Par. 0049 confirms the conditional nature: "If the encrypted geospatial index 146 for the specified geofence includes at least a portion of the encrypted device location identifier...then the geofence logic 132 may determine that the end user device 120 is within one or more of the geofence locations 112." This if-then determination — if stored hashes include the device's hashes, then authenticate — is the result of comparing hash values, satisfying the claim limitation "based on a comparison."Furthermore, the two sides of the comparison are clearly present in Ulewicz: (1) "The corresponding hash of the plurality of hashes" = the encrypted device location identifier 129, which contains hash values generated from the device's current location at multiple precision levels (pars. 0042, 0089). These are the hashes sent by the device.
(2) "The one or more hashes generated for the set of authenticated regions" = the encrypted geospatial index 146, which contains geofence location hash values generated by applying a hash function to the geofence locations and stored in the geofence database 142 (pars. 0023, 0031, 0078, 0019, 0084). These are the hashes provided to the server as part of the registration process.
Par. 0023 alone teaches the complete comparison framework: "The geofence service may receive an encrypted geospatial index for a specified geofence comprising a geofence location hash value generated based on application of a hash function to respective ones of a plurality of locations for the specified geofence...determine whether the user device is located in a location of the plurality of locations based on a query of the encrypted geospatial index according to the encrypted device location identifier." This teaches receiving registered hashes, storing them, and querying (comparing) them against device location hashes to make an authentication determination.Applicant appears to argue that a "comparison" requires something different from or more than an inclusion check. However, the claim does not require any particular type of comparison (e.g., bitwise equality, exact string matching, numerical comparison). Checking whether hash values of the encrypted device location identifier are included within the encrypted geospatial index is a comparison of hash values that produces an authentication result (match/non-match), which is exactly what claim requires.
E. Applicants argue: Applicant states that independent claims 9 and 17 recite features similar to claim 1 (Applicant’s argument page 11).
The Examiner respectfully disagrees with the Applicants.
Claims 9 and 17 are similar to the limitations of claim 1. The Examiner's responses to claim 1 (Please, see response to section A above for more details).
F. Applicants argue: Applicant states that claims 3, 4, 8, 11, 12, 16, and 19 are not anticipated by Ulewicz (Applicant’s argument page 11).
The Examiner respectfully disagrees with the Applicants.
Applicant states generally that claims 3, 4, 8, 11, 12, 16, and 19 are not anticipated by Ulewicz but does not provide specific arguments explaining which limitations of these dependent claims are not disclosed by Ulewicz or why the cited portions of Ulewicz fail to teach these limitations.
The Examiner's detailed rejections set forth in the Office Action specifically identified where each limitation of claims 3, 4, 8, 11, 12, 16, and 19 is disclosed in Ulewicz with citations to specific paragraphs and figures. Applicant has not rebutted these specific findings.
G. Applicants argue: The cited portions of the additional references do not remedy the deficiencies of Ulewicz with respect to the above features of claim 1. Independent claims 9 and 17 recite similar features. For at least the foregoing reasons, claims 2, 5-7, 10, 13-15, and 18-20 are patentable over Ulewicz and the additional references (Applicant’s argument pages 11-12).
The Examiner respectfully disagrees with the Applicants.
As explained above, Ulewicz teaches all limitations of independent claims 1, 9, and 17. The additional references cited in the § 103 rejections are used to teach limitations of dependent claims 2, 5-7, 10, 13-15, and 18-20, not to remedy any deficiencies of Ulewicz with respect to the independent claims. Therefore, the rejections of claims 2, 5-7, 10, 13-15, and 18-20 under 35 U.S.C. § 103 are maintained.
The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation /rejections, please contact the Examiner at (571) 270 1380 to schedule an interview.
Claim Rejections - 35 USC § 103
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, 3-4, 9, 11-12, 16-17, and 19 are under 35 U.S.C. 103 as being unpatentable over Ulewicz (“Ulewicz,” US 2023/0069458, published on Mar. 2, 2023), in view of West (“West,” US 2014/0031011, publishes on Jan. 30, 2014).
Regarding claim 1, Ulewics teaches a method for obscured location verification, the method comprising:
generating, by a computing device, one or more hashes for a set of authenticated regions (Ulewics: par. 0078: "generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations"; par. 0030), wherein the one or more hashes are generated using a key associated with the computing device (Ulewics: par. 0043, The secret key 128 may be private to the client 120 such that the secret key 128 is known only by the client 120 or entities granted access by the client 120, such the end user devices 120 [] the secret key 128 may be the same as the secret key 118 to maintain consistency between the format, encoding, or encryption of the encrypted geospatial index 119 and the encrypted device location identifier 129; par. 0089, the secret key used by the user device is the same as the secret key used by the client device such that the same secret key is shared by the user device and the client device; par. 0078, generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations of the one or more locations according to a secret key, at 606), and wherein the one or more hashes are provided to a server as part of a region registration process (Ulewicz: par. 0028, The client 110 may establish one or more geofence locations 112"; par. 0035, The client 110 may send a request to establish a geofence with the geofence service 130 [] the client 110 may send the encrypted geofence locations in addition to the encrypted geospatial index 119 as part of the request to establish the geofence; par. 0019, The geofence service may receive the encrypted identifiers and store the encrypted identifiers to a data store or a database for the geofence of the client; par. 0082, par. 0084, storing or updating the encrypted geospatial index at a data store according to the geofence identifier; par. 0019,.. The geofence service may then determine whether another device is located within the geofence based on querying the database.);
obtaining, by the computing device, location information associated with the computing device (Ulewicz: fig. 8, step 802 "Determine a current location of a user device according to a location sensor of the user device"; par. 0087, determining a current location of a user device according to a location sensor of the user device, at 802. The location sensor may correspond to the location sensor 122 of FIG. 1, according to some embodiments. The location sensor may include GPS hardware configured to determine the current location);
generating, by the computing device, a hash of region data (Ulewicz: fig. 8, step 806, "Generate one or more hashed representations of the current location based on applying a hash function to the one or more numerical representations of the current location according to a secret key"; par. 0089) for each of a plurality of regions associated with the location information (Ulewicz : fig. 8, step 804, "Determine one or more numerical representations of the current location of the user device, individual ones of the one or more numerical representations have different levels of precision of location tracking"; par. 0088, determining one or more numerical representations of the current location of the user device, individual ones of the one or more numerical representations have different levels of precision of location tracking, at 804. The one or more numerical representations may correspond to the cells 402 of FIG. 4, according to some embodiments. The user device may be configured to perform conversion operations to transform the current location to one or more cells according to a geospatial indexing algorithm, according to some embodiments. The cells may be expressed as numerical values of varying levels of precision, such as zoom levels per cell) using the key to produce a plurality of hashes (Ulewicz: fig. 8, step 806, "Generate one or more hashed representations of the current location based on applying a hash function to the one or more numerical representations of the current location according to a secret key"; par. 0043, par. 0089, …The hash function may output hash values for the numerical representations that are one-directional in nature, such that the hash values cannot be converted back to the numerical representations of the geofence locations, according to some embodiments. For example, the hash values may be encoded to obfuscate or encrypt the information that would otherwise identify the geofence locations to the geofence service.);
sending, by the computing device, the plurality of hashes to the server (Ulewicz; fig. 8, step 812, "Send the one or more hashed representations [ ... ] to a geofence service"; par. 0092, sending the one or more hashed representations and the encrypted the encrypted device location identifier and the encrypted representation of the current location to a geofence service to allow the geofence service to determine whether the user device is within a geofence, at 812. In some embodiments, the user device may send the encrypted device location identifier and the encrypted representation of the current location to the geofence service via a network connection; See also par. 0088: "determining one or more numerical representations of the current location of the user device, individual ones of the one or more numerical representations have different levels of precision of location tracking"; par. 0089: "generating an encrypted device location identifier for the current location based on applying a hash function to the one or more numerical representations of the current location according to a secret key” par. 0042: "the hashed representation of the current location may include a plurality of hash values that represent a hierarchical structure...different levels of precision"; par. 0059: "The cells 402 may represent different resolutions of cells corresponding to different degrees of precision in identifying the current location"); and
receiving, by the computing device (Ulewicz; fig 9. Step 910, "Send a notification to an event bus"; par 64 "The event bus service 520 may be configured to receive indications of events [ ... ] to interface with other services and external clients such as [ ... ] user devices"), authentication information from the server (Ulewicz; fig. step 910, "a notification [ ... ] indicating that the current location of the user device is within the one or more locations of the geofence", par. 0098; par. 0093, fig. 9, Illustrates[ ... ] a method 900 [ ... ] The method 900 may be performed by a geofence service " ), authentication information from the server indicative of whether one or more of the plurality of regions is authenticated based upon a corresponding hash from the plurality of hashes (Ulewicz:par. 0098, Fig. 9 step 910: "sending a notification to an event bus indicating that the current location of the user device is within the one or more locations of the geofence"; par. 0099: "sending a notification to the event bus indicating that the current location of the user device is not within the one or more locations of the geofence"; par. 0064: "The event bus service 520 may be configured to receive indications of events from the various services throughout the provider network 500 to interface with other services and external clients such as clients 550 and user devices 552"; par. 0050: "the geofence service 130 may indicate to an event bus 160 whether the end user device 120 is located within the geofence locations 112...The event bus 160 may be configured to send an indication as to whether the end user device 120 is located within the geofence locations 112 to the client 110"; par. 0023: "based on a determination that the user device is located in the location of the plurality of locations, provide an indication that the user device is located in the location of the plurality of locations".),
wherein the server authenticates the computing device based on a comparison of the corresponding hash of the plurality of hashes and the one or more hashes generated for the set of authenticated regions (Ulewicz: par. 0023: "The geofence service may receive an encrypted geospatial index for a specified geofence comprising a geofence location hash value generated based on application of a hash function to respective ones of a plurality of locations for the specified geofence...determine whether the user device is located in a location of the plurality of locations based on a query of the encrypted geospatial index according to the encrypted device location identifier"; par. 0031, "the hashed representation of the geofence locations 112 may include a plurality of hash values that represent a hierarchical structure"; Par. 0078: "generating an encrypted geospatial index of the one or more locations based on applying a hash function to the one or more numerical representations"; par. 0046: "the geofence logic 132 may determine whether the end user device 120 is currently located within one or more of the geofence locations 112 based on querying the geofence database 142 according to the encrypted device location identifier"; par. 0047: "The geofence logic 132 may be configured to determine whether there is a match or an inclusion of the encrypted device location identifier 129 within the encrypted geospatial index 146"; par. 0048: "the geofence logic 132 may implement a query of the encrypted geospatial index 146 according to the encrypted device location identifier 129...determine whether hash values of the encrypted device location identifier 129 are included within the encrypted geospatial index 146"; par. 0049: "If the encrypted geospatial index 146 for the specified geofence includes at least a portion of the encrypted device location identifier...then the geofence logic 132 may determine that the end user device 120 is within one or more of the geofence locations 112"; pars. 0096-0097, Fig. 9 steps 906-908: "querying the encrypted geospatial index according to the encrypted device location identifier...determining whether the encrypted device location identifier is included in the encrypted geospatial index; See also, par. 0019, The geofence service may receive the encrypted identifiers and store the encrypted identifiers to a data store or a database for the geofence of the client; par. 0084, storing or updating the encrypted geospatial index at a data store according to the geofence identifier.).
Ulewicz teaches “generating, by a computing device, one or more hashes for a set of authenticated regions, … the one or more hashes are provided to a server as part of a region registration process;” (i.e. registration process) is performed by client 110, while “obtaining, by the computing device, location information associated with the computing device;” “generating, by the computing device, a hash of region data for each of a plurality of regions ..;” ;”sending, by the computing device, the plurality of hashes to the server;” and “receiving, by the computing device, authentication information from the server … corresponding hash from the plurality of hashes,” (i.e. subsequent location-based authentication process with server) is performed by end user device 120.
Ulewicz does not explicitly teach that a single computing device performs both the registration and subsequent location-based authentication process with server.
However, in an analogous art, West teach the concept that a single computing device performs both the registration of geographic locations with a server and the subsequent location-based authentication with that server (West: par. 0012, “at 110, The location-based authentication manager "registers a mobile device for location-based authentication services." par. 0013, at 111 "the location-based authentication manager interacts with a user via an application that processes on the mobile device. So, the mobile device being registered with the location-based authentication manager is used to interact with the location-based authentication manager for registration."; par. 0015. As part of registration, the location-based authentication manager "associates or links together: a geographical location for the mobile device, an identifier for the mobile device, an identity for the user, and an authentication policy."; pars. 0015-0018; par. 0021, “the location-based authentication manager defines the authentication policy as actions to take when the mobile device is within a predefined range of the registered geographical location for the mobile device [...]”; par. 0022, As used herein, 'geofence' refers to a known or registered geographical location around or within proximity to geographical coordinates; par. 0025, "the location-based authentication manager enforces the registered authentication policy when the user subsequently attempts to access a secure network resource that requires authentication. This is done on behalf of the user and the mobile device and is based on the geographical location of the mobile device when the attempt is made by the user to access the secure network resource."; par. 0026, "the location-based authentication manager automatically provides registered credentials to the secure network resource on behalf of the user in order to automatically authenticate the user for access to the secure network resource based on dynamic evaluation of the authentication policy and a dynamically resolved current geographical location of the mobile device."; Abstract, "A user pre-registers a mobile device and a geographical location with a location-based authentication service. When the user attempts to access a target resource from the mobile device, a current location for the mobile device is resolved and communicated to the location-based authentication service.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of West to have modified the method and system of Ulewicz such that the end user device — rather than a separate client device — performs the registration of authenticated regions (generating hashes for geofence locations and providing them to the server), as taught by West. One of ordinary skill would have been motivated to make this modification for at least the following reasons:
(1) Ulewicz already equips the end user device 120 with all the cryptographic tools necessary to perform registration — specifically, the same hash function and the same secret key used by Client 110. Thus, the end user device is already technically capable of performing the registration step.
(2) West demonstrates that having a single device perform both registration and subsequent location-based authentication is a known design pattern in the art (West, pars. 0012-0015, 0025-0026), confirming that consolidating these functions onto a single device was a recognized approach.
(3) Consolidating the registration and authentication functions onto a single device would simplify system architecture by eliminating the need for a separate client system to perform registration, thereby reducing deployment complexity and allowing individual users to manage their own authenticated regions directly from their mobile device.
There would have been a reasonable expectation of success because Ulewicz's end user device 120 already possesses all the necessary components — the hash function, the secret key, and the geospatial indexing capability — to execute the registration process in addition to the authentication process. The modification merely involves having the same device execute both processes, which West confirms is a functional and effective architecture.
Regarding claim 3, the combination of Ulewicz and West teaches the method of claim 1. The combination of Ulewicz and West further discloses wherein the key is a device-specific key associated with the computing device location (Ulewciz: par. 0089, based on applying a hash function to the one or more numerical representations of the current location according to a secret key; par. 0092, the user device may send the encrypted device location identifier and the encrypted representation of the current location to the geofence service via a network connection; par. 0043, the secret key 128 may be private to the client 120; par. 0078).
Regarding claim 4, the combination of Ulewicz and West teaches the method of claim 1. The combination of Ulewicz and West further discloses, wherein the region data for each of the plurality of regions comprises a region size of each of the associated regions (Ulewicz: par. 0052, the geofence 210 is a different size and shape from the geofence 212. The different size and shape may be different levels of precision of geofenced locations in order to focus in on particular locations; par. 0088, the one or more numerical representations may correspond to the cells 402 of FIG. 4, according to some embodiments. The user device may be configured to perform conversion operations to transform the current location to one or more cells according to a geospatial indexing algorithm …; fig. 4, par. 0059 The cells 402 may be generated from a geometric representation of the current location; par. 0052).
Regarding claim 9, claim 9 is directed to an apparatus for obscured location verification, the apparatus comprising a computer processor (Ulewicz: pars. 0106,0107), a computer memory (Ulewicz: pars. 0106,0107), operatively coupled to the computer processor, the computer memory having disposed within it computer program instructions that, when executed by the computer processor, cause the apparatus to associated with the method claimed in claim 1; claim 9 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Regarding claim 16, the combination of Ulewicz and West teaches the method of claim 9. The combination of Ulewicz and West further discloses, wherein the server is configured to authenticate the computing device based upon a comparison of the corresponding hash for each of the plurality of regions to one or more hashes associated with a set of authenticated regions (Ulewicz: par. 0023, The geofence service may further receive an encrypted device location identifier comprising a hash value generated based on application of the hash function to a representation of a current location of a user device in accordance with the secret key; determine whether the user device is located in a location of the plurality of locations based on a query of the encrypted geospatial index according to the encrypted device location identifier. The geofence service may further based on a determination that the user device is located in the location of the plurality of locations, provide an indication that the user device is located in the location of the plurality of locations; par. 0093, determining whether a user device is in a geofence location based on an encrypted device location identifier..; pars. 0096-0097, querying the encrypted geospatial index according to the encrypted device location identifier, at 906..; fig. 9, (908) ; par. 0088-0089, individual ones of the one or more numerical representations have different levels of precision of location …The hash function may output hash values; par. 0019, The geofence service may receive the encrypted identifiers and store the encrypted identifiers to a data store or a database for the geofence of the client; par. 0084, storing or updating the encrypted geospatial index at a data store according to the geofence identifier).
Regarding claim 17, claim 17 is directed to a computer program product for obscured location verification, the computer program product disposed upon a computer readable storage device, the computer program product comprising computer program instructions that, when executed, cause a computer to associated with the method claimed in claim 17; claim 17 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Claims 2, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ulewicz (“Ulewicz,” US 2023/0069458, published on Mar. 2, 2023), in view of West (“West,” US 2014/0031011, publishes on Jan. 30, 2014), further in view of Arunkumar et al. (“Arunkumar,” US 9,473,511, published on Oct. 18, 2016).
Regarding claim 2, the combination of Ulewicz and West teaches the method of claim 1. The combination of Ulewicz and West further teaches generating, by the computing device, a hash of region data for each of a plurality of regions associated with the location information using a key associated with the computing device to produce a plurality of hashes. Ulewicz and West do not explicitly teach “wherein the key comprises a passphrase received from a user of the computing device, and wherein the hash region of data for each of the plurality of regions is generated using passphrase.”
However, in an analogous art, Arunkumar teaches wherein the key comprises a -9passphrase received from a user of the computing device (Arunkumar: Col. 3, lines 33-49, policy program 120 receives a username and password provided by a client device ( e.g., client device 104) or some other authentication method 35 known by one skilled in the art, which verifies that the specific identification is the actual user or machine that is trying to access the secure connection. …).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Arunkumar with the method and system of Ulewicz and West to include “wherein the key comprises a passphrase received from a user of the computing device, and wherein the hash region of data for each of the plurality of regions is generated using passphrase.” One would have been motivated to recognize that using a user-supplied passphrase as the key for hashing region data is a known design choice to enhance user control security, and would substitute it for the static or device-based in Ulewicz without the need for inventive ingenuity.”
Regarding claim 10, claim 10 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Claims 5, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ulewicz (“Ulewicz,” US 2023/0069458, published on Mar. 2, 2023), in view of West (“West,” US 2014/0031011, publishes on Jan. 30, 2014), further in view of Rajadurai et al. (“Rajadurai,” US 2022/0116774, published on Apr. 14, 2022)
Regarding claim 5, the combination of Ulewicz and West teaches the method of claim 1. The combination of Ulewicz and West further teaches a method for obscured location verification using encrypted device location identifiers and hash geospatial indexes (Ulewicz: fig. 9, pars. 0093-0099). The combination of Ulewicz and West further teaches teaches sending authentication information via a notification system (Ulewicz: par. 0098, sending a notification to an event bus indicating that the current location of the user device is within the one or more locations of the geofence based on results of the query, where the notification includes the one or more encrypted representation, at 910). Ulewicz and West do not explicitly disclose establishing a session between the device and a server based on the authentication information.
However, in an analogous art, Rajadurai discloses establishing a session between the device and a serv er based on the authentication information (Rajadurai: par. 0041, provisioning required credentials and establish a secure session/connection between the UE and the server for accessing edge computing services, based on a successful authentication and authorization of the UE and the server).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Rajadurai with the method and system of Ulewicz and West to include establishing a session between the device and a server based on the authentication information. One would have been motivated to provide the method enables performing mutual authentication between the UE and the server using the PSK so as to establish a secure connection for the edge computing service (Rajadurai: pars. 0018, 0042).
Regarding claim 13, claim 13 is similar in scope to claim 5, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is similar in scope to claim 5, and is therefore rejected under similar rationale.
Claims 6-7 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ulewicz (“Ulewicz,” US 2023/0069458, published on Mar. 2, 2023), in view of West (“West,” US 2014/0031011, publishes on Jan. 30, 2014), further in view of Delucas et al. (“Delucas,” US 2019/0164081, published on May 30, 2019).
Regarding claim 6, the combination of Ulewicz and West teaches the method of claim 1. Ulewicz and West do not explicitly teach, further comprising receiving an indication from the server of valid region sizes for the plurality of regions.
However, in an analogous art, Delucas further discloses comprising receiving an indication from the server of valid region sizes for the plurality of regions (Ulewicz: par. 0049, "manager system 110 can generate one or more additional candidate geofences having sizes based on the size of the specified nominally sized geofence, e.g. having one or more sizes incrementally larger and/or incrementally smaller. In one aspect, a purpose and function of the candidate geofences generated at predicting block 1107 can be to visualize performance of candidate geofences of different sizes."; par. 0066, manager system 110 can send geofence information to computer devices of user computer devices 130A-130Z for receipt by computer devices of user computer devices 130A-130Z at block 1304.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Delucas with the method and system of Ulewicz and West to include “receiving an indication from the server of valid region sizes for the plurality of regions.” One would have been motivated to provide the machine learning processes are performed for increased accuracy and for reduction of reliance on rules based criteria and thus reduced computational overhead. The potential network loading events are intelligently reduced by intelligent management of notifications to users. The distribution of geofence breach detection logic to user computer devices for local on-device breach detection improves computer network performance, e.g., in terms of bandwidth and power conservation, speed and reliability (Delucas; par 0072).
Regarding claim 7, the combination of Ulewicz, West, and Delucas teaches the method of claim 6. The combination of Ulewicz, West, and Delucas further discloses comprising receiving a selection of a region sizes from among the valid regions sizes for each of the plurality of regions from a user of the computing device (Delucas: par. [0052] discloses: "geofence configurator administrator user interface 600 can be configured so that a user can use pointer 620 to point and click onto the depicted perimeter, e.g. perimeter 602 or 603 and then drag inward or outward to change the size of the depicted perimeter representing a geofence. The user can point and click onto a perimeter and then drag inward to make the perimeter, e.g. perimeter 602 or 603 smaller, or can point, click, and drag outward to make the perimeter, e.g. perimeter 602 or 603, larger."; par. 0049: "manager system 110 can generate one or more additional candidate geofences having sizes based on the size of the specified nominally sized geofence, e.g. having one or more sizes incrementally larger and/or incrementally smaller"; par. 0052, "In another aspect, geofence configurator administrator user interface 600 can be provided so that the user can enter a target number of breaches in area 614 or 616...In response to the user entering the specified target value, manager system 110 can automatically generate iteratively a number of candidate geofences having different perimeters and can automatically predict performance of each candidate geofence until a candidate geofence yielding the target number of breaches is determined."; par. 0050 "there is shown perimeter 602 representing the area of a first candidate geofence and perimeter 603 representing an area of a second candidate geofence...a user can view depictions of anticipated predicted numbers of breaches for the various depicted geofences of different size").
Regarding claim 14, claim 14 is similar in scope to claim 6, and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ulewicz (“Ulewicz,” US 2023/0069458, published on Mar. 2, 2023), in view of West (“West,” US 2014/0031011, publishes on Jan. 30, 2014), further in view of Patel et al. (“Patel,” 9,973,891, published May 15, 2018).
Regarding claim 8, the combination of Ulewicz and West teaches the method of claim 1. The combination of Ulewicz and West further disclose generating, by the computing device, the one or more hashes based on one or more region size limits (Ulewicz: fig. 8, step 806, "Generate one or more hashed representations of the current location based on applying a hash function to the one or more numerical representations of the current location according to a secret key"; par. 0089, par. 0052, the geofence 210 is a different size and shape from the geofence 212. The different size and shape may be different levels of precision of geofenced locations in order to focus in on particular locations; par. 0088, the one or more numerical representations may correspond to the cells 402 of FIG. 4, according to some embodiments), wherein the set of authenticated regions are selected based on one or more region size limits (Ulewics: par. 0052, the geofence 210 is a different size and shape from the geofence 212. The different size and shape may be different levels of precision of geofenced locations in order to focus in on particular locations; par. 0088, the one or more numerical representations may correspond to the cells 402 of FIG. 4, according to some embodiments.).
Ulewicz and West do not explicitly disclose receiving, from the server, information regarding one or more region size limits
However, in an analogous art, Patel discloses receiving, from the server, information regarding one or more region size limits (Patel: Col. 16, lines 22-23, The location management server 204 sends updated geofences definitions to the group member 202B (step 514); Col. 16, lines 30-33. Updating the geofence definition may include transmitting a new location of the geofence anchor or reference point, or transmitting a new shape/size of the encapsulated region; See also claim 32).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Patel with the method and system of Ulewicz and West to include receiving, from the server, information regarding one or more region size limits. One would have been motivated to do so because having the server provide size information without require device-side configuration. Patel recognizes this benefit, teaching that the server dynamically updates geofence definitions including shape/size to the device during runtime (Patel: Col. 16, lines 22-23, Col. 16, lines 30-33), thereby allowing the system to adapt region parameters as operational, condition change.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
March 1st, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439