DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This is in response to an amendment/response filed 4/24/2026.
Claims 4 and 13 have been cancelled.
No claims have been added.
Claims 1-3, 5-12, and 14-20 are now pending.
Response to Arguments
Applicant's arguments filed 4/24/2026 have been fully considered but they are not persuasive.
On page 15-21 of the remarks, in regard to the independent claim(s), the Applicant disagrees with the rejection under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20230269151 (hereinafter “Wang”) in view of Liu et al. WO 2022166773 (hereinafter “Liu”) and in further view of Ben et al. US 20230155928 (hereinafter “Ben”).
Specifically, the Applicant remarks:
Wang does not disclose an in-situ flow detection method that follows service packet forwarding as claimed in the present application. Wang does not depend on forwarding of a multicast data packet, to test a performance parameter actively. Therefore, the first packet and second packet in Wang are independent of a multicast data packet (i.e., service packet in the present application). Wang does not include a field for service data payload. Wang fails to disclose "in-situ flow detection method for a Generalized Bit Index Explicit Replication (G-BIER) service packet". The "first packet" disclosed in Wang, the "raw multicast service packet" in amended claim 1 of the present application, and the "G-BIER packet" disclosed in Liu are all different.
Wang and Liu fail to disclose "in response to network device serving as a Bit Forwarding Ingress Router (BFIR) of a G-BIER domain, forwarding a G-BIER service packet in the G-BIER domain when receiving a raw multicast service packet to be subjected to in -situ flow detection"
Wang does not disclose "wherein the in-situ flow detection information further comprises at least one path detection parameter"
Wang does not disclose "if G-BIER in-situ flow detection is supported, updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet when receiving the G-BIER service packet and forwarding the updated G-BIER service packet in the G-BIER domain"
Ben does not disclose "reporting the detection data related to the in-situ flow detection information in the in-situ flow detection option carried in the updated G-BIER service packet to the analyzer"
The Examiner respectfully disagrees.
Regarding (1), the applicant continues to argue that Wang does not teach "in-situ flow detection method for a Generalized Bit Index Explicit Replication (G-BIER) service packet". First, the applicant mentions that Wang does not disclose an in-situ flow detection method that follows service packet forwarding. Wang teaches IOAM which the Examiner interpreted as a type of IFIT and the Examiner further interpreted IFIT as a standardized type of in-situ flow detection. In addition, the Examiner interpreted "service packet forwarding" or (raw multicast service packet forwarding) as forwarding a network data packet from one source to a group of receivers. FIG. 2 clearly shows R1 sending the first packet to R4 and R5 which clearly teaches "multicast" forwarding. The applicant further argues that Wang does not include a field for service data payload. The Examiner disagrees because a service data payload can be broadly interpreted as data used to measure performance metrics and Wang clearly teaches this as the first packet includes space to carry a "STAMP test packet". The applicant argues that the "STAMP test packet" in Wang does not include a field for service data payload - this argument is not persuasive as the "STAMP test packet" can be interpreted as a "service data payload". "Service data payload" is a broader way to describe a payload such as a "STAMP test packet".
Regarding (2), Wang clearly teaches a BIER forwarding a BIER service packet including "STAMP test packet" to several BFERs (which maps to multicast forwarding) after receiving the packet.
Regarding (3), in [0067], Wang mentions "in performance measurement of a delay or jitter, a timestamp in the STAMP test packet is used to carry a sending timestamp, to calculate the delay" and the specification of the instant application mentions "the path detection parameter at least includes a delay parameter". Therefore, "path detection parameter" is taught by Wang.
Regarding (4), in [0066], Wang mentions that the "IOAM option and data space field" on the forwarded packet can be used to "record a node included in the path" which maps to "updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet when receiving the G-BIER service packet and forwarding the updated G-BIER service packet in the G-BIER domain". The applicant further argues that Wang does not teach updating the service packet as it gets forwarded. The Examiner disagrees. Wang clearly teaches updating IOAM option and data space field included in the received first packet ([0070]) and Wang refers to the updated packet as "fourth packet". The updated packet is then forwarded to another node.
Regarding (5), the applicant mentions that Ben does not disclose "an intermediate node between the ingress node and the egress node reporting to the network control engine". FIG. 1 clearly shows an intermediate node between CSG and RSG that reports an update to the Network Control Engine (NCE) and in [0077], Ben further mentions "If the packet loss, the delay, or the retransmission exceeds the threshold, the NCE delivers an IFIT indication to a head node of each subnet, so that the head node adds an IFIT header to a packet. Each node may subsequently report information collected based on the IFIT header to the NCE, and the reported information is referred to as flow table data" which maps to "reporting the detection data related to the in-situ flow detection information in the in-situ flow detection option carried in the updated G-BIER service packet to the analyzer" where the "NCE" is the "analyzer".
On page 22 of the remarks, in regard to the dependent claims, the Applicant states that the claims are allowable at least due to the deficiencies of the ground of rejection applied to the independent claims.
The Examiner respectfully disagrees.
The Examiner kindly refer the Applicant to the reasoning pertaining to the independent claims, detailed above.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5, 8-12, 14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20230269151 (hereinafter “Wang”) in view of Liu et al. WO 2022166773 (hereinafter “Liu”) and in further view of Ben et al. US 20230155928 (hereinafter “Ben”)
As to claim 1, 10, and 19 (claim 1 is the method claim for the electronic device and non-transitory machine readable storage medium in claim 10 and 19 respectively):
Wang discloses:
An electronic device, comprising: a processor and a machine readable storage medium; the machine readable storage medium stores machine executable instructions executable by the processor; (“a performance measurement apparatus is provided. The performance measurement apparatus includes a processor and a non-transitory computer-readable storage medium storing program instructions for execution by the processor, where the program instructions instruct the processor to perform the performance measurement method in the first aspect or any possible design of the first aspect.”, Wang [0031])
An in-situ flow detection method for a (“The BIER data packet includes a multicast data packet and a BIER header encapsulated in the multicast data packet. The BIER header includes a bit string. A bit set to 1 in the bit string corresponds to one or more bit forwarding egress routers (BFERs) that need to receive the BIER data packet. Currently, performance such as a delay, a packet loss, and a jitter in the BIER domain is measured by using an in-situ operations, administration and maintenance (IOAM) technology”, Wang [0003]) based on Internet Protocol Version 6 (IPv6) multicast (“the first packet includes an Internet Protocol version 6 (IPv6) basic header, a next header field of the IPv6 basic header indicates that a destination options header DOH is encapsulated, the DOH is used to carry the BIER header, and a payload of the first packet is used to carry the STAMP test packet.”, Wang [0008]), the method being applied to a network device (“FIG. 1 is a schematic diagram of a network scenario according to an embodiment of this application. In the network scenario shown in FIG. 1, an R1, an R4, an R5, and an R6 are edge bit forwarding routers (BFRs).”, Wang [0063]), and comprising: in response to the network device serving as a Bit Forwarding Ingress Router (BFIR) of a G-BIER domain, forwarding a G-BIER service packet in the G-BIER domain when receiving a raw multicast service packet to be subjected to in-situ flow detection (“In a possible design, the first packet includes a BIER header, an IOAM option, and a STAMP test packet, the BIER header is used to carry the bit string, the IOAM option is used to carry the node table, and the STAMP test packet is used to carry the first parameter.”, Wang [0026])(“The packet used to obtain the performance parameter is encapsulated into an IP packet or a UDP packet, and is forwarded from a BFIR to a BFER based on a BIER header encapsulated at an outer layer of the IP packet or UDP packet.”, Wang [0064]);
a Destination Option Header (DOH) in the IPv6 extension header at least comprises: a G-BIER option and an in-situ flow detection option; (“In the packet format shown in FIG. 3A or FIG. 3B, a next header whose value is 60 and that is included in an IPv6 basic header indicates that a destination options header (DOH) is further encapsulated after the Internet Protocol version 6 IPv6 basic header (IPv6 basic header). When the packet format shown in FIG. 3A is used, the DOH further includes a BIER header and an IOAM option, and formats of the BIER header and the IOAM option may be packet formats shown in FIG. 3C.”, Wang [0066])
the G-BIER option indicates performing packet forwarding in the G-BIER domain, (“A parameter included in the BIER header shown in FIG. 3C is used to forward the first packet to the one or more BFERs. The one or more BFERs that receive the first packet may be determined based on a bit set to 1 in the bit string included in a BIER header. For example, if the R1 performs performance measurement on all BFERs in a BIER domain,”, Wang [0066]) and
the in-situ flow detection information at least comprises: a Flow identity (ID), a Sequence Number, a Timestamp Received and a Timestamp Sent; the Flow ID and the Sequence Number are self-defined by the BFIR and prohibited from being modified in the G-BIER domain after being self-defined; (“Optionally, the STAMP test packet may further include a branch identifier (ID) field, so that the BFER uses a packet, sent to the R1, to carry the BFR-ID of the BFER. The R1 may add one or more parameters of the sequence number and the sending timestamp to the first packet based on a performance measurement requirement.”, Wang [0067]) (“The R4 adds an SSID included in the fifth packet to an SSID field included in the STAMP test packet of the second packet, so that the R1 can determine an initiated session based on the SSID. When performing performance measurement of a packet loss, the R4 adds a sequence number included in the STAMP test packet of the fifth packet to a session-sender sequence number field included in the second packet, and adds a sequence number of a received packet to the sequence number field of the second packet, so that the R1 that receives the second packet calculates the packet loss. When performing performance measurement of a delay, the R4 adds a send timestamp included in the STAMP test packet of the fifth packet to a session-sender timestamp, and adds a time point at which the fifth packet is received as a receive timestamp to one or more of a timestamp field or a receive timestamp field of the second packet, so that the R1 that receives the second packet calculates the delay.”, Wang [0074])
the Sequence Number represents a sequence for forwarding each of packets having same packet characteristics; (“a sequence number in the STAMP test packet is used to identify a sending sequence of packets”, Wang [0067])
the Timestamp Received indicates a timestamp of receiving a packet; and the Timestamp Sent indicates a timestamp of sending a packet. (“When performing performance measurement of a delay, the R4 adds a send timestamp included in the STAMP test packet of the fifth packet to a session-sender timestamp, and adds a time point at which the fifth packet is received as a receive timestamp to one or more of a timestamp field or a receive timestamp field of the second packet, so that the R1 that receives the second packet calculates the delay.”, Wang [0074])
wherein the in-situ flow detection information further comprises at least one path detection parameter. (“"in performance measurement of a delay or jitter, a timestamp in the STAMP test packet is used to carry a sending timestamp, to calculate the delay", Wang [0067])
the method further comprises: in response to the network device serving as an intermediate Bit Forwarding Router (BFR) device between the BFIR and a bit forwarding egress router (BFER) in the G-BIER domain, (“the second packet further includes a segment routing header (SRH), and the SRH is used to carry node information of an intermediate BFR between the BFIR and the first BFER.”, Wang [0015]) if G-BIER in-situ flow detection is supported, updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet when receiving the G-BIER service packet and forwarding the updated G-BIER service packet in the G-BIER domain; (“An IOAM option and data space field included in an IOAM option in FIG. 3C may be used to record a node included in a path that the first packet passes through, so that the BFER obtains, from the first packet, the node included in the path that the first packet passes through, and the BFER can implement co-routing and reversing between a packet sent to the R1 and the first packet.”, Wang [0066])
Wang as described above does not explicitly teach:
Generalized Bit Index Explicit Replication (G-BIER) service packet
wherein the G-BIER service packet carries an IPv6 extension header and an IPv6 payload field; the IPv6 payload field comprises the raw multicast service packet;
and reporting the detection data related to the in-situ flow detection information in the in-situ flow detection option carried in the updated G-BIER service packet to the analyzer.
However, Liu further teaches G-BIER (or IPv6 BIER) and associated extension header and payload field which includes:
Generalized Bit Index Explicit Replication (G-BIER) service packet (“BFR performs multicast message replication, performs IPv6 BIER (Bit Index Explicit Replication) message encapsulation and forwarding, wherein the IPv6 source address in the IPv6 BIER message is set to BFIR (bit forwarding entry router, Bit-Forwarding Ingress Router) network prefix and service ID, and the IPv6 destination address is set to the MPRA (Multicast Policy Reserved Address) of the next hop BFR.”, Liu [page 2, line 22]
wherein the G-BIER service packet carries an IPv6 extension header and an IPv6 payload field; the IPv6 payload field comprises the raw multicast service packet;
(“the second receiving module is configured to receive the IPv6 BIER packet header by adding a type of Option to the Destination Option Header at the IPv6 extension packet header position”, Liu [page 9, line 16])
(“Find a specific BIFT table according to the information in the BIER header to determine whether the node is a BFER. If it is a BFER, decapsulate the inner-layer multicast packet of the payload, search the corresponding multicast routing table according to the service ID information, and perform related replication. Forwarding; if it is a common BFR, look up the BIFT table for BIER replication and forwarding, where the IPv6 destination address is set to the MPRA of the next hop, and the IPv6 source address is set unchanged.”, Liu [page 9, line 4])
Wang and Liu are analogous because they pertain to BIER.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include G-BIER (or IPv6 BIER) and associated extension header and payload field as described in Liu into Wang. By modifying the method to include G-BIER (or IPv6 BIER) and associated extension header and payload field as taught by Liu, the benefits of IPv6 BIER (Liu [page 12, line 35) and improved performance measurement (Wang [0015]) are achieved.
The combination of Wang and Liu as described above does not explicitly teach:
and reporting detection data associated with in-situ flow detection information to a specified analyzer such that the analyzer detects network quality based on the reported detection data;
and the in-situ flow detection option carries an in-situ flow detection flag and the in-situ flow detection information; the in-situ flow detection flag indicates performing in-situ flow detection;
the Flow ID is determined according to packet characteristics, wherein Flow IDs of different packets having different packet characteristics are different;
and reporting the detection data related to the in-situ flow detection information in the in-situ flow detection option carried in the updated G-BIER service packet to the analyzer.
However, Ben further teaches reporting detection information to an analyzer and in-situ flow detection process which includes:
and reporting detection data associated with in-situ flow detection information to a specified analyzer such that the analyzer detects network quality based on the reported detection data; (“The ingress node CSG and the egress node RSG separately perform in-band detection to obtain a link state routing protocol (LSP) entry, and report LSP entries determined by the ingress node CSG and the egress node RSG to a network control engine (NCE). The LSP entry determined by the ingress node CSG records a quantity of packets of the data flow that enter the ingress. The LSP entry determined by the egress node RSG records a quantity of packets of the data flow that are sent from the egress. Based on the LSP entries reported by the ingress node CSG and the egress node RSG, the NCE determines whether a packet loss, a delay, or retransmission of the data flow exceeds a threshold.”, Ben [0077])
and the in-situ flow detection option carries an in-situ flow detection flag and the in-situ flow detection information; (“Based on the in-situ flow detection method provided above, in a possible implementation, if the in-situ flow detection request indicates that the in-situ flow detection is the in-situ flow detection across tunnels of different types, a packet obtained through processing by the ingress node includes a first flag field, and a value of the first flag field indicates that the in-situ flow detection is the in-situ flow detection across tunnels of different types.”, Ben [0041])
the in-situ flow detection flag indicates performing in-situ flow detection; (“Based on the in-situ flow detection method provided above, in a possible implementation, if the in-situ flow detection request indicates that the in-situ flow detection is the in-situ flow detection across tunnels of different types, a packet obtained through processing by the ingress node includes a first flag field, and a value of the first flag field indicates that the in-situ flow detection is the in-situ flow detection across tunnels of different types.”, Ben [0041])
the Flow ID is determined according to packet characteristics, wherein Flow IDs of different packets having different packet characteristics are different; (“The flow identifier may be represented by using a 5-tuple, and the 5-tuple includes a source address, a destination address, an identifier of an ingress node, an identifier of an egress node, and a packet protocol.”, Ben [0092])
and reporting the detection data related to the in-situ flow detection information in the in-situ flow detection option carried in the updated G-BIER service packet to the analyzer. (“The ingress node CSG and the egress node RSG separately perform in-band detection to obtain a link state routing protocol (LSP) entry, and report LSP entries determined by the ingress node CSG and the egress node RSG to a network control engine (NCE). The LSP entry determined by the ingress node CSG records a quantity of packets of the data flow that enter the ingress. The LSP entry determined by the egress node RSG records a quantity of packets of the data flow that are sent from the egress. Based on the LSP entries reported by the ingress node CSG and the egress node RSG, the NCE determines whether a packet loss, a delay, or retransmission of the data flow exceeds a threshold.”, Ben [0077])
Wang, Liu, and Ben are analogous because they pertain to forwarding packets between nodes.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include reporting detection information to an analyzer and in-situ flow detection process as described in Ben into Wang as modified by Liu. By modifying the method to include reporting detection information to an analyzer and in-situ flow detection process as taught by Ben, the benefits of IPv6 BIER (Liu [page 12, line 35), improved flexibility of in-situ flow detection method (Ben [0006]), and improved performance measurement (Wang [0015]) are achieved.
As to claim 2, 11, and 20 (claim 2 is the method claim for the electronic device and non-transitory machine readable storage medium in claim 11 and 20 respectively):
Wang discloses:
The method according to claim 1, further comprising: in response to the network device serving as a bit forwarding egress router (BFER) in the G-BIER domain, (“FIG. 1 is a schematic diagram of a network scenario according to an embodiment of this application. In the network scenario shown in FIG. 1, an R1, an R4, an R5, and an R6 are edge bit forwarding routers (BFRs). An R2 and an R3 are intermediate BFRs. When the R1 communicates with a first multicast source, and the R4, the R5, and the R6 communicate with a multicast receiver requesting the first multicast source, the R1 is a BFIR, and the R4, the R5, and the R6 are BFERs.”, Wang [0063]); recording the in-situ flow detection information carried in the in-situ flow detection option in the G-BIER service packet when receiving the G-BIER service packet; (“An IOAM option and data space field included in an IOAM option in FIG. 3C may be used to record a node included in a path that the first packet passes through, so that the BFER obtains, from the first packet, the node included in the path that the first packet passes through, and the BFER can implement co-routing and reversing between a packet sent to the R1 and the first packet.”, Wang [0066])
and reporting a timestamp of receiving the G-BIER service packet (“When performing performance measurement of a delay, the R4 adds a send timestamp included in the STAMP test packet of the fifth packet to a session-sender timestamp, and adds a time point at which the fifth packet is received as a receive timestamp to one or more of a timestamp field or a receive timestamp field of the second packet, so that the R1 that receives the second packet calculates the delay.”, Wang [0074])
Wang as described above does not explicitly teach:
recovering the G-BIER service packet to the raw multicast service packet to be forwarded to a multicast receiver;
However, Liu further teaches recovering G-BIER (or IPv6 BIER) packet to be forwarded to a multicast receiver which includes:
recovering the G-BIER service packet to the raw multicast service packet to be forwarded to a multicast receiver; (“Find a specific BIFT table according to the information in the BIER header to determine whether the node is a BFER. If it is a BFER, decapsulate the inner-layer multicast packet of the payload, search the corresponding multicast routing table according to the service ID information, and perform related replication. Forwarding; if it is a common BFR, look up the BIFT table for BIER replication and forwarding, where the IPv6 destination address is set to the MPRA of the next hop, and the IPv6 source address is set unchanged.”, Liu [page 5, line 15])
Wang and Liu are analogous because they pertain to BIER.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include recovering G-BIER (or IPv6 BIER) packet to be forwarded to a multicast receiver as described in Liu into Wang. By modifying the method to include recovering G-BIER (or IPv6 BIER) packet to be forwarded to a multicast receiver as taught by Liu, the benefits of IPv6 BIER (Liu [page 12, line 35) and improved performance measurement (Wang [0015]) are achieved.
The combination of Wang and Liu as described above does not explicitly teach:
and the detection data related to the recorded in-situ flow detection information to the analyzer.
However, Ben further teaches reporting detection information to an analyzer and in-situ flow detection process which includes:
and the detection data related to the recorded in-situ flow detection information to the analyzer. (“The ingress node CSG and the egress node RSG separately perform in-band detection to obtain a link state routing protocol (LSP) entry, and report LSP entries determined by the ingress node CSG and the egress node RSG to a network control engine (NCE). The LSP entry determined by the ingress node CSG records a quantity of packets of the data flow that enter the ingress. The LSP entry determined by the egress node RSG records a quantity of packets of the data flow that are sent from the egress. Based on the LSP entries reported by the ingress node CSG and the egress node RSG, the NCE determines whether a packet loss, a delay, or retransmission of the data flow exceeds a threshold.”, Ben [0077])
Wang, Liu, and Ben are analogous because they pertain to forwarding packets between nodes.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include reporting detection information to an analyzer and in-situ flow detection process as described in Ben into Wang as modified by Liu. By modifying the method to include reporting detection information to an analyzer and in-situ flow detection process as taught by Ben, the benefits of IPv6 BIER (Liu [page 12, line 35), improved flexibility of in-situ flow detection method (Ben [0006]), and improved performance measurement (Wang [0015]) are achieved.
As to claim 3 and 12 (claim 3 is the method claim for the electronic device in claim 12):
Wang discloses:
The method according to claim 1, wherein the in-situ flow detection information further comprises: a timestamp format (TF); wherein the Timestamp Received and the Timestamp Sent follow the timestamp format. (“When performing performance measurement of a delay, the R4 adds a send timestamp included in the STAMP test packet of the fifth packet to a session-sender timestamp, and adds a time point at which the fifth packet is received as a receive timestamp to one or more of a timestamp field or a receive timestamp field of the second packet, so that the R1 that receives the second packet calculates the delay.”, Wang [0074])
As to claim 5 and 14 (claim 5 is the method claim for the electronic device in claim 14):
Wang discloses:
The method according to claim 4, wherein updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet comprises: updating the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of receiving the G-BIER service packet; updating the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of sending the updated G-BIER service packet; or, adding the timestamp of receiving the G-BIER service packet in the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet; adding the timestamp of sending the updated G-BIER service packet in the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet. (“When performing performance measurement of a delay, the R4 adds a send timestamp included in the STAMP test packet of the fifth packet to a session-sender timestamp, and adds a time point at which the fifth packet is received as a receive timestamp to one or more of a timestamp field or a receive timestamp field of the second packet, so that the R1 that receives the second packet calculates the delay.”, Wang [0074])
As to claim 8 and 17 (claim 8 is the method claim for the electronic device in claim 17):
Wang discloses:
The method according to claim 1, wherein, in response to that the in-situ flow detection is Edge-to-Edge detection, the G-BIER option is before the in-situ flow detection option in the DOH; in response to that the in-situ flow detection is hop-by-hop detection, the G-BIER option is after the in-situ flow detection option in the DOH. (FIG. 3C shows BIER is before the IOAM option in the DOH, Wang [FIG. 3C])
As to claim 9 and 18 (claim 9 is the method claim for the electronic device in claim 18):
Wang discloses:
The method according to claim 1, further comprising: in response to the network device serving as an intermediate device between the BFIR and a bit forwarding egress router (BFER) in the G-BIER domain, if G-BIER in-situ flow detection is not supported, (“When the packet format shown in FIG. 3A is used, the DOH further includes a BIER header and an IOAM option, and formats of the BIER header and the IOAM option may be packet formats shown in FIG. 3C.”, Wang [0066]) forwarding the G-BIER service packet in the G-BIER domain according to a destination Internet Protocol (IP) address of the G-BIER service packet when receiving the G-BIER service packet. (“For example, if the first packet is in the packet format shown in FIG. 3A or FIG. 3B, the first packet further includes an IPv6 header. A next header whose value is 17 and that is included in the IPv6 header indicates that a user datagram protocol (UDP) packet is further encapsulated after the IPv6 header. A source address (SA) included in the IPv6 header is used to carry the address of the R1. A destination address (DA) included in the IPv6 header is used to carry a loopback address or a multicast address. The multicast address may be an address that is set to identify that a packet is a multicast packet and that is not used by another device.”, Wang [0067])
Claim(s) 6 and 15 is rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Liu and Ben, as applied to claim 1 above, and further in view of Zhou et al. US 20230102193 (hereinafter “Zhou”)
As to claim 6 and 15 (claim 6 is the method claim for the electronic device in claim 15):
Wang discloses:
when the in-situ flow detection is used to detect a delay of network transmission, the path detection parameter at least comprises a delay parameter; (“"in performance measurement of a delay or jitter, a timestamp in the STAMP test packet is used to carry a sending timestamp, to calculate the delay", Wang [0067])
The combination of Wang, Liu, and Ben as described above does not teach:
The method according to claim 4, wherein the in-situ flow detection information further comprises: at least one Type-Length-Value (TLV, and each TLV carries at least one path detection parameter; when the in-situ flow detection is used to detect a delay of network transmission, the path detection parameter at least comprises a delay parameter; when the in-situ flow detection is used to perform statistics of packet loss, the path detection parameter at least comprises a number of lost packets; updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet comprises: updating the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of receiving the G- BIER service packet; updating the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of sending the updated G-BIER service packet, and filling at least one path detection parameter in at least one TLV; or, adding the timestamp of receiving the G-BIER service packet in the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet; adding the timestamp of sending the updated G-BIER service packet in the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet, and filling at least one path detection parameter in at least one TLV.
However, Zhou further teaches TLV for in-situ operations which includes:
The method according to claim 4, wherein the in-situ flow detection information further comprises: at least one Type-Length-Value (TLV), and each TLV carries at least one path detection parameter; (“The TLV field includes one TLV field, the TLV field includes at least one sub-type length value field, any one of the at least one sub-type length value field is corresponding to one type of network performance, and any sub-type length value field is used to carry measurement information of a corresponding type of network performance.”, Zhou [0142])
when the in-situ flow detection is used to perform statistics of packet loss, the path detection parameter at least comprises a number of lost packets; (“types of network performance include but are not limited to one or more types of delay information, jitter information, path information, packet loss information, bandwidth information, and the like.”, Zhou [0143])
updating the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet comprises: updating the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of receiving the G-BIER service packet;
updating the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet to a timestamp of sending the updated G-BIER service packet, and filling at least one path detection parameter in at least one TLV; or, adding the timestamp of receiving the G-BIER service packet in the Timestamp Received in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet; adding the timestamp of sending the updated G-BIER service packet in the Timestamp Sent in the in-situ flow detection information in the in-situ flow detection option carried in the G-BIER service packet, and filling at least one path detection parameter in at least one TLV. (“The sender sends the STAMP packet to a second network device, that is, a reflector (Reflector) R5. The packet sent to the egress node passes through nodes R2, R3, and R4 in sequence. Because End.OTP SIDs are encapsulated in the STAMP packet, forwarding planes of the nodes R2, R3, and R4 add receiving timestamps to the original packet and send the original packet to control planes (a control plane of each device), and an OAM process on the control plane copies timestamp data to the OAM TLV, so that timestamp information T2 to T7 is collected. For example, delay information of the packet inside R2 may be obtained by comparing T2 with T3, and delay information of the packet on the network link between R2 and R3 may be obtained by comparing T3 with T4.”, Zhou [0267])
Wang, Liu, Ben, and Zhou are analogous because they pertain to forwarding packets between nodes.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include reporting detection information to an analyzer and in-situ flow detection process as described in Ben into Wang as modified by Liu. By modifying the method to include reporting detection information to an analyzer and in-situ flow detection process as taught by Ben, the benefits of IPv6 BIER (Liu [page 12, line 35), improved flexibility of in-situ flow detection method (Ben [0006]), and improved performance measurement (Wang [0015] and Zhou [0019]) are achieved.
Claim(s) 7 and 16 is rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Liu and Ben, as applied to claim 1 above, and further in view of Xiao et al. US 12267230 (hereinafter “Xiao”)
As to claim 7 and 16 (claim 7 is the method claim for the electronic device in claim 16):
The combination of Wang, Liu, and Ben as described above does not teach:
The method according to claim 1, wherein the in-situ flow detection flag occupies 8 bits; Bit0 of the in-situ flow detection flag is a delay detection flag, and Bit1 of the in-situ flow detection flag is a packet loss detection flag; the Bit0 is a lowest bit of the in-situ flow detection flag, and the Bit1 is a bit adjacent to the Bit0 in the in-situ flow detection flag.
However, Zhou further teaches detection flag bit mapping which includes:
The method according to claim 1, wherein the in-situ flow detection flag occupies 8 bits; Bit0 of the in-situ flow detection flag is a delay detection flag, and Bit1 of the in-situ flow detection flag is a packet loss detection flag; the Bit0 is a lowest bit of the in-situ flow detection flag, and the Bit1 is a bit adjacent to the Bit0 in the in-situ flow detection flag. (FIG. 14 shows the delay and pack loss detection flag bit mapping, Xiao [FIG. 14])
Wang, Liu, Ben, and Xiao are analogous because they pertain to forwarding packets between nodes.
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include reporting detection information to an analyzer and in-situ flow detection process as described in Ben into Wang as modified by Liu. By modifying the method to include reporting detection information to an analyzer and in-situ flow detection process as taught by Ben, the benefits of IPv6 BIER (Liu [page 12, line 35), improved flexibility of in-situ flow detection method (Ben [0006]), improved flexibility (Xiao [97]), and improved performance measurement (Wang [0015]) are achieved.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW C KIM whose telephone number is (703)756-5607. The examiner can normally be reached M-F 9AM - 5PM (PST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sujoy K Kundu can be reached at (571) 272-8586. 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.
/A.C.K./
Examiner
Art Unit 2471
/SUJOY K KUNDU/Supervisory Patent Examiner, Art Unit 2471
Prosecution Insights