Ex Parte Durrant et alDownload PDFPatent Trial and Appeal BoardJan 29, 201814335466 (P.T.A.B. Jan. 29, 2018) Copy Citation 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/335,466 07/18/2014 Paul Durrant 007737.00430 8378 11331 7590 01/31/21 Banner & Witcoff, Ltd. Attorneys for client number 007737 1100 13th Street N.W. Suite 1200 Washington, DC 20005-4051 EXAMINER NGUYEN, KIM T ART UNIT PAPER NUMBER 2153 NOTIFICATION DATE DELIVERY MODE 01/31/2018 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): PTO-11331 @bannerwitcoff.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte PAUL DURRANT and BEN CHALMERS Appeal 2016-006037 Application 14/335,4661 Technology Center 2100 Before CARL W. WHITEHEAD JR., HUNG H. BUI, and SHARON FENICK, Administrative Patent Judges. BUI, Administrative Patent Judge. DECISION ON APPEAL Appellants seek our review under 35 U.S.C. § 134(a) of the Examiner’s Final Office Action rejecting claims 1—21, which are all the claims pending on appeal. We have jurisdiction under 35 U.S.C. § 6(b). An oral hearing was conducted on November 28, 2017. A transcript of the oral hearing was made of record on December 26, 2017. We AFFIRM-IN-PART.2 1 According to Appellants, the real party in interest is Citrix Systems, Inc. App. Br. 2. 2 Our Decision refers to Appellants’ Appeal Brief filed November 19, 2015 (“App. Br.”); Reply Brief filed May 13, 2016 (“Reply Br.”); Examiner’s Answer mailed May 6, 2016 (“Ans.”); Final Office Action mailed June 15, 2015 (“Final Act.”); and original Specification filed July 14, 2014 (“Spec.”) Appeal 2016-006037 Application 14/335,466 STATEMENT OF THE CASE Appellants’ invention relates to “methods and systems for performing file transfers across different domains hosted by a virtualization server.” Abstract. Data transfer can be performed “between virtual machines when at least one of the machines is untrusted,” i.e., “a trusted domain and a guest domain executing on a hypervisor [shown in Figure 5].” Spec. Tflf 2, 7. According to Appellants, “hypervisor [] may be a program executed by processors [] on the virtualization server [] to create and manage any number of virtual machines.” Spec. ^fl[ 60-62. Appellants’ Figure 5 is reproduced below with additional markings for illustration. Appellants’ Figure 5 shows a system architecture for data transfer between trust domain 501 (e.g., virtual machine 432A) and guest domain 511 (e.g., virtual machine 432B) executing on hypervisor 521. 2 Appeal 2016-006037 Application 14/335,466 Claims 1, 8, and 15 are independent. Claim 1 is illustrative of the claimed subject matter, as reproduced below with disputed limitations in italics: 1. A method of transferring data, comprising: receiving an indication that modified data is available to a guest domain executing on a hypervisor, said modified data including one or more data files in a file system of and originating from a trusted domain executing on the hypervisor, and aliasing each of the one or more data files to be accessible through a file system of the guest domain. App. Br. 12 (Claims App.). Examiner’s Rejection and Reference Claims 1—21 stand rejected under 35 U.S.C. § 102(b) as being anticipated by Schuba et al., US 2009/0313446 Al; pub. Dec. 17, 2009 (“Schuba”). Final Act. 3—9. ANALYSIS Claims 1, 8, and 15 Independent claim 1 (and similarly, claims 8 and 15) recites a method of transferring data comprising two disputed limitations: (1) “receiving an indication that modified data is available to a guest domain executing on a hypervisor, said modified data including one or more data files in a file system of and originating from a trusted domain executing on the hypervisor;” and (2) “aliasing each of the one or more data files to be accessible through a file system of the guest domain.” 3 Appeal 2016-006037 Application 14/335,466 In support of the anticipation rejection of independent claims 1, 8, and 15, the Examiner finds Schuba discloses a method of transferring data between virtual machines, i.e., a control (trusted) domain (CD) and a guest domain (GD) equipped with all the disputed limitations in contexts of (1) guest domain (GD) 402-404, shown in Figures 4A-4C, sending a request for data, via control (trusted) domain (CD) 400; (2) if the requested data (e.g., File A) has been modified by another domain (i.e., trusted domain), storing requested data including the original copy of File A and the modified copy of File A in shared memory (SM) 410; and (3) control (trusted) domain (CD) 400 notifying guest domain (GD) 402 or 404 that requested data is stored in shared memory (SM) 410 and that such requested data is made accessible to guest domain (GD) 402 or 404, via hypervisor page map 420. Final Act. 4, 5, 7 (citing Schuba Tflf 49-51, 62); Ans. 3 (citing Schuba Tflf 49-52, Figs. 4A-4C). Schuba’s Figure 4A is reproduced below with additional markings for illustration: 4 Appeal 2016-006037 Application 14/335,466 Schuba’s Figure 4A shows sharing data stored in shared memory (SM) 410 between control (trusted) domain (CD) 400 and guest domains (GDs) 402- 404, via hypervisor 406. Appellants contend Schuba does not disclose the disputed limitations: (1) “receiving an indication that modified data is available to a guest domain executing on a hypervisor, said modified data including one or more data files in a file system of and originating from a trusted domain executing on the hypervisor;” and (2) “aliasing each of the one or more data files to be accessible through a file system of the guest domain” as recited in claim 1, and similarly recited in claims 8 and 15. App. Br. 5—8; Reply Br. 1—4. In particular, Appellants acknowledge Schuba teaches a method and system for cross-domain data sharing, but argue Schuba “does not share data in the same manner as the claimed invention, i.e., where data originates from a trusted domain and is made available to a guest domain” because Schuba’s 5 Appeal 2016-006037 Application 14/335,466 “data modified by one domain is not made available to another domain.” App. Br. 5. According to Appellants, “[t]o any extent that data is ‘shared’ between domains in Schuba, it is only as a byproduct of both domains already having access to the underlying data in the first place.” App. Br. 4; Reply Br. 2. However, Appellants argue Schuba “does not transfer data, as recited in claim 1” and “[n]o data is ever transferred between domains that did not originate with the receiving domain.” App. Br. 7-8. In other words, “[d]ata originating from one domain in Schuba is never provided to a second/different domain in Schuba.” Reply Br. 3. According to Appellants, “Schuba does not use shared memory to transfer data or files from one domain to another, as claimed, but rather uses a shared memory to reduce redundancy and increase [memory] efficiency.” Reply Br. 4. In addition, Appellants argue: (1) Schuba does not teach “modified data as claimed [i.e., originating from a trusted domain]” or “providing a guest domain with access to data modified by a trusted domain;” rather, “each domain in Schuba is provided with access only to data created or modified by that domain, and not to data created or modified by a trusted domain, as claimed” (App. Br. 6); and (2) Schuba “actually prevents data modified by one domain from being accessible by a different domain” and, as such, “teaches away from the claimed invention” (App. Br. 6 (citing Schuba 149); Reply Br. 3—4). 6 Appeal 2016-006037 Application 14/335,466 We are not persuaded by Appellants’ arguments because these arguments: (1) are not commensurate with the scope of claims 1, 8, and 15; and (2) are predicated upon a narrow reading of Schuba. First, we note that while the term “data transfer” is recited in the preamble, no active step of transferring data from a trusted domain to a guest domain is recited in the body of Appellants’ claim 1. Similarly, Appellants’ claims 8 and 15 do not recite any “data transfer” between a trusted domain and a guest domain. Instead, Appellants’ claims 1, 8, and 15 are broadly worded to require only that (1) “an indication” is received that “modified data [including one or more data files in a file system of and originating from a trusted domain executing on the hypervisor] is available to a guest domain executing on a hypervisor” and that (2) “each [] data files [i.e., modified data]” is aliased or made “to be accessible through a file system of the guest domain.” These broadly worded limitations are disclosed by Schuba. For example, paragraph [49] of Schuba describes: “if the requested data (e.g., File A) has been modified by another domain ri.e., control (trusted) domain], then the storage pool would include the original copy of File A as well as a modified copy of File A. In such cases, the File A and modified File A would be stored at different metaslab IDs and offsets.” Schuba 149 (emphasis added). As also recognized by the Examiner, “when the requested data (modified data) located in the shared memory... rt]he guest domain (via the CD interface, hypervisor, and GD interface) is notified that the data was successfully obtained and stored at the virtual memory address specified. The requested data is stored in the exclusive virtual memory of the guest domain. However, the requested data is actually stored in the shared memory and is accessible to the guest domain via the 7 Appeal 2016-006037 Application 14/335,466 hypervisor page map and the guest domain address map. The guest domain may access the requested data using the hypervisor page map and the guest domain address map.” Ans. 3-4 (citing SchubaH 49, 51, 52, Figs. 2, 4A-4C) (emphasis added). In other words, Schuba discloses data sharing between a control (trusted) domain (CD) 400 and a guest domain (GD) 402-404, via hypervisor 406, shown in Figures 4A-AC, including: (1) the guest domain sending a request for data to the control (trusted) domain (see Schuba 147); (2) if the requested data (e.g., File A) has been modified by another domain, i.e., control (trusted) domain, the control (trusted) domain storing both the original copy of File A and the modified copy of File A in shared memory (see Schuba 149); and then (3) the control (trusted) domain sending notification (indication) to the guest domain (GD) that “modified data” [originating from a trusted domain executing on the hypervisor] is available and “to be accessible through a file system of the guest domain” (see Schuba 147). Second, Schuba teaches “a method and system for cross-domain data sharing,” as Appellants acknowledge. App. Br. 6. Contrary to Appellants’ arguments, data sharing as disclosed by Schuba is inclusive of both (1) original data and (2) modified data from any domain, including control (trusted) domain (GD) 400 or guest domains (GDs) 402-404, shown in Figures 4A-4C, and is intended across all different domains. As such, we disagree with Appellants’ narrow reading of paragraph 49 of Schuba and characterization that: (1) Schuba is limited to providing a guest domain with access to data created or modified by that domain, and not to data modified by a trusted domain; and (2) Schuba “actually prevents data modified by one 8 Appeal 2016-006037 Application 14/335,466 domain from being accessible by a different domain” and, as such, “teaches away from the claimed invention.” App. Br. 6—7 (citing Schuba 149); Reply Br. 2—4. Based on this record, we are not persuaded of Examiner error. Accordingly, we sustain the Examiner’s anticipation rejection of independent claims 1,8, and 15, and their respective dependent claims 6, 13, and 20, which Appellants do not argue separately. Claims 2—4, 9—11, and 16—18 Claim 2 depends from independent claim 1, and further recites “wherein aliasing comprises a proxy driver intercepting file system calls within the guest domain and determining whether to execute each file system call within the file system of the guest domain or to pass the file system call to the trusted domain.” Claims 9 and 16 recite similar limitations. Appellants argue Schuba does not disclose any “proxy driver intercepting file system calls within the guest domain and determining whether to execute each file system call within the file system of the guest domain or to pass the file system call to the trusted domain” as claimed. App. Br. 8-9. The Examiner initially cites paragraph 4 of Schuba (Final Act. 4) and then refers to paragraph 56 of Schuba (Ans. 6) for allegedly disclosing Appellants’ claimed “proxy driver.” Ans. 6 (citing Schuba 1 56). We do not agree with the Examiner’s findings. The “proxy driver” as recited in Appellants’ claims 2, 9, and 16 is described by Appellants’ Specification as part of, or within guest domain 511, shown in Figure 5, used 9 Appeal 2016-006037 Application 14/335,466 to intercept calls made by any application or program executing within guest domain 511 to access the guest domain’s file system 51 and proxy the request for any data shared to trusted domain 501, via shared memory 531. Spec. 117-8, 70, 75. Neither paragraph 4 nor paragraph 56 of Schuba describes any “proxy driver” or its functional equivalents as part of guest domain 511, shown in Figure 5, used to intercept calls within guest domain 511. Instead, these paragraphs describe hypervisor 406—as separate component from control (trusted) domain 501 and guest domain 511—acting to intercept a write request for data when guest domain 511 is implemented in a host mode. See Schuba 114, 53-56. Because Schuba does not disclose any “proxy driver intercepting file system calls within the guest domain and determining whether to execute each file system call within the file system of the guest domain or to pass the file system call to the trusted domain,” we do not sustain the Examiner’s anticipation rejection of claims 2, 9, and 16, and similarly, claims 3—4, 10- 11, and 17—18, which depend therefrom. Claims 5, 7, 12, 14, and 21 Claim 5 depends from independent claim 1, and further recites “the indication is received based on a key value store storing file metadata for each data file shared by the trusted domain, said metadata includes a file name, a file type, a file location, a file size, and a file date.” Claim 12 recites similar limitations. 10 Appeal 2016-006037 Application 14/335,466 Appellants argue Schuba does not disclose any use of keys, key values or “a key value store storing file metadata for each data file shared by the trusted domain” as claimed. App. Br. 10. The Examiner cites paragraphs 30 and 49 of Schuba for allegedly disclosing Appellants’ claimed “key value store [as part of trusted domain].” Final Act. 5 (citing Schuba ^fl[ 30, 49); Ans. 9—10 (citing Schuba 149). We disagree with the Examiner’s findings. The term “key value store” as recited in Appellants’ claims 5 and 12 is described by Appellants’ Specification as part of trusted domain 501, i.e., a key value database 507 administered by a key value manager 506, shown in Figure 5, to share configuration, metadata and status information. Spec. ]Hf 68—70. Neither paragraph 30 nor paragraph 49 of Schuba describes any “key value store” as part of the trusted domain. Instead, these paragraphs describe shared memory (SM) and storage pool 108, shown in Figure 1A and Figures 4A-4C, to store data to be shared between control (trusted) domain (CD) 100 and guest domains (GDs) 102-104. See Schuba ^fl[ 30, 49. Because Schuba does not disclose any “key value store” or “the indication is received based on a key value store storing file metadata for each data file shared by the trusted domain,” we do not sustain the Examiner’s anticipation rejection of claims 5 and 12, and similarly, claims 7, 14, and 21, which depend therefrom. CONCFUSION On the record before us, we conclude Appellants have not demonstrated the Examiner erred in rejecting claims 1, 6, 8, 13, 15, and 20 under 35 U.S.C. § 102(b) as anticipated by Schuba. However, we conclude 11 Appeal 2016-006037 Application 14/335,466 Appellants have demonstrated the Examiner erred in rejecting claims 2—5, 7—12, 14, 16—19, and 21 under 35 U.S.C. § 102(b) as anticipated by Schuba. DECISION As such, we AFFIRM the Examiner’s final rejection of claims 1, 6, 8, 13, 15, and 20 under 35 U.S.C. § 102(b) as anticipated by Schuba. However, we REVERSE the Examiners’ final rejection for claims 2—5, 7— 12, 14, 16—19, and 21 under 35 U.S.C. § 102(b) as anticipated by Schuba. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv). AFFIRMED-IN-PART 12 Copy with citationCopy as parenthetical citation