Prosecution Insights
Last updated: April 19, 2026
Application No. 18/069,835

DYNAMIC ID GENERATION FOR CONNECTED VEHICLE SYSTEMS

Non-Final OA §101§103
Filed
Dec 21, 2022
Examiner
KARTHOLY, REJI P
Art Unit
2143
Tech Center
2100 — Computer Architecture & Software
Assignee
Ford Global Technologies LLC
OA Round
1 (Non-Final)
64%
Grant Probability
Moderate
1-2
OA Rounds
3y 4m
To Grant
99%
With Interview

Examiner Intelligence

Grants 64% of resolved cases
64%
Career Allow Rate
97 granted / 151 resolved
+9.2% vs TC avg
Strong +72% interview lift
Without
With
+71.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
18 currently pending
Career history
169
Total Applications
across all art units

Statute-Specific Performance

§101
13.7%
-26.3% vs TC avg
§103
55.7%
+15.7% vs TC avg
§102
8.8%
-31.2% vs TC avg
§112
12.0%
-28.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 151 resolved cases

Office Action

§101 §103
DETAILED ACTION This Office Action is in response to Applicant's Communication received on 12/21/2022 for application number 18/069,835. Claims 1-20 are presented for examination. Claims 1, 9, and 19 are independent claims. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claim Objections Claims 1, 6, 9, 16, and 19-20 are objected to because of the following informalities: These claims recite “the respective trigger”, which has no antecedent basis. Appropriate correction is required. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1 Claims 1-8 are directed to a system, Claims 9-18 are directed to a method, and Claims 19-20 are directed to a computer-readable medium. Thus, the claims fall within one of the statutory categories (machine, process, articles of manufacture) and are eligible under Step 1. Step 2A Prong 1 Independent Claims Claims 1, 9, and 19 recite: process the triggers defined by the knowledge database, including to compare data elements of the connected data messages with the conditions of the triggers, and augment each of the connected data messages that occur while the respective trigger is activated with a generated dynamic ID corresponding to the activating of the respective trigger - these limitations encompass a user to perform these steps mentally or by using pen and paper, such as a user observing description of triggers, making an evaluation/ judgement to compare a message/ data with trigger conditions, and adding a label/ ID to the message based on the message satisfying certain trigger conditions. Accordingly, these claims recite an abstract idea that falls under the “mental process” grouping. Step 2A Prong 2 Independent Claims Additional elements Claim 1: a system for using a knowledge database to augment connected data messages, comprising: a controller of the vehicle, programmed to - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). a storage of a vehicle, configured to maintain a knowledge database describing a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)) and using generic computer components as a tool (see MPEP § 2106.05(f)). Claim 9: maintaining, to a storage of a vehicle, a knowledge database describing a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)) and using generic computer components as a tool (see MPEP § 2106.05(f)). a controller of the vehicle - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). Claim 19: a non-transitory computer-readable medium comprising instructions for using a knowledge database to augment connected data messages that, when executed by a processor of a controller of a vehicle, cause the controller to perform operations including to - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). receive a knowledge database over a communication network from a cloud server, the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database and a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger; send the augmented connected data messages to the cloud server - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Accordingly, these additional elements do not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea. These claims are directed to the abstract idea. Step 2B Independent Claims Additional elements Claim 1: a system for using a knowledge database to augment connected data messages, comprising: a controller of the vehicle, programmed to - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). a storage of a vehicle, configured to maintain a knowledge database describing a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”) and using generic computer components as a tool (see MPEP § 2106.05(f)). Claim 9: maintaining, to a storage of a vehicle, a knowledge database describing a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”) and using generic computer components as a tool (see MPEP § 2106.05(f)). a controller of the vehicle - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). Claim 19: a non-transitory computer-readable medium comprising instructions for using a knowledge database to augment connected data messages that, when executed by a processor of a controller of a vehicle, cause the controller to perform operations including to - these limitations are recited at a high-level of generality such that it amount to no more than using generic computer components to apply the judicial exception (see MPEP § 2106.05(f)). receive a knowledge database over a communication network from a cloud server, the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database and a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger; send the augmented connected data messages to the cloud server - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”, “receiving/ transmitting data”). Accordingly, these additional elements do not amount to significantly more than the judicial exception. As such, these claims are patent ineligible. Step 2A Prong 1 Dependent Claims Claims 6, 16, and 20: generate the dynamic ID using a hash of values including an identifier of the vehicle, a current time, an incremented value, and/or an identifier of the respective trigger that is satisfied - these limitations merely further the mental process of adding labels/ ID to the messages based on trigger conditions. Claims 7 and 17: apply a first dynamic ID to the connected data messages that occur between a first activation of a first trigger and a first deactivation of the first trigger; and apply a second dynamic ID to the connected data messages that occur between a second activation of the first trigger and a second deactivation of the first trigger, wherein the first dynamic ID and the second dynamic ID are different values - these limitations merely further the mental process of adding labels/ ID to the messages based on trigger conditions. Claims 8 and 18: apply a first dynamic ID to the connected data messages that occur between an activation of a first trigger and a deactivation of the first trigger; and apply a second dynamic ID to the connected data messages that occur between an activation of a second trigger and a deactivation of the second trigger, wherein the first dynamic ID and the second dynamic ID are different values, and wherein the activation of the first trigger and the activation of the second trigger at least partially overlap such that the first and second dynamic IDs are both applied to the connected data messages within the overlap – these limitations merely further the mental process of adding labels/ ID to the messages based on trigger conditions. Thus, the claims recite the abstract idea that falls under the “mental process” grouping. Step 2A Prong 2 Dependent Claims Additional elements Claims 2 and 10: the knowledge database includes a data element mapping of signals of the vehicle to the data elements of the knowledge database - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Claims 3 and 11: the controller is further programmed to: receive the knowledge database over a communication network from a cloud server; and send the augmented connected data messages to the cloud server - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)) and is merely using generic computer components as a tool (see MPEP § 2106.05(f)). Claims 4 and 14: the plurality of triggers including a first trigger that indicates to begin to apply a first dynamic ID to the connected data messages responsive to a first data element being set to a first value and to discontinue applying the first dynamic ID to the connected data messages responsive to the first data element being set to a second value - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Claims 5 and 15: the plurality of triggers including a second trigger that indicates to begin to apply a second dynamic ID to the connected data messages responsive to a second data element being observed and to discontinue applying the second dynamic ID to the connected data messages responsive to a third data element being observed - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Claim 12: storing the connected data messages to a data table of a relational database, wherein each row of the data table represents one of the connected data messages, each of the triggers is represented by a respective column of the data table, wherein the value of the respective column is either the dynamic ID if the trigger is activated for the connected data messages or NULL otherwise - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Claim 13: receiving, by the cloud server from a client device, a query for connected data messages, the query specifying at least one dynamic ID is non-NULL; querying a data store accessible to the cloud server using the query; and sending the results of the query to the client device - these limitations amount to insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)). Accordingly, these additional elements do not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to the abstract idea. Step 2B Dependent Claims Additional elements Claims 2 and 10: the knowledge database includes a data element mapping of signals of the vehicle to the data elements of the knowledge database - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”). Claims 3 and 11: the controller is further programmed to: receive the knowledge database over a communication network from a cloud server; and send the augmented connected data messages to the cloud server - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”, “receiving/ transmitting data”) and using generic computer components as a tool (see MPEP § 2106.05(f)). Claims 4 and 14: the plurality of triggers including a first trigger that indicates to begin to apply a first dynamic ID to the connected data messages responsive to a first data element being set to a first value and to discontinue applying the first dynamic ID to the connected data messages responsive to the first data element being set to a second value - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”). Claims 5 and 15: the plurality of triggers including a second trigger that indicates to begin to apply a second dynamic ID to the connected data messages responsive to a second data element being observed and to discontinue applying the second dynamic ID to the connected data messages responsive to a third data element being observed - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”). Claim 12: storing the connected data messages to a data table of a relational database, wherein each row of the data table represents one of the connected data messages, each of the triggers is represented by a respective column of the data table, wherein the value of the respective column is either the dynamic ID if the trigger is activated for the connected data messages or NULL otherwise - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “storing/ retrieving information in memory”). Claim 13: receiving, by the cloud server from a client device, a query for connected data messages, the query specifying at least one dynamic ID is non-NULL; querying a data store accessible to the cloud server using the query; and sending the results of the query to the client device - these limitations amount to insignificant extra-solution activity of mere data gathering, which are well-understood, routine, and conventional activity (see MPEP § 2106.05(d), “receiving/ transmitting data”, “storing/ retrieving information in memory”). Accordingly, these additional elements do not amount to significantly more than the judicial exception. As such, the claims are patent ineligible. 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-12 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mezaael (US 2019/0375357 A1) in view of Okuma et al. (US 2021/0306489 A1 hereinafter Okuma). Regarding Claim 1, Mezaael teaches a system for using a knowledge database to augment connected data messages ([0010] a system for intelligently monitoring a vehicle based on defined trigger events; [0057] the trigger event definitions (i.e., knowledge database) received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle; [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle; responsive to identifying a trigger event from the sensor data (i.e., connected data messages) in block 306, the event evaluator cause the vehicle to communicate a notification to the cloud server that a trigger event has been identified; [0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers, and/or associated sensor data, to the cloud server over the network (i.e., augmenting connected data messages)), comprising: a storage of a vehicle, configured to maintain a knowledge database describing a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger ([0057] the trigger event definitions received from the cloud server; the event evaluator configured to store the trigger event definitions (i.e., describing a plurality of triggers), as vehicle event data in the non-volatile storage of the vehicle (i.e., storage of the vehicle maintaining knowledge database); [0048] each defined trigger event relate to a driving behavior, such as excessive acceleration or excessive braking, and include instructions for recognizing the driving behavior, such as, sensing data indicative an acceleration level of the vehicle beyond a set threshold acceleration level (i.e., conditions for trigger); [0054] one of the trigger events may correspond to an excessive acceleration event, and may be defined as a current acceleration of the vehicle being greater than a set acceleration threshold; another defined trigger event may correspond to an excessive braking event, and may be defined as a current deceleration of the vehicle being less than a set deceleration threshold; another defined trigger event may be a hard-steering event that corresponds to a change in heading of the vehicle or a change in steering wheel position that is beyond a set change threshold and is within a set timeframe, such as indicated in data generated by a compass, gyroscope, GPS module, and/or wheel position sensor of the vehicle, etc. (i.e., conditions for triggers); [0062] the vehicle monitor for trigger events defined in the vehicle event data; [0063] if the event evaluator determines that a defined trigger event has not occurred (i.e., including condition for deactivating trigger), then the event evaluator continue monitoring for defined trigger events; if a defined trigger event is identified from the sensor data (i.e., including condition for activating trigger), then the event evaluator begin capturing video showing one or more areas around the vehicle); and a controller of the vehicle ([0019] the vehicle ECUs (i.e., controller) configured to monitor and manage various functions of the vehicle; the vehicle ECUs include one or more of a radio transceiver controller configured to manage wireless communications with mobile devices; a powertrain controller configured to monitor and manage engine operating components; a body controller configured to monitor and manage various power control functions, etc.), programmed to process the triggers defined by the knowledge database, including to compare data elements of the connected data messages with the conditions of the triggers ([0057] the trigger event definitions received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle; [0062] the vehicle monitor for trigger events defined in the vehicle event data; the event evaluator configured to monitor for and identify the defined trigger events from data generated by the vehicle sensors (i.e., comparing data elements of the connected data messages with the conditions of the triggers/ trigger event definitions); [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle), and augment the connected data messages that occur while the respective trigger is activated with a generated dynamic ID corresponding to the activating of the respective trigger ([0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle; responsive to identifying a trigger event from the sensor data (i.e., connected data messages) in block 306, the event evaluator cause the vehicle to communicate a notification to the cloud server that a trigger event has been identified; [0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers (i.e., dynamic ID), and/or associated sensor data, to the cloud server over the network (i.e., augmenting connected data messages/ sensor data while the respective trigger event has been identified)). However, Mezaael fails to expressly teach wherein augment each of the connected data messages with a generated dynamic ID. In the same field of endeavor, Okuma teaches wherein augment each of the connected data messages with a generated dynamic ID ([0094] the event collection module generates a login event about the login operation that the server is notified (i.e., connected data message), adds the session ID (i.e., dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected and adds the same session ID to each event generated until logout). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have incorporated wherein augment each of the connected data messages with a generated dynamic ID, as taught by Okuma into Mezaael. Doing so would be desirable because it would improve the efficiency of analysis of a user's operation behavior/ event data (Okuma [0113]). As to dependent Claim 2, Mezaael and Okuma teach all the limitations of Claim 1. Mezaael further teaches wherein the knowledge database includes a data element mapping of signals of the vehicle to the data elements of the knowledge database ([0057]the trigger event definitions (i.e., knowledge database)received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle; [0048] each defined trigger event (i.e., data elements of the knowledge database) relate to a driving behavior, such as excessive acceleration or excessive braking, and include instructions for recognizing the driving behavior, such as, sensing data (i.e., signals of the vehicle) indicative an acceleration level of the vehicle beyond a set threshold acceleration level; [0054] one of the trigger events may correspond to an excessive acceleration event, and may be defined as a current acceleration of the vehicle being greater than a set acceleration threshold; another defined trigger event may correspond to an excessive braking event, and may be defined as a current deceleration of the vehicle being less than a set deceleration threshold; another defined trigger event may be a hard-steering event that corresponds to a change in heading of the vehicle or a change in steering wheel position that is beyond a set change threshold and is within a set timeframe, such as indicated in data generated by a compass, gyroscope, GPS module, and/or wheel position sensor of the vehicle, etc.). As to dependent Claim 3, Mezaael and Okuma teach all the limitations of Claim 1. Mezaael further teaches wherein the controller is further programmed to: receive the knowledge database over a communication network from a cloud server ([0057] the trigger event definitions (i.e., knowledge database)received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle); and send the augmented connected data messages to the cloud server ([0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers, and/or associated sensor data, to the cloud server over the network (i.e., sending augmented connected data messages to the server)). As to dependent Claim 4, Mezaael and Okuma teach all the limitations of Claim 1. Okuma further teaches wherein the plurality of triggers including a first trigger that indicates to begin to apply a first dynamic ID to the connected data messages responsive to a first data element being set to a first value and to discontinue applying the first dynamic ID to the connected data messages responsive to the first data element being set to a second value ([0094] the event collection module generates a login event (i.e., connected data message) about the login operation (i.e., first trigger/ first data element being set to a first value) that the server is notified, adds the session ID (i.e., first dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected (i.e., first data element being set to a second value) and adds the same session ID to each event generated until logout - thus, the session ID/ first dynamic ID is applied to the events starting at login/ first value until logout/ second value (i.e., discontinue applying the session ID/ first dynamic ID responsive to logout/ second value)). As to dependent Claim 5, Mezaael and Okuma teach all the limitations of Claim 1. Okuma further teaches wherein the plurality of triggers including a second trigger that indicates to begin to apply a second dynamic ID to the connected data messages responsive to a second data element being observed and to discontinue applying the second dynamic ID to the connected data messages responsive to a third data element being observed ([0096] when determining that the event is a screen operation event accompanied by screen transition, the event collection module generates a job ID (i.e., second dynamic ID) added to this screen operation event (i.e., connected data message); the job ID is used to identify an operation for each time when a job is executed; [0107] a job ID specifies a range of a series of user operations as with the session ID; whenever a job is executed, the same job ID is allocated to user operations performed when the corresponding job is executed; [0133] the same job ID is added to a series of operation events from setting of a job (i.e., second trigger/ second data element being observed) to execution of the job (i.e., third data element being observed/ discontinue applying job ID/ the second dynamic ID to the connected data messages/ events). As to dependent Claim 6, Mezaael and Okuma teach all the limitations of Claim 1. Mezaael further teaches wherein the controller is further programmed to generate the dynamic ID using a hash of values including an identifier of the vehicle, a current time, an incremented value, and/or an identifier of the respective trigger that is satisfied ([0019] the vehicle ECUs (i.e., controller) configured to monitor and manage various functions of the vehicle; the vehicle ECUs include one or more of a radio transceiver controller configured to manage wireless communications with mobile devices; a powertrain controller configured to monitor and manage engine operating components; a body controller configured to monitor and manage various power control functions, etc.; [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle; responsive to identifying a trigger event from the sensor data in block 306, the event evaluator cause the vehicle to communicate a notification to the cloud server that a trigger event has been identified; [0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers (i.e., dynamic ID including identifier of the respective trigger that is satisfied), and/or associated sensor data, to the cloud server over the network). As to dependent Claim 7, Mezaael and Okuma teach all the limitations of Claim 1. Okuma further teaches wherein apply a first dynamic ID to the connected data messages that occur between a first activation of a first trigger and a first deactivation of the first trigger ([0094] the event collection module generates a login event (i.e., connected data message) about the login operation (i.e., first activation of the first trigger) that the server is notified, adds the session ID (i.e., first dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected (i.e., first deactivation of the first trigger) and adds the same session ID to each event generated until logout; [0106] as shown in fig. 8B, a session ID 7103 specifies a range of a series of user operations; the same ID “A001” is allocated to the session ID 7103 of all the operation events generated between the user's login to the MFP 1100 and logout; [0109] the MFP 1100 adds the session ID “A001” to the session ID 7103 of the generated event); and apply a second dynamic ID to the connected data messages that occur between a second activation of the first trigger and a second deactivation of the first trigger, wherein the first dynamic ID and the second dynamic ID are different values ([0094] the event collection module generates a login event (i.e., connected data message) about the login operation (i.e., including second activation of the first trigger) that the server is notified, adds the session ID (i.e., dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected (i.e., including second deactivation of the first trigger) and adds the same session ID to each event generated until logout; [0158] as shown in fig. 8B, values of the session ID are different for every login; a session ID “A001” (i.e., first dynamic ID) is added to the events from No. 2 to No. 15 in the example of FIG. 8B; a different session ID “C003” (i.e., second dynamic ID) is added to the events of No. 26 to No. 40). As to dependent Claim 8, Mezaael and Okuma teach all the limitations of Claim 1. Okuma further teaches wherein apply a first dynamic ID to the connected data messages that occur between an activation of a first trigger and a deactivation of the first trigger ([0094] the event collection module generates a login event (i.e., connected data message) about the login operation (i.e., activation of the first trigger) that the server is notified, adds the session ID (i.e., first dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected (i.e., deactivation of the first trigger) and adds the same session ID to each event generated until logout; [0106] as shown in fig. 8B, a session ID 7103 specifies a range of a series of user operations; the same ID “A001” is allocated to the session ID 7103 of all the operation events generated between the user's login to the MFP 1100 and logout; [0109] the MFP 1100 adds the session ID “A001” to the session ID 7103 of the generated event); and apply a second dynamic ID to the connected data messages that occur between an activation of a second trigger and a deactivation of the second trigger, wherein the first dynamic ID and the second dynamic ID are different values, and wherein the activation of the first trigger and the activation of the second trigger at least partially overlap such that the first and second dynamic IDs are both applied to the connected data messages within the overlap ([0096] when determining that the event is a screen operation event accompanied by screen transition, the event collection module generates a job ID (i.e., second dynamic ID) added to this screen operation event (i.e., connected data message); the job ID is used to identify an operation for each time when a job is executed; [0107] a job ID specifies a range of a series of user operations as with the session ID; whenever a job is executed, the same job ID is allocated to user operations performed when the corresponding job is executed; [0133] the same job ID is added to a series of operation events from setting of a job (i.e., activation of the second trigger) to execution of the job (i.e., deactivation of the second trigger); [0111] as shown in fig. 8B, the MFP adds “0001” indicating the job ID generated by the job ID generation process of S5212 to the job ID 7104; [0113] the MFP generates the UserOperatedInJob events as events of No. 6 through No. 8 and sets the job IDs 7104 to the same value “0001”. See fig. 8B - it shows the first dynamic ID/ Session ID “A001” and the second dynamic ID/ job ID “0001” are different values and the activation of the first and second trigger partially overlap such that the first and second dynamic IDs are both applied to the connected data messages/ events 5 to 10 within the overlap). Claims 9-11 and 14-18 are method claims corresponding to the system claims 1-8 respectively and therefore, rejected for the same reasons. As to dependent Claim 12, Mezaael and Okuma teach all the limitations of Claim 11. Okuma further teaches wherein storing the connected data messages to a data table of a relational database, wherein each row of the data table represents one of the connected data messages, each of the triggers is represented by a respective column of the data table, wherein the value of the respective column is either the dynamic ID if the trigger is activated for the connected data messages or NULL otherwise ([0088] the event notification data is saved as a log file in the HDD in the message buffer as a storage unit (equivalent to storing connected data messages/ events to a data table of a relational database); [0106] FIG. 8B is a view showing an example of the event log in the system; [0107] the generated information about the event is saved in the message buffer ; the saved information about the event is transmitted to the server as a log; an event name 7101, a generation time 7102, and a user name 7106 are the same as that of FIG. 8A; a session ID 7103 specifies a range of a series of user operations; the same ID “A001” is allocated to the session ID 7103 (i.e., dynamic ID) of all the operation events generated between the user's login to the MFP 1100 and logout. See fig. 8B - it shows each row representing one of the connected data messages/events, each of the triggers/ Time/ Target/ Session ID/ Job ID is represented by a column of the data table, wherein the value of the column is either the dynamic ID/ Session ID/ Job ID if the trigger is activated for the connected data messages or NULL otherwise/ left blank). Regarding Claim 19, Mezaael teaches a non-transitory computer-readable medium comprising instructions for using a knowledge database to augment connected data messages ([0023] the vehicle computing platform include a processor, memory, and non-volatile storage;[0024] the processor configured to read into memory and execute computer-executable instructions embodied as vehicle software residing in the non-volatile storage; [0057] the trigger event definitions (i.e., knowledge database) received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle; [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle; responsive to identifying a trigger event from the sensor data (i.e., connected data messages) in block 306, the event evaluator cause the vehicle to communicate a notification to the cloud server that a trigger event has been identified; [0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers, and/or associated sensor data, to the cloud server over the network (i.e., augmenting connected data messages) that, when executed by a processor of a controller of a vehicle, cause the controller to perform operations ([0019] the vehicle ECUs (i.e., controller) configured to monitor and manage various functions of the vehicle; the vehicle ECUs include one or more of a radio transceiver controller configured to manage wireless communications with mobile devices; a powertrain controller configured to monitor and manage engine operating components; a body controller configured to monitor and manage various power control functions, etc.; [0023] the vehicle computing platform include a processor, memory, and non-volatile storage;[0024] the processor configured to read into memory and execute computer-executable instructions embodied as vehicle software residing in the non-volatile storage), including to: receive a knowledge database over a communication network from a cloud server, the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database and a plurality of triggers, each trigger including a first condition for activating the trigger and a second condition for deactivating the trigger ([0057] the trigger event definitions received from the cloud server; the event evaluator configured to store the trigger event definitions (i.e., plurality of triggers), as vehicle event data in the non-volatile storage of the vehicle (i.e., storage of the vehicle maintaining knowledge database); [0048] each defined trigger event relate to a driving behavior, such as excessive acceleration or excessive braking, and include instructions for recognizing the driving behavior, such as, sensing data indicative an acceleration level of the vehicle beyond a set threshold acceleration level (i.e., data element mapping of signals of the vehicle/ sensor signals to data elements of the knowledge database/ trigger definitions); [0054] one of the trigger events may correspond to an excessive acceleration event, and may be defined as a current acceleration of the vehicle being greater than a set acceleration threshold; another defined trigger event may correspond to an excessive braking event, and may be defined as a current deceleration of the vehicle being less than a set deceleration threshold; another defined trigger event may be a hard-steering event that corresponds to a change in heading of the vehicle or a change in steering wheel position that is beyond a set change threshold and is within a set timeframe, such as indicated in data generated by a compass, gyroscope, GPS module, and/or wheel position sensor of the vehicle, etc. (i.e., conditions for triggers); [0062] the vehicle monitor for trigger events defined in the vehicle event data; [0063] if the event evaluator determines that a defined trigger event has not occurred (i.e., including condition for deactivating trigger), then the event evaluator continue monitoring for defined trigger events; if a defined trigger event is identified from the sensor data (i.e., including condition for activating trigger), then the event evaluator begin capturing video showing one or more areas around the vehicle); process, by a controller of the vehicle, the triggers defined by the knowledge database, including to compare data elements of the connected data messages with the conditions of the triggers ([0019] the vehicle ECUs (i.e., controller) configured to monitor and manage various functions of the vehicle; the vehicle ECUs include one or more of a radio transceiver controller configured to manage wireless communications with mobile devices; a powertrain controller configured to monitor and manage engine operating components; a body controller configured to monitor and manage various power control functions, etc.; [0057] the trigger event definitions received from the cloud server; the event evaluator configured to store the trigger event definitions as vehicle event data in the non-volatile storage of the vehicle; [0062] the vehicle monitor for trigger events defined in the vehicle event data; the event evaluator configured to monitor for and identify the defined trigger events from data generated by the vehicle sensors (i.e., comparing data elements of the connected data messages with the conditions of the triggers/ trigger event definitions); [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle) ; augment, by the controller of the vehicle, the connected data messages that occur while the respective trigger is activated with a generated dynamic ID corresponding to the activating of the respective trigger ([0019] the vehicle ECUs (i.e., controller) configured to monitor and manage various functions of the vehicle; the vehicle ECUs include one or more of a radio transceiver controller configured to manage wireless communications with mobile devices; a powertrain controller configured to monitor and manage engine operating components; a body controller configured to monitor and manage various power control functions, etc.; [0063] if a defined trigger event is identified from the sensor data (“Yes” branch of block 306) , then the event evaluator begin capturing video showing one or more areas around the vehicle; responsive to identifying a trigger event from the sensor data (i.e., connected data messages) in block 306, the event evaluator cause the vehicle to communicate a notification to the cloud server that a trigger event has been identified; [0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers (i.e., dynamic ID), and/or associated sensor data, to the cloud server over the network (i.e., augmenting connected data messages/ sensor data while the respective trigger event has been identified)); and send the augmented connected data messages to the cloud server ([0072] the event evaluator automatically transmit the video data for the one or more server-defined trigger events, such as, the captured video, trigger event identifiers, and/or associated sensor data, to the cloud server over the network (i.e., augmented connected data messages/ sensor data to the cloud server)). However, Mezaael fails to expressly teach wherein augment each of the connected data messages with a generated dynamic ID. In the same field of endeavor, Okuma teaches wherein augment each of the connected data messages with a generated dynamic ID ([0094] the event collection module generates a login event about the login operation that the server is notified (i.e., connected data message), adds the session ID (i.e., dynamic ID) to the generated event, and then saves it in the message buffet; the event collection module holds the session ID until the logout of the user is detected and adds the same session ID to each event generated until logout). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have incorporated wherein augment each of the connected data messages with a generated dynamic ID, as taught by Okuma into Mezaael. Doing so would be desirable because it would improve the efficiency of analysis of a user's operation behavior/ event data (Okuma [0113]). Claim 20 is a medium claim similar to the system claim 6 above and therefore, rejected for the same reasons. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Mezaael in view of Okuma, further in view of Zhang et al. (US 2021/0194904 A1 hereinafter Zhang) and Prabhakara et al. (US 2018/0083825 A1 hereinafter Prabhakara). As to dependent Claim 13, Mezaael and Okuma teach all the limitations of Claim 11. However, Mezaael and Okuma fail to expressly teach wherein receiving, by the cloud server from a client device, a query for connected data messages, the query specifying at least one dynamic ID is non-NULL; querying a data store accessible to the cloud server using the query; and sending the results of the query to the client device. In the same field of endeavor, Zhang teaches wherein a query for connected data messages, the query specifying at least one dynamic ID is non-NULL ([0058] the server obtain an event log; the event log received from a computing device associated with the vehicle, parsed, stored in a database associated with the server; the server obtain all records associated with the event corresponding to the event log; the server may obtain a vehicle identifier and an event identifier from the event log; it may query the database storing a plurality of event logs (i.e., querying for connected data messages) using the vehicle identifier and the event identifier and obtain all the event logs with the vehicle identifier and event identifier (i.e., dynamic ID is non-NULL)); querying a data store accessible to the cloud server using the query ([0058] the server obtain an event log; the event log received from a computing device associated with the vehicle, parsed, stored in a database associated with the server; the server obtain all records associated with the event corresponding to the event log; the server 160 may obtain a vehicle identifier and an event identifier from the event log; it may query the database storing a plurality of event logs using the vehicle identifier and the event identifier and obtain all the event logs with the vehicle identifier and event identifier (i.e., querying data store accessible to the cloud server); and sending the results of the query to the client device ([0058] the server may query the database storing a plurality of event logs using the vehicle identifier and the event identifier and obtain all the event logs with the vehicle identifier and event identifier (i.e., dynamic ID is non-NULL); the server proceed to determine whether the event corresponds to a type that may create a security threat; [0059] the server process the event log using a detection logic configured to process event logs of the type “wlmodify” to determine whether to create an alert; [0015] the system comprise a client associated with the vehicle and a server; monitoring, by the client, a plurality of activities of one or more electronic devices associated with the vehicle; generating, by the client, a plurality of event logs based on the monitored activities; sending, by the client to the server, the generated event logs; and receiving, by the client from the server, one or more alerts created based on the generated event logs (i.e., sending the results of the query to the client device)). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have incorporated wherein a query for connected data messages, the query specifying at least one dynamic ID is non-NULL; querying a data store accessible to the cloud server using the query; and sending the results of the query to the client device, as taught by Zhang into Mezaael and Okuma. Doing so would be desirable because it would allow for accurately identifying events to capture and analyze the events to determine the nature of any related security threats/ events (Zhang [0028]). However, Mezaael, Okuma, and Zhang fail to expressly teach wherein receiving, by the cloud server from a client device, a query and sending the results of the query to the client device. In the same field of endeavor, Prabhakara teaches wherein receiving, by the cloud server from a client device, the query ([0045] the database server store the event log; [0047] the database server receive a query from the one or more organizational computing-devices or the first user computing-device (i.e., client device) to extract/store information from/to the database server; [0054] system 200 correspond to the application server or the first user computing-device; [0055] the system 200 includes one or more processors, such as a processor 202; [0074] the processor 202 request the database server to filter the event log based on the clients belonging to the type specified by the user (i.e., receiving the query by the cloud server/ database server from a client device/ the processor 202) and sending the results of the query to the client device ([0074] the processor 202 request the database server to filter the event log based on the clients belonging to the type specified by the user; based on the filtering of the event log, the processor retrieve event data related to execution of processes specific to the clients that belong to the type specified by the user, from the database server (equivalent to sending results to the client device). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have incorporated wherein receiving, by the cloud server from a client device, the query and sending the results of the query to the client device, as taught by Prabhakara into Mezaael, Okuma, and Zhang. Doing so would be desirable because it would provide insights for performance and optimize the execution of the processes across the multiple clients (Prabhakara [0003]). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 CFR § 1.111(c) to consider these references fully when responding to this action. Tsuchida et al. (US 2017/0099177 A1) teaches: when the AP server application detect a failure as an event in the course of executing the processing according to the request, the AP server application generates an HMI message for displaying the contents of the failure and an HMI message code, in which information of the contents of the failure is coded, stores an application log including the generated HMI message and HMI message code in the log buffer, sends a transaction ID (cTID) added to the request and a response message storing the generated HMI message and HMI message code to the mobile terminal via the connection interface, and stores a response transmission log including the transaction ID (cTID), the HMI message and the HMI message code in the log buffer 27 (see [0038]). Any inquiry concerning this communication or earlier communications from the examiner should be directed to REJI KARTHOLY whose telephone number is (571)272-3432. The examiner can normally be reached on Monday - Thursday from 7:30 am to 3:30 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jennifer Welch, can be reached at telephone number 571-272-7212. 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. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, 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. /REJI KARTHOLY/Primary Examiner, Art Unit 2143
Read full office action

Prosecution Timeline

Dec 21, 2022
Application Filed
Feb 11, 2026
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585963
METHOD AND DEVICE FOR LEARNING A STRATEGY AND FOR IMPLEMENTING THE STRATEGY
2y 5m to grant Granted Mar 24, 2026
Patent 12585988
SYSTEMS AND METHODS FOR GENERATING AND APPLYING A SECURE STATISTICAL CLASSIFIER
2y 5m to grant Granted Mar 24, 2026
Patent 12572395
Method and Devices for Latency Compensation
2y 5m to grant Granted Mar 10, 2026
Patent 12572846
SYSTEM AND METHOD FOR DEVICE ATTRIBUTE IDENTIFICATION BASED ON HOST CONFIGURATION PROTOCOLS
2y 5m to grant Granted Mar 10, 2026
Patent 12569702
RADIOTHERAPY METHODS, SYSTEMS, AND WORKFLOW-ORIENTED GRAPHICAL USER INTERFACES
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
64%
Grant Probability
99%
With Interview (+71.8%)
3y 4m
Median Time to Grant
Low
PTA Risk
Based on 151 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month