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 Remarks/Arguments
This Office Action is in response to the communications for the present US application number 18/790,809 last filed on April 14th, 2026.
Claims 1-3, 5-8, 10-12, 14, 15, 17, and 18 were amended.
Claims 1-20 remain pending and have been examined, directed to METHOD AND SYSTEM FOR EFFICIENT TRAFFIC FORWARDING FROM A PRIVATE CLOUD.
Upon further review of the latest claim amendments along with the applicant’s representative’s response, the examiner reviewed and updated the search and applied a new combination of references’ teachings and respectfully remain unpersuaded at this time.
More specifically, the applicant’s representative primarily argued about the amended claim language related to a virtual MAC address that is applied and associated with the host system, also acting as a logical router, while running various VMs.
In response, after an updated search, the Examiner has reviewed and applied an updated combination of references, wherein the secondary reference would more clearly establish how a vMAC address can be associated with the VM(s) and the host system(s), which afterwards can still remain flexible enough such that the addressing information can be easily updated and changed if needed, such as to a physical MAC address, depending on the configuration and the established routing rules. For at least these reasons, the Examiner remains unpersuaded at this time.
The other independent claim 10 and 18 were similarly amended and argued following claim 1 and thus were similarly rejected under the same rationale.
The remaining dependent claims were not specifically argued at this time.
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
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 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2013/0125230 A1 to Koponen et al. (referred to hereafter as “Koponen”) in view of U.S. Patent Publication No. US 2023/0013269 A1 to Kale et al. (referred to hereafter as “Kale”).
As to claim 1, Koponen further discloses a method comprising:
identifying, by a host of a private cloud, a first packet from a virtual machine (VM) running on the host, wherein the private cloud includes one or more hosts operating as a logical router for sending packets to an external router outside of the private cloud, and wherein a respective host runs a set of VMs (Koponen discloses of an overall system that can encompass multiple host systems, where each host system can operate as a logical router and run multiple virtual machines, with different variations and examples (e.g., Figs. 1-6, and 9-11). There are forwarding tables and/or firewall configurations with entries that would translate an internal logical (IP or MAC) address from a VM to the physical egress port of the host/logical router as the data packet can then reach outside the cloud/network, e.g., Koponen: ¶¶ 50-51, 55-59, 62, and 134-135);… and
determining the local interface as an egress interface for forwarding the first packet to the external router (Koponen discloses in various examples that when an egressing packet from a VM can be forwarded and reach the firewall or the next higher level or external router and get routed, based on the entries in place, such as the host system’s physical port information, e.g., Koponen: ¶¶ 34 and 55-59 and Figs. 9-11).
Koponen does not fully expressly disclose of
determining that a source media access control (MAC) address of the first packet from the VM includes a virtual MAC address allocated to the logical router, wherein a respective host is associated with the virtual MAC address (Koponen does not expressly disclose about associating a virtual MAC address to the host and also treating that as the source virtual MAC address of a packet coming from a VM from within the host.
Kale more expressly discloses of what Koponen lacks, wherein the all of the VMs can be associated with a virtual port which contains the MAC address information, and there is a managed routing element or logical interface (L-I/F) that ties or associates the vPort or vMAC address of a VM to the (one or more) host system(s) as well, via this logical interface, within virtualization software 505 (e.g., Kale: ¶¶ 50, 55, 58, and Fig. 5, 520 and 530 and 505));
replacing, based on an address replacement rule programmed at the host, the virtual MAC address with a physical MAC address of a local physical interface of the host as the source MAC address of the first packet (Once again, Kale more expressly discloses of the virtual MAC address aspect that ties together the vMAC address of the VMs and the host system (e.g., Kale: ¶¶ 50, 55, and 58). The host system can still be identified via the physical addressing information (e.g., Kale: ¶ 49) and such information can be easily incorporated within Koponen’s teachings of the routing tables and firewall configuration entries, which would map the virtual/logical vMAC address to the physical egress port of the physical NIC, e.g., Koponen: ¶¶ 34 and 55-59);…
Based upon Kale’s teachings, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Kale’s teachings with the vMAC addressing within Koponen’s overall system and teachings, as those associations between VMs and host systems can be easily recorded and updated within the routing tables, resulting in a more flexible and robust system.
As to claim 2, Koponen further discloses the method of claim 1, wherein the local physical interface of the host is coupled to the external router and is associated with the virtual MAC address (The physical ports of the host system (as the destination address info) can be connected to the external network via physical network interface, and they are associated with the source virtual/logical address from where the packet originated within the VM(s), e.g., Koponen: ¶¶ 55-57).
As to claim 3, Koponen further discloses the method of claim 1, wherein the address replacement rule for replacing the virtual MAC address is programmed on a respective host of the private cloud (Koponen discloses that the policy and routing rules are user specified and programmed at the host. In one embodiment, it is explained that the rules can be within a user space vs a kernel space, on the host. Throughout all of the various example and configurations provided, it is further explained that the policies and routing rules were set up at each host, and usually along the interface, separated by firewalls or other logical partitions, e.g., Koponen: ¶¶ 32-34, 68, 95, and 122-124, and Figs. 1-6 and 9-11).
While Koponen does not expressly disclose about the vMAC address associated with the host systems, following claim 1, Kale more expressly discloses of associating all the VMs with the host systems using a vMAC or vPort addressing information (e.g., Kale: ¶¶ 50, 55, and 58), which could then be easily incorporated within Koponen’s routing and configurations tables.
See the previously stated reasons for combining and incorporating Kale’s teachings within Koponen’s overall system and teachings.
As to claim 4, Koponen further discloses the method of claim 1, further comprising: generating, at a local instance of the logical router on the host, a layer-2 header for the first packet (Koponen discloses in an embodiment about layer 2 information that needs to be configured within ACL entries, e.g., Koponen: ¶ 129 and Fig. 9); and
setting the virtual MAC address as the source MAC address in the layer-2 header (Following from claim 1’s interpretations, it’s already understood that the packet is originating from a VM within a host system, so the source is a virtual MAC address, and the destination is a physical port on the host and/or a switch or firewall, and all of this processing information is included within the packet header, e.g., Koponen: ¶¶ 56-57, 62, and 129-130).
As to claim 5, Koponen further discloses the method of claim 4, wherein the address replacement rule for replacing the virtual MAC address is programmed outside of the local instance of the logical router at the host (Similar to claim 3, the rules can be programmed and implemented by a user, at the host system that contains the VMs, e.g., Koponen: ¶¶ 32-34, 68, 95, and 122-124).
While Koponen does not expressly disclose about the vMAC address associated with the host systems, following claim 1, Kale more expressly discloses of associating all the VMs with the host systems using a vMAC or vPort addressing information (e.g., Kale: ¶¶ 50, 55, and 58), which could then be easily incorporated within Koponen’s routing and configurations tables.
See the previously stated reasons for combining and incorporating Kale’s teachings within Koponen’s overall system and teachings.
As to claim 6, Koponen further discloses the method of claim 1, further comprising:
receiving, by the host, a flow rule from a network controller provisioning the private cloud, wherein a respective flow rule indicates how traffic is to be processed at the host (Following claim 1’s steps and interpretations, the policy and routing rules set for the egressing packet would establish how the packet travels from a VM to the physical port interface on the host system, and Koponen discloses of at least two variations, with respect to Figs. 9 and 10, e.g., Koponen: ¶¶ 32-34, 56-57, 62, and 129-130 and Figs. 9-10); and
determining the local physical interface as an egress interface for the packet based on the flow rule (the local interface at the host, would be interpreted as the network interface to an external or separate network, such as to another host system, e.g., Koponen: ¶¶ 32-34, 56-57, 62, and 129-130 and Figs. 9-10).
As to claim 7, Koponen further discloses the method of claim 1, further comprising:
receiving, at the local physical interface from the external router, a second packet based on a direct route for an IP address of the VM (Following claim 1, supposing an additional or subsequent packet is received from an external source or external interfacing router, Koponen discloses of various embodiments that involve checking the target destination IP addressing information directed towards a destination VM, e.g., Koponen: ¶¶ 127-130 and 142-143 and Figs. 9-11);
replacing, based on a reverse address replacement rule programmed at the host, the physical MAC address of the local physical interface with the virtual MAC address as a destination MAC address of the second packet (Koponen discloses in some embodiments that firewall rules can translate the configuration data when needed, and by checking the packet’s destination addressing, such as to a target VM, any intermediary transitions, like tunneling would be handled by the system, e.g., Koponen: ¶¶ 73, 122, 127-130 and 142-143 and Figs. 8-11); and
forwarding the second packet to the logical router for providing the second packet to the VM (Following the above, the packet would be forwarded to the correct VM destination, ¶¶ 73, 122, 127-130 and 142-143 and Figs. 8-11).
As to claim 8, Koponen further discloses the method of claim 1, further comprising storing, by the host, information indicating a second host that hosts a second VM (e.g., Koponen: Figs. 1-3 and 9-11).
As to claim 9, Koponen further discloses the method of claim 1, further comprising:
receiving, by the host, a third packet from the external router (See below);
determining that the third packet is destined to second VM (See below); and
encapsulating the third packet with a tunnel encapsulation header associated with a tunnel between the host and the second host (For these three limitations directed to the same concept, and following claim 1, supposing an additional or subsequent packet is received from an external source, Koponen discloses similarly in at least one variation that a packet can be (received) and start at a first VM, and then be routed and tunneled and sent to a different VM on a separate host system, e.g., Koponen: ¶ 134, Fig. 9, host 925 to host 930).
As to claim 10, see the similar corresponding rejection of claim 1 as Koponen also further discloses of a system that can implement and carry out the steps (e.g., Koponen: ¶¶ 151 and 160-161).
As to claim 11, see the similar corresponding rejection of claim 2.
As to claim 12, see the similar corresponding rejection of claim 3.
As to claim 13, see the similar corresponding rejection of claim 4.
As to claim 14, see the similar corresponding rejection of claim 5.
As to claim 15, see the similar corresponding rejection of claim 6.
As to claim 16, see the similar corresponding rejection of claim 7.
As to claim 17, see the similar corresponding rejections of claims 8 and 9.
As to claim 18, Koponen further discloses a method comprising:
Identifying, by a router, a packet destined to a virtual machine (VM) reachable via a logical device, where the logical device corresponds to a private cloud comprising one or more hosts running a set of VMs (Similar to claim 1, a host system or any router/switch within the host can determine/identify the packet’s destination based upon it’s packet information, which includes the physical and the virtual/logical address information, e.g., Koponen: ¶¶ 55-59, 62, and 134-135);
looking up, in a forwarding data structure, a destination Internet Protocol (IP) address of the packet to a route programed on the router (The routing information can be looked up within the packet’s header or within stored table entries, which would include source and destination IP addressing information, e.g., Koponen: ¶¶ 34, 56-56, 62, 68, and 129-130);
determining, from the route, a target IP address associated with the VM (This can be referring to or interpreted as applicable towards incoming or outgoing packets, directed to a VM, which Koponen covers both examples, such as with an egressing packet from a first VM to a second VM, e.g., Koponen: ¶¶ 34, 56-56, 62, 68, 127-130, and 142-143 and Figs. 9-11);
determining a local physical interface of the router as an egress interface for forwarding the first packet to an external router outside of the private cloud (Koponen discloses of multiple embodiments wherein an egress packet, from a VM, can be forwarded and reach the firewall or the next higher level or external router and based upon the destination’s physical port information, e.g., Koponen: ¶¶ 34 and 55-59 and Figs. 9-11).
As to claim 19, Koponen further discloses the method of claim 18, wherein the route includes a direct route for the destination IP address, and wherein the target IP address is allocated to a host running a VM associated with the destination IP address (Following claim 18, Koponen discloses of at least an embodiment with a packet directed to a destination at a different host with a separate VM, e.g., Koponen: ¶¶ 127-130 and 142-143 and Figs. 9-11).
As to claim 20, Koponen further discloses the method of claim 18, wherein the route is for a subnet associated with the destination IP address, and wherein the target IP address is allocated to a host storing information location information of a VM associated with the destination IP address (Following claims 18 and 19, the packet’s routing information would have the target destination IP addressing information, e.g., Koponen: ¶¶ 127-130 and 142-143 and Figs. 9-11).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Xiang Yu whose telephone number is (571)270-5695. The examiner can normally be reached M-F 9:30-3:00 (PST/PDT).
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, Emmanuel Moise can be reached at (571)272-3865. 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.
/X.Y./Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455
Prosecution Insights