Ex Parte Glasgow et al

Patent Trial and Appeal Board

Jun 22, 2016

12850363 (P.T.A.B. Jun. 22, 2016)

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.
12/850,363 08/04/2010 Jay O. Glasgow 2010-0430 9691
38516 7590 06/23/2016
AT&T Legal Department - SZ
Attn: Patent Docketing
Room 2A-207
One AT&T Way
Bedminster, NJ 07921
EXAMINER
HOLDER, BRADLEY W
ART UNIT PAPER NUMBER
2439
MAIL DATE DELIVERY MODE
06/23/2016 PAPER
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.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte JAY O. GLASGOW and JOHANNES JASKOLSKI
____________

Appeal 2014-006357
Application 12/850,3631
Technology Center 2400
____________

Before ROBERT E. NAPPI, CARL L. SILVERMAN, and
STACY B. MARGOLIES, Administrative Patent Judges.

MARGOLIES, Administrative Patent Judge.

DECISION ON APPEAL

This appeal arises under 35 U.S.C. § 134(a) from the rejection of
claims 1–20. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm-in-part.

1 According to Appellants, the real party in interest is AT&T Mobility II
LLC. App. Br. 1.

Appeal 2014-006357
Application 12/850,363

2
SUMMARY OF THE INVENTION
The invention is generally directed to establishing a secure
communications session between an application that runs natively on a
device and a service of a service provider that is secured by a web services
gateway. See Abstract; Spec. ¶ 33.
Claims 1, 4, and 13 are illustrative of the subject matter on appeal and
are reproduced below (with disputed limitations emphasized):
1. A communications method comprising:
supporting, by the device, a temporary login session
socket between the device and a login session server;
receiving a login session token at the device from the
login session server, the login session token indicating that an
application that runs natively on the device is verified to access
a service that is secured by a web services gateway;
accepting, by the device, a userid and a password for the
service;
communicating, from the device to the web services
gateway, the userid and the password for the service along with
the login session token that indicates that the application that
runs natively on the device is verified to access the service; and
establishing, by the device, the communications session
between the application that runs natively on the device and the
service that is secured by the web services gateway in response
to verification by the web services gateway of the userid and
the password for the service and the login session token that
indicates that the application that runs natively on the device is
verified to access the service, so that the application that runs
natively on the device is allowed to access the service.

4. A method according to Claim 1 wherein accepting, by
the device, a userid and a password for the service comprises:
Appeal 2014-006357
Application 12/850,363

3
presenting at the device a user interface that identifies
both the service and the application and that accepts input of
the userid and the password for the service; and
accepting the userid and the password for the service that
are input to the user interface.

5. A method according to Claim 1 wherein communicating,
from the device to the web services gateway, the userid and the
password for the service along with the login session token that
indicates that the application that runs natively on the device is
verified to access the service comprises:
launching a browser at the device; and
communicating the userid and the password for the
service along with the login session token that indicates that the
application that runs natively on the device is verified to access
the service, from the device to the web services gateway using
the browser.

13. A communications method comprising:
establishing, by a login session server, a temporary login
session socket with a device in response to a request by the
device;
sending, by the login session server, a login session token
that indicates that an application that runs natively on the device
is verified to access a service that is secured by a web services
gateway, to the device over the temporary login session socket
in response to verification that the application is authorized to
access the service;
closing, by the login session server, the temporary login
session socket in response to receipt of the login session token
that indicates that the application that runs natively on the
device is verified to access the service by the device; and
communicating, by the login session server, the login
session token that indicates that the application that runs
natively on the device is verified to access the service, to the
web services gateway.
Appeal 2014-006357
Application 12/850,363

4
REFERENCES AND REJECTIONS
The Examiner rejected claims 1, 2, 4, 5, 7, 8, 10, and 11 under
35 U.S.C. § 103(a) as being unpatentable over Malakapalli (US
2009/0328182 A1; published Dec. 31, 2009) and Guarraci (US 7,992,198
B2; filed Sept. 14, 2007). Final Act. 3–13.
The Examiner rejected claims 3 and 6 under 35 U.S.C. § 103(a) as
being unpatentable over Malakapalli, Guarraci, and Gupta (US 6,763,468
B2; issued July 13, 2004). Final Act. 13–16.
The Examiner rejected claim 9 under 35 U.S.C. § 103(a) as being
unpatentable over Malakapalli, Guarraci, and Shrader (US 6,374,359 B1;
issued Apr. 16, 2002). Final Act. 16–18.
The Examiner rejected claim 12 under 35 U.S.C. § 103(a) as being
unpatentable over Malakapalli, Guarraci, and De Lutiis (US 7,954,141 B2;
filed Apr. 24, 2007). Final Act. 18–20.
The Examiner rejected claims 13–20 under 35 U.S.C. § 103(a) as
being unpatentable over Malakapalli, Guarraci, and Gupta. Final Act. 20–
29.

ISSUES
The issues in this appeal are:
(i) whether the Examiner erred in finding that the combination of
Malakapalli and Guarraci teaches or suggests “communicating, from the
device to the web services gateway, the userid and the password for the
service along with the login session token that indicates that the application
that runs natively on the device is verified to access the service,” as recited
in claim 1;
Appeal 2014-006357
Application 12/850,363

5
(ii) whether the Examiner erred in finding that Gupta teaches or
suggests “closing, by the login session server, the temporary login session
socket in response to receipt of the login session token that indicates that the
application that runs natively on the device is verified to access the service,”
as recited in independent claims 13 and 17;
(iii) whether the Examiner erred in finding that Malakapalli teaches
or suggests “presenting at the device a user interface that identifies both the
service and the application,” as recited in dependent claim 4; and
(iv) whether the Examiner erred in finding that Malakapalli teaches
or suggests “wherein communicating . . . the userid and the password for the
service along with the login session token . . . comprises: launching a
browser at the device . . . ,” as recited in dependent claim 5.

ANALYSIS
Obviousness rejection of independent claim 1
Appellants argue that because Malakapalli discloses sending the
native authentication information (userid and password) separately from and
subsequently to sending the authentication token (login session token),
Malakapalli does not disclose communicating a userid and password “along
with” a login session token as required by claim 1. App. Br. 5–8.
Appellants also argue that Guarraci does not disclose or suggest
communicating a userid and password “along with” a login session token,
and that Guarraci’s thick-client application “does not appear to be trusted
enough . . . to communicate a userid and password.” Id. at 9 (emphasis
removed).
Appeal 2014-006357
Application 12/850,363

6
We are not persuaded that the Examiner erred. The phrase “along
with” is not defined or otherwise limited in Appellants’ specification to
require that the userid and password be sent at the same time or in the same
packet as the login session token. See Spec. ¶¶ 33, 38, 40, 49. The
specification describes allowing a secured communications session to be
established between an application that runs natively on a device and a
service provided by a service provider, but does not describe, let alone
require, that the pieces of information to establish that session be sent
simultaneously or together. See, e.g., Spec. ¶¶ 29, 32, 33. We thus agree
with the Examiner that Malakapalli’s disclosure of communicating an
authentication token and communicating native authentication information
teaches “communicating, from the device to the web services gateway, the
userid and the password for the service along with the login session” as
claimed.
We also agree with the Examiner that the combination of Malakapalli
and Guarraci teaches or suggests “communicating, from the device to the
web services gateway, the userid and the password for the service along with
the login session token that indicates that the application that runs natively
on the device is verified to access the service.” See Final Act. 5. Guarraci
teaches that an application communicating with a web site or server can be
an application that runs natively at the requestor component. Guarraci Fig.
1, 4:66–5:3. Malakapalli teaches a client device communicating a userid, a
password, and a token that indicates the user or client device is verified to
access a service. Malakapalli Figs. 5, 6, 8; ¶¶ 2, 11, 14, 44, 51, 52. The
Examiner finds, and we agree, that Malakapalli and Guarraci both pertain to
network security and access control to data and services, and that it would
Appeal 2014-006357
Application 12/850,363

7
have been obvious to one of ordinary skill in the art to combine the two to
add the application aspect taught by Guarraci to the authentication
mechanisms taught by Malakapalli to provide different trust levels and
added security. Final Act. 5.
We thus sustain the obviousness rejection of claim 1 and claims 2, 3,
and 8–12 which are not argued separately.
Obviousness rejection of independent claims 13 and 17
Appellants argue that Gupta, which discloses that a communication
session ends after a specified time period or because a client or application
server has terminated the connection, does not teach or suggest “closing, by
the login session server, the temporary login session socket in response to
receipt of the login session token,” as required by claims 13 and 17. App.
Br. 10.
We are persuaded that the Examiner erred. The claims require closing
the temporary login session socket “in response to receipt of the login
session token . . . .” The Examiner fails to cite sufficient evidence showing
that the combination of Malakapalli and Gupta teaches or suggests
terminating the login session in response to receipt of the login session
token. See Ans. 7–8. The cited passage of Gupta does not disclose
terminating the connection in response to receipt of a token, and the cited
passages of Malakapalli do not disclose terminating a temporary session in
response to receiving a token. The Examiner fails to cite sufficient evidence
supporting the finding that the combination of the two references suggests
the termination of the connection with the authentication server after the
token has been received because the purpose of establishing a connection
with the server is to obtain the session token. See Ans. 7. We thus do not
Appeal 2014-006357
Application 12/850,363

8
sustain the obviousness rejection of independent claims 13 and 17 and
dependent claims 14–16 and 18–20.
Obviousness rejection of dependent claim 4
Appellants state that the cited portions of Malakapalli do not disclose
or suggest that the user interface identifies both the service and the
application, as required by claim 4. App. Br. 11.
The Examiner finds that Malakapalli teaches that a software
application or webpage is displayed at the client machine that allows the
user to connect to the remote service for accessing the data and other
resources. Ans. 9. The Examiner finds that Malakapalli teaches that when
the application or webpage is launched on the client computer to connect to
the remote terminal server and display the returned data from the connected
terminal server, this inherently involves the act of first identifying the
application/webpage itself (to determine which software/webpage for
execution) and then the service which the user intends to be connected to
(i.e., the terminal server itself, which provides the data and/or application
resources). Id.
We are not persuaded that the Examiner erred. Appellants’ blanket
statement that the cited portions of Malakapalli do not disclose the claimed
features fails to adequately address and show error in the Examiner’s
findings. See In re Lovin, 652 F.3d 1349, 1357 (Fed. Cir. 2011) (holding
that the Board reasonably interpreted Rule 41.37 “to require more
substantive arguments in an appeal brief than a mere recitation of the claim
elements and a naked assertion that the corresponding elements were not
found in the prior art”). Moreover, we agree with the Examiner’s findings
and reasoning. The claim term “service” is a broad term that is not defined
Appeal 2014-006357
Application 12/850,363

9
or limited in Appellants’ specification. See Spec. ¶ 2. The Examiner finds,
and we agree, that Malakapalli teaches or suggests that the
application/webpage displayed on the user’s screen embeds the
identification of the terminal server (i.e., the claimed service). Final Act. 7;
Ans. 9; Malakapalli ¶ 8. We thus sustain the obviousness rejection of claim
4.
Obviousness rejection of dependent claim 5
Appellants argue that, in Malakapalli, the browser “is already
operational” and therefore Malakapalli does not teach the requirement of
claim 5 of “launching a browser” at the device. App. Br. 11. The Examiner
responds that Malakapalli and Guarraci teach or suggest running the browser
to communicate with the terminal services gateway the necessary browser
cookie/token and credential for authentication. Ans. 10.
We are not persuaded that the Examiner erred. As the Examiner
finds, Malakapalli teaches communication of the token (browser cookie) and
the native authentication credential (userid) would require the use of a web
browser. See Ans. 10; Malakapalli ¶¶ 49, 51, 52. Also, as the Examiner
finds, Guarraci suggests launching a web browser to communicate the
session token. See Ans. 10; Guarraci 5:1–8, 7:20–40. Thus, the references
teach or suggest that communicating the userid and the password for the
service along with the login session token includes launching a web browser.
We thus sustain the obviousness rejection of claim 5 and claims 6 and 7
which are not argued separately.

Appeal 2014-006357
Application 12/850,363

10
DECISION
We affirm the Examiner’s rejection of claims 1–12.
We reverse the Examiner’s rejection of claims 13–20.
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).

AFFIRMED-IN-PART