MICROSOFT TECHNOLOGY LICENSING, LLCDownload PDFPatent Trials and Appeals BoardMay 21, 20202019002394 (P.T.A.B. May. 21, 2020) 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. 15/083,006 03/28/2016 Jose Bernabeu-Auban 324552.02/MFCP.252288 9797 45809 7590 05/21/2020 SHOOK, HARDY & BACON L.L.P. (MICROSOFT TECHNOLOGY LICENSING, LLC) INTELLECTUAL PROPERTY DEPARTMENT 2555 GRAND BOULEVARD KANSAS CITY, MO 64108-2613 EXAMINER TODD, GREGORY G ART UNIT PAPER NUMBER 2457 NOTIFICATION DATE DELIVERY MODE 05/21/2020 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): IPDocket@shb.com docket.shb@clarivate.com usdocket@microsoft.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ________________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ________________ Ex parte JOSE BERNABEU-AUBAN and YOUSEF A. KHALIDI ________________ Appeal 2019-002394 Application 15/083,006 Technology Center 2400 ________________ Before ERIC S. FRAHM, JOHNNY A. KUMAR, and LARRY J. HUME, Administrative Patent Judges. KUMAR, Administrative Patent Judge. DECISION ON APPEAL Appeal 2019-002394 Application 15/083,006 2 STATEMENT OF CASE Introduction Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals the Non-Final Rejection of claims 1–20. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. Exemplary Claim Exemplary claim 1 under appeal reads as follows: 1. One or more computer-readable memory having computer- executable instructions embodied thereon that, when executed, perform a method for configuring a hosting environment of a data center based on a definition of a subject role of a service application, the method comprising: receiving a service model that specifies definitions of one or more roles of the service application, wherein the one or more roles include hosting environment dependencies for implementation on the hosting environment, wherein the hosting environment is a runtime environment comprising Application Programming Interfaces (APIs) that facilitate execution of the one or more roles; automatically instantiating a subject role of the one or more roles, wherein instantiating comprises: (a) selecting one of the set of base hosting environments based on the definition of the subject role; and (b) refining the selected hosting environment according to map constructs derived from configuration settings of the subject role; and at least temporarily storing the refined hosting environment in conjunction with the subject role. 1 We use the word “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. According to Appellant, MICROSOFT TECHNOLOGY LICENSING, LLC is the real party in interest. Appeal Br. 3. Appeal 2019-002394 Application 15/083,006 3 REJECTIONS Claims 1–20 are rejected under 35 U.S.C. § 102(e) as being anticipated by Friedman et al. (US Pat. 2009/0300151 A1). Non-Final Act. 3. Claims 5 and 8 are rejected under 35 U.S.C. § 112, second paragraph. Non-Final Act. 2.2 Claims 1–20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of US Pat. 9,300,532. Non-Final Act. 9. 3 ANALYSIS We have considered all of Appellant’s arguments raised in the Brief4 and any evidence presented. We disagree with Appellant’s arguments, and we adopt as our own: (1) the findings and legal conclusions set forth by the Examiner in the Non-Final Office Action from which this appeal is taken, and (2) the findings, legal conclusions, and explanations set forth in the 2 We pro forma affirm the rejection of claims 5–11 under 35 U.S.C. § 112, second paragraph (see Non-Final Act. 2–3), which was not contested by Appellant. See Appeal Br. 7–15. Although the Examiner only identifies claims 5 and 8, claims 6 and 7 depend from claim 5, and claims 9–11 depend from claim 8. For purposes of this Appeal, we treat claims 5–11 together under this rejection. 3 We pro forma affirm the obviousness-type double-patenting rejection, which was not contested by Appellant. 4 Claims 2–7 are not argued separately from claim 1 in Appellant’s brief (Appeal Br. 7–15), and will not be separately addressed. Claims 9 and 10 are not argued separately from claim 8 in Appellant’s brief (id.), and will not be separately addressed. Claims 13–19 are not argued separately from claim 12 in Appellant’s brief (id.), and will not be separately addressed. Appeal 2019-002394 Application 15/083,006 4 Answer in response to Appellant’s arguments. We highlight and address specific findings and arguments for emphasis in our analysis below. Claim 1 Appellant characterizes Friedman as disclosing “first, building a virtual appliance image and then deploying the virtual appliance onto a runtime environment.” Appeal Br. 9 (citing Friedman ¶¶ 18, 38–39). Therefore, Appellant argues, because Friedman discloses “fully configured systems” (Appeal Br. 9, 10; citing Friedman ¶ 104); “a development environment generates a base appliance, (i.e., fully configured application image with JeOS components and other components needed to run the application)” (Appeal Br. 9–10); and images deployed “without any instructions on how [] to configure the runtime environment” (Appeal Br. 10 (emphasis omitted); citing Friedman ¶¶ 76, 129), Friedman does not disclose “a hosting environment that is a runtime environment with APIs to facilitate execution of roles, were, in a service model, a developer specifies roles defining hosting-environment dependencies for implementation of the role on the hosting environment.” Appeal Br. 9 (emphases omitted). Appellant further argues, for similarly outlined reasons, that Friedman fails to disclose the claimed features of “automatically instantiating a subject role of the one or more roles, wherein instantiating comprises: (a) selecting one of the set of base hosting environments based on the definition of the subject role; and (b) refining the selected hosting environment according to map constructs derived from configuration settings of the subject role.” Appeal Br. 10–11; see Claim 1. The Examiner finds that Appellant’s argument cherry-picks embodiments disclosed in Friedman but not relied upon by the Examiner. Appeal 2019-002394 Application 15/083,006 5 Ans. 7. Notably, the Examiner finds, and we agree, that Friedman discloses, per the limitations of claim 1: receiving a service model that specifies definitions of one or more roles of the service application (Non-Final Act. 3; Ans. 4–5; both citing Friedman ¶ 42), wherein the one or more roles include hosting-environment dependencies for implementation on the hosting environment (Non-Final Act. 3–4; Ans. 4–6; both citing Friedman ¶¶ 44, 60, 84, 108), wherein the hosting environment is a runtime environment comprising Application Programming Interfaces (APIs) that facilitate execution of the one or more roles (Non-Final Act. 4; Ans. 4–6; both citing Friedman ¶¶ 7, 19, 70, 75, 88–89). Furthermore, we find Appellant’s arguments about Friedman to be unpersuasive because “a developer specifies” the roles (Appeal Br. 9), and “preparing and configuring a hosting environment (i.e., runtime environment) of a node, based on definitions of a role” (Appeal Br. 11; citing Spec. ¶¶ 49–50) (emphases added), are not commensurate with the scope of the claims. See Ans. 6, 8–9. Although claim terms are interpreted in light of the specification, we do not read limitations from the specification into the claims. See Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571–72 (Fed. Cir. 1988), cert. denied, 488 U.S. 892 (1988) (various limitations on which appellant relied were not stated in the claims; the specification did not provide evidence indicating these limitations must be read into the claims to give meaning to the disputed terms); see also In re Am. Acad. Of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). In addition, proper claim construction requires a broadest reasonable interpretation consistent with the specification. In re Bond, 910 F.2d 831, 833 (Fed. Cir. 1990); see also Phillips v. AWH Corp., 415 F.3d 1303, 1317 Appeal 2019-002394 Application 15/083,006 6 (Fed. Cir. 2005). Furthermore, a preamble is generally not accorded any patentable weight where it merely recites the purpose of a process or the intended use of a structure, and where the body of the claim does not depend on the preamble for completeness but, instead, the process steps or structural limitations are able to stand alone. See In re Hirao, 535 F.2d 67, 190 USPQ 15 (CCPA 1976); Kropa v. Robie, 187 F.2d 150, 152, 88 USPQ 478, 481 (CCPA 1951). Here, claim 1 does not recite a developer, preparing a hosting environment, or a node. See Claim 1; see also Ans. 6, 8–9. Moreover, the limitation “configuring a hosting environment of a data center based on a definition of a subject role of a service application,” appears in the preamble of Claim 1, merely recites the purpose of the claimed process, and is not relied upon in the body of the claim for completeness. Regarding the “automatically instantiating . . .” limitations, we agree with the Examiner’s finding that Friedman discloses those disputed limitations in paragraphs 42, 44, and 60. Non-Final Act. 4; Ans. 8–10. For example, paragraph 42 of Friedman discloses: In one implementation, the development interface may further provide the user with an option to import a predefined configuration file, wherein the development environment 130 may be configured to create the base appliance from the imported configuration file. For example, in one implementation, the development environment 130 may be capable of importing and parsing configuration files associated with any suitable image creation system, wherein the configuration files generally include an image description for an appliance (i.e., name, author, contact information, description, and-version), a definition of users, groups, or other identity management settings for the appliance, a definition of repositories and packages included in the appliance, and a Appeal 2019-002394 Application 15/083,006 7 directory structure for the appliance image. Thus, in response to the user importing a configuration file, the development environment 130 may parse the configuration file, create the base appliance from the configuration file, and then load the base appliance for further development within the user interface 125. For example, in one implementation, the development environment 130 may be configured to import configuration files defined in accordance with an image creation system. Friedman ¶ 42 (emphases added). Paragraph 60 further discloses: Thus, when a user adds a particular package to the appliance, the dependency resolution service 140 may identify any other packages or components that the package may require, wherein the required packages or components may be added to the appliance automatically (e.g., in response to the user adding a server package, one or more packages needed to authenticate users, manage a file system, or perform other tasks to properly operate the server may be added to the appliance automatically). Further, the dependency resolution service 140 may identify any packages already added to the appliance that conflict with the added package, wherein the conflicting packages may be removed from the appliance to resolve the conflict. . . . Alternatively (or additionally), the development environment 130 may be configured to automatically add the recommended and/or suggested packages and enable the user to determine whether or not to remove the recommended and/or suggested packages that were automatically added. Friedman ¶ 60 (emphasis added). In other words, Friedman discloses automatically creating a base appliance from a predetermined configuration file; the development interface capable of importing and parsing the configuration file, and creating and loading the base appliance; and automatically adding other packages or components, depending on the base appliance that is selected. Id. at ¶¶ 42, 60. Appeal 2019-002394 Application 15/083,006 8 Accordingly, based on the above, supported by a preponderance of the evidence, we determine that the Examiner did not err in finding that Friedman discloses the disputed limitations of claim 1, as they are interpreted under the broadest reasonable construction consistent with Appellant’s Specification. Non-Final Act. 3–4; Ans. 3–10. Appellant’s arguments regarding independent claims 12 and 20 refer to the arguments presented for claim 1. Appeal Br. 12. Therefore, we sustain the Examiner’s rejections of claims 1–7 and 12–20 as being anticipated by Friedman. Claim 8 Appellant contends Friedman does not anticipate claim 8, because the Examiner has not identified how Friedman discloses “communication paths between a placed subject role and instantiated instances of one or more roles,” as recited in claim 8. Appeal Br. 13 (emphasis omitted). The Examiner finds, and we agree, that Friedman discloses the disputed limitations of claim 8: Friedman discloses images that are created are deployed to a suitable environment capable of loading and executing the images (at least paragraph 76, 126-129). Friedman also discloses the APIs being used to extend the functionality of the appliance, where the APIs provide and integrate the connections to remotely hosted applications (one or more roles) or locally hosted plug-ins (communication path being remote or local) and the subject role (appliance providing software component/functionality) (at least paragraph 88, Fig. 3a-c). Ans. 10–11. In view of the Examiner’s findings and a preponderance of the evidence, Appellant’s arguments are unpersuasive to show that the Examiner Appeal 2019-002394 Application 15/083,006 9 erred in rejecting claim 8, and claims 9–11 depending therefrom. Accordingly, we sustain the Examiner’s anticipation rejection of claims 8–11. Claim 11 Appellant argues that Friedman does not anticipate claim 11, because Friedman does not disclose “a level of security that corresponds with a degree of spatial isolation of the refined hosting environment from other hosting environments installed in a data center.” Appeal Br. 14 (emphasis omitted). In particular, Appellant contends that the disclosure in Friedman of “having a third-party application and client device communicating in a manner that is isolated from a virtualization environment,” does not anticipate the disputed limitation. Id. The Examiner finds, applying a broad but reasonable interpretation of “spatial isolation” in view of Appellant’s Specification (Ans. 11; citing Spec. ¶ 52), Friedman discloses the disputed limitation. Ans. 11. We note the Specification does not disclose the term “spatial.” See, generally, Spec. Notably, the Examiner finds, and we agree, that Friedman discloses third- party applications having validated tokens, i.e., a level of security, that are isolated from a virtualization environment to ensure accuracy of builds. Id.; citing Friedman ¶¶ 93–94. The Examiner further finds, and we agree, Friedman discloses the virtualization environment as being a separate, independent machine similar to a separate piece of hardware. Ans. 11; see also Friedman ¶ 3 (“For example, in a virtualized system, different virtual machines can execute different operating systems and/or applications on the same physical machine” (emphasis added)). Appeal 2019-002394 Application 15/083,006 10 Based on the foregoing reasons and a preponderance of the evidence, Appellant’s arguments are unpersuasive to demonstrate Examiner error in rejecting claim 11 as being anticipated by Friedman. We note that no Reply Brief is of record to rebut the Examiner’s responses to Appellant’s arguments. Accordingly, we sustain the Examiner’s rejections of claims 1–20 under 35 U.S.C. § 102(e). CONCLUSION We pro forma affirm the Examiner’s rejection of claim 5–11 under 35 U.S.C. § 112, second paragraph, as being indefinite. We pro forma affirm the Examiner’s rejection of claims 1–20 under the obviousness-type double patenting doctrine. We affirm the Examiner’s rejection of claims1–20 as being anticipated under 35 U.S.C. § 102(e). DECISION SUMMARY Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 5–11 112, ¶ 2 Indefiniteness 5–11 1–20 Non-statutory OTDP 1–20 1–20 102(e) Friedman 1–20 Overall Outcome 1–20 Appeal 2019-002394 Application 15/083,006 11 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. § 41.50(f). AFFIRMED Copy with citationCopy as parenthetical citation