HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP

Patent Trials and Appeals Board

Dec 22, 2020

2019004892 (P.T.A.B. Dec. 22, 2020)

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/128,501 09/23/2016 Ming Sum Sam NG 90278959 5479
146568 7590 12/22/2020
MICRO FOCUS LLC
500 Westover Drive
#12603
Sanford, NC 27330
EXAMINER
SCHMIDT, KARI L
ART UNIT PAPER NUMBER
2439
NOTIFICATION DATE DELIVERY MODE
12/22/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):
software.ip.mail@microfocus.com
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte MING SUM SAM NG, RONALD JOSEPH SECHMAN,
and MATIAS MADOU

Appeal 2019-004892
Application 15/128,501
Technology Center 2400
____________

Before JOSEPH L. DIXON, BEVERLY A. FRANKLIN, and
MAHSHID D. SAADAT, Administrative Patent Judges.

SAADAT, Administrative Patent Judge.

DECISION ON APPEAL

Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–7 and 10–21, which are all the claims
in this application.2 We have jurisdiction under 35 U.S.C. § 6(b).
We REVERSE.

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 EntIT
Software LLC. Appeal Br. 1.
2 Claims 8 and 9 have been canceled previously. See Final Act. 2.
Appeal 2019-004892
Application 15/128,501

2
STATEMENT OF THE CASE
Appellant’s disclosure is directed to monitoring events relating to
access of resources in a system where “[i]nformation stored in a Hypertext
Transfer Protocol (HTTP) session is” and “authentication information in the
information stored in the HTTP session is identified.” Spec. ¶ 8, Abstract.
Claim 1 is illustrative of the invention and reads as follows:
1. A method comprising:
receiving, by a program executed in a system comprising
a processor, a request from an entity to access a resource;
in response to the request being an authentication
request:
performing, by the program, a verification of a
credential included in the request, the program granting access
to the resource and adding authentication information into a
Hypertext Transfer Protocol (HTTP) session storage in
response to verifying the credential, and the program not adding
the authentication information into the HTTP session storage in
response to not verifying the credential;
monitoring, by a monitoring agent executed in the
system, information added to the HTTP session storage by the
program as part of processing the authentication request;
determining, by the monitoring agent based on the
monitoring, whether the authentication information is stored in
the HTTP session storage;
indicating, by the monitoring agent, a successful
authentication attempt in response to determining that the
authentication information is stored in the HTTP session
storage; and
indicating, by the monitoring agent, an
unsuccessful authentication attempt in response to determining
that the authentication information is not stored in the HTTP
session storage.
Appeal 2019-004892
Application 15/128,501

3
REFERENCES AND REJECTIONS
The prior art relied upon by the Examiner is:
Name Reference Date
Joshi US 2002/0091798 A1 July 11, 2002
Hatakeyama US 2007/0011303 Al Jan. 11, 2007
Champagne US 7,194,761 B1 Mar. 20, 2007
Rafiq US 2012/0023558 Al Jan. 26, 2012
Claims 1–7 and 11–21 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Hatakeyama, Champagne, and Joshi. Final Act. 10–24.
Claim 10 stands rejected under 35 U.S.C. § 103(a) as unpatentable
over Hatakeyama, Champagne, Joshi, and Rafiq. Final Act. 25.3
ISSUE ON APPEAL
Appellant’s arguments in the Appeal Brief present the following
dispositive issue4:
Whether the Examiner erred in finding the combination of
Hatakeyama and Champagne teaches or suggests the following limitation
recited in independent claims 1, 11, and 14:
performing, by the program, a verification of a credential
included in the request, the program granting access to the
resource and adding authentication information into a
Hypertext Transfer Protocol (HTTP) session storage in
response to verifying the credential, and the program not
adding the authentication information into the HTTP session
storage in response to not verifying the credential.
Appeal Br. 18 (emphasis added).

3 The Examiner withdrew the 35 U.S.C. § 101 rejection of claims 1–7 and
10–21. See Ans. 3.
4 We do not address Appellant’s other contentions because this contention is
dispositive of the issue on appeal.
Appeal 2019-004892
Application 15/128,501

4
ANALYSIS
We have reviewed the Examiner’s rejections 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 limitation at issue, the Examiner relies on the disclosure in
Champagne of an authentication response and inserting authentication
information in a header. Final Act. 12 (citing Champagne 11:21–41, 18:29–
41, Fig. 4). The Examiner maps the recited “adding authentication
information into a Hypertext Transfer Protocol (HTTP) session storage in
response to verifying the credential” to Champagne’s entry of the
information as “an HTTP www.authentication header” into a cached or a
new authentication response. Id. The Examiner further finds combining
Champagne with Hatakeyama would have been obvious for automatically
authenticating users’ requests for access resources. Final Act. 12–13 (citing
Champagne 3:6–10).
Appellant contends the Examiner erred in reading the disputed claim
limitation on Champagne’s authentication response 123 which is described
as follows:
The authentication manager in the data communications device
110 “creates an authentication response 123 to the
authentication request 122.” Id., 15:54–55. This authentication
response 123 is created by: retrieving from the cache of
requests the request for data, and inserting authentication
information into the retrieved cached request. Id., 22:67–23:65;
see also id. 11:32–33 (referring to “insert authentication
information . . . into this cached request.”
Appeal 2019-004892
Application 15/128,501

5
Appeal Br. 19. According to Appellant, “the intermediate device (i.e., the
data communication device 110 such as a router or switch) creates the
authentication response (rather than the client device),” which is created by
retrieving its cached version and adding authentication information to create
an authentication response. Id. Appellant argues adding authentication
information to the request is not the same as adding the authentication
information into the HTTP session storage.” Appeal Br. 20.
In response, the Examiner points to Figure 4 and paragraph 18, lines
29–41, of Champagne and explains that request 122 includes the credential
or authentication information. Ans. 4–5. The Examiner also finds
Champagne’s disclosure of inserting “authentication information (e.g., as an
HTTP www.authentication header) into a request in order to format or create
a new authentication response” is reasonably construed as “the HTTP
session storage (i.e., adding authentication information into a Hypertext
Transfer Protocol (HTTP) session storage in response to verifying the
credential).” Ans. 5.
Based on our review of Champagne’s disclosure, we find the
authentication information within an authentication request is received or
intercepted by the data communication device which “can insert
authentication information (e.g., as an HTTP www.authentication header)
into this cached request for data in order to formulate or create a new
authentication response,” which is forwarded “to the server device as if it
had originated from the client device.” See Champagne 11:30–39. To the
extent an HTTP header can be characterized as related to an HTTP session,
such connection does not sufficiently disclose that the authentication
information, even in the form of a header, is added into an HTTP session
Appeal 2019-004892
Application 15/128,501

6
storage to indicate that the credential is verified, as recited in claim 1. In
fact, Appellant’s disclosure describes an HTTP session storage as “a data
structure associated with the HTTP session that is used to contain data
relating to the HTTP session.” Spec. ¶ 21.
We find no indication in the cited portions of Champagne that the
authentication information is stored in other than the authentication response
in the form of a header. At best, Champagne’s request and response, which
may include the authentication response header, are transmitted as a part of
an HTTP communications session. See Champagne 10:1–11. However, the
Examiner has not shown, nor do we find, any disclosure in Champagne with
regard to storing such authentication information in an HTTP session
storage. Additionally, based on Appellant’s description of an HTTP session
storage, we do not agree with the Examiner’s characterization of inserting
the authentication information header into the response as the recited adding
the information to an HTTP session storage. See Ans. 5. As stated by
Appellant,
Adding authentication information to a request to form an
authentication response, as described in Champagne, does not
involve adding any authentication information into an HTTP
session storage as claimed. The authentication response to
which the authentication information is added in Champagne is
a message that is sent back to the server device, and is not an
HTTP session storage.
Reply Br. 4. That is, the Examiner has not established that Champagne’s
HTTP header is the same as an HTTP session storage.
In view of the above analysis, we are persuaded by Appellant’s
contentions that adding the authentication header in Champagne is not the
same as the recited adding the authentication information to an HTTP
Appeal 2019-004892
Application 15/128,501

7
session storage. Therefore, on the record before us, we are constrained to
conclude the Examiner errs in rejecting claim 1, as well as independent
claims 11 and 14 that recite similar limitations, as obvious.
DECISION
For the reasons stated above, we do not sustain the obviousness
rejection of independent claims 1, 11, and 14, as well as claims 2–7 and 12,
13, and 15–21 dependent therefrom, over Hatakeyama and Champagne. The
Examiner has not relied upon the additional reference to teach or suggest the
above-identified limitation in rejecting claim 10. See Final Act. 12–17.
Accordingly, for reasons similar to those above for independent claims 1,
11, and 14, we do not sustain the remaining rejection.
CONCLUSION SUMMARY
In summary:
Claims
Rejected
35 U.S.C. § Basis Affirmed Reversed
1–7, 11–21 103(a) Hatakeyama,
Champagne, Joshi
1–7, 11–21
10 103(a) Hatakeyama,
Champagne,
Joshi, Rafiq
10
Overall
Outcome
1–7, 10–21

REVERSED