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 .
Specification
The disclosure is objected to because of the following informalities: i) the element “453” seen in FIG. 4 is apparently not mentioned in the specification (see 37 CFR 1.84(p)(5)); and ii) at published paragraph [0020], “header 180” is apparently incorrect, since 180 (in this specification) apparently refers to the communication module(s) .
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.
Claims 10 and 17 to 20 are 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 claims 10 and 17, 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 8, 13, 14, and 17 to 20 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 8, line 4, “at least two Ethernet ports of the Ethernet network” is indefinite (in the context of the second communication module) because “at least two Ethernet ports of the Ethernet network” has already been recited in line 10 of claim 1, and it is therefore unclear and not reasonably certain3 whether the at least two Ethernet ports recited in claim 8 are the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc., the at least two Ethernet ports already recited in claim 1.
In claim 13, line 4, “at least two Ethernet ports of the Ethernet network” is indefinite (in the context of the second communication module) because “at least two Ethernet ports of the Ethernet network” has already been recited in lines 12ff of claim 12, and it is therefore unclear and not reasonably certain whether the at least two Ethernet ports recited in claim 13 are the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc., the at least two Ethernet ports already recited in claim 12.
In claim 13, lines 4ff, “a second network gateway . . . ” is indefinite (in the context of the second communication module) because “a second network gateway . . .” has already been recited in line 13 of claim 12, and it is therefore unclear and not reasonably certain whether the second network gateway recited in claim 13 are the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc. the second network gateway already recited in claim 12.
In claim 20, lines 3ff, “at least two Ethernet ports of the Ethernet network” is indefinite (in the context of the first communication module) because “at least two Ethernet ports of the Ethernet network” has already been recited in line 6 of claim 12, and it is therefore unclear and not reasonably certain whether the at least two Ethernet ports recited in claim 20 are the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc., the at least two Ethernet ports already recited in claim 12.
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 1 to 3 and 8 to 11 are rejected under 35 U.S.C. 103 as being unpatentable over Schlipf et al. (P.C.T., WO 2017/0058616) in view of Sikaria et al. (2018/0062988) and Taylor et al. (2018/0116102).
Schlipf et al. (WO, ‘616) reveals:
per claim 1, a communication system, comprising:
a first communication module [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)] includes at least one port of a 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 Ethernet ports of an Ethernet 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”], and [e.g., CAN/ISOBUS and e.g., Ethernet, respectively, in Schlipf et al. (WO, ‘616), have different protocols; see e.g., paragraphs [0067], [0069], etc.]; and
a second communication module [e.g., in Schlipf et al. (WO, ‘616), 1250, 1260, 1262] of a first row unit of an agricultural implement [e.g., FIG. 2 in Schlipf et al. (WO, ‘616); with “group[s]” of row units (such as left or right or all) being obviously defined] 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], 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)], at least one port of the 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 Ethernet ports of the Ethernet network [in Schlipf et al. (WO, ‘616), for the Ethernet, etc. in the network interface 1260 that communicates bi-directionally (e.g., input and output[4], 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 [e.g., paragraph [0067] in Schlipf et al. (WO, ‘616), “The network interface 1260 can be 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 machine 1202. The network interface 1 260 may be integrated with the implement network 1250 or separate from the implement network 1250 as illustrated in Figure 12.”]
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, 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, 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 may not reveal the additional communication module of the second row unit.
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 improved agricultural electronics for communicating data via Ethernet between a tractor/tow vehicle 44 and intelligent implement nodes (IPN) 58 of an agricultural implement, Taylor et al. (‘102) teaches in conjunction with FIGS. 3, 4, and 8 to 10 that the intelligent implement nodes (e.g., IPNs) 58 may be associated with respective row units 40 of the planter implement (paragraph [0061]), wherein each of the intelligent implement nodes (IPNs) 58 includes multiple Ethernet and CAN ports 104, 105 (see e.g., FIGS. 8 to 10), wherein the IPNs 58 transmit information/data between each other, the intelligent implement router (IPR) 56, and the intelligent router 54 of the tractor, etc., e.g., via the Ethernet connections 62, 63, 64 as shown in FIG. 3, in order to program locations and control functions of the implement components (paragraphs [0064], [0065], etc.), to display implement information on the (interactive) display 52, and to provide control and data communication for sensors, motors, cameras, lights, actuators, fans, and any other device linked to the implement network (paragraph [0011]).
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 for example only as sketched by the examiner herein below, 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 modify the Schlipf et al. (WO, ‘616) agricultural system and implement so that individual row units (e.g., 210 to 217) in Schlipf et al. (WO, ‘616) would have been (e.g., additionally or alternately) provided, as appropriate, with its/their own intelligent (programmed with location) implement nodes (IPN) 58 and CAN implement network, as taught in conjunction with the row units 40 in FIGS. 1 and 3 by Taylor et al. (‘102), in such a manner that the intelligent implement nodes (IPN) 58 would have connected the devices of the CAN implement networks to the Ethernet connection from the tractor (paragraph [0058]), as taught by Taylor et al. (‘102) and for example only as sketched herein below by the examiner, with each of the plural intelligent implement nodes (IPN) 58 including plural Ethernet and CAN ports, as taught in FIGS. 8 to 10 by Taylor et al. (‘102), in order to provide control and high speed/bandwidth data communication for and between sensors, motors, cameras, lights, actuators, fans, and any other device of the row units linked to the implement networks, via the Ethernet connections 62, 63, 64, as taught by Taylor et al. (‘102) and as suggested/desired by both Schlipf et al. (WO, ‘616) and Sikaria et al. (988), and/or as mere duplication of parts (MPEP 2144.04, VI., B.), 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.
For example, this arrangement of row units having individual CAN networks and IPNs with Ethernet connections, in Schlipf et al. (WO, ‘616), would have been obvious from the teachings of Taylor et al. (‘102), as sketched below/on the next page by the examiner5:
PNG
media_image1.png
1514
1095
media_image1.png
Greyscale
As such, the implemented or modified Schlipf et al. (WO, ‘616) agricultural system and implement would have rendered obvious:
per claim 1, a communication system, comprising:
a first communication module [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)] includes at least one port of a 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; and in Sikaria et al. (‘988), the ports of the CAN domains shown in FIGS. 2 and 3], at least two Ethernet ports of an Ethernet 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”; and 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 a first network gateway that is configured to translate between a protocol for the network and an Ethernet protocol for the Ethernet 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, and for communicating with cloud computing systems via the ECU Gateway D, as desired by Schlipf et al. (WO, ‘616), etc.], wherein the protocol of the network is different from the Ethernet protocol [e.g., CAN/ISOBUS and e.g., Ethernet, respectively, in Schlipf et al. (WO, ‘616), have different protocols; see e.g., paragraphs [0067], [0069], etc.; and similarly, for the CAN/Ethernet networks in Sikaria et al. (‘988)]; and
a second communication module [e.g., in Schlipf et al. (WO, ‘616), 1250, 1260, 1262] of a[6] first row unit of an agricultural implement [e.g., FIG. 2 in Schlipf et al. (WO, ‘616); with “group[s]” of one or more row units (such as left or right or all) being obviously defined; and including an intelligent implement node (IPN) 58 for e.g., one side (e.g., left or right) of the implement/planter in Taylor et al. (‘102)] 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; and in Taylor et al. (‘102), as shown in FIGS. 2 and 3 (e.g., in the Ethernet connection between the tractor/tow vehicle and the planter/implement], 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) e.g., in conjunction with FIGS. 2 and 3], at least one port of the 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 Ethernet ports of the Ethernet 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 a second network gateway that is configured to translate between the protocol for the network and the Ethernet protocol for the Ethernet 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 by communicatively coupling to at least one additional communication module [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.; to communicate with other intelligent implement nodes (IPNs) at paragraph [0064] and FIGS. 2 and 3 in Taylor et al. (‘102); and at paragraph [0067] in Schlipf et al. (WO, ‘616), “The network interface 1260 can be 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 machine 1202. The network interface 1 260 may be integrated with the implement network 1250 or separate from the implement network 1250 as illustrated in Figure 12”; and as shown in FIGS. 2 and 3 in Taylor et al. (‘102)] of a second row unit of the agricultural implement [e.g., FIG. 2 in Schlipf et al. (WO, ‘616); with “group[s]” of one or more row units (such as left or right or all) being obviously defined; and including an intelligent implement node (IPN) 58 for e.g., another/second side (e.g., left or right) of the implement/planter in Taylor et al. (‘102)];
per claim 2, depending from claim 1, wherein the second communication module includes the at least one port of the 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 3, depending from claim 1, wherein the 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 8, depending from claim 1, wherein the second communication module includes at least one controller area network (CAN) port of the network, which is a CAN network [e.g., as taught by Schlipf et al. (WO, ‘616) e.g., at paragraph [0064]; 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.], to receive data from at least one of sensors and controllers of the agricultural implement [e.g., from 1252, 1254, etc. in FIG. 12 of Schlipf et al. (WO, ‘616)], at least two Ethernet ports of the Ethernet 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[8], 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 the second network gateway of the second communication module to translate between the CAN protocol for the CAN network and the Ethernet protocol for the Ethernet 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.];
per claim 9, depending from claim 1, wherein the first communication module is located on the machine [e.g., paragraph [0057] in Schlipf et al. (WO, ‘616), “The machine 1202 includes . . .”] and the second communication module is located on the agricultural implement [e.g., paragraph [0064] in Schlipf et al. (WO, ‘616), “The implement 1240 [] includes . . .”], wherein the machine is a tractor or a combine harvester [e.g., “tractor, combine harvester, etc.” at paragraph [0057] in Schlipf et al. (WO, ‘616)];
per claim 10, depending from claim 1, wherein the first network gateway is configured 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 understood, 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); and with the location being programmed as taught at paragraph [0065] of Taylor et al. (‘102)];
per claim 11, depending from claim 1, wherein the second communication module is configurable to expand a network architecture of the communication system by having multiple Ethernet ports of the Ethernet network with at least one port being communicatively coupling to at least one additional communication module of the agricultural implement that includes at least one Ethernet and no controller area network (CAN) ports [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, etc., and being obvious in a system using (obviously expandable) Ethernet (or CAN) connections; and by the ECU Gateway D (for cloud communication, with no apparent CAN ports) in FIG. 2 of Sikaria et al. (‘988)];
Claims 4 to 7 are rejected under 35 U.S.C. 103 as being unpatentable over Schlipf et al. (P.C.T., WO 2017/0058616) in view of Sikaria et al. (2018/0062988) and Taylor et al. (2018/0116102) as applied to claim 2 above, and further in view of Sauder et al. (9,717,178).
Schlipf et al. (WO, ‘616) as implemented or modified in view of Sikaria et al. (‘988) and Taylor et al. (‘102) has been described above.
The implemented or modified Schlipf et al. (WO, ‘616) agricultural system and implement may not reveal the Power over Ethernet (POE) limitations of the dependent claims, 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 systems for planting crops, Sauder et al. (‘178) teaches (in combination with FIG. 3) that a power over Ethernet (PoE) injector9 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 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 4, depending from claim 2, wherein the Ethernet network comprises a Power over Ethernet (POE) network to pass 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), Sikaria et al. (‘988), and Taylor et al. (‘102), as taught at column 10, line 8 of Sauder et al. (‘178)];
per claim 5, depending from claim 4, wherein the second communication module of the first row unit of the agricultural implement is communicatively coupled to the first communication module of the machine with an Ethernet cable [e.g., the “one cable” taught at column 10, line 8 of Sauder et al. (‘178); and as taught by and/or rendered obvious from the Ethernet connection (for the network interfaces 1215, 1260) in Schlipf et al. (WO, ‘616); and the “wired” Ethernet connection disclosed and taught at paragraphs [0086], etc. (see also FIGS. 8 to 10) by Taylor et al. (‘102)];
per claim 6, depending from claim 5, wherein the Ethernet network transmits a sequence of messages to the at least two Ethernet ports of the second communication module to determine a configurable connection for each of the at least two Ethernet 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(s) having the source and destination addresses (414, 416), as taught and described (e.g., at paragraphs [0013], [0029], etc.) in conjunction with FIG. 4 of Sikaria et al. (‘988)];
per claim 7, depending from claim 5, 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];
Claims 12 to 15, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Taylor et al. (2018/0116102) in view of Diab et al. (2014/0078889) and Sikaria et al. (2018/0062988).
Taylor et al. (‘102) reveals:
per claim 12, an agricultural implement [e.g., FIG. 1], comprising:
a plurality of row units for agricultural operations [e.g., FIG. 1 including row units 40 mounted to the toolbar 22];
a[10] first communication module [e.g., one (or more) of the IPNs 58 in FIG. 3 (e.g., for example only, a left side IPN), e.g., as shown in FIGS. 8 to 10, with plural CAN ports and plural Ethernet ports (e.g., paragraphs [0073], [0081], [0082], etc.)] that is associated with a first group of row units [e.g., the left side row units (40) shown in FIG. 1, in the examiner’s example], the first communication module of the agricultural implement includes at least one port of a network to receive data from at least one of sensors and controllers [e.g., plural “CAN bus connections” 105 (paragraph [0073]) as shown in FIGS. 8 to 10, and as obviously inferable in FIG. 3; see also paragraph [0064], “The IPN's are connected to a number of sensors, motors, and other controls in which the IPN's transmit information between each other and the IPR in order to control functions of the components thereon. For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71. Such motor and sensors are generally associated with a row unit and/or seed meter of a planter”; see also paragraph [0067], “For example, the IPN's 58, one connected to a planter, can drive seed motors, collect data from seed sensors, activate solenoids, and or otherwise communicate with the IPR via Ethernet connection.”] of the agricultural implement, at least two Ethernet ports of an Ethernet network [e.g., the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraph [0073])], and [e.g., CAN uses a different protocol than Ethernet, as is well-known]; and
a second communication module [e.g., one (or more) of the IPNs 58 in FIG. 3 (e.g., a right side IPN), e.g., as shown in FIGS. 8 to 10, with plural CAN ports and plural Ethernet ports (e.g., paragraphs [0073], [0081], [0082], etc.)] communicatively coupled to the first communication module [e.g., via the Ethernet connections (e.g., 63, 64, etc.) shown in FIG. 3], wherein the second communication module is associated with a second group of row units [e.g., the right side row units (40) shown in FIG. 1] and includes at least one port of the network to receive data from at least one of sensors and controllers of the agricultural implement [e.g., plural “CAN bus connections” 105 (paragraph [0073]) as shown in FIGS. 8 to 10, and as obviously inferable in FIG. 3; see also paragraph [0064], “The IPN's are connected to a number of sensors, motors, and other controls in which the IPN's transmit information between each other and the IPR in order to control functions of the components thereon. For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71. Such motor and sensors are generally associated with a row unit and/or seed meter of a planter”; see also paragraph [0067], “For example, the IPN's 58, one connected to a planter, can drive seed motors, collect data from seed sensors, activate solenoids, and or otherwise communicate with the IPR via Ethernet connection.”], at least two ports of the Ethernet network [e.g., the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraph [0073]); see also FIG. 3], and
Taylor et al. (‘102) may not reveal that the intelligent implement nodes (IPNs) 58 include gateway functions to translate between CAN and Ethernet, although the examiner believes this would have been obvious to any person skilled in the art, to allow sensor and control data to pass through the IPNs, e.g., from the intelligent control 52 in the tractor to the (sensor/actuator) components in the implement, and vice versa.
However, in the context/field of improved network node modules (30) for a vehicle (such as an “agricultural vehicle” at paragraph [0004]) that uses Ethernet as the vehicular communications network 20, Diab et al. (‘889) teaches in conjunction with FIGS. 2 and 4 and at paragraphs [0073], etc. that each network node module 30 includes ore or more subsystems 340 (e.g., in the form of sensors, ECUs, actuators, etc.; paragraph [0034]) that communicate by CAN (e.g., paragraph [0038]). Moreover, in the context of using Ethernet as the global network communication protocol (see e.g., FIG. 2; paragraphs [0038], etc.; claims 8, etc.), Diab et al. (‘889) teaches that the network node module 30 “may further translate between a global vehicle network communication protocol utilized by the vehicular communication network and a particular vehicle device communication protocol (e.g., CAN, Flex Ray, etc.) utilized by Subsystem A. . . . Alternatively, the processing module 310 may encapsulate the vehicle device communication packet of Subsystem A into a global vehicle network communication protocol packet” (paragraph [0038]).
Moreover, , 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.
It would have been obvious before the effective filing date of the claimed invention to implement or modify the Taylor et al. (‘102) agricultural implement and electronics so that the intelligent implement nodes (IPNs) 58 would have been provided with the network gateway functionality to translate between a global vehicle network communication protocol utilized by the vehicular communication network (in the Ethernet connections 62 – 64 in FIG. 3 of Taylor et al. (‘102)) and the particular vehicle device communication protocol (e.g., CAN, etc.) as used with the IPNs 58 in FIGS. 8 to 10 connected to and positioned at the row units 40, as taught by Diab et al. (‘889) in conjunction with an agricultural vehicle at paragraphs [0038], etc., in order to facilitate the communication between the ECUs of differing communication protocols (paragraph [0006] in Diab et al. (‘889), such as ECUs communicating with CAN and ECUs communicating with Ethernet, and in order to facilitate transmission or row unit data on the CAN network(s) to or from other IPNs 58 or the router(s) via the Ethernet connection(s), as desired by Taylor et al. (‘102) at paragraph [0064] and as taught by Diab et al. (‘889), 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 Taylor et al. (‘102) agricultural implement and electronics so that, for transmitting (implement) data between the IPNs (58) over the Ethernet connections (62 to 64) in Taylor et al. (‘102) as desired at paragraph [0064], the IPNs (58) would have each been (e.g., additionally) provided with an ECU gateway, as taught by Sikaria et al.(‘988), in order i) to package each CAN message data to be transmitted (to other CAN bus domains at other IPNs 58) in an Ethernet frame, and to extract (from such Ethernet frames) the data of each CAN message to be received (from other CAN bus domains), in accordance with source/destination addresses in the frames, as taught by Sikaria et al. (‘988), and ii) to communicate with other IPNs and/or router(s) (e.g., e.g., the implement router (IPR) 56) via Ethernet, 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.
As such, the implemented or modified Taylor et al. (‘102) agricultural implement and electronics would have rendered obvious:
per claim 12, an agricultural implement [e.g., in Taylor et al. (‘102), FIG. 1], comprising:
a plurality of row units for agricultural operations [e.g., in Taylor et al. (‘102), FIG. 1 including row units 40 mounted to the toolbar 22];
a[11] first communication module [e.g., in Taylor et al. (‘102), one (or more) of the IPNs 58 in FIG. 3 (e.g., for example only, a left side IPN), e.g., as shown in FIGS. 8 to 10, with plural CAN ports and plural Ethernet ports (e.g., paragraphs [0073], [0081], [0082], etc.); with the node including the protocol translation functionality (at 310) as taught at paragraph [0038] by Diab et al. (‘889) and the ECU gateway 220 as taught by Sikaria et al. (‘988) for e.g., packaging and extracting CAN message data for/from the row units into Ethernet frames for transmission over the Ethernet connections (62 to 64) in Taylor et al. (‘102)] that is associated with a first group of row units [e.g., in Taylor et al. (‘102), the left side row units (40) shown in FIG. 1, in the examiner’s example], the first communication module of the agricultural implement includes at least one port of a network to receive data from at least one of sensors and controllers [e.g., in Taylor et al. (‘102), plural “CAN bus connections” 105 (paragraph [0073]) as shown in FIGS. 8 to 10, and as obviously inferable in FIG. 3; see also paragraph [0064], “The IPN's are connected to a number of sensors, motors, and other controls in which the IPN's transmit information between each other and the IPR in order to control functions of the components thereon. For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71. Such motor and sensors are generally associated with a row unit and/or seed meter of a planter”; see also paragraph [0067], “For example, the IPN's 58, one connected to a planter, can drive seed motors, collect data from seed sensors, activate solenoids, and or otherwise communicate with the IPR via Ethernet connection.”] of the agricultural implement, at least two Ethernet ports of an Ethernet network [e.g., in Taylor et al. (‘102), the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraphs [0073], [0081], etc.)], and a first network gateway [e.g., for each (e.g., left side) implement node (IPN) in Taylor et al. (‘102), the ECU gateway (220) as taught by Sikaria et al. (‘988) for communicating (e.g., implement) data between the CAN/Ethernet networks; and/or the processing module 310 in Diab et al. (‘889) for translating protocols at paragraph [0038]] to translate between a protocol for the network and an Ethernet protocol for the Ethernet network [e.g., paragraph [0038] in Diab et al. (‘889); and abstract in Sikaria et al. (‘988)], wherein the protocol of the network is different from the Ethernet protocol [e.g., in Taylor et al. (‘102), CAN uses a different protocol than Ethernet, as is well-known]; and
a second communication module [e.g., in Taylor et al. (‘102), one (or more) of the IPNs 58 in FIG. 3 (e.g., a right side IPN), e.g., as shown in FIGS. 8 to 10, with plural CAN ports and plural Ethernet ports (e.g., paragraphs [0073], [0081], [0082], etc.)] communicatively coupled to the first communication module [e.g., in Taylor et al. (‘102), via the Ethernet connections (e.g., 63, 64, etc.) shown in FIG. 3], wherein the second communication module is associated with a second group of row units [e.g., in Taylor et al. (‘102), the right side row units (40) shown in FIG. 1] and includes at least one port of the network to receive data from at least one of sensors and controllers of the agricultural implement [e.g., in Taylor et al. (‘102), plural “CAN bus connections” 105 (paragraph [0073]) as shown in FIGS. 8 to 10, and as obviously inferable in FIG. 3; see also paragraph [0064], “The IPN's are connected to a number of sensors, motors, and other controls in which the IPN's transmit information between each other and the IPR in order to control functions of the components thereon. For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71. Such motor and sensors are generally associated with a row unit and/or seed meter of a planter”; see also paragraph [0067], “For example, the IPN's 58, one connected to a planter, can drive seed motors, collect data from seed sensors, activate solenoids, and or otherwise communicate with the IPR via Ethernet connection.”], at least two ports of the Ethernet network [e.g., in Taylor et al. (‘102), the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraphs [0073], [0081], etc.); see also FIG. 3], and a second network gateway [e.g., for each (e.g., right side) implement node (IPN) in Taylor et al. (‘102), the ECU gateway (220) as taught by Sikaria et al. (‘988) for communicating (e.g., implement) data between the CAN/Ethernet networks; and/or the processing module 310 in Diab et al. (‘889) for translating protocols at paragraph [0038]] of the second communication module to translate between the protocol for the network and the Ethernet protocol for the Ethernet network [e.g., paragraph [0038] in Diab et al. (‘889); and abstract in Sikaria et al. (‘988)];
per claim 13, depending from claim 12, wherein the second communication module includes at least one controller area network (CAN) port of the network [e.g., as shown (e.g., at 105) and described with respect to the IPN (58) in FIGS. 8 to 10 of Taylor et al. (‘102); see e.g., paragraphs [0073], [0082], etc.], which is a CAN network, to receive data from at least one of sensors and controllers of the agricultural implement [e.g., paragraph [0064] in Taylor et al. (‘102), “For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71”; see also paragraphs [0073], [0082], etc.], at least two Ethernet ports of the Ethernet network [e.g., in Taylor et al. (‘102), the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraphs [0073], [0081], etc.); see also FIG. 3], and a second network gateway of the second communication module to translate between the CAN protocol for the CAN network and the Ethernet protocol for the Ethernet network [e.g., for each (e.g., right side) implement node (IPN) in Taylor et al. (‘102), the ECU gateway (220) as taught by Sikaria et al. (‘988) for communicating (e.g., implement) data between the CAN/Ethernet networks; and/or the processing module 310 in Diab et al. (‘889) for translating protocols at paragraph [0038]];
per claim 14, depending from claim 13, further comprising:
a third communication module communicatively coupled to the first or second communication module [e.g., other IPNs (58) in FIG. 3 of Taylor, such as connected to the Ethernet auxiliary connections 65];
per claim 15, depending from claim 12, wherein the network comprises a controller area network (CAN) [e.g., as taught at paragraphs [0073], [0082], etc. in Taylor et al. (‘102)];
per claim 17, depending from claim 14, wherein the first network gateway is configured 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 understood, 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); and with the location being programmed as taught at paragraph [0065] of Taylor et al. (‘102)];
per claim 19, depending from claim 18, wherein the second communication module receives power from an upstream module having PoE or has a separate power supply [e.g., it would have been obvious that the (e.g., for example, right side) intelligent implement nodes (IPNs) 58 in Taylor et al. (‘102) would have had (separate) power supplies, to power the circuitry shown in FIG. 10];
per claim 20, depending from claim 18, wherein the first communication module includes at least one controller area network (CAN) port of the network [e.g., as shown (e.g., at 105) and described with respect to the IPN (58) in FIGS. 8 to 10 of Taylor et al. (‘102); see e.g., paragraphs [0073], [0082], etc.], which is a CAN network, to receive data from at least one of sensors and controllers of the agricultural implement [e.g., paragraph [0064] in Taylor et al. (‘102), “For example, one IPN is connected to a seed meter motor 66, insecticide flow center 67, seed sensor 68, manual run button 69, insecticide motor control 70, and liquid fertilizer sensor 71”; see also paragraphs [0073], [0082], etc.], at least two Ethernet ports of the Ethernet network [e.g., in Taylor et al. (‘102), the “plurality of Ethernet connections 104” of the IPNs (58) in FIGS. 8 to 10 (paragraphs [0073], [0081], etc.); see also FIG. 3], and the first network gateway of the first communication module to translate between the CAN protocol for the CAN network and the Ethernet protocol for the Ethernet network [e.g., for each (e.g., left side) implement node (IPN) in Taylor et al. (‘102), the ECU gateway (220) as taught by Sikaria et al. (‘988) for communicating (e.g., implement) data between the CAN/Ethernet networks; and/or the processing module 310 in Diab et al. (‘889) for translating protocols at paragraph [0038]];
Claims 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Taylor et al. (2018/0116102) in view of Diab et al. (2014/0078889) and Sikaria et al. (2018/0062988) as applied to claims 12 and 17 above, and further in view of Sauder et al. (9,717,178).
Taylor et al. (‘102) as implemented or modified in view of Diab et al. (‘889) and Sikaria et al. (‘988) has been described above.
The implemented or modified Taylor et al. (‘102) agricultural implement and electronics may not reveal the Power over Ethernet (POE) limitations of the dependent claims, although the examiner has taken Official Notice in the parent application 17/267,712, and now takes 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 systems for planting crops, Sauder et al. (‘178) teaches (in combination with FIG. 3) that a power over Ethernet (PoE) injector12 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 further modify the Taylor et al. (‘102) agricultural implement and electronics so that the Ethernet connections (62 to 64) between the tractor and implement (and within the implement) would have been predictably implemented as a Power over Ethernet (PoE) connection (e.g., instead of the Ethernet connection suggested by Taylor et al. (‘102) himself), 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 Taylor et al. (‘102) agricultural implement and electronics have rendered obvious:
per claim 16, depending from claim 12, wherein the Ethernet network comprises a Power over Ethernet (POE) network to pass 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 connections (62 to 64) in Taylor et al. (‘102) and Sikaria et al. (‘988), e.g., as taught at column 10, line 8 of Sauder et al. (‘178)];
per claim 18, depending from claim 17, wherein the Ethernet network transmits a sequence of messages to the at least two Ethernet ports of the second communication module to determine a configurable connection for each of the at least Ethernet 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(s) having the source and destination addresses (414, 416), as taught and described (e.g., at paragraphs [0013], [0029], etc.) in conjunction with FIG. 4 of Sikaria et al. (‘988)];
per claim 19, depending from claim 18, 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 Taylor et al. (‘102) e.g., for the right side IPNs 58 (to power the circuitry shown in FIG. 10) 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];
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 9 and 11 to 16 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 claims in the instant application have already been (e.g., more broadly, for example by claiming a Power over Ethernet network, which is a particular type of Ethernet network in the reference patent, versus claiming a generic Ethernet network in the instant application, and/or by claiming obvious negative limitations in claim 11, MPEP 2144.04, II., A. and/or by obviously combining claimed embodiments to use a fully conventional CAN network as the network in claims 13 and 15 or to use a fully conventional Ethernet cable in claim 16) claimed in the reference patent with only slight but obvious differences in wording, with the claim limitations in the instant application corresponding to the claim limitations in the reference patent as in the following claim correspondence table:
Claims in Instant application 19/279,188 to Allgaier et al.
Corresponding Claims in U.S. Patent 12,342,745 to Allgaier et al. (reference patent)
1
1
2
2
3
1, 8
4
1, 2
5
1, 2, 3
6
1, 2, 3, 5
7
1, 2, 3, 7
8
1, 8
9
1, 9
--
--
11
1, 11
12
12
13
12, 8
14
12, 14
15
12, 8
16
12, 1, 3
--
--
--
--
--
--
--
--
Claims 1 to 9 and 11 to 16 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 to 18 of copending Application No. 19/227,633 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 claims in the instant application have already been (e.g., more broadly, for example by claiming a Power over Ethernet network, which is a particular type of Ethernet network in the reference application, versus claiming a generic Ethernet network in the instant application, and/or by claiming obvious negative limitations in claim 11, MPEP 2144.04, II., A. and/or by obviously combining claimed embodiments to use a fully conventional CAN network as the network in claims 13 and 15 or to use a fully conventional Ethernet cable in claim 16) claimed in the reference patent with only slight but obvious differences in wording, with the claim limitations in the instant application corresponding to the claim limitations in the reference patent as in the following claim correspondence table:
Claims in Instant application 19/279,188 to Allgaier et al.
Corresponding Claims in U.S. Patent Application 19/227,633 to Allgaier et al. (reference patent)
1
10, 11
2
10, 11, 12
3
10, 11, 13
4
10, 11, 12, 14
5
10, 11, 12, 14
6
10, 11, 12, 14, 15
7
10, 11, 12, 14, 15, 16
8
10, 11, 13
9
10, 11, 18
--
--
11
10, 11, 9
12
1, 2
13
1, 2, 4, 8
14
1, 2, 3, 4, 8
15
1, 2, 4, 8
16
1, 2, 5
--
--
--
--
--
--
--
--
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
For example only, the Wikipedia articles reveal fully conventional/obvious Power over Ethernet and CAN networks.
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 See Nautilus, Inc. v. Biosig Instruments, Inc. (U.S. Supreme Court, 2014) which held, "A patent is invalid for indefiniteness if its claims, read in light of the patent’s specification and prosecution history, fail to inform, with reasonable certainty, those skilled in the art about the scope of the invention." See also In re Packard, 751 F.3d 1307 (Fed.Cir.2014)(“[A] claim is indefinite when it contains words or phrases whose meaning is unclear,” i.e., “ambiguous, vague, incoherent, opaque, or otherwise unclear in describing and defining the claimed invention.”) and Ex Parte McAward, Appeal No. 2015-006416 (PTAB, Aug. 25, 2017, Precedential) (“Applying the broadest reasonable interpretation of a claim, then, the Office establishes a prima facie case of indefiniteness with a rejection explaining how the metes and bounds of a pending claim are not clear because the claim contains words or phrases whose meaning is unclear.”)
4 Applicant’s original claims, which provide support for the “two ports” limitation, claimed “at least one input port and at least one output port”.
5 The CAN/ISOBUS networks (1210, 1250) in Schlipf et al. (WO, '616) and the CAN bus connections (FIGS. 8 to 10) in Taylor et al. (‘102) had or would have obviously had at least one port, and the Ethernet networks (e.g., at/connecting the network interfaces) in Sikaria et al. ('988) and Taylor et al. (‘102) had or 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 [e.g., CAN] networks (1210, 1250) and/or Ethernet gateways (220a, 220b) and/or IPNs being indicated by the examiner as large black circles (e.g., larger than “●”) added in a sketch below/on the next page which was made (by the examiner) by merging respective FIGS. from Schlipf et al. (WO, ‘616), Sikaria et al. (‘988), and Taylor et al. (‘102), 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, in the examiner’s sketch.
6 It has been established that “[a]s a general rule, the words ‘a’ or ‘an’ in a patent claim carry the meaning of ‘one or more.’” TiVo, Inc. v. EchoStar Commc’ns Corp., 516 F.3d 1290, 1303 (Fed. Cir. 2008). It has also been held that “[t]he exceptions to this rule are extremely limited: a patentee must evince a clear intent to limit ‘a’ or ‘an’ to ‘one.’” Baldwin Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342 (Fed. Cir. 2008) (internal quotation marks and citation omitted).
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 Applicant’s original claims, which provide support for the “two ports” limitation, claimed “at least one input port and at least one output port”.
9 As is well-known, a PoE injector is a device that adds power to an Ethernet cable for Power over Ethernet (PoE) equipment.
10 It has been established that “[a]s a general rule, the words ‘a’ or ‘an’ in a patent claim carry the meaning of ‘one or more.’” TiVo, Inc. v. EchoStar Commc’ns Corp., 516 F.3d 1290, 1303 (Fed. Cir. 2008). It has also been held that “[t]he exceptions to this rule are extremely limited: a patentee must evince a clear intent to limit ‘a’ or ‘an’ to ‘one.’” Baldwin Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342 (Fed. Cir. 2008) (internal quotation marks and citation omitted).
11 It has been established that “[a]s a general rule, the words ‘a’ or ‘an’ in a patent claim carry the meaning of ‘one or more.’” TiVo, Inc. v. EchoStar Commc’ns Corp., 516 F.3d 1290, 1303 (Fed. Cir. 2008). It has also been held that “[t]he exceptions to this rule are extremely limited: a patentee must evince a clear intent to limit ‘a’ or ‘an’ to ‘one.’” Baldwin Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342 (Fed. Cir. 2008) (internal quotation marks and citation omitted).
12 As is well-known, a PoE injector is a device that adds power to an Ethernet cable for Power over Ethernet (PoE) equipment.
Prosecution Insights