DETAILED ACTION
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of Claims
The following is an office action in response to the communication filed on 11/21/2025.
Claim 1, 11, and 14 are amended.
Claims 1-20 are currently pending.
Claims 1-20 have been examined.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 6-7, 11, 14, and 16-17 are rejected under 35 U.S.C. 103) as being unpatentable over Chronowski et al. (US 20150279125 A1; hereinafter Chronowski).
Regarding claim 1, Chronowski discloses the subject matter indicated in bold below.
A method in a telematics device coupled to an asset communications bus of a vehicle (see Chronowski at least [0002] “Vehicle telematics units may be utilized to allow a user of a vehicle to interact with services available over a communications network.”; [0011] “A vehicle-based computing system (VCS), such as a vehicle telematics unit . . .”; [0019] “Although not shown, numerous of the vehicle components and auxiliary components in communication with the VCS 1 may use a vehicle network (such as, but not limited to, a car area network (CAN) bus) to pass data to and from the VCS 1 (or components thereof).”), the method comprising:
Receiving, at the telematics device, a log and trigger configuration comprising a unified data structure including . . . a trigger condition, and an action indicator, via a network interface (see Chronowski at least [0032] “The VCS 1 may be configured to provide vehicle data 202 over the network 61 to the telematics service provider 206 in accordance with the current reporting settings 204. The telematics service provider 206 may be configured to receive and maintain the vehicle data 202, as well as maintain one or more trigger conditions 208.”; [0040] “. . . the command 210 may specify an indication of which set of reporting settings 204 maintained by the vehicle 31 should be used by the vehicle 31 (e.g., normal reporting mode, faster reporting mode, etc.) [(i.e., command sent to telematics device over network includes an action indicator (change trigger condition) and a trigger condition (which trigger condition))].”);
creating a trigger configuration including a trigger condition and an associated action (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”);
associating the trigger configuration with a log configuration (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”); and
in response to detecting the trigger condition, performing the associated action (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”).
While Chronowski discloses receiving, at the telematics device, a log and trigger configuration comprising a unified data structure including a trigger condition and an action indicator, via a network interface, it does not appear to explicitly disclose receiving, at the telematics device, a log and trigger configuration comprising a unified data structure including a log identifier, trigger condition, and an action indicator, via a network interface.
However, Chronowski also discloses use of a CAN bus for data transmission to the vehicle telematics units (see Chronowski at least [0019] “. . . components in communication with the VCS 1 may use a vehicle network (such as, but not limited to, a car area network (CAN) bus) to pass data to and from the VCS 1 (or components thereof).”). The arbitration field of CAN frames used in data transmission over CAN buses serves as a log identifier and is necessary for decoding by receivers. In this case, information being sent over a CAN network would thus necessarily require an identifier to be unified with the trigger conditions and action indicator. Thus, it would be prima facie obvious to one of ordinary skill in the art to combine with a reasonable expectation of success the receiving, at the telematics device, a log and trigger configuration comprising a unified data structure including a trigger condition and an action indicator, via a network interface of Chronowski with the CAN bus for data transmission to the vehicle telematics units also of Chronowski to receive, at the telematics device, a log and trigger configuration comprising a unified data structure including a log identifier, trigger condition, and an action indicator, via a network interface. Doing so would provide a means for effective communication to and from the vehicle telematics device.
Regarding claim 3, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . further comprising in response to determining that the log and trigger configuration contains an existing log identifier, identifying the log configuration associated with the existing log identifier (see Chronowski at least [0042] “The data store 212 may be configured to be queried by vehicle identifier, and may provide any trigger conditions 208 that match to the specified vehicle 31 or to vehicles 31 generally.”).
Regarding claim 6, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein detecting the trigger condition comprises capturing asset data from the vehicle via the asset communications bus and evaluating the trigger condition for the asset data (see Chronowski at least [0053] “The trigger conditions 208 may include, as some non-limiting specific examples, that vehicle dynamics data retrieved from the vehicle systems is indicative of a pursuit being performed by the vehicle 31, and/or abnormal vehicle 31 conditions, such as low fuel or an indication of a vehicle 31 malfunction.”).
Regarding claim 7, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein detecting the trigger condition comprises evaluating the trigger condition for debug data generated by the telematics device (see Chronowski at least [0039] “. . . the terminating trigger conditions may include a predetermined about of time having passed since the initiating trigger conditions were met (e.g., a predetermined timeout).”; [0044] “The vehicle data 202 may include information from vehicle systems as discussed above, as well as other information, such as vehicle geographic location, date and time information during which the vehicle data 202 was collected, and information identifying the sending vehicle 31 [(i.e., debugging data)].”).
Regarding claim 11, Chronowski discloses the subject matter indicated in bold below:
A telematics device for coupling to an asset communications bus of a vehicle (see Chronowski at least [0019] “. . . numerous of the vehicle components and auxiliary components in communication with the VCS 1 may use a vehicle network (such as, but not limited to, a car area network (CAN) bus) to pass data to and from the VCS 1 (or components thereof).”; [0032] “. . . an exemplary telematics system 200 including a remote telematics service provider 206 in communication via network 61 with the VCS 1 of the vehicle 31.”), the telematics device comprising:
a controller (see Chronowski at least [0003] “. . . a system includes at least one controller of a vehicle . . .”);
a network interface coupled to the controller (see Chronowski at least [0019] “. . . numerous of the vehicle components and auxiliary components in communication with the VCS 1 may use a vehicle network (such as, but not limited to, a car area network (CAN) bus) to pass data to and from the VCS 1 (or components thereof).”; [0021] “. . . the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 . . .”); and
a memory coupled to the controller and storing machine-executable programming instructions which, when executed by the controller, configure the telematics device to (see Chronowski at least [0018] “. . . the non-persistent storage 5 is random access memory (RAM) and the persistent storage 7 is a hard disk drive (HDD) or flash memory. In general, persistent (non-transitory) storage 7 can include all forms of memory that maintain data when a computer or other device is powered down. These include, but are not limited to, HDDs, compact disks (CDs), digital versatile disks (DVDs), magnetic tapes, solid state drives, portable universal serial bus (USB) drives and any other suitable form of persistent storage 7.”):
receive, via the network interface, a log and trigger configuration comprising a unified data structure including . . . a trigger condition, and an action indicator (see Chronowski at least [0032] “The VCS 1 may be configured to provide vehicle data 202 over the network 61 to the telematics service provider 206 in accordance with the current reporting settings 204. The telematics service provider 206 may be configured to receive and maintain the vehicle data 202, as well as maintain one or more trigger conditions 208.”; [0040] “. . . the command 210 may specify an indication of which set of reporting settings 204 maintained by the vehicle 31 should be used by the vehicle 31 (e.g., normal reporting mode, faster reporting mode, etc.) [(i.e., command sent to telematics device over network includes an action indicator (change trigger condition) and a trigger condition (which trigger condition))].”);
create a trigger configuration including a trigger condition and an associated action (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”);
associate the trigger configuration with a log configuration (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”); and
in response to detecting the trigger condition, perform the associated action (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”).
While Chronowski discloses receiving, via a network interface, a log and trigger configuration comprising a unified data structure including a trigger condition and an action indicator, it does not appear to explicitly disclose receiving, via a network interface, a log and trigger configuration comprising a unified data structure including a log identifier, trigger condition, and an action indicator, via a network interface.
However, Chronowski also discloses use of a CAN bus for data transmission to the vehicle telematics units (see Chronowski at least [0019] “. . . components in communication with the VCS 1 may use a vehicle network (such as, but not limited to, a car area network (CAN) bus) to pass data to and from the VCS 1 (or components thereof).”). The arbitration field of CAN frames used in data transmission over CAN buses serves as a log identifier and is necessary for decoding by receivers. In this case, information being sent over a CAN network would thus necessarily require an identifier to be unified with the trigger conditions and action indicator. Thus, it would be prima facie obvious to one of ordinary skill in the art to combine with a reasonable expectation of success the receiving, via a network interface, a log and trigger configuration comprising a unified data structure including a trigger condition and an action indicator, of Chronowski with the CAN bus for data transmission to the vehicle telematics units also of Chronowski to receive, via a network interface, a log and trigger configuration comprising a unified data structure including a log identifier, trigger condition, and an action indicator. Doing so would provide a means for effective communication to and from the vehicle telematics device.
Regarding claim 13, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein the machine-executable programming instructions further configure the telematics device to in response to determining that the log and trigger configuration contains an existing log identifier, identify the log configuration associated with the existing log identifier (see Chronowski at least [0042] “The data store 212 may be configured to be queried by vehicle identifier, and may provide any trigger conditions 208 that match to the specified vehicle 31 or to vehicles 31 generally.”).
Regarding claim 16, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein the machine-executable programming instructions which configure the telematics device to detect the trigger condition comprise machine-executable programming instructions which configure the telematics device to capture asset data from the vehicle via the asset communications bus and evaluate the trigger condition for the asset data (see Chronowski at least [0053] “The trigger conditions 208 may include, as some non-limiting specific examples, that vehicle dynamics data retrieved from the vehicle systems is indicative of a pursuit being performed by the vehicle 31, and/or abnormal vehicle 31 conditions, such as low fuel or an indication of a vehicle 31 malfunction.”).
Regarding claim 17, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein the machine-executable programming instructions which configure the telematics device to detect the trigger condition comprise machine-executable programming instructions which configure the telematics device to evaluate the trigger condition for debug data generated by the telematics device (see Chronowski at least [0039] “. . . the terminating trigger conditions may include a predetermined about of time having passed since the initiating trigger conditions were met (e.g., a predetermined timeout).”; [0044] “The vehicle data 202 may include information from vehicle systems as discussed above, as well as other information, such as vehicle geographic location, date and time information during which the vehicle data 202 was collected, and information identifying the sending vehicle 31 [(i.e., debugging data)].”).
Claims 2, 4, 10, 12, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chronowski in view of Ma et al. (US 10095765 B1; hereinafter Ma).
Regarding claim 2, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above.
While Chronowski discloses having log and trigger configurations (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”), it does not appear to explicitly disclose, in response to determining that the log and trigger configuration contains a new log identifier, creating the log configuration based on the log and trigger configuration.
Ma teaches the subject matter underlined below:
. . . further comprising in response to determining that the log and trigger configuration contains a new log identifier, creating the log configuration based on the log and trigger configuration (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configurations of Chronowski with the, in response to determining that the log and trigger configuration contains a new log identifier, creating the log configuration based on the log and trigger configuration as taught by Ma to, in response to determining that the log and trigger configuration contains a new log identifier, create the log configuration based on the log and trigger configuration. Doing so would ensure that pertinent identifying information is captured in logging.
Regarding claim 4, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above.
While Chronowski discloses creating a log configuration (see Chronowski at least [0032] “The VCS 1 may be configured to provide vehicle data 202 over the network 61 to the telematics service provider 206 in accordance with the current reporting settings 204. The telematics service provider 206 may be configured to receive and maintain the vehicle data 202, as well as maintain one or more trigger conditions 208.”), it does not appear to explicitly disclose creating an AVL tree node in an AVL tree for storing the log configuration.
Ma teaches the subject matter underlined below:
. . . wherein creating the log configuration comprises creating an AVL tree node in an AVL tree for storing the log configuration (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the creating a log configuration of Chronowski with the creating an AVL tree node in an AVL tree for storing the log configuration as taught by Ma to create an AVL tree node in an AVL tree for storing the log configuration. Doing so would provide a means for capturing and logging information.
Regarding claim 10, Chronowski and Ma disclose the subject matter of claim 4 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein the log and trigger configuration includes a data trigger type (see Chronowski at least [0038] “. . . the trigger conditions 208 may include vehicle data 202 being indicative of one or abnormal vehicle operating conditions (e.g., low fuel, system malfunction, etc.).”), . . .
While Chronowski discloses the log and trigger configuration including a data trigger type, it does not appear to explicitly disclose the AVL tree being selected from a plurality of AVL trees based on the data trigger type.
Ma teaches the subject matter underlined below:
. . . and the AVL tree is selected from a plurality of AVL trees based on a tree identifier (see Ma at least pg. 13, col. 7, lines 18-36 “. . . the AVL trees. As discussed briefly above, each AVL tree table can be identified by a tree identifier and each record in the tree associated with a unique index.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configuration including a data trigger type of Chronowski with the AVL tree being selected from a plurality of AVL trees based on a tree identifier as taught by Ma to have the AVL tree be selected from a plurality of AVL trees based on the data trigger type. Doing so would organize the data storage system by data trigger type, therefore improving indexing for subsequent reference or retrieval.
Regarding claim 12, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above.
While Chronowski discloses having log and trigger configurations (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”), it does not appear to explicitly disclose, in response to determining that the log and trigger configuration contains a new log identifier, creating the log configuration based on the log and trigger configuration.
Ma teaches the subject matter underlined below:
. . . wherein the machine-executable programming instructions further configure the telematics device to in response to determining that the log and trigger configuration contains a new log identifier, create the log configuration based on the log and trigger configuration (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configurations of Chronowski with the, in response to determining that the log and trigger configuration contains a new log identifier, creating the log configuration based on the log and trigger configuration as taught by Ma to, in response to determining that the log and trigger configuration contains a new log identifier, create the log configuration based on the log and trigger configuration. Doing so would ensure that pertinent identifying information is captured in logging.
Regarding claim 14, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above.
While Chronowski discloses creating a log configuration (see Chronowski at least [0032] “The VCS 1 may be configured to provide vehicle data 202 over the network 61 to the telematics service provider 206 in accordance with the current reporting settings 204. The telematics service provider 206 may be configured to receive and maintain the vehicle data 202, as well as maintain one or more trigger conditions 208.”), it does not appear to explicitly disclose creating an AVL tree node in an AVL tree for storing the log configuration.
Ma teaches the subject matter underlined below:
. . . wherein the machine-executable programming instructions which configure the telematics device to create the log configuration comprise machine-executable programming instructions which configure the telematics device to create an AVL tree node in an AVL tree for storing the log configuration (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the creating a log configuration of Chronowski with the creating an AVL tree node in an AVL tree for storing the log configuration as taught by Ma to create an AVL tree node in an AVL tree for storing the log configuration. Doing so would provide a means for capturing and logging information.
Regarding claim 20, Chronowski discloses the subject matter of claim 14 as recited in the claim and applied above. Additionally, Chronowski discloses the subject matter indicated in bold below:
. . . wherein the log and trigger configuration includes a data trigger type (see Chronowski at least [0038] “. . . the trigger conditions 208 may include vehicle data 202 being indicative of one or abnormal vehicle operating conditions (e.g., low fuel, system malfunction, etc.).”), . . .
While Chronowski discloses the log and trigger configuration including a data trigger type, it does not appear to explicitly disclose the AVL tree being selected from a plurality of AVL trees based on the data trigger type.
Ma teaches the subject matter underlined below:
. . . and the AVL tree is selected from a plurality of AVL trees based on a tree identifier (see Ma at least pg. 13, col. 7, lines 18-36 “. . . the AVL trees. As discussed briefly above, each AVL tree table can be identified by a tree identifier and each record in the tree associated with a unique index.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configuration including a data trigger type of Chronowski with the AVL tree being selected from a plurality of AVL trees based on a tree identifier as taught by Ma to have the AVL tree be selected from a plurality of AVL trees based on the data trigger type. Doing so would organize the data storage system by data trigger type, therefore improving indexing for subsequent reference or retrieval.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Chronowski in view of Ma and further in view of Giannella et al. (US 20190158581 A1; hereinafter Giannella).
Regarding claim 5, Chronowski and Ma disclose the subject matter of claim 4 as recited in the claim and applied above.
While Chronowski discloses associating a trigger configuration with a log configuration (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”), it does not appear to explicitly disclose adding the trigger configuration to a list connected to an AVL tree node.
Ma teaches storing the log configuration in an AVL tree (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the associating a trigger configuration with a log configuration of Chronowski with the storing the log configuration in an AVL tree as taught by Ma to store the log and associated trigger configuration in an AVL tree node. Doing so would provide a means for recording the log configuration.
While Chronowski and Ma disclose storing the log and associated trigger configuration in an AVL tree node, they do not appear to explicitly disclose adding the trigger configuration to a list connected to the AVL tree node.
Giannella teaches adding the trigger configuration to a list (see Giannella at least [0067] “. . . process 300 may include outputting event data . . . Event data may include . . . information associated the set of signals sampled, the set of sampling rates, the event or validation thresholds used in the detection and validation steps, that an event has occurred or has been validated, or any other information associated with FIGS. 3-8.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the storing the log and associated trigger configuration in an AVL tree node of Chronowski and Ma with the adding the trigger configuration to a list as taught by Giannella to add the trigger configuration to a list connected to the AVL tree node. Doing so would provide a means for storing the log and associated trigger information in an AVL tree node.
Regarding claim 15, Chronowski and Ma disclose the subject matter of claim 14 as recited in the claim and applied above.
While Chronowski discloses associating a trigger configuration with a log configuration (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions.”), it does not appear to explicitly disclose adding the trigger configuration to a list connected to an AVL tree node.
Ma teaches storing the log configuration in an AVL tree (see Ma at least pg. 13, col. 8, lines 20-30 “As input, the ‘insert’ function is configured to take arguments that correspond to a key and an index for a record that is to be inserted into the AVL tree. Given the key and the index, the insert function inserts a new record having this information into the AVL tree.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the associating a trigger configuration with a log configuration of Chronowski with the storing the log configuration in an AVL tree as taught by Ma to store the log and associated trigger configuration in an AVL tree node. Doing so would provide a means for recording the log configuration
While Chronowski and Ma disclose storing the log and associated trigger configuration in an AVL tree node, they do not appear to explicitly disclose adding the trigger configuration to a list connected to the AVL tree node.
Giannella teaches adding the trigger configuration to a list (see Giannella at least [0067] “. . . process 300 may include outputting event data . . . Event data may include . . . information associated the set of signals sampled, the set of sampling rates, the event or validation thresholds used in the detection and validation steps, that an event has occurred or has been validated, or any other information associated with FIGS. 3-8.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the storing the log and associated trigger configuration in an AVL tree node of Chronowski and Ma with the adding the trigger configuration to a list as taught by Giannella to add the trigger configuration to a list connected to the AVL tree node. Doing so would provide a means for storing the log and associated trigger information in an AVL tree node.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chronowski in view of Baker (US 10268823 B2; hereinafter Baker).
Regarding claim 8, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above.
While Chronowski discloses log and trigger configurations and performing commands as associated actions (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”), it does not appear to explicitly disclose the log and trigger configuration comprising a callback function and performing the associated action comprising calling the callback function.
Baker teaches the subject matter underlined below:
. . . wherein the log and trigger configuration comprises a callback function, and wherein performing the associated action comprises calling the callback function (see Baker at least pg. 9, col. 7/8, lines 63-67/1-13 “. . . the accounting application 140 is configured to log each of the requests for operations and whether the request was serviced. Specifically, the accounting application 140 may account for a callback routine to log events . . .”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configurations and performing commands as associated actions of Chronowski with the log and trigger configuration comprising a callback function performing the associated action comprising calling the callback function as taught by Baker to have the log and trigger configuration comprise a callback function and have performing the associated action comprise calling the callback function. Doing so would provide a means for logging, as recognized by Baker (see Baker at least pg. 9, col. 7/8, lines 63-67/1-13 “. . . the accounting application 140 is configured to log each of the requests for operations and whether the request was serviced. Specifically, the accounting application 140 may account for a callback routine to log events . . .”).
Regarding claim 18, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above.
While Chronowski discloses log and trigger configurations and performing commands as associated actions (see Chronowski at least [0037] “The trigger conditions 208 may include information indicative of conditions that, when satisfied by the vehicle data 202, cause an alteration in the reporting settings 204 of the vehicle 31. The trigger conditions 208 may further include information indicative of how the reporting settings 204 should be modified based on satisfaction of the conditions. The telematics service provider 206 may be configured to maintain the trigger conditions 208, evaluate the received vehicle data 202 (or other acquired data regarding the vehicles 31) against the trigger conditions 208, and provide commands 210 to the vehicle 31 to cause the vehicle 31 to update its reporting settings 204 as specified by the trigger conditions 208.”), it does not appear to explicitly disclose the log and trigger configuration comprising a callback function and performing the associated action comprising calling the callback function.
Baker teaches the subject matter underlined below:
. . . wherein the log and trigger configuration comprises a callback function, and wherein the machine-executable programming instructions which configure the telematics device to perform the associated action comprise machine-executable programming instructions which configure the telematics device to call the callback function (see Baker at least pg. 9, col. 7/8, lines 63-67/1-13 “. . . the accounting application 140 is configured to log each of the requests for operations and whether the request was serviced. Specifically, the accounting application 140 may account for a callback routine to log events . . .”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configurations and performing commands as associated actions of Chronowski with the machine-executable programming instructions which configure the telematics device to perform the associated action comprising machine-executable programming instructions which configure the telematics device to call the callback function as taught by Baker to have the log and trigger configuration comprise a callback function and have the machine-executable programming instructions which configure the telematics device to perform the associated action comprise machine-executable programming instructions which configure the telematics device to call the callback function. Doing so would provide a means for logging, as recognized by Baker (see Baker at least pg. 9, col. 7/8, lines 63-67/1-13 “. . . the accounting application 140 is configured to log each of the requests for operations and whether the request was serviced. Specifically, the accounting application 140 may account for a callback routine to log events . . .”).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chronowski in view of Hopkins (Hopkins, J. (2020, July 21). About the CAN Protocol and How to Debug and Transmit CAN Communication. Total Phase.; hereinafter Hopkins).
Regarding claim 9, Chronowski discloses the subject matter of claim 1 as recited in the claim and applied above.
While Chronowski discloses a log and trigger configuration and performing an associated action comprising sending a message to an application via CAN BUS (see Chronowski at least [0052] “At block 406, the VCS 1 sends the collected vehicle data 202 to the telematics service provider 206. For example, the VCS 1 may provide the collected vehicle data 202 in one or more messages to the telematics service provider 206.”), it does not appear to explicitly disclose the log and trigger configuration comprising a message type, and performing the associated action comprising sending a message of the message type to an application.
Hopkins teaches CAN BUS communications requiring messages to be of specific types (see Hopkins at least pg. 3, paragraph 4 “There are four different message types, or frames, on a CAN bus: . . .”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configuration and performing an associated action comprising sending a message to an application via CAN BUS of Chronowski with the CAN BUS communications requiring messages to be of specific types as taught by Hopkins to have the log and trigger configuration comprise a message type, and wherein performing the associated action comprises sending a message of the message type to an application. Doing so would enable communications through the CAN BUS structure as described in Chronowski.
Regarding claim 19, Chronowski discloses the subject matter of claim 11 as recited in the claim and applied above.
While Chronowski discloses a log and trigger configuration and performing an associated action comprising sending a message to an application via CAN BUS (see Chronowski at least [0052] “At block 406, the VCS 1 sends the collected vehicle data 202 to the telematics service provider 206. For example, the VCS 1 may provide the collected vehicle data 202 in one or more messages to the telematics service provider 206.”), it does not appear to explicitly disclose the log and trigger configuration comprising a message type, and performing the associated action comprising sending a message of the message type to an application.
Hopkins teaches CAN BUS communications requiring messages to be of specific types (see Hopkins at least pg. 3, paragraph 4 “There are four different message types, or frames, on a CAN bus: . . .”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention with a reasonable expectation of success to have modified the log and trigger configuration and performing an associated action comprising sending a message to an application via CAN BUS of Chronowski with the CAN BUS communications requiring messages to be of specific types as taught by Hopkins to have the log and trigger configuration comprise a message type, and wherein the machine-executable programming instructions which configure the telematics device to perform the associated action comprise machine-executable programming instructions which configure the telematics device to send a message of the message type to an application. Doing so would enable communications through the CAN BUS structure as described in Chronowski.
Response to Arguments
Applicant's arguments filed 01/27/2026 have been fully considered but they are not persuasive.
(A) Applicant argues, “Without acquiescing to the above rejections, and solely to advance the prosecution of the application, the Applicant has amended the claims. Independent claims 1 and 11 are amended to clarify that the telematics device itself receives, via its network interface, ‘a log and trigger configuration comprising a unified data structure including a log identifier, a trigger condition, and an action indicator,’ before creating a trigger configuration, associating it with a log configuration, and performing the associated action. These limitations emphasize on-device receipt of a single composite configuration and the inclusion of both the condition and action indicator within that unified payload. Support appears at least in paragraph [0004] (‘receiving a log and trigger configuration’ as part of the device-side method) and in the specification passages describing that the application sends the log and trigger config to the on-device data trigger manager and that the data trigger manager receives the log and trigger config (e.g., ‘Turning back to Figure 9A, at step 904, the application 244 sends the log and trigger config 1040 to the data trigger manager 243 ... The data trigger manager 243 receives the log and trigger config 1040.’; ‘At step 1602, the data trigger manager 243 receives a log and trigger config ...’). Additional support for network delivery to, and device-side receipt of, an intermediate configuration is provided in the passages explaining that a remote log and trigger config 1400A is sent to the telematics server, which creates and sends an intermediate log and trigger config 1400B over the network to the telematics device, and that the on-device application receives 1400B and prepares the log and trigger config 1040. Further support for the unified structure fields, including the log identifier and the action indicator (callback function or message type), appears in the passages detailing the fields of the log and trigger config (e.g., log ID 1022, trigger condition 1004, callback function 1008/message type alternative).
“The amendments to independent claims 1 and 11 add explicit, affirmative limitations that the telematics device itself ‘receiv[es], via the network interface, a log and trigger configuration comprising a unified data structure including a log identifier, a trigger condition, and an action indicator.’ None of the cited references discloses or suggests these features. Chronowski does not teach the in-vehicle receipt of a single, composite ‘log and trigger configuration’ by the telematics device; instead, it describes server-side maintenance/evaluation with server-initiated commands. Ma concerns hardware AVL-tree management and is silent on any telematics configuration receipt. Giannella addresses dynamic allocation of signal processing and discusses ‘event data’ outputs, not a unified device-received configuration with the recited fields. Baker relates to secured operation verification and ‘callback’ accounting, not receipt of a composite telematics configuration. Hopkins addresses CAN message frame types, not receipt of a unified configuration payload by the device.
“Because the cited art lacks the amended features of device-side receipt via the network interface of a unified ‘log and trigger configuration’ that includes a log identifier, a trigger condition, and an action indicator, the anticipation and obviousness rejections predicated on those references cannot be sustained. Withdrawal of the rejections is respectfully requested.”
As to Point (A), the examiner respectfully disagrees. Applicant appears to argue that none of the prior art of record disclose or otherwise suggest “receiving, via the network interface, a log and trigger configuration comprising a unified data structure including a log identifier, a trigger condition, and an action indicator.” Specifically, Applicant asserts that Chronowski does not disclose the in-vehicle receipt of a single, composite ‘log and trigger configuration’ by the telematics device. While not explicit, Chronowski does disclose the use of a CAN bus structure for network communications with other system components. CAN communications, in order to function, require a specific message structure- a CAN frame. CAN frames are structured such that an arbitration field- an identifying string of bits- is provided at the start of the message. This serves as a log identifier that is unified with the command issued in Chronowski, which expressly includes both a trigger condition and an action indicator. As such, messages transmitted via the CAN network interface to the telematics device are unified data structures with all three aspects present. Please see the mapping of the 103 rejections of claims 1 and 11 above for further clarification.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 TABITHA KRESS whose telephone number is (703) 756-1763. The examiner can normally be reached MTWR 06:30-16:30 CST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hitesh Patel can be reached at (571) 270-5442. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TABITHA KRESS/ Examiner, Art Unit 3667
/Hitesh Patel/Supervisory Patent Examiner, Art Unit 3667
7/24/26
Prosecution Insights