DETAILED ACTION
This Office Action is in response to the amendment filed on 02/09/2026 in which claims 1-23 are presented for examination on the merits.
Notice of Pre-AIA or AIA Status
The present application is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/14/2026 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Response to Arguments
1. Applicant's arguments in pages 9-11 of the REMARKS filed on 02/09/2026 with respect to the rejection under 35 USC § 103(a) have been considered but are moot in view of the new grounds of rejection. After careful review and in light of Applicant’s amendments, remarks, and Examiner’s newly performed search and consideration, claims 1-23 are now newly rejected under 35 U.S.C. 103(a) for the reasons specified below.
In light of Applicant’s amendments, the rejection under 35 USC § 101 is hereby withdrawn.
Claim Rejections - 35 USC § 103
2. 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 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.
3. 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.
4. 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.
5. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 1-5, 7-13, 15, 17, 19 and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Maheswaranathan (US 20180338237 A1) in view of Holland et al. (US 20140082749 A1, hereinafter, Holland).
Regarding claim 1, Maheswaranathan discloses a method, comprising: receiving, from a first user device, an indication to start a device monitoring session (Para 0026: sending messages on behalf of the tracking device.);
sending, to a second user device, a first message that indicates a start of the device monitoring session (Para 0038: a user extends the tracking device application across the two devices …..start monitoring the tracking device on the master device, for example on his or her mobile telephone.);
gathering session data at different times throughout the device monitoring session (Para 0022: A user of a personal tracking device may want to communicate his or her location to a master or monitoring device so that the master or monitoring device can analyze the location),
wherein the session data includes location data and other device data associated with the first user device (Para 0038: the master device maps libraries (in real time or substantially real time) which will pull all other tracking devices and their locations to monitor in a map and provide for sending and/or requesting status/location information on demand or through a reporting status schedule set for the tracking devices);
[generating, using a key associated with the first user device, encrypted session data from the session data];
storing the encrypted session data within a secure storage service that is separate from the first user device and the second user device (Para 0091” stores detailed location information associated with one or more tracking devices that may be paired to the master device 104, the master device 104 may additionally or alternatively query a database for the intended travel route information and possibly other related information associated with the one or more tracking devices),
[wherein the encrypted session data is inaccessible to the second user device until the second user device receives a release session data message indicating that the second user device is authorized to access the encrypted session data];
monitoring, during the device monitoring session, the first user device to identify an occurrence of one or more events (Para 0031: e reporting interval may be increased/decreased based on a particular location or anticipated event (e.g., last transmission indicated the tracking device was near a dangerous boundary, the tracking device was last located in a dangerous area of a mine, or there is expected contact with a dangerous party),
wherein the one or more events include at least one of an end session event, a check-in event, or an anomaly event (Para 0031; master device automatically and/or semi automatically generates an SOS wherein the master device can request for location when it needs to do additional checks of the location of the tracking device or if the master device is aware of a heightened threat to safety of the tracking device.); and
performing one or more actions, based at least in part on the occurrence of the one or more events, wherein the one or more actions include at least one of an end session action that sends an end session message to the second user device that the session completed successfully (Para 0069: The status may be color coded and may further indicate a sending, retrying, or sent status. In the event, the SOS has yet to be sent successfully, the master device 104 is configured to keep trying until the message is eventually sent or cancelled),
a check-in action that sends a check-in message to the first user device that requests an indication to continue or end the device monitoring session (Para 0071-0072: Location information of the tracking device are collected from the master device 104. The location information collected may occur constantly or periodically depending on the environment of the tracking device 102 and may be reconfigured by the master device), or
a release session data action that includes sending a release session data message to the second user device indicating that the second user device is authorized to access the encrypted session data from the secure storage service (Para 0116, 0131, 0031: tracker application is configured to check smart algorithm conditions to see a preprogrammed contact/recipient list to push the tracking device location to the list of recipients comprising emergency response units, authorities, lifesaving services, police, fire, friends, family etc.).
Maheswaranathan does not explicitly state but Holland from the same or similar fields of endeavor teaches generating, using a key associated with the first user device, encrypted session data from the session data (Holland, Para 0099, 0054, 0086: generating a token to represent the created encryption key associated with the client device wherein communication data is encrypted using PGP encryption)
wherein the encrypted session data is inaccessible to the second user device until the second user device receives a release session data message indicating that the second user device is authorized to access the encrypted session data (Para .0052: The escrow agent is instructed by secure data center to release a control key only upon certification by the customer wherein an authentication token that is placed in escrow with an independent third party escrow entity or agent wherein ..protect information records subject to a legal/litigation hold command until that hold command has been released--even if a previously specified retention period for those records has expired).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to generate, using a key associated with the first user device, encrypted session data from the session data and wherein the encrypted session data is inaccessible to the second user device until the second user device receives a release session data message indicating that the second user device is authorized to access the encrypted session data as taught by Holland in the teachings of Maheswaranathan in order to enable a client computer associated with the user to store information in an elastic storage system and to prohibit the client computer, the information processing system, and the elastic storage system from altering and from deleting the stored information during an authorized retention period wherein the elastic storage system permits deletion, modification, or destruction of the stored information only when a trusted independent third party having predetermined authentication information associated with the client account provides the predetermined authentication information to the elastic storage system (Holland, Abstract).
Regarding claim 2, the combination of Maheswaranathan and Holland discloses the method of claim 1, wherein the release session data message includes one or more of a decrypt key to decrypt the encrypted session data or an access token to access the encrypted session data stored in the secure storage service (Para 0040: activate secure access module 204. Initialization may further comprise main processor 200 generating one or more secure session keys and establishing a secure, encrypted communication link with secure access module 204 via communication buss 210).
Regarding claim 3, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising: receiving, from the second user device, a request to release the encrypted session data (Maheswaranathan, Para 0116, 0131, 0031: tracker application is configured to check smart algorithm conditions to see a preprogrammed contact/recipient list to push the tracking device location to the list of recipients comprising emergency response units, authorities, lifesaving services, police, fire, friends, family etc wherein the ode may be encrypted.); and
releasing the encrypted session data to the second user device based at least in part on an access token received from the second user device, or after a specified release time (Maheswaranathan Para 0071, 0113: the case of the master device, a user may access the master device to request an update of the location of the tracking device … he master or monitoring device may send a message on behalf of the tracking device, such as without receiving a request from the tracking device, based on a detected condition, emergency, location).
Regarding claim 4, the combination of Maheswaranathan and Holland discloses the method of claim 1, wherein the secure storage service uses an access token to protect access to the encrypted session data (Holland, Para 0099, 0054, 0086: generating a token to represent the created encryption key associated with the client device wherein communication data is encrypted using PGP encryption).
Regarding claim 5, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising: scheduling a release time to deliver the release session data message, wherein the scheduling is performed in advance of a determination to release the session data (Maheswaranathan Para 0107: when the master device 104 should receive a status from the tracking device 102 so that whenever the tracking device 102 deviates from the predetermined reporting status schedule by a significant amount of time, the master device may be configured to request a status from the tracking device 102 and trigger transmission of an alert message to a third party should a status update not be received as requested); and
updating the release time to deliver the release session data message based, at least in part, on a use of the first user device during the device monitoring session (Maheswaranathan Para 0034: the master device may further be configured to update a reporting status schedule in which the tracking device reports its status).
Regarding claim 7, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising: determining that the first user device initiated an emergency call, and sending the release session data message based, at least in part, on the determination that the first user device completed the emergency call (Maheswaranathan Para 0043: he master or monitoring device may send a location request or SOS on behalf of the tracking device. The master device may additionally send the alert message with the location of the tracking device to an emergency response unit or may trigger the tracking device to directly send the location to the master, monitoring, emergency unit, relatives, friends).
Regarding claim 8, the combination of Maheswaranathan and Holland discloses the method of claim 1, wherein performing the one or more actions comprises sending the check-in message to the second user device based, at least in part, on determining that the first user device has been inactive for a predetermined period of time (Maheswaranathan Para 0030: he tracking device may operate in a sleep mode to reduce power and satellite airtime consumption. During the sleep mode, the tracking device operates at low power and does not report its status and/or transmit its location unless a request is received to do so from a master device. For example, the tracking device in sleep mode may be preprogrammed to wake once a day).
Regarding claim 9, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising: sending the check-in message to the first user device; and sending the release session data message based, at least in part, on not receiving a reply to the check-in message within a predetermined time period (Maheswaranathan Para 0030: if a monitoring device requests for location information from a tracking device, the tracking device will wake and/or otherwise activate so as to transmit a response to the request to the monitoring device.).
Regarding claim 10, the combination of Maheswaranathan and Holland discloses the method of claim 1is able to determine the location of the tracking device without contacting the tracking device directly, such as by accessing a last message sent by the tracking device.) and
sent by the second user device, one or more previous messages sent by the first user device, a current location, a current time, a desired destination, or a mode of transportation (Maheswaranathan Para 0031: he reporting request may be on-demand, based on a periodic reporting or other predetermined reporting interval, and/or generated based on an algorithm. Indeed, in some examples, the reporting interval may be increased/decreased based on a particular location or anticipated event (e.g., last transmission indicated the tracking device was near a dangerous boundary, the tracking device was last located in a dangerous area of a mine, or there is expected contact with a dangerous party).
Regarding claim 11, the combination of Maheswaranathan and Holland discloses the method of claim1, further comprising generating a suggestion to start the device monitoring session based at least in part on one or more keywords, one or more family contacts, or one or more emergency contacts (Maheswaranathan Para 0116, 0131, 0031: tracker application is configured to check smart algorithm conditions to see a preprogrammed contact/recipient list to push the tracking device location to the list of recipients comprising emergency response units, authorities, lifesaving services, police, fire, friends, family etc.).
Regarding claim 12, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising sending the check-in message to the first user device, wherein the check-in message requests an input to indicate to continue the device monitoring session or end the device monitoring session (Maheswaranathan Para 0029: tracking device does not transmit its location unless it receives a request to do so. … when the tracking device is preprogrammed only to respond to a master or monitoring device's request for a status, the tracking device is configured to respond when requested by the master device or monitoring device for a status and/or location information.).
Regarding claim 13, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising sending the release session data message based at least in part on determining that a period of time elapsed since sending the check-in message and no response has been received that indicates to extend or end the device monitoring session (Maheswaranathan Para 0030: the tracking device may operate in a sleep mode to reduce power and satellite airtime consumption. During the sleep mode, the tracking device operates at low power and does not report its status and/or transmit its location unless a request is received to do so from a master device. …if a monitoring device requests for location information from a tracking device, the tracking device will wake and/or otherwise activate so as to transmit a response to the request to the monitoring device).
Regarding claim 15, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising periodically re-scheduling the release session data message to be delivered at a future time based at least in part on one or more of a network connectivity of the first user device, or a use of the first user device (Maheswaranathan Para 0040: boundaries may be determined by geofences that are preloaded in the tracking device or pushed by smart devices. These boundaries may be used to trigger a change in position information. For example, once a tracking device passes or comes close to a boundary, the tracking device may be configured to change its reporting status schedule).
Regarding claim 17, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising sending the release session data message based at least in a determination that the first user device has deviated from a pattern (Maheswaranathan Para 0036, 0068: predictable pattern is provided to the tracking device and/or master device in order to take advantage of communications… end a message to wake the tracking device and request a status every 10 minutes instead of every hour. If, based on the new reporting status, the tracking device is off track, this deviation will initiate an SOS to be sent by the master device 104 on behalf of the tracking device).
Regarding claim 19, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising monitoring a third device that is associated with a first user device based, at least in part, on the third device losing a wireless connection to the first user device (Maheswaranathan Para 0030, 0035-0037: tracking device may operate in a sleep mode to reduce power and satellite airtime consumption. During the sleep mode, the tracking device operates at low power and does not report its status and/or transmit its location unless a request is received to do so from a master device).
Regarding claim 21, the combination of Maheswaranathan and Holland discloses the method of claim 1, further comprising performing end-to-end encryption for messages sent between the first user device and the second user device (Holland, Para 0099, 0054, 0086: generating a token to represent the created encryption key associated with the client device wherein communication data is encrypted using PGP encryption).
Regarding claim 22; Claim 22 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 23; Claim 23 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Allowable Subject Matter
7. Claims 6, 14, 16, 18, and 20 would be allowable if rewritten or amended to overcome the objections and rejection(s) under 35 USC § 101, set forth in this office action and to include all of the limitations of the base claim and any intervening claims.
.
Reasons for Allowance
8. The following is an examiner’s statement of reasons for placing claims 6, 14, 16, 18, and 20 under allowable subject matters:
The limitation of dependent claims 4, 6, 14, 16, 18, and 20 are allowed and the corresponding dependent claims including respective and any intervening claims are not disclosed by the any of the prior art of record. For example, the limitations in claim 4 including the intervening claims recites “..scheduling a release time to deliver the release session data message, wherein the scheduling is performed in advance of a determination to release the session data; and updating the release time to deliver the release session data message based, at least in part, on a use of the first user device during the device monitoring session.…. determining that the first user device is offline, and sending the release session data message based, at least in part, on the determination that the first user device is offline and the release time..” which are not are not taught or fairly suggested by the prior art of record.
The allowable subject matters in above dependent claims are novel and non-obvious in scope over the prior art of record as the prior-art references fail to teach each and every features of the aforesaid dependent claim(s) including the limitations set forth above.
In view of the foregoing, the scope of claimed subject matters renders the invention patentably distinct as none of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious the invention of the present application at or before the time it was filed.
Furthermore, the Examiner performed updated search which does not yield other specific references that reasonably, either alone or in combination, would result a proper rejection of all the claimed features presented in each of the dependent claims 6, 14, 16, 18, and 20 under 35 U.S.C 102 or 35 U.S.C.103 with proper motivation.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled "Comments on Statement of Reasons for Allowance."
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sarcanin (US 20050246292 A1) discloses atransaction server for performing a transaction over a network using a virtual smart card the server comprising, a virtual smart card database having a plurality of records each record including a virtual card identification and a value corresponding to a single virtual smart card.
10. 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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHFUZUR RAHMAN whose telephone number is (571)270-7638. The examiner can normally be reached on Monday thru Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached on 571-272-8878. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHFUZUR RAHMAN/Primary Examiner, Art Unit 2498
Prosecution Insights