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 .
Status of Claims
Claims 1-20 of US Application No. 19/065,220 are currently pending and have been examined. Applicant amended claims 1, 10-12, and 19
Information Disclosure Statement
The Information Disclosure Statement filed on 08 September 2026 has been considered. An initialed copy of form 1449 is enclosed herewith.
Response to Arguments/Amendments
Applicant’s arguments regarding the rejections of claims 1-20 under 35 U.S.C. 101, see REMARKS, filed 08 September 2026, have been fully considered but are not persuasive. Applicant first states, in the REMARKS at page 6:
In the Office Action, it is asserted that the claims are directed to concepts falling within the mental process or step grouping of abstract ideas. Particularly, it is contended that the claim is directed to an abstract idea as the claims recite "detect" and "determine," which are interpreted as observations and/or evaluations performed in the human mind. It is submitted that the claims relate to automated process of indicating a link between a fault in a first component of a machine, leading to the setting of a diagnostic trouble code by the first component, and related diagnostic information for a second component, which did not transmit the diagnostic trouble code. Accordingly, the claimed subject matter is inextricably tied to a machine having interrelated components.
The Examiner infers, from Applicant’s statement, that Applicant asserts that the claims are not directed to a mental process. Applicant’s reasoning, however, is not clear to the Examiner. The Examiner has previously identified receive a diagnostic trouble code and determine a relationship to a second component as limitations that may be performed mentally. Applicant has not directly indicated any reason why these limitations may not be practically performed in the human mind or with the aid of pen and paper. Applicant alludes to the claim relating to an automated process. However, the automated process appears to simply be executing functions on a processor, i.e., using a computer. With respect to mental processes, the courts do not distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer. The claimed system including a processor to receive a diagnostic trouble code and determine a relationship to a second component is merely performing the identified mental process on a computer, which does not remove the identified mental processes from the abstract ideas groupings.
Applicant then states, in the REMARKS at page 6:
Further, even if the claims were directed to a mental process, which the Applicant does not concede, the claims clearly integrate this concept into a practical application. As described in the specification, diagnosing communications between components is very difficult. For example, a fault set in one component may not be caused by a fault in that component but rather caused by a fault of another component. The claims provide a technical solution where faults associated with intercommunication between components are clearly identified to improve diagnostics.
Applicant argues that the claims integrate the abstract ideas identified by the Examiner into a practical application. In STEP 2A (prong 2) of the § 101 analysis, even when a judicial element is recited in the claim, an additional claim element(s) that integrates the judicial exception into a practical application of that exception renders the claim eligible under §101. The guidelines provide the following exemplary considerations that are indicative that an additional element (or combination of elements) may have integrated the judicial exception into a practical application:
an additional element reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field;
an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition;
an additional element implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim;
an additional element effects a transformation or reduction of a particular article to a different state or thing; and
an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
While the guidelines further state that the exemplary considerations are not an exhaustive list and that there may be other examples of integrating the exception into a practical application, the guidelines also list examples in which a judicial exception has not been integrated into a practical application:
an additional element merely recites the words “apply it” (or an equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea;
an additional element adds insignificant extra-solution activity to the judicial exception; and
an additional element does no more than generally link the use of a judicial exception to a particular technological environment or field of use.
Applicant has not identified any additional elements in the claim that, either alone or in combination, integrates the judicial exceptions into a practical application. The only additional element identified by the Examiner is display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component. As indicated in the step 2A, PRONG 2 analysis, this additional element is extra-solution activity, which is not sufficient to integrate the judicial exceptions into a practical application.
Accordingly, Applicant’s arguments are not persuasive. The previous rejections of claims 1-20 under § 101 are maintained.
The previous rejections of claims 1-20 under 35 U.S.C. 103 are withdrawn in consideration of amended independent claims 1, 12, and 19. However, new rejections of claims 1-20 under § 103 are set forth below.
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.
Analysis of claim 1:
STEP 1: Does claim 1 fall within one of the statutory categories? Yes. The claim is directed toward a system (machine) which falls within one of the statutory categories.
STEP 2A (PRONG 1): Is the claim directed to a law of nature, a natural phenomenon or an abstract idea? Yes, the claim is directed to an abstract idea.
Claim 1. A system, comprising:
at least one processor being configured to:
receive a diagnostic trouble code from a first component, having a first controller, of a machine;
determine a relationship to a second component, having a second controller, of the machine based on the diagnostic trouble code; and
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component.
The limitations highlighted in claim 1 above is a mental process that can be practicably performed in the human mind and, therefore, an abstract idea. The limitations of claim 1 highlighted above merely consist of a receiving a diagnostic code and determining a relationship between two components of a vehicle. This is equivalent to a person reading the diagnostic code associated with an error of a first component and knowing a relationship between a first and second component and understanding that a specific error with a first component is often associated with a different error in another component. Thus, the claim recites a mental process.
STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application? No, the claim does not recite additional elements that integrate the judicial exception into a practical application.
Claim 1. A system, comprising:
at least one processor being configured to:
receive a diagnostic trouble code from a component, having a first controller, of a machine;
determine a relationship to a second component, having a second controller, of the machine based on the diagnostic trouble code; and
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component.
Claim 1 does not recite any of the exemplary considerations that are indicative of an abstract idea having been integrated into a practical application. The display step is recited at a high level of generality (i.e. as a general means of displaying a link to known diagnostic information of a (second) vehicle component) and amounts to mere post solution actions, which is a form of insignificant extra solution activity. Still further, the system and processor are mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea which is indicative that the judicial exception has not been integrated into a practical application. As such, claim 1 is not integrated into practical application.
STEP 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? No, the claim does not recite additional elements that amount to significantly more than the judicial exception.
As explained with respect to Step 2A Prong Two, there are two additional elements. The first is the display a notification step, which is presumably performed using some form of display. These elements are generic and conventional components in the art. As explained previously, the display step is mere post solution actions, and the display of a notification using a conventional display is merely well understood, routine and conventional activity for device displays. MPEP 2106.05(d) The second additional element is use of a processor. These elements are generic and conventional components in the art. The use of a processor to connect and retrieve information is well-understood, routine and conventional activity for computer processors.
CONCLUSION
Thus, since claim 1 is: (a) directed toward an abstract idea, (b) does not recite additional elements that integrate the judicial exception into a practical application, and (c) does not recite additional elements that amount to significantly more than the judicial exception, it is clear that claim 1 is directed towards non-statutory subject matter.
Analysis of claim 12:
Claim 12 is commensurate in scope to claim 1, with claim 1 being drawn to a system and claim 12 being drawn to a corresponding method. As such, claim 12 is rejected using a similar analysis as applied to claim 1 above.
Analysis of claim 19:
STEP 1: Does claim 19 fall within one of the statutory categories? Yes. The claim is directed toward a system (machine) which falls within one of the statutory categories.
STEP 2A (PRONG 1): Is the claim directed to a law of nature, a natural phenomenon or an abstract idea? Yes, the claim is directed to an abstract idea.
Claim 19. A system, comprising:
a machine having at least a first component and a second component having a first controller and a second controller respectively, and at least the first controller of the first component being configured to:
detect a fault in the first component;
set a diagnostic trouble code corresponding to the fault detected; and
transmit the diagnostic trouble code; and
a receiver configured to:
receive the diagnostic trouble code from at least the first component;
retrieve definition information associated with the diagnostic trouble code;
determine, based on the definition information, a relationship to the second component of the machine;
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component; and
when the link is selected via operator input:
retrieve the diagnostic information associated with the second component; and
display the diagnostic information retrieved.
The limitations highlighted in claim 19 above is a mental process that can be practicably performed in the human mind and, therefore, an abstract idea. The limitations of claim 1 highlighted above merely consist of a receiving a diagnostic code and determining a relationship between two components of a vehicle. This is equivalent to a person reading the diagnostic code associated with an error of a first component and knowing a relationship between a first and second component and understanding that a specific error with a first component is often associated with a different error in another component. Thus, the claim recites a mental process.
STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application? No, the claim does not recite additional elements that integrate the judicial exception into a practical application.
Claim 19. A system, comprising:
a machine having at least a first component and a second component having a first controller and a second controller respectively, and at least the first controller of the first component being configured to:
detect a fault in the first component;
set a diagnostic trouble code corresponding to the fault detected; and
transmit the diagnostic trouble code; and
a receiver configured to:
receive the diagnostic trouble code from at least the first component;
retrieve definition information associated with the diagnostic trouble code;
determine, based on the definition information, a relationship to the second component of the machine;
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component; and
when the link is selected via operator input:
retrieve the diagnostic information associated with the second component; and
display the diagnostic information retrieved.
Claim 19 does not recite any of the exemplary considerations that are indicative of an abstract idea having been integrated into a practical application. The steps of detect a fault, set a diagnostic trouble code and transit the code amount to mere data gathering which is a form of insignificant extra solution activity. The steps of display a notification, retrieve the diagnostic information (after selected) and display the retrieved diagnostic information are recited at a high level of generality (i.e. as a general means of displaying a link to known diagnostic information of a (second) vehicle component and displaying the retrieved information when the link is selected) and amounts to mere post solution actions, which is a form of insignificant extra solution activity. Still further, the system, machine, controller and receiver are mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea which is indicative that the judicial exception has not been integrated into a practical application. As such, claim 19 is not integrated into practical application.
STEP 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? No, the claim does not recite additional elements that amount to significantly more than the judicial exception.
As explained with respect to Step 2A Prong Two, there are two additional elements. The first is the display a notification step, which is presumably performed using some form of display. These elements are generic and conventional components in the art. As explained previously, the display step is mere post solution actions, and the display of a notification using a conventional display is merely well understood, routine and conventional activity for device displays. MPEP 2106.05(d) The second additional element is use of a processor, controller and receiver on a machine. These elements are generic and conventional components in the art. The use of a controller and processor on a machine to connect and retrieve information is well-understood, routine and conventional activity for computers.
CONCLUSION
Thus, since claim 19 is: (a) directed toward an abstract idea, (b) does not recite additional elements that integrate the judicial exception into a practical application, and (c) does not recite additional elements that amount to significantly more than the judicial exception, it is clear that claim 19 is directed towards non-statutory subject matter.
Analysis of claims 2-11, 13-18 and 20:
Dependent claims 2-11, 13-18 and 20 further limit the abstract idea without integrating the abstract idea into practical application or adding significantly more. Rather, the limitations of dependent claims 2-11, 13-18 and 20 include limitations that are directed toward additional aspects of the judicial exceptions and/or are well-understood, routine and conventional additional elements that do not integrate the abstract idea into practical application.
As such, claims 1-20 are rejected under 35 USC 101 as being drawn to an abstract idea without significantly more, and thus are ineligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4, 5, 7, 9-13, and 16-20 are rejected under 35 U.S.C. 102(a)(a) as being anticipated by Kawahara et al. (US 2021/0375077 A1, “Kawahara”).
Regarding claim 1, Kawahara discloses a fault diagnosis device and teaches:
at least one processor being configured to:
receive a diagnostic trouble code from a first component, having a first controller, of a machine (computation unit 64 of data collection device 60 communicates with each of ECUs 82 of vehicle 80 and collects DTCs recorded in respective ECUs 82 – see at least Fig. 1 and ¶ [0028]; e.g., engine having ECUa = first component – see at least Fig. 1);
determine a relationship to a second component, having a second controller, of the machine based on the diagnostic trouble code (e.g., brake having ECU 82b = second component; at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]; e.g., system 1 includes DTCs from a plurality of systems, such as ABEI – see at least Figs. 5, 6 and ¶ [0057]); and
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component (at S5, display unit displays a true DTC identified in S3 at S14 – see at least Figs. 7, 8 and ¶ [0050]; displays a button on the screen for calling an operation manual corresponding to the DTC and associated with a URL – see at least Fig. 7 and ¶ [0050]).
Regarding claim 2, Kawahara further teaches:
wherein the at least one processor is further configured to:
retrieve definition information associated with the diagnostic trouble code (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]); and
determine, based on the definition information, the relationship to the second component of the machine (at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]).
Regarding claim 4, Kawahara further teaches:
wherein the definition information indicates a connection between the diagnostic trouble code and the second component (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]; e.g., DTC combination A, B, E, I is connected as system 1), and wherein the at least one processor is configured to determine the relationship based on the connection indicated in the definition information (at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]).
Regarding claim 5, Kawahara further teaches:
wherein the definition information is generated at development time (system information 34 of system table 30 system table stored in storage unit 16 – see at least Fig. 6 and ¶ [0054]).
Regarding claim 7, Kawahara further teaches:
wherein the at least one processor is further configured to:
receive operator input indicative of a selection of the link (at S6, determination of whether or not the button on the screen has been operated – see at least Fig. 7 and ¶ [0051]); and
retrieve diagnostic information related to the second component in response to the operator input (if S6 = YES, the repair manual corresponding to URL for the DTC is downloaded and displayed on the screen at S7 – see at least Figs. 7 and ¶ [0052]).
Regarding claim 9, Kawahara further teaches:
wherein the at least one processor is incorporated in a computing device separate from the machine (data collection device 60 – see at least Fig. 1 and ¶ [0025]).
Regarding claim 10, Kawahara further teaches:
wherein the first controller being configured to:
detect a fault in the first component (ECUs 82 record DTCs when failures occur – see at least ¶ [0028]);
set a diagnostic trouble code corresponding to the fault detected (DTCs recorded in respective ECUs 82 – see at least ¶ [0028]); and
transmit the diagnostic trouble code to the at least one processor (computation unit 64 of data collection device 60 communicates with each of ECUs 82 of vehicle 80 and collects DTCs recorded in respective ECUs 82 – see at least Fig. 1 and ¶ [0028]).
Regarding claim 11, Kawahara further teaches:
wherein the fault in the component may be based on a dependency to the second component (when a single failure occurs, the plurality of ECUs 82 may terminate the controls in a chained manner and fall into a failure state. Such a failure is referred to as a chain failure. When a chain failure occurs, each of the ECUs 82 records a DTC, respectively – see at least ¶ [0039]).
Regarding claim 12, Kawahara discloses a fault diagnosis device and teaches:
acquiring a diagnostic trouble code transmitted by a first component, having a first controller, of a machine (computation unit 64 of data collection device 60 communicates with each of ECUs 82 of vehicle 80 and collects DTCs recorded in respective ECUs 82 – see at least Fig. 1 and ¶ [0028]; e.g., engine having ECUa = first component – see at least Fig. 1);
retrieving definition information associated with the diagnostic trouble code (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]);
identifying a link between the diagnostic trouble code from the first component and a second component, having a second controller, of the machine (e.g., brake having ECU 82b = second component; at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]; e.g., system 1 includes DTCs from a plurality of systems, such as ABEI – see at least Figs. 5, 6 and ¶ [0057]); and
displaying a notification of the diagnostic trouble code from the first component, wherein the notification includes a navigation feature to diagnostic information of the second component (at S5, display unit displays a true DTC identified in S3 at S14 – see at least Figs. 7, 8 and ¶ [0050]; displays a button on the screen for calling an operation manual corresponding to the DTC and associated with a URL – see at least Fig. 7 and ¶ [0050]).
Regarding claim 13, Kawahara further teaches:
receiving a user input indicative of a selection of the navigation feature (at S6, determination of whether or not the button on the screen has been operated – see at least Fig. 7 and ¶ [0051]); and
retrieving the diagnostic information of the second component (if S6 = YES, the repair manual corresponding to URL for the DTC is downloaded and displayed on the screen at S7 – see at least Figs. 7 and ¶ [0052]).
Regarding claim 16, Kawahara further teaches:
wherein the definition information indicates a relationship between the diagnostic trouble code and the second component (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]; e.g., DTC combination A, B, E, I is connected as system 1).
Regarding claim 17, Kawahara further teaches:
wherein identifying the link to the second component includes identifying the relationship indicated in the definition information for the diagnostic trouble code (at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]).
Regarding claim 18, Kawahara further teaches:
wherein the definition information is generated at development time of firmware of the first component (system information 34 of system table 30 system table stored in storage unit 16 – see at least Fig. 6 and ¶ [0054]).
Regarding claim 19, Kawahara discloses a fault diagnosis device and teaches:
a machine having at least a first component and a second component having a first controller and a second controller respectively, and at least the first controller of the first component being configured to (engine, brake, steering – see at least Fig. 1; ECUs 82a-c – see at least Fig. 1):
detect a fault in the first component (ECUs 82 record DTCs when failures occur – see at least ¶ [0028]);
set a diagnostic trouble code corresponding to the fault detected (DTCs recorded in respective ECUs 82 – see at least ¶ [0028]); and
transmit the diagnostic trouble code (computation unit 64 of data collection device 60 communicates with each of ECUs 82 of vehicle 80 and collects DTCs recorded in respective ECUs 82 – see at least Fig. 1 and ¶ [0028]); and
a receiver configured to:
receive the diagnostic trouble code from at least the first component (computation unit 64 of data collection device 60 communicates with each of ECUs 82 of vehicle 80 and collects DTCs recorded in respective ECUs 82 – see at least Fig. 1 and ¶ [0028]; e.g., engine having ECUa = first component – see at least Fig. 1);
retrieve definition information associated with the diagnostic trouble code (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]);
determine, based on the definition information, a relationship to the second component of the machine (e.g., brake having ECU 82b = second component; at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]; e.g., system 1 includes DTCs from a plurality of systems, such as ABEI – see at least Figs. 5, 6 and ¶ [0057]);
display a notification of the diagnostic trouble code to an operator, the notification further including a link to navigate to diagnostic information of the second component (at S5, display unit displays a true DTC identified in S3 at S14 – see at least Figs. 7, 8 and ¶ [0050]; displays a button on the screen for calling an operation manual corresponding to the DTC and associated with a URL – see at least Fig. 7 and ¶ [0050]); and
when the link is selected via operator input: retrieve the diagnostic information associated with the second component (at S6, determination of whether or not the button on the screen has been operated – see at least Fig. 7 and ¶ [0051]; (if S6 = YES, the repair manual corresponding to URL for the DTC is downloaded and displayed on the screen at S7 – see at least Figs. 7 and ¶ [0052]); and
display the diagnostic information retrieved (if S6 = YES, the repair manual corresponding to URL for the DTC is downloaded and displayed on the screen at S7 – see at least Figs. 7 and ¶ [0052]).
Regarding claim 20, Kawahara discloses a fault diagnosis device and teaches:
wherein the receiver includes a storage medium storing definition information for a plurality of diagnostic trouble codes, wherein the definition information is predetermined at development time (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]), and wherein the definition information indicates a relationship between a component originating a diagnostic trouble code and a secondary component (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]; e.g., DTC combination A, B, E, I is connected as system 1).
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 3, 8, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kawahara in view of Takao et al. (US 2019/0130670 A1, “Takao”).
Regarding claims 3, 14, and 15, Kawahara fails to teach but Takao discloses an electronic manual display method and device and teaches:
wherein the definition information provides a description of a status associated with the diagnostic trouble code (e.g., ECU unable to receive signal S1 in overview display area 114 – see at least Fig. 2), and wherein the notification displayed includes output based at least in part on the description (e.g., wiper signal error in display area 112 – see at least Fig. 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the fault diagnosis device of Kawahara to provide and display a description of a status associated with the DTC, as taught by Takao, with a reasonable expectation of success, because providing DTC status descriptions to the mechanic would assist the mechanic in understanding the work processes required for fault diagnosis (Takao at ¶ [0007]).
Regarding claim 8, Kawahara fails to teach but Takao discloses an electronic manual display method and device and teaches:
wherein the at least one processor is in the machine (dealer terminal 12 receives DTCs from ECU 86 in vehicle 80 – see at least Fig. 1 and ¶ [0035]; vehicle may have multiple ECUs 86).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the fault diagnosis device of Kawahara to provide the processor in the machine, as taught by Takao, with a reasonable expectation of success, because providing the processor in the machine would allow the fault for faults to be communicated for analysis (Takao at ¶ [0035]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kawahara.
Regarding claim 6, Kawahara further teaches:
wherein the at least one processor is configured to:
receive linking information from [a data table] (system information 34 of system table 30 system table including trouble code groupings for each system – see at least Fig. 6 and ¶ [0054]); and
determine the relationship to the second component based on the linking information (at S11, systems of DTCs are identified – see at least Fig. 8 and ¶ [0054]; e.g., system 1 includes DTCs from a plurality of systems, such as ABEI – see at least Figs. 5, 6 and ¶ [0057]).
Kawahara discloses the claimed invention except that Kawahara discloses receiving linking information from a database associated with a failure diagnosis device instead of receiving linking information from the component of the machine. It would have been an obvious matter of design choice to receive linking information from the component of the machine instead of from a database associated with a failure diagnosis device, since Applicant has not disclosed that receiving linking information from the component of the machine solves any stated problem or is for any particular purpose and it appears that the invention would perform equally well with linking information received from any database.
Conclusion
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 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 AARON L TROOST whose telephone number is (571)270-5779. The examiner can normally be reached Mon-Fri 7:30am-4pm.
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, Anne Antonucci can be reached at 313-446-6519. 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.
/AARON L TROOST/Primary Examiner, Art Unit 3666
Prosecution Insights