CTFR 18/841,796 CTFR 88783 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This office action is in response to Applicant’s communication filed on 02/17/2026. Claims 1-2,4-9,11-18,20-21 have been examined. Claims 3,10,19 are cancelled. Response to Arguments Applicant’s arguments with respect to claims 1,11,12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claims 1- 2, 4-9, 11-18,20-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. With regards to claims 1, 11,12 , the claim recite “ wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of : determining whether a field in the first packet is a field required by an edge network node…..; or , acquiring , from the edge network node, a feature field position for carrying the feature field in the first packet…. , wherein after the determining the field required by the edge network node and carried in the first packet as the feature field, the packet sending method further comprises…..”. It is unclear if the “wherein after determining the field…” limitations are part of the acquiring limitation or they are separate limitations. Therefore, the examiner is unable to determine the metes and bounds of the claim language. For the purpose of examination , the examiner will interpret “wherein after determining the field” as part of the acquiring limitation since there is a comma (,) between the acquiring limitation and the wherein limitation. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1,2,6,11,12,18 are rejected under 35 U.S.C. 103 as being unpatentable over P4 et al. “In-band Network Telemetry (INT) Data plane Specification” 2020-02-14 (P4 hereinafter) in view of Li et al. Publication No. US 2022/0109624 A1 (Li hereinafter) . Regarding claim 1, P4 teaches a packet sending method, comprising: acquiring a feature field in a first packet received from a first domain, wherein the feature field is used for acquiring ancillary data information carried in the first packet, and the feature field indicates at least one of: a carrying position of the ancillary data information and a data type of the ancillary data information ( Section 2 - A set of inter-connected INT devices under the same administration. This specification defines the behavior and packet header formats for interoperability between INT switches from different vendors in an INT domain. The INT devices within the same domain must be configured in a consistent way to ensure interoperability between the devices. Operators of an INT domain should deploy INT Sink capability at domain edges to prevent INT information from leaking out of the domain – Section 5.7 - INT metadata header is 12 bytes long followed by a stack of INT metadata. Each metadata is either 4 bytes or 8 bytes in length. Each INT hop adds the same length of metadata. The total length of the metadata stack is variable as different packets may traverse different paths and hence different number of INT hops.. Upon creation of an INT metadata header, the INT Source must set this value to the maximum number of hops that are allowed to add metadata instance(s) to the packet. Each INT-capable device on the path, including the INT Source as well as INT Transit Hops, must decrement the Remaining Hop Count if and when it pushes its local metadata onto the stack. INT instructions are encoded as a bitmap in the 16-bit INT Instruction field: each bit corresponds to a specific standard metadata as specified in Section 3 - bit0 (MSB): Switch ID, bit1: Level 1 Ingress Port ID (16 bits) + Egress Port ID (16 bits) bit2: Hop latency – bit3: Queue ID (Carrying position) (8 bits) + Queue occupancy (24 bits) Hop ML (5b): Per-hop Metadata Length. This is the length of metadata including the Domain Specific Metadata in 4-Byte words to be inserted at each INT transit hop.).. converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain, sending the second packet to the second domain ( Section 2 - trusted entity that extracts the INT Headers and collects the path state contained in the INT Headers. The INT Sink is responsible for removing INT Headers so as to make INT transparent to upper layers. (Note that this does not preclude having nested or hierarchical INT domains.) The INT Sink can decide to send the collected information to the monitoring system – Section 5.5 - As described above in section 5.4, INT headers and metadata may be carried in an L4 protocol such as TCP or UDP, or in an encapsulation header that includes an L4 header, such as VXLAN. The checksum field in the TCP or UDP L4 header needs to be updated as INT switches modify the L4 payload via insertion/removal of INT headers and metadata. – Section 6.3 - this scenario host1 sends a UDP packet to host2. The ToR switch of host1 (Switch1) acts as the INT source. It alters the UDP destination port to INT_TBD, inserts INT headers before the UDP payload. Switch2 prepends its metadata. Finally, the ToR switch of host2 (Switch3) acts as the INT sink and removes the INT headers and restores the original UDP destination port before forwarding the packet to host2). However, P4 does not explicitly teach wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of: determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position , wherein after the determining the field required by the edge network node and carried in the first packet as the feature field, the packet sending method further comprises: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message; Li teaches wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position, wherein after the determining the field required by the edge network node and carried in the first packet as the feature field, the packet sending method further comprises: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message ( Claim 1 , Abstract - network node receives a packet carrying an SRH, where the SRH includes one or more TLV fields and a TLV processing attribute, the TLV processing attribute indicates whether the network node needs to process the TLV fields included in the SRH, and the network node determines, based on the TLV processing attribute, processing of the TLV fields included in the SRH. In this way, any segment endpoint node on a segment routing network may determine the TLV processing attribute by using the SRH, so as to determine whether the TLV fields included in the SRH need to be processed. – Note : Examiner only covers the determining limitation– see 112 2 nd rejection ). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Li. The motivation for doing so is to allow the system to improve flexibility of packet processing by a node on a segment routing network ( Li - ¶ 0006). Regarding claim 2, P4 does not explicitly teach in the first domain, carrying the feature field in one of: a Special Purpose Label (SPL) located in a Multi-Protocol Label Switching (MPLS) label stack, an extended Special Purpose Label (eSPL) located in the MPLS label stack, a regular label having a non-special purpose label value and located in the MPLS label stack, an indicator reconstructed based on the SPL or the eSPL, a Traffic Class (TC) field in an Internet Protocol version-6 (IPv6) basic header, a Flow Label in the IPv6 basic header, a source address in the IPv6 basic header, a destination address in the IPv6 basic header, a triple Type Length Value (TLV) field in an IPv6 extension header, and an option field in the IPv6 extension header However, Li teaches in the first domain, carrying the feature field in one of: a Special Purpose Label (SPL) located in a Multi-Protocol Label Switching (MPLS) label stack, an extended Special Purpose Label (eSPL) located in the MPLS label stack, a regular label having a non-special purpose label value and located in the MPLS label stack, an indicator reconstructed based on the SPL or the eSPL, a Traffic Class (TC) field in an Internet Protocol version-6 (IPv6) basic header, a Flow Label in the IPv6 basic header, a source address in the IPv6 basic header, a destination address in the IPv6 basic header, a triple Type Length Value (TLV) field in an IPv6 extension header , and an option field in the IPv6 extension header ( Abstract - In the method, the network node receives a packet carrying an SRH, where the SRH includes one or more TLV fields and a TLV processing attribute –¶0003 -segment routing header (SRH) is encapsulated into a packet forwarded on the SRv6 network. The SRH includes a field used to indicate a forwarding path and a plurality of type-length value (TLV) fields. Different TLV fields carry different indication information – ¶0072 - as shown in FIG. 2, the SRH further includes optional TLV fields ( optional type-length-value objects). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Li. The motivation for doing so is to allow the system to improve flexibility of packet processing by a node on a segment routing network ( Li- ¶ 0006). Regarding claim 6, P4 further teaches wherein the converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain comprises: acquiring the ancillary data information carried in the first packet according to the carrying position indicated by the feature field; and converting a format of the feature field and a format of the ancillary data information according to the data plane format of the second domain to obtain the second packet, wherein the second packet comprises the feature field and the ancillary data information after format conversion ( Section 2 - trusted entity that extracts the INT Headers and collects the path state contained in the INT Headers. The INT Sink is responsible for removing INT Headers so as to make INT transparent to upper layers. (Note that this does not preclude having nested or hierarchical INT domains.) The INT Sink can decide to send the collected information to the monitoring system – Section 5.5 - As described above in section 5.4, INT headers and metadata may be carried in an L4 protocol such as TCP or UDP, or in an encapsulation header that includes an L4 header, such as VXLAN. The checksum field in the TCP or UDP L4 header needs to be updated as INT switches modify the L4 payload via insertion/removal of INT headers and metadata. – Section 6.3 - this scenario host1 sends a UDP packet to host2. The ToR switch of host1 (Switch1) acts as the INT source. It alters the UDP destination port to INT_TBD, inserts INT headers before the UDP payload. Switch2 prepends its metadata. Finally, the ToR switch of host2 (Switch3) acts as the INT sink and removes the INT headers and restores the original UDP destination port before forwarding the packet to host2). Regarding claim 11, P4 teaches a non transitory computer-readable storage medium, wherein the non transitory computer-readable storage medium stores a computer program, wherein the computer program, when running on a processor, causes the processor to execute the following operations: acquiring a feature field in a first packet received from a first domain, wherein the feature field is used for acquiring ancillary data information carried in the first packet, and the feature field indicates at least one of: a carrying position of the ancillary data information and a data type of the ancillary data information ( Section 2 - A set of inter-connected INT devices under the same administration. This specification defines the behavior and packet header formats for interoperability between INT switches from different vendors in an INT domain. The INT devices within the same domain must be configured in a consistent way to ensure interoperability between the devices. Operators of an INT domain should deploy INT Sink capability at domain edges to prevent INT information from leaking out of the domain – Section 5.7 - INT metadata header is 12 bytes long followed by a stack of INT metadata. Each metadata is either 4 bytes or 8 bytes in length. Each INT hop adds the same length of metadata. The total length of the metadata stack is variable as different packets may traverse different paths and hence different number of INT hops.. Upon creation of an INT metadata header, the INT Source must set this value to the maximum number of hops that are allowed to add metadata instance(s) to the packet. Each INT-capable device on the path, including the INT Source as well as INT Transit Hops, must decrement the Remaining Hop Count if and when it pushes its local metadata onto the stack. INT instructions are encoded as a bitmap in the 16-bit INT Instruction field: each bit corresponds to a specific standard metadata as specified in Section 3 - bit0 (MSB): Switch ID, bit1: Level 1 Ingress Port ID (16 bits) + Egress Port ID (16 bits) bit2: Hop latency – bit3: Queue ID (Carrying position) (8 bits) + Queue occupancy (24 bits) Hop ML (5b): Per-hop Metadata Length. This is the length of metadata including the Domain Specific Metadata in 4-Byte words to be inserted at each INT transit hop.).. converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain; sending the second packet to the second domain ( Section 2 - trusted entity that extracts the INT Headers and collects the path state contained in the INT Headers. The INT Sink is responsible for removing INT Headers so as to make INT transparent to upper layers. (Note that this does not preclude having nested or hierarchical INT domains.) The INT Sink can decide to send the collected information to the monitoring system – Section 5.5 - As described above in section 5.4, INT headers and metadata may be carried in an L4 protocol such as TCP or UDP, or in an encapsulation header that includes an L4 header, such as VXLAN. The checksum field in the TCP or UDP L4 header needs to be updated as INT switches modify the L4 payload via insertion/removal of INT headers and metadata. – Section 6.3 - this scenario host1 sends a UDP packet to host2. The ToR switch of host1 (Switch1) acts as the INT source. It alters the UDP destination port to INT_TBD, inserts INT headers before the UDP payload. Switch2 prepends its metadata. Finally, the ToR switch of host2 (Switch3) acts as the INT sink and removes the INT headers and restores the original UDP destination port before forwarding the packet to host2). However, P4 does not explicitly teach wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of : determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position, wherein the computer program, when running on the processor, causes the processor to execute the following operations after the determining the field required by the edge network node and carried in the first packet as the feature field: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message; Li teaches wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of : determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position, wherein the computer program, when running on the processor, causes the processor to execute the following operations after the determining the field required by the edge network node and carried in the first packet as the feature field: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message ( Claim 1. Abstract - network node receives a packet carrying an SRH, where the SRH includes one or more TLV fields and a TLV processing attribute, the TLV processing attribute indicates whether the network node needs to process the TLV fields included in the SRH, and the network node determines, based on the TLV processing attribute, processing of the TLV fields included in the SRH. In this way, any segment endpoint node on a segment routing network may determine the TLV processing attribute by using the SRH, so as to determine whether the TLV fields included in the SRH need to be processed.). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Li. The motivation for doing so is to allow the system to improve flexibility of packet processing by a node on a segment routing network ( Li- ¶ 0006). Regarding claim 12, P4 teaches an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the following operations (Fig.1 & 6, ¶ 0009- ¶ 0010) : acquiring a feature field in a first packet received from a first domain, wherein the feature field is used for acquiring ancillary data information carried in the first packet, and the feature field indicates at least one of: a carrying position of the ancillary data information and a data type of the ancillary data information ( Section 2 - A set of inter-connected INT devices under the same administration. This specification defines the behavior and packet header formats for interoperability between INT switches from different vendors in an INT domain. The INT devices within the same domain must be configured in a consistent way to ensure interoperability between the devices. Operators of an INT domain should deploy INT Sink capability at domain edges to prevent INT information from leaking out of the domain – Section 5.7 - INT metadata header is 12 bytes long followed by a stack of INT metadata. Each metadata is either 4 bytes or 8 bytes in length. Each INT hop adds the same length of metadata. The total length of the metadata stack is variable as different packets may traverse different paths and hence different number of INT hops.. Upon creation of an INT metadata header, the INT Source must set this value to the maximum number of hops that are allowed to add metadata instance(s) to the packet. Each INT-capable device on the path, including the INT Source as well as INT Transit Hops, must decrement the Remaining Hop Count if and when it pushes its local metadata onto the stack. INT instructions are encoded as a bitmap in the 16-bit INT Instruction field: each bit corresponds to a specific standard metadata as specified in Section 3 - bit0 (MSB): Switch ID, bit1: Level 1 Ingress Port ID (16 bits) + Egress Port ID (16 bits) bit2: Hop latency – bit3: Queue ID (Carrying position) (8 bits) + Queue occupancy (24 bits) Hop ML (5b): Per-hop Metadata Length. This is the length of metadata including the Domain Specific Metadata in 4-Byte words to be inserted at each INT transit hop.). converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain; sending the second packet to the second domain ( Section 2 - trusted entity that extracts the INT Headers and collects the path state contained in the INT Headers. The INT Sink is responsible for removing INT Headers so as to make INT transparent to upper layers. (Note that this does not preclude having nested or hierarchical INT domains.) The INT Sink can decide to send the collected information to the monitoring system – Section 5.5 - As described above in section 5.4, INT headers and metadata may be carried in an L4 protocol such as TCP or UDP, or in an encapsulation header that includes an L4 header, such as VXLAN. The checksum field in the TCP or UDP L4 header needs to be updated as INT switches modify the L4 payload via insertion/removal of INT headers and metadata. – Section 6.3 - this scenario host1 sends a UDP packet to host2. The ToR switch of host1 (Switch1) acts as the INT source. It alters the UDP destination port to INT_TBD, inserts INT headers before the UDP payload. Switch2 prepends its metadata. Finally, the ToR switch of host2 (Switch3) acts as the INT sink and removes the INT headers and restores the original UDP destination port before forwarding the packet to host2). However, P4 does not explicitly teach wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of : determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position, wherein the processor is configured to run the computer program to further execute the following operations after the determining the field required by the edge network node and carried in the first packet as the feature field: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message; Li teaches wherein the acquiring a feature field in a first packet received from a first domain comprises at least one of : determining whether a field in the first packet is a field required by an edge network node, and determining the field required by the edge network node and carried in the first packet as the feature field ; or , acquiring, from the edge network node, a feature field position for carrying the feature field in the first packet, and acquiring the feature field at the feature field position, wherein the processor is configured to run the computer program to further execute the following operations after the determining the field required by the edge network node and carried in the first packet as the feature field: in a case where the feature field in the first packet does not have a global meaning, when determining that the edge network node receives a target message, identifying the feature field through the edge network node, wherein a source of the target message comprises at least one of: the first domain, pre-configured information of a device, a manual configuration message of a device, and a global configuration message ( Claim 1 & Abstract - network node receives a packet carrying an SRH, where the SRH includes one or more TLV fields and a TLV processing attribute, the TLV processing attribute indicates whether the network node needs to process the TLV fields included in the SRH, and the network node determines, based on the TLV processing attribute, processing of the TLV fields included in the SRH. In this way, any segment endpoint node on a segment routing network may determine the TLV processing attribute by using the SRH, so as to determine whether the TLV fields included in the SRH need to be processed.). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Li. The motivation for doing so is to allow the system to improve flexibility of packet processing by a node on a segment routing network ( Li- ¶ 0006). Regarding claim 18, P4 does not explicitly teach wherein the processor is configured to run the computer program to further execute the following operations: in the first domain, carrying the feature field in one of: a Special Purpose Label (SPL) located in a Multi-Protocol Label Switching (MPLS) label stack, an extended Special Purpose Label (eSPL) located in the MPLS label stack, a regular label having a non-special purpose label value and located in the MPLS label stack, an indicator reconstructed based on the SPL or the eSPL, a Traffic Class (TC) field in an Internet Protocol version-6 (IPv6) basic header, a Flow Label in the IPv6 basic header, a source address in the IPv6 basic header, a destination address in the IPv6 basic header, a triple Type Length Value (TLV) field in an IPv6 extension header, and an option field in the IPv6 extension header However, Li teaches wherein the processor is configured to run the computer program to further execute the following operations: in the first domain, carrying the feature field in one of: a Special Purpose Label (SPL) located in a Multi-Protocol Label Switching (MPLS) label stack, an extended Special Purpose Label (eSPL) located in the MPLS label stack, a regular label having a non-special purpose label value and located in the MPLS label stack, an indicator reconstructed based on the SPL or the eSPL, a Traffic Class (TC) field in an Internet Protocol version-6 (IPv6) basic header, a Flow Label in the IPv6 basic header, a source address in the IPv6 basic header, a destination address in the IPv6 basic header, a triple Type Length Value (TLV) field in an IPv6 extension header , and an option field in the IPv6 extension header (Abstract - In the method, the network node receives a packet carrying an SRH, where the SRH includes one or more TLV fields and a TLV processing attribute – ¶0003 -segment routing header (SRH) is encapsulated into a packet forwarded on the SRv6 network. The SRH includes a field used to indicate a forwarding path and a plurality of type-length value (TLV) fields. Different TLV fields carry different indication information – ¶0072 - as shown in FIG. 2, the SRH further includes optional TLV fields ( optional type-length-value objects). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Li. The motivation for doing so is to allow the system to improve flexibility of packet processing by a node on a segment routing network ( Li- ¶ 0006) . 07-21-aia AIA Claim s 4,5,8,15,16,20,21 are rejected under 35 U.S.C. 103 as being unpatentable over P4 in view of Li further in view of Xu et al. Publication No. US 2021/0044520 A1 ( Xu hereinafter) Regarding claim 4, P4 in view of Li further teaches wherein after the determining the field required by the edge network node and carried in the first packet as the feature field, the packet sending method further comprises ( Li - Claim 1, Abstract). However, P4 in view of Li does not explicitly teach in a case where the feature field has a global meaning, converting, according to the feature field, the first packet into the second packet conforming to the data plane format of the second domain; Xu teaches in a case where the feature field has a global meaning, converting, according to the feature field, the first packet into the second packet conforming to the data plane format of the second domain ( ¶ 0003 - Segment routing (SR) is a method for transferring, by a control plane by using the Interior Gateway Protocol (IGP), a Multiprotocol Label Switching (MPLS) label that has a global meaning or local meaning and is corresponding to an SR router – ¶ 0005 - To facilitate understanding of a segment routing technical solution, the following example is presented for a scenario where a control plane delivers a label having a global meaning- ¶ 0019 - determining, by the first SR router, whether a node segment label of the second SR router is a global label; and ¶ 0020- if the node segment label is a global label – ¶ 0057 - is assumed that A is an ingress SR router, B and D are intermediate SR routers, C is a Non-SR router, and Z is an egress SR router. In this case, when receiving, from A, an MPLS data packet whose top label is a node segment label (that is, "65") corresponding to Z, B finds that a next-hop (that is, element C) in an MPLS forwarding entry corresponding to the MPLS data packet is a non-SR router, and then, B determines whether the node segment label corresponding to Z is a global label. If the node segment label corresponding to Z is a global label; B directly encapsulates the MPLS data packet into an IP tunnel (for example, a GRE tunnel), and for details, refer to FIG. 4); It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). Regarding claim 5, P4 further teaches wherein before the sending the second packet to the second domain, the packet sending method further comprises (Section 2, Section 5.5 and Section 6.3) However, P4 does not explicitly teach wherein before the sending the second packet to the second domain, the packet sending method further comprises: in a case where a feature field in the second packet does not have a global meaning, when determining that a network node in the second domain receives a target message, identifying the feature field through the network node in the second domain, wherein a source of the target message at least comprises one of: the edge network node, pre-configured information of a device, a manual configuration message of a device, and a global configuration message. Xu teaches wherein before the sending the second packet to the second domain, the packet sending method further comprises: in a case where a feature field in the second packet does not have a global meaning, when determining that a network node in the second domain receives a target message, identifying the feature field through the network node in the second domain, wherein a source of the target message at least comprises one of: the edge network node, pre-configured information of a device, a manual configuration message of a device, and a global configuration message (¶ 0086 – ¶ 0089 - if the node segment label is a local label, the processor 81 directly performs a pop operation on the local label. The processor 81 is further configured to: before encapsulating the MPLS data packet into the IP tunnel, learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, an IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel. By using the foregoing solution, correct forwarding of an MPLS data packet is completed in an environment of hybrid networking of an SR router and a non-SR router, thereby meeting a requirement for incremental deployment of SR networks -See Also ¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). Regarding claim 8, P4 further teaches wherein the converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain ( Section 2, Section 5.5 and Section 6.3) comprises: However, P4 does not explicitly teach in a case where the feature field in the first packet does not have a global meaning, learning, through the target message, about the ancillary data information carried after the feature field; and acquiring the ancillary data information carried after the feature field, and converting, according to the data plane format in the second domain, the ancillary data information carried after the feature field to generate the second packet Xu teaches in a case where the feature field in the first packet does not have a global meaning, learning, through the target message, about the ancillary data information carried after the feature field; and acquiring the ancillary data information carried after the feature field, and converting, according to the data plane format in the second domain, the ancillary data information carried after the feature field to generate the second packet (¶ 0086 – ¶ 0089 - if the node segment label is a local label, the processor 81 directly performs a pop operation on the local label. The processor 81 is further configured to: ¶ 008 - before encapsulating the MPLS data packet into the IP tunnel, learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, an IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel. By using the foregoing solution, correct forwarding of an MPLS data packet is completed in an environment of hybrid networking of an SR router and a non-SR router, thereby meeting a requirement for incremental deployment of SR networks -See Also ¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). Regarding claim 15. P4 in view of Xu further teaches wherein the pre-configured information of the device refers to pre-configured device related information ( Xu – ¶ 0055 -the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system – Note : the motivation is the same as in claim 4). Regarding claim 16. P4 in view of Xu further teaches wherein the pre-configured information of the device refers to pre-configured device related information ( Xu -¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system - Note : the motivation is the same as in claim 5). Regarding claim 20, P4 further teaches wherein the processor is configured to run the computer program to further execute the following operations after the determining the field required by the edge network node and carried in the first packet as the feature field: ( Section 2, Section 5.5 and Section 6.3). However, P4 does not explicitly teach in a case where the feature field has a global meaning, converting, according to the feature field, the first packet into the second packet conforming to the data plane format of the second domain; Xu teaches in a case where the feature field has a global meaning, converting, according to the feature field, the first packet into the second packet conforming to the data plane format of the second domain ( ¶ 0003 - Segment routing (SR) is a method for transferring, by a control plane by using the Interior Gateway Protocol (IGP), a Multiprotocol Label Switching (MPLS) label that has a global meaning or local meaning and is corresponding to an SR router – ¶ 0005 - To facilitate understanding of a segment routing technical solution, the following example is presented for a scenario where a control plane delivers a label having a global meaning- ¶ 0019 - determining, by the first SR router, whether a node segment label of the second SR router is a global label; and ¶ 0020- if the node segment label is a global label – ¶ 0057 - is assumed that A is an ingress SR router, B and D are intermediate SR routers, C is a Non-SR router, and Z is an egress SR router. In this case, when receiving, from A, an MPLS data packet whose top label is a node segment label (that is, "65") corresponding to Z, B finds that a next-hop (that is, element C) in an MPLS forwarding entry corresponding to the MPLS data packet is a non-SR router, and then, B determines whether the node segment label corresponding to Z is a global label. If the node segment label corresponding to Z is a global label; B directly encapsulates the MPLS data packet into an IP tunnel (for example, a GRE tunnel), and for details, refer to FIG. 4); It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). Regarding claim 21, P4 further teaches wherein before the sending the second packet to the second domain, the packet sending method further comprises (Section 2, Section 5.5 and Section 6.3) However, P4 does not explicitly teach wherein the processor is configured to run the computer program to further execute the following operation before the sending the second packet to the second domain, the packet sending method further comprises: in a case where a feature field in the second packet does not have a global meaning, when determining that a network node in the second domain receives a target message, identifying the feature field through the network node in the second domain, wherein a source of the target message at least comprises one of: the edge network node, pre-configured information of a device, a manual configuration message of a device, and a global configuration message. Xu teaches wherein the processor is configured to run the computer program to further execute the following operation before the sending the second packet to the second domain, the packet sending method further comprises: in a case where a feature field in the second packet does not have a global meaning, when determining that a network node in the second domain receives a target message, identifying the feature field through the network node in the second domain, wherein a source of the target message at least comprises one of: the edge network node, pre-configured information of a device, a manual configuration message of a device, and a global configuration message (¶ 0086 – ¶ 0089 - if the node segment label is a local label, the processor 81 directly performs a pop operation on the local label The processor 81 is further configured to: before encapsulating the MPLS data packet into the IP tunnel, learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, an IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel. By using the foregoing solution, correct forwarding of an MPLS data packet is completed in an environment of hybrid networking of an SR router and a non-SR router, thereby meeting a requirement for incremental deployment of SR networks -See Also ¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system. ). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009) . 07-21-aia AIA Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over P4 in view of Li further in view of Hu et al. Publication No. WO 2022007550 A1 ( Hu hereinafter) further in view of Kini et al. Publication No. US 2011/0261812 A1 ( Kini hereinafter) Regarding claim 7, P4 does not explicitly teach wherein the carrying position is in a label stack of the first packet, or the carrying position is after the label stack of the first packet; wherein in a case where the carrying position is in the label stack of the first packet, the ancillary data information is carried in at least one of the following forms: an entropy label and an MPLS control word; and in a case where the carrying position is after the label stack of the first packet, the ancillary data information is carried in at least one of the following forms: a generic associated channel header, an MPLS extension header, and an MPLS control word. However, Hu teaches wherein the carrying position is in a label stack of the first packet, or the carrying position is after the label stack of the first packet, in a case where the carrying position is in the label stack of the first packet, the ancillary data information is carried in at least one of the following forms: an entropy label and an MPLS control word ( Page 3 - In the second possible implementation manner, when the first IPv6 packet is a segment routing (segment routing, SR) multiprotocol label switching (multiprotocol label switching, MPLS) packet, or an MPLS packet, the first application feature The information is carried in the multi-protocol label switching MPLS label stack of the first IPv6packet. Specifically, as a possible design, the label stack includes entropy label indication information and entropy label information, where the entropy label indication information is used to indicate the position of the entropy label information in the label stack, and the entropy label information is used to indicate the position of the entropy label information in the label stack. The tag information includes the first application feature information – See Also Page 7 ). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Hu. The motivation for doing so is to allow the system to obtain the first application characteristic information from the entropy label according to the location indicated by the entropy label indicator. This will allow traffic to spread more evenly across multiple path. Kini teaches in a case where the carrying position is after the label stack of the first packet, the ancillary data information is carried in at least one of the following forms: a generic associated channel header, an MPLS extension header, and an MPLS control word ( ¶ 0058 - If the PPW 128 is negotiated with control word processing, then flow moves from block 610 to block 630. The location of the control word is the location in the packet that immediately follows the bottom most label in the PW label stack. The parsing module 310 determines whether the first nibble of the control word is set to 0001. If it is, then flow moves to block 635 and the packet is G-ACh (an MPLS Generic Associated Channel packet) and the location of the packet begins immediately following the control word (4 bytes after the bottom most label in the PW label stack). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Kini. The motivation for doing so is to allow the system to allow correct packet processing and load balancing . 07-21-aia AIA Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over P4 in view of Li further in view of Filsfils et al. Publication No. US 2022/0014460 A1 ( Filsfils hereinafter) Regarding claim 9, P4 further teaches wherein the converting, according to the feature field, the first packet into a second packet conforming to a data plane format of a second domain comprises: acquiring, according to the feature field, the ancillary data information carried in the first packet, and converting the ancillary data information according to the data plane format in the second domain, and generating the second packet according to the converted ancillary data information ( Section 2 - trusted entity that extracts the INT Headers and collects the path state contained in the INT Headers. The INT Sink is responsible for removing INT Headers so as to make INT transparent to upper layers. (Note that this does not preclude having nested or hierarchical INT domains.) The INT Sink can decide to send the collected information to the monitoring system – Section 5.5 - As described above in section 5.4, INT headers and metadata may be carried in an L4 protocol such as TCP or UDP, or in an encapsulation header that includes an L4 header, such as VXLAN. The checksum field in the TCP or UDP L4 header needs to be updated as INT switches modify the L4 payload via insertion/removal of INT headers and metadata. – Section 6.3 - this scenario host1 sends a UDP packet to host2. The ToR switch of host1 (Switch1) acts as the INT source. It alters the UDP destination port to INT_TBD, inserts INT headers before the UDP payload. Switch2 prepends its metadata. Finally, the ToR switch of host2 (Switch3) acts as the INT sink and removes the INT headers and restores the original UDP destination port before forwarding the packet to host2); and However, P4 does not explicitly teach wherein the ancillary data information is carried in one of a flow label field in an IPv6 basic header, a Traffic Class (TC) field in the IPv6 basic header, a hop-by-hop option header in an IPv6 extension header, a destination option header in the IPv6 extension header, a routing header in the IPv6 extension header, a source address in the IPv6 basic header, and a destination address in the IPv6 basic header Filsfils teaches wherein the ancillary data information is carried in one of a flow label field in an IPv6 basic header, a Traffic Class (TC) field in the IPv6 basic header, a hop-by-hop option header in an IPv6 extension header, a destination option header in the IPv6 extension header, a routing header in the IPv6 extension header, a source address in the IPv6 basic header, and a destination address in the IPv6 basic header (¶ 0088 - Node 204 receives IPv6 packet 232 and performs the End.BM function, resulting in MPLS packet 233 being sent. Node 205 receives MPLS packet 233, and performs MPLS forwarding processing resulting MPLS packet 234 being sent. ¶ 0121 - node 4 updates its forwarding information based on a received BGP IPv6 labeled unicast (BGP-LU) advertisement of MPLS label 2, the prefix of B:10::/64, and next hop of 7.7.7.7 (loopback address of node 7). A MPLS label value of 2 represents the "IPv6 Explicit NULL Label." This label value is typically only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header. A BGP speaker uses BGP-LU to attach the MPLS label to an advertised Interior Gateway protocol (IGP) prefix and distribute the MPLS label mapped to the prefix to its peers). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Filsfils. The motivation for doing so is to allow the system to forward of packets through a network that includes interworking among different data plane protocol forwarding domains (Filsfils – ¶ 0031) . 07-21-aia AIA Claim s 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over P4 in view of Li further in view of Xu further in view of Guo et al. Publication No. US 2022/0174013 A1 (Guo hereinafter) Regarding claim 13. P4 does not explicitly teach wherein the target message from the first domain comprises an advertisement message and a negotiation message, wherein the advertisement message refers to a message sent by a network node in the first domain to the edge network node in a form of an advertisement, and the edge network node directly receives the advertisement message; the negotiation message refers to a message accepted by both a network node in the first domain and the edge network node after negotiation, and is a message pre-agreed between the network node in the first domain and the edge network node However, Xu teaches wherein the target message comprises an advertisement message and a negotiation message, wherein the advertisement message refers to a message sent by a network node in the first domain to the edge network node in a form of an advertisement, and the edge network node directly receives the advertisement message; the negotiation message refers to a message accepted by both a network node and the edge network node after negotiation, and is a message pre-agreed between the network node and the edge network node (¶ 0086 - if the node segment label is a local label, the processor 81 directly performs a pop operation on the local label. (0087] The processor 81 is further configured to: ¶ 0088 - before encapsulating the MPLS data packet into the IP tunnel, learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, an IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel. ¶ 0089 - By using the foregoing solution, correct forwarding of an MPLS data packet is completed in an environment of hybrid networking of an SR router and a non-SR router, thereby meeting a requirement for incremental deployment of SR networks -See Also ¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system. ). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). P4 in view of Xu does not explicitly teach the target message from the first domain comprises advertisement message refers to a message sent by a network node in the first domain to the edge network node , However, Guo teaches the target message from the first domain comprises advertisement message refers to a message sent by a network node in the first domain to the edge network node ( ¶ 0162 – 0165- the first network device may send, based on a SID on a communication link, an advertisement message to a network or subnet, to a specified node (edge node) in the network or subnet, so that a corresponding node obtains format indication information of a downstream SID of the node, and TE-FRR is correctly performed based on the format indication information. (0164] The advertisement message may carry one or more pieces of format indication information, for example, carry one or more of the following: first indication information, third indication information, and fifth indication information - The advertisement message may include one or more of the following: a BGP-LS message or an IGP routing message- ¶ 0238 - The second network device receives a first packet. (0239] As a node in the network or subnet, the second network device may receive the first packet from another node in the network or subnet, for example, from the first network device. The first packet may be an SRv6 packet – ¶ 0260 - The second network device updates the destination address in the first packet with the second SID to generate a second packet. (0264] For example, after obtaining the second SID, the second network device may update the destination address in the first packet with the second SID to obtain the second packet, and process the packet based on the second SID. For example, the second network device may forward the packet based on the second SID. In other words, TE-FRR is implemented when the compressed SID exists.) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 in view of Xu to include the teachings of Guo. The motivation for doing so is to allow packet forwarding operations to continue and to improve communication reliability (Guo – ¶ 0014) . Regarding claim 14. P4 does not explicitly teach wherein the target message from the first domain comprises an advertisement message and a negotiation message, wherein the advertisement message refers to a message sent by a network node in the first domain to the edge network node in a form of an advertisement, and the edge network node directly receives the advertisement message; the negotiation message refers to a message accepted by both a network node in the first domain and the edge network node after negotiation, and is a message pre-agreed between the network node in the first domain and the edge network node However, Xu teaches wherein the target message comprises an advertisement message and a negotiation message, wherein the advertisement message refers to a message sent by a network node to the edge network node in a form of an advertisement, and the edge network node directly receives the advertisement message; the negotiation message refers to a message accepted by both a network node and the edge network node after negotiation, and is a message pre-agreed between the network node and the edge network node (¶ 0086 - if the node segment label is a local label, the processor 81 directly performs a pop operation on the local label. (0087] The processor 81 is further configured to: ¶ 0088 - before encapsulating the MPLS data packet into the IP tunnel, learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, an IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel. ¶ 0089 - By using the foregoing solution, correct forwarding of an MPLS data packet is completed in an environment of hybrid networking of an SR router and a non-SR router, thereby meeting a requirement for incremental deployment of SR networks -See Also ¶ 0055 - the first SR router may learn, according to a tunnel encapsulation capability advertisement sent by the second SR router, the IP tunnel encapsulation type that is used when the MPLS data packet is encapsulated into the IP tunnel, for example, a generic routing encapsulation (GRE) tunnel type. Certainly, an IP tunnel encapsulation format that is to be used may also be agreed on in advance between SR routers in a system). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Xu. The motivation for doing so is to allow the system to correctly forward MPLS data packet in hybrid networking environment ( Xu - ¶ 0009). P4 in view of Xu does not explicitly teach the target message from the first domain comprises advertisement message refers to a message sent by a network node in the first domain to the edge network node , However, Guo teaches the target message from the first domain comprises advertisement message refers to a message sent by a network node in the first domain to the edge network node ( ¶ 0162 – 0165- the first network device may send, based on a SID on a communication link, an advertisement message to a network or subnet, to a specified node (edge node) in the network or subnet, so that a corresponding node obtains format indication information of a downstream SID of the node, and TE-FRR is correctly performed based on the format indication information. (0164] The advertisement message may carry one or more pieces of format indication information, for example, carry one or more of the following: first indication information, third indication information, and fifth indication information - The advertisement message may include one or more of the following: a BGP-LS message or an IGP routing message- ¶ 0238 - The second network device receives a first packet. (0239] As a node in the network or subnet, the second network device may receive the first packet from another node in the network or subnet, for example, from the first network device. The first packet may be an SRv6 packet – ¶ 0260 - The second network device updates the destination address in the first packet with the second SID to generate a second packet. (0264] For example, after obtaining the second SID, the second network device may update the destination address in the first packet with the second SID to obtain the second packet, and process the packet based on the second SID. For example, the second network device may forward the packet based on the second SID. In other words, TE-FRR is implemented when the compressed SID exists.) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 in view of Xu to include the teachings of Guo. The motivation for doing so is to allow packet forwarding operations to continue and to improve communication reliability (Guo – ¶ 0014) . 07-21-aia AIA Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over P4 in view of Li further in view of Ghandi et al “ MPLS Data Plane Encapsulation for In-situ OAM Data draft-gandhi-mpls-ioam-01” – September 9,2021 (Ghandi hereinafter) further in view of Juhua et al. Publication No. US 2021/0368429 A1 ( Juhua hereinafter) . Regarding claim 17. P4 does not explicitly teach wherein the ancillary data information carried in the IPv6 extension header comprises a type field for identifying a type of the ancillary data information, data needing to be processed hop-by-hop is stored after a label stack, and In-band Operation Administration and Maintenance (IOAM) data is stored in an extension header after the label stack. However, Ghandi teaches wherein the ancillary data information carried in the [..] extension header comprises a type field for identifying a type of the ancillary data information, data needing to be processed hop-by-hop is stored after a label stack, and In-band Operation Administration and Maintenance (IOAM) data is stored in an extension header after the label stack. ( Section 3.1 - The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data]. The IOAM data fields are carried in the MPLS header as shown in Figure 1. More than one trace options can be present in the IOAM data fields G-ACh [RFC5586] provides a mechanism to transport OAM and other control messages over MPLS data plane. The IOAM G-ACh header [RFC5586] with new IOAM G-ACh type MUST be added immediately after the MPLS label stack in the MPLS header as shown in Figure 1, IOAM-OPT-Type: 8-bit field defining the IOAM Option type – Section 3.2 - An IOAM Presence Indicator MUST be used to indicate the presence of the IOAM data fields in the MPLS header. There are two IOAM types defined in this document: Edge-to-Edge (E2E) and Hop-by-Hop (HbH) IOAM. If only edge nodes need to process IOAM data then E2E IOAM Presence Indicator MUST be used so that intermediate nodes can ignore it. If both edge and intermediate nodes need to process IOAM data then HbH IOAM Presence Indicator MUST be used. Different IOAM Presence Indicators allow to optimize the IOAM processing on intermediate nodes by checking if IOAM data fields need to be processed - Section 5.1 & 5.2 - The HbH IOAM data fields carry the Option-Type(s) that require processing at the intermediate and/or encapsulating and decapsulating nodes. The intermediate node enabled with HbH IOAM function processes the data packet including the IOAM data fields as defined in [I-D.ietf-ippm-ioam-data] when the node recognizes the HbH IOAM Presence Indicator in the MPLS header – Section 7 - The IOAM data fields, including IOAM G-ACh header are added in the MPLS encapsulation immediately after the MPLS header -See Also Fig.3) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 to include the teachings of Ghandi. The motivation for doing so is to allow the system to record operational and telemetry information in the data packet while the packet traverses a path between two nodes in the network (Ghandi – Abstract). P4 in view of Ghandi does not explicitly teach that the extension header is the IPv6 extension header. Juhua teaches the IPv6 extension header (¶ 0013 - In one embodiment, the IPv6 extension header includes a hop-by-hop options header, the hop-by-hop options header includes an option type and option data, the option type is used to identify a type of a network slice identifier, and the option data is used to carry the network slice identifier). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of P4 in view of Ghandi to include the teachings of Juhua. The motivation for doing so is to allow the system to utilize IPv6 extension header in order to improve router performance and efficiency. Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). 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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM. 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, Oscar A Louie can be reached at (571) 270-1684. 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. /YOUNES NAJI/Primary Examiner, Art Unit 2445 Application/Control Number: 18/841,796 Page 2 Art Unit: 2445 Application/Control Number: 18/841,796 Page 3 Art Unit: 2445 Application/Control Number: 18/841,796 Page 4 Art Unit: 2445 Application/Control Number: 18/841,796 Page 5 Art Unit: 2445 Application/Control Number: 18/841,796 Page 6 Art Unit: 2445 Application/Control Number: 18/841,796 Page 7 Art Unit: 2445 Application/Control Number: 18/841,796 Page 8 Art Unit: 2445 Application/Control Number: 18/841,796 Page 9 Art Unit: 2445 Application/Control Number: 18/841,796 Page 10 Art Unit: 2445 Application/Control Number: 18/841,796 Page 11 Art Unit: 2445 Application/Control Number: 18/841,796 Page 12 Art Unit: 2445 Application/Control Number: 18/841,796 Page 13 Art Unit: 2445 Application/Control Number: 18/841,796 Page 14 Art Unit: 2445 Application/Control Number: 18/841,796 Page 15 Art Unit: 2445 Application/Control Number: 18/841,796 Page 16 Art Unit: 2445 Application/Control Number: 18/841,796 Page 17 Art Unit: 2445 Application/Control Number: 18/841,796 Page 18 Art Unit: 2445 Application/Control Number: 18/841,796 Page 19 Art Unit: 2445 Application/Control Number: 18/841,796 Page 20 Art Unit: 2445 Application/Control Number: 18/841,796 Page 21 Art Unit: 2445 Application/Control Number: 18/841,796 Page 22 Art Unit: 2445 Application/Control Number: 18/841,796 Page 23 Art Unit: 2445 Application/Control Number: 18/841,796 Page 24 Art Unit: 2445 Application/Control Number: 18/841,796 Page 25 Art Unit: 2445 Application/Control Number: 18/841,796 Page 26 Art Unit: 2445 Application/Control Number: 18/841,796 Page 27 Art Unit: 2445
Prosecution Insights