DETAILED ACTION
Applicant’s Amendment filed on June 18, 2026 has been reviewed.
Claim 11 is newly added in the amendment.
Claims 2 is cancelled in the amendment.
Claims 1, 3-4 and 7-10 are amended in the amendment.
Claims 1 and 3-11 have been examined.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 18, 2026 has been entered
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on June 8, 2026 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 and 3-10 are rejected under 35 U.S.C. 103 as being unpatentable over Go et al. (US 2024/0187503 A1), hereinafter referred to as Go, in view of IINAMI et al. (US 2023/0344645 A1), hereinafter referred to as IINAMI.
With respect to claim 1, Go teaches A service proxy device (the gateway device 101B, para. 0097; fig. 2) comprising
a first communicator configured to be connected to a client (the gateway device 101A is a client of a service X to be provided in the vehicle 1, para. 0074; the vehicle-mounted device to which a service is provided is also referred to as a “client”, para. 0071) via a first communication (the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; communication port 24A is connected to the gateway device 101A, via the cables 14, para. 0081),
a second communicator configured to be connected to a server (the vehicle-mounted ECU 111B is a server of the service X, para. 0075) via a second communication (the vehicle-mounted ECUs 111A and 111B are connected to the gateway device 101B, para. 0072; the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; three communication ports 24B and 24C, are respectively connected to the vehicle-mounted ECU 111A, and the vehicle-mounted ECU 111B via the cables 14, para. 0081),
a database (The storage unit 23 is a nonvolatile memory, para. 0079), and
a controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079), wherein
the database (The storage unit 23 is a nonvolatile memory, para. 0079) is configured to
store a map table that associates functions with services and identifies, for each function from among the functions (the relay rule table Ta1 includes, for each communication port 24 of the gateway device 101B, a set of Transmission source, Transmission destination, Communication protocol in the TCP/IP layer, and Type of service of communication data to be received, and Content of control to be performed on the communication data, para. 0084; fig. 3 and 5),
store a server management table (the vehicle-mounted ECU 111B has multicast provision data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1, the relay unit 22 receives the provision data via the communication port 24C, and checks the rule to be applied to the provision data, para. 0113; also see para. 0119) that identifies, for each of one or more functions from among the functions possessed by the server, whether the function is available or not in association with the server having the function (the conversion processing unit 21 perform processing of displaying, messages meaning that the service X corresponding to the conversion processing of the communication protocol is not available and that the service X is available if you switch the driving state of the vehicle 1 from automated driving to manual driving, para. 0132),
the controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079) is configured to
receive, via the first communicator, a service execution instruction requesting execution of one service, from among the services, from the client (the gateway device 101B receives the request data transmitted from the gateway device 101A, para. 0175; fig. 9; the gateway device 101B transmits the request data conforming to the converted communication protocol P2 to the vehicle-mounted ECU 111B, para. 0177),
receive, via the second communicator, an execution result of one function, from among the functions, associated with the service from the server, wherein the one function is one or the one or more functions identified by the answer data as being possessed by the server (the vehicle-mounted ECU 111B transmits communication data (hereinafter, also referred to as “response data”) including a response message of responding to the request data for the service X to the gateway device 101A (step S53), continuously using the communication protocol P2, para. 0179), and
transmit, via the first communicator, the execution result of one function associated with one service based on the service execution instruction and the map table, to the client (the gateway device 101B transmits the response data conforming to the converted communication protocol P1 to the gateway device 101A (step S56); as a result of the operations in, the service X is realized in the vehicle-mounted communication system, para. 0181).
Go does not explicitly teach
transmit, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server,
receive, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server,
update, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server,
However, IINAMA teaches
transmit, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server (the access administration ECU 51 serve as a gateway; the access administration ECU 51 [gateway] check whether the specific work requested by the request message is listed in the available work list corresponding to the coupled device number of the vehicle maintenance apparatus 2; the access administration ECU 51 accept the request message and transfer the request message to the vehicle device ECUs 52 [including the server] via the communication line 54, para. 0054),
receive, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server (the access administration ECU 51 may serve as a gateway that transfers the request message to the vehicle device ECUs 52 via a communication line 54; when receiving an unacceptable request message, the access administration ECU 51 refrain from transferring the request message to the vehicle device ECUs 52, para. 0051),
update, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server (the access administration ECU 61 perform signature verification of the role list using a public key stored in the memory 612, and send the role list verified by the signature verification to all of vehicle device ECUs 62 relevant to the role list. In each of the vehicle device ECUs 62 relevant to the access administration of the specific work, a control processor 621 cause a memory 622 to store the available work list of the specific work, para. 0055) in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002),
Therefore, based on Go in view of IINAMI, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of IINAMI to the device of Go in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002).
With respect to claim 3, Go teaches The service proxy device according to claim 1, wherein
the controller is further configured to
determine whether the one function associated with the one service related to the service execution instruction is available based on the server management table (the vehicle-mounted ECU 111B multicasts again the provision data for the service X in accordance with the communication protocol P1. In this case, the gateway device 101B permits passage of the provision data and relays the provision data to the gateway device 101A, in accordance with the rule registered in the updated relay rule table Ta1 (step S80), communication connection between the server and the client of the service X is established in the vehicle-mounted communication system, para. 0191), and
transmit the execution result to the client in a case of determining that the one function is available (the vehicle-mounted ECU 111B multicasts again the provision data for the service X in accordance with the communication protocol P1. In this case, the gateway device 101B permits passage of the provision data and relays the provision data to the gateway device 101A, in accordance with the rule registered in the updated relay rule table Ta1 (step S80), communication connection between the server and the client of the service X is established in the vehicle-mounted communication system, para. 0191).
With respect to claim 4, Go teaches The service proxy device according to claim 1, wherein
the controller is further configured to
receive the execution result from the server (The gateway device 101B receives the provision data newly transmitted from the vehicle-mounted ECU 111B in accordance with the common protocol, checks the application rule of the provision data, and performs the above-described protocol determination, the gateway device 101B determines that the communication protocols of the gateway device 101A and the vehicle-mounted ECU 111B that are to communicate with each other match each other; the operation described in “(a) When Communication Protocols Match Each Other” is performed, and the relay rule table Ta1 is updated, para. 0119), and
update the server management table by associating the one function with the execution result (The gateway device 101B receives the provision data newly transmitted from the vehicle-mounted ECU 111B in accordance with the common protocol, checks the application rule of the provision data, and performs the above-described protocol determination, the gateway device 101B determines that the communication protocols of the gateway device 101A and the vehicle-mounted ECU 111B that are to communicate with each other match each other; the operation described in “(a) When Communication Protocols Match Each Other” is performed, and the relay rule table Ta1 is updated, para. 0119).
With respect to claim 5, Go teaches The service proxy device according to claim 1, wherein
the controller is further configured to
transmit a function execution instruction to the server that has the one function, the function execution instruction requesting execution of the one function associated with the service related to the one service execution instruction (Upon receiving the notification of the common protocol from the gateway device 101B, the vehicle-mounted ECU 111B determines whether or not it is possible to switch to the common protocol, and notifies the gateway device 101B of the determination result. If it is possible to switch to the common protocol, the vehicle-mounted ECU 111B switches to the common protocol, and transmits the provision data in accordance therewith, para. 0118), and
receive, from the server, the execution result based on the function execution instruction (Upon receiving the notification of the common protocol from the gateway device 101B, the vehicle-mounted ECU 111B determines whether or not it is possible to switch to the common protocol, and notifies the gateway device 101B of the determination result. If it is possible to switch to the common protocol, the vehicle-mounted ECU 111B switches to the common protocol, and transmits the provision data in accordance therewith, para. 0118).
With respect to claim 6, Go teaches The service proxy device according to claim 1, wherein
the database is further configured to
store a client management table that identifies the one service requested by the client in association with the client (the gateway device 101A has multicast search data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1. In this case, the relay unit 22 receives the search data via the communication port 24A, and checks the rule to be applied to the search data, para. 0111),
the controller is further configured to
receive a service check instruction for checking presence or absence of the one service from the client via the first communicator (the gateway device 101A has multicast search data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1. In this case, the relay unit 22 receives the search data via the communication port 24A, and checks the rule to be applied to the search data, para. 0111),
determine whether the one function corresponding to the one service exists based on the service check instruction and the map table (the gateway device 101A has multicast search data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1. In this case, the relay unit 22 receives the search data via the communication port 24A, and checks the rule to be applied to the search data, para. 0111), and
update the client management table and the map table based on the service check instruction (the conversion processing unit 21 changes the content of the rule 12 to content that the communication data for use in the service X received from the gateway device 101A via the communication port 24A is to be permitted to pass and relay processing be performed, and updates the relay rule table Ta1, para. 0109).
With respect to claim 7, Go teaches A service providing system comprising
a client (the gateway device 101A is a client of a service X to be provided in the vehicle 1, para. 0074),
a server (the vehicle-mounted ECU 111B is a server of the service X, para. 0075), and
a service proxy device (the gateway device 101B, para. 0097; fig. 2), wherein
the service proxy device (the gateway device 101B, para. 0097; fig. 2) includes
a first communicator configured to be connected to the client (the gateway device 101A is a client of a service X to be provided in the vehicle 1, para. 0074; the vehicle-mounted device to which a service is provided is also referred to as a “client”, para. 0071) via a first communication (the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; communication port 24A is connected to the gateway device 101A, via the cables 14, para. 0081),
a second communicator configured to be connected to the server (the vehicle-mounted ECU 111B is a server of the service X, para. 0075) via a second communication (the vehicle-mounted ECUs 111A and 111B are connected to the gateway device 101B, para. 0072; the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; three communication ports 24B and 24C, are respectively connected to the vehicle-mounted ECU 111A, and the vehicle-mounted ECU 111B via the cables 14, para. 0081),
a database (The storage unit 23 is a nonvolatile memory, para. 0079), and
a controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079), wherein
the database (The storage unit 23 is a nonvolatile memory, para. 0079) is configured to
store a map table that associates functions with services and identifies, for each function from among the functions, at least one server having the function and, for each service from among the services, at least one client requesting the service (the relay rule table Ta1 includes, for each communication port 24 of the gateway device 101B, a set of Transmission source, Transmission destination, Communication protocol in the TCP/IP layer, and Type of service of communication data to be received, and Content of control to be performed on the communication data, para. 0084; fig. 3 and 5), and
store a server management table (the vehicle-mounted ECU 111B has multicast provision data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1, the relay unit 22 receives the provision data via the communication port 24C, and checks the rule to be applied to the provision data, para. 0113; also see para. 0119) that identifies, for each of one or more functions from among the functions possessed by the server, whether the function is available or not in association with the server having the function (the conversion processing unit 21 perform processing of displaying, messages meaning that the service X corresponding to the conversion processing of the communication protocol is not available and that the service X is available if you switch the driving state of the vehicle 1 from automated driving to manual driving, para. 0132),
the controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079) is configured to
receive, via the first communicator, a service execution instruction requesting execution of one service, from among the services, from the client (the gateway device 101B receives the request data transmitted from the gateway device 101A, para. 0175; fig. 9; the gateway device 101B transmits the request data conforming to the converted communication protocol P2 to the vehicle-mounted ECU 111B, para. 0177),
receive, via the second communicator, an execution result of one function, from among the functions, associated with the service from the server, wherein the one function is one or the one or more functions identified by the answer data as being possessed by the server (the vehicle-mounted ECU 111B transmits communication data (hereinafter, also referred to as “response data”) including a response message of responding to the request data for the service X to the gateway device 101A (step S53), continuously using the communication protocol P2, para. 0179), and
transmit, via the first communicator, the execution result of the one function associated with the one service based on the service execution instruction and the map table, to the client (the gateway device 101B transmits the response data conforming to the converted communication protocol P1 to the gateway device 101A (step S56); as a result of the operations in, the service X is realized in the vehicle-mounted communication system, para. 0181).
Go does not explicitly teach
transmit, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server,
receive, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server,
update, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server,
However, IINAMA teaches
transmit, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server (the access administration ECU 51 serve as a gateway; the access administration ECU 51 [gateway] check whether the specific work requested by the request message is listed in the available work list corresponding to the coupled device number of the vehicle maintenance apparatus 2; the access administration ECU 51 accept the request message and transfer the request message to the vehicle device ECUs 52 [including the server] via the communication line 54, para. 0054),
receive, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server (the access administration ECU 51 may serve as a gateway that transfers the request message to the vehicle device ECUs 52 via a communication line 54; when receiving an unacceptable request message, the access administration ECU 51 refrain from transferring the request message to the vehicle device ECUs 52, para. 0051),
update, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server (the access administration ECU 61 perform signature verification of the role list using a public key stored in the memory 612, and send the role list verified by the signature verification to all of vehicle device ECUs 62 relevant to the role list. In each of the vehicle device ECUs 62 relevant to the access administration of the specific work, a control processor 621 cause a memory 622 to store the available work list of the specific work, para. 0055) in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002),
Therefore, based on Go in view of IINAMI, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of IINAMI to the system of Go in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002).
With respect to claim 8, Go teaches A service proxy method for a service proxy device (the gateway device 101B, para. 0097; fig. 2) including a first communicator connected to a client (the gateway device 101A is a client of a service X to be provided in the vehicle 1, para. 0074; the vehicle-mounted device to which a service is provided is also referred to as a “client”, para. 0071) via a first communication (the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; communication port 24A is connected to the gateway device 101A, via the cables 14, para. 0081), a second communicator connected to a server (the vehicle-mounted ECU 111B is a server of the service X, para. 0075) via a second communication (the vehicle-mounted ECUs 111A and 111B are connected to the gateway device 101B, para. 0072; the gateway device 101B is not limited to a configuration in which three communication ports 24 are provided, para. 0080; The communication port 24 is a terminal to which the cable 14 can be connected to a vehicle-mounted device of the vehicle 1; three communication ports 24B and 24C, are respectively connected to the vehicle-mounted ECU 111A, and the vehicle-mounted ECU 111B via the cables 14, para. 0081), a database (The storage unit 23 is a nonvolatile memory, para. 0079), and a controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079),
the service proxy method comprising,
by using the database (The storage unit 23 is a nonvolatile memory, para. 0079),
storing a map table that associates functions with services and identifies, for each function from among the functions, at least one server having the function and, for each service from among the services, at least one client requesting the service (the relay rule table Ta1 includes, for each communication port 24 of the gateway device 101B, a set of Transmission source, Transmission destination, Communication protocol in the TCP/IP layer, and Type of service of communication data to be received, and Content of control to be performed on the communication data, para. 0084; fig. 3 and 5),
storing a server management table (the vehicle-mounted ECU 111B has multicast provision data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1, the relay unit 22 receives the provision data via the communication port 24C, and checks the rule to be applied to the provision data, para. 0113; also see para. 0119) that identifies, for each of one or more functions from among the functions possessed by the server, whether the function is available or not in association with the server having the function (the conversion processing unit 21 perform processing of displaying, messages meaning that the service X corresponding to the conversion processing of the communication protocol is not available and that the service X is available if you switch the driving state of the vehicle 1 from automated driving to manual driving, para. 0132),
by using the controller (The conversion processing unit 21 and the relay unit 22 are realized by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor, para. 0079),
receiving, via the first communicator, a service execution instruction requesting execution of the one service, from among the services, from the client (the gateway device 101B receives the request data transmitted from the gateway device 101A, para. 0175; fig. 9; the gateway device 101B transmits the request data conforming to the converted communication protocol P2 to the vehicle-mounted ECU 111B, para. 0177),
receiving, via the second communicator, an execution result of one function, from among the functions, associated with the service from the server, wherein the one function is one or the one or more functions identified by the answer data as being possessed by the server (the vehicle-mounted ECU 111B transmits communication data (hereinafter, also referred to as “response data”) including a response message of responding to the request data for the service X to the gateway device 101A (step S53), continuously using the communication protocol P2, para. 0179), and
transmitting, via the first communicator, the execution result of the one function associated with the one service based on the service execution instruction and the map table, to the client (the gateway device 101B transmits the response data conforming to the converted communication protocol P1 to the gateway device 101A (step S56); as a result of the operations in, the service X is realized in the vehicle-mounted communication system, para. 0181).
Go does not explicitly teach
transmitting, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server,
receiving, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server,
updating, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server,
However, IINAMA teaches
transmit, via the second communicator, a function check instruction to the server for checking the one or more functions possessed by the server (the access administration ECU 51 serve as a gateway; the access administration ECU 51 [gateway] check whether the specific work requested by the request message is listed in the available work list corresponding to the coupled device number of the vehicle maintenance apparatus 2; the access administration ECU 51 accept the request message and transfer the request message to the vehicle device ECUs 52 [including the server] via the communication line 54, para. 0054),
receive, via the second communicator, an answer data transmitted from the server in response to the function check instruction and identifying the one or more functions possessed by the server (the access administration ECU 51 may serve as a gateway that transfers the request message to the vehicle device ECUs 52 via a communication line 54; when receiving an unacceptable request message, the access administration ECU 51 refrain from transferring the request message to the vehicle device ECUs 52, para. 0051),
update, based on the answer data, the server management table so as to identify whether each of the one or more functions identified as being possessed by the server is available or not in association with the server (the access administration ECU 61 perform signature verification of the role list using a public key stored in the memory 612, and send the role list verified by the signature verification to all of vehicle device ECUs 62 relevant to the role list. In each of the vehicle device ECUs 62 relevant to the access administration of the specific work, a control processor 621 cause a memory 622 to store the available work list of the specific work, para. 0055) in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002),
Therefore, based on Go in view of IINAMI, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of IINAMI to the method of Go in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002).
With respect to claim 9, Go teaches The service proxy device according to claim 1, wherein
the database is further configured to
store a client management table that identifies the one service requested by the client in association with the client (the conversion processing unit 21 changes the content of the rule 12 to content that the communication data for use in the service X received from the gateway device 101A via the communication port 24A is to be permitted to pass and relay processing be performed, and updates the relay rule table Ta1, para. 0109).
With respect to claim 10, Go teaches The service proxy device according to claim 10, wherein
the controller is further configured to
receive, via the first communicator, a service check instruction for checking presence or absence of the one service from the client via the first communicator (the gateway device 101A has multicast search data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1. In this case, the relay unit 22 receives the search data via the communication port 24A, and checks the rule to be applied to the search data, para. 0111),
determine whether the one function corresponding to the one service exists based on the service check instruction and the map table (the gateway device 101A has multicast search data for the service X conforming to the communication protocol P1 after the update of the relay rule table Ta1. In this case, the relay unit 22 receives the search data via the communication port 24A, and checks the rule to be applied to the search data, para. 0111), and
update the client management table and the map table based on the service check instruction in a case where the one function corresponding to the one service exists (the conversion processing unit 21 changes the content of the rule 12 to content that the communication data for use in the service X received from the gateway device 101A via the communication port 24A is to be permitted to pass and relay processing be performed, and updates the relay rule table Ta1, para. 0109).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Go et al. (US 2024/0187503 A1), hereinafter referred to as Go, in view of IINAMI et al. (US 2023/0344645 A1), hereinafter referred to as IINAMI, and further in view of Honya et al. (US 2025/0174054 A1), hereinafter referred to as Honya.
With respect to claim 11, Go in view of IINAMA teaches The service proxy device according to claim 1 as described above,
Go in view of IINAMA does not explicitly teach wherein the controller is further configured to:
determine, based on the server management table, whether there is an execution result that has been previously received from the server and registered in the server management table in association with the one function;
transmit, to the client, the execution result registered in the server management table in a case of determining that the execution result exists; and
in a case of determining that the execution result does not exist:
transmit, to the server, a function execution instruction requesting execution of the one function,
receive, from the server, the execution result transmitted based on the function execution instruction,
update the server management table by associating the one function with the received execution result; and
transmit the received execution result to the client.
However, Honya teaches wherein the controller is further configured to:
determine, based on the server management table, whether there is an execution result that has been previously received from the server and registered in the server management table in association with the one function (the application store 15 has a function of registering a service application SA manufactured by a service provider SV in the application store 15, based on submission by the service provider SV who accessed the application store 15 using a communication device such as a personal computer; the service application SA registered in the application store 15 is posted on the website of the application store 15, para. 0090);
transmit, to the client, the execution result registered in the server management table in a case of determining that the execution result exists (the ECU 4 transmits a command for instructing acquisition of vehicle speed information to the ECU 6 that controls the engine; upon acquiring the vehicle speed information, the ECU 6 that controls the engine transmits an execution result indicating the acquired vehicle speed information to the ECU 4; upon receiving the execution result from the request-targeted API, the API GW 40 transfers the execution result to the requester service application, para. 0114); and
in a case of determining that the execution result does not exist:
transmit, to the server, a function execution instruction requesting execution of the one function ((the ECU 4 transmits a command for instructing acquisition of vehicle speed information to the ECU 6 that controls the engine; upon acquiring the vehicle speed information, the ECU 6 that controls the engine transmits an execution result indicating the acquired vehicle speed information to the ECU 4; upon receiving the execution result from the request-targeted API, the API GW 40 transfers the execution result to the requester service application, para. 0114),
receive, from the server, the execution result transmitted based on the function execution instruction (the ECU 4 transmits a command for instructing acquisition of vehicle speed information to the ECU 6 that controls the engine. Upon acquiring the vehicle speed information, the ECU 6 that controls the engine transmits an execution result indicating the acquired vehicle speed information to the ECU 4; upon receiving the execution result from the request-targeted API, the API GW 40 transfers the execution result to the requester service application, para. 0114),
update the server management table by associating the one function with the received execution result (each time the service application SA uses the API, the API GW 40 updates the statistical access log, para. 0152); and
transmit the received execution result to the client (the ECU 4 transmits a command for instructing acquisition of vehicle speed information to the ECU 6 that controls the engine. Upon acquiring the vehicle speed information, the ECU 6 that controls the engine transmits an execution result indicating the acquired vehicle speed information to the ECU 4; upon receiving the execution result from the request-targeted API, the API GW 40 transfers the execution result to the requester service application, para. 0114).
Therefore, based on Go in view of IINAMI, and further in view of Honya, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Honya to the device of Go in view of IINAMI in order to prevent unauthorized access to information stored in the ECU mounted on a vehicle as taught by IINAMI (para. 0002).
Response to Arguments
Applicant’s arguments with respect to claims 1 and 3-11 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO HONG NGUYEN whose telephone number is (571)272-2666. The examiner can normally be reached on Monday-Friday 8AM-4:30PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H. Hwang can be reached on (571)272-40364036. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.H.N/Examiner, Art Unit 2447
July 25, 2026
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Prosecution Insights