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 IDS filed on 8 August 2025 was apparently blank and has been initialed (as such) by the examiner.
Drawings
The drawings were received on 11 August 2025. These drawings are accepted by the examiner.
Claim (Specification) Objections
Claim 10 is objected to because of the following informalities: claim 10 is grammatically incorrect, where “comprises” in line 2 should apparently read “comprising”. See MPEP 608.01(m). Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 6, applicant has apparently not described, in sufficient detail, by what algorithm(s)1, or by what steps or procedure, the first network gateway was configurable “to determine a physical location for the source port based on the source ID or source address”. No apparent algorithm(s) for the first gateway to determine a physical location is/are apparently described, in sufficient detail, in the specification. Accordingly, the examiner believes that applicant has not demonstrated, to those skilled in the art, possession of the full scope2 of the claimed invention, but has only (if anything) described a desired result.
In this respect, published paragraph [0039] of the specification indicates:
The PoE network can identify each communication module having a PoE port and also determine a physical location for each communication module. In one example, the PoE network can determine a physical location for each communication module on a row unit of an implement. The PoE network transmits a sequence of messages to each port of each module to determine how each PoE port is configured (e.g., port 1 connected to port 2, port 1 has no connection, etc.). The PoE network also prioritizes communications to be sent between modules.
The examiner believes that determining how each port might be configured (e.g., port 1 connected to port 2, port 1 has no connection, etc.) at paragraph [0039] of the specification is something different from determining a “physical location” of the source port, based on the specification language. Therefore, determining how each port is configured apparently does not constitute the first gateway determining the “physical location” of the source port, e.g., for example because the physical (real-world?) locations of the ports 1 and 2 can be/might be unknown even if it is determined that the ports are connected. Accordingly, the examiner believes that applicant has not demonstrated, to those skilled in the art, possession of the full scope of the claimed invention, but has only (if anything) described a desired result.
Claims 1 to 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 1, line 5, “the agricultural implement” has insufficient antecedent basis, rendering the structure of the claim unclear. For example, antecedent basis for this agricultural implement should be provided e.g., in the preamble. See MPEP 2173.05(e). Subsequent references to “the agricultural implement” (cf. claim 2, line 5, claim 9, line 4, etc.) are also unclear in the claim set.
In claim 1, line 7, “a second PoE network” is grammatically incorrect and unclear, since no first PoE network is recited in the claim.
The dependencies of claims 7 and 15 are apparently incorrect, leaving multiple claim terms without antecedent basis (e.g., “the second communication module”, “the at least two ports”, etc., etc.) and therefore unclear. Moreover, the claims as wholes are indefinite and unclear (e.g., how can a network that is separate from and connects the communication module(s) possibly “transmit” a message to determine a configurable connection for each of the at least two ports of the second communication module?)
In claim 7, line 2, in claim 9, line 1, and in claim 15, lines 2ff, “the second communication module” is unclear with insufficient antecedent basis.
In claim 8, line 4, “received from CAN controllers and sensors” is indefinite (e.g., how can the single header of the single communication, as the claim covers and encompasses, be received from plural CAN controllers and sensors?)
In claim 9, line 2, “the communication system” apparently has insufficient antecedent basis and is unclear.
in claim 9, lines 2ff, “multiple output ports . . . with at least one output port” is indefinite from the teachings of the specification (e.g., output port(s) defined particularly how, outputting what and/or to what particularly, and is/are this/these output port(s) the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from the PoE port(s) of previous claims, is the at least one output port one of the multiple output ports, etc.?)
In claim 9, line 3, “the second network” has insufficient antecedent basis (e.g., is this referring to the second PoE network?) and is unclear.
In claim 10, line 4, “a second power over Ethernet (PoE) network” is grammatically incorrect and unclear, since no first PoE network is recited in the claim.
In claim 10, line 5, “configurable [able to be configured?] with a protocol translator” is indefinite in the claim context and from the teachings of the specification that apparently describes no such configurability.
In claim 14, lines 1ff, “the second network comprises the PoE network” lacks sufficient antecedent basis in two respects and is unclear (and confusing, e.g., for splitting up the “second PoE network” after it was introduced in claim 10).
Claim(s) depending from claims expressly noted above are also rejected under 35 U.S.C. 112 by/for reason of their dependency from a noted claim that is rejected under 35 U.S.C. 112, for the reasons given.
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.
Claims 10, 13 to 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (2017/0072876) in view of Martin (2015/0194039).
Rajan et al. (‘876) reveals:
.per claim 10, a communication system [e.g., FIG. 1], comprising:
a first communication module [e.g., 136] of a machine [e.g., the vehicle] comprises
at least one port[3] of a first network [e.g., the bus interface 138 in FIG. 8 for the CAN bus 126 in FIG. 1],
at least two ports of a second [e.g., the bus interfaces 144, 806, 808 in FIGS. 8, 10 to 12, etc., described as “ports” in FIG. 8, for the Ethernet bus; e.g., paragraphs [0041], [0049] etc.], and
a first network gateway [e.g., the gateway circuitry 802 of the in-vehicle network gateway136 e.g., in FIG. 8] that is configurable with a protocol translator to translate between a first protocol for the first network and a second [e.g., paragraph [0018], “An in-vehicle network gateway 136 provides hardware accelerated protocol translation and intercommunication between the different in-vehicle networks”; with the first and second networks being e.g., CAN and Ethernet in FIGS. 1, 8, etc.], wherein the first protocol is different from the second protocol [e.g., CAN being different from Ethernet at paragraphs [0017], FIG. 8, etc.];
Rajan et al. (‘876) may not expressly reveal that the second (Ethernet) network is a Power over Ethernet network, although the examiner has taken Official Notice in the parent application 17/267,712 that “Power over Ethernet” was a well-known and IEEE standardized (e.g., since 2003 in various implementations) type/implementation of Ethernet network at the time the application was filed. See the Wikipedia article, “Power over Ethernet”, old revision, in support of this Official Notice.
However, in the context/field of an improved system 100 functioning as a connected gateway for vehicles including agricultural vehicles (paragraph [0043]) which acts as a network protocol converter (paragraphs [0002], [0044], [0045], etc.), Martin teaches that in a gateway accommodating e.g., both CAN and Ethernet networks (e.g., paragraphs [0014], [0060], etc.), the “[s]ystem 100 . . . can additionally and/or alternatively be operational using power over Ethernet (POE). As will be appreciated by those of ordinary skill, operating via power over Ethernet eliminates the need for a mains [AC/DC] power outlet being located near system 100.”
It would have been obvious before the effective filing date of the claimed invention to implement or modify the Rajan et al. (‘876) automotive gateway controller system, so that the Ethernet network (e.g., in FIG. 8) would have been implemented as a Power over Ethernet network, as taught by Martin (‘039) and as was a well-known and conventional of Ethernet network taught by Rajan et al. (‘876) by those having ordinary skill in the art, and so that the system 100 (and in particular, the gateway 136 and the gateway circuitry 802) would have been made operational by using the power supplied by the Power over Ethernet (POE) network, as taught by Martin (‘039), in order to eliminate the need for an external power source to be located near system 100 (136), with a reasonable expectation of success, and e.g., as a use of a known technique to improve similar devices (methods, or products) in the same way.
As such, the implemented or modified Rajan et al. (‘876) automotive gateway controller system would have rendered obvious:
per claim 10, a communication system [e.g., in Rajan et al. (‘876), FIG. 1], comprising:
a first communication module [e.g., in Rajan et al. (‘876), 136] of a machine [e.g., in Rajan et al. (‘876), the vehicle] comprises
at least one port of a first network [e.g., in Rajan et al. (‘876), the bus interface 138 in FIG. 8 for the CAN bus 126 in FIG. 1],
at least two ports of a second power over Ethernet (PoE) network [e.g., in Rajan et al. (‘876), the bus interfaces/ports 144, 806, 808 in FIGS. 8, 10 to 12, etc., described (and depicted; MPEP 2125, I.) as “ports” in FIG. 8, for the Ethernet bus; e.g., paragraphs [0041], [0049] etc.; and implementing conventional/standardized Power over Ethernet for powering the gateway system 100 (136), as taught by Martin (‘039)], and
a first network gateway [e.g., in Rajan et al. (‘876), the gateway circuitry 802 of the in-vehicle network gateway136 e.g., in FIG. 8] that is configurable with a protocol translator to translate between a first protocol for the first network and a second PoE protocol [e.g., the conventional/standardized Power over Ethernet as taught at paragraph [0058] by Martin (‘039), for both implementing the Ethernet networking and providing a supply of power for the gateway electronics] for the second PoE network [e.g., in Rajan et al. (‘876), paragraph [0018], “An in-vehicle network gateway 136 provides hardware accelerated protocol translation and intercommunication between the different in-vehicle networks”; with the first and second networks being e.g., CAN and Ethernet in FIGS. 1, 8, etc.; and with the Ethernet network being implemented as a conventional/standardized Power over Ethernet (POE) network as taught by Martin (‘039) for both implementing the Ethernet networking and providing a supply of power for the gateway electronics], wherein the first protocol is different from the second protocol [e.g., in Rajan et al. (‘876), CAN being different from Ethernet (and e.g., POE) at paragraphs [0017], FIG. 8, etc.];
per claim 13, depending from claim 10, wherein the first network comprises a controller area network (CAN) and the at least one port of the first communication module comprises a CAN port [e.g., as taught at 126, 138 by Rajan et al. (‘876)];
per claim 14, depending from claim 10, wherein the second network comprises the PoE network to pass electric power and data on an Ethernet cable [e.g., as taught by the Ethernet network in FIGS. 1, 8, and 10 to 12 of Rajan et al. (‘876), implemented as a conventional/standardized Power over Ethernet network, as taught at paragraph [0058] by Martin (‘039)];
per claim 15, depending from claim 10, wherein the second PoE network transmits a sequence of messages to the at least two ports of the second PoE network of the second communication module to determine a configurable connection for each of the at least two ports of the of the second PoE network [e.g., paragraph [0027] in Rajan et al. (‘876), “For instance, a translation table may be prepared in advance to provide Ethernet network headers for hardware accelerated translation of incoming messages (e.g., from a CAN bus) that are destined for an Ethernet network interface”; see also paragraphs [0029], [0040], [0041], [0044], [0049] to [0053], FIG. 3, etc., “When the pre-defined message headers are Ethernet headers, the pre-defined message headers may include any pre-defined set of header data, including one or more of Ethernet header data (e.g., source MAC address and destination MAC address), IP header data (e.g., source and destination address), and TCP or UDP header data (e.g., source and destination port)”, etc.];
per claim 17, depending from claim 10, wherein the second PoE network supports higher bit rates than bit rates of the first network [e.g., paragraph [0049] in Rajan et al. (‘876), “Note that in the to-Ethernet direction, the Ethernet data rate (e.g., 100 Mbps) is typically much faster than the incoming data rate from CAN, LIN, or FlexRay (e.g., 1 Kbps to 10 Mbps)”, with POE being an implementation of Ethernet as taught by Martin (‘039), and obviously supporting higher/faster bit rates than CAN];
Claims 1, 4 to 7, and 9 to 18 are rejected under 35 U.S.C. 103 as being unpatentable over Schlipf et al. (P.C.T., WO 2017/058616) in view of Sikaria et al. (2018/0062988) and further in view of Sauder et al. (9,717,178).
Schlipf et al. (WPO, ‘616) reveals:
per claim 1, an implement, comprising:
a plurality of row units [e.g., FIG. 2 in Schlipf et al. (WO, ‘616)] configured to perform one or more agricultural operations in an agricultural field; and
a first communication module [e.g., in Schlipf et al. (WO, ‘616), 1250, 1260, 1262] that is associated with at least one row unit of a first group of row units [e.g., FIG. 2 in Schlipf et al. (WO, ‘616); with “group[s]” of row units (such as left and right or all) being obviously defined], the first communication module of the agricultural implement includes at least one port of a first network [e.g., in Schlipf et al. (WO, ‘616), the CAN network and/or ISOBUS (paragraph [0064]) in the implement network 1250, connecting the controllers 1254, sensors 1252, and pump 1256, that obviously/implicitly included port(s) to connect to its processing system (at the communication link 1241 entering/exiting the implement network) and/or its (e.g., Ethernet) network interface] to receive data from at least one of sensors and controllers of the agricultural implement [e.g., obviously from the sensors 1252, controllers 1254, etc., in Schlipf et al. (‘WO, 616)], [e.g., CAN/ISOBUS and e.g., Ethernet (or Bluetooth, etc.), respectively, in Schlipf et al. (WO, ‘616); see e.g., paragraphs [0067], [0069], etc.];
Schlipf et al. (WO, ‘616) may not reveal that protocol was translated in the gateways between the e.g., CAN/ISOBUS networks 1210, 1250 and the e.g., Ethernet, Bluetooth, etc. network interfaces 1215, 1260, for example during wired bi-directional communication (paragraph [0069]) between the implement network 1250 and machine network 1210, although he suggests that the communication may be effected via the (e.g., Ethernet, Bluetooth, etc.) network interfaces (paragraph [0069]), and the examiner understands that one of ordinary skill in the art would have understood that conversion between two different network protocols would have been necessary to communicate the data using (and between) the two networks, even without further teaching.
Schlipf et al. (WO, ‘616) also does not expressly reveal details relating to a power over Ethernet (PoE) for the network interface (1215, 1260) between the machine 1202 and the implement(s) 1240, although he teaches that the interface “can include at least one of a GPS transceiver, a WLAN transceiver (e.g., WiFi), an infrared transceiver, a Bluetooth transceiver, Ethernet, or other interfaces from communications with other devices and systems including the implement 1240” (paragraph [0057]), and with the examiner having taken Official Notice in the parent application 17/267,712, and now taking Official Notice again, that “Power over Ethernet” was a well-known and IEEE standardized (e.g., since 2003) type/implementation of Ethernet network at the time the application was filed. See the Wikipedia article, “Power over Ethernet”, old revision, in support of this Official Notice.
However, in the context/field of communication of a vehicle using different types of networks (e.g., Ethernet and CAN) that avoids a burdensome number of wires and is not limited by the bandwidth of a (single) CAN bus, Sikaria et al. (‘988) teaches in conjunction with FIGS. 1 to 7 that CAN messages in the vehicle may be sent from one subsystem to another (i.e., that employ different CAN buses in different CAN domains) by employing ECU gateways (e.g., 220 in FIG. 2, which may themselves be CAN nodes of FIG. 1 or NICs of FIG. 3) to package each CAN message in an Ethernet frame (which includes a source port and a destination port 432, 434) and transmit the frame (i.e., from the source port to the destination port), using an Ethernet connection and Ethernet communication, between respective ECU gateways associated with each CAN domain, such that relevant CAN messages sent from one domain will be extracted by the ECU gateway (NIC) at the domain of the destination CAN device, wherein the Ethernet communication is expandable to connect a number of ECU gateways (FIG. 2, “● ● ●”), and the Ethernet frame includes both a source address 416 and a destination address 414 (of a destination CAN device) for the CAN message.
Moreover, in the context/field of communication systems for planting crops, Sauder et al. (‘178) teaches (in combination with FIG. 3) that a power over Ethernet (PoE) injector4 368 may be used in combination with an Ethernet communication link (386) between a first module 322 and an extension module 380 of a system for monitoring and controlling agricultural implements so that “both data and power connections [can be provided] in one cable such that devices and components do not need require two cables for data and power” (column 10, lines 7ff).
It would have been obvious before the effective filing date of the claimed invention to implement or modify the Schlipf et al. (WO, ‘616) agricultural system and implement so that the machine and implement networks 1210, 1250 and their respective network interfaces (1215, 1260) of the machine and implement subsystems would have been each predictably implemented as e.g., a CAN domain provided with an ECU gateway (e.g., 220a, 220b in Sikaria et al. (‘988), with the ECU gateways A, B, and C having CAN ports as implicitly shown at/below 220a, 220b, 220c in FIG. 2 of Sikaria et al. (‘988)) that would communicate (e.g., with each other) over Ethernet, etc. connection(s) that obviously connected Ethernet ports in the ECU gateway(s) (as desired by Schlipf et al. (WO, ‘616) at 1215, 1260, in FIG. 12; see also 1204) with an expandable number of other such ECU gateways (e.g., for example, including an ECU gateway such as taught at 220d, etc. by Sikaria et al. (‘988) for communicating with cloud computing systems provided outside the vehicle, etc., as specifically desired by Schlipf et al. (WO, ‘616) at paragraphs [0031], [0032], etc., or an ECU gateway such as taught at 220c, etc. by Sikaria et al., (‘988) for obviously communicating with other devices/systems, as specifically suggested by Schlipf et al. (WO, ‘616)), provided in the vehicle/agricultural system/implement, as taught by Sikaria et al. (‘988) in FIG. 2 and as sketched (for example only) by the examiner (e.g., in the footnote below/on the next page5), and so that the ECU gateways (e.g., 220a, 220b) taught by Sikaria et al. (‘988) would have been predictably operative i) to package each CAN message to be transmitted (to other CAN domains, e.g., from 1210 to 1250, from 1250 to 1210, etc. in Schlipf et al. (WO, ‘616)) in an Ethernet frame, and to extract (from such Ethernet frames) each CAN message to be received (from other CAN domains), in accordance with source/destination addresses in the frames, as taught by Sikaria et al. (‘988), and ii) to communicate with other gateways (e.g., for example, 220d, etc. in Sikaria et al. (‘988)) that could communicate with cloud computing systems outside the vehicle or with other devices/systems, as taught by Sikaria et al. (‘988) and as desired/suggested by Schlipf et al. (WO, ‘616)), in order that the machine and implement networks 1210, 1250, and any other obvious networks on the vehicle/system/implement (e.g., a network for display devices 1225, 1230 and/or for a cab control module 1270), would have been connected for communication (e.g., of CAN messages/data, etc.) through the Ethernet connection(s), as suggested by Schlipf et al. (WO, ‘616) himself and as taught by Sikaria et al. (‘988), in order that the connections between the subsystems would not have been limited by the bandwidth of a CAN bus, in order that a large number of burdensome wires for simple communication across multiple subsystems could be avoided in the vehicle/system, in order that cloud communication outside the vehicle would have been provided for in the manner taught by Sikaria et al. (‘988), with a reasonable expectation of success, and e.g., as a use of a known technique to improve similar devices (methods, or products) in the same way.
Moreover, it would have been obvious before the effective filing date of the claimed invention to implement or further modify the Schlipf et al. (WO, ‘616) agricultural system and implement so that the network interface (1215, 1260) between the machine and implement would have been predictably implemented as a Power over Ethernet (PoE) connection (e.g., instead of the Ethernet connection suggested by Schlipf et al (WO, ‘616) himself, and following his own teaching of using “other interfaces”), as taught by Sauder et al. (‘178), as a well-known and conventional (IEEE standardized) Ethernet network interface, in order that both data and power connections could be provided in one cable such that devices and components do not need require two cables for data and power, as taught by Sauder et al. (‘178), and in view of the Official Notice taken, with a reasonable expectation of success, as substituting equivalent network communication schemes (e.g., Ethernet, PoE) for the same purpose (communication) per MPEP 2144.06, II., and e.g., as a use of a known technique to improve similar devices (methods, or products) in the same way.
As such, the implemented or modified Schlipf et al. (WO, ‘616) agricultural system and implement would have rendered obvious:
per claim 1, an implement, comprising:
a plurality of row units [e.g., FIG. 2 in Schlipf et al. (WO, ‘616)] configured to perform one or more agricultural operations in an agricultural field; and
a first communication module [e.g., in Schlipf et al. (WO, ‘616), 1250, 1260, 1262] that is associated with at least one row unit of a first group of row units [e.g., FIG. 2 in Schlipf et al. (WO, ‘616)], the first communication module of the agricultural implement includes at least one port of a first network [e.g., in Schlipf et al. (WO, ‘616), the CAN network and/or ISOBUS (paragraph [0064]) in the implement network 1250, connecting the controllers 1254, sensors 1252, and pump 1256, that obviously/implicitly included port(s) to connect to its processing system (at the communication link 1241 entering/exiting the implement network) and/or its (e.g., Ethernet) network interface] to receive data from at least one of sensors and controllers of the agricultural implement [e.g., obviously from the sensors 1252, controllers 1254, etc., in Schlipf et al. (‘WO, 616)], at least one power over Ethernet (PoE) port of a second PoE network [e.g., the Ethernet network (having implicit ports) as taught by Schlipf et al. (WO, ‘616) and obviously having its port(s) arranged e.g., in the manner taught by Sikaria et al. (‘988) (as described/depicted above, e.g., for transmitting CAN messages via Ethernet communication) and with the Ethernet network in Schlipf et al. (WO, ‘616) further being obviously implemented as a conventional/standardized Power over Ethernet network as taught by Sauder et al. (‘178) for supplying power], and a first gateway to translate between a first protocol for the first network and a second PoE protocol for the second PoE network [e.g., the ECU gateways (or NICs), as taught by Sikaria et al. (‘988), such as the ECU Gateway A in FIG. 2, e.g., used for the implement network 1250 in Schlipf et al. (WO, ‘616), for packaging CAN messages from the implement network 1250 and transmitting them via Ethernet communication of the network interface 1260, e.g., to the machine network 1210], wherein the first protocol is different from the second protocol [e.g., CAN/ISOBUS and e.g., Ethernet (obviously including PoE as taught in Sauder et al. (‘178)), respectively, in Schlipf et al. (WO, ‘616), are different; see e.g., paragraphs [0067], [0069], etc.];
per claim 4, depending from claim 1, wherein the first network comprises a controller area network (CAN) [e.g., as taught by Schlipf et al. (WO, ‘616) and Sikaria et al. (‘988)];
per claim 5, depending from claim 1, wherein the second PoE network is capable of passing electric power and data on an Ethernet cable [e.g., as taught (for PoE) at column 9, line 67 to column 10, line 9 of Sauder et al. (‘178); and the Ethernet cable as would have been obvious for providing the Ethernet network in Schlipf et al. (WO, ‘616)]];
per claim 6, depending from claim 1, wherein the first network gateway is configurable to receive a communication, to inspect header information from a packet of the communication, to determine a source port that sent this communication based on source identification (ID) or source address of the header information, and to determine a physical location of the source port based on the source ID or source address [e.g., as taught in conjunction with FIG. 4 in Sikaria et al. (‘988), with 412 – 418 of the Ethernet frame being located ahead (as a header) of the data 420 and including the destination address 414 and the source address 416, with addresses being the MAC address (ID) of the device sending the message, which is obviously indicative of a physical location (see FIG. 3) on the (Ethernet) network; and thus a physical location of the implement/row units and CMUs 220 – 227 in FIGS. 2 and 12 of Schlipf et al. (WO, ‘616)];
per claim 7, depending from claim 1, wherein the second PoE network transmits a sequence of messages to the at least two ports of the second communication module to determine a configurable connection for each of the at least two ports of the second communication module [e.g., as taught at column 9, line 67 to column 10, line 9 of Sauder et al. (‘178), as obviously implemented with standard Ethernet protocols and information, e.g., using the Ethernet frame having the source and destination addresses (414, 416), as taught and described in conjunction with FIG. 4 of Sikaria et al. (‘988)];
per claim 9, depending from claim 1, wherein the second communication module is configurable to expand a network architecture of the communication system by having multiple output ports of the second network [e.g., when the “second communication module” (e.g., 1210, 1215, 1220) in Schlipf et al. (WO, ‘616) would have obviously been arranged to communicate (e.g., via Ethernet) with multiple other ECU gateways (e.g., for example, of multiple CAN domains of the implement) as shown in FIG. 2 of Sikaria et al. (‘988) and in the examiner’s sketch above merging Schlipf et al. (WO, ‘616) and Sikaria et al. (‘988), with duplication of parts being obvious to those skilled in the art (MPEP 2144.04, VI., B.)] with at least one output port [e.g., for communicating (by Ethernet) with other gateways or the cloud, in FIG. 2 of Sikaria et al. (‘988)] being communicatively coupling to at least one additional communication module of the agricultural implement [e.g., obviously the ECU Gateway D (for cloud communication) or another expanded/additional gateway (FIG. 2, “● ● ●”) for another CAN network in FIG. 2 of Sikaria et al. (‘988), with the additional gateway(s) being obviously located as part of the implement (paragraph [0065]) in Schlipf et al. (WO, ‘616) as a mere/obvious design choice with e.g., no unexpected results (MPEP 2144.04, VI., B. and C.)];
per claim 10, a communication system, comprising:
a first communication module[6] [e.g., 1210, 1215, 1220 in Schlipf et al. (WO, ‘616)] of a machine [e.g., the machine 1202 e.g., tractor, combine harvester, etc., in Schlipf et al. (WO, ‘616)] comprises
at least one port of a first network [e.g., in Schlipf et al. (WO, ‘616), the CAN network and/or ISOBUS (paragraph [0057]) in the machine network 1210, connecting the controllers 1211 and sensors 1212, that obviously/implicitly included port(s) to connect to its processing system (at the communication link 1231 entering/exiting the machine network) and/or its (e.g., Ethernet) network interface],
at least two ports of a second power over Ethernet (PoE) network [e.g., in Schlipf et al. (WO, ‘616), for the Ethernet, etc. in the network interface 1215 that communicates bi-directionally (e.g., input and output, using obvious ports) with “other systems or devices including the implement 1240” (paragraph [0057]), obviously by means of two Ethernet ports, where the network interface 1215 may be “integrated with the machine network 1210” (paragraph [0057]]); see also paragraph [0069], where the implement 1240 communicates with the machine via wired (and possibly also wireless) bi-directional communications 1204 e.g., either directly or “via the [e.g., Ethernet] networks interfaces 1215 and 1260”; in Sikaria et al. ('988), for the plural (e.g., two) Ethernet connections provided at each ECU Gateway in FIG. 2 or NIC in FIG. 3, such as the ECU Gateway B sketched above by the examiner, with a port being where the Ethernet (network/connection) is connected to the ECU Gateway/NIC and/or where data enters/exits the Ethernet connection(s) from/to the gateway(s) (e.g., for example, as a source port 432, a destination port 434, etc. as taught by Sikaria et al. (‘988)); and including the PoE injector 386 used in FIG. 3 of Sauder et al. (‘178) for communication (and power supply) between the modules, such that “PoE provides both data and power connections in one cable such that devices and components do not need require two cables for data and power” (column 10, lines 7ff)], and
a first network gateway that is configurable with a protocol translator to translate between a first protocol for the first network and a second PoE protocol for the second PoE network [e.g., obviously implemented as taught by the ECU gateways 220a-d, the NICs 312-318, etc. in Sikaria et al. (‘988), such as by the ECU Gateway B in FIG. 2, e.g., to be used for the machine network 1210 in Schlipf et al. (WO, ‘616), e.g., for packaging CAN messages from the machine network 1210 and transmitting them via Ethernet communication of the network interface 1215, that obviously implemented PoE as taught by Sauder et al. (‘178), and for communicating with cloud computing systems via the ECU Gateway D, as desired by Schlipf et al. (WO, ‘616), etc.], wherein the first protocol is different from the second protocol [e.g., CAN/ISOBUS and e.g., Ethernet (obviously including PoE as taught in Sauder et al. (‘178)), respectively, in Schlipf et al. (WO, ‘616), are different; see e.g., paragraphs [0067], [0069], etc.];
per claim 11, depending from claim 10, further comprising:
a second communication module [e.g., 1250, 1260, 1262, etc. in Schlipf et al. (WO, ‘616)] of an agricultural implement [e.g., 1240 in Schlipf et al. (WO, ‘616)] is communicatively coupled to the first communication module of the machine [e.g., in Schlipf et al. (WO, ‘616), via the network interfaces 1260, 1215; and as indicated at 1204], wherein the second communication module includes an input port connected to the first communication module [e.g., in Schlipf et al. (WO, ‘616), obviously as part of the wired and possibly also wireless bi-directional communications 1204, and/or over the (obviously bi-directional) Ethernet connection suggested by Schlipf et al. (WO, ‘616) and taught by Sikaria et al. (‘988)], at least one port of the first network [e.g., in Schlipf et al. (WO, ‘616), the CAN network and/or ISOBUS (paragraph [0064]) in the implement network 1250, connecting the controllers 1254, sensors 1252, and pump 1256, that obviously/implicitly included port(s) to connect to its processing system (at the communication link 1241 entering/exiting the implement network) and/or its (e.g., Ethernet) network interface], at least two ports of the second PoE network [e.g., in Sikaria, for the plural (e.g., two) Ethernet connections provided at each ECU Gateway in FIG. 2 or NIC in FIG. 3, such as the ECU Gateway A sketched above by the examiner, with a port being where the Ethernet (network/connection) is connected to the ECU Gateway/NIC and/or where data enters/exits the Ethernet connection(s) from/to the gateway(s) (e.g., for example, as a source port 432, a destination port 434, etc. as taught by Sikaria et al. (‘988)); and in Schlipf et al. (WO, ‘616), for the Ethernet, etc. in the network interface 1260 that communicates bi-directionally (e.g., input and output[7], using obvious ports) in accordance with communications with “other devices and systems including the machine 1202” (paragraph [0067]), obviously by means of two Ethernet ports, where the network interface 1260 may be “integrated with the implement network 1250” (paragraph [0067]]); see also paragraph [0069], where the implement 1240 communicates with the machine via wired (and possibly also wireless) bi-directional communications 1204 e.g., either directly or “via the [e.g., Ethernet] networks interfaces 1215 and 1260”; and including (for the Ethernet network/connection) the PoE injector 386 used in FIG. 3 of Sauder et al. (‘178) for communication (and power supply) between the modules, such that “PoE provides both data and power connections in one cable such that devices and components do not need require two cables for data and power” (column 10, lines 7ff)], and a second network gateway that is configurable to translate between the first protocol for the first network and the second PoE protocol for the second PoE network [e.g., the ECU gateways, etc., such as the ECU Gateway A in FIG. 2, as taught by Sikaria et al. (‘988), e.g., to be used for the implement network 1250 in Schlipf et al. (WO, ‘616), e.g., for packaging CAN messages from the implement network 1250 and transmitting them via Ethernet communication of the network interface 1260, and for communicating with cloud computing systems via the ECU Gateway D, as desired by Schlipf et al. (WO, ‘616), etc.] with the second communication module [e.g., including an ECU gateway disposed on an Ethernet connection and connected to a CAN domain (such as 1250 in Schlipf et al. (‘616)), as taught in FIG. 2 of Sikaria et al. (‘988)] being configurable to expand a network architecture of the communication system [e.g., to connect to any other ECU gateways as may have obviously been provided in modified Schlipf et al. (WO, ‘616), as taught in FIG. 2 of Sikaria et al. (‘988), e.g., to communicate with cloud computing system (via the gateway 220d), to connect (e.g., via 220c, etc. in Sikaria et al. (‘988)) with other devices such as display devices, cab control module, etc., as desired by Schlipf et al. (WO, ‘616), etc.] by communicatively coupling to at least one additional communication module [e.g., with this capability being suggested in FIG. 2 of Sikaria et al. (‘988), (e.g., “● ● ●”) e.g., by the multiple (ECU) gateways including e.g., 220c, 220d, etc., and being obvious in a system using (obviously expandable) Ethernet (or CAN) connections] of the agricultural implement [e.g., obviously the ECU Gateway D (for cloud communication) or another expanded/additional gateway (FIG. 2, “● ● ●”) for another CAN network in FIG. 2 of Sikaria et al. (‘988), with the additional gateway(s) being obviously located as part of the implement (paragraph [0065]) in Schlipf et al. (WO, ‘616) as a mere/obvious design choice with e.g., no unexpected results (MPEP 2144.04, VI., B. and C.)];
per claim 12, depending from claim 11, wherein the second communication module includes the at least one port of the first network [e.g., obvious input/output/CAN/ISOBUS ports of the implement network 1250 in Schlipf et al. (WO, ‘616)] to receive data from at least one of sensors and controllers of the agricultural implement [e.g., obviously from the sensors 1252, controllers 1254, etc., in Schlipf et al. (‘WO, 616), for communication in and/or bi-directional communication between the networks 1210, 1250];
per claim 13, depending from claim 10, wherein the first network comprises a controller area network (CAN) and the at least one port of the first communication module comprises a CAN port [e.g., as taught by Schlipf et al. (WO, ‘616) e.g., at paragraph [0057]; and as taught by Sikaria et al. (‘988), with the CAN port being an obvious/implicit in a CAN network, e.g., for connecting sensors, controllers, etc.];
per claim 14, depending from claim 10, wherein the second network comprises the PoE network to pass electric power and data on an Ethernet cable [e.g., the PoE injector 386 used in FIG. 3 of Sauder et al. (‘178) for power supply between the Ethernet-connected modules, such that “PoE provides both data and power connections in one cable such that devices and components do not need require two cables for data and power” (column 10, lines 7ff); and the Ethernet cable as would have been obvious for providing the Ethernet network in Schlipf et al. (WO, ‘616)]];
per claim 15, depending from claim 10, wherein the second PoE network transmits a sequence of messages to the at least two ports of the second PoE network of the second communication module to determine a configurable connection for each of the at least two ports of the of the second PoE network [e.g., as taught at column 9, line 67 to column 10, line 9 of Sauder et al. (‘178), as obviously implemented with standard Ethernet protocols and information, e.g., using the Ethernet frame having the source and destination addresses (414, 416), as taught and described in conjunction with FIG. 4 of Sikaria et al. (‘988)];
per claim 16, depending from claim 11, wherein the second communication module receives power from an upstream module having PoE or has a separate power supply [e.g., as would have been obvious in the communication systems of both Schlipf et al. (WO, ‘616) and Sikaria et al. (‘988), for each electronic component to have access to its own source of power (separate power supply) for proper operation; and/or as taught by the PoE injector (368) in Sauder et al. (‘178), as described above];
per claim 17, depending from claim 10, wherein the second PoE network supports higher bit rates than bit rates of the first network [e.g., as would have been obvious to one of ordinary skill in the art, with even high speed CAN being limited to 1 Mbit/s and power over Ethernet being well-known to be significantly higher (10 Mbit/s, 100 Mbit/s, or Gigabit and faster8)];
per claim 18, depending from claim 11, wherein the first communication module is located on the machine and the second communication module is located on the agricultural implement [e.g., as taught and described with respect to FIG. 12 in Schlipf et al. (WO, ‘616); cf. paragraphs [0058], “The machine 1202 includes a processing system 1220, memory 1205, machine network 1210 (e.g., a controller area network (CAN) serial bus protocol network, an ISOBUS network, etc.), and a network interface 1215 for communicating with other systems or devices including the implement 1240” and [0065], “The implement 1240 (e.g., planter, cultivator, plough, sprayer, spreader, irrigation implement, etc.) includes an implement network 1250, a processing system 1262, a network interface 1260, and optional input/output ports 1266 for communicating with other systems or devices including the machine 1202”], wherein the machine is a tractor or a combine harvester [e.g., a tractor, combine harvester, etc. at paragraph [0058] in Schlipf et al. (WO, ‘616)];
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 to 5 and 7 to 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 to 20 of U.S. Patent No. 12,342,745 to Allgaier et al. (reference patent). Although the claims at issue are not identical, they are not patentably distinct from each other because all of the limitations claimed in the instant application have already been claimed in the reference patent with only slight but obvious (to those having ordinary skill in the art, e.g., that header information includes metadata and a network packet includes payload data, as was well-known and conventional) differences in wording, with the claim limitations in the instant application corresponding to the patented claim limitations as in the following claim correspondence table:
Claims in Instant application 19/227,633 to Allgaier et al.
Corresponding Claims in U.S. Patent 12,342,745 to Allgaier et al. (reference patent)
1
12
2
12
3
12, 14
4
12, 19
5
12, 20
--
--
7
12, 16
8
12, 19
9
1, 11, 12
10
1
11
1
12
1, 2
13
1, 8
14
1, 3
15
1, 5
16
1, 7
17
1, 6
18
1, 9
Claims 1 to 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 to 20 of copending Application No. 19/279,188 to Allgaier et al. (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because all of the limitations claimed in the instant application are also currently claimed in the reference application with only slight but obvious (to those having ordinary skill in the art, where e.g., network communications obviously include payload data, as was well-known and conventional, and where conventional Ethernet [including PoE] bit rates are well-known to be higher than conventional CAN bit rates) differences in wording, with the claim limitations in the instant application corresponding to the reference application claim limitations as in the following claim correspondence table:
Claims in Instant application 19/227,633 to Allgaier et al.
Corresponding Claims in U.S. Patent Application 19/279,188 to Allgaier et al. (reference application)
1
12, 16
2
12, 16
3
12, 14, 16
4
12, 15, 16
5
12, 16
6
12, 16, 17
7
12, 16, 18
8
12, 16, 17
9
12, 16, 1, 11
10
1, 2, 4
11
1, 2, 4
12
1, 2, 4
13
1, 2, 3, 4
14
1, 2, 4
15
1, 2, 4, 6
16
1, 2, 4, 7
17
1, 2, 3, 4
18
1, 2, 4, 9
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David A Testardi whose telephone number is (571)270-3528. The examiner can normally be reached Monday, Tuesday, Thursday, 8:30am - 5:30pm E.T., and Friday, 8:30 am - 12:30 pm E.T.
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, Rachid Bendidi can be reached at (571) 272-4896. 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.
/DAVID A TESTARDI/Primary Examiner, Art Unit 3664
1 See the 2019 35 U.S.C. 112 Compliance Federal Register Notice (Federal Register, Vol. 84, No. 4, Monday, January 7, 2019, pages 57 to 63). See also https://www.uspto.gov/sites/default/files/documents/2019_112_guidance_initiative.pptx . Quoting the FR Notice at pages 61 and 62, "The Federal Circuit emphasized that ‘‘[t]he written description requirement is not met if the specification merely describes a ‘desired result.’ ’’ Vasudevan, 782 F.3d at 682 (quoting Ariad, 598 F.3d at 1349). . . . When examining computer-implemented, software-related claims, examiners should determine whether the specification discloses the computer and the algorithm(s) that achieve the claimed function in sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as 'a finite sequence of steps for solving a logical or mathematical problem or performing a task.' Microsoft Computer Dictionary (5th ed., 2002). Applicant may 'express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure.' Finisar, 523 F.3d at 1340 (internal citation omitted). It is not enough that one skilled in the art could theoretically write a program to achieve the claimed function, rather the specification itself must explain how the claimed function is achieved to demonstrate that the applicant had possession of it. See, e.g., Vasudevan, 782 F.3d at 682–83. If the specification does not provide a disclosure of the computer and algorithm(s) in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention that achieves the claimed result, a rejection under 35 U.S.C. 112(a) for lack of written description must be made. See MPEP § 2161.01, subsection I."
2 See MPEP 2161.01, I. and LizardTech Inc. v. Earth Resource Mapping Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005) cited therein ("Whether the flaw in the specification is regarded as a failure to demonstrate that the applicant possessed the full scope of the invention recited in [the claim] or a failure to enable the full breadth of that claim, the specification provides inadequate support for the claim under [§ 112(a)]"). See also MPEP 2163.02.
3 port 3 (pôrt) n.
. . .
4.
a. An entrance to or exit from a data network.
b. A connection point for a peripheral device.
. . .
[From: American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2016 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved. Retrieved 8 May 2024.]
4 As is well-known, a PoE injector is a device that adds power to an Ethernet cable for Power over Ethernet (PoE) equipment.
5 The CAN/ISOBUS network in Schlipf et al. (WO, '616) would have obviously had at least one port, and the Ethernet networks (e.g., at/connecting the network interfaces) in Sikaria et al. ('988) would have obviously had at least two ports, with implicit/obvious example port locations/presence/functionality (that would have been obvious to those skilled in the art) e.g., for data entering and leaving the respective networks (1210, 1250) and/or Ethernet gateways (220a, 220b) being indicated by the examiner as large black circles (e.g., larger than “●”) added in sketch below/on the next page which was made (by the examiner) by merging respective FIGS. from Schlipf et al. (WO, ‘616) and Sikaria et al. (‘988), in the manner already set forth, and with examples of the “first communication module” and “the second communication module” (e.g., for the first claim set) shown by ovals marked (by the examiner) with the numerals “1” and “2”, respectively:
PNG
media_image1.png
1203
1095
media_image1.png
Greyscale
6 Here, the examiner merely notes that applicant has changed, in this claim set, the “first communication module” from being part of the “implement” to being “of the machine”. Accordingly, the examiner maps the first communication module, the second communication module, etc. differently in this claim set than in the previous claim set, as shown (for example) by the examiner in the sketch below/on the next page by ovals marked (by the examiner) with the numerals “1” and “2”, respectively:
PNG
media_image2.png
1203
1095
media_image2.png
Greyscale
7 Applicant’s original claims, which provide support for the “two ports” limitation, claimed “at least one input port and at least one output port”.
8 See the Wikipedia articles, CAN bus, old revision, and Power over Ethernet , old revision, in support of this assertion.
Prosecution Insights