VMware, Inc.

Patent Trials and Appeals Board

Feb 8, 2022

2021000320 (P.T.A.B. Feb. 8, 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/685,299 08/24/2017 Eugene Liderman D685.02 (500104-1860) 4928 152577 7590 02/08/2022 Thomas | Horstemeyer, LLP (VMW) 3200 Windy Hill Road, SE Suite 1600E Atlanta, GA 30339 EXAMINER LE, CANH ART UNIT PAPER NUMBER 2439 NOTIFICATION DATE DELIVERY MODE 02/08/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): docketing@thomashorstemeyer.com ipadmin@vmware.com uspatents@thomashorstemeyer.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte EUGENE LIDERMAN, JONATHON DERISO, WILLIAM THOMAS HOOPER, SAGAR DATE, TEJAS MEHROTRA, STEPHEN TURNER, AMOGH DATAR, and DIPANSHU GUOTA Appeal 2021-000320 Application 15/685,299 Technology Center 2400 BEFORE ALLEN R. MACDONALD, MINN CHUNG, and CHRISTA P. ZADO, 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-20, all the claims pending in the present application. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM. 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. 2. Appeal 2021-000320 Application 15/685,299 2 CLAIMED SUBJECT MATTER The instant application relates to distributed profile and key management for network security and enrolled device management. Spec. ¶ 17. Claim 1, reproduced below with claim language at issue italicized, illustrates the claimed subject matter: 1. A system for distributed profile and key management, comprising: a client device; and program instructions executable in the client device that, when executed by the client device, cause the client device to: receive, by a first client application of the client device, a partially populated device profile, the partially populated device profile generated by a management service remotely located from the client device to configure at least one setting on the client device; authenticate, by a second client application of the client device, the client device through communication with a third-party security service; in response to the client device being authenticated, generate, by the second client application, a credential; provide, by the second client application, the credential to the first client application; modify, by the first client application, the partially populated device profile to include the credential to create a fully populated device profile; and cause, by the first client application, the client device to be configured in accordance with the fully populated device profile. Appeal Br. 18 (Claims App.). Appeal 2021-000320 Application 15/685,299 3 REFERENCES The prior art relied upon by the Examiner is: Name Reference Date Mistry US 2017/0094509 A1 Mar. 30, 2017 Rodgers US 9,686,278 B1 June 20, 2017 Rykowski US 10,122,577 B1 Nov. 6, 2018 “Entrust,” Mobile Derived PIV/CAC Credential-A Complete Solution For NIST 800-157, pp. 1-15 (Nov. 15, 2014). REJECTIONS The claims stand rejected as follows: Claims Rejected 35 U.S.C. § References 1, 2, 5-9, 12- 16, 19, 20 103 Rykowski, Entrust 3, 4, 10, 11, 17, 18 103 Rykowski, Entrust, Mistry, Rodgers OPINION Background The Specification explains that the emergence of bring-your-own- device (BYOD) technology in the workplace permits employees to use their own personal devices, such as mobile phones, to access enterprise data including email and corporate documents. Spec. ¶ 3. However, use of personal devices raises security issues, namely that system administrators need to ensure that only authorized devices have access to enterprise data. Id. As a result, employees must enroll with a management service and must authenticate their devices prior to their devices being granted access to Appeal 2021-000320 Application 15/685,299 4 enterprise data. Id. On method of authenticating a device involves using, e.g., a Personal Identity Verification (PIV) card, or other physical security card, wherein data read from the card is pushed from the device to a server so that the server may verify the device’s authenticity. Id. ¶ 17. However, numerous devices, such as mobile phones, do not have a card reader. Id. As a result, the National Institute of Standards and Technology (NIST) has established a protocol that allows for use of a “derived credential” in lieu of using a physical security card. Id. ¶¶ 17, 21. For example, pre-enrolled users may provide certain security information to, e.g., a management server, wherein the management server uses such information to generate a derived credential that is pushed out to the mobile device. Id. According to the Specification, the management server, for security reasons, does not keep copies of the credentials it derives for devices it serves, because centrally locating such information would leave vulnerable the credentials of potentially thousands of employees in a management server attack. Id. ¶ 44. The derived credential, also referred to in the Specification as a certificate, is used, inter alia, in conjunction with encryption keys. Spec. ¶¶ 23, 45. A private/public key pair is a set of asymmetric keys that are used to ensure data transmissions are secure. Because communications across networks such as the Internet can be sniffed (i.e., intercepted and viewed by others), encrypting such data provides additional security. A widely-used form of encryption uses a private/public key pair. Data is encrypted using a public key prior to transmission, but may only be decrypted using a different, private key. In this manner, the public key may be widely distributed because even if it is compromised, data encrypted with it is still secure. When a mobile device sends its public key to a server for encrypting Appeal 2021-000320 Application 15/685,299 5 enterprise data to be sent to the device, the server requires the key to be accompanied by a public certificate so that the server knows the public key is from a trusted source. In order to access enterprise data, devices must have a device profile (typically generated by a server) that specifies, e.g., a public certificate, as well as information necessary to configure device settings on the mobile device. Spec. ¶ 44. According to the Specification, an issue arises with regard to devices using certain operating systems such as Android or iOS. Namely, each application on the device (e.g., email, text, voicemail) is sandboxed such that a separate device profile is required for each application that seeks to access enterprise data. Id.. Because each profile must include a public certificate, and because the management server does not store a copy of the certificate (discussed above), the management server in traditional systems must generate a public certificate for each device profile for a mobile device, according to the Specification. Id. ¶¶ 44-47. The Specification, therefore, proposes a management server that, rather than generate certificate information for each device profile, creates a partial profile for each application that includes device configuration information but excludes certificate information. Id.. The partial device profiles are pushed to the mobile device. Id.. The mobile device, via an application, inserts the derived credentials into the partially populated device profiles to create fully populated device profiles. Id. ¶ 46. With the concept of a partial device profile in mind, we note that claim 1 recites, in pertinent part, a client device with executable program instructions that cause a first application on the client device to receive a partially populated device profile and modify the partially populated device Appeal 2021-000320 Application 15/685,299 6 profile to include a credential in order to create a fully populated device profile. Appeal Br. 18 (Claims App.) Discussion Appellant argues the Examiner has not shown that the combination of Rykowski and Entrust teaches or suggests the following limitation of claim 1 (and identical limitations of claims 8 and 15): “modify, by the first client application, the partially populated device profile to include the credential to create a fully populated device profile.” Appeal Br. 10-15. Appellant submits, therefore, that we should reverse the Examiner’s rejections of claims 1, 8, and 15, and all claims depending therefrom. Id. at 10-16. For reasons that follow, we affirm the Examiner’s rejections. Our discussion refers explicitly to the Examiner’s findings and conclusions regarding claim 1, but applies equally to claims 8 and 15. The Examiner finds that Rykowski teaches a partially populated device profile as follows. Rykowski, like the present application, relates to BYOD technology in the workplace, and more specifically, to generation of operating system profiles for devices. Rykowski 1:25-34, 2:37-38. Rykowski explains that different devices, such as smartphones, tablets, and personal computers, each operate using different operating systems having different features, capabilities, and restrictions. Id. at 2:39-46. According to Rykowski, certain features are common to all operating systems, whereas other features apply only to specific operating systems. Id. at 3:19-27. The Examiner finds that Rykowski’s initial operating system profile, which includes common features but not operating system specific features, teaches a “partially populated device profile,” as recited in claim 1. Final Act. 11- Appeal 2021-000320 Application 15/685,299 7 12 (citing Rykowski 3:19-26, 5:23-32, 5:45-6:9, Fig. 3). The Examiner further finds that Rykowski teaches modifying the partially populated device profile to create a fully populated device profile because it discloses inserting advanced settings specific to a particular operating system into the asserted partially populated device profile. Id. at 12 (citing Rykowski 5:39- 44). The Examiner acknowledges that Rykowski does not explicitly refer to inserting a “credential” into the partially populated device profile, as recited in claim 1. Id. at 12-13. However, the Examiner finds that Entrust provides the missing disclosure. Final Act. 13-15 (citing Entrust 7-8). Entrust describes a product called IdentityGaurd Mobile Identity Smart Credential solution. See, e.g., Entrust 6. Entrust relates to deriving credentials for use by mobile platforms. See id. at 4 (“With the publication of FIPS 201-2, the ability to place an HSPD-12-compliant credential onto a mobile platform became permissible as defined by the NIST Special Publication 800-157”). Entrust describes a derived credential enrollment process in which a user requests a derived credential by navigating a Web browser on a computer and establishing a trust relationship by having the workstation read a PIV card and sending the data to a server. Id. at 7. The server that receives the request validates the data, and if valid, issues a link to activate the derived credential. Id. The activation information may be delivered in a variety of ways including, e.g., it may be encoded in a QR code that is displayed on the Web browser along with a password. Id. The user then opens the Entrust Mobile Smart Credential Application on their mobile device, captures the QR code, and enters the password. Id. This decrypts the information in the Appeal 2021-000320 Application 15/685,299 8 QR code, allowing the user to generate and activate their derived PIV credential. Id. The Examiner finds the claimed invention would have been obvious in view of Rykowski and Entrust in order to provide mobile device users with means to easily self-manage their devices by using Entrust’s Smart Credential Application (i.e., by requesting and being issued a derived credential), and it would have been obvious to have an application on the mobile device use such credential to fully populate the operating system profile of Rykowski. Final Act. 14-15 (citing Entrust 7-8). Appellant disagrees with the Examiner’s obviousness conclusion, arguing that both Rykowski’s initial operating system profile (that includes features common to all operating systems) and complete device profile (generated by inserting operating system specific information) are completed by the server. Appeal Br. 13. Accordingly, Rykowski does not disclose a client application on the mobile device modifying the device profile, as required by claim 1, according to Appellant. Id. (arguing that all the manipulation of the device profile is performed at the server). Appellant submits that “generating a complete device profile on a remote [server] [as Rykowski discloses] is not the same thing as generating a partially populated device profile” on the remote server and having the mobile device insert the credential in order to complete the device profile, as claimed. Id. We agree with Appellant that in Rykowski, the advanced operating system settings are configured at the server, rather than at the client. Figure 2 of Rykowski depicts a process map illustrating a process for an administrator at a server to follow when creating a configuration profile for an operating system. Rykowski 5:23-25. Rykowsi states that “the first task Appeal 2021-000320 Application 15/685,299 9 performed by the administrator can include configuring common settings.” Id. at 5:26-28. With regard to the same process (i.e., the process followed by the administrator) Rykowski further states that “after common settings have been specified, the process can include configuring advanced settings that may be unique to a particular operating system.” Id. at 5:39-42. Accordingly, it is the administrator operating on the server who inserts the advanced settings into the profile, not a client application on the mobile device. However, this is not fatal to the Examiner’s obviousness determination. The claims do not require the advanced operating system settings to be inserted into the device profile at the client. Rather, it is the credential that is added at the client. Accordingly, the fact that the advanced settings are inserted at the server, rather than at the client, does not preclude an obviousness finding. Here, the Examiner relies on the combination of Rykowsi and Entrust, rather than on Rykowski alone, to show the limitation at issue. Final Act. 14-15 (“it would have been obvious . . . to combine the teaching of Entrust with the method and system of Rykowski, wherein modify, by the first client application, the partially populated device profile to include the credential to create a fully populated device profile”) (emphasis added). As the Examiner points out, in response to Appellant’s argument that “nothing in Rykowski discusses or hints at modifying a device profile once received by the client. Instead all the manipulation . . . is performed on the remote computing device,” it is the combination of Rykowski and Entrust that teaches the claim limitation at issue. Ans. 6-7. Specifically, as found by the Examiner and discussed above, Rykowski teaches modifying a device profile. Final Act. 12 (citing Appeal 2021-000320 Application 15/685,299 10 Rykowski 5:39-44); Ans. 7. Rykowski provides a rationale to do so, explaining that generating profiles in two stages avoids repeating the process of configuring redundant information across multiple profiles. Rykowski 3:38-55. Also found by the Examiner, and discussed above, Entrust discloses generating a derived credential at the client. Final Act. 13-14 (citing Entrust 7-8); Ans. 7. Entrust provides a rationale to do so, explaining the benefit of deriving a credential at the client, namely to provide users with means to easily self-manage their credentials “directly on the mobile device.” Final Act. 15; Ans. 7; Entrust 5 (stating, “granting users’ access to request and manage their Derived PIV Credentials without the need for administrative interaction” “greatly reduces administrative costs associated with other derived credential solution”). According to the Examiner, it is the combination of Rykowski and Entrust that teaches performing the modification at the client. Final Act. 13-15; Ans. 6-7. The Examiner finds: Rykowski teaches modifying a device profile. Entrust teaches generating a credential at the client device to complete a device profile. The combination of the references teaches modifying a device profile once received by the client device. Ans. 7. As such, Entrust is relied upon, not Rykowski, for teaching inserting a credential into a device profile at the client. In the Reply Brief, Appellant reiterates the argument that Rykowski does not disclose a device profile to be completed at the client, and further argues that Entrust does not disclose generating a partially populated device profile received on a client device and modifying such profile on the client device. Reply Br. 4-7. Appeal 2021-000320 Application 15/685,299 11 In so doing, Appellant attacks the references individually, but still fails to address the combination of the two references. Appellant does not persuasively address the Examiner’s findings regarding the combined teachings of Rykowski and Entrust. The test for obviousness is not whether the claimed invention must be expressly suggested in any one or all of the references. “Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art.” In re Keller, 642 F.2d 413, 425 (CCPA 1981) (citations omitted) (emphasis added). Thus, where, as here, the rejections are based upon the teachings of a combination of references, “[n]on-obviousness cannot be established by attacking references individually.” In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986) (citing Keller, 642 F.2d at 425). In addition, a reference “must be read, not in isolation, but for what it fairly teaches in combination with the prior art as a whole.” Id. For the foregoing reasons, we affirm the Examiner’s rejections of claims 1, 8, and 15, and all pending claims depending therefrom. CONCLUSION The Examiner’s rejections are affirmed. Appeal 2021-000320 Application 15/685,299 12 DECISION SUMMARY In summary: Claim(s) Rejected 35 U.S.C. § References Affirmed Reversed 1, 2, 5-9, 12-16, 19, 20 103 Rykowski, Entrust 1, 2, 5-9, 12-16, 19, 20 3, 4, 10, 11, 17, 18 103 Rykowski, Entrust, Mistry, Rodgers 3, 4, 10, 11, 17, 18 Overall Outcome 1-20 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). See 37 C.F.R. § 1.136(a)(1)(iv) (2019). AFFIRMED