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 . Claims 1-20 are presented for examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Foreign Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. IN202341089495, filed on 12/28/2023.
Response to Arguments
Applicant's arguments with respect to claims above filed on 4/15/2026 have been considered but they are not persuasive. After further search and thorough examination of present application claims 1-20 remain rejected.
In the remarks, applicant argues in substance:
That- “Because (i) Immidi does not disclose encapsulating a multicast packet using a multicast address of a different multicast group configured in an underlying network, and (ii) the combination of Immidi and McCane does not teach forwarding the encapsulated packet based on such a second multicast group, the cited references do not teach the limitations of claim 1”
In response to applicants arguments – Immidi teaches VXLAN/Overlay-underlay multicast environment, the VTEP network device, receipt of multicast traffic, use of an underlay network, and RP-based multicast forwarding. Immidi expressly teaches that VXLAN uses encapsulation and VTEP and that multicast traffic may be communicated in a VXLAN using underlay network. Immidi further teaches that overlay network is implemented on an underlay network and that network devices include VTEP’s. Applicants arguments appear to be directed toward Immidi. However, the rejection is based on the combination of Immidi and McCane. McCane a relevant art in the same field of endeavor discloses that overlay routers forward overlay packets by embedding then in a native multicast datagrams and that overlay routers map overlay addresses onto native group addresses using a well-defined hash function. McCane further teaches that overlay routers hash an overlay group G to native group h(G) and sends packets for overlay group G to native group h(G).
Thus, McCane teaches applying a mapping rule to a first/overlay multicast group to determine a second/native multicast group configured in the underlying/native network. McCane also teaches transmitting packets for the overlay group using computed native multicast group h(G). Therefore the combination teaches encapsulating or embedding overlay multicast traffic for a first multicast group in a packet/datagram addressed to a different native multicast group in the underlying network.
Applicant also argues that Immidi forwards multicast traffic in the underlay without encapsulation. This is not persuasive because Immidi is not relied upon for rule-based overlay-to-underlay multicast group mapping. Moreover, Immidi does not exclude encapsulation generally; it states that multicast traffic is not encapsulated with VXLAN packets in some embodiments, but may be encapsulated using other encapsulation protocols such as GRE with the destination IP address being the multicast address or group address.
Applicant further argues that combining Immidi with McCane would still result in forwarding based on the original group address. This is not consistent with McCane, because it expressly teaches that packets for overlay group G are sent to native group h(G), where h(G) is computed from G using hash function. Accordingly, the combination would not merely forward using the original multicast group address. It would use McCane’s mapped native multicast group h(G) for underlying multicast forwarding.
Accordingly, applicants arguments do not overcome the rejection, Immidi teaches the VXLAN overlay/underlay VTEP multicast environment and RP-based multicast forwarding while McCane teaches the amended mapping rule feature by computing a native multicast group from an overlay multicast group and forwarding packets for the overlay group using the computed native multicast group. The rejection under 35 USC 103 is respectfully maintained.
In conclusion, the applicant arguments are not persuasive and no patentable subject matter has been identified given the breath of the claims being recited herein. It is further concluded that distinguishing features in question have been addressed and therefore do not overcome the current grounds of rejection. Dependent claims stand rejected since the independent claims are rejected over the prescribed prior art and are obvious to an ordinary artisan. Finally no allowable subject matter has been discovered during this prosecution cycle.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Immidi (US pub, 2019/0207779 A1) in view of McCane (US pub, 2009/0207840 A1).
Referring to claims 1 & 9, Immidi teaches a method (¶[003], multicast traffic in a VXLAN including registering a network device as a VTEP, receiving multicast traffic and transmitting the multicast traffic using underlay network), comprising:
receiving, by a network device in an overlay network, a multicast packet destined to a first multicast group via an edge port of the network device (¶ [016], [020], multicast source 201 transmitting multicast traffic addressed to multicast group address…network device 230 receives the multicast traffic and adds a S,G route for the multicast source/group), wherein the network device operates as a tunnel endpoint in the overlay network, and wherein the edge port is coupled to a source of the first multicast group (see ¶ [014], [019], Claim 1, registering a network device as a virtual extensible (VXLAN) Tunnel endpoints (VTEP) in an overlay network……..receiving multicast traffic from the multicast source);
identifying, by the network device, a Rendezvous Point (RP) of the second multicast group (see ¶ [016], “the network architecture 200…include ….a rendezvous point (RP) 250”, i.e. Identifies a Rendezvous point used for multicast routing in the underlay network); and
forwarding, by the network device, the encapsulated multicast packet to the RP based on the multicast address of the second multicast group (see ¶ [027],”transmitting the multicast traffic to a rendezvous point” , i.e. Transmitting multicast traffic to an RP and maintaining (*,G) / S,G) routes) & Claim 2, ¶ [027], “transmitting the multicast traffic to a rendezvous point).
Immidi teaches underlay multicast groups for VXLAN multicast delivery but does not expressly teach applying, by the network device, a mapping rule to the first multicast group to determine a second multicast group configured in an underlying network of the overlay network
However, McCanne teaches applying, by the network device, a mapping rule to the first multicast group to determine a second multicast group configured in an underlying network of the overlay network (McCane: ¶ [030], [051], [152], [155], discloses two level addressing strategy where native multicast address are computed from overlay addresses using a hashing scheme. It further teaches that an overlay routers maps an overlay group into a native multicast group selected from an administratively scoped range and in the example overlay group A corresponds to native group “a” computed from “A”);
McCane teaches mapping, by the network device, the first multicast group to the second multicast group (see McCanne: ¶ [151]-[152], [155], McCane expressly states that overlay groups are mapped to native multicast groups to exploit native multicasting. It also teaches that for a multicast transit VIF the media Bridge/Overlay router decides which native group to join as a function of the overlay group);
encapsulating, by the network device, the multicast packet with a first encapsulation header comprising a destination address, which is a multicast address of the second multicast group (see ¶ [048], Fig. 6, transforming native multicast packets into overlay packets by adding an overlay header including the destination overlay group. Fig. 6 also shows header/address processing)
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Immidi’s VXLAN multicast system to include Overlay-to-Native multicast group mapping techniques as taught by McCanne in order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claims 2, 10 McCane teaches the method of claim 1,wherein the mapping rule comprises at least one of: a hash function producing an index for a range of predetermined multicast groups configured in the underlying network (see ¶ [078], Hash Overlay group to a native group, where the hash function is chosen to map the entire overlay address range into the native multicast address range……”;
sequential mapping to the range of predetermined multicast groups (see ¶ [081], Explains collisions and group pooling within a range of native multicast groups); and
a random mapping to the range of predetermined multicast groups (see McCane: ¶ [101], mapping is random, distributed mapping between multicast addresses and source domains, [141], [147],[151], [167]).
Referring to claim 3, 11, Immidi and McCane teaches the method of claim 1, wherein the first multicast group is based on a Protocol Independent Multicast (PIM) sparse-mode (SM) protocol (Immidi: [033], PIM-SM join behavior to RP(*,G) joins), and wherein the second multicast group is based on a bidirectional PIM (PIM-BIDIR) protocol (McCanne [077]-[079], Overlay routers forward traffic using native multicast shared trees, i.e. McCanne teaches RP-centric multi-cast trees and native multicast routing consistent with BIDIR/Shared-tree semantics even though protocol name BIDIR-PIM is not explicitly used, the RP-rooted shared tree model is disclosed).
It would have been obvious to utilize PIM-SM overlay joins as taught by Immidi to include RP=rooted shared trees / bidirectional multicast behavior in order to order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claim 4, 12, Immidi and McCane teaches the method of claim 1, wherein identifying the RP of the second multicast group comprises: selecting the RP of the second multicast group from a set of RPs of a range of predetermined multicast groups configured in the underlying network (see ¶ [016], Network architecture includes a Rendezvous Point (RP0 250 used for multicast routing); and
(McCanne: [078]-[080], Mapping overlay address ranges into native multicast address ranges, McCanne teaches mapping overlay groups into range of native multicast groups which inherently corresponds to multicast infrastructure (including RP selection per group range making RP selection from a configured set obvious when mapping groups into ranges).
Referring to claims 5, 13, McCane teaches the method of claim 1, wherein multicast traffic from the source of the first multicast group is forwarded via a multicast tree in the underlying network rooted at the RP of the second multicast group (see ¶ [078], “Hash function…maps the entire overlay address range into the native multicast address range”).
Referring to claims 6,14. Immidi teaches the method of claim 1, further comprising determining, by the network device, a third multicast group configured in the underlying network, wherein the third multicast group is for carrying multicast traffic in the underlying network to a multicast querier of a virtual local area network (VLAN) associated with the multicast packet (see ¶ [032], IGMP join on VXLAN VLAN; DR processes IGMP joins and manages multicast forwarding, i.e. Immidi discloses IGMP join processing on a VXLAN VLAN and designated-router behavior, establishing VLAN association, Multicast Querier (IGMP Context), multicast traffic distribution to queriers).
Referring to claims 7,15. Immidi teaches the method of claim 6, further comprising:
encapsulating, by the network device, a copy of the multicast packet with a second encapsulation header, wherein a destination address of the second encapsulation header comprises a second multicast address of the third multicast group (¶ [037] Immidi disclose multicast traffic replication and forwarding to multiple receivers via the underlay “multicast traffic forwarded using shared trees to multiple receivers);
identifying, by the network device, a second RP of the third multicast group (replication of multicast packets to multiple underlay multicast destinations is inherent in shared-tree multicast forwarding); and forwarding, by the network device, the encapsulated copy of the multicast packet to the second RP based on the second multicast address (see ¶ [037], Mutlicast traffic forwarded using shared trees to multiple receivers, ).
Referring to claim 8,16. The method of claim 6, wherein the third multicast group is associated with a respective multicast group sending traffic over the VLAN (see ¶ [032], “IGMP join/request/message on the VXLAN VLAN”).
Referring to claim 17, Immidi teaches a method (¶[003], [051]-[054] VTEP for multicast traffic and join Messaging) comprising:
receiving, by a network device in an overlay network, a first join request from a client device requesting multicast traffic of a first multicast group via an edge port of the network device, wherein the network device operates as a tunnel endpoint in the overlay network (see ¶ [032], The multicast receiver 304 …may send an IGMP join request/message on the VXLAN VLAN”, i.e. Immidi discloses receiving IGMP join requests from multicast receiver in a VXLAN environment);
generating, by the network device, a second join request requesting multicast traffic of the second multicast group (see ¶ [033], “the network device may send a (*,G) join request/message to the rendezvous point” , i.e. Immidi discloses generating and forwarding (*,G) join messages toward the RP)
identifying, by the network device, a Rendezvous Point (RP) of the second multicast group (see ¶ [016], “the network architecture 200…include ….a rendezvous point (RP) 250”, i.e. Identifies a Rendezvous point used for multicast routing in the underlay network); and
forwarding, by the network device, the second join request to the RP based on a multicast address of the second multicast group (see ¶ [033], “the network device…may forward the (*,G) join to the rendezvous point 250” i.e. Immidi teaches forwarding join requests to the RP to establish multicast state)
Immidi teaches underlay multicast groups for VXLAN multicast delivery but does not expressly teach applying by the network device a mapping rule to the first multicast group to determine a second multicast group configured in an underlying network of the overlay network.
However, McCanne teaches applying by the network device a mapping rule to the first multicast group to determine a second multicast group configured in an underlying network of the overlay network (McCane: ¶ [030], [051], [152], [155], discloses two level addressing strategy where native multicast address are computed from overlay addresses using a hashing scheme. It further teaches that an overlay routers maps an overlay group into a native multicast group selected from an administratively scoped range and in the example overlay group A corresponds to native group “a” computed from “A”);
McCane teaches mapping, by the network device, the first multicast group to the second multicast group (see McCanne: ¶ [151]-[152], [155], McCane expressly states that overlay groups are mapped to native multicast groups to exploit native multicasting. It also teaches that for a multicast transit VIF the media Bridge/Overlay router decides which native group to join as a function of the overlay group);
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Immidi’s VXLAN multicast system to include Overlay-to-Native multicast group mapping techniques as taught by McCanne in order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claim 18, Immidi teaches the method of claim 17, further comprising:
receiving, by the network device, a multicast packet encapsulated by an encapsulation header comprising a destination address, which is the multicast address of the second multicast group, wherein the multicast packet belongs to the first multicast group ([033], Receiving multicast traffic via the underlay after sending (*.G) joins, i.e. distinction between outer (underlay) and inner (overlay) group me membership is inherent in VXLAN encapsulation); and
forwarding, by the network device, the multicast packet via the edge port based on the first join request (see ¶ [037], Immidi teaches forwarding multicast traffic to receivers based on routing state).
Referring to claim 19, McCanne teaches the method of claim 17, wherein the mapping rule comprises at least one a hash function producing an index for a range of predetermined multicast groups configured in the underlying network ([078], Hash mapping of overlay group to native group, i.e. McCanne explicitly teaches hash mapping and discusses address collision and group pooling); a sequential mapping to the range of predetermined multicast groups; and a random mapping to the predetermined range of multicast groups (sequential or random selection from a group range in an obvious design alternative to hashing once group poolin is taught~Obvious over McCanne ).
Referring to claim 20, Immidi and McCanne teaches the method of claim 17, wherein the first multicast group is based on a Protocol Independent Multicast (PIM) sparse-mode (SM) protocol, and wherein the second multicast group is based on a bidirectional PIM (PIM-BIDIR) protocol (Immidi ¶ [033], PIM-SM join messages to RP & McCanne ¶ [077]-[079], RP-rooted shared trees / bidirectional multicast behavior).
Conclusion
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.
The examiner also requests, when responding to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application. Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFTAB N. KHAN whose telephone number is (571)270-5172. The examiner can normally be reached on Monday-Friday 8AM-5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached on 571-272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AFTAB N. KHAN/
Primary Examiner, Art Unit 2454
Prosecution Insights