DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicants’ arguments filed 07/22/2026 have been fully considered but they are not persuasive.
-Regarding the 112 rejection, applicant argued that because of the instant application states that the hosts are edge devices that are in BIER domain, and edge devices of BIER domain are BFER (BIER forwarding egress router).
Examiner respectfully Disagrees:
Applicant rely on inference to define what a claim limitations meaning entails to. First, applicant assumed that all edge nodes in BIER domain are BFER (BIER forwarding egress router). However, in BIER domain, there can be BIER supporting nodes and non-BIER supporting nodes. When the non-BIER supporting nodes are at the edge, the node could not correspond to BFER. As to applicants’ argument that all edge devices in BIER domain are BFER, for instance, non-relied upon prior art US pat. No. 10567181 in fig. 1C discloses BIER domain comprising BIER ingress device, BIER forwarding device and Non-BIER egress (edge device that is not BFER). However, just because the non-BIER egress device is at the edge, we could not assume that it is BFER, because explicitly indicated that it is not. The limitation, the host device is BFER as claimed in the claims is specific limitation that changes scope, hence explicit support is needed.
Further, claim 1 states that the first host is a BIER neighbor but that does not support BIER forwarding behavior. Claim 18 that comprises all limitations of claim 1 states that the first host is BFER. The two seem to contradict.
There is no support in the disclosure that associates the BIER neighbor that does not support the BIER forwarding behavior of claim 1 is equivalent to the BFER of claim 18. Contrary to the fact what is known in the art that is BFER is edge node that supports BIER forwarding, there is no support in the disclosure that shows how the two are equivalent and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art … to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention as required by the statue of 112a.
The 112a statue states that “The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms”. Applicant did not indicate support in the disclosure in such full, clear, concise, and exact terms that supports the limitations in corresponding claims.
-Regarding the 103 rejection:
Applicant argued that “Figure 6B and Figure 7 are explicitly given as separate embodiments. Figure 6B specifically provides a communication technique for when there are nodes PE1 and PE2 and these are each located in different IGP domains, as in paragraph [0314] of the US equivalent. Figure 7 is then based on three total nodes, PE 2, P20, and a BR 2, which are in the same IGP domain”.
Examiner respectfully disagrees:
Applicant is arguing as if there are only few nodes such as BR2 and PE2 that are in a network. Fig. 6B or Fig. 7 are diagrammatic representation to simplify the concept and forward it in simplistic way to the reader. There may be nodes between BR2 and PE2 or after PE2 that forwards received packet to destination using similar mechanism indicated in fig. 6B and fig. 7. In no way, it is written to indicate that any network contains only nodes indicated in the figure. Nowhere in the disclosure is indicated that BR2 of fig.6 or PE2 of fig. 7 could not correspond to the first device of the claim, or any of the nodes in the corresponding networks could not correspond to the first device. Both devices, BR2 of fig.6B and PE2 of fig. 7 receive packets as required by the first device of the claim.
Further, the scope of the claim is that nodes in any type of network domain configuration reads on the limitations. Nowhere in the claim or the disclosure that it disclosed that nodes in two network domains of claim 6B or nodes in single domain of fig. 7 could not correspond to the nodes of the claim. Since the embodiment difference for fig. 6B, and 7 is based on the nodes being in a single domain and two different domain and that distinction is irrelevant to the scope of the claim requirement, both domain configurations of fig. 6B and fig. 7 reads on the limitation without any need to reason out a motivation to combine. Because, 6B and fig. 7 are similar concepts that equally read on the limitations of the claim. Applicant`s argument would have been persuasive, if the claim explicitly claims specific domain configuration for the nodes to be in either a single domain or a two domain. In the current form, any nodes in any type of network domain configuration as fig. 6B two domain or fig. 7 single domain read on the limitations.
- Applicant further argued that the combination does not disclose "popping up, by the first routing device, the DOH that comprises the BIER option...," since BR2 of Figure 6B (Embodiment 1) is explicitly a different node than PE2 of Figure 7 (Embodiment 2)
Examiner respectfully disagrees:
The scope of the claim is that nodes in any type of domain configuration reads on the limitations. Nowhere in the disclosure is it described that a node either in two domain network or single domain network only correspond to the nodes of the limitation. The scope of the claim is that nodes in any type of domain configuration reads on the limitations. Embodiment difference of fig. 6B and fig. 7 of the prior art is based on the nodes being in two domain network for fig. 6 and the nodes being in a single domain network for fig. 7. however, that difference is irrelevant to the scope of the claim. The two figures perform the same functions despite the network domain configurations. The two would not contradict. Nowhere in the claim or the disclosure it is disclosed that nodes in two network domains of claim 6B could not correspond to the nodes of the claim or nodes of single domain of fig.7 could not correspond to nodes of the claim. Applicant`s argument would have been persuasive, if the claim explicitly claims specific domain configuration for the nodes of the claim to be in either a single domain or a two domain. In the current form, any nodes in any type of network domain configuration as fig. 6B two domain or fig. 7 single domain read on the limitations. Since the embodiment difference for fig. 6B, and 7 is based on the nodes being in a single domain and two different domain and that distinction is irrelevant to the scope of the claim requirement, both domain configuration of fig. 6B and fig. 7 reads on the limitation without any need to reason out a motivation to combine.
Applicant is arguing as if there are only few nodes such as BR2 and PE2 that are in a network. Fig. 6B or Fig. 7 are diagrammatic representation to simplify the concept and forward it in simplistic way to the reader. There may be nodes between BR2 and PE2 or after PE2 that forwards received packet to destination using similar mechanism indicated in fig. 6B and fig. 7. In no way, it is written to indicate that any network contains only nodes indicated in the figure. Nowhere in the disclosure, is indicated that BR2 of fig.6 or PE2 of fig. 7 could not correspond to the first device of the claim, or any of the nodes in the corresponding networks could not correspond to the first device.
Xie in fig. 7 discloses similarly popping the DOH comprising the BIER option before forwarding to the target. In the second packet sent to CE2, DOH with BIER information is popped out. Obtaining the IP address of the final packet using IP address information of received packet as indicated in[0168] of the instant application by translation/ conversion or copying are well known hence obvious to a PHOSITA.
Zhang Introduction discloses “ One way to solve this problem is to use Penultimate Hop Popping (PHP) so that the upstream BFR can pop the BIER header (DOH)and send the payload "natively"”.
- Applicant further argued that " Similarly, "the DOH that comprises the BIER option and that is in the first packet to obtain..." is not taught, since the packet sent by BR1 to BR2 in Figure 6B is a
different packet than the packet sent by BR2 to PE2 in Figure 7.
Examiner Respectfully Disagrees:
Applicant argued that the packets are not the same. The packets being the same or different are not the requirements of the claim limitation. The claim limitation requires that the first packet that received by the first device to comprise DOH that comprises BIER option. The packet received by BR2 of fig.6B or PE2 of fig 7 (both mapped to correspond to the first device) comprises DOH that comprises BIER option. Both fig. 6B and fig. 7 discloses that above packet to comprise DOH that comprises BIER option hence teaching the limitation. Applicant is arguing as if there are only two nodes. Fig. 6B or Fig. 7 are diagrammatic representation to simplify the concept and forward it in simplistic way to the reader. In no way, it is written to indicate that any network contains only nodes indicated in the figure. There may be any other nodes in the network indicated that performs the mechanism indicated in the figure and read on the limitation.
Zhang, Introduction discloses “is to use Penultimate Hop Popping (PHP) so that the upstream BFR can pop the BIER header and send the payload "natively"”. The packet received by BFR comprises DOH with BIER index that needed to be popped to forward it.
- Applicant argued that the combination does not disclose: "a second IPv6 header obtained based on the first IPv6 header" as claimed is not taught”.
Examiner respectfully Disagrees:
Xie in fig. 6B discloses BR2 receives packet; BR2 creates a second packet based on the first packet received wherein the second packet comprises IPV6 header inner (inherently that corresponds to upper layer header), payload (inherently that corresponds to upper-layer payload; IPV6 header (outer) (corresponds to second IPV6 header) that is obtained by modifying DA of the first IPV6 header in the received packet that corresponds to obtaining a second packet based on the first packet. Any node in the network apart from BR2 of fig. 6B and PE2 of fig. 7 can be the first device that performs the above function. Nodes in the network of fig. 6B and fig. 7 are capable of obtaining a second IPv6 header based on the first IPv6 header.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 18-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The disclosure does not explicitly discloses that the first host that receives payload after popping the DOH is the BIER forwarding egress router (BFER) in explicit and exact terms.
The instant disclosure indicates BFER in as:
[0095]…When the multicast data packet enters a BIER domain, a bit forwarding ingress router (BFIR, an ingress node in the BIER domain) determines a bit forwarding egress router (BFER, an egress node in the BIER domain) set to which the packet needs to be sent. The BFIR encapsulates a BIER option (also referred to as a BIER header) into the packet. The BIER option includes the bitstring.
[0096] In some embodiments, the BIER generally refers to a method for encapsulating and forwarding a packet based on a bitstring. A transmit end encapsulates the bitstring into the packet, and after receiving the packet including the bitstring, a routing device duplicates the packet based on the bitstring and sends the packet to a destination node. In some embodiments, a BIER packet reuses an original BIER packet format.
(5) Bitstring
[0097] A bitstring represents a group of BFERs in a BIER domain, and cach bit in the bitstring corresponds to one BFER. Bits set in the bitstring are a set of identifiers of destination BFER nodes of a packet. When a BFIR needs to forward a packet to a specified group of BFERs through a transit node, the BFIR sets all bits that correspond to the specified group of BFERs and that are in a BIER option, so that the transit node can duplicate the packet based on a setting situation in the bitstring and forward the packet.
The disclosure does not explicitly discloses that the first host that receives payload after popping the DOH is the BIER forwarding egress router (BFER) in explicit and exact terms. The limitation does not have a support in the specification as filed.
Applicant may assume that because the first host is at the edge in BIER domain, it would correspond as BFER. Not all edge devices in BIER domain correspond to BFER. For instance, non-relied upon prior art US pat. No. 10567181 in fig. 1C discloses BIER domain comprising BIER ingress device, BIER forwarding device and Non-BIER egress (edge device that is not BFER). However, just because the non-BIER egress device is at the edge, we could not assume that it is BFER, because explicitly indicated that it is not. Since the host being BFER is specifically claimed and that it affects the bounds and limits of the claims, written description support of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art … to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention is required.
Further, claim 1 states that the first host is a BIER neighbor but that does not support BIER forwarding behavior. Claim 18 that comprises all limitations of claim 1 states that the first host is BFER. These two seem to contradict. There is no support in the disclosure that associates the BIER neighbor that does not support the BIER forwarding behavior of claim 1 is equivalent to the BFER of claim 18. Contrary to the fact what is known in the art that is BFER is edge node that supports BIER forwarding. There is no support in the disclosure that shows how the two are equivalent and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art … to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
The 112b statue states that “The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms”. Applicant did not indicate support in the disclosure in such full, clear, concise, and exact terms that supports the limitations in corresponding claims.
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.
Claims) 1-4, 6, 8-11, and 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xie (WO 2020088696A1), further in view of Zhang “BIER Penultimate Hop Popping”.
Regarding claim 1. Xie discloses a method comprising:
receiving, by a first routing device a first packet (fig. 7 discloses PE2 receives packet from BR2. It discloses The BR 2 encapsulates an outer IPv6 header, where a source address carried in the outer IPv6 header is an IPv6 address #1, and a destination address carried in the outer IPv6 header is a group address (DA<mcastY>). The BR 2 encapsulates an IPv6 destination option header, where the IPv6 destination option header includes a BIER header, the BIER header carries bitstring information 000001, and Proto is 4 or 6. Alternatively, the PE 1 encapsulates a BIER extension header, where the BIER extension header carries bitstring information 000001 and forwards it to PE2), wherein the first packet comprises a first internet protocol version 6 (IPv6) header, destination option header (DOH) , (fig. 7 discloses PE2 receives packet from BR2. It discloses The BR 2 encapsulates an outer IPv6 header (first internet protocol version 6 (IPv6) header. The BR 2 encapsulates an IPv6 destination option header (DOH), where the IPv6 destination option header includes a BIER header (BIER option), the BIER header carries bitstring information 000001, and Proto is 4 or 6 and forwards it to PE2; fig. 6B BR2 (first routing device) receives packet that comprises IPV6 header (outer) that corresponds to first IPV6 header, SRH header (second IPV6 extension header), IPV6 destination option header with BIER info (first IPV6 extension header), and an upper-layer header, and an upper-layer payload (fig. 7 PE2 (first routing device) receives packet that comprises IPV6 header (outer) that corresponds to first IPV6 header, IPV6 destination option header with BIER info (DOH with BIER option), IPV6 (inner) (upper layer IPV6 header) with SA:X and DA: mcastX, and payload (upper layer pay load)).
Xie further discloses DOH comprises a bit index explicit replication (BIER) option (page 26, lines 53-56 discloses BR2 encapsulates IPv6 Destination Option Header (DOH), where IPv6 Destination Option includes BIER header (BIER option), BIER header carries Bitstring information 000001, Proto = 4 or 6);
Popping, by the first routing device, the DOH that comprises the BIER option and that is in the first packet to obtain a second packet, wherein the second packet comprises the upper-layer header, the upper-layer payload, and a second Ipv6 header obtained based on the first Ipv6 header (fig. 6B discloses BR2 receives packet; BR2 creates a second packet based on the first packet received wherein the second packet comprises IPV6 header inner (inherently that corresponds to upper layer header), payload (inherently that corresponds to upper-layer payload; IPV6 header (outer) (corresponds to second IPV6 header) that is obtained by modifying DA of the first IPV6 header in the received packet that corresponds to obtaining a second packet based on the first packet; BR2 sends modified packet to subsequent nodes; fig. 7 discloses similarly popping the DOH comprising the BIER option before forwarding to the target. In the second packet sent to CE2, DOH with BIER information is popped out. Obtaining the IP address of the final packet using IP address information of received packet as indicated in[0168] of the instant application by translation/ conversion or copying are well known hence obvious to a PHOSITA); and
sending, by the first routing device, the second packet to a first host (fig. 7 discloses PE2 sends the second packet to CE2 (first host); fig. 6B BR2 sends packets to subsequent nodes);
But, Xie does not explicitly disclose:
wherein the first host is a serving as a BIER neighbor, but does not support BIER forwarding behavior;
However, in the same field of endeavor, Zhang discloses wherein the first host is a serving as a BIER neighbor, but does not support BIER forwarding behavior (Introduction discloses Consider an MVPN/EVPN deployment where enough P/PE routers are BIER capable for BIER to become the preferred the choice of provider tunnel. However, some PEs cannot be upgraded to support BIER forwarding (does not support BIER forwarding). While there are ways to allow an ingress PE to send traffic to some PEs with one type of tunnel and send traffic to some other PEs with a different type of tunnel, the procedure becomes complicated and forwarding is not optimized. One way to solve this problem is to use Penultimate Hop Popping (PHP) so that the upstream BFR can pop the BIER header and send the payload "natively").
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of Xie with Zhang. The modification would allow to send information for BIER egress node in order to effectively forward decapsulated data to final destination node that is not capable of processing encapsulated packet of BIER forwarding. The modification would allow effective networking and data forwarding.
Regarding claim 2. The combination discloses method according to claim 1.
Xie discloses, wherein the BIER option comprises a bitstring (fig. 7 discloses the IP packet in the IPv6 destination option header comprising BIER option with BIER bitstring 0000001), and obtaining, by the first routing device, the second packet based on the first packet further comprises:
obtaining, by the first routing device (fig. 7 PE2), indication information based on the bitstring, wherein the indication information indicates to pop up the DOH comprising the BIER option (page 26, lines 53-56 discloses BR2 encapsulates IPv6 Destination Option Header (DOH), where IPv6 Destination Option includes BIER header (BIER option), BIER header carries Bitstring information 000001, Proto = 4 or 6; or, PE1 encapsulates BIER extension header, BIER extension header carries Bitstring information 000001; fig. 7 and page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to Bit String = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IPv4 packet behind the outer IPv6 Destination Option); and
obtaining, by the first routing device, the second packet based on the indication information and the first packet (page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IP packet behind the outer IPv6 Destination Option; fig. 7 discloses PE2 decapsulates and determines message in format 2 to be forwarded to CE2 from message received from BR2).
Regarding claim 3. The combination discloses method according to claim 2.
Xie discloses, wherein obtaining, by the first routing device, the indication information based on the bitstring further comprises: obtaining, by the first routing device, an identifier of the first host based on the bitstring (page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2); and
obtaining, by the first routing device, the indication information based on a correspondence and the identifier of the first host, wherein the correspondence comprises the indication information and the identifier of the first host (page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IP packet behind the outer IPv6 Destination Option; fig. 7 discloses PE2 decapsulates and determines message in format 2 to be forwarded to CE2 from message received from BR2.
Regarding claim 4. The combination discloses method according to claim1.
Xie discloses, wherein the upper-layer header is a user datagram protocol (UDP) header, and the upper-layer payload is a UDP payload (fig. 7 discloses payload with its respective header originated from source of the packet that is encapsulated and forwarded towards to PE2. It is known in the art that the payload can be UDP/ TCP encapsulated. For example. Non-relied upon prior art JP-2010130611-A in fig. 20 discloses the upper layer header is UDP header and the upper layer payload is UDP payload).
Regarding claim 6. The combination discloses method according to claim 1.
Xie discloses , wherein the BIER option of the first packet comprises the bitstring, the bitstring comprises a first bit corresponding to the identifier of the first host, the first bit in the bitstring is set, and before the receiving, by a first routing device, a first packet (page 26, lines 53-6 and page 27 lines 1-17 discloses BR2 encapsulates IPv6 Destination Option Header, where IPv6 Destination Option includes BIER header, BIER header carries Bitstring information 000001 (bitstring and the first bit in the bitstring is set), Proto = 4 or 6; or, PE1 encapsulates BIER extension header, BIER ) extension header carries Bitstring information 000001; BR2 encapsulates the inner IPv6 header. The source address carried in the inner IPv6 header is the source address and destination address of the multicast data packet; the group address of the multicast data packet; The load of the BIER message is the IP message of the original multicast data message. In this case, the BIER message encapsulated by the first node is shown in format 2 in FIG. 7. In Figure 7, Hdr is the abbreviation of Header. Step 3: PE2 decapsulates the BIER message. After receiving the BIER message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message… PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IP packet (second IPv6) behind the outer IPv6 Destination Option), the method further comprises:
advertising, by the first routing device, the identifier of the first host between routing devices in a BIER domain (page 7, lines 1-7 discloses Figure 1 is a schematic diagram of the BIER message forwarding architecture. The diagram includes two different BIER domains (BIER domain 1 and BIER domain 2 as shown in Figure 1), and at the edges of BIER domain 1 and BIER domain 2, the edge BFR node that encapsulates multicast data is BFIR (such as (BFIR1 to BFIR4 shown in FIG. 1), the edge BFR node that decapsulates the BIER message is BFER (BFER1 to BFER4 shown in FIG. 1. Advertisement of routing information in the BIER domain corresponds to advertisement).
Regarding claim 8. Xie discloses an apparatus is disposed in a first routing device, the apparatus comprising: a memory storing instructions (fig. 7 PE2 corresponds to ana apparatus having memory); and a processor coupled to the memory to execute the instructions (fig. 7 PE2 has processor) to:
All other limitations of claim 8 are similar with the limitations of claim 1 above.
Regarding claim 9. The combination discloses apparatus according to claim 8.
All other limitations of claim 9 are similar with the limitations of claim 2 above and rejected on the analysis of claim 2.
Regarding claim 10. The combination discloses apparatus according to claim 9.
All other limitations of claim 10 are similar with the limitations of claim 3 above and are rejected on similar basis.
Regarding claim 11. The combination discloses apparatus according to claim 8.
All other limitations of claim 11 are similar with the limitations of claim 6 are rejected on the analysis of claim 6.
Regarding claim 13. Xie discloses an apparatus that is disposed in a first routing device (fig. 7 PE2), the apparatus comprising:
All other limitations of claim 13 are identical with the limitations of claim 8 rejected above.
Regarding claim 14. The combination discloses apparatus according to claim 13.
Xie discloses, wherein the BIER option comprises a bitstring (fig. 7 discloses the IP packet in the IPv6 destination option header comprising BIER option with BIER bitstring 0000001),, and the processor is coupled to the memory to execute instructions to:
obtain indication information and an IPv4 address of the first host based on the bitstring, wherein the indication information indicates the DOH comprising the BIER option and indicates to replace the IPv6 header with the IPv4 header (page 26, lines 53-56 discloses BR2 encapsulates IPv6 Destination Option Header (DOH), where IPv6 Destination Option includes BIER header (BIER option), BIER header carries Bitstring information 000001, Proto = 4 or 6; or, PE1 encapsulates BIER extension header, BIER extension header carries Bitstring information 000001; fig. 7 and page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IPv4 packet behind the outer IPv6 Destination Option); and
obtain the second packet based on the indication information, the IPv4 address of the first host, and the first packet, wherein a destination address in the IPv4 header of the second packet is the IPv4 address of the first host (fig. 7 and page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IPv4 packet behind the outer IPv6 Destination Option).
Regarding claim 15. The combination discloses and apparatus according to claim 14.
Xie discloses, wherein the processor is coupled to the memory to execute instructions to:
obtain an identifier of the first host based on the bitstring; and
obtain the indication information and the IPv4 address of the first host based on a first correspondence and the identifier of the first host, wherein the first correspondence comprises the indication information, the identifier of the first host, and the IPv4 address of the first host (fig. 7 and page 27, lines 8-17 discloses After receiving the message, PE2 determines that the message needs to be forwarded to the node with BFR-ID = 1 according to BitString = 000001 in the message, and in the above configuration information process, PE2 configures BFR-ID = 1. Therefore, it is decided to decapsulate the received BIER message. Specifically, the decapsulation includes: PE2 determines that the packet belongs to VRF # 2 according to the source address IPv6 address # 1 in the outer IPv6 header. PE2 then copies and sends the packet to the corresponding outgoing interface of VRF # 2 according to the source and destination addresses of the inner IPv4 packet behind the outer IPv6 Destination Option).
Regarding claim 16. The combination discloses apparatus according to claim 13.
All other limitations of claim 16 are similar with the limitations of claim 6 and are rejected on the analysis of claim 6 above.
Regarding claim 17. The combination discloses apparatus according to claim 13.
Xie discloses, wherein the processor is coupled to the memory to further execute the instructions to advertise, between the routing devices in the BIER domain, a correspondence between an IPv6 address of the first host and the IPv4 address of the first host (fig. 7 disclose IGP domain for BIER message communication that corresponds to BIER domain for devices exchanging IPV6 encapsulated packets. Utilizing any of the IGP protocols such as OSPF or IS-IS to advertise routing information (address information) among nodes in the IGP domain corresponds 8o advertising).
Regarding claim 18, the combination discloses method according to claim 1.
Xie further discloses, wherein the first host is a bit forwarding egress router (BFER) (fig. 1 discloses BIER domain ½ comprising BFER 1-4, any of the BFER can correspond to the first host).
Regarding claim 19, the combination discloses combination discloses method according to claim 8.
All other limitations of claim 19 are similar with the limitations of claim 18 above rejected above.
Regarding claim 20, the combination discloses the method according to claim 13.
All other limitations of claim 20 are similar with the limitations of claim 18 rejected above.
Claim(s) 7 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Xie (WO 2020088696A1), and Zhang “BIER Penultimate Hop Popping”, further in view of Goud (US pg. no. 20200120013).
Regarding claim 7. The combination discloses a method according to claim 6.
The combination does not explicitly disclose:
further discloses wherein advertising, by the first routing device, the identifier of the first host between the routing devices in the BIER domain further comprises: generating, by the first routing device, a routing protocol packet, wherein the routing protocol packet comprises the identifier of the first host, and the routing protocol packet is a border gateway protocol (BGP) packet; and advertising, by the first routing device, the routing protocol packet between the routing devices in the BIER domain;
However, in the same field of endeavor, Goud discloses further discloses wherein advertising, by the first routing device, the identifier of the first host between the routing devices in the BIER domain further comprises: generating, by the first routing device, a routing protocol packet, wherein the routing protocol packet comprises the identifier of the first host, and the routing protocol packet is a border gateway protocol (BGP) packet; and advertising, by the first routing device, the routing protocol packet between the routing devices in the BIER domain ([0035] discloses each of routers 102 may flood the bit position to BFR-prefix mapping to each other within the BIER Domain. For example, each of routers 102 may use Border Gateway Protocol or Interior Gateway Protocol (IGP), such as Intermediate-System to Intermediate-System (IS-IS) protocol or Open Shortest Path First (OSPF) protocol, to advertise the bit position to BFR-prefix mapping and bit-string length).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of the combination with Goud. The modification would allow exchanging routing information among nodes in the domain to enable effective data forwarding and networking.
Regarding claim 12. The combination discloses apparatus according to claim 11.
All other limitations of claim 12 are similar with the limitations of claim 7. Claim 12 is rejected on the analysis of claim 7 above.
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 MESSERET F. GEBRE whose telephone number is (571)272-8272. The examiner can normally be reached 9:00 am-5:30PM.
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, Oscar Louie can be reached at 5712701684. 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.
/MESSERET F GEBRE/Primary Examiner, Art Unit 2445
