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 communications filed on 3/11/2025.
Claims 1-24 are pending.
DETAILED ACTION
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 7, 9, 11-14, 21, 23-24 is/are rejected under 35 U.S.C. 102(A)(2) as being anticipated by Huang et al. (US 20220337497 A1, hereinafter Huang).
Regarding claim 1, Huang discloses a method of in-situ flow information telemetry for an encapsulation node in a Multi- Protocol Label Switching MPLS network, the method comprising:
encapsulating a telemetry indication label and a telemetry information label into a label stack of an MPLS packet (¶[0098], "The head node encapsulates, in the analog service packet 1, the packet header 1 including the in-situ flow metrics information 1, to obtain the detection packet 1"; ¶[0099], "for an MPLS network environment, the packet header 1 may be encapsulated in an MPLS packet header"; ¶[0112], "indication information 1 may be, for example, obtained by extending a reserved field in an in-situ flow metrics header 1 of the packet header 1, for example, adding at least one bit, where information indicated by the at least one bit is the indication information 1. For another example, an identifier may be added to another field in an in-situ flow metrics header 1 of the packet header 1 to indicate the indication information 1");
wherein the telemetry indication label is used to indicate the telemetry information label in the label stack (¶[0112], "indication information 1 may be, for example, obtained by extending a reserved field in an in-situ flow metrics header 1 of the packet header 1, for example, adding at least one bit, where information indicated by the at least one bit is the indication information 1. For another example, an identifier may be added to another field in an in-situ flow metrics header 1 of the packet header 1 to indicate the indication information 1"),
the telemetry information label is used to indicate a telemetry type and telemetry information of in-situ flow information telemetry to be performed (¶[0100], "The in-situ flow metrics information 1 in the packet header 1 is used to indicate each node in the forwarding path 1 to perform in-situ flow metrics on network performance"; ¶[0113], "indication information 1 may be, for example, a value of a flag bit R in the FIH. For example, when the value of the flag bit R is 0, it may indicate that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the flag bit R is 1, it may indicate that the detection packet 1 is active in-situ flow metrics. For another example, the indication information 1 may be a value of a preset field in the in-situ flow metrics header 1. IFIT detection is still used as an example. Referring to FIG. 1, the indication information 1 may be specifically information indicated by a header type indicator HTI, and a value of the HIT can indicate whether the in-situ flow metrics header 1 includes a flow instruction extension header FIEH field or a type of an FIEH. Specifically, when the value of the HIT indicates that the in-situ flow metrics header 1 does not include an FIEH or includes an FIEH whose type is passive in-situ flow metrics, it is determined that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the HIT indicates that the in-situ flow metrics header 1 includes an FIEH whose type is active in-situ flow metrics, it is determined that the detection packet 1 is active in-situ flow metrics"; ¶[0186], "the in-situ flow metrics may be IFIT in-situ flow metrics, IOAM in-situ flow metrics, or INT in-situ flow metrics").
Regarding claim 7, Huang discloses a method of in-situ flow information telemetry for a telemetry node in a Multi- Protocol Label Switching (MPLS) network, the method comprising:
parsing a label stack of a received MPLS packet (¶[0122], "The head node may further send the detection packet 1 to the intermediate node"; ¶[0124], "The intermediate node 1 performs in-situ flow metrics on the network performance based on the in-situ flow metrics information 1 in the detection packet 1"; ¶[0112], indication information is transmitted in a header, therefore, parsing the header is inherent; ¶[0099], "for an MPLS network environment, the packet header 1 may be encapsulated in an MPLS packet header");
in response to the label stack comprising a telemetry indication label, determining a telemetry information label in the label stack based on the telemetry indication label (¶[0124], "The intermediate node 1 performs in-situ flow metrics on the network performance based on the in-situ flow metrics information 1 in the detection packet 1"; ¶[0112], "indication information 1 may be, for example, obtained by extending a reserved field in an in-situ flow metrics header 1 of the packet header 1, for example, adding at least one bit, where information indicated by the at least one bit is the indication information 1. For another example, an identifier may be added to another field in an in-situ flow metrics header 1 of the packet header 1 to indicate the indication information 1" ),
wherein the telemetry indication label is used to indicate the telemetry information label in the label stack (¶[0112], "indication information 1 may be, for example, obtained by extending a reserved field in an in-situ flow metrics header 1 of the packet header 1, for example, adding at least one bit, where information indicated by the at least one bit is the indication information 1. For another example, an identifier may be added to another field in an in-situ flow metrics header 1 of the packet header 1 to indicate the indication information 1" ),
the telemetry information label is used to indicate a telemetry type and telemetry information of in-situ flow information telemetry to be performed (¶[0100], "The in-situ flow metrics information 1 in the packet header 1 is used to indicate each node in the forwarding path 1 to perform in-situ flow metrics on network performance"; ¶[0113], "indication information 1 may be, for example, a value of a flag bit R in the FIH. For example, when the value of the flag bit R is 0, it may indicate that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the flag bit R is 1, it may indicate that the detection packet 1 is active in-situ flow metrics. For another example, the indication information 1 may be a value of a preset field in the in-situ flow metrics header 1. IFIT detection is still used as an example. Referring to FIG. 1, the indication information 1 may be specifically information indicated by a header type indicator HTI, and a value of the HIT can indicate whether the in-situ flow metrics header 1 includes a flow instruction extension header FIEH field or a type of an FIEH. Specifically, when the value of the HIT indicates that the in-situ flow metrics header 1 does not include an FIEH or includes an FIEH whose type is passive in-situ flow metrics, it is determined that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the HIT indicates that the in-situ flow metrics header 1 includes an FIEH whose type is active in-situ flow metrics, it is determined that the detection packet 1 is active in-situ flow metrics"; ¶[0186], "the in-situ flow metrics may be IFIT in-situ flow metrics, IOAM in-situ flow metrics, or INT in-situ flow metrics");
determining, based on the telemetry information label, a telemetry type and telemetry information of in-situ flow information telemetry to be performed (¶[0100], "The in-situ flow metrics information 1 in the packet header 1 is used to indicate each node in the forwarding path 1 to perform in-situ flow metrics on network performance"; ¶[0113], "indication information 1 may be, for example, a value of a flag bit R in the FIH. For example, when the value of the flag bit R is 0, it may indicate that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the flag bit R is 1, it may indicate that the detection packet 1 is active in-situ flow metrics. For another example, the indication information 1 may be a value of a preset field in the in-situ flow metrics header 1. IFIT detection is still used as an example. Referring to FIG. 1, the indication information 1 may be specifically information indicated by a header type indicator HTI, and a value of the HIT can indicate whether the in-situ flow metrics header 1 includes a flow instruction extension header FIEH field or a type of an FIEH. Specifically, when the value of the HIT indicates that the in-situ flow metrics header 1 does not include an FIEH or includes an FIEH whose type is passive in-situ flow metrics, it is determined that the detection packet 1 is passive in-situ flow metrics. On the contrary, when the value of the HIT indicates that the in-situ flow metrics header 1 includes an FIEH whose type is active in-situ flow metrics, it is determined that the detection packet 1 is active in-situ flow metrics"; claim 17, "wherein the in-situ flow metrics are in-situ flow information telemetry IFIT, in-situ operations administration and maintenance IOAM in-situ flow metrics, or in-band network telemetry INT in-situ flow metrics"; ¶[0124], "The intermediate node 1 performs in-situ flow metrics on the network performance based on the in-situ flow metrics information 1 in the detection packet 1"); and
performing the in-situ flow information telemetry based on the telemetry type and the telemetry information (¶[0124], "The intermediate node 1 performs in-situ flow metrics on the network performance based on the in-situ flow metrics information 1 in the detection packet 1").
Regarding claim 9, Huang discloses the method of claim 7, further comprising: forwarding the MPLS packet (¶[0122], "The head node may further send the detection packet 1 to the intermediate node").
Regarding claim 11, Huang discloses the method of claim 7, wherein, the telemetry type comprises an Alternate Marking type, and/or an In situ Operations, Administration, and Maintenance type (¶[0205], "The in-situ flow metrics are IFIT in-situ flow metrics, IOAM in-situ flow metrics, or INT in-situ flow metrics").
Regarding claim 12, Huang discloses an encapsulation node applied to a Multi-Protocol Label Switching (MPLS) network, comprising one or more memories and one or more processors, wherein the one or more memories store a computer program executable by the one or more processors to cause the one or more processors to implement operations of in-situ flow information telemetry (¶[0212], "a memory 1401 and a processor 1402 communicating with the memory 1401. The memory 1401 includes computer-readable instructions. The processor 1402 is configured to execute the computer-readable instructions, so that the first network device 1400 performs the methods on a side of the head node").
The remaining limitations of claim 12 are similar in scope to those of claim 1. Therefore, claim 12 is rejected for the same reasons as set forth in the rejection of claim 1, above.
Regarding claim 13, Huang discloses a telemetry node applied to a Multi-Protocol Label Switching (MPLS) network, comprising one or more memories and one or more processors, wherein the one or more memories store a computer program executable by the one or more processors causing implementation operations of in-situ flow information telemetry (¶[0213], "second network device 1500 includes a memory 1501 and a processor 1502 communicating with the memory 1501. The memory 1501 includes computer-readable instructions. The processor 1502 is configured to execute the computer-readable instructions, so that the second network device 1500 performs the methods on a side of the intermediate node 1, the intermediate node 2, or the end node in the embodiments").
The remaining limitations of claims 13, 21, and 23 are similar in scope to those of claims 7, 9, and 11. Therefore, claims 13, 21, and 23 are rejected for the same reasons as set forth in the rejection of claims 7, 9, and 11 above.
Regarding claim 14, Huang discloses a non-transitory computer readable medium having a computer program stored thereon, wherein the method of in-situ flow information telemetry of claim 1 is implemented when the computer program is executed by a processor (¶[0212], "a memory 1401 and a processor 1402 communicating with the memory 1401. The memory 1401 includes computer-readable instructions. The processor 1402 is configured to execute the computer-readable instructions, so that the first network device 1400 performs the methods on a side of the head node").
Regarding claim 24, Huang discloses a computer readable medium having a computer program stored thereon, wherein the method of in-situ flow information telemetry of claim 7 is implemented when the computer program is executed by a processor (¶[0213], "second network device 1500 includes a memory 1501 and a processor 1502 communicating with the memory 1501. The memory 1501 includes computer-readable instructions. The processor 1502 is configured to execute the computer-readable instructions, so that the second network device 1500 performs the methods on a side of the intermediate node 1, the intermediate node 2, or the end node in the embodiments").
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) 10 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20220337497 A1) in view of Gandhi et al. (US 20230031423 A1, hereinafter Gandhi).
Regarding claim 10, Huang discloses the method of claim 7.
Huang does not disclose removing the telemetry indication label and the telemetry information label from the MPLS packet.
Gandhi discloses removing the telemetry indication label and the telemetry information label from the MPLS packet (¶[0061], "encapsulating, by the first node, the packet with a Multiprotocol Label Switching (MPLS) header that includes an entropy label, the entropy label including a flag indicating the monitoring operation to be performed. For instance, the node 106(1) may encapsulate the packet 108 based at least in part on determining to perform the monitoring operation. In some examples, the monitoring operation may comprise, or be associated with, a packet loss measurement, a telemetry operation, an OAM operation, a determination of a latency between the first node and the second node, a determination of whether a TSN lifetime has expired, an IOAM operation, or the like. Additionally, in some examples, the flag may be included in at least one of a TTL field, traffic class field, entropy label control field, or other field of the entropy label or entropy label indicator or some other label of the MPLS header (e.g., MPLS stack)"; ¶[0043], "in some examples the node 106(3) (e.g., egress decapsulating node) may remove the MPLS encapsulation before sending the packet 108 to its destination").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Huang in view of Gandhi for removing the telemetry indication label and the telemetry information label from the MPLS packet.
One of ordinary skill in the art would have been motivated because it would enable monitoring to be performed using existing packets without disturbing actual communications.
Regarding claim 22, Huang discloses the telemetry node of claim 13.
The remaining limitations of claim 22 are similar in scope to those of claim 10. Therefore, claim 22 is rejected for the same reasons as set forth in the rejection of claim 10, above.
Allowable Subject Matter
Claims 2-6, 8, and 15-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
WO 2022132208 A1, which discloses "the node encapsulates a header and node data list of the IOAM header and data structure 501 in the payload data of the UDP header packet structure 400. The UDP header packet structure 400 is an extension header of the modified packet (i.e. , the IPv6 header 200 and the SRH 300). In one embodiment, the encapsulated header and node data list is one of an in-situ operations, administration and management (IOAM) header" (¶[0086]).
US 11979317 B2, which discloses "adding ancillary data within the MPLS stack of the data packet by adding, based on the IPI and the BPI, an in-stack extension header to the MPLS stack of the data packet that corresponds to a label stack entry that includes in-stack data within the MPLS stack, wherein the ancillary data includes at least one member selected from the group consisting of a network slice identifier, an In-Situ OAM data presence indicator, a data flow identifier, an in-band telemetry indicator, an alternate-marking method for delay/loss measurement identifier, a fragmentation identifier, an already fast-rerouted packet identifier, a timestamp presence indicator, and a network resource partition identifier" (claim 1).
US 20210135986 A1, which discloses "at least one of the one or more MPLS extension headers added to the packet support an in-network service that is not supported by the MPLS network. For example, in-network services that the method can add to an MPLS network include, but are not limited to: a network service header (NSH) service, an in-situ operations, administration, and maintenance (IOAM) service, a segment routing (SR) service; and a network programming service" (¶[0009]).
US 20200162375 A1, which discloses "embedding, at an encapsulation node in an in-situ operation administration and maintenance, IOAM, domain, IOAM information in a segment routing multi-protocol label switching, SR MPLS, header" (claim 1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BORIS D GRIJALVA LOBOS whose telephone number is (571)272-0767. The examiner can normally be reached M-F 10:30AM to 6:30PM 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, Brian Gillis can be reached at 571-272-7952. 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.
/BORIS D GRIJALVA LOBOS/ Primary Patent Examiner, Art Unit 2446
Prosecution Insights