VMWARE, INC.

Patent Trials and Appeals Board

Jan 14, 2022

2021000319 (P.T.A.B. Jan. 14, 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. 14/841,737 09/01/2015 DINESH BABU THIRUKONDAN GNANESWARAN C494 1469 152569 7590 01/14/2022 Patterson + Sheridan, LLP - VMware 24 Greenway Plaza Suite 1600 Houston, TX 77046 EXAMINER SOWA, TIMOTHY JOHN ART UNIT PAPER NUMBER 2448 NOTIFICATION DATE DELIVERY MODE 01/14/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 psdocketing@pattersonsheridan.com vmware_admin@pattersonsheridan.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte DINESH BABU THIRUKONDAN GNANESWARAN, SUBRAHMANYAM MANNAM, GAURAV GUPTA, and HERMANTH KUMAR KILARI Appeal 2021-000319 Application 14/841,737 Technology Center 2400 BEFORE ALLEN R. MacDONALD, CHRISTA P. ZADO, and AMBER L. HAGY, Administrative Patent Judges. ZADO, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1, 3-5, 7-9, 11-13, 15-17, 19, and 20, all the claims pending in the present application. We have jurisdiction under 35 U.S.C. § 6(b). We REVERSE. 1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42(a). Appellant identifies the real party in interest as VMware, Inc. Appeal Br. 3. Appeal 2021-000319 Application 14/841,737 2 CLAIMED SUBJECT MATTER The instant application relates to identifying application dependency in virtualized environments. Spec. ¶¶ 2. Claim 1, with the limitation at issue italicized, illustrates the claimed subject matter and is reproduced below: 1. A computer-implemented method of identifying application dependencies in a hybrid environment in which one or more applications run in operating system (OS)-less containers, where an OS-less container comprises a container without its own operating system that runs on a host operating system, comprising: monitoring network traffic at one or more host computer systems, wherein OS-less containers run in at least one of the host computer systems; monitoring network traffic at virtual bridges to which the OS- less containers are attached, wherein monitoring the network traffic at the virtual bridges includes: identifying OS-less container services running in the host computer systems; for each of the OS-less container services: identifying an external port used on the host computer to accept requests from the OS-less container service and an internal port used by the OS-less container to process the requests by issuing a request for information regarding the external port and the internal port to the host operating system, and obtaining an assigned local address for the OS-less container service; and capturing network packet details from the virtual bridges using Transmission Control Protocol (TCP) dumps; Appeal 2021-000319 Application 14/841,737 3 identifying network dependencies based on the monitored network traffic at the host computer systems and the monitored network traffic at the virtual bridges; and determining the application dependencies based on the identified network dependencies, wherein determining the application dependencies of a first application and a second application includes generating a hash map comprising from internet protocol (IP) address, to IP address, and port number as keys and applications as values, and wherein the dependency of the first application on the second application is identified when the first and second applications are associated with the same key in the hash map. Appeal Br. 14 (Claims App.). REFERENCES The prior art relied upon by the Examiner is: Name Reference Date Hull US 2012/0072258 A1 Mar. 22, 2012 Benc US 2016/0254964 A1 Sept. 1, 2016 Parandehgheibi US 2016/0359705 A1 Dec. 8, 2016 Feng Zhao et al., VNIDS: A Virtual Machine-based Network Intrusion Detection System, IEEE ASID 2008 2nd International Conference, pp. 254-259 (2008). REJECTIONS The claims stand rejected as follows: Claims Rejected 35 U.S.C. § References 1, 3-5, 7-9, 11-13, 15- 17, 19, 20 103 Parandehgheibi, Benc, Hull, Zhao Appeal 2021-000319 Application 14/841,737 4 OPINION At issue in this appeal is whether Parandehgheibi teaches or recites “identifying an external port used on the host computer to accept requests from the OS-less container service and an internal port used by the OS-less container to process the requests,” as recited in independent claim 1, and similar recitations of independent claims 9 and 17. Appellant submits that because Parandehgheibi neither teaches nor suggests this claimed feature, we should reverse the Examiner’s rejection of claims 1, 9, and 17, and all pending claims depending therefrom. For reasons that follow, we find the Examiner has not shown Parandehgheibi teaches identifying an internal port used by an OS-less container, and we reverse the Examiner’s rejection. In datacenter computer systems, it can be desirable to determine dependencies between software applications. For example, “datacenter migration preplanning typically includes considering application dependency to ensure applications that depend on each other are migrated together.” Spec. ¶ 2. Traditional techniques for determining application dependency involve monitoring network traffic to identify source and destination of requests and source and destination of responses to requests. Id. ¶ 3. For example, when a network includes multiple virtual machines (VMs), the system monitors outgoing requests from one VM and incoming requests at another VM, specifically looking at the source and destination ports of the requests. If the from/to ports of an outgoing request on one VM match the to/from ports of an outgoing response on another VM, the applications running on each machine might be related (a hash map may be applied to make this determination, but it is not relevant to this appeal). See, e.g., id. ¶¶ 11-14. Appeal 2021-000319 Application 14/841,737 5 The Specification states that mapping dependencies is even more complicated when the system includes Operating System-less (OS-less) containers. Spec. ¶ 3. OS-less containers are containers that each contain an application that runs on the same software kernel as other containers, but each OS-less container has its own specific allocation of resources. Id. According to the Specification, the OS-less containers within the same host VM use the same external port number, i.e., the port number associated with the virtual Ethernet bridge to which the containers are connected. Id. However, each container also has a private, hidden IP address visible only within the internal container network, wherein the hidden address identifies the container (and hence the application running on the container). Id. Appellant argues that a problem arises when mapping application dependencies using traditional network monitoring techniques. Appeal Br. 9-10. Specifically, when a request or response is from or to an OS-less container, the port data in the header of the request or response in conventional systems uses the public external port number. Id. According to Appellant, such information is not specific enough to map application dependencies because it does not identify the private internal port number of the OS-less container running a particular application. Id. (citing Spec. ¶ 3). The claims relate to identifying application dependencies in an environment that includes OS-less containers. The limitation at issue recites, “identifying an external port used on the host computer to accept requests from the OS-less container service and an internal port used by the OS-less container to process the requests.” Appeal Br. 14 (Claims App.). For this limitation, the Examiner relies on Parandehgheibi. Parandehgheibi relates to mapping application dependencies. Parandehgheibi [57]. The Appeal 2021-000319 Application 14/841,737 6 Final Action from which this appeal is taken relies on Figure 3 and paragraphs 3, 28, 37, 51-53, 58, 64, 66, 75, and 101. Final Act. 6. Appellant argues that although these paragraphs describe monitoring network packets and identifying ports, they do not describe identifying an internal port used by an OS-less container. Appeal Br. 8-11. Appellant argues Parandehgheibi uses a conventional technique that is limited to identifying external ports. Id. at 11. We agree with Appellant that the cited portions of Parandehgheibi do not describe identifying an internal port of an OS-less container. As argued by Appellant, the cited portions of Parandehgheibi describe monitoring public IP addresses and public port numbers. Id.; Parandehgheibi ¶¶ 3, 28, 37, 51-53, 58, 64, 66, 75, 101. In the Answer, the Examiner introduces paragraph 40 of Parandehgheibi, which discusses the issue of collecting network traffic data for VM-to-VM or container-to-container traffic on the same host. Ans. 6 (citing Parandehgheibi ¶ 40). Appellant responds that Parandehgheibi acknowledges that conventional network monitoring sensors do not monitor container-to-container traffic, but does not teach identifying internal ports as a solution to this problem. Reply 6. We are persuaded by Appellant’s arguments. Parandehgheibi ¶ 40 teaches, in pertinent part, that conventional sensors do not monitor container internal port numbers, stating “a conventional sensor network may be limited to sensors running on external- facing network devices . . . such that east-west traffic, including VM-to-VM or container-to-container traffic on a same host, may not be monitored.” The Examiner finds, however, that Parandehgheibi discloses a solution to the problem of conventional systems not monitoring container-to-container Appeal 2021-000319 Application 14/841,737 7 traffic, namely that sensors can be located at multiple points of potential failure. Ans. 6 (citing Parandehgheibi ¶ 40). Based on this disclosure, the Examiner concludes that Parandehgheibi teaches identifying internal port numbers, finding that “by ubiquitously situating sensors at virtual machines internal to a virtual switch, e.g. a virtual bridge, such sensors situated at virtual machines on the internal side of a virtual bridge collect and report internal source and destination IP addresses as well as port numbers, in addition to external ports, e.g. standard port 80 for public HTTP Web services.” Id. We disagree with the conclusion the Examiner draws. When read in full context, Parandehgheibi appears to be concerned with ensuring accurate data is collected by collecting data from multiple (more than one) points of view. See, e.g., Parandehgheibi ¶ 40 (“collecting network traffic and corresponding data from multiple points of view ensures more accurate data is collected”). Parandehgheibi explains more generally that packets may be dropped before traversing a network device or that packets containing error may be monitored incorrectly, and that such problems may be mitigated by locating sensors at multiple points of potential failure: Since the sensors 304 may be located throughout the network, network traffic and corresponding data can be collected from multiple vantage points or multiple perspectives in the network to provide a more comprehensive view of network behavior. The capture of network traffic and corresponding data from multiple perspectives rather than just at a single sensor located in the data path or in communication with a component in the data path, allows the data to be correlated from the various data sources, which may be used as additional data points by the analytics engine 310. Further, collecting network traffic and corresponding data from multiple points of view ensures more accurate data is captured. For example, a conventional sensor network may be limited to sensors running on external-facing Appeal 2021-000319 Application 14/841,737 8 network devices (e.g., routers, switches, network appliances, etc.) such that east-west traffic, including VM-to-VM or container-to-container traffic on a same host, may not be monitored. In addition, packets that are dropped before traversing a network device or packets containing errors may not be accurately monitored by the conventional sensor network. The sensor network 304 of various embodiments substantially mitigates or eliminates these issues altogether by locating sensors at multiple points of potential failure. Moreover, the network traffic monitoring system 300 can verify multiple instances of data for a flow (e.g., source endpoint flow data, network device flow data, and endpoint flow data) against one another. Parandehgheibi ¶ 40. We do not discern any disclosure of placing sensors at a location within an internal container network in order to monitor internal port numbers, much less any discussion of internal port numbers. Reply 7 (arguing that although Parandehgheibi describes the problem of monitoring traffic at a container, it does not distinguish between an external port used by a host computer and an internal port used by an OS-less container to process the requests). For the foregoing reasons, we reverse the Examiner’s rejection of claims 1, 3-5, 7-9, 11-13, 15-17, 19, and 20 under 35 U.S.C. § 103 as unpatentable over the combination of Parandehgheibi, Benc, Hull, and Zhao. CONCLUSION The Examiner’s rejection is reversed. Appeal 2021-000319 Application 14/841,737 9 DECISION SUMMARY In summary: Claims Rejected 35 U.S.C. § References Affirmed Reversed 1, 3-5, 7-9, 11-13, 15- 17, 19, 20 103 Parandehgheibi, Benc, Hull, Zhao 1, 3-5, 7-9, 11-13, 15- 17, 19, 20 Overall Outcome 1, 3-5, 7-9, 11-13, 15- 17, 19, 20 REVERSED