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 .
This office action is in response to application filed on 114.
Claims 1-14 and 19-20 are pending and rejected.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119 (a)-(d) based on an application filed in the People's Republic of China on 05/07/2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05, 08/20/2025, and 06/04/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Specification
The disclosure is objected to because the title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Objections
Claim 2 is objected to as failing to disclose the abbreviation as defined by the specification. The claim recites the term "TLV," but the abbreviation or acronym has not been clearly defined the first time it appears.
Claim 5 is objected to as failing to provide proper antecedent basis for the claimed subject matter. Claim 5 recites the limitation "the terminal." There is insufficient antecedent basis for this limitation in the claim.
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.
Claims 1, 8, 9, 13, 14, 19, and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Saavedra et al (US20170250901A1) (hereinafter "Saavedra").
Regarding claim 1, Saavedra discloses a message processing method, applied to a customer premise equipment (CPE), comprising:
receiving a first message sent by a point of presence (PoP); wherein ([0143] The CPE-CE (124) may be configured to collect information from network components in its vicinity including from one or more available PoPs (130) and their CCPEs (110).)
the first message carries first information of each cloud node of at least two cloud nodes ([0143] CCPEs), the first information represents detection information of the cloud node ([0143] The CPE-CE (124) for example connects to a closest available CCPE (124), implemented as part of a PoP (130), and thereby having access to a connection to the MPLS network core (112). [0144] In one implementation, each CPE-CE (124) establishes a connection by dynamically advertising its IP address, and receiving replies from associated CCPE (110) along with their current network performance information. [0153] In one aspect of the invention, the CPE-CEs/CCPEs may monitor network performance, including in the areas proximate to their position, and may reconfigure the network overlay dynamically, across multiple locations (including multiple PoPs) based on changes in MPLS network performance while providing continuity of service.).
Regarding claim 8, Saavedra discloses the method, wherein the first information comprises at least one of the following information of the cloud node:
network-related performance indicators ([0144] In one implementation, each CPE-CE (124) establishes a connection by dynamically advertising its IP address, and receiving replies from associated CCPE (110) along with their current network performance information.);
service-related performance indicators (The examiner does not select this because of the "at least one of" statement.);
availability detection results (The examiner does not select this because of the "at least one of" statement.);
resource location detection results (The examiner does not select this because of the "at least one of" statement.).
Regarding claim 9, Saavedra discloses a message processing method, applied to point of presence (PoP), comprising:
sending a first message to a customer premise equipment (CPE); wherein ([0143] The CPE-CE (124) may be configured to collect information from network components in its vicinity including from one or more available PoPs (130) and their CCPEs (110).)
the first message carries first information of each cloud node of at least two cloud nodes, the first information represents detection information of the cloud node ([0143] The CPE-CE (124) for example connects to a closest available CCPE (124), implemented as part of a PoP (130), and thereby having access to a connection to the MPLS network core (112). [0144] In one implementation, each CPE-CE (124) establishes a connection by dynamically advertising its IP address, and receiving replies from associated CCPE (110) along with their current network performance information. [0153] In one aspect of the invention, the CPE-CEs/CCPEs may monitor network performance, including in the areas proximate to their position, and may reconfigure the network overlay dynamically, across multiple locations (including multiple PoPs) based on changes in MPLS network performance while providing continuity of service.).
Regarding claim 13, Saavedra discloses the method, wherein before sending the first message to the CPE, the method further comprises:
receiving first information reported by each of the at least two cloud nodes ([0143] The CPE-CE (124) may be configured to collect information from network components in its vicinity including from one or more available PoPs (130) and their CCPEs (110).)
Regarding claim 14, Saavedra discloses the method according to claim 9, wherein the first information comprises at least one of the following information of the cloud node:
network-related performance indicators ([0144] In one implementation, each CPE-CE (124) establishes a connection by dynamically advertising its IP address, and receiving replies from associated CCPE (110) along with their current network performance information.);
service-related performance indicators (The examiner does not select this because of the "at least one of" statement.);
availability detection results (The examiner does not select this because of the "at least one of" statement.);
resource location detection results (The examiner does not select this because of the "at least one of" statement.).
Regarding claim 19, Saavedra discloses a customer premise equipment (CPE), comprising a first processor and a first memory for storing a computer program executable on the first processor, wherein ([0103] In one aspect, the first network component may be implemented using what is called in this disclosure a “CPE-CE” or customer premises equipment (also referred to as customer edge (CE) router or client site network component).)
the first processor is configured to execute the computer program to perform the method according to claim 1 ([0093] The embodiments of the systems and methods described herein may be implemented in hardware or software, or a combination of both. These embodiments may be implemented in computer programs executing on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.).
Regarding claim 20, Saavedra discloses a point of presence (PoP), comprising a second processor and a second memory for storing a computer program executable on the processor, wherein ([0140] In another aspect of the invention, and as shown in FIG. 2d, one or more CCPEs can be implemented at a given physical location, as part of a Point-of Presence (PoP) (130). In one aspect of the present invention, a PoP (130) can define a relatively high concentration of servers, concentrators, and/or CCPEs within an area.)
the second processor is configured to execute the computer program to perform the method according to claim 9 ([0093] The embodiments of the systems and methods described herein may be implemented in hardware or software, or a combination of both. These embodiments may be implemented in computer programs executing on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2, 7, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Saavedra in view of Peng et al (US20210409315A1) (hereinafter "Peng").
Regarding claim 2, Saavedra fails to disclose the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message.
However, Peng discloses the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message ([0006] The ingress node is a first node on a path used to forward a packet from an application program, and the ingress node may be a device, for example, a router (router) or a switch (switch). The egress node is a last node on the path used to forward the packet from the application program, and the egress node may be a device, for example, a router (router) or a switch (switch). … First, the ingress node obtains the packet, and obtains feature information of the application program corresponding to the packet. [0011] In a possible implementation, the IPv6 extension header of the IPv6 packet includes at least one of the following: the type-length-value (type-length-value, TLV) field in the IPv6 extension header and a segment identifier (segment identifier, SID) in a segment routing header (segment routing header, SRH). The feature information of the application program is encapsulated by using the segment identifier of the segment routing header, so that the information can be directly extracted and put into the destination address of the IPv6 packet, and the ingress node efficiently and quickly obtains the feature information that is of the application program and that is in the packet.).
Saavedra and Peng are considered to be analogous to the claimed invention because both are in the same endeavor of packet processing and routing.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Peng to create the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message.
The motivation to combine both references would come from the need to allow an ingress node to extract an application's feature information quickly and efficiently.
Regarding claim 7, Saavedra fails to disclose the method, wherein the determining the second cloud node based on the first information and the second information of each of the at least two cloud nodes comprises: reporting the first information and second information of each cloud node of the at least two cloud nodes to a controller; receiving third information returned by the controller; wherein the third information is configured to indicate the second cloud node; the second cloud node is determined by the controller based on information reported by the CPE.
However, Peng discloses the method, wherein the determining the second cloud node based on the first information and the second information of each of the at least two cloud nodes comprises:
reporting the first information and second information of each cloud node of the at least two cloud nodes to a controller ([0029] In the other possible implementation, the ingress node sends a path obtaining request to a controller, where the path obtaining request carries the feature information of the application program.);
receiving third information returned by the controller; wherein ([0029] The controller generates, based on the path obtaining request, a path corresponding to the feature information of the application program. The ingress node receives the path that is generated by the controller based on the path obtaining request and that corresponds to the feature information of the application program.)
the third information is configured to indicate the second cloud node; the second cloud node is determined by the controller based on information reported by the CPE ([0076] According to a fifth aspect, this application further provides a packet processing apparatus. The apparatus is used in a network system, and the network system includes a network device, an ingress node, and an egress node. A packet reaches a destination node through a path between the ingress node and the egress node. The network device is the packet processing apparatus. The packet processing apparatus includes: an obtaining unit (packet receiver), configured to receive the packet, and obtain feature information of an application program corresponding to the packet, where the feature information of the application program includes at least one piece of the following information: feature information and network performance requirement information of the application program, and the identification information is used to identify the application program; and a sending unit (packet transmitter), configured to send, to the ingress node, the packet that carries the feature information of the application program, where the feature information of the application program is used by the ingress node to determine the path from the ingress node to the egress node, so as to forward the packet.).
Saavedra and Peng are considered to be analogous to the claimed invention because both are in the same endeavor of packet processing and routing.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Peng to create the method, wherein the determining the second cloud node based on the first information and the second information of each of the at least two cloud nodes comprises: reporting the first information and second information of each cloud node of the at least two cloud nodes to a controller; receiving third information returned by the controller; wherein the third information is configured to indicate the second cloud node; the second cloud node is determined by the controller based on information reported by the CPE.
The motivation to combine both references would come from the need to allow an ingress node to extract an application's feature information quickly and efficiently.
Regarding claim 10, Saavedra fails to disclose the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message.
However, Peng discloses the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message ([0006] The ingress node is a first node on a path used to forward a packet from an application program, and the ingress node may be a device, for example, a router (router) or a switch (switch). The egress node is a last node on the path used to forward the packet from the application program, and the egress node may be a device, for example, a router (router) or a switch (switch). … First, the ingress node obtains the packet, and obtains feature information of the application program corresponding to the packet. [0011] In a possible implementation, the IPv6 extension header of the IPv6 packet includes at least one of the following: the type-length-value (type-length-value, TLV) field in the IPv6 extension header and a segment identifier (segment identifier, SID) in a segment routing header (segment routing header, SRH). The feature information of the application program is encapsulated by using the segment identifier of the segment routing header, so that the information can be directly extracted and put into the destination address of the IPv6 packet, and the ingress node efficiently and quickly obtains the feature information that is of the application program and that is in the packet.).
Saavedra and Peng are considered to be analogous to the claimed invention because both are in the same endeavor of packet processing and routing.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Peng to create the method, wherein the first information of each cloud node of the at least two cloud nodes is encapsulated in a first TLV of a segment routing header (SRH) of the first message.
The motivation to combine both references would come from the need to allow an ingress node to extract an application's feature information quickly and efficiently.
Claims 3, 5, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Saavedra in view of Zhang et al (US20210377173A1) (hereinafter "Zhang").
Regarding claim 3, Saavedra fails to disclose the method, further comprising:
changing a segment identifier (SID) of a last hop in a segment list of a second message from a first SID to a second SID, based on the first information of each cloud node in the at least two cloud nodes; wherein the first SID represents a SID allocated to a user by a first cloud node of the at least two cloud nodes; and the second SID represents a SID allocated to the user by a second cloud node of the at least two cloud nodes.
However, Zhang discloses the method, further comprising:
changing a segment identifier (SID) of a last hop in a segment list of a second message from a first SID to a second SID, based on the first information of each cloud node in the at least two cloud nodes; wherein ([0024] the first SID list is generated based on a SID of the ingress edge node in the first DCN subnet; the first SID list is replaced with the second SID list at the ingress edge node in the first DCN subnet, and the second SID list is generated based on at least one SF node in the first DCN subnet and the egress edge node in the first DCN subnet; and the second SID list is replaced with a third SID list at the egress edge node in the first DCN subnet, and the third SID list is generated based on the ingress edge node in the second DCN subnet [0168] A head node (which may be considered as a BSID node) steers traffic to an SR policy. The head node obtains, based on a current active candidate path of the SR policy, a SID list corresponding to a specified path. Then, the head node encapsulates, in front of the to-be-forwarded data, a packet header including the SID list, to obtain a to-be-forwarded packet through encapsulation, where a first SID in the SID list is indicated as an active SID; and then forwards the to-be-forwarded packet to a downstream device by using the active SID as a destination address (DA). At any time when an SRv6 packet is forwarded through an SRv6 tunnel, there is only one active SID in a SID list of the SRv6 packet. The active SID is used to identify a SID of a next-hop node.)
the first SID represents a SID allocated to a user by a first cloud node of the at least two cloud nodes; and the second SID represents a SID allocated to the user by a second cloud node of the at least two cloud nodes ([0197] When the SID list in the packet header includes at least two SIDs, the SID list is added to the SRH field in the packet header. The head node needs to set a first SID that has not arrived and that is in the SID list to an active SID, and set the active SID as the destination address in the packet header, to indicate a next-hop address of the to-be-forwarded packet.).
Saavedra and Zhang are considered to be analogous to the claimed invention because both are in the same endeavor of traffic steering.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Zhang to create the method, further comprising: changing a segment identifier (SID) of a last hop in a segment list of a second message from a first SID to a second SID, based on the first information of each cloud node in the at least two cloud nodes; wherein the first SID represents a SID allocated to a user by a first cloud node of the at least two cloud nodes; and the second SID represents a SID allocated to the user by a second cloud node of the at least two cloud nodes.
The motivation to combine both references would come from the need to address a condition in which data fails to be normally transmitted in a network because a target forwarding path is excessively long.
Regarding claim 5, Saavedra fails to disclose the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises: notifying the terminal that sends the second message to re-encapsulate the second message according to an IP address of the second cloud node.
However, Zhang discloses the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises:
notifying the terminal that sends the second message to re-encapsulate the second message according to an IP address of the second cloud node ([0212] For example, the to-be-forwarded data may be a data frame or an IP packet, and the destination address of the to-be-forwarded data may be a destination MAC address in the data frame or a destination IP address in the IP packet. The tail node may continue to forward the to-be-forwarded data based on the destination MAC address in the data frame or the destination IP address in the IP packet. [0228] S303: The head node encapsulates, in front of the to-be-forwarded data, a packet header including the first SID list, to obtain a to-be-forwarded packet.).
Saavedra and Zhang are considered to be analogous to the claimed invention because both are in the same endeavor of traffic steering.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Zhang to create the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises: notifying the terminal that sends the second message to re-encapsulate the second message according to an IP address of the second cloud node.
The motivation to combine both references would come from the need to address a condition in which data fails to be normally transmitted in a network because a target forwarding path is excessively long.
Regarding claim 11, Saavedra fails to disclose the method, further comprising:
receiving a second message; wherein a segment identifier (SID) of a last hop in a segment list of the second message is configured as a second SID and a destination IP address of the second message points to a first cloud node; the second SID represents a SID assigned to a user by a second cloud node; sending the second message, based on a mapping relationship between the second SID and the second cloud node.
However, Zhang discloses the method, further comprising:
receiving a second message; wherein a segment identifier (SID) of a last hop in a segment list of the second message is configured as a second SID and a destination IP address of the second message points to a first cloud node; the second SID represents a SID assigned to a user by a second cloud node ([0024] the first SID list is generated based on a SID of the ingress edge node in the first DCN subnet; the first SID list is replaced with the second SID list at the ingress edge node in the first DCN subnet, and the second SID list is generated based on at least one SF node in the first DCN subnet and the egress edge node in the first DCN subnet; and the second SID list is replaced with a third SID list at the egress edge node in the first DCN subnet, and the third SID list is generated based on the ingress edge node in the second DCN subnet [0168] A head node (which may be considered as a BSID node) steers traffic to an SR policy. The head node obtains, based on a current active candidate path of the SR policy, a SID list corresponding to a specified path. Then, the head node encapsulates, in front of the to-be-forwarded data, a packet header including the SID list, to obtain a to-be-forwarded packet through encapsulation, where a first SID in the SID list is indicated as an active SID; and then forwards the to-be-forwarded packet to a downstream device by using the active SID as a destination address (DA). [0168] At any time when an SRv6 packet is forwarded through an SRv6 tunnel, there is only one active SID in a SID list of the SRv6 packet. The active SID is used to identify a SID of a next-hop node. The active SID is used to identify a SID of a next-hop node. When receiving the SRv6 packet, an intermediate node queries my local SID table based on the active SID (that is, an IPv6 DA). If a matching entry exists (that is, the active SID is a SID of the intermediate node), the intermediate node performs related processing based on a function associated with the hit local SID entry.);
sending the second message, based on a mapping relationship between the second SID and the second cloud node ([0168] At any time when an SRv6 packet is forwarded through an SRv6 tunnel, there is only one active SID in a SID list of the SRv6 packet. The active SID is used to identify a SID of a next-hop node. The active SID is used to identify a SID of a next-hop node. When receiving the SRv6 packet, an intermediate node queries my local SID table based on the active SID (that is, an IPv6 DA). If a matching entry exists (that is, the active SID is a SID of the intermediate node), the intermediate node performs related processing based on a function associated with the hit local SID entry. [0197] When the SID list in the packet header includes at least two SIDs, the SID list is added to the SRH field in the packet header. The head node needs to set a first SID that has not arrived and that is in the SID list to an active SID, and set the active SID as the destination address in the packet header, to indicate a next-hop address of the to-be-forwarded packet. ).
Saavedra and Zhang are considered to be analogous to the claimed invention because both are in the same endeavor of traffic steering.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Zhang to create the method, further comprising: receiving a second message; wherein a segment identifier (SID) of a last hop in a segment list of the second message is configured as a second SID and a destination IP address of the second message points to a first cloud node; the second SID represents a SID assigned to a user by a second cloud node; sending the second message, based on a mapping relationship between the second SID and the second cloud node.
The motivation to combine both references would come from the need to address a condition in which data fails to be normally transmitted in a network because a target forwarding path is excessively long.
Regarding claim 12, Saavedra fails to disclose the method, wherein before sending the second message, the method further comprises: modifying a first path based on an IP address of the second cloud node; wherein the first path represents a path from the PoP to the second cloud node.
However, Zhang discloses the method, wherein before sending the second message, the method further comprises:
modifying a first path based on an IP address of the second cloud node; wherein ([0024] the first SID list is generated based on a SID of the ingress edge node in the first DCN subnet; the first SID list is replaced with the second SID list at the ingress edge node in the first DCN subnet, and the second SID list is generated based on at least one SF node in the first DCN subnet and the egress edge node in the first DCN subnet; and the second SID list is replaced with a third SID list at the egress edge node in the first DCN subnet, and the third SID list is generated based on the ingress edge node in the second DCN subnet [0168] A head node (which may be considered as a BSID node) steers traffic to an SR policy. The head node obtains, based on a current active candidate path of the SR policy, a SID list corresponding to a specified path. Then, the head node encapsulates, in front of the to-be-forwarded data, a packet header including the SID list, to obtain a to-be-forwarded packet through encapsulation, where a first SID in the SID list is indicated as an active SID; and then forwards the to-be-forwarded packet to a downstream device by using the active SID as a destination address (DA). At any time when an SRv6 packet is forwarded through an SRv6 tunnel, there is only one active SID in a SID list of the SRv6 packet. The active SID is used to identify a SID of a next-hop node.)
the first path represents a path from the PoP to the second cloud node ([0212] For example, the to-be-forwarded data may be a data frame or an IP packet, and the destination address of the to-be-forwarded data may be a destination MAC address in the data frame or a destination IP address in the IP packet. The tail node may continue to forward the to-be-forwarded data based on the destination MAC address in the data frame or the destination IP address in the IP packet. [0228] S303: The head node encapsulates, in front of the to-be-forwarded data, a packet header including the first SID list, to obtain a to-be-forwarded packet.).
Saavedra and Zhang are considered to be analogous to the claimed invention because both are in the same endeavor of traffic steering.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Zhang to create the method, wherein before sending the second message, the method further comprises: modifying a first path based on an IP address of the second cloud node; wherein the first path represents a path from the PoP to the second cloud node.
The motivation to combine both references would come from the need to address a condition in which data fails to be normally transmitted in a network because a target forwarding path is excessively long.
Claims 4 are rejected under 35 U.S.C. 103 as being unpatentable over Saavedra in view of Filsfils et al (US20220174011A1) (hereinafter "Filsfils").
Regarding claim 4, Saavedra fails to disclose the method, wherein after changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method comprises: updating the segment list of the second message, according to the second SID.
However, Filsfils discloses the method, wherein after changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method comprises:
updating the segment list of the second message, according to the second SID ([0019] In some examples, the method may include receiving the packet at the second node of the network and determining, by the second node, that the packet includes a Segment Routing for IPv6 micro-segment (uSID) instruction that is configured to prompt the second node to perform path tracing actions. As such, the method may also include performing, by the second node, the path tracing actions based at least in part on reading the SRv6 uSID instruction, the path tracing actions including, in some examples, determining second telemetry data of the specific type that is associated with the second node and appending (inserting or updating) the second telemetry data at the second location within the SID list or hop-by-hop option and/or TLV of the SRH of the packet.).
Saavedra and Filsfils are considered to be analogous to the claimed invention because both are in the same endeavor of using an IPv6 header option and/or segment identifier field of a segment list or a TLV of a segment routing header as a telemetry data carrier.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Filsfils to create the method, wherein after changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method comprises: updating the segment list of the second message, according to the second SID.
The motivation to combine both references would come from the need to improve network path tracing and delay measurement techniques.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Saavedra in view of Black et al (US20230039824A1) (hereinafter "Black").
Regarding claim 6, Saavedra fails to disclose the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises: determining the second cloud node, based on the first information and second information of each cloud node of the at least two cloud nodes; wherein the second information represents a path quality from the CPE to the corresponding cloud node.
However, Black discloses the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises:
determining the second cloud node, based on the first information and second information of each cloud node of the at least two cloud nodes; wherein ([0038] A cloud manager 416 configures the various cloud providers 140 (not shown) as per the data residency requirements of each tenant. … Policies 410 selected by the enterprise 198 and client 304 communicate to the ARS 185 to control residency for cloud services and routes. [0042] Routing between various cloud services, enterprises 198 and end user devices 195 is arranged by a route controller 428. Different performance and residency for routes can be specified by the enterprise 198 according to the policy 412 selected by a tenant. Traffic maps 440 store performance and route maps store addresses and residency for each link.)
the second information represents a path quality from the CPE to the corresponding cloud node ([0044] A global cloud traffic controller 408 knows the route maps 436 and has traffic maps 440 for all the connections in the cloud network 100. Traffic maps 440 for each link specify bandwidth, latency, reliability, and other performance characteristics. Performance preference can be specified by any enterprise 198 through selection of the appropriate policy.).
Saavedra and Black are considered to be analogous to the claimed invention because both are in the same endeavor of route management in cloud-based multi-tenant systems.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have a motivation to combine the teachings of Saavedra with Black to create the method, wherein before changing the SID of the last hop in the segment list of the second message from the first SID to the second SID, the method further comprises: determining the second cloud node, based on the first information and second information of each cloud node of the at least two cloud nodes; wherein the second information represents a path quality from the CPE to the corresponding cloud node.
The motivation to combine both references would come from the need to improve utilization bandwidth and address network performance issues.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gamage et al (US20230171178A1) discloses method of network traffic routing in a network, and more specifically to validating multiple paths used for routing network traffic in a segment routing network as well as IP network.
Bashandy et al (US11882203B2) discloses techniques for providing efficiencies in processing and communicating internet protocol packets in a network using segment routing.
Brissette et al (US20180375763A1) discloses a Ethernet Virtual Private Network using an Internet Protocol Version 6 Segment Routing underlay network and SRv6-enhanced Border Gateway Protocol signaling.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to D LITTLE whose telephone number is (571)272-5748. The examiner can normally be reached M-Th 8-6 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, Nishant Divecha can be reached on 571-270-3125. 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.
/D LITTLE/Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
