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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 14 is 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.
Regarding claim 14, lines 12-19, the claim recites forwarding the modified packet or frame . . . while the one more gates . . . are open state . . . and while the one or more gates . . . are closed state. The manner in which the modified packet is initialed forward and then either conditionally forwarded or not according to the open or closed status of the gate is unclear from the claim. The claim appears to forward the modified packet, but at the same time either forward or block the forwarding of the modified packet according to the open or closed state is unclear form the context of the claim. Further consideration and clarification is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mardmoeller et al. (US 2020/0389405 A1), hereinafter referred to as D1, in view of Varga et al., “IEEE 802.1CB Improvements, FRER, Improvements of Replication and Elimination Functions,” July 16, 2019, pp. 1-13, applicant admitted prior art, hereinafter referred to as D2.
Regarding claims 1 and 15, D1 discloses time sensitive network, which comprises:
obtaining by a gate controller downstream information indicating which application instance is downstream active needing to send a stream of packets or frames in a downstream direction through the network (Referring to Figures 10 and 11, controller comprises a receive path and transmit path (downstream). The controller (gate controller) manages according to the gate control list (downstream information) the transmission selection and traffic shaping queues for the transmission (downstream) of frames for data transmission session (interpreted as an application per paragraph 0102 and 0103). See paragraph 0076, 0077, and 0080.); and
based on the downstream information, controlling by the gate controller a gate within a gate cluster that is associated with the downstream active application instance to be open state which operates to forward the stream of packets or frames in the downstream direction (Referring to Figures 10 and 11, a set of gate controllers 39, each controller 39 arranged to read a respective individual gate control list 7 and issue a control signal 40 to a corresponding gate 4. The individual gate control list 7 includes M entries 10 (where M≥1), each entry comprising a gate time 11 and control data 12. The control data 12 can indicate a gate state, i.e., open or closed, and/or whether the entry is the end of the list (EOL). Closed and open may be represented by logical ‘0’ and ‘1’ respectively. End of list may be represented by ‘1’. See paragraphs 0080, 0084, and 0085. In this manner the gate controller controls the open and close position of a gate for forwarding when the application instance is downstream active needs to send a stream of frames in a downstream direction through the network.)
D1 does not disclose an application cluster and forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoint paths through the network.
D2 teaches moving towards virtualized environments utilizing FRER in a cloud-based scenario in which a Talker/Listener (application cluster) is moved to the cloud. The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claims 2 and 16, D1 does not disclose obtaining by the gate controller upstream information indicating which one or more application instances in the application cluster are upstream active needing to receive a stream of packets or frames in an upstream direction from the network; and based on the upstream information, controlling by the gate controller one or more gates within the gate cluster that are associated with the upstream active one or more application instances to be open state which operates to forward the stream of packets or frames from one or more packet or frame elimination entities, which are associated with the one or more gates and eliminate replicated packets or frames in the stream, in the upstream direction to the upstream active one or more application instances.
D1 teaches the gate controller controlling one or more gates with the gate cluster that associated with the application for frames. See rejection of claim 1. D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claims 3 and 17, the primary reference further teaches wherein the controlling to change any of the gates between different ones of the open and closed states based on the downstream information is performed in a time synchronized manner (Referring to Figures 1 and 2, a set of gate controllers 39, each controller 39 arranged to read a respective individual gate control list 7 and issue a control signal 40 to a corresponding gate 4. The individual gate control list 7 includes M entries 10 (where M≥1), each entry comprising a gate time 11 and control data 12. The control data 12 can indicate a gate state, i.e., open or closed, and/or whether the entry is the end of the list (EOL). Closed and open may be represented by logical ‘0’ and ‘1’ respectively. End of list may be represented by ‘1’. See paragraphs 0080, 0084, and 0085. In this manner the gate controller controls the open and close position of a gate for forwarding when the application instance is downstream active needs to send a stream of frames in a downstream direction through the TSN network (time synchronized). See paragraph 0075.)
Regarding claims 4 and 18, the primary reference further teaches wherein the controlling by the gate controller of the gate within the gate cluster that is associated with the downstream active application instance to be open state, operates to allow only a single one of the gates in the gate cluster to be in the open state at a time which operates to forward the stream of packets or frames (Referring to Figures 1 and 2, a set of gate controllers 39, each controller 39 arranged to read a respective individual gate control list 7 and issue a control signal 40 to a corresponding gate 4. The individual gate control list 7 includes M entries 10 (where M≥1), each entry comprising a gate time 11 and control data 12. The control data 12 can indicate a gate state, i.e., open or closed (controllable to allow only a single open gate), and/or whether the entry is the end of the list (EOL). Closed and open may be represented by logical ‘0’ and ‘1’ respectively. End of list may be represented by ‘1’. See paragraphs 0080, 0084, and 0085. In this manner the gate controller controls the open and close position of a gate for forwarding when the application instance is downstream active needs to send a stream of frames in a downstream direction through the TSN network (time synchronized). See paragraph 0075.)
D1 does not disclose in the downstream direction to the associated packet or frame replication entity for replication and transmission via the at least two disjoint paths through the network.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claims 5 and 19, D1 does not disclose wherein the packet or frame replication entity replicates the packets or frames in the stream for transmission via the at least two disjoint paths through a Time-Sensitive Networking, TSN, network.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claims 6 and 20, D1 does not disclose triggering by the gate controller the packet or frame replication entity to reset a sequence number generation function based on the downstream information.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (reset), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 7, the primary reference further teaches identifying which one of the gates within the gate cluster is associated with the downstream active application instance and needs to be controlled by the gate controller to be open state (Referring to Figures 1 and 2, a set of gate controllers 39, each controller 39 arranged to read a respective individual gate control list 7 and issue a control signal 40 to a corresponding gate 4. The individual gate control list 7 includes M entries 10 (where M≥1), each entry comprising a gate time 11 and control data 12. The control data 12 can indicate a gate state, i.e., open or closed (controllable to allow only a single open gate), and/or whether the entry is the end of the list (EOL). Closed and open may be represented by logical ‘0’ and ‘1’ respectively. End of list may be represented by ‘1’. See paragraphs 0080, 0084, and 0085. In this manner the gate controller controls the open and close position of a gate for forwarding when the application instance is downstream active needs to send a stream of frames in a downstream direction through the TSN network (time synchronized). See paragraph 0075.)
D1 does not disclose triggering the packet or frame replication entity which is associated with the identified gate, to reset the sequence number generation function.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (reset), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 8, the primary reference further teaches the identified gate is controlled to change from a closed state to the open state (Referring to Figures 1 and 2, a set of gate controllers 39, each controller 39 arranged to read a respective individual gate control list 7 and issue a control signal 40 to a corresponding gate 4. The individual gate control list 7 includes M entries 10 (where M≥1), each entry comprising a gate time 11 and control data 12. The control data 12 can indicate a gate state, i.e., open or closed (controllable to allow only a single open gate), and/or whether the entry is the end of the list (EOL). Closed and open may be represented by logical ‘0’ and ‘1’ respectively. End of list may be represented by ‘1’. See paragraphs 0080, 0084, and 0085. In this manner the gate controller controls the open and close position of a gate for forwarding when the application instance is downstream active needs to send a stream of frames in a downstream direction through the TSN network (time synchronized). See paragraph 0075.)
D1 does not disclose the triggering of the packet or frame replication entity, which is associated with the identified gate, to reset the sequence number generation function is performed before gate control.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (resetting), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2; thereby, controlling ordering of gates either before or after sequencing recovery. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 9, D1 does not disclose the triggering by the gate controller the packet or frame replication entity to reset the sequence number generation function, is performed using a frerSeqRevyReset managed object.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listener (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (interpreted as claimed managed object), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2; thereby, controlling ordering of gates either before or after sequencing recovery. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 10, D1 does not disclose triggering the packet or frame replication entity to reset the sequence number generation function responsive to no packets or frames being received by the packet or frame replication entity in a threshold time interval.
D2 teaches moving towards virtualized environments utilizing FRER in a cloud-based scenario in which a Talker/Listener (application cluster) is moved to the cloud. The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function. IEEE 802.1CB also defines a timeout mechanism for the elimination function in order to cope with some networking scenarios that results in unnecessarily dropped frames (e.g., if the elimination function somehow gets out of step with its corresponding Sequence generation function; if a Sequence generation function is reset; etc.). If a timeout occurs before receiving a packet from any of the Member Streams that has a “sequence_number” that is within the history window, the “SequenceHistory” and the history window are reset, and the elimination function is allowed to accept the next packet received for any of the Member Streams, regardless of the value of its “sequence_number” sub-parameter. Once this next packet is received, its “sequence_number” is added to the “SequenceHistory” and the history window is updated accordingly. The “GenSeqNum” is initialized to 0 whenever the function is reset, and is incremented by 1 after its value is copied to the “sequence_number” sub-parameter. When incremented past its maximum value, the new value is 0. “SequenceGenerationReset”: The “SequenceGenerationReset” function is called whenever a “resets all FRER functions event” or a management order occurs. It resets “GenSeqNum” (sets its value to 0).
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 11, D1 does not disclose wherein: the gate controller and the gate cluster are part of a packet or frame replication entities domain.
D1 teaches the gate controller and gate clusters. D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listerner (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (interpreted as claimed managed object), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2; thereby, controlling ordering of gates either before or after sequencing recovery. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 12, D1 does not disclose replicating by the packet or frame replication entity the packets or frames in the stream received from the gate associated with the downstream active application instance to create Time-Sensitive Networking, TSN, streams for transmission via the at least two disjoint paths through the network.
D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listerner (downstream) (application clusters) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions) for TSN networks. The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function) (interpreted as claimed managed object), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2; thereby, controlling ordering of gates either before or after sequencing recovery. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Regarding claim 13, D1 does not disclose receiving by the gate controller from an application-cluster controller, ACC, that controls redundancy of the application instances that are concurrently executing, upstream information indicating which one or more application instances in the application cluster are upstream active needing to receive a stream of packets or frames in an upstream direction from the network; and based on the upstream information, controlling by the gate controller one or more gates within the gate cluster that are associated with the upstream active one or more application instances to be open state which operates to forward the stream of packets or frames from one or more packet or frame elimination entities, which are associated with the one or more gates and eliminate replicated packets or frames in the stream, in the upstream direction to the upstream active one or more application instances.
D1 teaches the gate controller controlling one or more gates with the gate cluster that associated with the application for frames to be in an open or closed state to forward frames. See rejection of claim 1. D2 teaches moving towards virtualized environments utilizing FRER, replication and elimination functions, in a cloud-based scenario in which a Talker (upstream)/Listerner (downstream) (application clusters, interpreted as ACC) is moved to the cloud for applications involving Talkers and Listeners (upstream and downstream directions). The FRER works inside the cloud and the FRER can be an instance in a Ctrl-cluster. The cloud actions include multiple VMs/instance (application cluster). See slide 3. By definition, the Frame Replication and Elimination for Reliability (FRER) as defined in IEEE Std 802.1CB-2017, cited by D2, is applied in order to reduce the probability of frame/packet loss due to equipment failures when transferring a TSN stream via a bridged (TSN) network, thereby providing for an end-to-end reliability mechanism. This increased reliability (and availability) is achieved by transmitting multiple copies of the frames/packets belonging to a TSN stream through different/independent paths in the network (forwarding from the downstream active application instance to an associated packet or frame replication entity for replication and transmission via at least two disjoin paths through the network). The FRER functionality is based on two basic mechanisms, namely (1) the stream splitting function (SSF), which contains sequence numbering and replicating every frame/packet in a first entity (either an end station or a bridge), and (2) the sequence recovery function (SRF), which eliminates frame/packet replicates and re-/merges (re-/joins) them into a single (recovered/reconstituted) stream in a second entity (either an end station or a bridge). That is, the FRER functionality transforms a stream into one or more linked member streams, thus making the original stream a compound stream. Accordingly, the FRER functionality is based on (the handling or processing of) a compound stream composed of one or more member streams (between SSF and SRF). As defined in the IEEE Std 802.1 TSN standard family, five functions form the central functionality of the FRER mechanism, namely (in the order from higher layers toward lower layers) sequencing function (including sequence generation function and sequence recovery function), stream splitting function, individual recovery function, sequence encode/decode function and stream identification function.
The claims are rejected as being unpatentable over D1 in view of D2. The claims represent the application of a well-known technique in a well-known system. D1 teaches the well-known TSN system with gate controllers to perform traffic shaping. D2 teaches the well-known technique of moving TSN system to the cloud comprising FRER functionality. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of moving TSN service to the cloud as taught by D2 with the well-known TSN traffic shaping system of D2. One of ordinary skill in the art before the effective filing date of the invention would have done so to virtualize TSN service with traffic shaping control; thereby, reducing implementation costs and improving system application by managing individual queues.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sivasiva et al. (US 2023/0379081 A1) - There are provided measures for enabling/realizing FRER support of a wireless communication system operable as a TSN bridge, such as e.g. FRER support of a 5GS TSN bridge.
STEINDL (US 2022/0050442 A1) - A method and communication system for transmitting time-critical data, wherein selected datagrams are assigned to data streams and transmitted via paths for the data streams, where reservation requests are transmitted to a higher-level communication controller to reserve resources to be provided by the communication devices for transmitting data streams.
BRUCKNER (US 2023/0031236 A1) - An industrial communication network configured according to the standards of the IEEE 802.1 TSN working group is used, and at least one guarantee defined in the standards of the IEEE 802.1 TSN working group is assigned for the data packet in that a frame which contains the data packet.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
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, Yemane Mesfin can be reached at 571-272-3927. 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.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462