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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 8-10, and 16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tripathi et al. (Patent No: US 2016/0087885 A1), hereinafter, Tripathi.
Regarding Claim 1, Tripathi teaches,
A method of a computer network, the method comprising: -Paragraph [0213] ([0213] recites, “The apparatus may be specially constructed for the required purpose, such as a special purpose computer. When defined as a special purpose computer, the computer can also perform other processing, program execution or routines that are not part of the special purpose, while still being capable of operating for the special purpose. Alternatively, the operations may be processed by a general-purpose computer selectively activated or configured by one or more computer programs stored in the computer memory, cache, or obtained over a network. When data is obtained over a network the data may be processed by other computers on the network, e.g., a cloud of computing resources.”)
receiving, from a first switch at a second switch, an encapsulated packet comprising information that includes a route to the second switch and indicates a first node of the second switch is included in a multicast operation; -Fig. 6, 7A, 7B; Paragraph [0180-0181, 0069, 0051] ([0180-0181] recites, “From operation 778, the method flows to operation 780 for creating an encapsulation flow on the first switch to encapsulate packets from the first node to the second node over the tunnel so future layer 2 packets from the first node to the second node get encapsulated in chip hardware and get decapsulated on the second switch in hardware. After the encapsulation flow is created, the packet is sent in operation 782 from the network switch to the second switch over the tunnel using the encapsulation and decapsulation. The tunnel is created without processing by the first node or the second node, i.e., the first node and the second node do not have to do any work to establish or use the tunnel, and the tunnel is, in one embodiment, transparent to the first node and the second. Additionally, the second switch also create an encapsulation flow (operation 784), where packets from the second node to the first node are encapsulated over the tunnel. When the first switch receives the encapsulated packet from the second switch, the first switch decapsulates the packet before delivering it to the first node.”[0069] recites, “In one embodiment, the fabric-connect request includes one or more of the following parameters: source switch identification (switch 1), remote or destination switch identification (switch 2), the name of the source-fabric (fab1), the name of the remote-fabric (fab2), tunnel name (tunnel1), the IP address of the source switch (not shown), the IP address of the remote switch (50.2.2.2), the router IP address (e.g., next-hop-ip 100.1.1.1), encapsulation protocol (e.g., VXLAN), or encryption key.”[0051] recites, “In one embodiment, ndOS switches periodically send multicast messages on a well-known address, the multicast messages including the senders' own IP address and a unique switch identifier (ID). “)
obtaining a source packet from the encapsulated packet based on de-encapsulating the encapsulated packet; -Paragraph [0181] )[0181] recites, “the method flows to operation 780 for creating an encapsulation flow on the first switch to encapsulate packets from the first node to the second node over the tunnel so future layer 2 packets from the first node to the second node get encapsulated in chip hardware and get decapsulated on the second switch in hardware…”)
and transmitting a first copy of the source packet to the first node of the second switch based on copying the source packet and based on determining the information indicates the first node of the second switch is included in the multicast operation -Paragraph [0197, 0171-0173] ([0197] recites, … send a copy of the packet to a specific external port,…” [0172-0173] recites, “…Since VM1 now has connection information for VM2, VM1 now sends a packet 734 to VM2, which is sent via switch1. Switch1 then determines 736 that the packet has to be sent through the tunnel to switch2 based on the MAC address information (as described above with reference to FIG. 5B) ..… Future unicast and multicast packets sent from switch1 to VM2 will be encapsulated over the tunnel and sent.”)
Regarding Claim 8, Tripathi teaches the limitations of Claim 1.
Tripathi further teaches,
The method of claim 1, wherein: the encapsulated packet comprises the source packet that is encapsulated by the first switch, and a header of the encapsulated packet includes the information for one or more switches, including the second switch. -Fig. 4B, Paragraph [0101-0102] ([0101-0102] recites, “Broadcasts, and multicasts are also encapsulated in to vlxan. Virtual Tunnel End Points (VTEPs) are the end points that do the encapsulation and decapsulation (e.g., switch1 and switch2). VXLAN packets include an outer MAC header, and outer IP header, a UDP header, a VXLAN header and the original packet that is to be sent through the tunnel. When VM1 sends a packet 434 to VM2, switch1 detects that the remote address is for VM2 which is logically connected to switch2. The tunneling engine module 440 in switch1 then encapsulates the packet into a VXLAN packet 334, which has the outer destination IP address as 15.2.2.2 (switch2 IP address), and outer source IP of switch1, and inner destination MAC address of VM2, a source MAC address of VM1, and inner destination IP of VM2, and an inner's source IP of VM1. When switch 2 receives the packet, the tunneling engine module in switch2 decapsulates the packet and delivers the original payload to VM2 through server2.”)
Regarding Claim 9, Tripathi teaches the limitations of Claim 1.
Tripathi further teaches,
The method of claim 1, wherein de-encapsulating the encapsulated packet includes removing the information from the encapsulated packet. -Paragraph [0102] ([0102] recites, “When switch 2 receives the packet, the tunneling engine module in switch2 decapsulates the packet and delivers the original payload to VM2 through server2.” It is well known that de-encapsulation process is to retrieve the payload portion from the encapsulated packet by removing the information in the header.)
Regarding Claim 10, Tripathi teaches the limitations of Claim 1.
Tripathi further teaches,
The method of claim 1, wherein: the computer network comprises a high-performance computing (HPC) network protocol based on at least one of peripheral component interconnect express (PCIe), InfiniBand, Ethernet or Omni-Path, and the source packet comprises a format based on the HPC network protocol. -Fig. 9; Paragraph [0189, 0212, 0144] ([0189] recites, “FIG. 9 shows a network device in accordance with one or more embodiments. In one or more embodiments, the network device 104 includes external ports 176, internal ports 174, a switch fabric classifier 178, one or more network processing units (NPUs) 172A-172B, also referred to herein as packet processors, a control processor 162, persistent memory 164, a Peripheral Component Interconnect Express (PCIe) switch 170, switch fabric 180 and volatile memory 166. The PCIe connection may be implemented over a copper connection, or an optical media connection, or any other type of media that supports PCIExpress.”[0144] recites, “…In one embodiment, all future unicast packets to the destination will hit the encapsulation rule and reach the other side (this happens in hardware) but broadcast and multicast has to be processed in software and are sent to remote switches over fabric protocol using TCP/IP.”)
Claim 16 is the apparatus claim corresponding to the method claim 1. The applicant’s attention is directed towards claim 1 above which is rejected. Claim 16 is rejected under the same rational as claim 1.
Tripathi further teaches,
A non-transitory computer-readable medium storing code that comprises instructions executable by a processor of a second switch -Paragraph [0214] ([0214] recites, “One or more embodiments can also be fabricated as computer readable code on a non-transitory computer readable storage medium. The non-transitory computer readable storage medium is any non-transitory data storage device that can store data, which can be thereafter be read by a computer system. Examples of the non-transitory computer readable storage medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices. The non-transitory computer readable storage medium can include computer readable storage medium distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.”)
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 2, 6, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi
in view of Addanki et al. (Patent No: US 2014/0362854 A1), hereinafter, Addanki.
Regarding Claim 2, Tripathi teaches the limitations of claim 1.
Although implicit, Tripathi does not explicitly mention,
The method of claim 1, further comprising transmitting a second copy of the source packet to a second node of the second switch based on copying the source packet and based on determining the second node of the second switch is included in the multicast operation.
However, in an analogous invention, Addanki teaches,
The method of claim 1, further comprising transmitting a second copy of the source packet to a second node of the second switch based on copying the source packet and based on determining the second node of the second switch is included in the multicast operation. -Claim 1 (Recites, “an inter-switch multicast module adapted to identify for a first replication of a multicast packet an egress inter-switch port in a multicast tree rooted at the switch, wherein the multicast tree is identified by an identifier of the switch; and an edge multicast module adapted to identify an egress edge port for a second replication of the multicast packet based on a multicast group identifier, wherein the multicast group identifier is local within the switch.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “transmitting a second copy of the source packet to a second node of the second switch based on copying the source packet and based on determining the second node of the second switch is included in the multicast operation” of Addanki. One of ordinary skill in the art would have been motivated to make this modification in order to improve the scalability of a switch system [0007].
Regarding Claim 6, Tripathi teaches the limitations of claim 1.
Although implicit, Tripathi does not explicitly mention,
The method of claim 1, further comprising omitting transmission of a copy of the source packet to a third node of the second switch based on the information excluding the third node.
However, in an analogous invention, Addanki teaches,
The method of claim 1, further comprising omitting transmission of a copy of the source packet to a third node of the second switch based on the information excluding the third node. -Fig. 4; Paragraph [0072] ([0072] recites, “The switch obtains an edge port bitmap from an MGID table based on the obtained MGID (operation 408). The switch can obtain the edge port bitmap from an entry in the MGID table comprising a mapping between the MGID and the edge port bitmap, or by using the MGID as an index of the MGID table. The switch identifies the edge ports corresponding to the obtained edge port bitmap (operation 410), as described in conjunction with FIG. 3A, and replicates and forwards the packet via the identified edge ports (operation 412). If the switch has multiple MSID table instances, the switch selects an MSID table instance based on the layer-2 and/or layer-3 forwarding decision (operation 414), as described in conjunction with FIG. 3C.” As explained above replication and forwarding of packets happens only with the ports/nodes identified in the port bitmap. If the third node is not identified in the bitmap, replicated packet will not be transmitted to the third node.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “omitting transmission of a copy of the source packet to a third node of the second switch based on the information excluding the third node.” of Addanki. One of ordinary skill in the art would have been motivated to make this modification in order to improve the scalability of a switch system [0007].
Claim 17 is the apparatus claim corresponding to the method claim 2. The applicant’s attention is directed towards claim 2 above which is rejected. Claim 17 is rejected under the same rational as claim 2.
Claims 3-5, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi
in view of Addanki, and further in view of Seth et al. (Patent No: US 2020/0313915 A1), hereinafter, Seth.
Regarding Claim 3, Tripathi and Addanki teach the limitations of claim 2.
Although implicit, Tripathi and Addanki do not explicitly teach,
The method of claim 2, further comprising: receiving, from the first node, a first node acknowledgement indicating the first node received the first copy of the source packet; and receiving, from the second node, a second node acknowledgement indicating the first node received the first copy of the source packet.
However, in an analogous invention, Seth teaches,
The method of claim 2, further comprising: receiving, from the first node, a first node acknowledgement indicating the first node received the first copy of the source packet; and receiving, from the second node, a second node acknowledgement indicating the first node received the first copy of the source packet. -Paragraph [0009-0010] ([0009-0010] recites, “The techniques may also include routers sending acknowledgements, to upstream routers of the multicast distribution tree, to indicate that multicast packets have been received…..the non-last hop routers continue to relay the data over the downstream TCP buffer. If the non-last hop router receives an acknowledgement message (directly or indirectly) from a last hop router indicating in-order receipt of a multicast packet over the multicast path, the non-last hop router may discard any TCP packets up to the acknowledgement-inducing sequence number, without forwarding those particular TCP packets”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “receiving, from the first node, a first node acknowledgement indicating the first node received the first copy of the source packet; and receiving, from the second node, a second node acknowledgement indicating the first node received the first copy of the source packet.” of Seth. One of ordinary skill in the art would have been motivated to make this modification in order to improve reliability in delivery of UDP multicast datagrams over multicast flows [0052].
Claims 4 and 5 are very similar to Claim 3 and are related to acknowledgement of received packets from switches. It is easily understandable to an ordinary person with the skill in the art that feedback/acknowledgement is sent for each received packets at the switch/node. The applicant’s attention is directed towards Claim 3 above which is rejected. Claims 4 and 5 are rejected under the same rational as claim 4.
Claim 18 is the apparatus claim corresponding to the method claim 3. The applicant’s attention is directed towards claim 3 above which is rejected. Claim 18 is rejected under the same rational as claim 3.
Claims 19-20 are the apparatus claim corresponding to the method claims 4-5. The applicant’s attention is directed towards claims 4-5 above which is rejected. Claims 19-20 are rejected under the same rational as claims 4-5.
Claims 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi
in view of Seth.
Regarding Claim 11, Tripathi teaches,
A method of a computer network, the method comprising: obtaining, at a first switch, a source packet from a source node of the first switch; -Fig. 7A (734); Paragraph [0172] ([0172] recites, “Since VM1 now has connection information for VM2, VM1 now sends a packet 734 to VM2, which is sent via switch1”)
generating an encapsulated packet based on information that includes a route to a second switch and based on the information indicating a first node of the second switch are included in a multicast operation; -Fig. 6, 7A, 7B; Paragraph [0180-0181, 0069, 0051] ([0180-0181] recites, “From operation 778, the method flows to operation 780 for creating an encapsulation flow on the first switch to encapsulate packets from the first node to the second node over the tunnel so future layer 2 packets from the first node to the second node get encapsulated in chip hardware and get decapsulated on the second switch in hardware. After the encapsulation flow is created, the packet is sent in operation 782 from the network switch to the second switch over the tunnel using the encapsulation and decapsulation. The tunnel is created without processing by the first node or the second node, i.e., the first node and the second node do not have to do any work to establish or use the tunnel, and the tunnel is, in one embodiment, transparent to the first node and the second. Additionally, the second switch also create an encapsulation flow (operation 784), where packets from the second node to the first node are encapsulated over the tunnel. When the first switch receives the encapsulated packet from the second switch, the first switch decapsulates the packet before delivering it to the first node.”[0069] recites, “In one embodiment, the fabric-connect request includes one or more of the following parameters: source switch identification (switch 1), remote or destination switch identification (switch 2), the name of the source-fabric (fab1), the name of the remote-fabric (fab2), tunnel name (tunnel1), the IP address of the source switch (not shown), the IP address of the remote switch (50.2.2.2), the router IP address (e.g., next-hop-ip 100.1.1.1), encapsulation protocol (e.g., VXLAN), or encryption key.”[0051] recites, “In one embodiment, ndOS switches periodically send multicast messages on a well-known address, the multicast messages including the senders' own IP address and a unique switch identifier (ID). “)
transmitting a first copy of the encapsulated packet to the second switch based on determining the information indicates the first node of the second switch are included in the multicast operation; -Fig. 7B (782); Paragraph [0180] ([0180] recites, “…the packet is sent in operation 782 from the network switch to the second switch over the tunnel using the encapsulation and decapsulation”)
Although implicit, Tripathi does not explicitly mention,
and receiving, from the second switch, a switch acknowledgement indicating the second switch received the encapsulated packet.
However, in an analogous invention, Seth teaches,
and receiving, from the second switch, a switch acknowledgement indicating the second switch received the encapsulated packet. -Paragraph [0009-0010] ([0009] recites, “The techniques may also include routers sending acknowledgements, to upstream routers of the multicast distribution tree, to indicate that multicast packets have been received…”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “receiving, from the second switch, a switch acknowledgement indicating the second switch received the encapsulated packet” of Seth. One of ordinary skill in the art would have been motivated to make this modification in order to improve reliability in delivery of UDP multicast datagrams over multicast flows [0052].
Regarding Claim 12, Tripathi and Seth teach the limitations of Claim 11.
Although implicit, Tripathi does not explicitly teach,
The method of claim 11, further comprising: identifying a failed link to a third switch; and routing a second copy of the encapsulated packet to the third switch over an alternative path based on network topology information of the computer network.
However, in an analogous invention, Seth teaches,
The method of claim 11, further comprising: identifying a failed link to a third switch; and routing a second copy of the encapsulated packet to the third switch over an alternative path based on network topology information of the computer network. -Paragraph [0003] ([0003] recites, “…Many conventional computer networks, including the Internet, are designed to dynamically reroute data packets in the event an individual link fails. Upon failure of a link, the routers transmit new connectivity information to neighboring devices, allowing each device to update its local routing table. Links can fail for any number of reasons, such as failure of the physical infrastructure between the devices, or failure of the devices”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “identifying a failed link to a third switch; and routing a second copy of the encapsulated packet to the third switch over an alternative path based on network topology information of the computer network” of Seth. One of ordinary skill in the art would have been motivated to make this modification in order to improve reliability in delivery of UDP multicast datagrams over multicast flows [0052].
Regarding Claim 13, Tripathi and Seth teach the limitations of Claim 11.
Tripathi further teaches,
The method of claim 11, wherein generating the encapsulated packet comprises adding the information to a header of the encapsulated packet. -Paragraph [0101] ([0101] recites, “…The encapsulation adds about 50 bytes to the header. Virtual Network IDs (VNIDs) are vlxan segment identifiers. Broadcasts, and multicasts are also encapsulated in to vlxan. Virtual Tunnel End Points (VTEPs) are the end points that do the encapsulation and decapsulation (e.g., switch1 and switch2). VXLAN packets include an outer MAC header, and outer IP header, a UDP header, a VXLAN header and the original packet that is to be sent through the tunnel.”)
Regarding Claim 14, Tripathi and Seth teach the limitations of Claim 11.
Although implicit, Tripathi does not explicitly teach,
The method of claim 11, wherein the switch acknowledgement indicates the first node of the second switch received a first copy of the source packet and a second node of the second switch received a second copy of the source packet.
However, in an analogous invention Seth teaches,
The method of claim 11, wherein the switch acknowledgement indicates the first node of the second switch received a first copy of the source packet and a second node of the second switch received a second copy of the source packet. -Paragraph [0009-0010] ([0009] recites, “The techniques may also include routers sending acknowledgements, to upstream routers of the multicast distribution tree, to indicate that multicast packets have been received…” It is easily conceivable to an ordinary person with the skill in the art that in acknowledgement-based protocol response (acknowledgement) is sent back for received packets. )
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the “CONNECTING FABRICS VIA SWITCH-TO-SWITCH TUNNELING TRANSPARENT TO NETWORK SERVERS” proposed by Tripathi to include the concept of “the switch acknowledgement indicates the first node of the second switch received a first copy of the source packet and a second node of the second switch received a second copy of the source packet.” of Seth. One of ordinary skill in the art would have been motivated to make this modification in order to improve reliability in delivery of UDP multicast datagrams over multicast flows [0052].
Claim 15 is essentially the same as Claim 10, except Claim 15 is dependent Claim of Claim 11, whereas Claim 10 is dependent of Claim 1. The applicant’s attention is directed towards Claim 10 above which is rejected. Claim 15 is rejected under the same rational as claim 1o.
Allowable Subject Matter
Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AHMED SAIFUDDIN whose telephone number is (703)756-4581. The examiner can normally be reached Monday-Friday 8:30am-6: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, KHALED M KASSIM can be reached on 571-270-3770. 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.
/AHMED SAIFUDDIN/Examiner, Art Unit 2475
/ABDULLAHI AHMED/Examiner, Art Unit 2475
Prosecution Insights