DETAILED ACTION
This communication is a Non-Final Office Action on the Merits. Claims 1-20 as originally filed are pending and have been considered as follows.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 103
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.
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, 4-5, 8, 11-12, 15, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Brewer (US Pub. No. 2017/0039356) in view of Takada (US Pub. No. 2017/0149562).
As per Claim 1, Brewer discloses a method (100, 300) (Figs. 1-3; ¶12, 23, 28), comprising:
in response to an initiation of a security check process (204; 300) of a transport (106), gathering a first software item (310) and gathering a second software item (312) (Figs. 1-3; ¶9, 12, 23-25, 28-35, 45);
determining the gathered first software item (310) fails a first security check (as per NO at 310) of the security check process (204; 300) and determining the gathered second software item (312) fails a second security check (as per NO at 312) of the security check process (204; 300) (Figs. 1-3; ¶12, 23-25, 28-35); and
in response to determining that the gathered first software item (310) fails the first security check (as per NO at 310) and the gathered second software item (312) fails the second security check (as per NO at 312):
inhibiting the transport (106) from moving (208) (Figs. 1-3; ¶12, 23-27, 28-36); and
sending a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party, a computer, a computing device…” in ¶27) of the security check failures (as per NO at 310; as per NO at 312) of the gathered first software item (310) and the gathered second software item (312) to a server (104) (Figs. 1-3; ¶12, 23-27, 28-36).
Brewer does not expressly disclose wherein gathering the first and second software items involves hashing.
Takada discloses a vehicle (1) that includes a plurality of electronic control units (3) each of which are in communication with a monitoring device (5) (Fig. 1; ¶51, 110). Each ECU (3) includes a processing unit (31) that calculates a hash value at a hash value calculation unit (41) and the monitoring device (5) includes a processing unit (51) that calculates a hash value at a hash value calculation unit (61) (Figs. 2, 4; ¶52, 56, 59, 62). In operation, the monitoring device (5) performs functions including transmitting to each ECU (3) a hash confirmation instruction (S5), determining whether the hash confirmation response has been received (S6), and determining whether received response information is valid (S8) (Fig. 9; ¶93-97). In response to a determination that the hash confirmation has not been received (NO at S6) or in response to a determination that the response information is not valid (NO at S8), the monitoring device (5) performs suitable error processing (S9) (¶96). In this way, the monitoring unit (5) detects and responds to falsification of each ECU (3) (¶51, 64-66, 93, 105-108). Like Brewer, Takada is concerned with vehicle control systems.
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates “wherein gathering the first and second software items involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada.
As per Claim 4, the combination of Brewer and Takada teaches or suggests all limitations of Claim 1. Brewer further discloses:
comparing (as per step 310) the gathered first software item (310) to a stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Figs. 2-3; ¶25, 28-34);
determining the first software item (310) is not identical (as per NO at step 310) to the stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Fig. 3; ¶28-34); and
providing a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party” in ¶27) to the server (as per “third party, a computer, a computing device, or stored in a repository” in ¶27).
Brewer does not expressly disclose:
wherein gathering the first software item involves hashing;
wherein the stored data is a stored hash of data; and
wherein the notification is that the first software item of the transport may have been hacked.
See rejection of Claim 1 for discussion of teachings of Takada. Takada further discloses an embodiment in which illegal falsification to programs and data involves illegal data transmission to the in-vehicle network (¶51).
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates:
“wherein gathering the first software item involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada;
“wherein the stored data is a stored hash of data” in that the comparison process as per Brewer would be adapted to detect and respond to falsification as per the system of Takada; and
“wherein the notification is that the first software item of the transport may have been hacked” in that the reporting as per Brewer would be adapted to detect and respond to embodiments of falsification involving illegal data transmission as per the system of Takada.
As per Claim 5, the combination of Brewer and Takada teaches or suggests all limitations of Claim 1. Brewer further discloses wherein the first software item (310) and the second software item (312) are received by a processor (as per “server 104 includes authorization program 110” in ¶14, “In decision 310, authorization program 110 determines” in ¶34, per “In decision 312, authorization program 110 determines” in ¶35, and “computer processors 404 of server 104” in ¶42), and wherein the first software item (310) and the second software item (312) are each associated with and correspond to the transport (as per “The combination is the credentials which are used to verify vehicle 106 and the driver to determine if vehicle 106 is safe to operate and the driver is verified to operate vehicle 106” in ¶34; as per “The override code may be, for example, a code, a device, or a verification from a third party to allow the driver which was not approved to operate vehicle 106” in ¶35).
As per Claim 8, Brewer discloses a system (100) (Fig. 1; ¶12), comprising:
a processor (404) that, when executing instructions (as per “program instructions” in ¶14, 42) stored in an associated memory (406, 408) (Figs. 1, 4; ¶12-14, 39-42), is configured to:
in response to an initiation of a security check process (204; 300), gather a first software item (310) and gather a second software item (312) (Figs. 1-3; ¶9, 12, 23-25, 28-35, 45);
determine the gathered first software item (310) fails a first security check (as per NO at 310) of the security check process (204; 300) and determine the gathered second software item (312) fails a second security check (as per NO at 312) of the security check process (204; 300) (Figs. 1-3; ¶12, 23-25, 28-35); and
in response to the determination that the gathered first software item (310) fails the first security check (as per NO at 310) and the gathered second software item (312) fails the second security check (as per NO at 312):
inhibit the transport (106) from being able to move (208) (Figs. 1-3; ¶12, 23-27, 28-36); and
send a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party, a computer, a computing device…” in ¶27) of the security check failures (as per NO at 310; as per NO at 312) of the gathered first software item (310) and the gathered second software item (312) to a server (104) (Figs. 1-3; ¶12, 23-27, 28-36).
Takada does not expressly disclose:
wherein the processor is of a transport; and
wherein gathering the first and second software items involves hashing.
See rejection of Claim 1 for discussion of teachings of Takada. Takada further discloses an embodiment in which the monitoring device (5) is connected to the ECUs (3) via a common communication line on the vehicle (1) (Fig. 1; 51) and an embodiment in which the monitoring device (5) and an embodiment in which the monitoring device (5) communicates with the ECUs (3) wirelessly and functions with a server (¶110).
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates:
“wherein the processor is of a transport” in that the authorization program (110) operating within the server (104) as per Brewer would be adapted for local operation within a suitable processor of the vehicle (106) in view of teachings of Takada in which the location of a monitoring program within a vehicle or remotely is a matter of design choice; and
“wherein gathering the first and second software items involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada.
As per Claim 11, the combination of Brewer and Takada teaches or suggests all limitations of Claim 8. Brewer further discloses wherein the processor (404) is further configured to:
compare (as per step 310) the gathered first software item (310) to a stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Figs. 2-3; ¶25, 28-34);
determine that the gathered first software item (310) is not identical (as per NO at step 310) to the stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Fig. 3; ¶28-34); and
provide a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party” in ¶27) to the server (as per “third party, a computer, a computing device, or stored in a repository” in ¶27).
Brewer does not expressly disclose:
wherein gathering the first software item involves hashing;
wherein the stored data is a stored hash of data; and
wherein the notification is that the first software item of the transport may have been hacked.
See rejection of Claim 1 for discussion of teachings of Takada. Takada further discloses an embodiment in which illegal falsification to programs and data involves illegal data transmission to the in-vehicle network (¶51).
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates:
“wherein gathering the first software item involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada;
“wherein the stored data is a stored hash of data” in that the comparison process as per Brewer would be adapted to detect and respond to falsification as per the system of Takada; and
“wherein the notification is that the first software item of the transport may have been hacked” in that the reporting as per Brewer would be adapted to detect and respond to embodiments of falsification involving illegal data transmission as per the system of Takada.
As per Claim 12, the combination of Brewer and Takada teaches or suggests all limitations of Claim 8. Brewer further discloses wherein the first software item (310) and the second software item (312) are received by the processor (as per “server 104 includes authorization program 110” in ¶14, “In decision 310, authorization program 110 determines” in ¶34, per “In decision 312, authorization program 110 determines” in ¶35, and “computer processors 404 of server 104” in ¶42), wherein the first software item (310) and the second software item (312) are each associated with and correspond to the transport (per “The combination is the credentials which are used to verify vehicle 106 and the driver to determine if vehicle 106 is safe to operate and the driver is verified to operate vehicle 106” in ¶34; as per “The override code may be, for example, a code, a device, or a verification from a third party to allow the driver which was not approved to operate vehicle 106” in ¶35).
As per Claim 15, Brewer discloses a non-transitory computer-readable medium (406, 408) comprising instructions (as per “program instructions” in ¶14, 42) that, when executed by a processor (404) associated with a transport (106) (Figs. 1, 4; ¶12-14, 39-42), cause the processor (404) to perform:
in response to an initiation of a security check process (204; 300) of the transport (106), gathering a first software item (310) and gathering a second software item (312) (Figs. 1-3; ¶9, 12, 23-25, 28-35, 45);
determining the gathered first software item (310) fails a first security check (as per NO at 310) of the security check process (204; 300) and determining the gathered second software item (312) fails a second security check (as per NO at 312) of the security check process (204; 300) (Figs. 1-3; ¶12, 23-25, 28-35); and
in response to determining that the gathered first software item (310) fails the first security check (as per NO at 310) and the gathered second software item (312) fails the second security check (as per NO at 312):
inhibiting the transport (106) from moving (208) (Figs. 1-3; ¶12, 23-27, 28-36); and
sending a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party, a computer, a computing device…” in ¶27) of the security check failures (as per NO at 310; as per NO at 312) of the gathered first software item (310) and the gathered second software item (312) to a server (104) (Figs. 1-3; ¶12, 23-27, 28-36).
Brewer does not expressly disclose wherein gathering the first and second software items involves hashing.
See rejection of Claim 1 for discussion of teachings of Takada.
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates “wherein gathering the first and second software items involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada.
As per Claim 18, the combination of Brewer and Takada teaches or suggests all limitations of Claim 15. Brewer further discloses wherein the instructions (as per “program instructions” in ¶14, 42) further cause the processor (404) to perform:
comparing (as per step 310) the gathered first software item (310) to a stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Figs. 2-3; ¶25, 28-34);
determining the first software item (310) is not identical (as per NO at step 310) to the stored data (as per “authorization program 110 compares the credentials to various databases to determine whether the received credentials are valid” in ¶25) (Fig. 3; ¶28-34); and
providing a notification (as per “program 113 reports the information relating to denying vehicle 106 the ability to start to a third party” in ¶27) to the server (as per “third party, a computer, a computing device, or stored in a repository” in ¶27).
Brewer does not expressly disclose:
wherein gathering the first software item involves hashing;
wherein the stored data is a stored hash of data; and
wherein the notification is that the first software item of the transport may have been hacked.
See rejection of Claim 1 for discussion of teachings of Takada. Takada further discloses an embodiment in which illegal falsification to programs and data involves illegal data transmission to the in-vehicle network (¶51).
Therefore, from these teachings of Brewer and Takada, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada to the system of Brewer since doing so would enhance the system by adapting the system to detect and respond to falsification. Applying the teachings of Takada to the system of Brewer would result in a system that operates:
“wherein gathering the first software item involves hashing” in that the server (104) of Brewer would be adapted to detect and respond to falsification as per the system of Takada;
“wherein the stored data is a stored hash of data” in that the comparison process as per Brewer would be adapted to detect and respond to falsification as per the system of Takada; and
“wherein the notification is that the first software item of the transport may have been hacked” in that the reporting as per Brewer would be adapted to detect and respond to embodiments of falsification involving illegal data transmission as per the system of Takada.
As per Claim 19, the combination of Brewer and Takada teaches or suggests all limitations of Claim 15. Brewer further discloses wherein the first software item (310) and the second software item (310) are received by the processor (as per “server 104 includes authorization program 110” in ¶14, “In decision 310, authorization program 110 determines” in ¶34, per “In decision 312, authorization program 110 determines” in ¶35, and “computer processors 404 of server 104” in ¶42), wherein the first software item (310) and the second software item (312) are each associated with and correspond to the transport (per “The combination is the credentials which are used to verify vehicle 106 and the driver to determine if vehicle 106 is safe to operate and the driver is verified to operate vehicle 106” in ¶34; as per “The override code may be, for example, a code, a device, or a verification from a third party to allow the driver which was not approved to operate vehicle 106” in ¶35).
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Brewer (US Pub. No. 2017/0039356) in view of Takada (US Pub. No. 2017/0149562), further in view of Ibrahim (US Pub. No. 2019/0378220).
As per Claim 2, the combination of Brewer and Takada teaches or suggests all limitations of Claim 1. Brewer does not expressly disclose quarantining the first software item and the second software item, wherein the quarantining comprises setting a flag in a data store that designates a quarantined status of the first software item.
See rejection of Claim 1 for discussion of teachings of Takada.
Ibrahim discloses a vehicle data system in which a vehicle (110) communicates over a network (170) (Figs. 1-2; ¶17, 19). The vehicle (110) includes a module (230) that operates to store and maintain data regarding versions of software running on the vehicle (110) (Fig. 2; ¶19, 26). The system operates to isolate and remove malicious code from messages sent to the vehicle (110) in order to prevent a computer or network from being compromised (¶111). The system further includes a file parsing routine that performs the following operations: scan the communication for the identified beginning malicious code marker; flag each scanned byte between the beginning marker and the successive end malicious code marker; continue scanning until no further beginning malicious code marker is found; and create a new data file by sequentially copying all non-flagged data bytes into a new file which forms a sanitized file (¶111). The new file forms a sanitized communication file which is transferred to a non-quarantine sector of the computer memory (¶111). In this way, the system physically isolates a received electronic communication in a quarantine sector of memory (¶111). Like Brewer, Ibrahim is concerned with vehicle data systems.
Therefore, from these teachings of Brewer, Takada, and Ibrahim, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Ibrahim to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and preventing the system from being compromised. Applying the teachings of Takada and Ibrahim to the system of Brewer would result in a system that operates by “quarantining the first software item and the second software item, wherein the quarantining comprises setting a flag in a data store that designates a quarantined status of the first software item” in that the system of Brewer would for received software items that cause errors flag and quarantine such items as per Ibraham.
As per Claim 9, the combination of Brewer and Takada teaches or suggests all limitations of Claim 8. Brewer does not expressly disclose wherein the processor is configured to quarantine the first software item and set a flag in a data store that designates a quarantined status of the first software item.
See rejection of Claim 1 for discussion of teachings of Takada.
See rejection of Claim 2 for discussion of teachings of Ibrahim.
Therefore, from these teachings of Brewer, Takada, and Ibrahim, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Ibrahim to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and preventing the system from being compromised. Applying the teachings of Takada and Ibrahim to the system of Brewer would result in a system that operates by “wherein the processor is configured to quarantine the first software item and set a flag in a data store that designates a quarantined status of the first software item” in that the system of Brewer would for received software items that cause errors flag and quarantine such items as per Ibraham.
As per Claim 16, the combination of Brewer and Takada teaches or suggests all limitations of Claim 15. Brewer does not expressly disclose wherein the processor is further configured to perform quarantining the first software item, wherein the quarantining comprises setting a flag in a data store that designates a quarantined status of the first software item.
See rejection of Claim 1 for discussion of teachings of Takada.
See rejection of Claim 2 for discussion of teachings of Ibrahim.
Therefore, from these teachings of Brewer, Takada, and Ibrahim, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Ibrahim to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and preventing the system from being compromised. Applying the teachings of Takada and Ibrahim to the system of Brewer would result in a system that operates by “wherein the processor is further configured to perform quarantining the first software item, wherein the quarantining comprises setting a flag in a data store that designates a quarantined status of the first software item” in that the system of Brewer would for received software items that cause errors flag and quarantine such items as per Ibraham.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Brewer (US Pub. No. 2017/0039356) in view of Takada (US Pub. No. 2017/0149562), further in view of Zymeri (US Pub. No. 2017/0123784).
As per Claim 3, the combination of Brewer and Takada teaches or suggests all limitations of Claim 1. Brewer does not expressly disclose requesting a previous version of the first software item from the server.
Zymeri discloses a vehicle (10) that communicates with a backend (20) comprising servers (21, 22, 23, 24, 26), the vehicle (10) including update clients (12, 13) for updating software on the vehicle (10) with information from the backend (20) (Fig. 1; ¶19-25). In operation, the software update clients (12, 13) are capable of carrying out the actual update and determining errors in their functioning (¶60). In the case of errors that cannot be solved, countermeasures may be employed (¶60). The countermeasures include an update availability abort trigger through the backend (20) that operates to interrupt and undo updates that are running or have already been carried out by causing rollback actions (¶90). As such, a previous version (as per “rollback” in ¶42, 59-60, 90) of the software item (as per update clients 12, 13) is implemented through the backend (20) (Figs. 1, 3; ¶19-42, 59-60, 76, 90). In this way, the system provides an appropriate response to failure of the update process (¶83). Like Brewer, Zymeri is concerned with vehicle control systems.
Therefore, from these teachings of Brewer, Takada, and Zymeri, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Zymeri to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and providing an appropriate response to failure of the update process. Applying the teachings of Takada and Zymeri to the system of Brewer would result in a system that operates by “requesting a previous version of the first software item from the server” in that the system of Brewer would be adapted to provide software updates and respond to errors with the update process as per Zymeri.
As per Claim 10, the combination of Brewer and Takada teaches or suggests all limitations of Claim 8. Brewer does not expressly disclose wherein the processor is further configured to request a previous version of the first software item from the server.
See rejection of Claim 1 for discussion of teachings of Takada.
See rejection of Claim 3 for discussion of teachings of Zymeri.
Therefore, from these teachings of Brewer, Takada, and Zymeri, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Zymeri to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and providing an appropriate response to failure of the update process. Applying the teachings of Takada and Zymeri to the system of Brewer would result in a system that operates “wherein the processor is further configured to request a previous version of the first software item from the server” in that the system of Brewer would be adapted to provide software updates and respond to errors with the update process as per Zymeri.
As per Claim 17, the combination of Brewer and Takada teaches or suggests all limitations of Claim 15. Brewer does not expressly disclose wherein the requesting a previous version of the first software item from the server.
See rejection of Claim 1 for discussion of teachings of Takada.
See rejection of Claim 3 for discussion of teachings of Zymeri.
Therefore, from these teachings of Brewer, Takada, and Zymeri, one of ordinary skill in the art before the effective filing date would have found it obvious to apply the teachings of Takada and Zymeri to the system of Brewer since doing so would enhance the system by: adapting the system to detect and respond to falsification; and providing an appropriate response to failure of the update process. Applying the teachings of Takada and Zymeri to the system of Brewer would result in a system that operates “wherein the requesting a previous version of the first software item from the server” in that the system of Brewer would be adapted to provide software updates and respond to errors with the update process as per Zymeri.
Allowable Subject Matter
Claims 6-7, 13-14, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Saito (US Pub. No. 2002/0044049), Huang (US Pub. No. 2016/0075193), and Dominick (US Pub. No. 2017/0017927) disclose vehicle data systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN HOLWERDA whose telephone number is (571)270-5747. The examiner can normally be reached M-F 8am - 4:30pm.
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, KHOI TRAN can be reached at (571) 272-6919. 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.
/STEPHEN HOLWERDA/Primary Examiner, Art Unit 3656
Prosecution Insights