DETAILED ACTION
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4-6, 16-20 is/are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by Thoresen et al. (US 20180270608 A1) (hereinafter Thoresen)
Regarding claim 1, Thoresen teaches A method for confirming arrival at a target location,
the method comprising: comparing, by one or more controllers, properties of a plurality of identifying features of the target location with properties of a corresponding plurality of corresponding features of a present location to result in a plurality of comparisons. (Thoresen [0061]– [0062], [0090]– [0092], Fig. 6A–6C). Thoresen’s server and/or edge sensor (the “controllers”) generate similarity metrics by comparing present-location probe request data to stored device profiles—where the probe request data includes multiple identifying features such as SSID, channel, supported rates, vendor info, timestamp, and signal strength—thereby comparing a plurality of properties across target vs. present features. Because multiple similarity metrics are produced and each is compared (e.g., against a similarity threshold).
identifying, by one or more controllers, the present location as the target location if the plurality of comparisons concludes that the present location is the target location. (Thoresen [0091]– [0093]; Fig. 10A; [0169]– [0170]). After generating the plurality of similarity metrics from the comparisons, Thoresen’s controller compares the metrics to a threshold and, upon a match, causes a location-based event—which is the controller’s identification that the present location corresponds to the target (e.g., payment zone, alert, or map display). This “identify-on-match” logic is explicitly tied to the result of the comparisons (metrics ≥ threshold).
wherein the properties of a plurality of identifying features of the target location include at least one property of one or more wireless communication networks expected to be detectable at the target location. (Thoresen [0061]– [0065]; Figs. 6A–6C. Thoresen lists wireless-network properties captured and used in the comparisons—SSID, BSSID/addresses, channel/frequency, supported rates, vendor information, signal strength, and timestamp—i.e., properties of networks detectable at the target and present locations (see the probe-request fields in Figs. 6A–6C). These explicit network properties are part of the “identifying features” compared by the controllers when establishing whether the present location matches the target location.
Regarding claim 4, Thoresen teaches the method of Claim 1,
wherein the one or more wireless communication networks are WIFI networks and the at least one property of the one or more wireless communication networks includes SSIDs or BSSIDs of the wireless communication networks. (Thoresen [0061]– [0065]; Figs. 6A–6C (SSID / BSS Id fields); Fig. 9 (903 device data processing; 907 event management). Thoresen’s edge sensors passively monitor Wi-Fi (802.11) probe-request frames and capture the SSID and BSS Id (BSSID) fields—explicitly shown in Figs. 6A–6C and described as part of the probe request “data/metadata”—which are properties of Wi-Fi networks detectable at the location. These captured SSID/BSSID values are then provided to the server’s device data processing subsystem (903) and event management (907) for comparison against stored profiles to verify/confirm presence at a target location, satisfying the claimed use of Wi-Fi network properties as identifying features.
Regarding claim 5, Thoresen teaches the method of Claim 4,
wherein the at least one property of the one or more wireless communication networks includes signal strengths of the one or more wireless communication networks. (Thoresen [0062]–[0065], [0081]– [0085]; Figs. 4–6A–6C, 8A, 9). Thoresen’s edge sensor passively monitors 802.11 traffic, copies header/frame details and metadata, and the frames “reveal… signal level,” with device locations determined “based on the signal strengths detected at each edge sensor,” thereby expressly teaching use of signal strength as a network property. Those signal-strength values are postprocessed by the server’s device data processing subsystem (903) to compute similarity/location metrics and trigger events, so signal strength is one of the compared properties used in confirming presence at a target location.
Regarding claim 6, Thoresen teaches the method of Claim 4,
wherein the at least one property of the one or more wireless communication networks includes radiofrequencies of the one or more wireless communication networks. (Thoresen Figs. 6B–6C (probe-request fields incl. “Current Channel”); text describing radio tap header fields “including the channel, the frequency”; Fig. 10A (generate similarity metrics by comparing probe-request data to stored device profiles). Thoresen passively monitors 802.11 probe-request frames and captures RF properties explicitly including channel and frequency (i.e., radiofrequencies), as shown by the radio tap header fields and the “Current Channel” parameter in the captured frames. Those RF properties are among the probe-request data the controller compares to stored device/network profiles to generate similarity metrics (Fig. 10A), thereby using radiofrequency properties as identifying features for target-location determination.
Regarding claim 16, Thoresen teaches A method for confirming arrival at a target location,
the method comprising: generating a comparison of a profile of wireless communication networks expected to be detectable at the target location with a profile of wireless communications networks detected at a present location. (Thoresen Fig. 10A (step 1055); [0091]– [0092]; [0061]– [0065] (probe-request fields SSID/BSSID, channel, rates, timestamp, signal strength). Thoresen expressly “generates similarity metrics by comparing probe request data for a monitored device (the present-location wireless profile consisting of SSID/BSSID, channel, supported rates, timestamps, signal strength) to stored device profiles (the expected profile used for a target/geofenced zone). This is a controller-executed comparison of the present wireless profile to an expected profile associated with the target zone, satisfying the claimed “generating a comparison” of profiles of wireless communication networks at the present vs. target location.
and identifying the present location as the target location if the comparison concludes that the present location is the target location. (Thoresen Fig. 10A (steps 1056–1057) [0092]– [0093]). after generating the comparison, Thoresen compares the similarity metrics to a similarity threshold and, when the comparison meets the threshold, causes a location-based event, i.e., identifies/acts on the device as being at the target location. This thresholder match is exactly the claimed condition “identify the present location as the target location if the comparison concludes” in favor of a match
Regarding claim 17, Thoresen teaches the method of Claim 16,
wherein the profile of wireless communication networks expected to be detectable at the target location includes one or more SSIDs or BSSIDs. (Thoresen [0061]– [0065], [0091]– [0093]; Figs. 6A–6C (SSID / BSS Id fields), 7. Thoresen’s controllers use profiles composed of Wi-Fi probe-request metadata—expressly including SSID and BSS Id (BSSID)—and compare live present-location probe-request data against stored profiles associated with target/geofenced locations. Because those stored target profiles include expected SSID/BSSID values and the system matches them to the SSID/BSSID observed at the present location to determine a similarity/match.
Regarding claim 18, Thoresen teaches the method of Claim 16,
wherein the profile of wireless communication networks expected to be detectable at the target location includes signal strengths, at the target location, of the wireless communications networks. (Thoresen [0061]– [0062]; Fig. 6A–6C (Fig. 11A) Thoresen’s edge sensors capture and store). Thoresen’s for observed Wi-Fi networks in probe-request metadata and aggregate this data to form a “bigger picture of the surveyed area” (i.e., a target-zone profile of expected networks and their observed strengths). The server then uses those stored signal-strength values in the comparison—e.g., determining location from signal strength (FSPL/trilateration) and matching present measurements to the stored profile.
Regarding claim 19, Thoresen teaches the method of Claim 16,
wherein the profile of wireless communication networks expected to be detectable at the target location includes radiofrequencies of the wireless communications networks. (Thoresen [0066], [0070], Fig. 6B–6C, Fig. 16B). Thoresen expressly captures RF properties—channel/frequency—from Wi-Fi probe-request frames via radio tap and shows those values (e.g., “Current Channel: 1”) in the captured metadata, and the edge sensor both listens on different frequencies and reports serialized data that includes the channel used, which are then stored/processed as part of device/network profiles. Because those stored profiles (used for geofenced target zones) include the captured channel/frequency fields and are compared against present measurements to generate similarity metrics, the profile “includes radiofrequencies” of the networks expected at the target location.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-3 are rejected under 35 U.S.C. §103 as being unpatentable over Thoresen (US 2018/0270608 A1) in view of Shveki (US 2021/0112427 A1)
Regarding claim 2, Thoresen teaches the method of Claim 1,
wherein the plurality of identifying features of the target location includes a visible street address number located at the target location. Thoresen ([0162]– [0165]; Figs. 6A–6C, 9) Thoresen system confirms arrival by comparing a present-location wireless “signature” (SSID/BSSID, channel, supported rates, timing/strength) against a stored profile and declaring a match at a similarity threshold. These passages show the controller compares properties captured from Wi-Fi probe traffic (e.g., SSID/BSSID, channel/rates) to stored device/network signatures and confirms presence when the similarity meets a threshold.
Thoresen does not disclose: An explicit visible street address number as an identifying feature. (Shveki 0220]– [0222]; Figs. 22–23) Shveki teaches XR device extracts visual features from camera images, computes image/key-frame descriptors and localizes by matching the present image to stored maps Because Shveki localizes using visually perceptible, persistent object features in the scene, a POSITA would treat street-address numeralson a building as a straightforward, stable visual marker to include among those features for location identification.
It would have been obvious to combine for robust, low-latency arrival confirmation; incorporate Shveki’s camera-based visual marker (street-number) into Thoresen’s profile-matching workflow so the controller can confirm with both RF fingerprints and a plainly visible, location-unique cue; this is a predictable use of known techniques (visual feature matching + Wi-Fi fingerprinting) to yield improved reliability in the same context of confirming a user’s location.
Regarding claim 3, Thoresen teaches the method of Claim 1,
wherein the plurality of identifying features of the target location includes at least one visible exterior feature of a building at the target location. Thoresen (Fig. 10A, steps 1055–1057; [0091]–[0093]; Figs. 6A–6C ) Thoresen teaches controllers confirm arrival by comparing present Wi-Fi probe-request metadata (e.g., SSID/BSSID, supported rates, channel/frequency, signal level) to stored profiles, generating similarity metrics, comparing them to a similarity threshold, and triggering an event on a match.
Thoresen does not disclose: Using a visible exterior feature of a building as one of the identifying features. (Shveki Fig. 22; Fig. 23; Figs. 6A–6B:) Shveki teaches Vision-based localization in which an XR device captures images of the physical environment and identifies surfaces/objects with CV and object recognizers, then localizes by computing descriptors. Shveki’s text and figures show outdoor scenes with buildings and mapping of world surfaces and explicitly describes keyframes tied to architectural features (e.g., door, window)—i.e., visible building features used for localization.
It would have been obvious to combine Shveki’s visible building-exterior cues (surfaces/objects recognized from camera images and matched via descriptors) with Thoresen’s RF profile-comparison workflow so the controller corroborates a Wi-Fi fingerprint using a stable visual landmark at the same location. This predictable fusion of known, complementary techniques in the same localization context improves last-meter accuracy and reduces RF-only false positives.
Claims 7–13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Thoresen (US 2018/0270608 A1) in view of Brachet (US 2016/0323704 A1)
Regarding claim 7, Thoresen teaches the method of Claim 1,
wherein the plurality of identifying features of the target location includes a walking profile of a route approaching the target location. Thoresen (Fig. 16B, and geofence checks at 1693–1694) Thoresen teaches controllers comparing present Wi-Fi probe-request data to stored profiles and triggering on a threshold, within geofenced zones.
Thoresen does not disclose: A “walking profile” per se. However (Brachet [0025]– [0027]). Brachet teaches: Client uses tile data and server tile store to estimate/update location; the predicted route and estimated speed/direction of the client are expressly used to determine the limited region/tiles
It would have been obvious to combine Brachet’s tile/route signals to derive a simple walking profile (sequence/shape along tiles) used as an additional identifying feature in Thoresen’s comparison, predictably hardening last-meter confirmation by leveraging the same positioning data both systems already compute.
Regarding claim 8, Thoresen teaches the method of Claim 7,
wherein the walking profile includes at least one of number of stairs in the walking profile, shape of the walking profile, length of the walking profile, and expected walking time to traverse the walking profile (Thoresen Fig. 10A) Thoresen provides the same compare/confirm controller pipeline Thoresen does not disclose: shape/length/expected-time attributes of a walking profile. However (Brachet [0020]– [0027]). Brachet teaches predicted route with estimated speed/direction over tile partitions—data from which a POSITA would compute route shape, distance/length, and expected time.
It would have been obvious to combine these route/speed/tile cues to compute shape/length/expected-time features and feed them into Thoresen’s similarity comparison, a routine enhancement yielding predictable accuracy gains.
Regarding claim 9, Thoresen teaches the method of Claim 1,
further comprising using a geofence to confirm proximity to the target location before comparing properties of a plurality of identifying features of the target location with properties of a plurality of corresponding features of the present location Thoresen (Fig. 16B, Steps 1693–1697) shows a flow that checks geofence/region before generating similarity metrics and comparing to a threshold.
Thoresen does not disclose: your exact “only after” gating phrasing. However (Brachet [0019]– [0023]). Brachet teaches narrowing to a limited region/tiles before deeper processing.
It would have been obvious to combine Brachet’s region-narrowing with Thoresen’s geofence/threshold flow to gate the comparison on geofence entry, reducing computation and false positives in a predictable way.
Regarding claim 10, Brachet teaches the method of Claim 1,
further comprising combining results of the plurality of comparisons to result in a confidence score; (Thoresen Fig. 10A, 1055–1057; [0091]– [0093]) teaches generating similarity metrics from multiple comparisons and using them in the controller’s decision flow but does not disclose combining those comparison results into a single aggregated confidence score.
Thoresen does not disclose: an aggregated confidence score from the plurality of comparisons. However (Brachet [0058], [0074]– [0076], [0117], Fig. 14). Brachet teaches weighting/aggregating multiple Wi-Fi observations (RSS-based quasi weighted average) and maintaining confidence factors for accuracy—i.e., combining multiple signals into a single reliability measure.
comparing the confidence score with a validation threshold. Thoresen (Fig. 10A, 1056; [0092]) expressly compares similarity metrics to a similarity threshold and proceeds based on the result.
Thoresen does not disclose applying that threshold to a single aggregated confidence score. However (Brachet [0058], [0074]– [0076], [0117], Fig. 14). Brachet teaches using the weighted/aggregated measure (confidence/reliability) as the basis for acceptance criteria.It would have been obvious to combine these teachings, so the aggregated confidence score is compared to a validation threshold, substituting a well-known single-score gate for multiple per-metric checks with predictable benefits (simpler, robust decisioning)
and identifying the present location as the target location if the confidence score is above the validation threshold. (Thoresen Fig. 10A, 1057; [0093]) Thoresen teaches causing a location-based event (i.e., confirming/acting on the location) when the threshold condition is met.
Thoresen does not disclose tying that event explicitly to an aggregated confidence score. However (Brachet [0074]– [0076], [0117], Fig. 14). Brachet teaches: the aggregated/weighted measure serves as the reliability gate for acceptance.
It would have been obvious to combine Brachet’s weighted/aggregated confidence factor with Thoresen’s plurality of similarity metrics, so the controller evaluates a single confidence score against a validation threshold—a predictable substitution of known gating mechanisms in the same WLAN localization context. By aggregating per-feature comparisons into one score, a POSITA would expect improved robustness to noisy RF measurements, simpler decision logic, and reduced false positives without changing Thoresen’s principle of operation—only routine data-fusion and thresholding are required.
Regarding claim 11, Brachet teaches the method of Claim 1,
further comprising updating a database record of properties of identifying features of the target location with a property of at least one identifying feature of the present location if the present location has been identified as the target location, wherein the database record is identified by a unique digital identifier. Thoresen (Fig. 10A, 1055–1057; Fig. 16B, 1693–1697) Thoresen teaches comparing present Wi-Fi probe-request data to stored profiles, generating similarity metrics, comparing them to a similarity threshold, and causing a location-based event upon a match within a geofenced zone.
Thoresen does not disclose performing a database update tied to that identification event, nor identifying the database record by a unique digital identifier. However (Brachet [0073]– [0076], [0116]–[0118], [0098]–[0105], Fig. 14, Fig. 20). Brachet teaches: the server parses upload and updates the master Wi-Fi AP location database by adding new APs and repositioning existing APs using a weighted model; the Network Server 1401 maintains the Master Wi-Fi Access Point Location Database 1406 which includes TileID information used to uniquely identify each tile, with TileIDs defined as the database’s global unique identifiers.
It would have been obvious to combine Thoresen’s identify-on-threshold flow with Brachet’s database update + TileID scheme so that, once the controller identifies the present location as the target, it updates the corresponding record(keyed by TileID/unique identifier) with the newly observed properties— a routine integration of known elements that improves future matching accuracy without changing the principle of operation.
Regarding claim 12, Brachet teaches A method for confirming arrival at a target location,
the method comprising: retrieving properties of a plurality of identifying features of the target location from a database populated based on prior observations made at the target location. (Brachet [0071]– [0073], [0096]– [0099], Fig. 6, Fig. 14). Brachet maintains a location database populated from prior observations (e.g., BSSID and RSS histories) for geographic tiles and retrieves those stored properties during positioning. These retrieved BSSID/RSS properties are the “properties of a plurality of identifying features of the target location” populated from prior observations and supplied for later comparison.
comparing the properties of the plurality of identifying features of the target location with properties of a corresponding plurality of corresponding features of a present location to result in a plurality of comparisons. (Thoresen [0091]– [0093], Fig. 10A) Thoresen’s Controllers compute similarity metrics by comparing present-location Wi-Fi features—e.g., SSID/BSSID, channel/frequency, RSS, timing—against stored profile values, thereby producing multiple per-feature comparisons (a plurality of comparisons).
Thoresen does not disclose: That the target-side properties used in those comparisons are retrieved prior-observation records for the target location. (Brachet [0071]– [0074], Figs. 6, 14) Brachet teaches a location database populated from prior observations (BSSID/RSS histories) for geographic tiles; during confirmation, the device retrieves those stored properties, so the per-feature comparisons are expressly between stored target properties and present measurements.
and identifying the present location as the target location if the plurality of comparisons concludes that the present location is the target location. (Thoresen Fig. 10A; [0092]– [0093]) Thoresen teaches comparing similarity metrics to a threshold and, upon a match, causing a location-based event—i.e., identifying/acting on the device as being at the target location.
Thoresen does not disclose: Using an aggregated confidence score derived from the plurality of comparisons as the explicit gate for identification. (Brachet. Fig 14; [0074]– [0076]) Brachet teaches: Computing a weighted/aggregated confidence score from multiple comparisons (e.g., BSSID/RSS across APs) and validating against a threshold to accept the estimated position as the correct location.
It would have been obvious to combine Brachet’s confidence-score thresholding with Thoresen’s identify-on-threshold flow, so the controller identifies the target location when the aggregated result of the plurality of comparisons exceeds a validation threshold. This is a predictable substitution of known gating mechanisms in the same WLAN localization context, improving robustness to noisy measurements without changing the principle of operation.
Regarding claim 13, Brachet teaches the method of Claim 12,
further comprising updating a database record of properties of identifying features of the target location with a property of at least one identifying feature of the present location if the present location has been identified as the target location, wherein the database record is identified by a unique digital identifier. (Thoresen Fig. 10A, 1055–1057; [0091]– [0093]; Fig. 16B). Thoresen teaches: Thoresen’s controllers compare present Wi-Fi features to a stored profile, generate similarity metrics, apply a threshold, and trigger a location-based event upon a match.
Thoresen does not disclose: Performing a database update tied to that identification event, nor identifying the record by a unique digital identifier. (Brachet [0073], [0075], [0098]– [0099], Fig. 14).
Brachet teaches After verifying/estimating position, the system updates the location database with current signal/AP properties and maintains records indexed by a WPS TileID (a unique digital identifier) for each geographic tile.
It would have been obvious to combine Brachet’s update + TileID keying with Thoresen’s identify-on-threshold flow so that once the controller identifies the present location as the target, it updates the uniquely keyed record with newly observed properties—routine database maintenance that predictably improves future matching accuracy without changing Thoresen’s principle of operation.
Regarding claim 15, Brachet teaches the method of Claim 12,
wherein the plurality of identifying features of the target location includes a walking profile of a route approaching the target location. (Thoresen Fig. 10A, 1055–1057; [0091]– [0093]; Fig. 16B). Thoresen teaches controllers compare present Wi-Fi features to a stored profile, generate similarity metrics, apply a threshold, and trigger a location-based event upon a match.
Thoresen does not disclose performing a database update tied to that identification event, nor identifying the record by a unique digital identifier. (Brachet [0073], [0075], [0098]– [0099], Fig. 14). Brachet teaches after verifying/estimating position, the system updates the location database with current signal/AP properties and maintains records indexed by a WPS TileID (a unique digital identifier) for each geographic tile.
It would have been obvious to combine Brachet’s update + TileID keying with Thoresen’s identify-on-threshold flow so that once the controller identifies the present location as the target, it updates the uniquely keyed record with newly observed properties—routine database maintenance that predictably improves future matching accuracy without changing Thoresen’s principle of operation.
Claim 14 is rejected under 35 U.S.C. §103 as being unpatentable over Brachet (US 2016/0323704 A1) in view of Shveki (US 2021/0112427 A1).
Regarding claim 14, Brachet teaches the method of Claim 12,
wherein the plurality of identifying features of the target location includes at least one visible exterior feature of a building at the target location. Brachet [0018]– [0023], [0088]– [0091], [0106]– [0110]; Figs. 15–18; (Shveki Figs. 6B, 9, 22–23) Brachet teaches the Claim-12 method by scanning Wi-Fi APs, using a server-maintained AP database partitioned into tiles, caching tiles on the client, and estimating location from those wireless features
Brachet does not disclose using a visible exterior building feature as an identifying feature, whereas (Shveki Figs. 6B, 9, 22–23) Shveki’s XR pipeline captures camera images and performs object recognition/descriptor matching over world surfaces—Object Recognizers, Planes & Semantics, and frame-descriptor localization
It would have been obvious to combine Shveki’s visible building-exterior cues with Brachet’s Wi-Fi profile/tiling workflow, so the controller corroborates the RF fingerprint with a stable façade landmark, a predictable fusion in the same localization context to improve last-meter accuracy and reduce RF-only false positives.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Thoresen (US 2018/0270608 A1) in view of Rocci et al. (US 2019/0090174 A1)
Regarding claim 20, Thoresen teaches the method of Claim 16,
wherein the profile of wireless communication networks expected to be detectable at the target location includes at least one vehicle-based WiFi network. (Thoresen Fig. 15; Fig. 16A–16B, 1693–1697; Fig. 10A, 1055–1057; [0157]– [0163]). Thoresen teaches controllers operating in a vehicle context with dynamic geofences that generate similarity metrics by comparing probe-request data to stored profiles, compare to a similarity threshold, and trigger a location-based event on a match.
Thoresen does not disclose that the stored expected profile explicitly includes an SSID/BSSID of a vehicle-based Wi-Fi hotspot. (Rocci [0029]– [0033], [0038]–[0039], [0048]; Figs. 2–3).Rocci teaches a vehicle as a Wi-Fi hotspot: the vehicle modem broadcasts identifiers/SSIDs for public and private wireless networks (dual-SSID), receives connection requests including the SSID, and routes traffic accordingly (flow 300).]: [0039] “broadcast the SSIDs associated with the private… and the public wireless network”).
It would have been obvious to combine Rocci’s vehicle-hotspot SSID/BSSID with Thoresen’s profile/compare/threshold framework so the expected-network profile for a vehicle-defined target zone includes the vehicle hotspot as an identifying feature— a predictable use of known WLAN elements (SSID/BSSID) to improve confirmation for dynamic or semi-static targets without changing Thoresen’s principle of operation.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANNABELLA CHRISTOPHE whose telephone number is (571)272-4666. The examiner can normally be reached Monday thru Friday 8-5pm, ET.
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, JEFFREY RUTKOWSKI can be reached at (571)270-1215. 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.
/ANNABELLA CHRISTOPHE/Examiner, Art Unit 2415
/JEFFREY M RUTKOWSKI/Supervisory Patent Examiner, Art Unit 2415
Prosecution Insights