Nicira, Inc.

Patent Trials and Appeals Board

Mar 18, 2022

2021001537 (P.T.A.B. Mar. 18, 2022)

UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 15/784,136 10/15/2017 Jun Xiao N104.01.C1 2540 109858 7590 03/18/2022 ADELI LLP P.O. Box 516 Pacific Palisades, CA 90272 EXAMINER PANT, RANJAN ART UNIT PAPER NUMBER 2458 NOTIFICATION DATE DELIVERY MODE 03/18/2022 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): ipadmin@vmware.com mail@adelillp.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte JUN XIAO ____________ Appeal 2021-001537 Application 15/784,1361 Technology Center 2400 _______________ Before ALLEN R. MacDONALD, JEAN R. HOMERE, and HUNG H. BUI, Administrative Patent Judges. BUI, Administrative Patent Judge. DECISION ON APPEAL Appellant seeks our review under 35 U.S.C. § 134(a) from the Examiner’s final rejection of claims 21-40, all of the pending claims. Appeal Br. 21-26. We have jurisdiction under 35 U.S.C. § 6(b). We affirm in part.2 1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42 (2012). According to Appellant, VMware, Inc., and Nicira Inc. is identified as the real party in interest. Appeal Br. 2. 2 We refer to Appellant’s Appeal Brief filed June 29, 2020 (“Appeal Br.”); Reply Brief filed December 28, 2020 (“Reply Br.”); Examiner’s Answer mailed October 26, 2020 (“Ans.”); Final Office Action mailed January 30, 2020 (“Final Act.”); and Specification filed October 15, 2017 (“Spec.”). Appeal 2021-001537 Application 15/784,136 2 STATEMENT OF THE CASE Cloud services are often assigned with public (or Internet routable) IP addresses, which can be accessed from clients either in or out of the cloud. The tenants’ clients inside the cloud are assigned with private IP addresses (i.e., IP addresses that are not routable for traversing the Internet) reserved for private use, so that devices outside of the local network cannot directly connect to devices with private IP addresses without a network address translation (NAT) to translate private IP addresses into public (Internet routable) IP addresses. Spec. ¶ 2. Tenants’ clients generally access cloud services, via a NAT gateway to each tenant logical network. However, packets have to travel through the NAT gateway, which creates bottlenecks among tenant logical networks. Appellant’s claimed subject matter seeks to use a “distributed network address translation for efficient cloud service access,” via “the use of private (i.e., not routable for traversing the Internet) IP addresses for accessing shared cloud services by multiple tenant logical networks [in a virtualized infrastructure domain including several hosts 210-204, shown in Figure 2]” without going through a NAT gateway. Spec. ¶ 8. Figure 2 depicting Appellant’s virtualized infrastructure domain is reproduced below: Appeal 2021-001537 Application 15/784,136 3 Figure 2 depicts Appellant’s virtualized infrastructure domain including several hosts 201, 202, 203, or 204, each including a group of tenant VMs, a set of service VMs that provide different services to tenant VMs, and network address translation (NAT) agent 241-243. Spec. ¶¶ 53-54. According to Appellant, NAT agent 241, 242, 243, or 244 at each host 201, 202, 203, or 204 is arranged to intercept a packet sent by a tenant VM to one of the service VMs and replace “the source IP address and the port number of the tenant VM [] in a packet with a pair of replacement IP address and replacement port numbers that are unique among all tenant logical networks that utilize a virtualized infrastructure domain to access the cloud service.” Spec. ¶¶ 9, 13. The packet is then sent to the destination service VM without going through a NAT gateway. Id. If the requesting tenant VM Appeal 2021-001537 Application 15/784,136 4 and the destination service VM are not on the same host, “the packet is sent through a tunnel between the two hosts” without going through a NAT gateway to avoid bottlenecks. Spec. ¶ 10. Claims 21 and 31 are independent. Representative claim 21 is reproduced below with disputed limitations emphasized and numeral brackets added for clarity: 21. For a multi-tenant datacenter, a method of forwarding packets from tenant machines executing on a host computer to a set of one or more service machines used by a plurality of tenants, the method comprising: at the host computer, receiving a packet sent by a first machine of a first tenant that executes on the host computer; [1] determining that the packet should be processed by the set of service machines that are used by the plurality of tenants; based on the determination that the packet should be processed by the set of service machines, [2] replacing a first network address identified as a source network address in a header of the packet with a second network address, in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address; and forwarding the packet with the second network address to the set of service machines. Appeal Br. 21 (Claims App.). REJECTIONS AND REFERENCES (1) Claims 21-24 and 31-34 are rejected under 35 U.S.C. § 103 as obvious over the combined teachings of Mao (US 2014/0052877 A1; published Feb. 20, 2014) and Kageyama (US 2010/0115080 A1; published May 6, 2010). Final Act. 3-9. Appeal 2021-001537 Application 15/784,136 5 (2) Claims 25-29 and 35-39 are rejected under 35 U.S.C. § 103 as obvious over the combined teachings of Mao, Kageyama, Johnson et al. (US 2004/0109457 A1; published Jun. 10, 2004; “Johnson”), and Koponen et al. (US 2013/0044636 A1; published Feb. 21, 2013; “Koponen”). Final Act. 9- 14. (3) Claims 30 and 40 are rejected under 35 U.S.C. § 103 as obvious over the combined teachings of Mao, Kageyama, and DeCusatis et al. (US 2015/0188773 A1; published Jul. 2, 2015; “DeCusatis”). Final Act. 15. ANALYSIS Claims 21 and 31 In support of the obviousness rejection, the Examiner finds Mao teaches or suggests most of the limitations of Appellant’s claims 21 and 31, including the disputed limitation: [1] “determining that the packet should be processed by the set of service machines that are used by the plurality of tenants.” Final Act. 4 (citing Mao ¶ 66; see also Mao ¶¶ 8-11, 65, 67, 108- 111, 116, Figs. 4, 9). The Examiner acknowledges Mao does not teach, but relies on Kageyama for teaching the disputed limitation: [2] “replacing a first network address identified as a source network address in a header of the packet with a second network address, in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address” before “forwarding the packet with the second network address to the set of service machines.” Id. at 4-5 (citing Kageyama ¶¶ 6-6, 49, 71, Figs. 1, 2, 9). Based on these findings, the Examiner concludes: Appeal 2021-001537 Application 15/784,136 6 “[i]t would have been obvious . . . to have modified Mao to incorporate the teaching of Kageyama such that the system hypervisor/SH which intercepts the packet from the tenant VM performs a network address port translation function using an address port translation table which includes a pair of private source IP address and source port number used by a VM and a pair of global IP address and port number for each entry of the translation table allocated to the VM. Doing so would enable a virtual machine to be migrated between the virtual machine monitors operating on different hosts since the system would perform network address port translation such that a source/tenant VM forwards packets to the destination/service VM having a unique global network source address for each tenant VM.” Id. at 5-6 (emphasis added). Appellant disputes the Examiner’s findings regarding Mao and Kageyama. In particular, Appellant presents several principal arguments against the application of the teachings of Mao and Kageyama. First, Appellant contends Mao does not teach or suggest the disputed limitation: [1] “determining that the packet should be processed by the set of service machines that are used by the plurality of tenants” as recited in claims 21 and 31. Appeal Br. 9-13; Reply Br. 2-4. According Appellant, the cited paragraph [66] of Mao only describes that (1) “cloud resources are allocated ‘through various providers’ to a set of VMs” and (2) “a network virtualization infrastructure (NVI) system can then map globally unique identities of the set of VMs to the addresses of the allocated physical resources” (Appeal Br. at 9-10) and, as such, “has nothing to do with any determination that a packet should be processed by a set of service machines, let alone a set of service machines being used by multiple tenants” (Reply Br. 2). Likewise, the cited paragraphs [67, 100, 111] of Mao refer to the “determination made is whether a packet sent to a particular destination Appeal 2021-001537 Application 15/784,136 7 from a particular source is allowed” but “fails to disclose a determination that the packet should be processed by a set of service machines.” Appeal Br. at 11. (emphasis in original). Second, Appellant contends Kageyama does not teach or suggest the disputed limitation: [2] “replacing a first network address identified as a source network address in a header of the packet with a second network address, in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address” as recited in claims 21 and 31. Appeal Br. 13-14; Reply Br. 5-6. In particular, Appellant argues the cited portions of Kageyama only describe the use of first network address port translation (NAPT) module 14-1 within virtual machine (VM) 12-1, shown in Figure 1, to translate a destination network address (e.g., IP address and port number) of a packet from VM into a global network address (e.g., IP address and port number) of second NAPT module 14-2. Appeal Br. 13. According to Appellant, Kageyama’s “NAPT modules perform network address translation in order to transmit data addressed to VMs that have been migrated to another NAPT modules, not in order to prevent service machines from receiving different packets from different tenants with a common source network address.” Appeal Br. 13; Reply Br. 5. Third, Appellant contends Kageyama teaches away from Appellant’s disputed limitation because “two VMs on the same host would have their source addresses replaced with the same NAPT global address.” Appeal Br. 14; Reply Br. 6. According to Appellant, “the operations of Kageyama would NOT prevent external entities from receiving different packets from different tenant VMs with a common source address, because all VMs on the Appeal 2021-001537 Application 15/784,136 8 same host would have their source addresses replaced with the same NAPT global address.” Reply Br. 6. Appellant’s contentions are not persuasive of reversible Examiner error. Instead, we find the Examiner’s findings, including the Examiner’s responses to Appellant’s contentions, are supported by a preponderance of the evidence on this record. Ans. 3-7. As such, we adopt the Examiner’s findings provided therein. Id. For additional emphasis, we note that (1) the scope of Appellant’s claims 21 and 31 is significantly broader than the embodiments disclosed in Figures 2, 3, 5, 7, 15, 17, and 19 and described in paragraphs 52, 56-58, and 65-66 of the Specification; and (2) Appellant’s arguments are not commensurate with the scope of the claims and, for that reason, do not demonstrate error in the Examiner’s obviousness rejection of claims 21 and 31. See In re Self, 671 F.2d 1344, 1348 (CCPA 1982) (limitations not appearing in the claims cannot be relied upon for patentability). For example, Appellant’s claims 21 and 31 do not make a distinction between (1) public (or Internet routable) IP addresses for cloud services, which can be accessed from clients either in or out of the cloud and (2) private IP addresses (i.e., IP addresses that are not routable for traversing the Internet) assigned to tenants’ clients inside the cloud for private use. Nor do these claims emphasize the transmission of a packet sent to the destination service VM, whether between the requesting tenant VM and the destination service VM in the same host or at different hosts, without going through a NAT gateway to avoid bottlenecks. Instead, Appellant’s claims 21 and 31 broadly recite receiving determining that a packet should be processed by a set of service machines and replacing a first network address in a header of Appeal 2021-001537 Application 15/784,136 9 the packet with a second network address before forwarding the same packet with the replaced network address to the set of service machines. We also note that the test for obviousness is not whether the claimed invention is expressly disclosed in the references, but whether the claimed subject matter would have been obvious to those of ordinary skill in the art in light of the combined teachings of those references. In re Keller, 642 F.2d 413, 425 (CCPA 1981). Moreover, each “reference may be read for all that it teaches.” In re Mouttet, 686 F.3d 1322, 1331 (Fed. Cir. 2012) (citing KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 418-21 (2007)). In an obviousness analysis, it is not necessary to find precise disclosure directed to the specific subject matter claimed because inferences and creative steps that a person of ordinary skill in the art would employ can be taken into account. See KSR, 550 U.S. at 418. In this regard, “[a] person of ordinary skill is also a person of ordinary creativity, not an automaton.” Id. at 421. As the U.S. Supreme Court has stated, obviousness requires an “expansive and flexible” approach that asks whether the claimed improvement is more than a “predictable variation” of “prior art elements according to their established functions.” Id. at 415, 417. Here, in contrast, Appellant’s contentions rigidly focus on a narrow reading of Mao and Kageyama, without taking full account of an ordinarily skilled artisan’s “knowledge, creativity, and common sense.” Randall Mfg. v. Rea, 733 F.3d 1355, 1362 (Fed. Cir. 2013). For example, as recognized by the Examiner, when Mao’s virtual machines (VMs) are distributed within the network virtualization infrastructure (NVI), shown in Figure 2, to provide cloud services or cloud resources to tenant VMs in the tenant logical networks, these tenant VMs are Appeal 2021-001537 Application 15/784,136 10 tied to a set of service machines used by multiple tenants. Ans. 5 (citing Mao ¶¶ 8, 66). As such, we agree with the Examiner that a person skilled in the art would understand that any packet received from a tenant VM is said to be processed by the set of service machines that are used by multiple tenants in the manner recited in Appellant’s claims 21 and 31. Id. Likewise, as recognized by the Examiner, when Kageyama’s network address port translation (NAPT) module is used to translate between (1) a network address (private address) and a port number in the private address space and (2) a network address (global address) and a port number in the global address space, as shown in Figures 5-6 (Kageyama ¶ 52) and, more specifically, to translate the destination IP address and destination port number upon receipt of a packet based on its address port translation table 128, shown in Figure 9 and 12 (Kageyama ¶ 66), “a packet [] sent to a destination host includes the global address of source NAPT as the source IP address and the port number of source guest OS/VM, which would prevent service VMs from receiving different packets from different tenant VMs with a common source address.” Ans. 6-7 (citing Kageyama ¶ 71). As such, we agree with the Examiner that a person skilled in the art would understand that, when Kageyama’s packet is intercepted from the tenant VM and a destination network address is translated into a global network address, as shown in Figures 9-10, service VMs would be prevented “from receiving different packets from different tenant VMs with a common source address.” Id. 7 (emphasis added). Lastly, we are not persuaded by Appellant’s argument that Kageyama teaches away from claims 21 and 31. “A reference may be said to teach away when a person of ordinary skill, upon reading the reference, would be Appeal 2021-001537 Application 15/784,136 11 discouraged from following the path set out in the reference, or would be led in a direction divergent from the path that was taken by the applicant.” In re Gurley, 27 F.3d 551, 553 (Fed. Cir. 1994). There is no evidence in the record to support Appellant’s argument that “two VMs on the same host would have their source addresses replaced with the same NAPT global address.” Appeal Br. 14; Reply Br. 6. Instead, upon receipt of a packet (communication data), Kageyama’s NAPT module 14-1, shown in Figure 1, translates the destination network address (e.g., IP address and port number) into a global network address (e.g., unique IP address and port number). As shown in Figures 11-12, these global network addresses as translated are unique from each other. As such, we are not persuaded by Appellant’s contention that “all VMs on the same host would have their source addresses replaced with the same NAPT global address.” Reply Br. 6. For these reasons, Appellant does not persuade us of reversible Examiner error. Accordingly, we sustain the Examiner’s obviousness rejection of Appellant’s independent claims 21 and 31 and of dependent claim 23 and 33, which are not argued separately. Claims 22 and 32 Claims 22 and 32 depend from claims 21 and 31, and further recite: (i) receiving a second packet sent by a second machine of a second tenant that also executes on the host computer and (ii) replacing a third network address identified as a source network address in a header of the second packet with a fourth network address in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address. Appeal 2021-001537 Application 15/784,136 12 Appellant contends neither Mao nor Kageyama teaches or suggests multiple tenants executing on a host computer or using a fourth network address to replace a third network address in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address. Appeal Br. 15-17; Reply Br. 7-8. Appellant’s contention is not persuasive of Examiner error. As recognized by the Examiner, Kageyama’s network address port translation (NAPT) module is used to translate the destination IP address and destination port number upon receipt of a packet (Kageyama ¶ 66), “a packet [] sent to a destination host includes the global address of source NAPT as the source IP address and the port number of source guest OS/VM, which would prevent service VMs from receiving different packets from different tenant VMs with a common source address.” Ans. 8 (citing Kageyama ¶ 71). According to Kageyama, the packet received would be processed and translated the same way, via the address port translation table, shown in Figures 9 and 12, whethere the tenant is the first or the second tenant. As such, we agree with the Examiner that a person skilled in the art would understand that, when Kageyama’s packet is intercepted from the tenant VM and a destination network address is translated into a global network address, as shown in Figure 9 and 12, service VMs would be prevented “from receiving different packets from different tenant VMs with a common source address.” Id. 9. Claims 24 and 34 Claims 24 and 34 depend from claims 21 and 31, and further require that “the second network address uniquely identifies the first machine for the set of service machine.” Appeal 2021-001537 Application 15/784,136 13 Appellant contends Kageyama only teaches using a global address that identifies the NAPT module instead of “a network address that uniquely identifies a source machine of the packet.” Appeal Br. 17; Reply Br. 7-8. We do not agree with Appellant. As explained by the Examiner, when a packet received is translated, via Kageyama’s NAPT module, that “ packet [] sent to a destination host includes the global address of source NAPT as the source IP address and the port number of source guest OS/VM, which identifies the source VM.” Ans. 10 (citing Kageyama ¶ 71). For these reasons, Appellant does not persuade us of reversible Examiner error. Accordingly, we sustain the Examiner’s obviousness rejection of Appellant’s dependent claims 22, 24, 32, and 34. For the same reasons, we also sustain the Examiner’s obviousness rejections of (1) claims 25, 26, 28, 29, 35, 36, 38, and 39 as obvious over Mao, Kageyama, Johnson, and Koponen, which are not argued separately, and (2) claims 30 and 40 as obvious over Mao, Kageyama, and DeCusatis, which are not argued separately. Claims 27 and 37 Claims 27 and 37 depend from claims 21 and 31, via intervening claims 25-26 and 35-36, and further comprise: (i) “determining that a session between the first machine and a service machine in the set of service machine has ended;” and (ii) “re-assigning the second network address to the plurality of replacement candidate network addresses.” The Examiner relies upon Johnson for teaching these limitations of claims 27 and 37. Final Act. 12 (citing Johnson ¶¶ 19, 26). Appellant argues the cited portions of “Johnson refers to (1) a routing table of a gateway device that automatically updates to quickly show invalid Appeal 2021-001537 Application 15/784,136 14 routes and (2) a device inside a network communicating a request for an external address to a network address management module to be assigned an external network address to use to establish an outbound communication session with an external device.” Appeal Br. 18 (citing Johnson ¶ 26); Reply Br. 9-10. According to Appellant, Johnson “fails to address determining that a session has ended or re-assigning any network address to the pool of potential network addresses.” Id. The Examiner responds that Johnson’s network address translation (NAT) technology is used to perform dynamic network address assignment that eliminates the possibility of assigning a network address that is already in use by another device to the network device, where a candidate network address can be taken from a pool of potential network addresses and, “if a client does not request renewal of the lease, it expires, and upon lease expiration, the device’s assigned IP address is returned to an address pool for reassignment to a different device.” Ans. 10 (citing Johnson ¶¶ 2, 8, 19, 26). However, the Examiner’s findings and explanations are not supported by substantial evidence. Returning Johnson’s assigned IP address to an address pool upon an expiration of a lease for reassignment to a different device is not the same as the claimed “determining that a session between the first machine and a service machine in the set of service machine has ended” and “re-assigning the second network address to the plurality of replacement candidate network addresses” as recited in Appellant’s claims 27 and 37. For these reasons, we do not sustain the Examiner’s obviousness rejection of claims 27 and 37 as obvious over Mao, Kageyama, Johnson, and Koponen. Appeal 2021-001537 Application 15/784,136 15 CONCLUSION3 On this record, Appellant does not persuade us the Examiner errs in rejecting (1) claims 21-24 and 31-34 as obvious over the combined teachings of Mao and Kageyama; (2) claims 25, 26, 28, 29, 35, 36, 38, and 39 as obvious over the combined teachings of Mao, Kageyama, Johnson, and Koponen; and (3) claims 30 and 40 as obvious over the combined teachings of Mao, Kageyama, and DeCusatis. However, Appellant persuades us the Examiner errs in rejecting claims 27 and 37 as obvious over the combined teachings of Mao, Kageyama, Johnson, and Koponen. As such, we reverse the Examiner’s obviousness rejection of claims 27 and 37. 3 In the event of further prosecution of this application, the Examiner should evaluate claims 21 and 31 for compliance under 35 U.S.C. § 112(a) for failing to comply with the written support for the phrase: “in order to prevent the set of service machines from receiving different packets from different tenants with a common source network address.” Appellant refers to paragraphs 62-69 and Figure 3 of the Specification to provide the written support for that phrase. Appeal Br. 2 (emphasis added) (citing Spec. ¶¶ 62- 69, Fig. 3). However, the cited portions of Appellant’s Specification do not appear to convey that “the set of service machines” are prevented “from receiving different packets from different tenants with a common source network address.” Moreover, we are unable to discern the meaning of the term “a common source network address.” The Examiner should consider whether, based on the disclosure of Appellant’s Specification, a skilled artisan would understand that a set of service machines are prevented from “receiving different packets from different tenants with a common source network address,” as claimed (emphasis added). Should the Examiner find the requisite disclosure lacking, the Examiner should consider rejecting claims 21 and 31 under 35 U.S.C. § 112(a) as lacking written description. Appeal 2021-001537 Application 15/784,136 16 DECISION SUMMARY In summary: Claim(s) Rejected 35 U.S.C. § Reference(s)/ Basis Affirmed Reversed 21-24, 31-34 103 Mao, Kageyama 21-24, 31- 34 25, 26, 28, 29, 35, 36, 38, 39 103 Mao, Kageyama, Johnson, Koponen 25, 26, 28, 29, 35, 36, 38, 39 27, 37 103 Mao, Kageyama, Johnson, Koponen 27, 37 30, 40 103 Mao, Kageyama, DeCusatis 30, 40 Overall Outcome 21-26, 28- 36, 38-40 27, 37 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv). See 37 C.F.R. § 1.136(a)(1)(iv) (2019). AFFIRMED IN PART