VMware, Inc.

Patent Trials and Appeals Board

Dec 27, 2021

2020005833 (P.T.A.B. Dec. 27, 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/488,067 04/14/2017 Anthony J. WILKINSON A431.C2 1099
152569 7590 12/27/2021
Patterson + Sheridan, LLP - VMware
24 Greenway Plaza
Suite 1600
Houston, TX 77046
EXAMINER
EDWARDS, LINGLAN E
ART UNIT PAPER NUMBER
2491
NOTIFICATION DATE DELIVERY MODE
12/27/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):
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 ANTHONY J. WILKINSON, PER OLOV LARSSON,
ASHLEY NUTTALL, HANS CHRISTENSON, TOM ELLIOTT,
STEVEN SIGEL and ADAM GROSS
Appeal 2020-005833
Application 15/488,067
Technology Center 2400
Before JAMES R. HUGHES, JOYCE CRAIG, and
MATTHEW J. McNEILL, Administrative Patent Judges.
CRAIG, 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. See Final Act. 1. We have
jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

1 We use the term “Appellant” to refer to “applicant” as defined in 37 C.F.R.
§ 1.42. Appellant identifies the real party in interest as VMware, Inc. Appeal
Br. 3.
Appeal 2020-005833
Application 15/488,067

2
CLAIMED SUBJECT MATTER
The claims are directed to a single sign-on authentication method and
system where, “[u]pon successfully logging into client machine 108,” the
user may select an option in which “the same credentials that were used to
log into client machine 108 are used as the credentials for logging into the
virtual machine hosting the user’s remote desktop and the user is not
required to re-enter those credentials.” Spec. ¶¶ 19–20; Fig. 2. Claim 1,
reproduced below, is illustrative of the claimed subject matter:
1. A method of authenticating a user to a service running in a
system, comprising:
responsive to receiving an input of user credentials at a
client computing device, logging the user into the client
computing device which is configured to communicate with the
service via a network;
storing the user credentials in the client computing
device;
displaying, via the client computing device, a first user
interface for connecting to the service, wherein the first user
interface (i) includes an option permitting the user to select
whether to use the same user credentials used to log into the
client computing device to also access the service, and (ii) does
not prompt the user to input user credentials to access the
service; and
responsive to a first request, made via the first user
interface, to access the service using the same user credentials
used to log into the client computing device:
transmitting the stored user credentials from the client
computing device to the service, and
at the service, authenticating the user using the user
credentials transmitted from the client computing device.
Appeal Br. 20 (Claims App.).
Appeal 2020-005833
Application 15/488,067

3
REFERENCES
The prior art relied upon by the Examiner is:
Name Reference Date
Wheeler et al. US 2004/0128508 A1 July 1, 2004
Fisher et al. US 2004/0205473 A1 Oct. 14, 2004
Baron et al. US 2008/0196090 A1 Aug. 14, 2008
Innes US 2009/0210934 A1 Aug. 20, 2009
Kuzin et al. US 2010/0146611 A1 June 10, 2010
NewsRx, “Yahoo! Inc.; Yahoo! Announces Support for OpenID; Users Able
to Access Multiple Internet Sites with Their Yahoo! ID,” Jan. 28, 2008
(“Yahoo!”)
REJECTIONS2
Claims 1, 2, 4, 6, 7, 10–12, 14, 16, 17, and 20 are rejected under
35 U.S.C. § 103(a) as unpatentable over Innes, Kuzin, and Yahoo!. Final
Act. 5–9.

2 In the event of further prosecution, the Examiner may wish to consider,
under 35 U.S.C. § 101, whether the claims are patent-ineligible as being
directed to an abstract idea that is not integrated into a practical application,
where the claims do not amount to significantly more than the abstract idea
itself. See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed.
Reg. 50 (Jan. 7, 2019). In particular, the Examiner may consider whether
claim 1, for example, recites an abstract method of organizing human
activity where the additional elements of “a client computing device,” “a
network,” and “a first user interface” do not integrate the possible abstract
idea into a practical application, and whether the additional limitations are
merely well-understood, routine, or conventional. See id.; see also, e.g.,
Universal Secure Registry LLC v. Apple Inc., 10 F.4th 1342, 1350 (Fed. Cir.
2021) (“the asserted claims are directed to a method for verifying the
identity of a user to facilitate an economic transaction, for which computers
are merely used in a conventional way”); Electronic Communication
Technologies, LLC v. ShoppersChoice.com LLC, 958 F.3d 1178, 1181 (Fed.
Cir. 2020) (finding to be abstract claim limitations that covered “enabling a
first party to input authentication information, storing the authentication
Appeal 2020-005833
Application 15/488,067

4
Claims 3 and 13 are rejected under 35 U.S.C. § 103(a) as unpatentable
over Innes, Kuzin, Yahoo!, and Fisher. Final Act. 9–10.
Claims 5 and 15 are rejected under 35 U.S.C. § 103(a) as unpatentable
over Innes, Kuzin, Yahoo!, and Wheeler. Final Act. 10–11.
Claims 8, 9, 18, and 19 are rejected under 35 U.S.C. § 103(a) as
unpatentable over Innes, Kuzin, Yahoo!, and Baron. Final Act. 11–12.
OPINION
Appellant disputes the Examiner’s findings that Innes teaches the
following claim 1 limitations:
responsive to receiving an input of user credentials at a
client computing device, logging the user into the client
computing device which is configured to communicate with the
service via a network;
. . .
responsive to a first request, made via the first user
interface, to access the service using the same user credentials
used to log into the client computing device:
transmitting the stored user credentials from the
client computing device to the service, and

information, and providing the authentication information along with the
advance notice of arrival to help ensure the customer that the notice was
initiated by an authorized source”); Prism Technologies LLC v. T-Mobile
USA, Inc., 696 F. App’x 1014, 1017 (Fed. Cir. 2017) (“the asserted claims
are directed to an abstract process that includes: (1) receiving identity data
from a device with a request for access to resources; (2) confirming the
authenticity of the identity data associated with that device; (3) determining
whether the device identified is authorized to access the resources requested;
and (4) if authorized, permitting access to the requested resources”).
Although the Board is authorized to reject claims under 37 C.F.R.
§ 41.50(b), no inference should be drawn when the Board elects not to do
so. See Manual of Patent Examining Procedure (MPEP) § 1213.02.
Appeal 2020-005833
Application 15/488,067

5
at the service, authenticating the user using the
user credentials transmitted from the client computing
device.
See Appeal Br. 8–14. In particular, Appellant contends that “while it is true
that certain computer devices may be configured to require user credentials
as part of the log-in process,” nothing, for example, in Innes’s Figure 1A,
“suggests user credentials are used to log into any of client machines 102.”
Id. at 9–10. Appellant further contends that Innes does not disclose using the
same user credentials to access the service as for logging into a client
computing device “because Innes simply does not even disclose user
credentials being used to log the user into a client computing device.” Id. at
13–14. Rather, Appellant contends, Innes “merely discloses a broker service
240 receiving authentication credentials but does not disclose that such
credentials are the same credentials that were used to log the user into a
client computing device.” Id. at 13.
We are not persuaded that the Examiner errs in relying on Innes for
the claim 1 limitations relating to using the same user credentials for both
logging into a client computing device and for accessing a service. Innes
generally relates to “authenticating, by a trusted component, a user of a
desktop appliance to a remote machine.” Innes, Abstract. Innes describes a
desktop appliance 102 that includes a user interaction component 210. Id.
¶ 60. “In some embodiments, the user interaction component 210 receives
authentication credentials from a user” and “includes an authentication
module for authenticating the user responsive to the received authentication
credentials.” Id. ¶¶ 61–62. In an embodiment, “user interaction component
210 transmits the received authentication credentials to the broker
interaction component 220” in desktop appliance 102. Id. ¶ 61. Also in an
Appeal 2020-005833
Application 15/488,067

6
embodiment, “broker interaction component 220 transmits the received
authentication credentials to the broker service 240.” Id. ¶ 64. “In one
embodiment, the broker service 240 executes on the broker server 106,
receives the authentication credentials and authenticates the user.” Id. ¶ 66.
Broker service 240 may then, in an embodiment, “provision[] a desktop host
106[’] to accept a connection from a desktop appliance 102.” Id.
Alternatively, a “remote machine (i.e., the desktop host 106’) receives, from
the broker service 240, the authentication data associated with the received
authentication credentials, authenticates the user . . . , and establishes a
connection with the desktop appliance.” Id. In some embodiments, “the
authentication data includes the authentication credentials,” and in other
embodiments, “the desktop host 106’ includes an authentication module
receiving authentication credentials and authenticating the user.” Id. ¶¶ 67–
68.
As shown above, Innes describes performing authentication at desktop
appliance 102—i.e., the “client computing device”—with user interaction
component 210. We find Innes’s authentication at the desktop appliance 102
at least suggests “logging the user into the client computing device,” as
recited in claim 1. In particular, Innes describes “authenticating a user by a
trusted local component,” such as a “security procedure for accessing a local
Windows desktop [that] includes the use of a Secure Attention Sequence
(SAS).” Id. ¶ 51. This way, Innes can leverage “existing local operating
system components that normally receive and process the SAS without
replacing those components.” Id. Further, Innes describes that, in an
embodiment, “the desktop connection component 230 [in desktop appliance
102] loses its connection to the desktop host 106’ while the desktop
Appeal 2020-005833
Application 15/488,067

7
appliance is in the locked state and the desktop appliance 102 transitions to
the pre-authenticated state.” Id. ¶ 89. In this case, “if a local operating
system logon session was created during a log-on process, it is destroyed.”
Id. Here, Innes’s descriptions of using local operating system components
for authenticating a user and destroying a local logon session if a connection
to the remote desktop is lost at least suggest logging into a client computing
device.
As also shown above, Innes describes transmitting to broker service
240 the very credentials received by user interaction component 210, and
thereafter authenticating the user based on the credentials, either at broker
service 240 or desktop host 106’. Further, Innes describes that “single sign-
on functionality is provided to the user.” Id. ¶ 119. Accordingly, we find that
Innes at least suggests using the same user credentials to log the user into a
client computing device and authenticate the user at a service.
In the Reply Brief, Appellant argues, with respect to paragraph 119 of
Innes, that “based on Innes’s clear choice of words, (1) displaying a log-in
interface, (2) receiving user authentication credentials, and (3) providing a
single sign-on functionality to the user are all separate and unrelated
embodiments.” Reply Br. 3. In particular, Appellant argues that “Innes’s
simple statement that ‘[i]n still another of these embodiments, single sign-on
functionality is provided to the user,’ . . . is not enough to support the
Examiner’s conclusions that the same user credentials that are allegedly used
to log the user into the desktop appliance 102 are also used to authenticate
the user to the broker service.” Id. This argument is not persuasive of
Examiner error.
Appeal 2020-005833
Application 15/488,067

8
As discussed above, Innes describes embodiments that include
authenticating a user with user interaction component 210 at desktop
appliance 102 based on “received authentication credentials” (Innes ¶ 62), as
well as authenticating the user with broker service 240 at broker server 106
based on “the authentication credentials” (id. ¶ 66). We see no evidence that
Innes intended these to be mutually exclusive embodiments. Rather, Innes’s
disclosure that “[i]n some embodiments, the user inter[action] component
210 includes an authentication module” (id. ¶ 62) and “[i]n some
embodiments, the broker service 240 includes an authentication module” (id.
¶ 66) shows that each of these features may be used in more than one
embodiment, with different combinations of features. In other words, Innes
describes many optional features, including authentication modules in both
user interface component 210 and broker service 240, without describing
these modules as incompatible in a single implementation. Innes’s disclosure
of a “single sign-on” (Innes ¶ 119) suggests such an implementation with
authentication modules in both user interface component 210 and broker
service 240, where the user only enters the user credentials once.
Specifically, we agree with the Examiner that “the definition of single sign-
on is to allow [a] user to log in with a single credential to multiple
applications.” Ans. 8.
Appellant also disputes the Examiner’s finding that Yahoo!, in
combination with Innes and Kuzin, teaches the following claim 1
limitations:
displaying, via the client computing device, a first user
interface for connecting to the service, wherein the first user
interface (i) includes an option permitting the user to select
whether to use the same user credentials used to log into the
Appeal 2020-005833
Application 15/488,067

9
client computing device to also access the service, and (ii) does
not prompt the user to input user credentials to access the
service.
See Appeal Br. 14–16. In particular, Appellant contends “[a]n OpenID
identifier that provides a user with access to Yahoo! and some affiliate
websites is not the same as user credentials used to log into the client
computing device.” Appeal Br. 16. Appellant also contends that “Yahoo!
discloses that each time a user wants to access an affiliate website, the user
needs to input his/her Yahoo! credentials.” Id.
We are not persuaded that the Examiner errs in relying on Yahoo! in
combination with Innes and Kuzin for the claim 1 limitations of a displaying
a user interface that “permit[s] the user to select whether to use the same
user credentials used to log into the client computing device to also access
the service,” and “does not prompt the user to input user credentials to
access the service.” Yahoo! relates to the OpenID framework which
“enables users to consolidate their Internet identity, eliminating the need to
create separate IDs and logins at all of the various websites, blogs, and
profile pages they may visit in the course of their online session.” Yahoo!, 1.
In particular, Yahoo! describes that “web sites that accept OpenID 2.0 will
be able to add a simple ‘Sign-in with Your Yahoo! ID’ button to their login
pages that will make it even easier for their users.” Id. Here, we find that a
“‘Sign-in with Your Yahoo! ID’ button” at least suggests displaying a user
interface that permits the user to select whether to use the same user
credentials to log into a particular website—i.e., “a service”—as used to log
on elsewhere.
Moreover, Yahoo! describes the OpenID 2.0 specification as “the
most user-friendly single sign-on and online user-authentication standard.”
Appeal 2020-005833
Application 15/488,067

10
Id. As noted above, we determine that a single sign-on defines an
authentication process in which a user enters credentials once. Accordingly,
we find Yahoo! also at least suggests that the sign-in button is an interface
that does not prompt the user to input user credentials, as claimed. We
disagree with Appellant’s argument that “in Yahoo!, the user is actually
prompted to use their Yahoo! credentials for signing in.” Appeal Br. 16.
Appellant does not point to any evidence that shows Yahoo! requires a user
to enter credentials after clicking the “‘Sign-in with Your Yahoo! ID’
button.” See id. Given Innes’s similar disclosure of “single sign-on
functionality” (Innes ¶ 119), we find Yahoo! would have suggested to one of
ordinary skill in the art to use an interface that allows a user to select
whether to use the same authentication credentials at Innes’s broker service
240, or desktop host 106’, to authenticate the user as those credentials used
to authenticate the user at user interaction component 210.
For these reasons, we are not persuaded the Examiner errs in finding
the combination of Innes, Kuzin, and Yahoo! teaches the disputed
limitations of claim 1. Accordingly, we sustain the Examiner’s obviousness
rejection of claim 1, as well as claims 2, 4, 6, 7, 10–12, 14, 16, 17, and 20
not specifically argued separately. Appellant does not provide specific
separate arguments regarding the obviousness rejections of claims 3, 5, 8, 9,
13, 15, 18, and 19, but rather relies on the arguments presented for claim 1.
See Appeal Br. 16–17. For the same reasons discussed above, we sustain the
Examiner’s obviousness rejections of claims 3, 5, 8, 9, 13, 15, 18, and 19.
CONCLUSION
The Examiner’s decision rejecting claims 1–20 is AFFIRMED.
Appeal 2020-005833
Application 15/488,067

11
DECISION SUMMARY
Claim(s)
Rejected
35 U.S.C. § Reference(s)/Basis Affirmed Reversed
1, 2, 4, 6, 7,
10–12, 14,
16, 17, 20
103(a) Innes, Kuzin,
Yahoo!
1, 2, 4, 6, 7,
10–12, 14,
16, 17, 20

3, 13 103(a) Innes, Kuzin,
Yahoo!, Fisher
3, 13
5, 15 103(a) Innes, Kuzin,
Yahoo!, Wheeler
5, 15
8, 9, 18, 19 103(a) Innes, Kuzin,
Yahoo!, Baron
8, 9, 18, 19
Overall
Outcome
1–20
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).
AFFIRMED