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 .
Response to Amendment
This action is responsive to an amendment filed on 03/25/2026. Claims 9-12 have been added. Claims 1-12 are pending for examination.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 03/25/2026, with respect to the rejection of the pending claims under 35 U.S.C. §102 have been fully considered but they are not persuasive.
Applicant argues that “…no portion of the relay ECU 3 of Kurachi transmits a presentation message offering to provide a service to the integrated ECU 1 based on first setting information set in response to an instruction from the ECU 5. …the relay ECU 3 simply relays messages between the ECU 5 and the integrated ECU I using the appropriate communication protocols. The relay ECU 3 does not transmit any presentation message offering to provide a service to the integrated ECU 1…Accordingly, Kurachi fails to disclose, or even suggest, at least the following feature of independent claim 1: the communication transceiver comprising: a service control unit configured to transmit a presentation message offering to provide a service to the electronic control device conforming to a first protocol, which is a service-oriented communication protocol, based on first setting information set in response to an instruction from the main control unit” (Arg./Rem. Pages 12-13).
Examiner respectfully disagrees. Kurachi expressly teaches that the relay ECU 3 does more than merely “relay” messages. Kurachi discloses that the relay ECU 3 initiates service-oriented communication by transmitting a registration request to the integrated ECU 1: “the processing unit requests the in-vehicle communication device to register a delivery destination…” ¶[0037]. “The in-vehicle relay device makes a registration request to the in-vehicle communication device…” ¶[0038]. Kurachi further teaches that communication between the relay ECU 3 and the integrated ECU 1 uses SOME/IP, which is explicitly identified as a service-oriented communication protocol ¶[0053]. In a service-oriented architecture such as SOME/IP, a registration request is the mechanism by which a node presents its service needs or capabilities and thereby offers or requests a service. This is the functional equivalent of the claimed “presentation message offering to provide a service.”. Additionally, Kurachi explains that the integrated ECU 1 maintains configuration information (delivery destination table) and determines delivery behavior “according to the received request” ¶[0059], which corresponds to the claimed “first setting information set in response to an instruction from the main control unit.”
Accordingly, Kurachi teaches or at least suggests a service control unit that transmits a presentation message using a service-oriented protocol, and thus Applicant’s arguments is not persuasive. For details, see rejection infra.
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:
(A) 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;
(B) 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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a service control unit configured to…” and “a service interface unit configured to…” couple with functional language of transmit, convert communication data, receive request, register information in claims 1-4, without reciting sufficient structure to achieve those functions.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 USC. 112, sixth paragraph limitation: In para 0090, discloses “The service transceiver and techniques thereof described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied by a computer program.” and also recites in claim 8.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5, 8 and 9 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2024/0286564 (Kurachi et al.).
Regarding Claim 1, Kurachi teaches a communication transceiver connected to a main control unit of a communication device configured to be connected to an electronic control device via a single or a plurality of communication lines ([Fig. 1, ¶ 0050] Fig. is illustrates an in-vehicle communication system in which various devices such as an integrated ECU 1 [i.e., main control unit], a relay ECU 3 [i.e., communication transceiver/service control unit] and an ECU 5 [i.e., electronic control device]. …integrated ECU 1 is connected with multiple relay ECUs 3 through individual communication lines. …Multiple ECUs 5 are connected to each of the relay ECUs 3 through a common communication line), the communication transceiver comprising:
a service control unit configured to transmit a presentation message offering to provide a service to the electronic control device conforming to a first protocol, which is a service-oriented communication protocol, based on first setting information set in response to an instruction from the main control unit ([¶ 0036], The in-vehicle relay device communicates with the in-vehicle communication device in compliance with the first communication protocol for service-oriented communication. [¶ 0038], the in-vehicle relay device makes a registration request [implicitly, the registration request functions as a service presentation/offer in a service-oriented architecture] to the in-vehicle communication device. [¶ 0069], The relay ECUs 3 transmits, to the integrated ECU 1, a registration request for the delivery destination including the identification information attached thereto and information such as the type of information requested to be delivered. The registration of delivery destinations in the in-vehicle communication system can be performed in a procedure complying with the SOME/IP-SD communication protocol [i.e., a first protocol, which is a service-oriented communication protocol]. [¶ 0059], Fig. 3 illustrates a delivery destination table 12b that storing the identification information of the device as a delivery destination of the information in association with the type of information to be delivered to this device. [¶ 0083], the registration processing unit 11a transmits service information including various information related to services offered by its own device to the relay ECUs 3 ); and
a service interface unit configured to, in a case where service-oriented communication is established according to the presentation message, (i) convert communication data conforming to a second protocol received from the main control unit into communication data conforming to the first protocol and transmit converted communication data to the electronic control device ([¶ 0035], receives time-series information delivered from the in-vehicle communication device by the first communication unit and transmits the time-series information …by the second communication unit. [¶ 0053], The SOME/IP communication protocol is employed for communication between the integrated ECU 1 and the relay ECU 3. …the CAN communication protocol is employed for communication between the relay ECU 3 and the ECU 5. ([¶¶ 0077-0078] relay processing unit 31b performs processing of relaying messages between the integrated ECU 1 and the one or more ECUs 5. The relay processing unit 31b receives a message delivered from the integrated ECU 1 through the first communication unit 33, acquires time-series information contained in the received message, generates a CAN message containing the acquired information and transmits it through the second communication unit 34. The relay processing unit 31b receives a message to be transmitted by the ECU 5 through the second communication unit 34, acquires time-series information contained in the received message, generates an Ethernet (or SOME/IP) message containing the acquired information and transmits the message from the first communication unit 33. …messages are transmitted and received between the one or more ECUs 5 and the relay ECU 3 in compliance with the CAN communication protocol [i.e., second protocol] while messages are transmitted and received between the one or more relay ECUs 3 and the integrated ECU 1 in compliance with the SOME/IP communication protocol), or (ii) convert communication data conforming to the first protocol received from the electronic control device into communication data conforming to the second protocol and transmit converted communication data to the main control unit, based on second setting information set in response to an instruction from the main control unit [¶¶ 0088-0091] The integrated ECU 1 generates a message complying with SOME/IP communication protocol (service-oriented message) that contains one or more information read from the stream DB and transmits the message to the one or more relay ECUs 3 which has been registered as the delivery destination of this information. The relay processing unit 31b of the relay ECU 3 generates a message complying with the CAN communication protocol containing the information received and transmits the message to the ECU 5. Conversely, when the relay ECU 3 receives a message from the ECU 5, it acquires time-series information from the message complying with the CAN communication protocol and generates a message complying with the SOME/IP communication protocol containing the information acquired and transmits the message generated to the integrated ECU 1. [¶ 0059], delivery destination table 12b …storing, …the identification information of the device as a delivery destination of the information in association with the type of information to be delivered to this device. …The integrated ECU 1 …decides the type of information to be delivered according to the received request and stores the identification information of the relay ECU 3 as a request source in association with the type of information to be delivered in the delivery destination table 12b.).
Regarding Claim 2, Kurachi teaches the communication transceiver according to claim 1, wherein: the service control unit is configured to: receive a request for subscription to event communication conforming to the first protocol from the electronic control device that has received the presentation message; and register information of a request source requesting the subscription in the service interface unit based on a received request ([¶¶ 0085-0086], a registration processing procedure performed by the relay ECU 3. The relay ECU 3 determines whether or not the service information transmitted by the integrated ECU 1 is received, if received the service information from the integrated ECU 1 , the registration processing unit 31a judges the information required by the one or more ECUs 5. The registration processing unit 31a may here judge the information required by each ECU 5 by inquiring of the ECU 5 about required information and obtaining the reply. The registration processing unit 31a generates a registration request message containing information such as the type of information that is judged to be required by the ECU 5, identification information attached to its own device and the like. The registration processing unit 31a transmits the generated registration request message from the first communication unit 33 to the integrated ECU 1); and the service interface unit is configured to: receive the communication data conforming to the second protocol from the main control unit; convert the communication data conforming to the second protocol received from the main control unit into an event message conforming to the first protocol based on the second setting information; and transmit the event message conforming to the first protocol to the electronic control device based on information of a registered request source ([¶¶ 0088-0091] The integrated ECU 1 generates a message complying with SOME/IP communication protocol (service-oriented message) that contains one or more information read from the stream DB and transmits the message to the one or more relay ECUs 3 which has been registered as the delivery destination of this information. The relay processing unit 31b of the relay ECU 3 generates a message complying with the CAN communication protocol containing the information received and transmits the message to the ECU 5. Conversely, when the relay ECU 3 receives a message from the ECU 5, it acquires time-series information from the message complying with the CAN communication protocol and generates a message complying with the SOME/IP communication protocol containing the information acquired and transmits the message generated to the integrated ECU 1).
Regarding Claim 3, Kurachi teaches the communication transceiver according to claim 1, wherein: the service interface unit is configured to: receive a request message conforming to the first protocol from the electronic control device that has received the presentation message; convert the request message conforming to the first protocol into request message conforming to the second protocol based on the second setting information; transmit the request message conforming to the second protocol together with an identifier indicating the request message to the main control unit; receive a response message conforming to the second protocol together with an identifier indicating the response message from the main control unit; and convert the response message conforming to the second protocol received from the main control unit into response message conforming to the first protocol based on the second setting information, and transmit a converted response message to the electronic control device ([¶¶ 0088-0091] The integrated ECU 1 generates a message complying with SOME/IP communication protocol (service-oriented message) that contains one or more information read from the stream DB and transmits the message to the one or more relay ECUs 3 which has been registered as the delivery destination of this information. The relay processing unit 31b of the relay ECU 3 generates a message complying with the CAN communication protocol containing the information received and transmits the message to the ECU 5. Conversely, when the relay ECU 3 receives a message from the ECU 5, it acquires time-series information from the message complying with the CAN communication protocol and generates a message complying with the SOME/IP communication protocol containing the information acquired and transmits the message generated to the integrated ECU 1).
Regarding Claim 5, Kurachi teaches the communication transceiver according to claim 1, wherein: the first protocol is Scalable service-Oriented Middleware over Internet Protocol or Data Distribution Service ([¶ 0008], Scalable service-Oriented Middleware over IP (SOME/IP) communication protocol is a communication protocol for the upper layer of the Ethernet. SOME/IP is service-oriented communication where a service-oriented architecture is applied to vehicle communication. [¶ 0053], The SOME/IP communication protocol is employed for communication between the integrated ECU 1 and the relay ECU 3).
Regarding Claim 8, Kurachi teaches the communication transceiver according to claim 1, further comprising: at least one of (i) a circuit and (ii) a processor having a memory storing computer program code, wherein: the at least one of the circuit and the processor having the memory is configured to cause the communication transceiver to provide at least one of: the service control unit; and the service interface unit (Fig. 5, ¶ 0072] The relay ECU 3 is composed of a processing unit 31, a storage unit 32, a first communication unit (transceiver) 33, a second communication unit (transceiver) 34 and the like. The processing unit 31 reads and executes the program 32a stored in the storage unit 32 to thereby perform various processing such as processing of requesting the integrated ECU 1 to register the delivery destination and processing of relaying messages between the integrated ECU 1 and the ECUs 5).
Regarding Claim 9, Kurachi teaches the communication transceiver according to claim 1, wherein: the communication transceiver generates the presentation message conforming to the service-oriented communication protocol ([¶¶ 0037-0038], the processing unit requests the in-vehicle communication device to register a delivery destination… the in-vehicle relay device makes a registration request [implicitly, presentation message] to the in-vehicle communication device. [¶ 0035], in-vehicle relay device …communicates in compliance with a first communication protocol for service-oriented communication. [¶¶ 0052-0053], The SOME/IP communication protocol is a communication protocol designed based on a service-oriented architecture and is a communication protocol … The SOME/IP communication protocol is employed for communication between the integrated ECU 1 and the relay ECU 3).
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.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kurachi in view of US 2018/0287815 (Yamamoto et al.).
Regarding Claim 4, the limitations are identical and/or equivalent in scope to claim 2, therefore, rejected for the same rationale. However, Kurachi does not explicitly teach, but Yamamoto teaches communication data conforming to a third protocol (emphasis added) ([¶ 0018], An in-vehicle gateway device is a device which connects communication between a first network and a second network. The first network is an Ethernet network and an ECU that transmits data to the in-vehicle gateway device. And a second network, a non-Ethernet network includes a plurality of networks of plurality of types, that is, a CAN network, an LIN network, a FlexRay network, and a MOST network. The Gateway device is configured to perform transfer control of data between the first network and plurality of destinations in the second network. Thus, Yamamoto discloses an in-vehicle gateway that communicates with different ECUs over multiple, different communication networks, namely Ethernet and a plurality of non-Ethernet network including CAN, LIN, FlexRay, and MOST [i.e., third protocol], thereby teaches communication data conforming to a third protocol).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yamamoto's gateway device that connects an ethernet network with plurality of different non-Ethernet network including CAN, LIN, FlexRay, and MOST to the teachings of Kurachi, because incorporating this gateway architecture would have predictably allowed the relay ECU of Kurachi to support communication with additional ECU operating on another network form, thereby facilitating integration of multiple vehicle subsystems across heterogeneous in-vehicle network.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kurachi in view of US 2020/0047687 (Camhi et al.).
Regarding Claim 6, although, Kurachi teaches the second protocol conform to CAN communication protocol, however, Kurachi does not explicitly teach, but Camhi teaches the communication transceiver according to claim 1, wherein: the second protocol conforms to at least one of a Serial Peripheral Interface, a Mobile Industry Processor Interface - Camera Serial Interface, a Mobile Industry Processor Interface - Camera Serial Interface 2, and a Mobile Industry Processor Interface - Display Serial Interface ([¶ 0066] The communication module 155 can communicate with the ECUs 120 using one or more communication protocol standards, such as Controller Area Network (CAN), CAN with Flexible Data-Rate (CAN FD), Local Interconnect Network (LIN), FlexRay, Media Oriented Systems Transport (MOST), Ethernet, Serial Peripheral Interface (SPI), Peripheral Sensor Interface (PSI5), Distributed Systems Interface (DSI), and Single Edge Nibble Transmission (SENT), among others).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Camhi's using communication protocol such as Serial Peripheral Interface (SPI) to the teachings of Kurachi in order to increase compatibility and design flexibility, allowing the communication module to interface with ECUs that support different protocol standard.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Kurachi in view of Yamamoto, and further in view of EP 4622184 (Hirama).
Regarding Claim 7, Kurachi in view of Yamamoto do not explicitly teach, however, Hirama teaches the communication transceiver according to claim 4, wherein: the third protocol is Institute of Electrical and Electronics Engineers 1722 ([Page 3, para 4] the ECU 22 and the ECU 24 can communicate over Ethernet conforming to Institute of Electrical and Electronics Engineers (IEEE) 1722, which is a communication standard that defines the packet format for video and audio data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hirama's teaching of communicate over Ethernet conforming IEEE 1722 to the combined teachings of Kurachi and Yamamoto in order to support transmission of high bandwidth multimedia data that cannot be efficiently handled by CAN. Therefore, such a modification reflects a known and predictable design choice in an automotive system.
Claim 10-12 is rejected under 35 U.S.C. 103 as being unpatentable over Kurachi in view of AUTOSAR SOME/IP Service Discovery Protocol Specification (herein after “AUTOSAR”).
Claim 10, Kurachi teaches the communication transceiver according to claim 1, wherein: the presentation message …indicates a content of the service provided by the communication device ([¶ 0059] …delivery destination table 12b is storing the identification information of the device as a delivery destination of the information in association with the type of information to be delivered to this device. …the table stores delivery of information such as a vehicle speed, an engine revolution number, a steering angle and the like to the delivery destination with the identification information of the relay ECU_A. Further stored is delivery of information such as a steering angle, a shift position and the like to the delivery destination with the identification information of the relay ECU_B. Further stored is delivery of information such as position information, a vehicle speed and the like to the delivery destination with the identification information of the relay ECU_C. The integrated ECU 1 accepts a registration request from the relay ECU 3 … decides the type of information to be delivered according to the received request and stores the identification information of the relay ECU 3 as a request source in association with the type of information to be delivered in the delivery destination table 12b).
While, Kurachi teaches message includes identification information of the relay, however, Kurachi does not explicitly teach, but AUTOSAR teaches the presentation message includes a service ID ([5.1.2 SOME/IP-SD Message Format and 5.1.2.1 The SOME/IP-SD Header Format shall follow: Message ID (Service ID/Method ID)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate AUTOSAR's SOME/IP-SD into Kurachi because Kurachi already relies on SOME/IP for service oriented communication, and AUTOSAR SD is the industry-standard extension that defines the mandatory message structure for service presentation, including the Service ID field used to uniquely identify the service. Integrated AUTOSAR SD’s OfferService message format into Kurachi would have been obvious design choice to ensure interoperability with other ECUs, compliance with established automotive Ethernet standard, and correct service-oriented behavior.
Regarding Claim 11, Kurachi does not explicitly teach, however, AUTOSAR teaches the communication transceiver according to claim 1, wherein: when a service provision state of the communication device is a Not-Ready state, the service interface unit is configured to discard the communication data from the main control unit ([Page 6] AUTOSAR discloses message sequences and semantics of the Protocol SOME/IP Service Discovery (SOME/IP-SD). The main tasks of the Service Discovery Protocol are communicating the availability of functional entities called services in the in-vehicle communication as well as controlling the send behavior of event messages. SOME/IP-SD is used to Detect if service instances are running. [Page 19], Requiring a service instance: send a SOME/IP-SD message to the ECU implementing the required service instance with the meaning that this service instance is needed by the other ECU. This may be also sent if the service instance is not running; thus, was not offered yet. [page 44] The Stop Offer Service entry type shall be used to stop offering service instances [Page 56], When a server service instance of an ECU is being stopped, a Stop Offer Service entry shall be sent out. … When a server sends out a Stop Offer Service entry all subscriptions for this service instance shall be deleted on the server side. When a client receives a Stop Offer Service entry all subscriptions for this service instance shall be deleted on the client side. … When a client service instance of an ECU is in the Main Phase and is being stopped, the SD shall send out Stop Subscribe Eventgroup entries for all subscribed Eventgroups).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate AUTOSAR's SOME/SD into Kurachi because Kurachi already relies on SOME/IP, and AUTOSAR SD is standard, widely-adopted service-availability and discover layer that operates directly on top of SOME/IP. AUTOSAR SD provide the missing functionality, i.e., a service-availability state machine in which communication is ignored when a service in not ready yet and an OfferService presentation message transmitted when the service become available. Integrated AUTOSAR SD into Kurachi would have been obvious design choice to ensure correct, interoperable, and standard-compliant service-oriented communication behavior, yielding predictable results and solving the known problem of preventing invalid communication before service availability.
Regarding Claim 12, Kurachi does not explicitly teach, however, AUTOSAR teaches the communication transceiver according to claim 11, wherein: the service interface unit is configured to transmit the presentation message when the communication device is in a Ready state ([Page 6], Service Offering…A service is offering a service to the network [implicitly, ready state]. [Page 18] Offering a service instance that one ECU implements an instance of a service and tells other ECUs using SOME/IP-SD that they may use it. [Page 53] The service discovery shall enter the Initial Wait Phase for a server service instance when the link on the interface needed for this service instance is up and the server service is available …the functionality needed by this service instance has to be ready to offer a service).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate AUTOSAR 's SOME/SD into Kurachi because Kurachi already relies on SOME/IP, and AUTOSAR SD is standard, widely-adopted service-availability and discover layer that operates directly on top of SOME/IP. AUTOSAR SD provide the missing functionality, i.e., a service-availability state machine in which communication is ignored when a service in not ready yet and an OfferService presentation message transmitted when the service become available. Integrated AUTOSAR SD into Kurachi would have been obvious design choice to ensure correct, interoperable, and standard-compliant service-oriented communication behavior, yielding predictable results and solving the known problem of start communication confirming the service is available.
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 MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5: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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights