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 .
This office action is responsive to communication filed on 11/29/2024. Claims 1-20 are pending for examination.
Response to Amendment
Applicant’s amendment filed on April 5, 2025 has been entered and made of record.
Applicant’s arguments, see Remarks, pages 1 and 2, filed on April 5, 2025, with respect to the rejection of claims 15 and 18-20 under 35 USC 102(a)(2) rejection being anticipated by Filsfils et al. (WO 2019005949 A1) and the rejection of claim 1-14 under 35 USC 103 as being unpatentable over Filsfils et al. in view of Lyu (CN 112787927A). as well as the rejection of claims 16 and 17 under 35 USC 103 as being unpatentable under Filsfils and in further view of Lyu. These arguments are deemed not persuasive.
Point A
Applicant argues that neither reference mentions or even suggests an SID type, let alone that the SID type indicates that a segment routing header is not supported.
As to Point A
It is the position of the examiner that Filsfils does in fact disclose a SID type based upon a SID type inherently containing or associated with a specific SID type, as to the type that defines the function and the forwarding behavior of the particular segment. Inherently it indicates how a packet should be processed (i.e., forwarded from one node to the other) as well as an advertisement mechanism via MPLS. With regards to the argument that Filsfils does not disclose SID type that indicates that a segment routing header is not supported. On pages 71 and 72 of Filsfils it discloses “an applicant or the underlying operation system implements at least the End function as defined in [2]. An SRv6-capable appliance shall receive, process and forward the SRv6 traffic it receives. For example, any appliance running on top of Linux kernel 4.10 or later is SRv6-capable. An SRv6-incable appliance receiving an SRv6 packet whose DA matches a local address will drop this packet due to the unrecognized routing extension header [3]. Furthermore, as stated in the rejection Filsfils discloses An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment Identifier) is often used as a shorter reference for "SRv6 Segment". An SRv6-capable node N maintains a "My Local SID Table". This table contains all the local SRv6 segments explicitly instantiated at node N. N is the parent node for these SIDs. A local SID of N can be an IPv6 address associated to a local interface of N but it is not mandatory. Nor is the My Local SID table populated by default with all IPv6 addresses defined on node N. In most use-cases, a local SID will NOT be an address associated to a local interface of N.
Point B
Applicant argues that Filsfils fails to disclose a first segment routing header, wherein the second IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header.
As to Point B
It is the position of the examiner, that Filsfils in combination with Lyu does in fact disclose a first segment routing header, wherein the second IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header. Lyu discloses all SRHs in the message are moved to the tail offset field of the analysis message, see also page 10, "EndSRHOffset field: The length is 2 bytes. The offset after logically moving the SRH header to the end of the message comes from the value of the parsing message. Also, Lyu teaches modification of the messages of the segment routing message and then forwards the message. Filsfils teachings of encapsulating outer layer makes it obvious that a second IP header can be encapsulated in a first IP payload (packet) and the first segment routing header.
Accordingly, it is the Examiner’s position that Applicant has not yet submitted claims drawn to limitations, which clearly define the operation and apparatus of Applicant’s disclosed invention in manner, which distinguishes over the prior art. As it is Applicant’s right to continue to claim as broadly as possible their invention. It is also the Examiner’s right to continue to interpret the claim language as broadly as possible. It is the Examiner’s position that the detailed functionality that allows for Applicant’s invention to overcome the prior art used in the rejection, fails to differentiate in detail how these features are unique (see Applicant’s enabling portions of the specification, page 5, lines 5-10). As it is extremely well known in the networking art as already shown by Filsfils and Lyu. Thus, it is clear that Applicant must submit amendments to the claims in order to distinguish over the prior art use in the rejection that discloses different features of Applicant’s claim invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 – 14 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils et al. (WO2019005949A1) in view of Lyu (CN112787927A).
As per claim 1, Filsfils disclose a packet processing method (see Fig.9, packet processing routing method), wherein the method comprises: receiving, by a service function forwarder (SFF), a first packet, wherein the first packet comprises a first segment routing header, a first internet protocol (IP) header, and a first IP payload, and wherein the first segment routing header is encapsulated in an outer layer of the first IP header and the first IP payload (see Fig. 9, page 75 lines 20-page 81, where the SR Hdr is encapsulated in an outer layer of the 1Pv4 packet, see also Fig 1B page 6 lines 26 – page 7 lines 1-15);
obtaining, by the SFF, a second packet based on the first packet (see Fig. 9, page 75 lines 20-page 81, where the 1Pv4 packet is obtained by removing the outer 1Pv6 and SR headers of the received packet, see also Fig 1B and accompanying sections of the description), 1Nherein the second packet comprises a second), and
sending, by the SFF, the second packet to a service function (SF) device (see Fig. 9, page 75 lines 20-page 81, the packet is sent to the Appliance which is a service function as explained throughout the description, see also Fig 1B and accompanying sections of the description),
wherein the first segment routing header comprises a first segment identifier (SID), wherein the SFF stores a first correspondence, wherein the first correspondence comprises the first SID and a SID type, and the SID type indicates that a segment routing header is not supported (see page 15, An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment Identifier) is often used as a shorter reference for "SRv6 Segment". An SRv6-capable node N maintains a "My Local SID Table". This table contains all the local SRv6 segments explicitly instantiated at node N. N is the parent node for these SIDs. A local SID of N can be an IPv6 address associated to a local interface of N but it is not mandatory. Nor is the My Local SID table populated by default with all IPv6 addresses defined on node N. In most use-cases, a local SID will NOT be an address associated to a local interface of N.).
Filsfils does not explicitly disclose wherein the second packet comprises a second IP header, the first IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header.
Lyn however discloses wherein a second packet comprises a second IP header, the first IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header (see page 9, S608, S608, all SRHs in the message are moved to the tail offset field of the analysis message, see also page 10, "EndSRHOffset field: The length is 2 bytes. The offset after logically moving the SRH header to the end of the message comes from the value of the parsing message").
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a second packet comprises a second IP header, the first IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header, as taught by Lyn, in the system of Filsfils, so as to provide a segmented routing message forwarding method, a segmented routing message forwarding device and a preset logic circuit unit, so that forwarding efficiency of the segmented routing message is improved, see Lyn, para 21-22.
As per claim 2 Filsfils and Lyn disclose the method according to claim 1.
Filsfils further discloses and wherein the obtaining, by the SFF, a second packet based on the first packet comprises: obtaining, by the SFF, the SID type based on the first SID and the first correspondence; and performing, by the SFF, first processing on the first packet based on the SID type to obtain the second packet, wherein the first processing comprises setting the first segment routing header behind the first IP payload, and further comprises replacing the first IP header with the second IP header (see page 15, An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment Identifier) is often used as a shorter reference for "SRv6 Segment". An SRv6-capable node N maintains a "My Local SID Table". This table contains all the local SRv6 segments explicitly instantiated at node N. N is the parent node for these SIDs. A local SID of N can be an IPv6 address associated to a local interface of N but it is not mandatory. Nor is the My Local SID table populated by default with all IPv6 addresses defined on node N. In most use-cases, a local SID will NOT be an address associated to a local interface of N.).
As per claim 3 Filsfils and Lyn disclose the method according to claim 1.
Filsfils further discloses wherein at least one of: the first segment routing header is a segment routing over internet protocol version 6 (SRv6) header, the first IP header and the second IP header both are internet protocol version 4 (IPv4) headers, and the first IP payload is an IPv4 payload; or the first segment routing header is an SRv6 header, the first IP header and the second IP header both are internet protocol version 6 (IPv6) headers, and the first IP payload is an IPv6 payload (see Fig. 3B, see page 10, see Fig. 3B, see page 10, FIG. 3B illustrates two Segment Routing (SR) packets 340 and 360 according to one embodiment. As shown, SR packet 340 (e.g. SRv6 packet) includes an SR encapsulating header 342 and native packet 349. SR encapsulating header 342 includes an 1Pv6 header 347 and one or more SR headers (SRHs) 348. As shown, SR packet 360 (e.g. SR-MPLS packet) includes an SR encapsulating header 362 and native packet 369. SR encapsulating header 362 includes an MPLS header 367 and a label stack of segments 368).
As per claim 4 Filsfils and Lyn disclose the method according to claim 1.
Filsfils further discloses wherein at least one of: the first segment routing header is a segment routing-multiprotocol label switching (SR-MPLS) header, the first IP header and the second IP header both are IPv4 headers, and the first IP payload is an IPv4 payload; or the first segment routing header is an SR-MPLS header, the first IP header and the second IP header both are IPv6 headers, and the first IP payload is an IPv6 payload (see Fig. 3B, see page 10, As shown, SR packet 360 (e.g. SR-MPLS packet) includes an SR encapsulating header 362 and native packet 369. SR encapsulating header 362 includes an MPLS header 367 and a label stack of segments 368).
As per claim 5 Filsfils and Lyn disclose the method according to claim 1.
Filsfils further discloses further comprising performing, after the sending the second packet to the SF device: receiving, by the SFF, a third packet from the SF device, wherein the third packet comprises a third IP header, a second IP payload, and the first segment routing header, and the third IP header is encapsulated in an outer layer of the second IP payload and the first segment routing header; obtaining, by the SFF, a fourth packet based on the third packet, wherein the fourth packet comprises the first segment routing header, a fourth IP header, and a third IP payload, and the first segment routing header is encapsulated in an outer layer of the fourth IP header and the third IP payload; and sending, by the SFF, the fourth packet based on the first segment routing header (see Fig. 4, page 11, FIG. 4 illustrates mapping data structures 401 to identify a stored encapsulating header in SR encapsulating header storage 420 according to one embodiment. Active segments 402 (e.g., SRv6 or MPLS SID) are hashed resulting in hash values 403 into hash table 404 storing pointers 405 to corresponding stored encapsulating headers in SR encapsulating header storage 420. Thus, a gateway receiving an SR packet identifies the storage location for storing the stored encapsulating header (e.g., provides for updating of a SR policy for a segment based on a subsequently received SR packet with a same active segment)).
As per claim 6 Filsfils and Lyn disclose the method according to claim 5.
Filsfils further discloses wherein the obtaining the fourth packet based on the third packet comprises performing at least one of: obtaining the fourth packet by performing, by the SFF, second processing on the third packet based on the third IP header wherein the second processing comprises replacing the third IP header with the fourth IP header, and further comprises encapsulating the first segment routing header in the outer layer of the fourth IP header and the third IP payload; obtaining the fourth packet by performing, by the SFF, second processing on the third packet based on an interface for receiving the third packet, wherein the interface for receiving the third packet is an inbound interface bound to the first SID, and wherein the second processing comprises replacing the third IP header with the fourth IP header, and further comprises encapsulating the first segment routing header in the outer layer of the fourth IP header and the third IP payload; or obtaining the fourth packet by performing, by the SFF, second processing on the third packet based on the third IP header and an interface for receiving the third packet, wherein the interface for receiving the third packet is an inbound interface bound to the first SID, and wherein the second processing comprises replacing the third IP header with the fourth IP header, and further comprises encapsulating the first segment routing header in the outer layer of the fourth IP header and the third IP payload (see Fig. 4, page 11, the segment routing header is stored in the forwarder and re-incorporated into the processed packet when the processed packet arrives back from the service function by looking at a mapping (e.g. Fig. 4). Appending the segment routing header to the native packet (essentially storing the segment routing header into the packet that will come back after processing) rather than storing the segment routing header in the forwarder for later use (i.e. in the mapping table of Fig. 4)).
As per claim 7 Filsfils and Lyn disclose the method according to claim 5.
Filsfils further discloses wherein the third IP header further comprises first length information, and wherein the first length information is associated with a location of the first segment routing header in the third packet (see page 1, Fig.4, continuing in process block 392 of FIG. 3C, the received SR packet (including the SR encapsulating header) is stored in shared memory, with a shared memory mapping data structure for identifying the location of the start of the SR packet from the location of the start of the native packet updated accordingly. Processing proceeds to process block 396).
As per claim 8 Filsfils and Lyn disclose the method according to claim 1.
Filsfils further discloses wherein the second IP header comprises identification information, and wherein the identification information identifies that the first segment routing header is set behind the first IP payload (see page 22, conveniently reuse the next-header value 59 allocated to 1Pv6 No Next Header. When the SID is of function End.DX2 and the Next-Header=59, we know that an Ethernet frame is in the payload without any further header, see also page 57, when the SID is of function End.DX2V and the Next-Header=59, we know that an Ethernet frame is in the payload without any further header.).
As per claim 9 Filsfils and Lyn disclose the method according to claim 8.
Filsfils further discloses wherein the second IP header further comprises second length information, and wherein the second length information indicates at least one of a length of the first IP payload or a sum of lengths of the first IP payload and the second IP header (see page 15, an SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment Identifier) is often used as a shorter reference for "SRv6 Segment".).
As per claim 10 Filsfils and Lyn disclose the method according to claim 8.
Filsfils further discloses wherein the second IP header comprises a first option, and wherein a type field of the first option carries the identification information (see page 14, NH is the abbreviation of the IPv6 next-header field. NH=SRH means that the next-header field is 43 with routing type 4. When there are multiple SRHs, they must follow each other: the next header field of all SRH except the last one must be SRH. The effective next-header (ENH) is the next-header field of the IP header when no SRH is present, or is the next-header field of the last SRH).
As per claim 11, Filsfils disclose A packet processing apparatus (see Fig.2A, Fig.2B, SR-CAPABLE PACKET SWITCHING DEVICE (E.G., GATEWAY, APPLIANCE, ROUTER 200), wherein the apparatus is disposed in a service function forwarder (SFF) (see Fig.2A, Fig.2B, Fig.9, a service function forwarder / SR proxy) and comprises: at least one processor (see Fig.2A, 2B, Processing Elements 221); and at least one non-transitory computer readable memory (see Fig.2A, 2B, MEMORY 222 (INSTRUCTIONS, DATA), ) connected to the at least one processor and including computer program code (see page 68, Network program/ including computer program code) and wherein the first segment routing header comprises a first segment identifier (SID), and wherein the first segment routing header is encapsulated in an outer layer of the first IP header and the first IP payload (see rejection of claim 1) store a first correspondence, wherein the first correspondence comprises the first SID and a SID type, and the SID type indicates that a segment routing header is not supported (see rejection of claim 1).
Filsfils and Lyn disclose the additional elements of claim 16 as discussed per claim 1 above.
As per claim 12, Filsfils and Lyn disclose all the elements as discussed per claims 2 above.
As per claim 13, Filsfils and Lyn disclose all the elements as discussed per claims 5 above.
As per claim 14, Filsfils and Lyn disclose all the elements as discussed per claims 6 above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraph 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) 15 and 18-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Filsfils et al. (WO2019005949A1).
As per claim 15, Filsfils disclose A packet processing apparatus (see Fig.2A, Fig.2B, SR-CAPABLE PACKET SWITCHING DEVICE (E.G., GATEWAY, APPLIANCE, ROUTER 200), wherein the apparatus is disposed in a service function (SF) device (see Fig.2A, Fig.2B, Fig.9, SR proxy) and comprises: at least one processor (see Fig.2A, 2B, Processing Elements 221); and at least one non-transitory computer readable memory connected to the at least one processor and including computer program code (see Fig.2A, 2B, MEMORY 222 (INSTRUCTIONS, DATA), wherein the at least one non-transitory computer readable memory and the computer program code are configured, with the at least one processor (see page 68, Network program/ including computer program code), to cause the apparatus to at least:
receive a first packet from a service function forwarder (SFF), wherein the first packet comprises a first internet protocol (IP) header, a first IP payload, and a first segment routing header, wherein the first segment routing header is set behind the first IP payload, and wherein the first IP header is encapsulated in an outer layer of the first IP payload and the first segment routing header (see Fig.9, page 75 lines 20-page 81, where the packets received by the SR proxy includes a 1Pv6 header that is placed before the SRH and payload, see also Fig 1B page 6 lines 26 – page 7 lines 1-15); and perform service processing based on the first packet (see Fig.9, where the proxy processes the packets to perform subsequent forwarding).
As per claim 18, Filsfils disclose the apparatus according to claim 15.
Filsfils further discloses wherein the first IP header comprises identification information, and wherein the identification information identifies that the first segment routing header is set behind the first IP payload (see page 22, conveniently reuse the next-header value 59 allocated to 1Pv6 No Next Header. When the SID is of function End.DX2 and the Next-Header=59, we know that an Ethernet frame is in the payload without any further header, see also page 57, when the SID is of function End.DX2V and the Next-Header=59, we know that an Ethernet frame is in the payload without any further header).
As per claim 19, Filsfils disclose the apparatus according to claim 18.
Filsfils further discloses wherein the first IP header further comprises second length information, and wherein the second length information indicates at least one of a length of the first IP payload, or a sum of lengths of the first IP payload and the first IP header (see page 15, an SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment Identifier) is often used as a shorter reference for "SRv6 Segment").
As per claim 20, Filsfils disclose the apparatus according to claim 18.
Filsfils further discloses wherein the first IP header comprises a first option, and wherein a type field of the first option carries the identification information (see page 14, NH is the abbreviation of the IPv6 next-header field. NH=SRH means that the next-header field is 43 with routing type 4.
When there are multiple SRHs, they must follow each other: the next header field of all SRH except the last one must be SRH. The effective next-header (ENH) is the next-header field of the IP header when no SRH is present, or is the next-header field of the last SRH).
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils et al. (WO2019005949A1), and further in view of Lyu (CN112787927A).
As per claim 16, Filsfils disclose the apparatus according to claim 15.
Filsfils does not explicitly disclose wherein the at least one non-transitory computer readable memory and the computer program code are configured, with the at least one processor, to further cause the apparatus to perform at least one of send, to the SFF, a second packet obtained through the service processing, wherein the second packet comprises a second IP header, a second IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the second IP payload and the first segment routing header.
Lyn however disclose wherein the at least one non-transitory computer readable memory and the computer program code are configured, with the at least one processor, to further cause the apparatus to perform at least one of send, to the SFF, a second packet obtained through the service processing, wherein the second packet comprises a second IP header, a second IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the second IP payload and the first segment routing header (see page 9, S608, S608, all SRHs in the message are moved to the tail offset field of the analysis message, see also page 10, "EndSRHOffset field: The length is 2 bytes. The offset after logically moving the SRH header to the end of the message comes from the value of the parsing message").
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the at least one non-transitory computer readable memory and the computer program code are configured, with the at least one processor, to further cause the apparatus to perform at least one of send, to the SFF, a second packet obtained through the service processing, wherein the second packet comprises a second IP header, a second IP payload, and the first segment routing header, and wherein the second IP header is encapsulated in an outer layer of the second IP payload and the first segment routing header, as taught by Lyn, in the system of Filsfils, so as to provide a segmented routing message forwarding method, a segmented routing message forwarding device and a preset logic circuit unit, so that forwarding efficiency of the segmented routing message is improved, see Lyn, Abstract.
As per claim 17 Filsfils and Lyn disclose the apparatus according to claim 16.
Filsfils further discloses wherein the second IP header further comprises first length information, and wherein the first length information is associated with a location of the first segment routing header in the second packet (see page 1, Fig.4, continuing in process block 392 of FIG. 3C, the received SR packet (including the SR encapsulating header) is stored in shared memory, with a shared memory mapping data structure for identifying the location of the start of the SR packet from the location of the start of the native packet updated accordingly. Processing proceeds to process block 396).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent are -
• Guichard (US20170244631A1) – Related art in the area of a device in a network receives a packet that includes one or more forwarding labels and a service function chaining (SFC) header.
• Nainar (US20170250908A1) – Related art in the area of segment-routing methods and systems that facilitate data plane signaling of a packet as a candidate for capture at various network nodes within a segment routing (SR) network.
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 WILLIAM C VAUGHN JR whose telephone number is (571)272-3922. The examiner can normally be reached Monday-Friday, 8:30am-5:00pm.
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, Amy Johnson can be reached at 571-272-2238. 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.
/WILLIAM C VAUGHN JR/Supervisory Patent Examiner, Art Unit 2481
Prosecution Insights