DETAILED ACTION
This Office Action is in response to Applicant's Communication received on 05/18/2026 for the above identified application.
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 .
Response to Amendment
The amendment filed on 05/18/2026 has been entered.
Claims 1, 9, and 19 are amended. Claims 2 and 10 are canceled. Claims 1, 3-9, and 11-20 are pending in the application.
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 and 2-8 are directed to a system, Claims 9 and 11-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:
apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database, process the triggers defined by the knowledge database, including to compare data elements of the connected data messages mapped from the signals of the vehicle with the conditions of the triggers, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, 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 applying defined mapping between vehicle signals and data elements, observing description of triggers, making an evaluation/ judgement to compare a message/ data with trigger conditions, activate the trigger when the trigger condition is met, keep the trigger active until a deactivating condition is satisfied, and adding a label/ ID to the messages based on the messages satisfying certain trigger conditions. Comparing values against conditions to decide whether a condition is met and labeling records with an identifier during the interval a condition holds are steps a person could perform mentally or with pen and paper.
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 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements - 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 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements- 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements; 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 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements - 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 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements - 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, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements; 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 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 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, 3-9, 11-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), further in view of Chronowski et al. (US 2015/0279125 A1 hereinafter Chronowski).
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 including a plurality of triggers, each trigger including a first condition for activating 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 a defined trigger event is identified from the sensor data (i.e., 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 mapped from the signals of the vehicle 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 based on signals 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), 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 a second condition for deactivating the trigger, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, and augment each of the connected data messages with a generated dynamic ID.
In the same field of endeavor, Okuma teaches wherein a second condition for deactivating the trigger ([0094] event collection module is notified of the login event (i.e., first condition for activating the trigger) from the function application that controls the login process generates a session ID to be added to the operation event; the event collection module generates an event (login event) about the login operation that the server is notified, adds the session ID to the generated event, and then saves it in the message buffer; the event collection module holds the session ID until the logout of the user is detected (i.e., second condition for deactivating the trigger) and adds the same session ID to each event generated until logout), such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied ([0094] event collection module is notified of the login event from the function application that controls the login process generates a session ID to be added to the operation event; the session ID is mainly used to distinguish a series of user operations that are given from login to logout from an operation of the same user of a time of another login; the event collection module generates an event (login event) about the login operation that the server is notified, adds the session ID to the generated event, and then saves it in the message buffer; 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 - thus, the session activation is created responsive to the first condition (login) being satisfied and remains active, with its identifier held and applied to each event, until the second condition (logout) is satisfied), and 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 a second condition for deactivating the trigger, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, and 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]).
However, Mezaael and Okuma fail to expressly teach wherein the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements, and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database.
In the same field of endeavor, Chronowski teaches wherein the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database ([0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0038] the trigger conditions include vehicle data exceeding one or more vehicle dynamic thresholds indicating vehicle pursuit, such as, high g-forces, acceleration, braking, etc.; vehicle data being indicative of one or abnormal vehicle operating conditions, such as, low fuel, system malfunction, etc. (i.e., mapping of signals of vehicles to trigger conditions in the data store/ data elements of knowledge database)), wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements ([0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0038] the trigger conditions include vehicle data exceeding one or more vehicle dynamic thresholds indicating vehicle pursuit, such as, high g-forces, acceleration, braking, etc.; vehicle data being indicative of one or abnormal vehicle operating conditions, such as, low fuel, system malfunction, etc. (i.e., first condition of trigger); [0039 ]the trigger conditions also include terminating trigger conditions; terminating trigger conditions include satisfaction of one or more conditions, such as vehicle key-off, reduced vehicle speeds, or relaxed vehicle braking (i.e., second condition of trigger) - thus, the conditions of trigger are defined in terms of data elements/ trigger conditions in the datastore)), and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database ([0052] provide the collected vehicle data in one or more messages (i.e., connected data messages) to the telematics service provider; [0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0047] the telematics service provider create one or more commands to be provided to the vehicle, where the commands include any adjustments to the reporting settings to be performed as specified by the trigger conditions that are met or expired).
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 the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements, and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database, as taught by Chronowski into Mezaael and Okuma. Doing so would be desirable because it would provide increased granularity of the vehicle data during certain conditions (Chronowski [0055]).
As to dependent Claim 3, Mezaael, Okuma, and Chronowski 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, Okuma, and Chronowski 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, Okuma, and Chronowski 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, Okuma, and Chronowski 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, Okuma, and Chronowski 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, Okuma, and Chronowski 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, Okuma, and Chronowski 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 ([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 the triggers defined by the knowledge database, including to compare data elements of the connected data messages mapped from the signals 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 based on signals 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) ;
augment the connected data messages mapped from the signals of the vehicle that occur while the respective trigger is activated with a generated dynamic ID corresponding to the activating of the respective trigger ([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., mapping of signals of the vehicle/ sensor signals to data elements of the knowledge database/ trigger 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; responsive to identifying a trigger event from the sensor data (i.e., connected data messages based on the sensor signal-trigger definition mapping) 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 a second condition for deactivating the trigger and augment each of the connected data messages with a generated dynamic ID, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied.
In the same field of endeavor, Okuma teaches wherein a second condition for deactivating the trigger ([0094] event collection module is notified of the login event (i.e., first condition for activating the trigger) from the function application that controls the login process generates a session ID to be added to the operation event; the event collection module generates an event (login event) about the login operation that the server is notified, adds the session ID to the generated event, and then saves it in the message buffer; the event collection module holds the session ID until the logout of the user is detected (i.e., second condition for deactivating the trigger) and adds the same session ID to each event generated until logout), and 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), such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied ([0094] event collection module is notified of the login event from the function application that controls the login process generates a session ID to be added to the operation event; the session ID is mainly used to distinguish a series of user operations that are given from login to logout from an operation of the same user of a time of another login; the event collection module generates an event (login event) about the login operation that the server is notified, adds the session ID to the generated event, and then saves it in the message buffer; 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 - thus, the session activation is created responsive to the first condition (login) being satisfied and remains active, with its identifier held and applied to each event, until the second condition (logout) is satisfied).
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 second condition for deactivating the trigger and augment each of the connected data messages with a generated dynamic ID, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, 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]).
However, Mezaael and Okuma fail to expressly teach wherein the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements, and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database.
In the same field of endeavor, Chronowski teaches wherein the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database ([0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0038] the trigger conditions include vehicle data exceeding one or more vehicle dynamic thresholds indicating vehicle pursuit, such as, high g-forces, acceleration, braking, etc.; vehicle data being indicative of one or abnormal vehicle operating conditions, such as, low fuel, system malfunction, etc. (i.e., mapping of signals of vehicles to trigger conditions in the data store/ data elements of knowledge database)), wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements ([0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0038] the trigger conditions include vehicle data exceeding one or more vehicle dynamic thresholds indicating vehicle pursuit, such as, high g-forces, acceleration, braking, etc.; vehicle data being indicative of one or abnormal vehicle operating conditions, such as, low fuel, system malfunction, etc. (i.e., first condition of trigger); [0039 ]the trigger conditions also include terminating trigger conditions; terminating trigger conditions include satisfaction of one or more conditions, such as vehicle key-off, reduced vehicle speeds, or relaxed vehicle braking (i.e., second condition of trigger) - thus, the conditions of trigger are defined in terms of data elements/ trigger conditions in the datastore)), and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database ([0052] provide the collected vehicle data in one or more messages (i.e., connected data messages) to the telematics service provider; [0041] the data store maintain the vehicle data and the trigger conditions used to generate the commands; the data store may be used to store trigger conditions that are associated with vehicles according to vehicle identifier, which vehicles are associated with which fleets, such as, mapping vehicle identifiers to fleet identifiers and which trigger conditions are associated with which fleets according to fleet identifier; store trigger conditions that are associated with vehicles in general, trigger conditions that are associated with vehicles that are a part of a fleet, and/or trigger conditions that are associated with specific vehicles; [0047] the telematics service provider create one or more commands to be provided to the vehicle, where the commands include any adjustments to the reporting settings to be performed as specified by the trigger conditions that are met or expired).
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 the knowledge database including a data element mapping of signals of the vehicle to data elements of the knowledge database, wherein the first condition and the second condition of each trigger are each defined in terms of one or more of the data elements, and apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database, as taught by Chronowski into Mezaael and Okuma. Doing so would be desirable because it would provide increased granularity of the vehicle data during certain conditions (Chronowski [0055]).
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 and Chronowski, 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, Okuma, and Chronowski teach all the limitations of Claim 11. However, Mezaael, Okuma, and Chronowski 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, Okuma, and Chronowski. 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, Chronowski, 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, Chronowski, 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]).
Response to Arguments
Claim Objections: Applicant’s amendments have overcome the claim objections previously set forth.
35 U.S.C. §101: In the remarks, Applicant argues that:
(a) Step 2A prong 1: These mapping, triggering, and augmenting operations performed on the vehicle's messages are not records that are practical for a human to scan and manipulate with pen and paper. The claimed data element mapping transforms heterogeneous, vehicle-specific signals into a normalized data structure that is not present in the input messages themselves, enabling the trigger evaluation independent of the vehicle's signal format. This is also not a mental categorization.
(b) Step 2A prong 2: The additional elements integrate a practical application. The specification at [0004] describes the technical purpose served by the claimed architecture. The claimed applying of the data element mapping and the trigger processing operations implement this architecture by enforcing a separation between vehicle- specific signals and trigger logic defined in terms of normalized data elements.
(c) Step 2B: The Office Action has not identified any evidence that this specific10
combination of operations is well-understood, routine, or conventional.
Examiner respectfully disagrees with applicant’s arguments.
As to point (a), as analyzed in detail under Step 2A, Prong 1 portion of the 35 U.S.C. 101 rejections above, Claims 1, 9, and 19 do recite abstract ideas that falls under the “mental processes” grouping. The claims recites “apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database, process the triggers defined by the knowledge database, including to compare data elements of the connected data messages mapped from the signals of the vehicle with the conditions of the triggers, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, 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.” The recited act of mapping signals to data elements and comparing data elements with trigger conditions is a correlation and evaluation a person can perform. The claimed limitations encompass a user to perform these steps mentally or by using pen and paper, such as a user applying defined mapping between vehicle signals and data elements, observing description of triggers, making an evaluation/ judgement to compare a message/ data with trigger conditions, activate the trigger when the trigger condition is met, keep the trigger active until a deactivating condition is satisfied, and adding a label/ ID to the messages based on the messages satisfying certain trigger conditions. Examiner notes that the data element mapping transforming heterogeneous, vehicle-specific signals into a normalized data structure that is not present in the input messages themselves is not specifically recited in the claims. Further, reorganizing or normalizing data into a different representation is itself a species of data manipulation that courts have treated as abstract (MPEP 2106.04(a)(2)). Accordingly, the claims recite abstract idea. See the detailed analysis under 35 U.S.C. 101 rejections above.
As to point (b), as analyzed under Step 2A, Prong 2 portion of the 35 U.S.C. 101 rejections above, the additional elements amount to no more than insignificant extra-solution activity of mere data gathering (see MPEP § 2106.05(g)) and using generic computer components as a tool to apply the judicial exception (see MPEP § 2106.05(f)).
Any purported improvement is an improvement to the abstract idea itself - i.e., organizing and labeling data so it’s easier to group and query (see spec [0016]), not an improvement to the functioning of a computer or technological process. Examiner notes that “It is important to keep in mind that an improvement in the abstract idea itself is not an improvement in technology” (see MPEP 2106.05(a)(II)). The claims recite abstract ideas and the 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. See the detailed analysis under 35 U.S.C. 101 rejections above.
As to point (c), the steps of “apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database, process the triggers defined by the knowledge database, including to compare data elements of the connected data messages mapped from the signals of the vehicle with the conditions of the triggers, such that a respective trigger of the plurality of triggers is activated responsive to the first condition of the respective trigger being satisfied and remains activated until the second condition of the respective trigger is satisfied, 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” are abstract ideas as analyzed in detail under Step 2A, Prong 1 portion of the 35 U.S.C. 101 rejections above. As analyzed under Step 2B portion, the additional elements the Office Action identified as WURC are the generic storage storing data, controller, and receiving/ transmitting data over network – and MPEP 2106.05(d)(II) enumerates “Storing and retrieving information in memory” and “Receiving or transmitting data over a network” as court recognized WURC functions. A citation of MPEP’s enumerated functions and their supporting decision is itself one of the evidentiary forms, so the finding can be properly supported. The additional elements recited in the claims do not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea and do not amount to significantly more than the judicial exception. As such, the claim does not provide an inventive concept and is patent ineligible. See the detailed analysis under 35 U.S.C. 101 rejections above.
Accordingly, Applicant’s arguments concerning the §101 rejections are not persuasive.
35 U.S.C. §103: In the remarks, applicant argues that the cited do not teach or suggest to "apply the data element mapping to map signals of the vehicle in the connected data messages to the data elements of the knowledge database" as recited by amended claim 1, and similar claims 9 and 19.
Applicant's arguments with respect to the 103 rejections have been considered, but are moot in view of new ground of rejection made under 35 U.S.C. § 103.
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.
Onti Srinivasan et al. (US 2023/0171314 A1) teaches: vehicle model configuration having a hierarchical tree structure that uses a vehicle signal catalog and enables a unified signal representation to be used in collecting data using a common data collection scheme across a fleet of heterogenous vehicle models; the signal catalog contain signal attributes that are used by the OEMs across multiple models of their vehicles or sensors; the signal catalog may follow a Vehicle Signal Specification (VSS) naming guide and may be accessible using qualified names; after the model configuration is created, decoding rules for all the vehicle sensors in the model configuration are obtained; decoding rules would enable customers to collect data from the sensors that are listed in the model configuration; the decoder rules include a mapping file that maps signal names given in the CAN DBCs to the signal name given in the model configuration (see [0033], [0046], [0051]).
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 REJI KARTHOLY whose telephone number is (571)272-3432. The examiner can normally be reached on Monday - Thursday 7:30 am - 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
Prosecution Insights