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 .
Status of the Claims
This office action considers claims 1, 5, 7-10, 15-20, 24-28 and 30 filed on 02/05/2026 are pending for prosecution.
Claims 2-4, 6, 11-14, 21-23 and 29 are canceled.
Response to Arguments
Applicant’s arguments filed on 02/05/2026 with respect to claims 1, 5, 7-10, 15-20, 24-28 and 30 have been fully considered but they are not persuasive.
Applicant presented argument that Lee does not disclose the limitation “. . . wherein the standardized bus format comprises an application format" (Emphasis added) as recited in amended claims 1, 8 and 18. (REMARKS, Pages 10-12)
The Examiner respectfully disagrees. The Examiner presents that – it is improper to import claim limitations from the specification. See MPEP 2111.01.II.
The Examiner further presents that the claims 1, 8 and 18 limitations “the standardized bus format comprises an application format”, and the instant application Specification discloses –
[0033] Present disclosure CTM embodiments may be configured for use in a variety of different system applications, including defense applications (e.g., defense aircraft platforms, weapon management systems, naval platforms, electronic warfare platforms, and the like, or combinations thereof), commercial aircraft applications, medical device applications, Internet of Things (IoT) applications, and the like. ……
However, in REMARKS, the Applicant cites Specification [0034] disclosing OSI stack model of Fig. 3, without disclosing corresponding distinguishing feature in the claims 1, 8 and 18, which may overcome Lee.
Accordingly the claim limitation in interpreted as the standardized bus format comprises an application format usable for defense or …… medical device or IoT, which is analogous to machine automation applications like self-driving vehicle, an automated industrial machine or an automated self-controlled robot or for VPN application as disclosed in Lee (0054, 0055, 0070) disclosing –
[0054] the system, method and device provides a unique intranet system architecture specially defined and optimized for machine automation applications.
[0055] FIG. 1 illustrates a machine automation system 100 according to some embodiments. ….. the system 100 is able to be a part of an automated device such as a self-driving vehicle, an automated industrial machine or an automated self-controlled robot. Alternatively, the system 100 is able to be a part of other machine automation applications. …. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2).
[0070] Finally use GEM packet format for VPN channel application between local-nodes 204, 208 to far nodes 204, 208 through bus 104.).
Accordingly, claims 1, 8 and 18 are rejected.
Dependent claims 5, 7, 9-10, 15-17, 19-20, 24-28 and 30, being dependent on independent claims 1, 8 and 18, are also rejected for same as above.
NOTICE for all US Patent Applications filed on or after March 16, 2013
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 5, 7-10, 15-20, 24-28 and 30 are rejected under 35 U.S.C. 102 (a)(1) as anticipated by Lee et al. (US 20210056058 A1, of IDS, hereinafter ‘LEE’).
Regarding claim 1, LEE teaches an electronic communication translation module (CTM) (Fig. 2 Node 204 or 208, Fig. 30 I/O Data Adapter 3004 of Node 204/208, See also Fig. 1 machine automation system 100) for use with a system having at least one communication bus (Fig 1 bus 104, [0055] system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104…. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2)…
[0056] FIG. 2 illustrates the intelligent controller and sensor intranet bus 104 according to some embodiments. As shown in FIG. 2, the bus 104 comprises an intranet formed by a central core 200 that is coupled with one or more gates 202 and a plurality of edge nodes 204 (each having one or more external IO ports 99) via one or more central transmission networks 206, and coupled with one or more edge sub-nodes 208 (each having one or more external IO ports 99) via one or more sub-networks 210 that extend from the gates 202.), the communication bus configured to transfer electronic communications in a standardized bus format ([0063] The bus 104 is able to encapsulate all input data and internally generated data (e.g. control, operation and management messages) into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208 …...
See also Fig. 31, [0150] illustrating protocol conversion mechanism in a bus system 100 for packets from a source device 102 to a destination device 102), the system having a plurality of system components in electronic communication with the communication bus for communicating between system components (Fig. 1, [0055] As shown in FIG. 1, the system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104….. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2).
[0101] …..In order to provide data from the devices 102 coupled to the ports 99 of the nodes 204, 208, the nodes 204, 208, 234 construct and transmit burst messages …as GEMS …. through the bus 104 to the other nodes 204, 208 via the root port 230 (of the network 206 of which they are a part or a subnetwork 210 thereof). Further, in order to provide data to the devices 102 ……. nodes 204, 208, 234 receive broadcast message ….as GEMs … from other nodes 204, 208), and each system component configured to produce at least one electronic communication protocol (
[0005] The system comprises a controller and sensor bus including at least one central processing core including one or more root ports, one or more transmission networks each directly coupled to the core via a different one of the root ports and including a plurality of nodes and a plurality of input/output ports each coupled with one of the nodes and a plurality of external machine automation devices each having one or more accepted data formats and coupled to one of the nodes via the plurality of the ports coupled with the one of the nodes.
[0006] the accepted data formats are one or more of a group consisting of Ethernet protocol format, I2C protocol format, I3C protocol format, peripheral component internet express (PCIe) format, mobile industry processor interface (MIPI) camera serial interface (CSI) format, general purpose input/output (GPIO) format, universal serial bus (USB) format and controller area network (CAN) bus protocol format.
Fig. 1, [0055] As shown in FIG. 1, the system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104….. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2).
[0135] the bus 104 is able to provide a protocol conversion mechanism. Specifically, each of the nodes 204, 208 are able to comprise a I/O data adaptor 3004 that is able to intercept and convert the original format of an incoming message (e.g. the format as received from the source device/port(s)) to a different format that is designated for the destination port(s)/epoch(s)/device(s). In particular, the different format is able to be based on the type of device 102 and/or the type of format the device 102 expects to receive via the destination port(s) and/or epoch (e.g. if the device 102 is able to receive data in multiple formats).), the CTM comprising:
a protocol storage submodule configured to store a plurality of predetermined system component protocols (PSCPs), each PSCP associated with the at least one said electronic communication protocol of a respective said system component (
[0135] As described above, in some embodiments in addition to encapsulating/decapsulating messages from devices 102 for burst/broadcast transmission over the bus network 206, 210, the bus 104 is able to provide a protocol conversion mechanism. Specifically, each of the nodes 204, 208 are able to comprise a I/O data adaptor 3004 that is able to intercept and convert the original format of an incoming message (e.g. the format as received from the source device/port(s)) to a different format that is designated for the destination port(s)/epoch(s)/device(s). In particular, the different format is able to be based on the type of device 102 and/or the type of format the device 102 expects to receive via the destination port(s) and/or epoch (e.g. if the device 102 is able to receive data in multiple formats)..
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port).
[0137] In some embodiments, the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. ); and
a processor in communication with the protocol storage submodule storing instructions (Fig. 30 node processing engine 3014 in communication with node memory 3012 and I/O adapter 3004, [0102] FIG. 30 illustrates a node 204, 208 …. are able to comprise one or more ports 99, an encapsulation/decapsulation engine 3002, an I/O data adaptor 3004, … a node reception MAC 3008, a node transmission MAC 3010, a node memory 3012 and a node processing engine 3014.
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
See also [0137] stored in node memory 3014 …. conversion instruction), which instructions when executed cause the processor to:
identify a respective said system component using the respective said at least one electronic communication protocol of the respective said system component and a selected said PSCP ([0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
[0137] In some embodiments, the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair.),
the respective said system component corresponding to a new system component ([0137] the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus).); and
translate an electronic communication including the respective at least one said system component electronic communication protocol into a said standardized bus format transferable on the at least one communication bus using said selected PSCP enabling communication between system components (
Fig. 8 Steps 804, 808, 810)
[0089] As shown in FIG. 8, one or more of the nodes 204, 208 input one or more messages from the one or more of the devices 102 coupled to the one or more of the ports 99 at the step 802. The nodes 204, 208 encapsulate the messages into the generic encapsulation mode (GEM) format for transmission to the central processing core 200 at the step 804. …. if the destination(s) of the input messages is one or more other nodes 204, 208 (outside the core 200), the core 200 decapsulates, processes and re-encapsulates the messages back into the GEM format for broadcast to their destination(s) at the step 808. ... The nodes 204, 208 decapsulate the messages as received from the core 200 from the GEM format to an original format of the input data as received from one of the devices 102 at the step 810.
[0135] As described above, in some embodiments in addition to encapsulating/decapsulating messages from devices 102 for burst/broadcast transmission over the bus network 206, 210, the bus 104 is able to provide a protocol conversion mechanism. Specifically, each of the nodes 204, 208 are able to comprise a I/O data adaptor 3004 that is able to intercept and convert the original format of an incoming message (e.g. the format as received from the source device/port(s)) to a different format that is designated for the destination port(s)/epoch(s)/device(s). In particular, the different format is able to be based on the type of device 102 and/or the type of format the device 102 expects to receive via the destination port(s) and/or epoch (e.g. if the device 102 is able to receive data in multiple formats).
[0137] In some embodiments, the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair.
See also Fig. 31 Steps 3102-3106,
[0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104 ….. The node 204, 208 transmits the encapsulated packets as a burst message through the core 200 and to a destination node 204, 208 coupled with a destination device 102 at the step 3106.
(It is construed from LEE Fig. 31, [0089, 0135-0137, 0150] LEE disclosing each node 204, 208 translates protocol of incoming packet to protocol of destination packet using and a set of conversion instructions or PSCP, and encapsulate the converted packet in to a GEM packet format or the standardized bus format of BUS 104 for communication with the destination via BUS 104. )),
wherein the translation includes simultaneously translating one or more physical protocol elements associated with at least one said system component electronic communication protocol into said standardized bus format using said selected PSCP ([0063] The bus 104 is able to encapsulate all input data and internally generated data (e.g. control, operation and management messages) into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208, 234 or gates 202 and/or the embedded CPU cores 232.
[0138] When in the hybrid mode, both hardware and software are involved in protocol and format conversion. The software performs the protocol conversion and the hardware performs the format conversion based on the lookup results of format/protocol conversion table. This mode is able to be used for IO-Port (USB) to IO-Port (PCIe), IO-Port (Ethernet) to IO-Port (USB), IO-Port (EtherCAT) to IO-Port (PCIe/Ethernet) and/or other conversions. …. the software of the node 204, 208 performs the protocol conversion ….. used for …new application specific and dynamic protocol …..
Fig. 31 step 3104, [0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104. In some embodiments, the node 204, 208 assigns a packet identifier (e.g. GEM identifier) to each of the packets 600.
(Construed that physical elements associated with Port (Ethernet) to IO-Port (USB) are also translated for encapsulation)), and translating one or more logical protocol elements associated with at least one said system component electronic communication protocol into said standardized bus format using said selected PSCP ([0069] Use GEM packet format to carry CPU/PCIe access CMD/DATA from core 200 and local gate 202 and/or node 204 through bus 104 after GEM encapsulation, to far-end local gate 202 and/or node 204 (e.g. CPU 232 access target device 102 from NODE-to-NODE through PCIe, USB, I2C, UART and GPIO interfaces).
Fig. 2, [0092] As a result, the core switch 228 is able to provide the functions of on ingress, the switch 228 receives GEMs from one or more of the root ports 230, local nodes 234, computer 232 and/or other IO ports, processes the GEMs and on egress, forwards and transmits the received GEMs to one or more of the root ports 230, local nodes 234, computer 232 and/or other IO ports. In other words, the switch 228 is able to accept GEM-Packets from multiple sources; perform GEM and Ethernet L2/L3/L4 header parsing, L2 MAC lookup and learning, GEM message and 5-tuple ACL and classification; modify GEM-Header and GEM payload Ethernet header (if necessary) …..
[0101] …..In order to provide data from the devices 102 coupled to the ports 99 of the nodes 204, 208, the nodes 204, 208, 234 construct and transmit burst messages …as GEMS …. through the bus 104 to the other nodes 204, 208 via the root port 230 (of the network 206 of which they are a part or a subnetwork 210 thereof). Further, in order to provide data to the devices 102 ……. nodes 204, 208, 234 receive broadcast message ….as GEMs … from other nodes 204, 208.
(Construed that the nodes 204, 208, 234 with the core switch 228 is able to provide the functions of ingress provides L2/L3/L4 logical layer characteristics or logical protocol elements correspond to logical layer characteristics of the at least one said system component electronic communication protocol).
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
See also [0138] and Fig. 31 step 3104, [0150] cited above.
(Construed that at least logical elements of Ethernet L2/L3/L4 are also translated for encapsulation));
transport the electronic communication in the said standardized bus format to at least another system component of the plurality of system components (
Fig. 8 Steps 804, 808,
[0089] As shown in FIG. 8, one or more of the nodes 204, 208 input one or more messages from the one or more of the devices 102 coupled to the one or more of the ports 99 at the step 802. The nodes 204, 208 encapsulate the messages into the generic encapsulation mode (GEM) format for transmission to the central processing core 200 at the step 804. …. if the destination(s) of the input messages is one or more other nodes 204, 208 (outside the core 200), the core 200 decapsulates, processes and re-encapsulates the messages back into the GEM format for broadcast to their destination(s) at the step 808.
See also Fig. 31 Steps 3102-3106,
[0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104 ….. The node 204, 208 transmits the encapsulated packets as a burst message through the core 200 and to a destination node 204, 208 coupled with a destination device 102 at the step 3106.); and
translate the electronic communications in said standardized bus format to a format utilized by the at least another system component (
Fig. 8, Step 810,
[0089] The nodes 204, 208 decapsulate the messages as received from the core 200 from the GEM format to an original format of the input data as received from one of the devices 102 at the step 810.
See also Fig. 31 Steps 3112 and 3114,
[0151] The destination node 204, 208 decapsulates the message as received from the core 200 back to its original format as received from the source device 102 at the step 3108. The destination node 204, 208 determines whether the original format matches at least one data format accepted by the destination device 102 at the step 3110. If there is a match, the destination node 204, 208 outputs the message to the destination device 102 in its original format at the step 3112. If there is not a match, the destination node 204, 208 converts the message from its original format into one of the formats accepted by the destination device and outputs the converted message to the destination device 102 at the step 3114. );
wherein the one or more physical protocol elements correspond to physical laver characteristics of the at least one said system component electronic communication protocol, the one or more physical protocol elements associated with the said standardized bus format (
[0138] In some embodiments, there are three protocol and format conversion modes used by the adaptor 3004: a hardware (HW) mode; a software (SW) mode; and a hybrid mode. When in the HW mode, hardware of the node 204, 208 performs the protocol and format conversion based on the lookup results of format/protocol conversion table. This approach is able to be mainly used for high speed, high throughput, low latency applications such as input (MIPI) to output (Ethernet), IO-Port (PCIe) to IO-Port (Ethernet), and/or other similar conversions.).
Protocol/Format Conversion Examples
[0140] As a first example of the protocol conversion mechanism using PCIe devices 102, when a PCIe root complex (RC) device 102 (e.g. CPU) wants to access one or multiple PCIe endpoint (EP) devices coupled to one or more node ports 99 (e.g. epochs), the nodes 204, 208 provide a PCIe bridging function including a PCIe virtual function ID. Specifically, when the node 204, 208 receives a PCIe TLP message from a PCIe RC device 102, the node 204, 208 is able to terminate PCIe protocol at the node 204, 208, identify the TLP message's memory Read/Write address ranges and map to a GEM identifier and/or the TLP message's associated virtual function ID. The core 200 is able to use the GEM identifier to process the data encapsulated in the packets 600 and/or determine where to forward the GEM packets 600 so they can reach their destination node(s). Subsequently, the PCIe data output from PCIe virtual function ID is encapsulated into GEM packet format by the encapsulation/decapsulation engine 3002 and then forwarded as a GEM packet 600 across the bus 104 to remote destination node 204, 208 coupled to the target device 102 (e.g. PCIe EP device).
See also Fig. 6A, a GEM packet 600, and
FIG. 7A, the Broadcast-PHY-Frame 700 with encapsulated GEP packets.
(It is construed that GEM protocol packet forwarded across bus 104 indicates physical protocol elements of GEM associated with the said standardized 104 bus format, and correspond to physical layer characteristics of the at least one said system component or PCIe device’s PCIe protocol or electronic communication protocol being terminated at node 204 and corresponding data getting encapsulated in GEM packet 600.)); and
wherein the one or more logical protocol elements correspond to logical layer characteristics of the at least one said system component electronic communication protocol, the one or more logical protocol elements associated with the said standardized bus format (
[0140] ……the node 204, 208 is able to terminate PCIe protocol at the node 204, 208, identify the TLP message's memory Read/Write address ranges and map to a GEM identifier and/or the TLP message's associated virtual function ID. The core 200 is able to use the GEM identifier to process the data encapsulated in the packets 600 and/or determine where to forward the GEM packets 600 so they can reach their destination node(s).
See also Fig. 6A, a GEM packet 600, and
FIG. 6B, GEM packet header format comprises a GEM-ID field 614.
(It is construed that the GEM identifier is a logical protocol element associated with the said standardized 104 bus format, and TLP message's associated virtual function ID correspond to logical layer characteristics of the at least one said system component or PCIe device’s PCIe protocol or electronic communication protocol.)); and
wherein the standardized bus format comprises an application format (
[0054] the system, method and device provides a unique intranet system architecture specially defined and optimized for machine automation applications.
[0055] FIG. 1 illustrates a machine automation system 100 according to some embodiments. ….. the system 100 is able to be a part of an automated device such as a self-driving vehicle, an automated industrial machine or an automated self-controlled robot. Alternatively, the system 100 is able to be a part of other machine automation applications. …. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2).
[0070] Finally use GEM packet format for VPN channel application between local-nodes 204, 208 to far nodes 204, 208 through bus 104.).
Regarding claim 5, LEE teaches the electronic CTM of claim 1, wherein the electronic communication translation module is configured for bidirectional electronic communication translation ([0063] the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208.
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port). If it matches, the adaptor 3004 refrains from any conversion and the data is able to be output. If it does not match, the adaptor 3004 converts the data from the original format to one of the desired formats. The data is then able to be output to the destination port(s)/epoch(s)/device(s) in this different data format/protocol.
(It is construed that, since a source and destination pair can be any of the devices 102 pair, the of source and destination may reverse at different times, a formatting in both direction over time for a pair of devices 102 is implied)).
Regarding claim 7, LEE teaches the electronic CTM of claim 1, wherein the electronic communication translation module is configured to identify a plurality of system components, each said system component different from each of the other said system components ([0055] FIG. 1 illustrates a machine automation system 100 according to some embodiments. As shown in FIG. 1, the system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104. In some embodiments, the system 100 is able to be a part of an automated device such as a self-driving vehicle, an automated industrial machine or an automated self-controlled robot. Alternatively, the system 100 is able to be a part of other machine automation applications. The devices 102 are able to comprise one or more of sensor devices (e.g. ultrasonic, infrared, camera, light detection and ranging (LIDAR), sound navigation and ranging (SONAR), magnetic, radio detection and ranging (RADAR)), internet devices, motors, actuators, lights, displays (e.g. screens, user interfaces), speakers, a graphics processing units, central processing units, memories (e.g. solid state drives, hard disk drives), controllers/microcontrollers or a combination thereof.
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port)).
Regarding claim 8, LEE teaches a method of establishing electronic communications between a plurality of system components within a system (Fig. 1, Fig 1 bus 104, [0055] system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104…. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2)…
[0063] The bus 104 is able to encapsulate all input data and internally generated data (e.g. control, operation and management messages) into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208, 234 or gates 202 and/or the embedded CPU cores 232.), the system having at least one communication bus in communication with the plurality of system components (Fig 1 bus 104, [0055] system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104….), and the at least one communication bus configured to transfer electronic communications in a standardized bus format (GEM Format, [0063] The bus 104 is able to encapsulate all input data …..into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be …..egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208…..
See also Fig. 31, [0150] illustrating protocol conversion mechanism in a bus system 100 for packets from a source device 102 to a destination device 102), the method comprising:
using a first communication translation module (CTM) (Fig. 2 Node 204 or 208, Fig. 30 I/O Data Adapter 3004 of Node 204/208, See also Fig. 1 machine automation system 100) to receive an electronic communication including at least one electronic communication protocol from a first system component of the plurality of system components (
[0063] The bus 104 is able to encapsulate all input data …..into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. ….. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208….
[0135] the bus 104 is able to provide a protocol conversion mechanism. Specifically, each of the nodes 204, 208 are able to comprise a I/O data adaptor 3004 that is able to intercept and convert the original format of an incoming message (e.g. the format as received from the source device/port(s)) to a different format that is designated for the destination port(s)/epoch(s)/device(s). In particular, the different format is able to be based on the type of device 102 and/or the type of format the device 102 expects to receive via the destination port(s) and/or epoch (e.g. if the device 102 is able to receive data in multiple formats).
See also Fig. 31 Steps 3102-3106,
[0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104 ….. The node 204, 208 transmits the encapsulated packets as a burst message through the core 200 and to a destination node 204, 208 coupled with a destination device 102 at the step 3106.),
the first system component new to the system ([0137] the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus).), the first CTM including a first protocol storage submodule configured to store a plurality of predetermined system component protocols (PSCPs) ([0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
[0137] In some embodiments, the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus). In some embodiments, the formats/protocols used on the bus and/or stored in the table comprise one or more of PCIe, USB, UART, MIPI, GPIO, Ethernet, EtherCAT, CAN-Bus, I.sup.2C, I.sup.3C and/or other data protocols.);
using the first CTM and a selected said PSCP to identify the first system component using at least a portion of the at least one electronic communication protocol of the first system component received by the first CTM ([0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port);
using the first CTM and the selected said PSCP from said first protocol storage submodule to translate the at least one electronic communication protocol of the first system component into an outgoing packet in said standardized bus format transferable on the at least one communication bus ([0063] Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet.
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port). ….If it does not match, the adaptor 3004 converts the data from the original format to one of the desired formats. The data is then able to be output to the destination port(s)/epoch(s)/device(s) in this different data format/protocol.),
wherein the translation includes simultaneously translating one or more physical protocol elements associated with the at least one electronic communication protocol of the first system component into said standardized bus format using said selected PSCP ([0063] The bus 104 is able to encapsulate all input data and internally generated data (e.g. control, operation and management messages) into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208, 234 or gates 202 and/or the embedded CPU cores 232.
[0138] When in the hybrid mode, both hardware and software are involved in protocol and format conversion. The software performs the protocol conversion and the hardware performs the format conversion based on the lookup results of format/protocol conversion table. This mode is able to be used for IO-Port (USB) to IO-Port (PCIe), IO-Port (Ethernet) to IO-Port (USB), IO-Port (EtherCAT) to IO-Port (PCIe/Ethernet) and/or other conversions. …. the software of the node 204, 208 performs the protocol conversion ….. used for …new application specific and dynamic protocol …..
Fig. 31 step 3104, [0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104. In some embodiments, the node 204, 208 assigns a packet identifier (e.g. GEM identifier) to each of the packets 600.
(Construed that physical elements associated with Port (Ethernet) to IO-Port (USB) are also translated for encapsulation)), and translating one or more logical protocol elements associated with the at least one electronic communication protocol of the first system component into said standardized bus format using said selected PSCP, the one or more logical protocol elements corresponding to logical layer characteristics of the at least one electronic communication protocol of the first system component (
[0069] Use GEM packet format to carry CPU/PCIe access CMD/DATA from core 200 and local gate 202 and/or node 204 through bus 104 after GEM encapsulation, to far-end local gate 202 and/or node 204 (e.g. CPU 232 access target device 102 from NODE-to-NODE through PCIe, USB, I2C, UART and GPIO interfaces).
Fig. 2, [0092] As a result, the core switch 228 is able to provide the functions of on ingress, the switch 228 receives GEMs from one or more of the root ports 230, local nodes 234, computer 232 and/or other IO ports, processes the GEMs and on egress, forwards and transmits the received GEMs to one or more of the root ports 230, local nodes 234, computer 232 and/or other IO ports. In other words, the switch 228 is able to accept GEM-Packets from multiple sources; perform GEM and Ethernet L2/L3/L4 header parsing, L2 MAC lookup and learning, GEM message and 5-tuple ACL and classification; modify GEM-Header and GEM payload Ethernet header (if necessary) …..
[0101] …..In order to provide data from the devices 102 coupled to the ports 99 of the nodes 204, 208, the nodes 204, 208, 234 construct and transmit burst messages …as GEMS …. through the bus 104 to the other nodes 204, 208 via the root port 230 (of the network 206 of which they are a part or a subnetwork 210 thereof). Further, in order to provide data to the devices 102 ……. nodes 204, 208, 234 receive broadcast message ….as GEMs … from other nodes 204, 208.
(Construed that the nodes 204, 208, 234 with the core switch 228 is able to provide the functions of ingress provides L2/L3/L4 logical layer characteristics or logical protocol elements correspond to logical layer characteristics of the at least one said system component electronic communication protocol).
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
See also [0138] and See also Fig. 31 Steps 3102-3104 cited above,
(Construed that at least logical elements of Ethernet L2/L3/L4 associated with node at the input or logical protocol elements corresponding to logical layer characteristics of the first system component at the input are also translated for encapsulation)), and the one or more logical protocol elements associated with said standardized bus format (
[0140] ……the node 204, 208 is able to terminate PCIe protocol at the node 204, 208, identify the TLP message's memory Read/Write address ranges and map to a GEM identifier and/or the TLP message's associated virtual function ID. The core 200 is able to use the GEM identifier to process the data encapsulated in the packets 600 and/or determine where to forward the GEM packets 600 so they can reach their destination node(s).
See also Fig. 6A, a GEM packet 600, and
FIG. 6B, GEM packet header format comprises a GEM-ID field 614.
(It is construed that the GEM identifier is a logical protocol element associated with the said standardized 104 bus format, and TLP message's associated virtual function ID correspond to logical layer characteristics of the at least one said system component or PCIe device’s PCIe protocol or electronic communication protocol.)); and
transferring the outgoing packet on the at least one communication bus to at least another of the plurality of system components (
Fig. 8 Steps 804, 808,
[0089] As shown in FIG. 8, one or more of the nodes 204, 208 input one or more messages from the one or more of the devices 102 coupled to the one or more of the ports 99 at the step 802. The nodes 204, 208 encapsulate the messages into the generic encapsulation mode (GEM) format for transmission to the central processing core 200 at the step 804. …. if the destination(s) of the input messages is one or more other nodes 204, 208 (outside the core 200), the core 200 decapsulates, processes and re-encapsulates the messages back into the GEM format for broadcast to their destination(s) at the step 808.
[0101] …..In order to provide data from the devices 102 coupled to the ports 99 of the nodes 204, 208, the nodes 204, 208, 234 construct and transmit burst messages …as GEMS …. through the bus 104 to the other nodes 204, 208 via the root port 230 (of the network 206 of which they are a part or a subnetwork 210 thereof)……
[0136] If it does not match, the adaptor 3004 converts the data from the original format to one of the desired formats. The data is then able to be output to the destination port(s)/epoch(s)/device(s) in this different data format/protocol.
See also Fig. 31 Steps 3102-3106,
[0150] As shown in FIG. 31, a source node 204, 208 inputs a message from an input device 102 coupled to one of the ports 99 of the source node 204, 208 at the step 3102. The node 204, 208 encapsulates the message into one or more encapsulated packets 600 at the step 3104 ….. The node 204, 208 transmits the encapsulated packets as a burst message through the core 200 and to a destination node 204, 208 coupled with a destination device 102 at the step 3106.);
wherein the standardized bus format comprises an application format (
[0054] the system, method and device provides a unique intranet system architecture specially defined and optimized for machine automation applications.
[0055] FIG. 1 illustrates a machine automation system 100 according to some embodiments. ….. the system 100 is able to be a part of an automated device such as a self-driving vehicle, an automated industrial machine or an automated self-controlled robot. Alternatively, the system 100 is able to be a part of other machine automation applications. …. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2).
[0070] Finally use GEM packet format for VPN channel application between local-nodes 204, 208 to far nodes 204, 208 through bus 104.).
Regarding claim 9, LEE teaches the electronic CTM of claim 8, wherein the at least another of the plurality of system components is a second system component (Fig. 2 a second Node 204 or 208, Fig. 30 I/O Data Adapter 3004 of a second Node 204/208, See also Fig. 1 machine automation system 100), the method further comprising:
using a second CTM in communication with the second system component to receive the outgoing packet, the second CTM including a second protocol storage submodule configured to store a plurality of PSCPs ([0102] FIG. 30 illustrates a node 204, 208 …. are able to comprise one or more ports 99, an encapsulation/decapsulation engine 3002, an I/O data adaptor 3004, … a node reception MAC 3008, a node transmission MAC 3010, a node memory 3012 and a node processing engine 3014.
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port).
See also [0137] stored in node memory 3014 …. conversion instruction);
using the second CTM and a said PSCP from said second protocol storage submodule to translate the outgoing packet from the standardized bus format to at least a portion of an electronic communication protocol of the second system component (
[0063] The bus 104 is able to encapsulate all input data and internally generated data (e.g. control, operation and management messages) into a generic encapsulation mode (GEM) for transport across the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet. As a result, the input data is able to be encapsulated into the GEM format at each of the nodes as it enters the bus 104 and is routed through the core 200 (where it is decapsulated for processing and re-encapsulated for transmission) and onto its destination node which decapsulates the data back to the original format for egress to the target external device 102 or other destination. This input data is able to be from various sources (e.g. devices 102, CAN 226) input via the ports 99 at the nodes 204, 208 …...
See also [0136-0137]).
Regarding claim 10 is interpreted and rejected for the same reason as set forth for claim 5.
Regarding claim 15, LEE teaches the electronic CTM of claim further comprising:
replacing the first system component with a second system component, using the first CTM to receive at least one electronic communication protocol from the second system component of the plurality of system components (Fig. 2, [0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols.
[0137] …..the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus).
(Construed that replacing the first system component device 102 with a second system component device 102 at a node 204/208 is possible and can be dynamic as user choice));
using the first CTM and a second selected said PSCP to identify the second system component using at least a portion of the at least one electronic communication protocol of the second system component received by the first CTM ([0136] …. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus).
(Construed that replacing the first system component device 102 with a second system component device 102 at a node 204/208 provides a new one electronic communication protocol and node memory storage 3012 dynamically gets updated with new protocol and protocol conversion instruction for CTM-I/O adapter 3004 to determine and execute for protocol conversion));
using the first CTM and the second selected said PSCP from said first protocol storage submodule to translate the at least one electronic communication protocol of the second system component into a said outgoing packet in said standardized bus format associated with the second system component ([0063] ….. the GEM acts as a unique standardized data and message container for transmitting data between nodes and/or to the core 200 via the bus 104 intranet……
[0136] For example, each of the nodes 204, 208 are able to store a local SLA profile (e.g. generated when the device 102 coupled to the node and stored in node memory) for each of the devices 102 and/or ports 99 coupled to the node 204, 208 (and/or epochs/gem identifiers allocated to the node 204, 208) that indicates one or more desired input data formats/protocols. As a result, upon receiving data whose destination is the one of the devices/ports, the I/O data adaptor 3004 of the node 204, 208 is able to determine whether the format/protocol of the received data (e.g. indicated in the GEM header 602 and/or GEM identifier therein encapsulating the data and/or the protocol/format header of the data itself) matches one of the desired input data formats/protocols of the destination device/port (as indicated by the SLA profile of that device/port). If it matches, the adaptor 3004 refrains from any conversion and the data is able to be output. If it does not match, the adaptor 3004 converts the data from the original format to one of the desired formats. The data is then able to be output to the destination port(s)/epoch(s)/device(s) in this different data format/protocol.
See also [0137]); and
transferring the outgoing packet associated with the second system component on the at least one communication bus to at least another of the plurality of system components ([0136] ….. The data is then able to be output to the destination port(s)/epoch(s)/device(s) in this different data format/protocol.).
Regarding claim 16, LEE teaches the electronic CTM of claim 8, wherein the first CTM comprises a plurality of executable instructions stored in a non-transitory computer readable memory device in communication with a processor dedicated to the first CTM ([0102] FIG. 30 illustrates a node 204, 208 …. are able to comprise one or more ports 99, an encapsulation/decapsulation engine 3002, an I/O data adaptor 3004, … a node reception MAC 3008, a node transmission MAC 3010, a node memory 3012 and a node processing engine 3014.
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.).
Regarding claim 17, LEE teaches the electronic CTM of claim 8, wherein the first CTM comprises a plurality of executable instructions stored in a non-transitory computer readable memory device in communication with a processor of a said system component ([0102] FIG. 30 illustrates a node 204, 208 …. are able to comprise one or more ports 99, an encapsulation/decapsulation engine 3002, an I/O data adaptor 3004, … a node reception MAC 3008, a node transmission MAC 3010, a node memory 3012 and a node processing engine 3014.
[0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.).
Regarding claim 18, LEE teaches a non-transitory computer-readable medium containing instructions (Fig. 4, computing device 400 and Memory 404,
[0131] FIG. 4 illustrates a block diagram of an exemplary computing device 400 configured to implement the system 100 according to some embodiments. In addition to the features described above, the external devices 102 are able to include some or all of the features of the device 400 described below. In general, a hardware structure suitable for implementing the computing device 400 includes a network interface 402, a memory 404, a processor 406, I/O device(s) 408 (e.g. reader), a bus 410 and a storage device 412….. The memory 404 is able to be any conventional computer memory known in the art. The storage device 412 is able to include a hard drive, CDROM, CDRW, DVD, DVDRW, flash memory card or any other storage device…... The operating software/applications 430 or function(s)/module(s) thereof are likely to be stored in the storage device 412 and memory 404 and processed as applications are typically processed.
See also Fig. 1, [0055] describing System 100.) for carrying out a method of establishing electronic communications between a plurality of system components within a system (Fig. 1, Fig 1 bus 104, [0055] system 100 comprises one or more external devices 102 operably coupled together with an intelligent controller and sensor intranet bus 104…. Each of the devices 102 is able to be operably wired and/or wirelessly coupled with the bus 104 via one or more bus input/output (IO) ports (see FIG. 2)…
Further, claim 18 is interpreted mutatis mutandis of claim 1 and rejected for the same reason as set forth for claim 1.
Regarding claim 19 is interpreted and rejected for the same reason as set forth for claim 9.
Regarding claim 20 is interpreted and rejected for the same reason as set forth for claim 15.
Regarding claim 24, LEE teaches the electronic CTM of claim 1, wherein the instructions, when executed cause the processor to translate at least a portion of the respective at least one said system component electronic communication protocol into the standardized bus format as an outgoing packet transferable on the at least one communication bus using said selected PSCP
([0103] The node memory 3012 is used to store data used for the node functions described herein and the node processing engine 3014 is used in conjunction with the node memory and other elements to perform the node processing functions described herein.
[0137] the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus.
See also Fig. 31 Steps 3102-3106, [0150] cited for Claim 1).
Regarding claim 25, LEE teaches the electronic CTM of claim 1, wherein the electronic communication translation module is further configured to receive, from the at least another system component of the plurality of system components, electronic communications in said standardized bus format and the instructions when executed cause the processor to translate the received electronic communications in said standardized bus format using at least one said PSCP (
[0137] the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus.
See also Fig. 31 Steps 3102-3110, [0150-0151] cited for Claim 1).
Regarding claim 26, LEE teaches the electronic CTM of claim 1, wherein the plurality of predetermined system component protocols include instructions that provide a mapping for system component communications (
[0135] As described above, in some embodiments in addition to encapsulating/decapsulating messages from devices 102 for burst/broadcast transmission over the bus network 206, 210, the bus 104 is able to provide a protocol conversion mechanism. Specifically, each of the nodes 204, 208 are able to comprise a I/O data adaptor 3004 that is able to intercept and convert the original format of an incoming message (e.g. the format as received from the source device/port(s)) to a different format that is designated for the destination port(s)/epoch(s)/device(s). In particular, the different format is able to be based on the type of device 102 and/or the type of format the device 102 expects to receive via the destination port(s) and/or epoch (e.g. if the device 102 is able to receive data in multiple formats).
[0137] In some embodiments, the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. ).
Regarding claim 27, LEE teaches the electronic CTM of claim 1, wherein the plurality of predetermined system component protocols include an identifier portion usable by the protocol storage submodule to identify a protocol received from the new system component (
[0137] the node 204, 208 further comprises a format/protocol conversion table stored in the node memory 3012 that includes pairs of different types of formats/protocols that are each associated with a set of conversion instructions that when performed will convert a message from the first format/protocol of the pair to the second format/protocol of the pair. Thus, when the adaptor 3004 determines that it needs to convert input data, it is able to determine and execute the appropriate conversion instructions by finding the conversion instructions associated with the pair whose first format/protocol matches that of the input data and whose second format/protocol matches that of one of the desired formats. This format/protocol conversion table it able to include each permutation of pairs of protocols/formats used on the bus 104 and/or dynamically updated with additional conversion instructions each time a new protocol/format is added to the bus (e.g. when a device using that new protocol/format is coupled to the bus)).
Regarding claim 28, LEE teaches the electronic CTM of claim 1, wherein the standardized bus format includes data expressed in a predetermined order (
[0059] Multi-Layer Bus Addressing The bus 104 is able to utilize a multi-layered addressing scheme where the root ports 230, IO ports 99, nodes 204, 208, 234 and/or gates 202 are able to use node, epoch and GEM identifying addresses for directing messages through the bus 104.
Fig. 6A, [0072] As shown in FIG. 6A, a GEM packet 600 is able to comprise a header 602 and a corresponding payload 604. As described above, for message packets the header is able to be a set size (e.g. 8 bytes) and the payload is able to vary in length (e.g. length from 8 bytes to 4 kilobytes).
Fig. 7A, [0087] FIG. 7A illustrates a Broadcast-PHY-Frame 700 according to some embodiments. As shown in FIG. 7A, the Broadcast-PHY-Frame 700 comprises a physical synchronization block for broadcast (PSBbc) 702 and a broadcast framing sublayer frame 704 including a GEM control message 706, one or more GEM packets 600 and a framing sublayer (FS) trailer 708.).
Regarding claim 30, the claim is interpreted and rejected for the same reason as set forth for claim 26.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zhao et al. (CN 110049014 B), describing OpenAPI Conversion System And Method Based On Multi-Modbus Bus Protocol
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, UN C CHO can be reached at 571-272-7919. 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.
/SHAH M RAHMAN/Primary Examiner, Art Unit 2413
Prosecution Insights