DETAILED ACTION
Applicant's submission filed on 3 November 2025 has been entered. Claims 1, 3-8, 10-13, 15, 17, 19, and 20 are currently amended; no claims are cancelled; claims 2, 9, 14, 16, and 18 are previously presented; no claims have been added. Claims 1-20 are pending and ready for examination.
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot in view of the new grounds of rejection.
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 nonobviousness.
Claims 1-3, 7-10, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bocci et al, “MPLS Generic Associated Channel”, RFC 5586, June 2009, XP015065601, hereafter referred Bocci, in view of Krzanowski (US 2011/0090909 A1), further in view of WO 2011/015102 A1. A machine translation of WO 2011/015102 A1 is provided and is hereafter referred Guo. Bocci and Krzanowski were cited by applicant’s IDS filed 12 September 2024.
Regarding claim 1, Bocci teaches a packet processing method comprising:
generating an Internet Protocol version 6 (IPv6) packet comprising an associated channel data carrying a plurality of control channels of different types, wherein the plurality of control channels comprises management messages (Bocci, paragraph 1 and 2.1-3.3; This document defines a mechanism that is recommended for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in RFC4379 and BFD-MPLS are not available. Yet this mechanism may be used in addition to IP-based mechanisms. A set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages. The Channel Type field indicates the type of message carried on the associated control channel, e.g. IPv4 or IPv6); and
forwarding the IPv6 packet (Bocci, Figures 5-8, paragraph 4.2.1.1-4.2.1.2; packet are forwarded between the different entities in the figures, in order to provide the necessary communication management).
Bocci does not expressly teach wherein the plurality of control channels comprises control types.
However, Krzanowski teaches wherein the plurality of control channels comprises control types (Krzanowski, Fig. 11A, [0059]-[0061]; a VCCV Parameter field 1102 may include a Type 1104, a Length 1106, Control Channel Types 1108, and Connectivity Verification Types 1110, where the CC Types 1108 may carry an eight-bit field to indicate the type of control channels by which a router is capable of receiving control traffic and bits 0-2 can designate one of three control channel types (e.g. as assigned by the Internet Assigned Numbers Authority (IRNA))).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci to include the above recited limitations as taught by Krzanowski in order to distinguish the control messages from other packets (Krzanowski, [0061]).
Bocci in view of Krzanowski does not expressly teach wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels.
However, Guo teaches wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels (Guo, p. 16-21, Table 11; an interface parameter type length value field carrying a general integrated control channel header subtype length value field may be added and provide associated channel capability information for sending a label mapping message to the upstream node, where the length indicates the length, the Interface 1 ID indicates the identifier of the interface 1 which can include IPV6, the associated channel capability parameter bitmap of the interface may include information such as OAM, APS, MCC, SCC, and the special label GAL, mode 3 puts the associated channel capability information of each interface as an independent TLV in the TLV of the node).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski to include the above recited limitations as taught by Guo in order to have better flexibility in extending the capability information of the associated channel of the bearer (Guo, p. 20).
Regarding claim 8, Bocci teaches a communication apparatus comprising:
receive an Internet Protocol version 6 (IPv6) packet comprising an associated channel data carrying control channels of different types, wherein the control channels comprise management messages (Bocci, paragraph 1 and 2.1-3.3; This document defines a mechanism that is recommended for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in RFC4379 and BFD-MPLS are not available. Yet this mechanism may be used in addition to IP-based mechanisms. A set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages. The Channel Type field indicates the type of message carried on the associated control channel, e.g. IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel or OAM or other maintenance function if IP demultiplexing is not used); and
obtain the control types and management messages (Bocci, Figures 5-8, paragraph 4.2.1.1-4.2.1.2; packet are received and unpacked by the different entities in the figures, in order to receive the comprised OAM messages within them).
Bocci does not expressly teach a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions; and
wherein the control channels comprise control types.
However, Krzanowski teaches a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions (Krzanowski, [0089]; implementations that have been described as “logic” may include hardware, such as a processor, an application specific integrated circuit, FPGA, software, or a combination of hardware and software); and
wherein the control channels comprise control types (Krzanowski, Fig. 11A, [0059]-[0061]; a VCCV Parameter field 1102 may include a Type 1104, a Length 1106, Control Channel Types 1108, and Connectivity Verification Types 1110, where the CC Types 1108 may carry an eight-bit field to indicate the type of control channels by which a router is capable of receiving control traffic and bits 0-2 can designate one of three control channel types (e.g. as assigned by the Internet Assigned Numbers Authority (IRNA))).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci to include the above recited limitations as taught by Krzanowski in order to distinguish the control messages from other packets (Krzanowski, [0061]).
Bocci in view of Krzanowski does not expressly teach wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels.
However, Guo teaches wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels (Guo, p. 16-21, Table 11; an interface parameter type length value field carrying a general integrated control channel header subtype length value field may be added and provide associated channel capability information for sending a label mapping message to the upstream node, where the length indicates the length, the Interface 1 ID indicates the identifier of the interface 1 which can include IPV6, the associated channel capability parameter bitmap of the interface may include information such as OAM, APS, MCC, SCC, and the special label GAL, mode 3 puts the associated channel capability information of each interface as an independent TLV in the TLV of the node).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski to include the above recited limitations as taught by Guo in order to have better flexibility in extending the capability information of the associated channel of the bearer (Guo, p. 20).
Regarding claim 17, Bocci teaches a communication apparatus comprising:
obtain an Internet Protocol version 6 (IPv6) packet comprising an associated channel data carrying control channels of different types, wherein the control channels comprise management messages (Bocci, paragraph 1 and 2.1-3.3; This document defines a mechanism that is recommended for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in RFC4379 and BFD-MPLS are not available. Yet this mechanism may be used in addition to IP-based mechanisms. A set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages. The Channel Type field indicates the type of message carried on the associated control channel, e.g. IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel or OAM or other maintenance function if IP demultiplexing is not used); and
forwarding the IPv6 packet (Bocci, Figures 5-8, paragraph 4.2.1.1-4.2.1.2; packet are forwarded between the different entities in the figures, in order to provide the necessary communication management).
Bocci does not expressly teach a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions; and
wherein the control channels comprise control types.
However, Krzanowski teaches a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions (Krzanowski, [0089]; implementations that have been described as “logic” may include hardware, such as a processor, an application specific integrated circuit, FPGA, software, or a combination of hardware and software); and
wherein the control channels comprise control types (Krzanowski, Fig. 11A, [0059]-[0061]; a VCCV Parameter field 1102 may include a Type 1104, a Length 1106, Control Channel Types 1108, and Connectivity Verification Types 1110, where the CC Types 1108 may carry an eight-bit field to indicate the type of control channels by which a router is capable of receiving control traffic and bits 0-2 can designate one of three control channel types (e.g. as assigned by the Internet Assigned Numbers Authority (IRNA))).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci to include the above recited limitations as taught by Krzanowski in order to distinguish the control messages from other packets (Krzanowski, [0061]).
Bocci in view of Krzanowski does not expressly teach wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels.
However, Guo teaches wherein the IPv6 packet further comprises an IPv6 extension header comprising a Type-Length-Value (TLV) field, wherein the TLV field comprises a plurality of channel type fields indicating the different types of control channels in the plurality of control channels carried by the associated channel data, and wherein the plurality of channel type fields is in a one-to-one correspondence with the plurality of control channels (Guo, p. 16-21, Table 11; an interface parameter type length value field carrying a general integrated control channel header subtype length value field may be added and provide associated channel capability information for sending a label mapping message to the upstream node, where the length indicates the length, the Interface 1 ID indicates the identifier of the interface 1 which can include IPV6, the associated channel capability parameter bitmap of the interface may include information such as OAM, APS, MCC, SCC, and the special label GAL, mode 3 puts the associated channel capability information of each interface as an independent TLV in the TLV of the node).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski to include the above recited limitations as taught by Guo in order to have better flexibility in extending the capability information of the associated channel of the bearer (Guo, p. 20).
Regarding claims 2, 9, and 18, Bocci in view of Krzanowski further in view of Guo teaches the packet processing method of claim 1, the communication apparatus of claim 8, and the communication apparatus of claim 17 above. Further, Bocci teaches wherein the IPv6 packet further comprises indication information indicating the associated channel data (Bocci, paragraph 2.2; the channel type indicates the specific protocol carried in the associated control channel).
Regarding claims 3, 10, and 19, Bocci in view of Krzanowski further in view of Guo teaches the packet processing method of claim 2, the communication apparatus of claim 9, and the communication apparatus of claim 18 above. Further, Bocci teaches wherein the TLV field further comprises a type field that carries the indication information (Bocci, paragraph 3-3.3; ACH TLVs have a TLV header, where the Channel Type defines that ACH TLVs may be used and has the payload structure shown in Figures 2-3).
Regarding claims 7 and 15, Bocci in view of Krzanowski teaches the packet processing method of claim 1 and the communication apparatus of claim 8 above. Further, Bocci teaches wherein the control channels of different types comprise any one or more of the following: an operation, administration and maintenance (OAM) channel, a fault indication channel, a resource management channel, a signaling communication channel (SCC), or a management communication channel (MCC) (Bocci, paragraph 1 and 2.1-3.3; This document defines a mechanism that is recommended for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in RFC4379 and BFD-MPLS are not available. Yet this mechanism may be used in addition to IP-based mechanisms. A set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages. The Channel Type field indicates the type of message carried on the associated control channel, e.g. IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel or OAM or other maintenance function if IP demultiplexing is not used).
Claims 4, 5, 11, 12, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bocci in view of Krzanowski as applied to claims 1 and 8 above, and further in view of Bonica et al. (US 2020/0366763 A1), hereafter referred Bonica.
Regarding claims 4, 11, and 20, Bocci in view of Krzanowski further in view of Guo teaches the packet processing method of claim 3, the communication apparatus of claim 10, and the communication apparatus of claim 19 above. Bocci in view of Krzanowski further in view of Guo does not expressly teach wherein the IPv6 extension header is a destination option header (DOH).
However, Bonica teaches wherein the IPv6 extension header is a destination option header (DOH) (Bonica, [0047]; between the IP payload header and the IPv6 transport header may be a set of extension headers (e.g. a hop-by-hop extension header, a destination header, or the like)).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski further in view of Guo to include the above recited limitations as taught by Bonica in order to steer a payload packet through a specific path to a destination (Bonica, [0002]).
Regarding claims 5 and 12, Bocci in view of Krzanowski further in view of Guo teaches the packet processing method of claim 1 and the communication apparatus of claim 8 above. Bocci in view of Krzanowski further in view of Guo does not expressly teach wherein the IPv6 packet further comprises an extension header carrying the associated channel data, and wherein the extension header is a hop-by-hop (HBH) option header.
However, Bonica teaches wherein the IPv6 packet further comprises an extension header carrying the associated channel data, and wherein the extension header is a hop-by-hop (HBH) option header (Bonica, [0047]; between the IP payload header and the IPv6 transport header may be a set of extension headers (e.g. a hop-by-hop extension header, a destination header, or the like)).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski further in view of Guo to include the above recited limitations as taught by Bonica in order to steer a payload packet through a specific path to a destination (Bonica, [0002]).
Regarding 14, Bocci in view of Krzanowski further in view of Guo teaches the communication apparatus of claim 8 above. Bocci in view of Krzanowski further in view of Guo does not expressly teach wherein the IPv6 packet further comprises identification information identifying a transmission path of the IPv6 packet.
However, Bonica teaches wherein the IPv6 packet further comprises identification information identifying a transmission path of the IPv6 packet (Bonica, [0043]-[0045]; the first edge node may encapsulate the IP payload packet using an IPv6 transport header that has been extended using a CRH, where the CRH may include a list of SIDs that define the path for the IP payload packet).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski further in view of Guo to include the above recited limitations as taught by Bonica in order to steer a payload packet through a specific path to a destination (Bonica, [0002]).
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Bocci in view of Krzanowski further in view of Guo as applied to claims 1 and 8 above, and further in view of Filsfils et al. (US 2019/0215267 A1), hereafter referred Filsfils.
Regarding claims 6 and 13, Bocci in view of Krzanowski further in view of Guo teaches the packet processing method of claim 1 and the communication apparatus of claim 8 above. Bocci in view of Krzanowski further in view of Guo does not expressly teach wherein the IPv6 packet is a Segment Routing over IPv6 (SRv6) packet, and wherein the IPv6 extension header is a Segment Routing Header (SRH) of the SRv6 packet.
However, Filsfils teaches wherein the IPv6 packet is a Segment Routing over IPv6 (SRv6) packet, and wherein the IPv6 extension header is a Segment Routing Header (SRH) of the SRv6 packet (Filsfils, [0017]; the particular packet sent from the particular router is an IPv6 packet including a Segment Routing version 6 (SRv6) header).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing date of the invention to create the invention of Bocci in view of Krzanowski further in view of Guo to include the above recited limitations as taught by Filsfils in order to achieve greater bandwidth (Filsfils, [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODRICK MAK whose telephone number is (571)270-0284. The examiner can normally be reached Monday - Friday 9:30 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Noel Beharry can be reached at 571-270-5630. 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.
/R.M./Examiner, Art Unit 2416
/NOEL R BEHARRY/Supervisory Patent Examiner, Art Unit 2416