CTNF 19/256,835 CTNF 81719 DETAILED ACTION This Office action is responsive to the following communication: Application filed on 1 July 2025. Claim(s) 1-20 is/are pending and present for examination. Claim(s) 1, 11, and 20 is/are in independent form. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statement(s) (IDS) submitted on 1 July 2025 and 5 December 2025 is/are being considered by the examiner. Drawings 06-37 AIA The drawings were received on 1 July 2025 . These drawings are accepted . Priority 02-26 AIA Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Claim Objections 07-29-01 AIA Claim (s) 1 is/are objected to because of the following informalities: line 9 recites the grammatical error of “database,;” . Appropriate correction is required. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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. 07-07-aia AIA 07-07 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 – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15-03-aia AIA Claim(s) 1-9 and 10-19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Patrick et al, USPGPUB No. 2025/0097344, filed on 29 September 2023, and published on 20 March 2025 . As per independent claims 1 and 11, Patrick teaches: A method of managing a dynamic database for providing a personalized service comprising: obtaining user input information through at least one application (app) installed on an electronic device {See Patrick, [0044], wherein this reads over “As a general matter, the SDK 216 is installed in the client app 214 by the client. In one example, the SDK 216 can provide the functionality of a geofencing platform within the client app 214. In different embodiments, once the consumer (e.g., user device 210) grants location permissions to the client app 214, the SDK 216 can begin its tracking operations at the user device 210 and collecting data via a data collection module 224. For example, in some embodiments, the data collection module 224 can request and collect data from one or more device location sensors 220 that provides location information 222 (e.g., latitude, longitude, accuracy, etc.).”} ; obtaining, from the user input information, context information that comprises information indicating a reason for an event and that relates to the personalized service {See Patrick, [0045], wherein this reads over “In some embodiments, based on the received location information, as well as additional data such as the location information for a previous time (location history for that user), device state information, and client project settings, the API server 250 can determine if one or more location events (e.g., “geofence entry or exit,” “place visit,” “trip arrival,” “country entry or exit,” “beacon entry or exit”, etc.) have occurred, as well as a corresponding user context (e.g., “user is currently in these geofences [list geofences by name/label]” “user is currently at this place [name of place]” “user is currently 5 mins away from this destination [name of destination],” etc.). The user context can be understood to be a more descriptive or nuanced narrative of the location event. While location events can indicate where the user device was based on the collected location data, and/or whether it was in some target zone or pre-defined geographical area that is of relevance to the client, the user context specifies exactly what the pre-defined geographical area is (i.e., its name or label) and describes in human-reader friendly language what the user device was doing relative to the detected area. In some embodiments, user context can be based on other, non-location type data, such as user device connectivity strength, battery life, or other user device sensor data. in some embodiments, a rule trigger can be composed of a location event, while in other embodiments, a rule trigger can be composed of a user context based on the location event, and in still other embodiments, a rule trigger can include either or both of a location event and a user context.”} ; obtaining classified context information by classifying the context information based on reason information included in the context information {See Patrick, [0045], wherein this reads over “The user context can be understood to be a more descriptive or nuanced narrative of the location event. While location events can indicate where the user device was based on the collected location data, and/or whether it was in some target zone or pre-defined geographical area that is of relevance to the client, the user context specifies exactly what the pre-defined geographical area is (i.e., its name or label) and describes in human-reader friendly language what the user device was doing relative to the detected area. In some embodiments, user context can be based on other, non-location type data, such as user device connectivity strength, battery life, or other user device sensor data. in some embodiments, a rule trigger can be composed of a location event, while in other embodiments, a rule trigger can be composed of a user context based on the location event, and in still other embodiments, a rule trigger can include either or both of a location event and a user context.”} , and storing the classified context information in the dynamic database, {See Patrick, [0046], wherein this reads over “In other examples, as shown in FIG. 2B, the location event and user context can be stored in a database for reporting and analysis in a dashboard and/or sent to integrations.”} ; and executing the personalized service on the electronic device based on the context information and at least one other piece of context information connected to the context information {See Patrick, [0051], wherein this reads over “Furthermore, clients can use the SDK to define user contexts for “trips” that a user may undertake and thereby calculate live ETAs from an origin to a destination. Trips can encompass several location events, such as a user starting a trip, trip modification/update, approaching trip destination, arrived at trip destination, and trip stopped. Detection of these events is particularly useful in pickup or delivery tracking. A client can create a destination geofence, and then use the SDK to generate trip events with ETAs to the destination geofence.”} . As per dependent claims 2 and 12, Patrick teaches: The method of claim 1, wherein the obtaining the classified context information and the storing the classified context information comprises: obtaining connected context information by identifying, based on the reason information, at least one connection between the context information and the at least one other piece of context information {See Patrick, [0047], wherein this reads over “In one embodiment, a location data processor 254 can receive and process the location information obtained from the user device 210 and determine whether any location events 256 have occurred (e.g., entry and/or exit from a specific boundary, such as a geofenced area or other place of interest as designated by the client). In addition, in some embodiments, the location data processor can define any relevant user context 272 based on the location data and a given project settings (e.g., see developer database 274 below) that can specify their geographical areas of interest.”} , wherein the at least one other piece of context information is previously stored in the dynamic database, and storing the connected context information in the dynamic database {See Patrick, [0046], wherein this reads over “In other examples, as shown in FIG. 2B, the location event and user context can be stored in a database for reporting and analysis in a dashboard and/or sent to integrations.”} . As per dependent claims 3 and 13, Patrick teaches: The method of claim 2, wherein, first reason information is included in first context information obtained from the user input information {See Patrick, [0044], wherein this reads over “In different embodiments, once the consumer (e.g., user device 210) grants location permissions to the client app 214, the SDK 216 can begin its tracking operations at the user device 210 and collecting data via a data collection module 224.”} , wherein second context information comprising second reason information is stored in the dynamic database {See Patrick, [0046], wherein this reads over “In other examples, as shown in FIG. 2B, the location event and user context can be stored in a database for reporting and analysis in a dashboard and/or sent to integrations.”} , and wherein the classifying the context information and the storing the classified context information comprises: comparing the first reason information with the second reason information {See Patrick, [0050], wherein this reads over “As a general matter, geofences can be understood to represent custom-selected/bounded regions or pre-defined geographical regions or zones that have been created by a client in order to monitor user activity in relation to that area. Depending on the use case, a geofence event-based context might represent detection of a user entering/exiting a specific retail store, a neighborhood, as some non-limiting examples. In some embodiments, the SDK can generate a geofence entry event if a user enters a geofence or stops in a geofence with sufficient confidence, as well as a geofence exit event when the user leaves the geofence with sufficient confidence. A device must exit a geofence before a subsequent entry into that same geofence. The client can specify the metadata for geofences when the geofence is created, including the tag (a group for the geofence, e.g., store), external ID (an external ID for the geofence that maps to your internal database, e.g., 123), and description (a display name for the geofence, e.g., Store #123). This allows geofences to be uniquely referenced by tag and external ID, which can be referenced by the rule builder interface module when the client wants to create a rule that involves a specific geofence. Furthermore, in some embodiments, geofence events that are detected by the SDK can be associated with varying confidence levels.”} ; and based on identifying correspondence between the first reason information and the second reason information, obtaining the connected context information by connecting the first context information to the second context information {See Patrick, [0052], wherein this reads over “With respect to the user context type of places, clients can request that the SDK monitor and track user device 210 to detect when they visit a place, chain, or category (regardless of whether a geofence has been created for that location) by reference to an internal points-of-interest (POI) database associated with the API server 250”} , and storing the connected context information in the dynamic database {See Patrick, [0046], wherein this reads over “In other examples, as shown in FIG. 2B, the location event and user context can be stored in a database for reporting and analysis in a dashboard and/or sent to integrations.”} . As per dependent claims 4 and 14, Patrick teaches: The method of claim 1, wherein the reason information is determined based on content of the user input information corresponding to the context information {See Patrick, [0045], wherein this reads over “In some embodiments, based on the received location information, as well as additional data such as the location information for a previous time (location history for that user), device state information, and client project settings, the API server 250 can determine if one or more location events (e.g., “geofence entry or exit,” “place visit,” “trip arrival,” “country entry or exit,” “beacon entry or exit”, etc.) have occurred, as well as a corresponding user context (e.g., “user is currently in these geofences [list geofences by name/label]” “user is currently at this place [name of place]” “user is currently 5 mins away from this destination [name of destination],” etc.).”} . As per dependent claims 5 and 15, Patrick teaches: The method of claim 4, wherein the context information comprises: explicit information, and implicit information that is determined based on content of the user input information, and wherein the implicit information comprises the reason information {See Patrick, [0053], wherein this reads over “Events can also be classified based on a region user context type. For example, the SDK and location infrastructure described herein can access a boundary database to detect a user's country, state, DMA (media market), or postal code. In some cases, the region detection tool can also be used to allowlist or blocklist location updates in specific countries for privacy or compliance reasons. In another example, region events can be issued in response to detection of the user device in the user's home regions based on location updates in the last 30 days, and detect when a user is traveling outside of their home regions. Thus, a client can select a region event as a trigger in the rules builder to cause some action when the client enters or exit a specific country, or enters or exits some bounded area or zone around their home location”} . As per dependent claims 6 and 16, Patrick teaches: The method of claim 5, wherein the obtaining the context information comprises: determining a context from the user input information {See Patrick, [0047], wherein this reads over “a location data processor 254 can receive and process the location information obtained from the user device 210 and determine whether any location events 256 have occurred (e.g., entry and/or exit from a specific boundary, such as a geofenced area or other place of interest as designated by the client). In addition, in some embodiments, the location data processor can define any relevant user context 272 based on the location data and a given project settings (e.g., see developer database 274 below) that can specify their geographical areas of interest.”} ; obtaining one or more pieces of explicit information from the user input information {See Patrick, [0047], wherein this reads over “a location data processor 254 can receive and process the location information obtained from the user device 210 and determine whether any location events 256 have occurred (e.g., entry and/or exit from a specific boundary, such as a geofenced area or other place of interest as designated by the client). In addition, in some embodiments, the location data processor can define any relevant user context 272 based on the location data and a given project settings (e.g., see developer database 274 below) that can specify their geographical areas of interest.”} ; and determining the reason information, based on a generative model, using at least one of the context or the one or more pieces of explicit information {See Patrick, [0052], wherein this reads over “With respect to the user context type of places, clients can request that the SDK monitor and track user device 210 to detect when they visit a place, chain, or category (regardless of whether a geofence has been created for that location) by reference to an internal points-of-interest (POI) database associated with the API server 250”} . As per dependent claims 7 and 17, Patrick teaches: The method of claim 5, wherein the one or more pieces of explicit information comprises event information and at least one of subject information, location information, or temporal information, and wherein the reason information comprises the information indicating the reason for the event, and the event corresponds to the event information {See Patrick, [0045], wherein this reads over “In some embodiments, based on the received location information, as well as additional data such as the location information for a previous time (location history for that user), device state information, and client project settings, the API server 250 can determine if one or more location events (e.g., “geofence entry or exit,” “place visit,” “trip arrival,” “country entry or exit,” “beacon entry or exit”, etc.) have occurred, as well as a corresponding user context (e.g., “user is currently in these geofences [list geofences by name/label]” “user is currently at this place [name of place]” “user is currently 5 mins away from this destination [name of destination],” etc.).”} . As per dependent claims 8 and 18, Patrick teaches: The method of claim 1, wherein the user input information comprises at least one of: information input to the electronic device by a user, information based on a usage pattern of the electronic device by the user, information based on an action performed on the electronic device by the user, or information displayed on a screen of the electronic device based on usage of the electronic device by the user {See Patrick, [0044], wherein this reads over “In different embodiments, once the consumer (e.g., user device 210) grants location permissions to the client app 214, the SDK 216 can begin its tracking operations at the user device 210 and collecting data via a data collection module 224. For example, in some embodiments, the data collection module 224 can request and collect data from one or more device location sensors 220 that provides location information 222 (e.g., latitude, longitude, accuracy, etc.). In another embodiment, the data collection module 224 can request and collect data from one or more device settings and account information (“user device data”) 232 (e.g., device information and settings, user activity information, etc.)”} . As per dependent claims 9 and 19, Patrick teaches: The method of claim 8, wherein the obtaining the user input information comprises: storing a user input to the at least one app by a user {See Patrick, [0044], wherein this reads over “In different embodiments, once the consumer (e.g., user device 210) grants location permissions to the client app 214, the SDK 216 can begin its tracking operations at the user device 210 and collecting data via a data collection module 224. For example, in some embodiments, the data collection module 224 can request and collect data from one or more device location sensors 220 that provides location information 222 (e.g., latitude, longitude, accuracy, etc.). In another embodiment, the data collection module 224 can request and collect data from one or more device settings and account information (“user device data”) 232 (e.g., device information and settings, user activity information, etc.)”} ; or identifying a screen displayed on the electronic device corresponding to the at least one app . Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim s 10 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL KIM whose telephone number is (571)272-2737. The examiner can normally be reached Monday-Friday, 9AM-5PM. 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, Sanjiv Shah can be reached at (571) 272-4098. 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. /Paul Kim/ Primary Examiner Art Unit 2166 /PK/ Application/Control Number: 19/256,835 Page 2 Art Unit: 2166 Application/Control Number: 19/256,835 Page 3 Art Unit: 2166 Application/Control Number: 19/256,835 Page 4 Art Unit: 2166 Application/Control Number: 19/256,835 Page 5 Art Unit: 2166 Application/Control Number: 19/256,835 Page 6 Art Unit: 2166 Application/Control Number: 19/256,835 Page 7 Art Unit: 2166 Application/Control Number: 19/256,835 Page 8 Art Unit: 2166 Application/Control Number: 19/256,835 Page 9 Art Unit: 2166 Application/Control Number: 19/256,835 Page 10 Art Unit: 2166 Application/Control Number: 19/256,835 Page 11 Art Unit: 2166
Prosecution Insights