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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/06/2025 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 Interpretation
During examination, claim terms are given their broadest reasonable interpretation consistent with the specification as that specification would be read by one of ordinary skill in the art (MPEP 2111). The constructions below govern the rejections that follow.
With respect to Claim 7 recites: “an input/output module that receives or transmits a communication network frame, a first conversion module that converts a first communication network frame into a second communication network frame and a second conversion module that converts the second communication network frame into the first communication network frame.”
The Examiner notes that each limitation uses the generic placeholder module, joined to the function the module performs, and recites no structure for performing that function. Under MPEP 2181 these limitations are presumed to invoke 35 U.S.C. 112(f) even though they do not use the word means, and the presumption is not rebutted, because module is a nonce word and the claim supplies no structural modifier. (MPEP 2181(I)(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;”)
Accordingly, the corresponding structure in the specification is, for the conversion modules, “a communication protocol conversion module implemented as hardware or software” (paragraph [0039] of the publication), that is, conversion hardware or a processor executing conversion software (paragraphs [0064] and [0076]), and, for the input/output module, the module connected to the first and second communication networks that receives a frame from either network or transmits it (paragraph [0066]).
Therefore, the limitations are construed to cover those structures and their equivalents. The same terms in claims 1 to 6 name the components through which the converting steps of the method are performed and are given the same construction.
Conditional limitations (claims 4, 5, 10 and 11). Claims 4 and 5 recite a step taken if the comparison result shows that the compared frames do not match or match. Under MPEP 2111.04(II) the broadest reasonable interpretation of a method claim reciting a conditional step covers the case in which the condition occurs and the step is performed, and each rejection below shows the prior art performing the step when its condition holds. Claims 10 and 11 recite the corresponding apparatus, whose processor performs the recited operation when the condition holds.
Alternative recitations (claims 3 and 9). Claims 3 and 9 recite that the non-Ethernet frame includes at least one of a CAN frame, a LIN frame and a FlexRay frame. A claim so drafted is satisfied when any one of the recited alternatives is satisfied, and each rejection below states which alternative it rests on.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Rajan (US 2017/0072876 A1) in view of Smith (US 6,937,594 B2).
Regarding claim 1, Rajan discloses: A communication protocol conversion method for detecting communication protocol conversion errors between heterogeneous automobile communication networks, performed by a communication protocol conversion apparatus, the method comprising:, because Rajan teaches an in-vehicle network gateway that connects the heterogeneous networks and buses of a vehicle, such as a CAN bus, a LIN bus, via a FlexRay fault-tolerant automotive communication protocol (i.e., “detecting communication protocol conversion errors between heterogeneous automobile communication networks” as claimed) and an Ethernet network, and translates the protocol of a message received on one of them into the protocol of another, in either direction, with error management in real time, which means that the gateway performs a communication protocol conversion method between heterogeneous automobile communication networks, performed by a communication protocol conversion apparatus: (Rajan, para [0013] “The in-vehicle network gateway described below provides hardware accelerated intercommunication between heterogeneous in-vehicle networks, in any given direction from one bus or network to another, the reverse direction, and more generally from any source in-vehicle bus or network to any destination in-vehicle bus or network”; Rajan, para [0013] “The gateway provides protocol conversion via message translation, message routing between networks, and error management in real time”; Rajan, para [0017] “As just one example, type A may be CAN, type B may be LIN, type C may be FlexRay, and type D may be Ethernet”).
Furthermore, Rajan discloses: converting the received first communication network frame into a second communication network frame through a first conversion module;, as Rajan describes the gateway buffering a CAN message that arrives on its CAN interface and, when the message is routed to the Ethernet interface, looking up a pre-defined Ethernet header for the message in its translation table and having its control circuitry generate an Ethernet packet from that header and the message payload. The translation table and control circuitry that carry out this hardware assisted protocol translation are one conversion unit of the gateway (i.e., “a first conversion module” as claimed), such that the received CAN message, a first communication network frame, is converted into an Ethernet packet, a second communication network frame, through a first conversion module: (Rajan, para [0022] “The in-vehicle network gateway 136 includes one or more instances of buffer circuitry 202 for receiving messages 204 in the form, e.g., of data packets or CAN bus messages, arriving on the automotive network or bus interfaces (302)”; Rajan, para [0027] “when performing hardware assisted protocol translation of a message received on a first network or bus type (e.g., the CAN bus) that the control circuitry 214 decides to send as an outgoing message on a second network or bus type (e.g., the Ethernet network)”; Rajan, para [0040] “the control circuitry 214 also obtains a particular Ethernet header for the particular message through the translation table and generates an Ethernet packet comprising the particular Ethernet header and the data payload of the particular message”).
Although Rajan teaches the gateway also converting in the reverse direction, its CPU passing an Ethernet frame received from the Ethernet switch down the software protocol stack, which converts the frame to the CAN message format for transmission on the CAN bus: (Rajan, para [0051]), Rajan does not explicitly disclose storing a copy of the received frame, inversely converting the converted second communication network frame back into a first communication network frame, comparing the stored copy and the inversely converted first communication network frame, and detecting conversion errors according to a comparison result.
However, Rajan in view of Smith discloses storing a copy of a first communication network frame received; since Smith explains a protocol converting network element that verifies its own conversion by looping the real data it receives from the first protocol to the second and back, and, in a variant of the same check, keeps a packet stored on its first protocol side while a duplicate of that packet makes the round trip through the conversion. The packet the element keeps unconverted while its duplicate is converted is a retained copy of the frame that entered the element (i.e., “a copy of a first communication network frame received” as claimed), whereby a copy of a first communication network frame received is stored (Smith, col. 4, lines 8-10, “real, versus test, data, is periodically selected to be converted between protocols and back to an original protocol for testing the protocol conversion”; Smith, col. 4, lines 10-14, “a predetermined packet is stored on one side (first protocol) of the protocol converting network element and a duplicate of that packet is converted to the second protocol then back to the first protocol”).
Furthermore, Smith discloses inversely converting the converted second communication network frame into a first communication network frame through a second conversion module; in that Smith shows the gateway that converted the received IP/ATM message into an IP message then converting that IP message back into an IP/ATM message, the conversion in the return direction being carried out by the gateway’s own protocol conversion, with the result that the converted second communication network frame is inversely converted into a first communication network frame through a second conversion module (Smith, col. 6, lines 16-20, “when gateway 110 receives the loop back test message, which is originally in an IP/ATM protocol, gateway 110 converts that message to a corresponding message in IP protocol. Then the IP protocol message is converted back to an IP/ATM protocol”; Smith, col. 4, lines 4-7, “a network element that converts from one protocol to another protocol periodically loops data from the first protocol to the second protocol and back to the first protocol in order to verify internally the protocol conversion”).
Moreover, Smith discloses comparing the stored copy of the first communication network frame and the inversely converted first communication network frame; and given that Smith sets out the unconverted first message and the message that went through the conversion and back being compared with each other to determine the accuracy of the protocol conversion, and the results of the element’s internal test being kept for comparison with known acceptable data, so that the stored copy of the first communication network frame is compared with the inversely converted first communication network frame (Smith, col. 6, lines 28-31, “the originator of the loop back test receives the first message (304) and the protocol-converted message (308), and compares those messages to determine the accuracy of the protocol conversion”; Smith, col. 4, lines 16-18, “the results of the test are stored for subsequent examination, including comparison with known acceptable data”).
In addition, Smith discloses detecting conversion errors between the first and second communication network frames according to a comparison result because Smith teaches the comparison telling whether the protocol conversion was accurate, each round trip being counted as a passing or a failing test, and a protocol converter that has run this internal test being used to determine whether there are conversion problems, which means that conversion errors between the first and second communication network frames are detected according to a comparison result (Smith, col. 6, lines 30-31, “compares those messages to determine the accuracy of the protocol conversion”; Smith, col. 4, lines 18-19, “a count of the number of passing and failing tests is kept”; Smith, col. 5, lines 35-38, “any protocol converters, such as gateway 110, which may have conducted internal protocol conversion test, maybe used to determine whether there are problems”; Smith, col. 1, lines 40-43, “a failure in a traditional loop back test in a hybrid network may indicate path integrity problems, protocol conversion problems, or even a quality of service problem”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have Rajan’s gateway verify its own translation in the way Smith’s protocol converters do, by keeping a copy of the received CAN message, passing the translated Ethernet packet back through the gateway’s Ethernet to CAN software protocol stack, comparing the result with the copy and treating a mismatch as a conversion error. Rajan’s gateway sits between every vehicle network it serves and promises error management in real time, yet nothing in Rajan checks whether a header the translation table looked up or a packet the control circuitry assembled came out right; Smith addresses exactly that problem for a protocol converting network element, noting that a conversion problem is otherwise hard to tell from a path problem, and has the converter loop data from the first protocol to the second and back so that the conversion is verified internally. Thus, applying that known technique to Rajan’s gateway is the use of a known technique to improve a similar device in the same way, and it would have yielded no more than the predictable result of a faulty translation being caught at the gateway before the corrupted message reaches an electronic control unit. One of ordinary skill would have had a reasonable expectation of success, since Rajan’s gateway already buffers every received message and already converts in both directions, so the round trip uses conversion paths and storage the gateway has.
Regarding claim 2, which depends on claim 1, Rajan discloses The method of claim 1, wherein, if the first communication network frame is a non-Ethernet frame, then the second communication network frame is an Ethernet frame, and if the first communication network frame is an Ethernet frame, then the second communication network frame is a non-Ethernet frame, as Rajan further discloses the CAN to Ethernet flow, in which a CAN message that arrives at the CAN controller leaves the gateway queued as an Ethernet frame, and the Ethernet to CAN flow, in which an arriving Ethernet frame is converted to the CAN message format, such that if the first communication network frame is a non-Ethernet frame the second communication network frame is an Ethernet frame, and if the first communication network frame is an Ethernet frame the second communication network frame is a non-Ethernet frame (Rajan, para [0047] “FIG. 10 shows a use case 1000 for CAN/LIN/FlexRay to Ethernet message flow. At (1), a CAN message arrives at the CAN controller and is stored in the buffer 822”; Rajan, para [0049] “At (7), the outgoing message is queued as an Ethernet frame in the appropriate queue at the egress port (or ports)”; Rajan, para [0051] “the CPU passes the Ethernet frame down the software protocol stack 604, which converts the Ethernet frame to a CAN message protocol format, and sends the CAN message to the CAN controller for transmission”).
Regarding claim 3, which depends on claim 2, Rajan discloses The method of claim 2, wherein the non-Ethernet frame includes at least one of a CAN (controller area network) frame, a LIN (local interconnect network) frame, and a FlexRay frame, as Rajan further discloses the non-Ethernet buses of the gateway being a CAN bus, a LIN bus and a FlexRay bus, whose transceivers take in the CAN, LIN and FlexRay messages the gateway translates, whereby the non-Ethernet frame includes a CAN frame (Rajan, para [0017] “As just one example, type A may be CAN, type B may be LIN, type C may be FlexRay, and type D may be Ethernet”; Rajan, para [0043] “the bus transceiver circuitry 820 includes CAN bus transceivers, LIN bus transceivers, and FlexRay bus transceivers”).
Claim 3 recites its alternatives joined by at least one of, so the claim is satisfied when any one of them is satisfied. The alternative relied on is the CAN frame, which is the limitation mapped above.
Regarding claim 4, which depends on claim 1, Rajan in view of Smith discloses The method of claim 1, wherein, in the detecting of conversion errors, if the comparison result shows that the stored copy of the first communication network frame and the inversely converted first communication network frame do not match, a conversion error notification is issued, as Smith further discloses the converter keeping a count of the passing and failing round trip tests for a managing device such as a gateway controller to check, and the results of loop back testing being reported to a monitoring system, with the result that when the comparison shows that the frames do not match, a failing test, a conversion error notification is issued (Smith, col. 4, lines 18-21, “a count of the number of passing and failing tests is kept. The pass/fail counts are checked by a managing device, e.g., a gateway controller, or are placed in a loop back test”; Smith, col. 6, lines 48-49, “The results of loop back testing are preferably reported to a monitoring system”).
Consequently, Rajan and Smith are combined for the reasons set forth in the rejection of claim 1 above.
Regarding claim 5, which depends on claim 1, Rajan discloses The method of claim 1, wherein, in the detecting of conversion errors, if the comparison result shows that the stored copy of the first communication network frame and the inversely converted first communication network frame match, the converted second communication network frame is outputted, as Rajan further discloses the control circuitry transmitting the Ethernet packet it generated from the received CAN message out through the Ethernet interface, the packet being scheduled and sent out of the destination port of the Ethernet switch. In the method of claim 1 that transmission follows the round trip check, and a packet whose stored copy and inversely converted frame match is one the gateway sends on, so that if the comparison result shows that the frames match, the converted second communication network frame is outputted (Rajan, para [0040] “The control circuitry 214 transmits the Ethernet packet through the Ethernet protocol automotive network interface”; Rajan, para [0049] “At (8), the outgoing message the Ethernet switch 804 schedules and transmits the outgoing message out of the destination port (or ports)”).
Regarding claim 6, which depends on claim 1, Rajan discloses The method of claim 1, wherein, in the detecting of conversion errors, errors arising when the first conversion module or the second conversion module reassembles control information (PDU; Protocol Data Unit) format of an input frame into control information (PDU) format of an output frame are detected, as Rajan further discloses each message carrying a header, the control information that holds the message identifier, together with a payload, and the gateway’s translation building the outgoing message by appending the payload of the input message to the pre-defined header of the output protocol, so that the conversion module rebuilds the header format of the input frame into the header format of the output frame. Any error the translation introduces is therefore an error arising in that reassembly, and the conversion errors that the detecting step of claim 1 detects are errors of this kind, which means that errors arising when the first conversion module or the second conversion module reassembles control information format of an input frame into control information format of an output frame are detected (Rajan, para [0023] “The messages 204 may vary widely in format per protocol specification, and typically include a message header and a message payload. The message header may include, e.g., a message identifier 206, and the message payload carries the payload data 208”; Rajan, para [0030] “The control circuitry 214 prepares an outgoing message by, e.g., appending the message payload to the pre-defined header (314)”; Rajan, para [0034] “prepares a protocol B message including the pre-defined protocol B header and the message payload”).
Regarding claim 7, Rajan discloses: A communication protocol conversion apparatus for detecting communication protocol conversion errors between heterogeneous automobile communication networks, the apparatus comprising: an input/output module that receives or transmits a communication network frame between the heterogeneous automobile communication networks;, as Rajan describes an in-vehicle network gateway that connects the heterogeneous networks and buses of a vehicle, such as a CAN bus, a LIN bus, a FlexRay bus and an Ethernet network, and translates messages between them in either direction with error management in real time. The gateway has a network or bus interface for each of those networks, with interface circuitry for receiving and transmitting messages over it (i.e., “an input/output module” as claimed), such that the gateway is a communication protocol conversion apparatus with an input/output module that receives or transmits a communication network frame between the heterogeneous automobile communication networks: (Rajan, para [0013] “The in-vehicle network gateway described below provides hardware accelerated intercommunication between heterogeneous in-vehicle networks, in any given direction from one bus or network to another, the reverse direction, and more generally from any source in-vehicle bus or network to any destination in-vehicle bus or network”; Rajan, para [0017] “As just one example, type A may be CAN, type B may be LIN, type C may be FlexRay, and type D may be Ethernet”; Rajan, para [0018] “The in-vehicle network gateway 136 includes a type A network or bus interface 138, a type B network or bus interface 140, a type C network or bus interface 142, a type D network or bus interface 144, and a type E network or bus interface 146”; Rajan, para [0019] “The network and bus interfaces 138-146 include the interface circuitry for unidirectional or bidirectional communications over the corresponding in-vehicle network or bus”).
Furthermore, Rajan discloses: a first conversion module that converts a first communication network frame into a second communication network frame, between the heterogeneous automobile communication networks;, since Rajan explains the gateway translating a message received on the CAN bus for the Ethernet network by looking up a pre-defined Ethernet header for the message in its translation table and having its control circuitry generate an Ethernet packet from that header and the message payload. The translation table and control circuitry that perform this hardware assisted protocol translation are one conversion unit of the gateway (i.e., “a first conversion module” as claimed), whereby a first conversion module converts a first communication network frame, the CAN message, into a second communication network frame, the Ethernet packet, between the heterogeneous automobile communication networks: (Rajan, para [0027] “when performing hardware assisted protocol translation of a message received on a first network or bus type (e.g., the CAN bus) that the control circuitry 214 decides to send as an outgoing message on a second network or bus type (e.g., the Ethernet network)”; Rajan, para [0040] “the control circuitry 214 also obtains a particular Ethernet header for the particular message through the translation table and generates an Ethernet packet comprising the particular Ethernet header and the data payload of the particular message”).
Moreover, Rajan discloses: a second conversion module that converts the second communication network frame into the first communication network frame, between the heterogeneous automobile communication networks;, in that Rajan shows the gateway handling traffic in the opposite direction, from Ethernet to CAN, by having the CPU pass a received Ethernet frame down the software protocol stack, which converts it to the CAN message format for the CAN controller to transmit. That software protocol stack is the gateway’s other conversion unit (i.e., “a second conversion module” as claimed), with the result that a second conversion module converts the second communication network frame, an Ethernet frame, into the first communication network frame, a CAN message, between the heterogeneous automobile communication networks: (Rajan, para [0044] “The in-vehicle network gateway 136 also handles speed mismatches between interfaces, e.g., traffic from Ethernet to CAN”; Rajan, para [0051] “the CPU passes the Ethernet frame down the software protocol stack 604, which converts the Ethernet frame to a CAN message protocol format, and sends the CAN message to the CAN controller for transmission”).
In addition, Rajan discloses: a memory that stores one or more programs; and a processor that executes the one or more stored programs;, given that Rajan sets out the control circuitry of the gateway (See FIG. 6) being coupled to a memory system that stores the software protocol stack and the configuration settings, the control circuitry being a processor that executes software or firmware instructions, and, in the gateway of FIG. 8, CPUs that implement the control circuitry with a RAM that holds the software protocol stack, the translation table and the pre-defined headers, so that the gateway comprises a memory that stores one or more programs and a processor that executes the one or more stored programs: (Rajan, para [0035] “In FIG. 6, the control circuitry 214 is coupled to a memory system 602. The memory system 602 stores a software protocol stack 604 and configuration settings 606 for the in-vehicle network gateway 136”; Rajan, para [0030] “The control circuitry 214 may be implemented entirely in hardware, or as a processor that executes software or firmware instructions to perform the gateway processing”; Rajan, para [0042] “the CPUs 814 may implement all or part of the control circuitry 214 discussed above, while the RAM 816 (alone or in combination with other memory types) may implement the memory system and store the routing table 211, translation table 212, pre-defined headers 218-1-218-n, the software protocol stack 604”).
Furthermore, Rajan discloses: converts the received first communication network frame into the second communication network frame through the first conversion module,, because Rajan teaches the CPU reading a received CAN message, routing it to the Ethernet port by its message identifier, and applying that identifier to the translation table so that the pre-configured Ethernet header it retrieves is prepended to the message payload and the resulting message goes out to the Ethernet switch, which means that the processor converts the received first communication network frame into the second communication network frame through the first conversion module: (Rajan, para [0048] “At (3), the CPU reads the message. At (4), the CPU uses the message identifier to perform a routing function and determine that the message destination in this example is an Ethernet port”; Rajan, para [0048] “at (5) the index value (e.g., the 11-bit hash or received message identifier) is applied to the translation table (e.g., in the RAM 816) to look up the corresponding pre-configured Ethernet header”; Rajan, para [0049] “At (6) the retrieved pre-configured header is pre-pended to the message payload and the resulting outgoing message is sent to the Ethernet switch 804 via the MAC 810”).
Although Rajan teaches the gateway’s CPU converting a received Ethernet frame back into the CAN message format through the software protocol stack, the reverse of its CAN to Ethernet translation: (Rajan, para [0051]), Rajan does not explicitly disclose the processor storing a copy of the received frame, inversely converting the converted second communication network frame back into a first communication network frame, comparing the stored copy and the inversely converted first communication network frame, and detecting conversion errors according to a comparison result.
Nevertheless, Rajan in view of Smith discloses wherein the processor stores a copy of the first communication network frame received through the input/output module, as Smith describes protocol converting network elements that are processor based and execute stored programs, one of which verifies its own conversion by looping the real data it receives from the first protocol to the second and back and, in a variant of the same check, keeps a packet stored on its first protocol side while a duplicate of that packet makes the round trip. The packet the element keeps unconverted while its duplicate is converted is a retained copy of the frame that entered the element (i.e., “a copy of the first communication network frame received” as claimed), such that the processor stores a copy of the first communication network frame received through the input/output module (Smith, col. 3, lines 35-36, “Preferably, the network elements are processor based and execute stored programs”; Smith, col. 4, lines 8-10, “real, versus test, data, is periodically selected to be converted between protocols and back to an original protocol for testing the protocol conversion”; Smith, col. 4, lines 10-14, “a predetermined packet is stored on one side (first protocol) of the protocol converting network element and a duplicate of that packet is converted to the second protocol then back to the first protocol”).
Furthermore, Smith discloses inversely converts the converted second communication network frame into a first communication network frame through the second conversion module, since Smith explains the gateway that converted the received IP/ATM message into an IP message then converting that IP message back into an IP/ATM message, the conversion in the return direction being carried out by the gateway’s own protocol conversion, whereby the processor inversely converts the converted second communication network frame into a first communication network frame through the second conversion module (Smith, col. 6, lines 16-20, “when gateway 110 receives the loop back test message, which is originally in an IP/ATM protocol, gateway 110 converts that message to a corresponding message in IP protocol. Then the IP protocol message is converted back to an IP/ATM protocol”; Smith, col. 4, lines 4-7, “a network element that converts from one protocol to another protocol periodically loops data from the first protocol to the second protocol and back to the first protocol in order to verify internally the protocol conversion”).
Moreover, Smith discloses compares the stored copy of the first communication network frame and the inversely converted first communication network frame, and in that Smith shows the unconverted first message and the message that went through the conversion and back being compared with each other to determine the accuracy of the protocol conversion, and the results of the element’s internal test being kept for comparison with known acceptable data, with the result that the processor compares the stored copy of the first communication network frame and the inversely converted first communication network frame (Smith, col. 6, lines 28-31, “the originator of the loop back test receives the first message (304) and the protocol-converted message (308), and compares those messages to determine the accuracy of the protocol conversion”; Smith, col. 4, lines 16-18, “the results of the test are stored for subsequent examination, including comparison with known acceptable data”).
In addition, Smith discloses detects conversion errors between the first and second communication network frames according to a comparison result given that Smith sets out the comparison telling whether the protocol conversion was accurate, each round trip being counted as a passing or a failing test, and a protocol converter that has run this internal test being used to determine whether there are conversion problems, so that the processor detects conversion errors between the first and second communication network frames according to a comparison result (Smith, col. 6, lines 30-31, “compares those messages to determine the accuracy of the protocol conversion”; Smith, col. 4, lines 18-19, “a count of the number of passing and failing tests is kept”; Smith, col. 5, lines 35-38, “any protocol converters, such as gateway 110, which may have conducted internal protocol conversion test, maybe used to determine whether there are problems”; Smith, col. 1, lines 40-43, “a failure in a traditional loop back test in a hybrid network may indicate path integrity problems, protocol conversion problems, or even a quality of service problem”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to program the CPU of Rajan’s gateway to verify the gateway’s own translation in the way Smith’s protocol converters do, keeping a copy of the received CAN message, passing the translated Ethernet packet back through the software protocol stack that converts Ethernet frames to CAN messages, comparing the result with the copy and treating a mismatch as a conversion error. Rajan’s gateway promises error management in real time for the messages it carries between the vehicle’s networks, yet nothing in Rajan checks whether a header its translation table looked up or a packet its control circuitry assembled came out right; Smith addresses exactly that problem for a protocol converting network element, noting that a conversion problem is otherwise hard to tell from a path problem, and has the converter loop data from the first protocol to the second and back so that the conversion is verified internally. Applying that known technique to Rajan’s gateway is the use of a known technique to improve a similar device in the same way, and it would have yielded no more than the predictable result of a faulty translation being caught at the gateway before the corrupted message reaches an electronic control unit. One of ordinary skill would have had a reasonable expectation of success, since Rajan’s gateway already buffers every received message, already holds its software protocol stack in memory for the CPU to run, and already converts in both directions, so the round trip uses conversion paths and storage the gateway has.
Regarding claim 8, which depends on claim 7, Rajan discloses The apparatus of claim 7, wherein, if the first communication network frame is a non-Ethernet frame, then the second communication network frame is an Ethernet frame, and if the first communication network frame is an Ethernet frame, then the second communication network frame is a non-Ethernet frame, as Rajan further discloses the CAN to Ethernet flow, in which a CAN message that arrives at the CAN controller leaves the gateway queued as an Ethernet frame, and the Ethernet to CAN flow, in which an arriving Ethernet frame is converted to the CAN message format, whereby if the first communication network frame is a non-Ethernet frame the second communication network frame is an Ethernet frame, and if the first communication network frame is an Ethernet frame the second communication network frame is a non-Ethernet frame (Rajan, para [0047] “FIG. 10 shows a use case 1000 for CAN/LIN/FlexRay to Ethernet message flow. At (1), a CAN message arrives at the CAN controller and is stored in the buffer 822”; Rajan, para [0049] “At (7), the outgoing message is queued as an Ethernet frame in the appropriate queue at the egress port (or ports)”; Rajan, para [0051] “the CPU passes the Ethernet frame down the software protocol stack 604, which converts the Ethernet frame to a CAN message protocol format, and sends the CAN message to the CAN controller for transmission”).
Regarding claim 9, which depends on claim 8, Rajan discloses The apparatus of claim 8, wherein the non-Ethernet frame includes at least one of a CAN (controller area network) frame, a LIN (local interconnect network) frame, and a FlexRay frame, as Rajan further discloses the non-Ethernet buses of the gateway being a CAN bus, a LIN bus and a FlexRay bus, whose transceivers take in the CAN, LIN and FlexRay messages the gateway translates, with the result that the non-Ethernet frame includes a CAN frame (Rajan, para [0017] “As just one example, type A may be CAN, type B may be LIN, type C may be FlexRay, and type D may be Ethernet”; Rajan, para [0043] “the bus transceiver circuitry 820 includes CAN bus transceivers, LIN bus transceivers, and FlexRay bus transceivers”).
Claim 9 recites its alternatives joined by at least one of, so the claim is satisfied when any one of them is satisfied. The alternative relied on is the CAN frame, which is the limitation mapped above.
Regarding claim 10, which depends on claim 7, Rajan in view of Smith discloses The apparatus of claim 7, wherein, if the comparison result shows that the stored copy of the first communication network frame and the inversely converted first communication network frame do not match, the processor issues a conversion error notification, as Smith further discloses the converter keeping a count of the passing and failing round trip tests for a managing device such as a gateway controller to check, and the results of loop back testing being reported to a monitoring system, so that when the comparison shows that the frames do not match, a failing test, the processor issues a conversion error notification (Smith, col. 4, lines 18-21, “a count of the number of passing and failing tests is kept. The pass/fail counts are checked by a managing device, e.g., a gateway controller, or are placed in a loop back test”; Smith, col. 6, lines 48-49, “The results of loop back testing are preferably reported to a monitoring system”).
For these reasons, Rajan and Smith are combined for the reasons set forth in the rejection of claim 7 above.
Regarding claim 11, which depends on claim 7, Rajan discloses The apparatus of claim 7, wherein, if the comparison result shows that the stored copy of the first communication network frame and the inversely converted first communication network frame match, the processor outputs the converted second communication network frame, as Rajan further discloses the control circuitry transmitting the Ethernet packet it generated from the received CAN message out through the Ethernet interface, the packet being scheduled and sent out of the destination port of the Ethernet switch. In the apparatus of claim 7 that transmission follows the round trip check, and a packet whose stored copy and inversely converted frame match is one the gateway sends on, which means that if the comparison result shows that the frames match, the processor outputs the converted second communication network frame (Rajan, para [0040] “The control circuitry 214 transmits the Ethernet packet through the Ethernet protocol automotive network interface”; Rajan, para [0049] “At (8), the outgoing message the Ethernet switch 804 schedules and transmits the outgoing message out of the destination port (or ports)”).
Regarding claim 12, which depends on claim 7, Rajan discloses The apparatus of claim 7, wherein the processor detects errors arising when the first conversion module or the second conversion module reassembles control information (PDU; Protocol Data Unit) format of an input frame into control information (PDU) format of an output frame, as Rajan further discloses each message carrying a header, the control information that holds the message identifier, together with a payload, and the gateway’s translation building the outgoing message by appending the payload of the input message to the pre-defined header of the output protocol, so the conversion module rebuilds the header format of the input frame into the header format of the output frame. Any error the translation introduces is therefore an error arising in that reassembly, and the conversion errors that the processor of claim 7 detects are errors of this kind, such that the processor detects errors arising when the first conversion module or the second conversion module reassembles control information format of an input frame into control information format of an output frame (Rajan, para [0023] “The messages 204 may vary widely in format per protocol specification, and typically include a message header and a message payload. The message header may include, e.g., a message identifier 206, and the message payload carries the payload data 208”; Rajan, para [0030] “The control circuitry 214 prepares an outgoing message by, e.g., appending the message payload to the pre-defined header (314)”; Rajan, para [0034] “prepares a protocol B message including the pre-defined protocol B header and the message payload”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 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.
/CHONGSUH PARK/Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
