Microsoft Technology Licensing, LLC.

Patent Trials and Appeals BoardMay 19, 2021

2020000437 (P.T.A.B. May. 19, 2021)

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/082,768 03/28/2016 Vitaly KHAIT 346311-US-NP 7028 69316 7590 05/19/2021 MICROSOFT CORPORATION ONE MICROSOFT WAY REDMOND, WA 98052 EXAMINER LESNIEWSKI, VICTOR D ART UNIT PAPER NUMBER 2493 NOTIFICATION DATE DELIVERY MODE 05/19/2021 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): chriochs@microsoft.com jkarr@microsoft.com usdocket@microsoft.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte VITALY KHAIT, AMI LUTTWAK, LIRAN MOYSI, ARIEL STOLOVICH, and GREG VISHNEPOLSKY Appeal 2020-000437 Application 15/082,768 Technology Center 2400 Before MAHSHID D. SAADAT, JOHNNY A. KUMAR, and JUSTIN BUSCH, Administrative Patent Judges. Opinion for the Board filed by Administrative Patent Judge SAADAT. Opinion Dissenting filed by Administrative Patent Judge BUSCH. SAADAT, 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–26. We have jurisdiction under 35 U.S.C. § 6(b). 1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R. § 1.42(a). Appellant identifies the real party in interest as Microsoft Technology Licensing, LLC. Appeal Br. 3. Appeal 2020-000437 Application 15/082,768 2 We REVERSE. CLAIMED SUBJECT MATTER The claims are directed to techniques for secured access control to cloud-based applications by detecting the unauthorized and/or unsecured access to those applications. See Spec. ¶¶ 6–11. Claim 1, reproduced below, illustrates the claimed subject matter: 1. A method for securing an access to a cloud-based application, comprising: receiving, by an authentication proxy device, an authentication token, wherein the authentication token includes an identity of a user of a client device requesting an access to the cloud-based application, wherein the client device is at least an un-managed device, and wherein the authentication proxy device is connected between the unmanaged client device and a cloud computing platform hosting the cloud-based application to be secured, wherein the un-managed client device is not secured by an organization; receiving, from an agent executed in the un-managed client device, a client certificate; retrieving, from a compliance server, a device posture of the un-managed client device, wherein the device posture is retrieved respective of the received client certificate; identifying an access policy, from among a plurality of access polices configured with the authentication proxy device, for the un-managed client device to access the cloud-based application, wherein the access policy is identified based at least on the retrieved device posture; and determining whether to grant an access to the cloud- based application based in part on the compliance of the un- managed client device with the identified access policy. Appeal Br. 21 (Claims Appendix). Appeal 2020-000437 Application 15/082,768 3 REFERENCES and REJECTION The prior art relied upon by the Examiner is: Name Reference Date Khalid US 2015/0188907 A1 July 2, 2015 Leung US 2015/0200969 A1 July 16, 2015 The Examiner rejected claims 1–26 under 35 U.S.C. § 103 as unpatentable over Leung and Khalid. Final Act. 2–11. OPINION We have reviewed the Examiner’s rejection in light of Appellant’s contentions in the Appeal Brief and the Reply Brief that the Examiner has erred, as well as the Examiner’s response to Appellant’s arguments in the Appeal Brief. As discussed below, we are persuaded by Appellant’s contentions of Examiner error. For the recited steps of “receiving, by an authentication proxy device, . . ., wherein the un-managed client device is not secured by an organization,” “receiving, from an agent executed in the un-managed client device, a client certificate,” “retrieving, . . ., a device posture of the un- managed client device,” and “determining whether to grant an access to the cloud-based application” limitations of claim 1, the Examiner relies on Leung’s disclosure of the user of a client device requesting access to the cloud-based applications of an enterprise-secured network. Final Act. 3 (citing Leung Abs., ¶¶ 27, 29, 38, 41, 42, 47, 51). The Examiner further finds “using user authentication tokens when accessing network resources was well known in the art as evidenced by Khalid.” Final Act. 4 (citing Khalid ¶ 38 (“SSO authentication token”)). The Examiner concludes “[o]ne Appeal 2020-000437 Application 15/082,768 4 of ordinary skill in the art would have recognized the benefit that utilizing SSO would allow authentication of a user without requiring the user to re- enter a username and password combination multiple times.” Id. (citing Khalid ¶ 1). The Examiner specifically maps the recited “client certificate” that is received from an agent executed in the un-managed client device to the disclosure of “HIP report” of Leung. Final Act. 3 (citing Leung ¶ 42). Appellant contends the Examiner erred in finding Leung or the proposed combination teaches or suggests an “unauthorized client device” that includes both “an agent” and/or “client certificate,” as required by claim 1. Appeal Br. 9. Appellant also contends the cited portions of Leung related to “security cloud service” and “HIP related information” do not disclose the recited “retrieving, from a compliance server, a device posture of the un- managed client device, wherein the device posture is retrieved respective of the received client certificate.” Appeal Br. 7–11. According to Appellant, the Examiner’s mapping of “the claimed ‘compliance server’ to Leung’s ‘security cloud service’ and the claimed ‘device posture’ to Leung’s ‘host information profile (HIP)’” is erroneous because paragraph 47 of Leung discloses “retrieving HIP related information, and not the actual HIP” which is “an important distinction, as Leung’s method requires the client device to retrieve the HIP.” Id. at 10–11 (citing Leung, Abs. (“receiving a host information profile report from a client device”), ¶ 27 (“the term host information profile (e.g., or HIP profile) refers to administration configured device profiles that can be used to match against HIP reports received from one or more client devices”), ¶ 47). Appellant also argues that, based on this mapping, “Leung does not teach a method of retrieving the HIP from the cloud service, but rather from the client device” and therefore, “does not Appeal 2020-000437 Application 15/082,768 5 teach the claimed feature of “retrieving, from a compliance server, a device posture of the un-managed client device’.” Appeal Br. 11. 2 In response, the Examiner reiterates the findings with respect to Leung’s disclosure of using “a personal device” as an unauthorized device compared to using “a corporate/enterprise device” as an authorized device and maps the recited “un-managed client device” to Leung’s “personal device.” Ans. 4. The Examiner adds that the disclosed “HIP report” in paragraph 42 of Leung meets the recited “client certificate” that is received from an agent in the un-managed device. Id. at 5. The Examiner explains: The rejection cites Leung, paragraph 42, which shows that a HIP report is provided from the client device. The HIP report is seen to meet the limitation of the claimed “client certificate”. The client necessarily requires some software operating on it in order to provide the HIP report to the gateway, but Leung is even more explicit, using the same “agent” terminology as the claim language. See, inter alia, paragraphs 28, 34, and 48-50. Leung, paragraph 51, already cited in the rejection, explicitly states that “the client device agent” sends the HIP report to the gateway. Id. The Examiner refers to Leung’s paragraph 47 as showing “the use of a security cloud service in providing profile information” (Ans. 5–6) and explains: This is seen to meet the limitation at hand as Leung’s HIP profiles are “administration configured device profiles that can be used to match against HIP reports”. See again, paragraph 27. The HIP profile is considered to be “retrieved respective of 2 Appellant presents additional arguments regarding the failure of the proposed combination to teach or suggest other recited limitations of claim 1 and other independent claims, which are not addressed here because the above discussed arguments are dispositive of the issue on appeal. See Appeal Br. 12–19. Appeal 2020-000437 Application 15/082,768 6 the received client certificate” as the HIP profile to be used is determined via the matching process. Paragraph 27 states “Any HIP report received by gateway can be compared with all HIP profiles to see which (if any) HIP profiles match such HIP reports”. Thus, the appropriate HIP profile is returned and utilized for policy enforcement. . . . In the brief, the appellant argues that “Leung’s method requires the client device to retrieve the HIP”. However, the appellant fails to make any distinction between the HIP report and the HIP profile, two very different things. It is agreed that the HIP report is received from the client device, but the rejection aligns Leung’s HIP report to the claimed “client certificate” NOT to the claimed “device posture”, as the appellant has argued. Id. at 6. Based on our review of the references, we are persuaded by Appellant’s arguments. Although Leung’s disclosure identifies authorized corporate/enterprise client devices and unauthorized client devices (such as personal or home computer, or personal tablet or phone), the Examiner does not identify any teachings in Leung related to “receiving, from an agent executed in the un-managed client device, a client certificate” and “retrieving, from a compliance server, a device posture of the un-managed client device, wherein the device posture is retrieved respective of the received client certificate.” Instead, the Examiner cited Leung’s teaching of the HIP reports received from one or more client devices as the claimed “client certificate.” Final Act. 3; Ans. 5. Claim 1 recites “an authentication proxy device” that receives a token and allows/denies access to a client device if the client device posture complies with the access policy of the cloud-based application. According Appeal 2020-000437 Application 15/082,768 7 to the claim, the client device posture is retrieved from a compliance server based on the client certificate. Appellant’s disclosure describes the authentication proxy device as the entity that controls and enforces access to the cloud-based application (see figure 2, element 120; Spec. ¶¶ 28, 38, 39) and the compliance server that retrieves a device posture “respective of the retrieved client certificate” as follows: The compliance server 150 is configured to gather and maintain for each client device 130 a device posture. . . . In one embodiment, the device posture includes a unique device certificate associated with the respective client device and a set of compliance parameters. The compliance parameters of each client device 130 are associated with a unique client certificate and can be stored locally in the compliance server 150 or in a database (not shown) connected to the server 150. The gathering of compliance parameters is facilitated using an agent 131. Spec. ¶ 27. Appellant’s disclosure further describes the functions of the authentication proxy device and the compliance server by stating “[t]he authentication proxy 120 is further configured to query the compliance server 150 using the client certificate to retrieve at least the device posture.” Spec. ¶ 51. In other words, a client device certificate, that is specific to each client device, is needed for corresponding each client device with its stored compliance parameters included in the device posture. Therefore, the recited “retrieving, from a compliance server, a device posture of the un- managed client device” requires the compliance server, first to identify the device posture specific to a client device which was gathered and maintained based on that client’s certificate, and then to provide it to the authentication proxy device to be checked for compliance with the system access policy. See Appeal Br. 11–12. Appeal 2020-000437 Application 15/082,768 8 The Examiner’s cited portions of Leung, although related to policy enforcement based on the device profile obtained from a client device, do not disclose a compliance server where a device posture of the un-managed client device is retrieved based on the client certificate. Based on the Examiner’s mapping of the recited compliance server to Leung’s “cloud security service” and mapping of the recited client certificate to Leung’s “HIP report,” Leung does not disclose that the device posture is retrieved from the cloud security service respective of the HIP report. Leung describes that security gateway 202 communicates with cloud security service 210 (the compliance server according to the Examiner) to receive security related content or HIP report information, but not whether a client device posture or any HIP reports (the client certificate according to the Examiner) are retrieved from the cloud security service. See Leung ¶ 47. As argued by Appellant, Leung receives the HIP reports, or any device parameters included therewith, from the client devices instead of security cloud service 210 or the compliance server. See Appeal. Br. 10–11. We therefore agree with Appellant that Leung’s HIP report from each client device does not meet the recited client certificate because the HIP report is provided directly from the client device to Leung’s security gateway 202, instead of from a compliance server, which corresponds the device posture to the specific device based on the received device certificate. See Leung ¶ 42; Ans. 5. We therefore agree with Appellant that neither Leung’s HIP report, nor any information obtained from security cloud service 210 meets the recited client certificate because “[a] client certificate is associated with a particular client device and received from the client device” and “is unique for the device.” See Reply Br. 4 (citing Spec. ¶¶ 27, 50). Even if an Appeal 2020-000437 Application 15/082,768 9 unauthorized device can be characterized as the recited “un-managed client device,” or HIP reports are specific to clients, we agree with Appellant’s argument that the Examiner’s findings in the Final Action and the Answer are insufficient to establish Leung’s providing the host information profile (HIP) report teaches or suggests the steps of receiving client certificate and retrieving, by a compliance server, a device posture related to the received client certificate, as recited in claim 1. See also Spec. ¶ 27 (stating “the device posture includes a unique device certificate associated with the respective client device and a set of compliance parameters”) and ¶ 49 (stating “the client certificate is a unique identifier of each client device”). Hence, the rejection involves speculation as to how the HIP report of Leung, that is used to enforce the security policy for network access, meets the recited client certificate in claim 1, whereas a certificate is unique to the client device and is used to retrieve the specific device posture from a compliance server. See Reply Br. 4. CONCLUSION In view of the above analysis, we are persuaded by Appellant’s contentions that combining the references, even if properly combined, does not teach or suggest the disputed limitations. Therefore, on the record before us, we are constrained to conclude the Examiner erred in rejecting claim 1 and independent claims 14 and 26, which recite similar limitations, as obvious. Accordingly, we do not sustain the obviousness rejection of independent claims 1, 14, and 26, as well as claims 2–13 and 15–25, dependent therefrom, over Leung and Khalid. Appeal 2020-000437 Application 15/082,768 10 DECISION SUMMARY In summary: Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1–26 103 Leung, Khalid 1–26 REVERSED Appeal 2020-000437 Application 15/082,768 11 BUSCH, Administrative Patent Judge, dissenting. I respectfully dissent from my colleagues’ decision to reverse the rejection of claims 1–16 under 35 U.S.C. § 103 as obvious over Leung and Khalid. I write separately because I agree with the Examiner that the claims would have been obvious over Leung and Khalid when the disputed limitations are construed according to the broadest reasonable interpretation. Briefly, I first address Appellant’s two assertions not addressed in the Majority Opinion.3 Appellant first argues that Leung does not teach an “un- managed client device [that] is not secured by an organization.” Appeal Br. 8–10; Reply Br. 2–3. I disagree with Appellant’s assertion essentially for the reasons explained by the Examiner. See Ans. 4–5 (citing Leung ¶¶ 42, 51; Spec. ¶ 31). Leung discloses a gateway enforcing access policies based at least in part on host information profile (“HIP”) reports that client devices send to the gateway. Leung ¶ 42; see also Leung ¶¶ 38 (“a gateway for policy enforcement using host profile information”), 48 (describing each client device including an agent for providing HIP reports), 49 (“agents on client devices report new or updated HIP reports to the gateway”), 51 (disclosing the gateway may use the application, user name, and HIP report to determine whether to allow access). Leung further discloses that the HIP report may include information that allows that the gateway to distinguish between “an authorized corporate/enterprise client device” and “an 3 Because the Majority Opinion reverses the rejection, that opinion did not need to address Appellant’s alternative patentability arguments. However, because I conclude that the claims would have been obvious, I briefly address each of Appellant’s arguments. Appeal 2020-000437 Application 15/082,768 12 unauthorized client device (e.g., personal home computer, personal table[t], or personal smart phone).” Leung ¶ 51 (emphases added). This distinction between authorized corporate/enterprise client devices and unauthorized personal devices and the disclosed ability to apply different security policies based on such a distinction at least suggests that a personal device is an “un- managed client device.” These disclosures also teach that the client devices accessing the gateway, whether corporate or personal, include the recited agents and communicate with the gateway as recited. Appellant also contends that, even if combined, Leung and Khalid do not teach or suggest an authentication proxy device receiving an authentication token. Appeal Br. 12–13. More specifically, Appellant argues claim 1 recites that the proxy device is connected between the client device and a platform hosting an application to be secured, whereas the proposed combination “would result in providing the authentication to be secured to the application, and not to an authentication proxy as required by Claim 1.” Appeal Br. 13. As the Examiner notes, however, Appellant’s argument does not consider the combination as articulated. See Ans. 6–7. In particular, the Examiner finds Leung discloses a gateway that teaches the recited authentication proxy device and Khalid is just added to teach passing a token in a single sign-on (SSO) authentication system. Ans. 7; Final Act. 4 (citing Khalid ¶ 38). The Examiner further explains, and I agree, that a person of ordinary skill in the art would have understood that the authentication token would be passed to the device performing the authentication (i.e., Leung’s gateway). Ans. 7. Furthermore, Leung teaches using the gateway to secure access to cloud-based services, as recited in claim 1. Leung ¶ 45. Appeal 2020-000437 Application 15/082,768 13 To the extent Appellant argues that claim 1 requires securing access to the authentication proxy server, I disagree. Rather, claim 1 requires securing access to the cloud-based application. Compare Appeal Br. 13 (arguing that the proposed combination “provid[es] the authentication [token] to be secured to the application, and not to an authentication proxy”), with Appeal Br. 21 (“the authentication proxy device is connected between the unmanaged client device and a cloud computing platform hosting the cloud-based application to be secured” (emphasis added)) and Spec. ¶ 11 (“providing secured access control to cloud-based applications”). For the above reasons, I agree with the Examiner that the combination of Leung and Khalid teaches the receiving an authentication token step. Finally, with respect to representative claim 1, Appellant argues Leung does not teach or suggest receiving a client certificate from the client device then retrieving a device posture from a compliance server, “wherein the device posture is retrieved respective of the received client certificate.” Appeal Br. 10–12; Reply Br. 3–4. This argument is the basis on which the Majority Decision reverses the rejection. Claim 1 recites three devices—an “authentication proxy device,” an “un-managed client device . . . not secured by an organization,” and a “compliance server.” Appeal Br. 21. Claim 1 further recites receiving, retrieving, or identifying four different data elements or data structures—an “authentication token” received by the authentication proxy device and including the identity of a user of the client device, a “client certificate” received from an agent on the client device, a “device posture of the un- managed client device” retrieved from the compliance server “respective of Appeal 2020-000437 Application 15/082,768 14 the received client certificate,” and an “access policy” for the client device identified based on the device posture. Appeal Br. 21. Figure 1, reproduced below, depicts the claimed architecture: Spec., Fig. 1 (network diagram depicting the claimed client devices, authentication proxy server, and compliance server). An exemplary architecture of Leung’s system is depicted in Figure 2, reproduced below: Leung, Fig. 2 (block diagram depicting a policy enforcement architecture). Appeal 2020-000437 Application 15/082,768 15 Leung discloses that client devices 204 may access services provided by servers 208, such as cloud-based services, via the Internet. Leung ¶ 45. Leung further discloses that the gateway may encore access “policies based on the client device specific information,” such as whether “a client device is executing up to date security software,” using host profile information or a host information profile (“HIP”). See Leung ¶¶ 26–27. “[F]rom the gateway/appliance side, the term host information profile (e.g., or HIP profile) refers to administration configured device profiles that can be used to match against HIP reports received from one or more client devices.” Leung ¶ 27. By matching a HIP report to one or more HIP profiles,4 the gateway can determine which security access rules to apply to the client device that sent the particular HIP report. Leung ¶ 27. Leung further discloses embodiments in which “the various network security functions for policy enforcement using host information profile techniques as described herein . . . are implemented in part in security device 202 and in part using a cloud-based security service 210.” Leung ¶ 46. One particularly relevant example to which the Examiner cites describes gateway 202 communicating with security cloud service 210 to provide “HIP report information for the client device . . . and possibly user identification and/or application identification information” so security cloud service 210 can perform analysis. Leung ¶ 47. Leung also discloses that “some or all of the functions described above with respect to FIG. 1 [(such as matching HIP reports to identify one or more HIP profiles, see Leung ¶ 42)] can be assisted 4 Although the phrase “HIP [(host information profile)] profile” seems redundant, I use the term herein consistent with the use in Leung. Appeal 2020-000437 Application 15/082,768 16 by or implemented in whole or in part by the security cloud service.” Leung ¶ 47. Leung discloses that the HIP report “is generally a report that includes various information about a device” that is sent from the client device to the gateway and may include “information indicating the type of device, including certain hardware information . . . and also generally includes certain information regarding software installed on the device.” Leung ¶ 27. Figures 8 and 9 depict exemplary XML-formatted HIP reports. Leung ¶¶ 12–13, 67–68. Each exemplary HIP report includes information specific to the client sending the HIP report (e.g., the report in Figure 8 is from a client that does not have antivirus software whereas the report in Figure 9 is from a client that has antivirus software installed and enabled). Leung ¶¶ 67–68. Also of note, Leung’s exemplary HIP reports include host names, IP addresses and MAC addresses. See Leung, Figs. 8, 9. As discussed above, the Examiner finds the combination of Leung and Khalid’s SSO system teaches the details regarding receiving and using an authentication token to secure access to a cloud-based application. See Final Act. 3–4 (citing Khalid ¶ 38); Ans. 7. The Examiner finds Leung’s gateway 202, clients 204, and cloud security service 210 teach the recited authentication proxy server, un-managed client device, and compliance server, respectively. Final Act. 3 citing Leung ¶ 47); Ans. 4 (“Thus, the unauthorized device is seen to be ‘un-managed’ as it is a personal device as opposed to a corporate/enterprise device, which would, by definition, be enabled by the corporation or enterprise of which it is a part.”), 6 (finding Leung’s “use of a security cloud service in providing profile information” teaches or suggests retrieving a device posture from a compliance server), 7 Appeal 2020-000437 Application 15/082,768 17 (“Leung already teaches a gateway that represents the claimed ‘authentication proxy device’.”). The Examiner finds Leung’s HIP report and HIP profile teach the recited client certificate and device posture, respectively. See Final Act. 3 (finding “paragraph 42 [of Leung], HIP report” teaches receiving a client certificate and “paragraph 27 [of Leung], matching HIP profile, and paragraph 47, security cloud service” teaches retrieving a device posture from a compliance server); Ans. 5 (“The HIP report is seen to meet the limitation of the claimed ‘client certificate’.”), 6. The Examiner explains that Leung’s HIP profiles teach the device posture because they are “administration configured device profiles that can be used to match against HIP reports.” Ans. 6 (quoting Leung ¶ 27). Appellant asserts Leung’s security cloud service does not teach the claimed compliance server and Leung’s HIP does not teach the claimed device posture because Leung discloses “retrieving HIP related information, and not the actual HIP” whereas “Leung’s method requires the client device to retrieve the HIP.” Appeal Br. 10–11 (citing Leung, ¶¶ 27, 47, Abstract). Appellant also argues that Leung, therefore, “does not teach a method for retrieving the HIP from the cloud service, but rather from the client device” not from a compliance server. Appeal Br. 11. I disagree with Appellant’s understanding of Leung’s teachings and the Examiner’s findings. As the Examiner pointed out, Appellant appears to confuse Leung’s distinction between a HIP report and a HIP profile. See Ans. 6 (“[T]he appellant fails to make any distinction between the HIP report and the HIP profile, two very different things.”). The Examiner agrees with Appellant, as do I, that Leung teaches receiving the HIP report from the client device. Appeal 2020-000437 Application 15/082,768 18 The Examiner finds the HIP report teaches the client certificate. Accordingly, receiving the HIP report (i.e., the element the Examiner finds teaches the client certificate) from the client device teaches “receiving, from an agent executed in the un-managed client device, a client certificate.” Appeal Br. 21. The Examiner finds the HIP profile, which is managed on the gateway side, teaches the device posture. Final Act. 3; Ans. 5–6. The Examiner finds Leung discloses that the gateway may retrieve this HIP related information from the cloud security service. As noted above, Leung discloses that any of the various security policy functions may be performed by cloud security service 210. See Leung ¶¶ 27, 42, 46–47. Accordingly, Leung’s disclosure that the gateway (mapped to the authentication proxy server) retrieves the HIP profile (i.e., the HIP related information) from the cloud security service (mapped to the compliance server) based on the HIP report received from the client device teaches or suggests “retrieving, from a compliance server, a device posture of the un-managed client device, wherein the device posture is retrieved respective of the received client certificate,” as recited in claim 1. Appellant, for the first time in the Reply Brief, contends that Leung’s HIP report cannot teach the recited client certificate because a “client certificate is associated with a particular client device and received from the client device.” Reply Br. 4. Appellant argues that the recited client certificate, therefore, “is unique for the device,” whereas Leung’s “HIP report is not unique to a particular client device” because the HIP report can match multiple profiles. Reply Br. 4 (citing Spec. ¶¶ 27, 50; Leung ¶ 27). Appeal 2020-000437 Application 15/082,768 19 Appellant asserts Leung’s HIP report therefore can be used “to retrieve HIP profiles of multiple client devices.” Reply Br. 4 (citing Leung ¶ 43). Appellant’s Specification refers to the certificate as a “unique device certificate” or “unique client certificate.” Spec. ¶¶ 27, 30. The Specification also describes the client certificate as “a unique identifier of each client device.” Spec. ¶ 49. Notably, the claims do not recite these particular characteristics. The Specification describes using the client certificate for only one purpose—to query the compliance server “in order to return the posture of the respective device.” Spec. ¶ 37; see also Spec. ¶ 51 (“The authentication proxy 120 is further configured to query the compliance server 150 using the client certificate to retrieve at least the device posture.”). Appellant’s invention includes an alternative embodiment that may store a “state cookie [that] maintains compliance parameters.” Spec. ¶ 67. In such embodiments,5 no compliance server is required or queried to obtain the device posture because the necessary information is retrieved directly from the client device. Spec. ¶ 70. Given the Specification’s disclosures as a whole, I find we must broadly interpret the client certificate as merely data or a data structure that is particular to a client device such that it can be used to identify a device posture for that client device. Notwithstanding that a “certificate” may have “a specific meaning in the field of cybersecurity systems,” Reply Br. 4, 5 Given that the Specification discloses using the client certificate only as part of the query to the compliance server, it follows that the client certificate also is unnecessary in such embodiments. In other words, the client certificate appears to broadly encompass any data structure that allows the compliance server to select the device posture associated with the device. The claimed embodiments, however, all require the compliance server. Appeal 2020-000437 Application 15/082,768 20 Appellant’s Specification does not use the certificate in a way that appears to be consistent with certificates in cybersecurity systems. Rather, as discussed above, the Specification merely discloses using the certificate as a means for looking up a device posture associated with a particular device. Leung clearly uses the received HIP report to retrieve a HIP profile. See, e.g., Leung ¶¶ 27, 42, 46. Furthermore, Leung’s HIP report is specific to the client device that generates the report. Leung ¶¶ 26–27, 67–68. Accordingly, even considering Appellant’s belated argument that the HIP report is not a client certificate, I find Leung teaches the recited client certificate. Moreover, even interpreting the client certificate in a way that requires the certificate to be “unique,” I still find Leung’s HIP report teaches the client certificate. As discussed above, each of Leung’s client devices has an agent that generates a HIP report having “client device specific information.” Leung ¶ 26. Although not described in detail, Leung’s exemplary HIP reports include host names, IP addresses, and MAC addresses, which seem to at least suggest a unique identifier of the device sending the HIP report. Appellant raised this contention in the Reply Brief and, therefore, the Examiner did not directly point to these particular elements in the HIP report. Nevertheless, the Examiner finds the HIP reports teach the client certificates and Leung’s Figures 8 and 9 merely proved examples of such reports. Although not the basis of my dissent (because it is not based on findings made by the Examiner), I find it relevant that Leung discloses an alternative to receiving the HIP report directly from the client device. In particular, Leung discloses that some embodiments may receive the HIP Appeal 2020-000437 Application 15/082,768 21 report “indirectly using an intermediary device/function that collects, aggregates, and/or forwards HIP reports from the client device and/or other client devices.” Leung ¶ 28. In my opinion, this embodiment describes an architecture and system that at least suggests the claim language even when construed as narrowly as Appellant’s implicitly argue. In other words, this embodiment of Leung at least suggests that, upon receiving an access to cloud-based services from a client device, the gateway retrieves the HIP report for that client from “an intermediary device” that aggregates the reports from multiple clients. Leung ¶ 28. Furthermore, in order to identify the HIP report for the particular client device, this embodiment at least suggests that the gateway receives a unique identification (i.e., a client certificate) from the client device, which it then uses to obtain the HIP report from the intermediary device (i.e., compliance server). Appellant argues claims 2 and 11 separately. Appeal Br. 15–16. The assertions with respect to these claims essentially contend that Leung fails to teach the additionally recited subject matter because Leung does not teach an un-managed client device. However, for the same reasons discussed with respect to claim 1, I agree with the Examiner’s findings and conclusions that Leung teaches both managed and un-managed client devices. See, e.g., Leung ¶ 51. For these reasons, I respectfully dissent from the decision reversing the rejection of claims 1–26 under 35 U.S.C. § 103 as obvious over Leung and Khalid.