UNITED STATES PATENT AND TRADEMARK OFFICE ______
BEFORE THE PATENT TRIAL AND APPEAL BOARD ______
EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; AND ORBITZ, LLC Petitioners
v.
INTERNATIONAL BUSINESS MACHINES CORP. Patent Owner ______
Case No. Unassigned Patent 6,374,359 ______
PETITION FOR INTER PARTES REVIEW OF CLAIMS 1-16 OF U.S. PATENT NO. 6,374,359 Petition for IPR of U.S. Patent 6,374,359
TABLE OF CONTENTS
I. INTRODUCTION ...... 1
Summary of Unpatentability Grounds ...... 1 II. MANDATORY NOTICES, STANDING, AND FEES ...... 1
Mandatory Notices ...... 1 Certification of Grounds for Standing ...... 3 Fees ...... 3 III. OVERVIEW OF THE ’359 Patent ...... 3
Subject Matter of the ’359 Patent ...... 3 Claims of the ’359 Patent ...... 5 Prosecution History of the ’359 Patent ...... 6 Ordinary Skill in the Art ...... 8 IV. SUMMARY OF PRIOR ART ...... 9
Reiche ...... 9 Spinning the Web by Yuval Fisher ...... 16 Stubbs ...... 19 Goodman ...... 24 LDAP Draft and RFCs ...... 25 V. CLAIM CONSTRUCTION ...... 28
VI. THE CHALLENGED CLAIMS ARE UNPATENTABLE ...... 35
Ground 1 ...... 35 Ground 2 ...... 45 Ground 3 ...... 58 Ground 4 ...... 64 Ground 5 ...... 72
i Petition for IPR of U.S. Patent 6,374,359
Ground 6 ...... 75 VII. CONCLUSION ...... 77
ii Petition for IPR of U.S. Patent 6,374,359
LIST OF EXHIBITS1
1001 U.S. Patent No. 6,374,359 to Shrader et al. (“the ’359 Patent”)
1002 Expert Declaration of B. Keith Moore
1003 CV of B. Keith Moore
1004 File History of U.S. Patent No. 6,374,359 to Shrader et al.
1005 U.S. Patent No. 6,092,196 to Reiche (“Reiche”)
1006 Yuval Fisher, Spinning the Web (1996) (“Fisher”)
1007 Nesta Stubbs, One-time authentication for multiple Web servers?, post to the comp.infosystems.www.servers.misc group on July 3, 1996 (“Stubbs”)
1008 D. Kristol et al., “HTTP State Management Mechanism,” Internet RFC 2109 (Feb. 1997) (“RFC 2109”)
1009 R. Fielding et al., “Hypertext Transfer Protocol - HTTP/1.1,” Internet RFC 2068 (Jan. 1997) (“RFC 2068”)
1010 Danny Goodman, JavaScript Handbook, 1996 (“Goodman”)
1011 T. Howes et al., “The C LDAP Application Program Interface”, IETF Working Draft (Jul. 29, 1997) (“LDAP Draft”)
1012 Expert Declaration of James L. Mullins, Ph.D
1013 CV of James L. Mullins
1014 Memorandum in Support of Motion for Summary Judgment of Defendant Groupon, Inc., International Business Machines Corp. v. Groupon Inc., 1:16-cv-122, Dkt. 241, March 13, 2018
1 Citations in the Petition to Exhibits are made to native page numbering on the exhibits wherever possible.
iii Petition for IPR of U.S. Patent 6,374,359
1015 Collected posts to the comp.infosystems.www.servers.misc group in thread with One-time authentication for multiple Web servers?
1016 Exhibit 1 to Mullins Declaration
1017 Exhibit 2 to Mullins Declaration
1018 RESERVED
1019 RESERVED
1020 S. Bradner, “The Internet Standards Process -- Revision 3,” Internet RFC 2026 (Oct. 1996) (“RFC 2026”)
1021 M. Horton, “Standard for Interchange of USENET Message,” Internet RFC 1036 (Dec. 1987) (“RFC 1036”)
1022 B. Reid, “USENET Readership Summary Report for July 1995,” (Aug. 6, 1995), available at https://groups.google.com/forum/#!original/news.lists/bt_reRadXYo/- 9tq-mbefFYJ
1023 B. Reid, “USENET Readership Report for July 1995,” (Aug. 6, 1995). available at https://groups.google.com/forum/#!original/news.lists/zCfHkoXchIg/ N41pFcwrUTQJ
1024 J. Linn, “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures,” Internet RFC 989 (Feb. 1987) (“RFC 989”)
1025 N. Borenstein, N .Freed. “MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies,”. Internet RFC 1341 (June 1992) (“RFC 1341”)
1026 T. Berners-Lee et al., “Uniform Resource Locators,” Internet RFC 1738 (Dec. 1994) (“RFC 1738”)
1027 T. Berners-Lee, D. Connolly, “Hypertext Markup Language – 2.0,”
iv Petition for IPR of U.S. Patent 6,374,359
Internet RFC 1866 (Nov. 1995) (“RFC 1866”)
1028 “An Exploration of Dynamic Documents,” captured June 14, 1997, available at https://web.archive.org/web/19970614044340/http://home.netscape.co m/assist/net_sites/pushpull.html
1029 “Common Gateway Interface,” captured Dec. 10, 1998, available at https://web.archive.org/web/19971210170704/http://hoohoo.ncsa.uiuc. edu/cgi/intro.html
1030 M. Horton, R. Adams, “Standard for Interchange of USENET Messages,” Internet RFC 1036 (Dec. 1987) (“RFC 1036”)
1031 J.S. Quarterman, The Matrix: Computer Networks and Conferencing Systems Worldwide, 1990 (“Quarterman”)
1032 “Google Acquires Usenet Discussion Service and Significant Assets from Deja.com,” captured Feb. 16, 2001, available at https://web.archive.org/web/20010216202357/http://www.google.com /press/pressrel/pressrelease48.html
1033 “Google Acquires Deja’s Usenet Archive: Google Releases Beta Service in Transition,” captured Feb. 17, 2001, available at https://web.archive.org/web/20010217005302/http://groups.google.co m:80/
1034 Google Groups Beta, captured May 12, 2001, available at https://web.archive.org/web/20010512173704/http://groups.google.co m:80/
1035 “Full Usenet Archive Now Available,” Google Groups Beta, Captured May 7, 2012, available at https://web.archive.org/web/20010507171811/http://groups.google.co m/googlegroups/archive_announce.html
1036 “Google Groups Archive Information,” Dec. 21, 2001, available at https://groups.google.com/forum/message/raw?msg=news.admin.misc /1GuWaOCDgMc/x7PnQ5BQ7G0J.
v Petition for IPR of U.S. Patent 6,374,359
1037 “20 Year Usenet Archive Now Available,” captured on Dec. 12, 2001, available at https://web.archive.org/web/20011212191924/http://www.google.com /googlegroups/archive_announce_20.html
1038 IETF Mail Archive, RFC 2068 publication, Jan. 2, 1997, available at https://mailarchive.ietf.org/arch/search/?q=subject%3A%28RFC+206 8%29
1039 E. Raymond, This is the Jargon File, Version 2.9.6, Aug. 16, 1991, available at http://jargon-file.org/archive/jargon-2.9.6.dos.txt
1040 V. Khera, Using Set-cookie and Location in the same header?, post to the comp.infosystems.www.authoring.cgi group on June 13, 1996
1041 M. Budash, HTTP Header Syntax, post to the comp.infosystems.www.authoring.cgi group on July 30, 1997
1042 D. Crichton, Setting a cookie and redirecting in the same perl script, post to the comp.infosystems.www.authoring.cgi group on Feb. 3, 1998
1043 C. Saia, Make clients forget passwords, post to the comp.infosystems.www.servers.unix group on Dec. 26, 1997
vi Petition for IPR of U.S. Patent 6,374,359
I. INTRODUCTION
Petitioners request inter partes review (“IPR”) under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42.100 et seq. of Claims 1-16 (“the Challenged Claims”) of U.S.
Patent No. 6,374,359 (“the ’359 Patent”).
Petitioners assert the Challenged Claims are unpatentable and request review and cancellation of the Challenged Claims under 35 U.S.C. § 103.
Summary of Unpatentability Grounds
Ground Summary 1 Claims 1, 5, and 6 are obvious in view of Reiche and Fisher 2 Claims 2, 3 and 4 are obvious in view of Reiche, Fisher, and Stubbs 3 Claims 7, 8, and 9 are obvious in view of Reiche, Fisher, and the LDAP Draft 4 Claim 10 is obvious in view of Reiche, Fisher, and Goodman 5 Claims 11, 12, and 13 are obvious in view of Reiche, Fisher, Goodman, and Stubbs 6 Claims 14, 15, and 16 are obvious in view of Reiche, Fisher, Goodman, and the LDAP Draft
II. MANDATORY NOTICES, STANDING, AND FEES
Mandatory Notices
Real Party in Interest: The real parties in interest are the Petitioners (Expedia,
Inc.; Homeaway.com, Inc.; Hotels.com L.P.; Hotwire, Inc.; and Orbitz, LLC) and
Expedia Group, Inc.; Hotels.com GP, LLC; HRN 99 Holdings; Travelscape LLC.;
HomeAway Holdings, Inc., Orbitz Worldwide, Inc.; Orbitz Worldwide, LLC; and
Orbitz, Inc.
1 Petition for IPR of U.S. Patent 6,374,359
Related Matters: The ’359 Patent is subject to a pending lawsuit entitled
International Business Machines Corp. v. Expedia, Inc. et al., Case No. 1:17-cv-
01875-LPS-CJB (D. Del.) (the “Litigation”) in which the Petitioners are defendants.
In addition, Petitioners have filed petitions for IPR against other patents held by
Patent Owner, including IPR2018-01134, IPR2018-01354, and IPR2018-01459 against U.S. Patent No. 5,961,601; IPR2018-01135 and IPR2018-01136 against U.S.
Patent No. 5,796,967; IPR2018-1685 and IPR2019-00404 against the U.S. Patent
No. 7,631,346; and IPR2018-01743 against U.S. Patent No. 7,072,849. Petitioner was served with an amended complaint asserting the ’359 Patent in the Litigation on
July 12, 2018.
Lead Counsel: Lead Counsel is Brian W. Oaks, Reg. No. 44,981, of Baker
Botts L.L.P., and Back-up Counsel are Chris V. Ryan, Reg. No. 54,759, of Baker
Botts L.L.P. and Mark Speegle, Reg. No. 77,512 of Baker Botts L.L.P.
Service Information: Baker Botts L.L.P., 98 San Jacinto Boulevard, Suite
1500, Austin, Texas 78701-4078; Tel. (512) 322-2500; Fax (512) 322-2501.
Petitioners consent to service by electronic mail at
[email protected]. A Power of Attorney is filed concurrently herewith under 37 C.F.R. § 42.10(b).
2 Petition for IPR of U.S. Patent 6,374,359
Certification of Grounds for Standing
Petitioners certify the ’359 Patent is available for IPR. Petitioners are not barred or estopped from requesting IPR of the ’359 Patent.
Fees
The Office is authorized to charge any fees that become due in connection with this Petition to Deposit Account No. 02-0384, Ref. No. 082332.0109, as well as any additional fees that might be due in connection with this Petition.
III. OVERVIEW OF THE ’359 Patent
Subject Matter of the ’359 Patent
The ’359 Patent describes a method for authenticating a Web browser user that requires a Web browser to refresh a webpage, thereby allowing the server to confirm that the browser set a requested cookie. EX1001, Abstract, 1:66-2:3, 4:53-
65. Figure 3 illustrates this method:
3 Petition for IPR of U.S. Patent 6,374,359
EX1001, Figure 3
4 Petition for IPR of U.S. Patent 6,374,359
Setting a cookie to authenticate a Web browser user was well-known before the ’359 Patent. EX1001, 1:38-47; EX1002, ¶78. Cookies are objects (e.g., text) a
Web browser may store and resend to a Web server. Id. Cookies may be received from a server when the user visits a website and may be sent back to the server when the user requests a page hosted by the server. Id. Cookies consist of a string of information, such as user-identification information, and they can be used to maintain state variables during HTTP communications. Id., see also EX1005, 2:17-
19. The ’359 Patent purports to improve on known techniques for using cookies to authenticate a Web browser user by addressing existing problems, such as detecting when a browser is refusing to accept cookies. EX1001, 1:38-50.
Claims of the ’359 Patent
The ’359 Patent was filed as U.S. Patent Application No. 09/195,859 on
November 19, 1998. It does not claim priority to any earlier application. EX1001.
November 19, 1998 is the earliest priority date for the Challenged Claims.
The ’359 Patent’s independent claims use a “refresh object” or “refresh page” for checking a Web browser user’s cookie. EX1001, 9:45-55, 10:28-40. Claim 1 of the ’359 Patent is directed to a method of enabling a Web browser user to interact with an application including the steps of: setting a cookie at a Web browser; redirecting the Web browser to a refresh object; determining if the cookie is valid; and, if the cookie is valid, enabling the user to access the application. Id., 9:45-55.
5 Petition for IPR of U.S. Patent 6,374,359
Claim 10 is directed to a similar method, plus: requiring a valid user login at the
Web server; using a refresh page instead of a refresh object; specifying the cookie be returned to the browser in the refresh page; and using a parameter in determining if the cookie is valid. Id., 10:28-40.
Dependent Claims 2 and 11 each recite additional requirements for the formation and encryption of the claimed cookie, such as requiring the cookie include a username and password. EX1001, 9:56-63, 10:41-47. Claims 3 and 12 further require the claimed cookie include an IP address. Id., 9:64-65, 10:48-49. Claim 4 recites steps for determining whether the cookie is valid, including checking the IP address before checking the username and password. Id., 9:66-10:12, 10:50-64.
Claims 5 and 6 recite additional steps for Claim 1 that are already recited in
Claim 10: the returning of the cookie from a user to the server, and the occurrence of a user login at the Web server. Id., 10:12-18. Claims 7-9 and 14-16, describe implementations where the application a user seeks to access is an LDAP interface.
Id., 10:19-27, 10:65-11:6.
Prosecution History of the ’359 Patent
During prosecution, the Examiner rejected original Claim 1 of the ’359 Patent application based on Reiche. EX1004, 78. The Examiner concluded Reiche disclosed or rendered obvious at least the following features (see EX1004 at 78-80):
constructing a cookie;
6 Petition for IPR of U.S. Patent 6,374,359
issuing the cookie to a client browser;
a redirect procedure where a client browser is reconnected to detect a cookie;
ensuring the cookie is valid;
including information such as ID, password, and other information in the
cookie;
encrypting and encoding a cookie;
including the IP address as other information in the cookie;
encrypted data needs to be decrypted in order to gain access to the
information;
enabling the user to interact with the application once the user name and
password matches; and
having the ability to exit or log off of a site and access another server.
Claim 1 was eventually allowed over Reiche after Patent Owner amended the claim to include a “refresh object.” EX1004, 91 and 102. Claims 11-21 of the ’359 Patent were allowed as presented because the Examiner’s “search of the prior art fails to reveal use [of] ‘a refresh page the redirect HTTP flow back to itself’.” EX1004, 102.
This history shows that the Examiner’s basis for distinguishing the ’359 Patent from Reiche lies in how Reiche instructs a Web browser to refresh a
7 Petition for IPR of U.S. Patent 6,374,359 webpage, compared with the “refresh page” or “refresh object” in the ’359 Patent.
See EX1004, 80 and 104. Reiche describes the use of a 302-redirect (i.e., an HTTP- standard header-redirect using response headers), while the ’359 Patent describes the use of HTML performing the refresh, specifically an HTTP-Equiv=“Refresh” metatag (i.e., the “refresh object” within the HTML code). Compare EX1005, 10:39-
42 with EX1001, 6:1-11 and Figure 7. This distinction matters because HTTP headers are generated differently and segregated from the HTML code comprising a webpage. EX1002, ¶¶83, 129; see also EX1009, § 6.1.1 (explaining 302 status code for Redirection).
However, this distinction between Reiche and the ’359 Patent is not a patentable distinction. During prosecution, the Examiner was not informed the
HTML metatag mechanism for causing a refresh (as in the ’359 Patent) was a well- known alternative to header-redirects (as in Reiche). See EX1002, ¶¶146-48;
EX1006, 319-20. Petitioner submits the ’359 Patent would never have issued if the
Examiner had been informed such HTML mechanisms were known.
Ordinary Skill in the Art
A person of ordinary skill in the art (POSITA) for the ’359 Patent would be a person with an undergraduate degree or equivalent in computer science with two years of experience related to distributed systems and/or network applications, or a master’s degree or equivalent in computer science. EX1002, ¶66. A person with less
8 Petition for IPR of U.S. Patent 6,374,359 education, but more relevant practical experience, is also a person of ordinary skill in the art. Id.
IV. SUMMARY OF PRIOR ART
The following prior art demonstrates the Challenged Claims would have been obvious to a POSITA at the time of the ’359 Patent. EX1002, ¶¶132-36.
Reiche
U.S. Patent No. 6,092,196 (“Reiche”) was filed on November 25, 1997. Thus,
Reiche is prior art at least under § 102(e).
None of the prior art references presented herein for combination with Reiche were considered during prosecution of the ’359 Patent. Most importantly, the
Examiner did not identify or substantively examine any references disclosing the
HTML-Refresh metatag, such as Fisher. Because this petition, therefore, includes substantially different arguments and combinations never presented during prosecution, the Board should institute this proceeding and not exercise its discretion to deny this petition under 35 U.S.C. § 325(d). See Mitsuba Corporation et al v.
Intellectual Ventures II LLC, PTAB-IPR2018-00071, Paper 7 at 40-41 (PTAB Apr.
23, 2018); HyperBranch Medical Technology, Inc. et al v. Confluent Surgical, Inc. et al, PTAB-IPR2018-01099, Paper 14 at 15-17 (PTAB Nov. 27, 2018) (permitting
9 Petition for IPR of U.S. Patent 6,374,359 review because the combination of references “not before the Examiner” fills gaps in a previously examined reference).
1. Reiche Discloses Using An Encrypted Cookie To Authenticate A User
Reiche describes a multi-step process where a Web browser is transferred between a customer server hosting a resource requested by the user and an authentication server. The later stages of this process involve setting and checking an encrypted cookie to validate the user. See, e.g., EX1005, 1:22-26, 3:8-21, 3:60-
64, 4:5-9.
The process in Reiche begins when a Web browser user (“client 100”) requests a resource from customer server 120 by providing a URL. EX1005, 8:47-
52. The URL from the user includes an address for “Authentication Daemon 124” on customer server 120. Id., 8:47-52.
10 Petition for IPR of U.S. Patent 6,374,359
EX1005, Figure 1 (annotated)
The first time a Web browser user requests access to the customer server, the user will not have the necessary cookie to access the customer server, nor will the user have a “special URL” that would prompt the server to provide the cookie. Id.,
8:55-61. Instead, the user is given a special URL and redirected via an HTTP- standard header-redirect to the authentication server. Id., 9:6-11.
11 Petition for IPR of U.S. Patent 6,374,359
header- redirect
EX1005, Figure 1 (annotated)
Reiche’s authentication server then instructs user’s browser to prompt the user for login information. Id., 9:15-30. If the user provides a valid login, the authentication server stores information about the Web browser user and sends the user (via a header-redirect) back to Authentication Daemon (AD) 124 on the customer server 120, this time with another special URL. Id., 9:38-56.
12 Petition for IPR of U.S. Patent 6,374,359
header-redirect after authentication
EX1005, Figure 1 (annotated)
When the Web browser user returns to AD 124 with the special URL, AD 124 instructs the browser sets an encrypted cookie. Id., 9:57-59, 10:17-21. Specifically, after the valid login is confirmed, AD 124 constructs a cookie for the Web browser user “out of memory table 122 row ID, client ID and the new transaction ID.” Id.,
10:15-24. Reiche states the cookie holds “the user ID and the authentication server
13 Petition for IPR of U.S. Patent 6,374,359 user information.” Id., 6:37-40. Reiche further teaches the cookie is both encrypted and encoded. Id., 10:21-24.
2. Reiche Discloses Redirecting From A Location Back To Itself To Check For A Cookie
Once the encrypted cookie is constructed, AD 124 on customer server 120 send the Web browser a 302-redirect to the originally requested URL (green arrow), this time including the cookie in the HTTP response header. EX1005, 10:21-27. The referenced URL from step 200 refers to the URL for the originally requested resource, which includes the location of AD 124 on customer server 120. Id., 8:49-
51. When the Web browser reconnects with AD 124 (blue arrow), AD 124 will detect the presence of the cookie and verify identification information from the cookie. Id., 10:42-47.
14 Petition for IPR of U.S. Patent 6,374,359
EX1005, Figure 1 (annotated)
3. Reiche Discloses Checking Transaction Details Stored In Cookie Before Basic Authentication
After setting an encrypted cookie and redirecting the Web browser user back to itself, Reiche discloses additional steps of verification. One of these verification steps involves checking specific transaction details stored in the cookie: “The row
ID, client ID and transaction ID are determined from the cookie, and at step 262 and
15 Petition for IPR of U.S. Patent 6,374,359
264, are verified against the memory table 122.” Id., 10:44-47. Then “the customer
HTTP server 126 performs basic authentication as it normally would.” Id., 11:1-2; compare Figure 2d (steps 262 and 264 preceding “G”) with Figure 2e (step 282
“Basic authentication” is subsequent to “G”).
The industry standards for HTTP at the time of Reiche describes Basic
Authentication, which includes checking a user ID and password (“user-pass”) provided in a “basic-cookie:”
EX1009, § 11.1; see also EX1002, ¶144.
Spinning the Web by Yuval Fisher
Spinning the Web by Yuval Fisher (“Fisher”) was published in 1996 by
Springer-Verlag New York, Inc. EX1006. Fisher was received, cataloged, indexed,
16 Petition for IPR of U.S. Patent 6,374,359 and sent to the general collection at the Library of Congress by April 1, 1996.2
EX1012, ¶32; EX1016, Attachment 1A-1D. Likewise, Fisher was received, cataloged, indexed, and made publicly available at the University of Texas at Austin
Library and Auburn University no later than April 23, 1996. EX1012, ¶¶35-38;
EX1016, Attachment 1E-1H. The public availability of Fisher is specifically confirmed by the MARC record for the copy of Fisher held by the University of
Texas at Austin, which includes the date entry “19960423145357.0” for the field
“005.” EX1012, ¶36; EX1016, Attachment 1F. This entry indicates that Fisher had been acquired and/or catalogued by the University of Texas at Austin Library on
April 23, 1996. EX1012, ¶36. It was common practice to shelve a book within weeks of the MARC record being created, and the book at least would have been accessible at that point. Id., ¶19. Accordingly, Fisher is a printed publication predating the filing date of the ’359 Patent by more than a year, and therefore qualifies as prior art under
§§ 102(a) and 102(b). Fisher was not considered during the prosecution of the ’359 Patent.
2 In an unrelated litigation, Patent Owner did not dispute Fisher’s publication and publicly availability on February 23, 1996. EX1014, 34 n.13.
17 Petition for IPR of U.S. Patent 6,374,359
1. Fisher Discloses Refreshing A Webpage Using An HTML Refresh Metatag
Fisher is an instruction book on Website design and Web server configuration that addresses providing dynamic content to a client (i.e., a Web browser). EX1006, vii (Preface), 319. Fisher explains servers and browsers communicate using HTTP requests and response, and HTTP responses from a server may precede HTML elements defining a webpage. Id., 45-47 and 59; EX1002, ¶145.
Fisher identifies two ways to implement a “client-pull” method for causing a browser to repeatedly request information from a server over time. EX1006, 319.
One way is for a server to include an HTTP response header for “Refresh” when transmitting the website to the client, such as in the following example:
Id., 319. As an HTTP header directing the Web browser to reconnect to the same location, this HTTP “Refresh” header is analogous to the header-redirect described in Reiche for reconnecting a Web browser user to AD 124. EX1005, 10:24-27;
EX1002, ¶146. Fisher explains this server-controlled header causes a Web browser to wait 12 seconds (“Refresh:12”) before rerouting the browser to the URL specified
(“URL=http://host/next.html”). EX1006, 319.
The alternative method in Fisher for returning the user to the same page is the
HTTP-EQUIV=REFRESH HTML metatag. Id., 319-320. An HTML metatag is a
18 Petition for IPR of U.S. Patent 6,374,359 part of the HTML head (different from the HTTP header—the HTML head is inside the Web page) emulating the function of an HTTP header. Id., 207-208. Fisher provides an example of the HTML-Refresh metatag:
Id., 319. This HTML metatag implementation produces the same result as the HTTP response header example above: the client will wait 12 seconds and then reroute the browser to the URL in the metatag. Id. While the response header and metatag results are the same, Fisher notes a difference in these two implementations: “the HTTP header cannot be included in an HTML document,” i.e., the HTTP header is controlled by the server and cannot be embedded in the HTML content of the webpage. Id., 320.
Notably, Fisher also states the URL included in both “client-pull” implementations is optional. Id., 320. If no URL is included, “the current document is reloaded.” Id., 320. Thus, Fisher demonstrates the HTML-Refresh metatag was a known way to cause a webpage to redirect to itself.
Stubbs
“Stubbs” is a public Usenet posting by an author identified as “Nesta Stubbs” on July 3, 1996 in response to a post “From: afr…@musc.edu (Lawrence B. Afrin,
M.D.)” on a thread titled One-time authentication for multiple Web servers?
EX1007, 1. The Stubbs post appeared publicly in the following newsgroups on
19 Petition for IPR of U.S. Patent 6,374,359
July 3, 1996: comp.infosystems.www.servers.misc, comp.infosystems.www. servers.ms-windows, and comp.infosystems.www.servers.unix. Usenet was a widely accessible, public electronic bulletin board system, and evidence indicates the Stubbs post was publicly available in July of 1996. Id.; EX1002, ¶¶ 149, 151.
Stubbs was not considered during the prosecution of the ’359 Patent.
The Stubbs July 3 post would be understood by a person of ordinary skill in the art to be part of a larger conversation identified in the Usenet post thread, including at least the following:
20 Petition for IPR of U.S. Patent 6,374,359
Author Date Message-ID
Nesta Stubbs 1996/06/26 <[email protected]>#1/1
Vivek Khera 1996/06/27
Lawrence B. Afrin, 1996/06/29 <[email protected]>#1/1 M.D.
Nesta Stubbs 1996/06/29 <[email protected]>#1/1
Lawrence B. Afrin, 1996/06/30 <[email protected]>#1/1 M.D.
Nesta Stubbs 1996/06/30 <[email protected]>#1/1
Tom Arthur 1996/07/02 <01bb681e.fec2afa0$412254a0@arthugt. framatech.com>#1/1
Tom Arthur 1996/07/02 <01bb681e.fec2afa0$412254a0@arthugt. framatech.com>#1/13
Kyler Laird 1996/07/02 <[email protected]>#1/1
Lawrence B. Afrin, 1996/07/03 <[email protected]> M.D.
Nesta Stubbs 1996/07/03 <[email protected]>
Nathan J. Kurz 1996/07/12 <[email protected]>#1/1
See EX1015; EX1002, ¶¶151-69 (Mr. Moore verified the publication dates of the
Stubbs Usenet post based on these unique Message-IDs).
3 Note the two messages by Tom Arthur have the same Message-ID and
therefore appear to be duplicate posts.
21 Petition for IPR of U.S. Patent 6,374,359
Because Stubbs was published more than a year before the filing date of the ’359 Patent, as discussed in further detail below, and because Patent Owner has not alleged any earlier priority date from the filing date of the ’359 Patent, Stubbs is prior art under § 102(a) and/or § 102(b).
1. Stubbs Discloses Using An Encrypted Cookie With A Username, Password, And IP Address To Authenticate A User
The Stubbs Usenet post continued an ongoing conversation about potential ways to enable one-time authentication of a user for multiple servers, and a particular proposed solution using cookies. EX1007, 1-2. Other posters on the conversation expressed concern that cookies “are not secure” and “are subject to tampering unless encrypted, [and] can be exchanged between machines unless encoded with ip (sic) address[.]” Id., 1. Nesta Stubbs responded to these concerns by reiterating a suggestion to do exactly that—to encrypt and encode the cookie. Id. (“Which is what
I suggested…”). Nesta Stubbs further specifies the cookie can be “a combination of
IP address, username, password, date, and other info[.]” Id.
2. Stubbs Is A Usenet Post That Was Publicly Available
Other PTAB panels and the Federal Circuit have affirmed that Usenet posts qualify as prior art printed publications. See Suffolk Techs., LLC v. AOL Inc., 752
F.3d 1358, 1364-65 (Fed. Cir. 2014); EMC Corp. et al. v. PersonalWeb
Technologies, LLC et al., IPR2013-00085, 2014 WL 2090664, *9 (May 15, 2014),
22 Petition for IPR of U.S. Patent 6,374,359 aff’d sub nom Pers. Web Techs., LLC v. EMC Corp., 612 F. App’x 611, 612 (Fed.
Cir. 2015); Rackspace US, Inc. et al. v. PersonalWeb Technologies, LLC et al.,
IPR2014-00059, Paper 9 at 33-34 (April 15, 2014).
Consistent with this precedent, Usenet postings were well-known in the 1996-
1998 timeframe as a source of technical conversations regarding computer network and website configurations. EX1002, ¶¶107, 110. A POSITA would have understood postings to Usenet groups to be a useful source of relevant technical information and would likely have subscribed to these Usenet groups to regularly receive posts to the Usenet groups. Id. The Stubbs reference was posted to three newsgroups each under the comp.infosystems.www.servers hierarchy (.misc, .unix, and .ms-windows), which means these posts were automatically disseminated to subscribers and also readily accessible and searchable by non-subscribers. Id.,
¶¶107-08, 153.
The Google Groups archive is a well-known and trusted source for such postings. EX1002, ¶159. Deja News began archiving Usenet posts in 1995, until
Google acquired this Usenet archive from Deja News in 2001 and rebranded it as
“Google Groups.” Id. Through the Google Groups archive, postings such as the
Stubbs reference have remained publicly accessible, well-organized, and searchable.
Id.
23 Petition for IPR of U.S. Patent 6,374,359
Google Groups maintains an accurate copy of the original posting for Usenet posts, including a reference to the original posting date. EX1002, ¶¶159-68. Even though the “Date” field shown in the archived posts appears to be a later recreation of the message date, the “Message-ID” field can be used to confirm the “Date” field is accurate. Id. The “Message-ID” is a field created by message-posting software based on the time and date the message was created, among other inputs. Id. For example, the Stubbs July 3, 1996 message (<[email protected]>) corresponds with an input date of 07/04/1996, 02:49:34 GMT. Id., ¶168.4 The consistency between the “Message-ID” field and “Date” field confirms Google
Groups has accurately maintained a record of the posts in the Stubbs reference.
Goodman
Danny Goodman’s JavaScript Handbook by Danny Goodman (“Goodman”) was published in 1996 by IDG Books Worldwide, Inc. EX1010; EX1012, ¶41.
Goodman was “cataloged and made accessible to the public through the University of North Texas library no later than October 29, 1996.” EX1012, ¶¶42-45; EX1017,
Attachment 2A. The public availability of Goodman is specifically confirmed by the
MARC record for the copy of Goodman held by the University of North Texas,
4 2:49 AM Greenwich Mean Time on July 4 corresponds to 11:49 PM Eastern
Time on July 3.
24 Petition for IPR of U.S. Patent 6,374,359 which includes the date entry “19961029151529.0” for the field “005.” EX1012,
¶43; EX1017, Attachment 2C. This entry indicates that Goodman had been acquired and/or catalogued by the University of North Texas Library on October 29, 1996.
EX1012, ¶43. It was common practice to shelve a book within weeks of the MARC record being created and that it at least would have been accessible at that point.
EX1012, ¶19. Accordingly, Goodman is a printed publication predating the filing date of the ’359 Patent by more than a year and therefore qualifies as prior art under
§§ 102(a) and 102(b). Goodman was not considered during the prosecution of the ’359 Patent.
Goodman contains code for creating, reading, and deleting cookies. EX1010,
160-63. While the industry standard approach for setting a cookie includes a server configuration that sets a cookie using an HTTP header (see EX1008, § 4.2.1),
Goodman discloses creating a cookie using JavaScript embedded in a webpage.
EX1010, 160-62 (the JavaScript “SetCookie” function enables a developer to “create or update a cookie”); EX1002, ¶172.
LDAP Draft and RFCs
The C LDAP Application Program Interface (the “LDAP Draft”) defines an application program interface (API) to the “lightweight directory access protocol”
(“LDAP”). EX1011, § 2. The ’359 Patent states LDAP was a well-known
“standalone directory service that has begun to obtain wide acceptability.” EX1001,
25 Petition for IPR of U.S. Patent 6,374,359
4:21-23. At the time of the ’359 Patent, LDAP was an industry standard application protocol for accessing and maintaining directory information, such as email or telephone directories. EX1002, ¶180; EX1001, 4:10-26. The Working Draft describes various operations using an LDAP interface, including: (1) authenticating a session; (2) connecting to the LDAP directory and retrieving data; and (3) closing the session. See EX1011, §§ 4, 7.4-7.5, 7.10.
The LDAP Draft was published as a revision of RFC 1823 on July 29, 1997.
EX1011; EX1002, ¶179. Like other RFCs, the LDAP Draft was available on the publication date appearing in the upper right corner of each page—July 29, 1997.
EX1002, ¶189 (Mr. Moore is an expert in the workings of the IETF and its practices for publishing RFCs). As a “Standards Track” document and consistent the procedures laid out in RFC 2026, the LDAP Draft was provided to the RFC Editor for distribution to the IETF and its working groups for “review and revision.” Id.,
¶¶190-91. By 1997, the RFC Editor had thousands of subscribers that received emails containing instructions for accessing pending drafts prior to their final publication. Id. The publication date, as shown in the upper right-hand corner of each page of an RFC (or a draft such as the LDAP Draft), is the date of the announcement to the subscriber lists and the date on which the RFC became available to the public online. Id., ¶189.
26 Petition for IPR of U.S. Patent 6,374,359
In addition, the ’359 Patent incorporates by reference the LDAP Draft, and more generally cites to both RFCs and Internet-Drafts as published and available to the public. EX1001, 3:51-54; 4:23-26. At least one patent application filed by IBM more than one year before the filing date of the ’359 Patent cites the LDAP Draft and incorporates it by reference. See, e.g., U.S. Patent No. 6,339,827, 4:49-52. For at least these reasons, the LDAP Draft is prior art to the ’359 Patent under § 102(a) and (b).
Other PTAB panels and the Federal Circuit have affirmed RFCs qualify as prior art printed publications. See, e.g., Apple Inc. v. Virnetx Inc., IPR2014-00238,
2015 WL 2251196 (May 11, 2015), aff'd sub nom. VirnetX Inc. v. Apple Inc., 665
Fed. Appx. 880 (Fed. Cir. 2016); Samsung Elecs. Co., Ltd. v. IXI Ip, LLC, IPR2015-
01444, 2016 WL 11489261 (Dec. 21, 2016), aff'd sub nom. IXI IP, LLC v. Samsung
Elecs. Co., Ltd., 903 F.3d 1257 (Fed. Cir. 2018); Cisco Sys., Inc. v. AIP Acquisition
LLC, IPR2015-00307, 2016 WL 2909189 (May 18, 2016), aff'd sub nom. AIP
Acquisition LLC v. Cisco Systems, Inc., 714 Fed. Appx. 1010 (Fed. Cir. 2017);
Limelight Networks, Inc. v. Akamai Techs., Inc., IPR2016-01631, 2017 WL
4861937, at *7 (Oct. 25, 2017). Additionally, Patent Owner has relied on RFCs to invalidate other patents. See, e.g., Int'l Bus. Machines Corp. v. Intellectual Ventures
II LLC, IPR2014-00660, 2015 WL 6180896, at *29 (Oct. 19, 2015).
27 Petition for IPR of U.S. Patent 6,374,359
1. RFCs 2068 and 2109
RFCs 2068 and 2109 are also “Standards Track” documents including publication dates on each page and requesting “discussion and suggestions for improvements.” EX1009; EX1008; EX1002, ¶¶174-78, 182, 189. For the same reasons described for the LDAP draft, RFC 2068 and RFC2109 also would qualify as prior art printed publications as to the ’359 Patent under § 102(a) and (b).
RFC 2068 specified the Internet standard governing HTTP as of January
1997, prior to the application for the ’359 Patent, and includes a discussion of “Basic
Authentication” where a “basic-cookie” is an encoded combination of a username and password. EX1002, ¶¶174-75; EX1009, § 11.1. Similarly, RFC 2109 describes the Internet standard by which Web servers and browsers set and return cookies.
EX1002, ¶177; EX1008, § 4. RFC 2109 standard teaches that after a server sets a cookie, the browser includes the cookie in future communications to the server.
EX1002, ¶177; EX1008, §§ 4.2.1, 5.2.
V. CLAIM CONSTRUCTION
Claim terms “shall be construed using the same claim construction standard that would be used to construe the claim in a civil action under 35 U.S.C. § 282(b), including construing the claim in accordance with the ordinary and customary meaning of such claim as understood by one of ordinary skill in the art and the prosecution history pertaining to the patent.” 37 C.F.R. § 42.100(b).
28 Petition for IPR of U.S. Patent 6,374,359
Petitioner and Patent Owner disputed the following constructions in the co-pending district court litigation:
“refresh object”
Petitioner: “HTML code for causing a IBM: “a resource to which the web
Web browser to refresh the page” browser is redirected”
“refresh page”
Petitioner.: “page containing HTML IBM: “content that redirects the web code for causing a Web browser to browser” refresh the page”
“returning the cookie to the Web browser in a refresh page the redirects HTTP flow back to itself with a given parameter”
Petitioner: “returning HTML code to IBM: “returning the cookie to the Web the Web browser in a page that (1) browser in a refresh page that redirects instructs a Web browser to set the HTTP flow back to itself with a given cookie, and (2) causes the Web parameter” browser to refresh the page with a given parameter”
29 Petition for IPR of U.S. Patent 6,374,359
“redirects/redirecting [x]”
Petitioner: No construction necessary. IBM: “instructs/instructing [x] to go to
Or, alternatively: “instructs/instructing a separate object, such as a page”
[x] to go to an object or page”
Petitioners submit the Challenged Claims should be found obvious under any of the above constructions. However, for resolution of any doubt, Petitioners submits that its above proposals should be adopted.
The claims, specification, and prosecution history all point to the constructions of “refresh object” and “refresh page” proposed by Petitioner. The terms “object” and “page” are commonly used to describe HTML webpages, especially in the context of the Internet. EX1002, ¶127. The word “refresh” also has a common meaning in this context: everyone who has used a Web browser knows that the “refresh” button refreshes (reloads) the current webpage. Id. Petitioner’s proposed constructions for “refresh object” and “refresh page” are thus consistent with these ordinary meanings.
The specification further confirms Petitioner’s proposals. EX1002, ¶127. The sole mechanism in the specification for causing a Web browser to reconnect with a server is an HTML metatag entitled HTTP–EQUIV=“Refresh”. This is shown in
30 Petition for IPR of U.S. Patent 6,374,359
Figure 7 of the ’359 Patent, which “illustrates a representative refresh page[.]”
EX1001, 6:4-5.
EX1001, Figure 7
EX1001, Figure 7 (highlight and underline added). As such, the “refresh object” and
“refresh page” in the ’359 Patent refer to HTML code (or, respectively, a page containing such code) that causes a Web browser to refresh a webpage, i.e., to
“redirect the HTTP flow back to itself.”
The prosecution history further confirms Petitioner’s proposed constructions.
EX1002, ¶128. The Examiner concluded that Reiche discloses every element in
31 Petition for IPR of U.S. Patent 6,374,359
IBM’s original claim 1, including reconnecting a Web browser to a resource after a cookie is set to confirm that a valid cookie was set. Id. EX1004, 78 (citing
EX1005,10:32-35 and 10:40-48). Still, the Examiner concluded that Reiche did not disclose either a “refresh object” (originally in dependent claim 6) or “refresh page”
(original independent claims 11, 18). EX1004, 80 and 103. Thus, the Examiner must have understood that the claimed “refresh object” and “refresh page” referred to something different from the redirecting process in Reiche.
A proper construction of “refresh object” and “refresh page” should recognize the differences between Reiche and the ’359 Patent that led the Examiner to grant the patent: Reiche uses a server-based 302 redirect to reconnect the Web browser to the server and check the cookie, while the ’359 Patent uses a specific HTML code to perform this refresh. In contrast, Patent Holder’s proposed constructions eliminate both the specific action of reloading the requested webpage (refresh) and the specific mechanism (i.e., HTML code) used to accomplish that action. Broadening the claims to include any server-based redirect to a different resource, rather than a browser- based refresh of the requested page, would improperly eliminate the distinction on which the Patent Office relied in issuing the patent and grossly distort the proper scope of the claims.
Petitioner’s proposed construction for “returning the cookie to the Web browser in a refresh page th[at] redirects HTTP flow back to itself with a given
32 Petition for IPR of U.S. Patent 6,374,359 parameter” is correct for the same reasons. The only distinction between “refresh object” and “refresh page” flows from the language of the claims themselves. Most notably, claim 10 adds the requirement that a cookie be set “in” the refresh page, which distinguishes other techniques and other claims of the ’359 Patent, such as setting a cookie in HTTP headers preceding an HTML page in a server response.
EX1002, ¶129. As such, the “refresh page” itself in claim 10 must not only cause a
Web browser to refresh a page (e.g., redirect the HTTP flow back to itself), but must also include something setting the cookie.
Conversely, there is no support in the ’359 Patent for Patent Owner’s suggestion that a “refresh object” is the location that a browser is redirected to while a “refresh page” is the content that causes the redirection—the patent is clear that the “refresh page” and “refresh object” are interchangeable. See EX1001, 8:41-43
(“This is accomplished by the present invention by using a refresh object or page to allow the LDAP GUI CGIs to automatically determine if the cookie was set.”).
Patent Holder’s suggestion that “redirect[ing]” (in isolation) requires a separate resource is unsupported. This is contradicted both by the specification and the plain language of claim 10 that recites the refresh page redirecting the HTTP flow back to itself. See also EX1001, 6:9-11 (“As will be seen, the refresh page redirects HTTP flow back to itself with the parameter to check if the cookie was
33 Petition for IPR of U.S. Patent 6,374,359 set.”). It is unclear how redirecting anything “back to itself” could be consistent with
IBM’s suggestion that “redirecting” must only be to a separate (different) object.
In the event that the Board disagrees with Petitioner’s proposed constructions,
Petitioner submits that an inter partes review should still be instituted. See EX1002,
¶131. While different portions of the prior art references and different combinations may be more relevant under Patent Owner’s interpretation—compared with the portions cited in this Petition using a proper claim construction—there can be no doubt the prior art identified here still satisfies the broader claim scope suggested by Patent Owner. For example, Reiche discloses AD 124 on the customer server issues a header-redirect sending the client Web browser to the originally requested
URL, this time with the cookie in the HTTP response header. EX1005, 10:24-27.
Upon receiving the redirected browser, AD 124 in Reiche then checks the cookie.
Id., 10:40-48. Thus, under Patent Owner’s construction, there would be no need to combine Reiche with Fisher, or with Goodman. Reiche alone would anticipate claims 1 and 10, and Reiche in combination with Stubbs and/or the LDAP Draft would render all remaining claims obvious. EX1002, ¶131.
Lastly, the parties agreed to the following constructions in the district court:
“application” - any program, routine, or algorithm
34 Petition for IPR of U.S. Patent 6,374,359
“encrypting” - Plain and ordinary meaning, which is reversibly
transforming data to prevent unauthorized access
“LDAP GUI interface” - Plain and ordinary meaning, which is a graphical
user interface for accessing an LDAP directory
Petitioners do not believe any other claim terms require construction for resolution of this Petition. However, should any other claim construction dispute arise, Petitioners reserve the right to challenge the construction of claims in the ’359 Patent in this proceeding or any other.
VI. THE CHALLENGED CLAIMS ARE UNPATENTABLE
Ground 1
The combination of Reiche and Fisher, when considered with the knowledge of a POSITA, renders Claims 1, 5, and 6 obvious under 35 U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche and Fisher
A POSITA would be motivated to replace the server-based 302-redirect of
Reiche with the HTML meta Refresh metatag taught by Fisher to ensure consistent browser behavior. In some contexts, when a program on a server outputs a webpage with both a 302-redirect and another HTTP header (such as a Set-Cookie header), there is a chance the server may ignore the other header and pass only the 302- redirect to the browser. EX1002, ¶¶98, 100, 195, 205. In other words, if a webpage
35 Petition for IPR of U.S. Patent 6,374,359 is supposed to be delivered both with a 302-redirect and with a Set-Cookie header, then there is a chance (depending on how the webpage is generated) that the server would ignore the Set-Cookie header and send only the 302 status code. Id. This potential problem is directly applicable to Reiche, where the AD 124 is supposed to use a HTTP header both to cause a 302-redirect and set a cookie. Id.
Another advantage described in Fisher for the HTML-Refresh metatag is the ability to use relative URLs instead of absolute URLs. EX1006, 319-320; EX1002,
¶¶96, 98, 196, 204. Relative URLs may be useful in situations where a Web browser is being redirected among various locations based on various different conditions— such as the architecture described in Reiche. Id., ¶203. If any of these locations in
Reiche were moved as the system is maintained or upgraded, then the absolute URLs would need to be edited to match the new locations. Id., ¶195. However, relative
URLs can be written to maintain a link between pages even as two pages are moved in absolute location. See EX1006, 185-187; EX1002, ¶196.
Accordingly, a POSITA would be motivated to modify Reiche to use the
HTML metatag redirect disclosed in Fisher, because both are directed to the same field of endeavor—configuring websites for interaction with Web browser users— and this combination would grant the Web developer control over the redirect, regardless of access to or control over server configurations. EX1002, ¶¶194-199; see, e.g., EX1006, 1, vii (Preface). Additionally, Reiche and Fisher in combination
36 Petition for IPR of U.S. Patent 6,374,359 would have been an obvious use of a known technique (the HTML metatag) to improve similar methods (the 302 status code redirect) with simple substitution of a feature of one system into another system (substitution of the HTML metatag redirect of Fisher for the 302 redirect in Reiche) to achieve the desired advantages.
KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417-18 (2007).
Design incentives and market forces would also have prompted a POSITA to modify Reiche in this manner. KSR, 550 U.S. at 401 (“When a work is available in one field, design incentives and other market forces can prompt variations of it, either in the same field or in another. If a POSITA can implement a predictable variation, and would see the benefit of doing so, § 103 likely bars its patentability.”).
The header-redirect described in Reiche has drawbacks listed above (no relative
URLs, potential errors with multiple headers); therefore, a POSITA would be motivated to use the predictable solution of replacing these header-redirects with the
HTML metatag from Fisher. EX1002, ¶198; EX1006, 319.
Additionally, the combination of Reiche and Fisher would have been obvious to try because the POSITA would have had “good reason” to pursue “a finite number of identified, predictable solutions.” See KSR, 550 U.S. at 421. The system described in Reiche requires a webpage redirect to itself (e.g., the originally requested URL).
EX1005, 10:39-42. At the time of Reiche and the ’359 Patent, Fisher indicates there were few well-known ways for a webpage to dynamically redirect to itself using
37 Petition for IPR of U.S. Patent 6,374,359 standard HTTP and HTML techniques. EX1002, ¶198; see EX1006, 319-20.
Therefore, it would have been obvious to a POSITA to try the HTML metatag described in Fisher to perform the redirect described in Reiche. Id.
In summary, a POSITA would be motivated to combine Reiche and Fisher to use an HTML metatag that redirects the webpage to itself. EX1002, ¶194-99.
2. Claim 1
Claim element 1[pre]. A method of enabling a Web browser user to interact with a given application running on a Web server, comprising the steps of:
To the extent the preamble of Claim 1 is limiting, Reiche discloses a method of enabling a Web browser user to interact with a given application running on a
Web server. The “given application” in Reiche includes customer server 126 and
AD 124 on customer server 120 at the URL originally requested by customer. See, e.g., EX1005, 8:47-52. After a Web browser user initially requests access to the secure customer HTTP server 126 in Reiche (see id.), the user is permitted to interact with AD 124 after authentication (see EX1005, 11:7-10). See also EX1005, 8:41-42
(“AD 124 is a program that is executed by the CPU of the customer server 120”).
Claim element 1[a]. upon a given occurrence at the Web server, constructing and returning a cookie to the Web browser;
Reiche discloses constructing and returning a cookie to a Web browser after the Web browser user (client 100) is redirected to AD 124 on customer server 120
38 Petition for IPR of U.S. Patent 6,374,359 from the authentication server. EX1005, 10:1-24. After a triggering event (or “given occurrence”), AD 124 “constructs a cookie out of memory table 122 row ID, client
ID and the new transaction ID.” EX1005, 10:17-21. The trigger for this action in
Reiche is AD 124 receiving confirmation of a valid login by the user. Id., 10:15-17.
Further, AD 124 returns the cookie to the Web browser in the header of a header- redirect. EX1005, 10:24-27.
Claim element 1[b]. without user input, redirecting the Web browser to a refresh object to allow the given application to determine if the cookie was set on the Web browser;
Without user input, AD 124 in Reiche redirects a Web browser to reconnect with AD 124, which confirms the Web browser has a cookie set. “At step 260,
AD 124 on the customer server 120 issues, to the client browser 100, a 302-redirect to the original URL requested in step 200 and, this time, includes the cookie in the
HTTP response header.” EX1005, 10:24-27, see also 10:39-42, 1:51-53 (describing
HTTP-standard header-redirect procedure). Following this redirect, “AD 124 detects the presence of the AD cookie embedded earlier[.]” Id., 10:42-43.
The Examiner of the ’359 Patent held, and Applicant did not contest, Reiche
“includes a redirect procedure [using a standard header-redirect] where the client browser is reconnected to the customer server 120 detecting the AD 124 cookie embedded earlier on the client browser (refer to col. 10, lines 40-48) to ensure the
39 Petition for IPR of U.S. Patent 6,374,359 cookie is valid for that particular customer server (see col. 10, lines 32-35).”
EX1004, 78. So, the only difference between Reiche and the claimed element is whether Reiche uses a “refresh object.”
As explained in VI.A.1, a POSITA would be motivated to substitute Fisher’s
Refresh metatag for the header-redirect mechanism in Reiche. As modified, this system would practice element 1[b].
When the HTML-Refresh metatag from Fisher is substituted for the header- redirect described in Reiche, the resulting architecture would necessarily practice element 1[b]. In this combination, instead of just issuing a server command, AD 124 sends the Web browser a new webpage that sets the newly constructed cookie and includes the HTML-Refresh metatag. EX1002, ¶205. Because the Refresh metatag is HTML code for causing a Web browser to refresh a page, AD 124 sends the browser to this webpage, satisfying the “redirecting the Web browser to a refresh object” element recited in element 1[b]. Id. Notably, the proposed obvious modification of Reiche in light of Fisher—where AD 124 redirects the browser using an HTTP-Equiv=“Refresh” metatag instead of a header-redirect—results in exactly the approach described in the ’359 Patent specification and depicted in Figure 7.
Claim element 1[c]. at the Web server, determining if the cookie is valid; and
Reiche discloses validating the cookie set on a browser. After the redirection and reconnection to AD 124 in Reiche, AD 124 extracts and verifies information
40 Petition for IPR of U.S. Patent 6,374,359 from the cookie against stored values in memory table 122. EX1005, 10:44-49,
Figure 2d (step 262 “Compare cookie to memory table” and step 264 “Is cookie information correct”).
EX1005, Figure 2d
Claim element 1[d]. enabling the user to interact with the given application if the cookie is valid.5
Reiche discloses enabling user interaction with the customer server application after cookie validation. The “given application” that a user seeks to access in Reiche is the resource located at the original URL. Reiche teaches that this
5 The USPTO issued a Certificate of Correction on November 5, 2002 to correct
the original language of Claim 1 from “if the cookie is invalid” to “if the
cookie is valid.”
41 Petition for IPR of U.S. Patent 6,374,359 original URL includes both the customer HTTP server 126 and AD 124, both of which are on customer server 120. EX1005, 8:47-51, 10:39-42, 10:50-52. Notably, the AD 124 is part of the same application—as indicated in Reiche by the fact the originally requested URL “contains address of Authentication Daemon 124 located on the customer server 120[.]” Id., 8:49-51; see also 10:39-42. And, when AD 124 completes the authentication process described in Reiche, which includes validating the cookie, the user is permitted access to the requested information (step 286). See id., 10:50-52, 11:9-10, Figures 2d, 2e (excerpted below). Accordingly, Reiche enables a user to interact with a given application after verifying the cookie and its contents.
EX1005, Figure 2d EX1005, Figure 2e
42 Petition for IPR of U.S. Patent 6,374,359
EX1005, Figure 2e
3. Claim 5
The method as described in claim 1 wherein the redirecting step includes the step of sending the cookie from the Web client back to the Web server to enable the given application to determine if the cookie is valid.
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 1. Supra, VI.A.2.
Reiche discloses AD 124 redirects the Web browser to the original URL
(which refers to the location of AD 124 on customer server 120) after the cookie is set and “includes the cookie in the HTTP response header.” EX1005, 10:24-27; see also 8:49-51. This redirect includes the cookie, allowing AD 124 to detect the cookie and determine if it is valid. See EX1005, 10:42-44. As noted above, AD 124 is part of the given application in Reiche that a user seeks to access. Id., 49-51.
Applicable industry standards confirm the Web browser sends the cookie back to the Web server. RFC 2109 states: “When it sends a request to an origin server, the user agent [i.e. Web browser] sends a Cookie request header to the origin server if it has cookies that are applicable to the request[.]” EX1008, § 4.3.4. Thus, a Web
43 Petition for IPR of U.S. Patent 6,374,359 browser using cookies—in accordance with industry standards disclosed in
Reiche—will send a cookie back to the Web server in subsequent requests. EX1002,
¶211. Reiche’s system conforms to these industry standards, as Reiche describes the impact and role of the cookie “in accordance with well-known HTTP communication protocols[.]” EX1005, 10:27-29. Thus, a POSITA would understand
Reiche to disclose this element. EX1002, ¶211.
4. Claim 6
The method as described in claim 1 wherein the given occurrence is a valid login to the given application.
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 1. Supra, VI.A.2.
As described for element 1[a], Reiche discloses a cookie is constructed and returned to a Web browser in response to a triggering event, or “given occurrence.”
Supra VI.A.2, citing EX1005, 10:1-24. In Reiche, this occurrence is a valid login.
Id. AD 124 at customer server 120 in Reiche only constructs a cookie after AD 124
“verif[ies] that the client 100 did in fact logon to the authentication server 110[.]”
See EX1005, 10:1-3, 10:15-24. AD 124 receives this valid login by sending information about the Web browser user directly to authentication server 110 via a separate TCP/IP connection. EX1005, 10:3-8. AD verification daemon 112 then authenticates the information provided by AD 124 and provides a status code to
44 Petition for IPR of U.S. Patent 6,374,359
AD 124 indicating whether the Web browser user has been successfully authenticated. Id., 10:8-17. Receipt of this status code is a valid login delivered to
AD 124, which causes AD 124 to proceed with constructing and setting a cookie for the Web browser. Id., 10:15-21. Further, this is a login “to the given application” because AD 124 is part of the application requested by the user through the original
URL. Id., 49-51. Thus, a POSITA would understand Reiche to disclose this element.
EX1002, ¶213.
Ground 2
The combination of Reiche, Fisher, and Stubbs, when considered with the knowledge of a POSITA, renders Claims 2, 3 and 4 obvious under 35 U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche, Fisher, and Stubbs
As explained above, a POSITA would be motivated to combine Reiche, which describes the general use of a header-redirect to redirect a page and check a cookie was set, with Fisher, which describes the alternative use of an HTML metatag to redirect a page to itself. See VI.A, supra. A POSITA would also be motivated to include additional information and security measures taught by Stubbs, a Usenet post describing additional techniques for using cookies to authenticate users, to bolster the security of the cookie-based authentication technique described in Reiche, as modified in view of Fisher.
45 Petition for IPR of U.S. Patent 6,374,359
Both Reiche and Stubbs address the use of cookies to authenticate a user across multiple servers by storing a combination of information about the user in the cookie. Compare EX1007 with EX1005, Abstract, 6:37-44. As noted in Reiche and
Stubbs, cookie transmission on a network was a known security problem. EX1005,
2:65-66, 3:35-36; EX1007 (quoting prior post: “I am basically opposed to using cookies for anything, they are not secure”). This would motivate a POSITA to look for ways to improve security of the cookie in Reiche. EX1002, ¶215. Stubbs teaches including the IP address—along with the username, password, and other information—as a way to prevent forgery of the cookie and improve security.
EX1007, 1. For example, the POSITA in Stubbs saw the benefit of a predictable variation from Reiche, including encrypting the cookie comprising user authentication information including an IP address. KSR, 550 U.S. at 401. Therefore, it would have been obvious for a POSITA to take advantage of this teaching from
Stubbs and include a Web browser destination address, such as an IP address, in the cookie. EX1002, ¶215.
2. Claim 2
Claim element 2[pre]. The method as described in claim 1 wherein the cookie is a string generated by the following steps:
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 1. Supra, VI.A.2.
46 Petition for IPR of U.S. Patent 6,374,359
To the extent the preamble of Claim 2 is limiting, Reiche discloses a method for generating a cookie as a string. For example, Reiche states AD 124 “constructs a cookie out of memory table 122 row ID, client ID and the new transaction ID.”
EX1005, 10:17-19. Reiche further states “[a] cookie can take the form of an HTTP header that consists of a string of information.” EX1005, 2:18-22.
Claim element 2[a]. concatenating into a derived value a userid, a password and other information;
It would be obvious to a POSITA to modify the cookie used by AD 124 in
Reiche in the authentication process to include a userid, password, and other information in a value, as disclosed in Stubbs. EX1002, ¶215. It would also have been obvious to a POSITA that one way to combine these values is by concatenation.
EX1002, ¶215. Specifically, Stubbs recommended the cookie be “a combination of
IP address, username, password, date, and other info[.]” EX1007. Additionally, the specific example data structure disclosed in Reiche for the cookie includes a “signed client ID stored as a string” (EX1005, 12:22) and “other information” (id., 12:18-
24). Because other portions of Reiche suggest the cookie does in fact include a password, and because cookies with the username and password were suggested in
Stubbs, a POSITA would find it obvious to modify the cookie disclosed in Reiche to include a userid, password, and other information concatenated into a value.
EX1002, ¶215.
47 Petition for IPR of U.S. Patent 6,374,359
Reiche also suggests a password may in fact be included in the cookie. For example, Reiche describes one advantage as follows:
EX1005, 6:37-46 (emphasis added). Reiche explains what “authentication server user information” is in the context of describing the user logging into the authentication server: “namely the user ID, password or any other authentication information.” EX1005, 5:25-28. Read together, these two passages suggest the cookie holds the “authentication server user information,” which includes a password, along with the user ID. This would be in addition to “other information” such as a transaction ID, which are identified as being part of the cookie. See id.,
12:20-24. This disclosure is sufficient to show a POSITA would find it obvious to include the password in the Reiche cookie.
Another reason a POSITA would find it obvious to include the password in the cookie is Reiche describes a second validation using an industry standard
48 Petition for IPR of U.S. Patent 6,374,359 authentication technique known as “Basic Authentication.” EX1005, 11:1-10.
RFC2068 explains Basic Authentication includes a “basic-cookie”:
EX1009, § 11.1. As seen above, the basic-cookie includes a concatenation of the userid and password (“user-pass”). EX1002, ¶221. While it is not certain whether this occurrence of Basic Authentication in Reiche would necessarily utilize the same cookie as checked elsewhere in Reiche, the use of Basic Authentication in Reiche confirms that it would be obvious to check a userid and password in a cookie—as disclosed in Basic Authentication above. Id. Thus, at a minimum a POSITA would understand that it would be obvious to modify Reiche to include a userid and password along with the other information expressly identified in the cookie so the
49 Petition for IPR of U.S. Patent 6,374,359 userid and password could be used in Basic Authentication. Id.; see EX1005, 5:19-
25, 12:20-24.
Claim element 2[b]. encrypting the derived value to generate a binary string; and
Reiche discloses encrypting the derived value for the cookie to generate a binary string. Reiche discloses the cookie constructed by AD 124 is encrypted
“using a simple private key encryption algorithm[.]” EX1005, 10:21-23. This is consistent with Stubbs, which also teaches encrypting the information in a cookie.
EX1007 (“[cookies] are subject to tampering unless encrypted”). The disclosure in
Reiche includes encryption that produces a binary string because the encrypted cookie is subsequently Uuencoded; Uuencoding is a “program for encoding binary data in the American Standard Code for information Interchange (ASCII) format.”
EX1005, 10:21-24, 2:23-26, Figure 2d. Because Uuencoding requires binary data for encoding, the encryption step must produce a binary string for Uuencoding. Id.;
EX1002, ¶222.
EX1005, Figure 2d
50 Petition for IPR of U.S. Patent 6,374,359
Claim element 2[c]. encoding the binary string.
As discussed above in VI.B.2 for claim element 2[b], Reiche discloses the cookie constructed by AD 124 is Uuencoded and URL encoded after encryption, and
Uuencoding is a technique for encoding a binary string. EX1005, 10:21-24, 2:23-26.
Consistent with this teaching from Reiche, Stubbs also suggests encoding the cookie contents. EX1007 (“[cookies] can be exchanged between machines unless encoded with ip (sic) address – host name -username, etc.”). EX1002, ¶223.
3. Claim 3
The method as described in claim 2 wherein the other information is a client destination address.
The combination of Reiche, Fisher, and Stubbs disclose or render obvious all elements of Claim 2. Supra, VI.B.2.
The ’359 Patent indicates the IP address of the client is a “client destination address.” EX1001, 2:45-48, 7:1-5. As explained in VI.B.1 above, the inclusion of the client’s IP address in the cookie, as taught in Stubbs, would have been obvious to Reiche, as modified by Fisher. See EX1005, 2:10-14 (describing IP Protocol).
First, Stubbs confirms a POSITA would be motivated to make exactly this modification. To address security challenges with cookies, Stubbs recommended the cookie be “a combination of IP address, username, password, date, and other info[.]”
EX1007. Second, the inclusion of the IP address in the cookie would be a
51 Petition for IPR of U.S. Patent 6,374,359 straightforward modification to Reiche. Reiche already discloses AD 124 on customer server 120 stores the Web browser user’s IP address in a row of the memory table 122. EX1005, 8:65-9:6. Because this information is already collected and stored by AD 124, it would have been trivial for AD 124 to include the IP address in the cookie. EX1002, ¶225. Indeed, the Examiner concluded such a modification was obvious based on Reiche alone. EX1004, 79.
4. Claim 4
Claim element 4[pre]. The method as described in claim 3 wherein the step of determining whether the cookie is valid comprises:
The combination of Reiche, Fisher, and Stubbs disclose or render obvious all elements of Claim 3. Supra, VI.B.3.
To the extent the preamble of Claim 4 is limiting, Reiche discloses a step of checking information to validate a cookie. See EX1005, 10:44-47 (“The row ID, client ID and transaction ID are determined from the cookie and, at step 262 and
264, are verified against the memory table 122.”), Figure 2d:
52 Petition for IPR of U.S. Patent 6,374,359
EX1005, Figure 2d
Claim element 4[a]. decoding the string to generate a resulting binary value;
Reiche discloses or renders obvious decoding the string from a cookie to generate a binary value. As explained for element 2[b], Reiche states the cookie is
Uuencoded, which requires “encoding binary data in the American Standard Code for information Interchange (ASCII) format.” EX1005, 10:21-24, 2:24-26. Reiche also states information is “extracted” from the cookie and verified against a memory table. EX1005, 10:44-47. A POSITA would have understood that for encoded information to be extracted and verified against values in a table, that information must first be decoded. EX1002, ¶228. When the Uuencoding process is reversed— e.g., the string is decoded—the output would be the same as what was originally input for Uuencoding: a binary value. Id. Thus, a POSITA would understand Reiche teaches decoding the string to generate a resulting binary value.
53 Petition for IPR of U.S. Patent 6,374,359
Claim element 4[b]. decrypting the resulting binary value to generate a resulting derived value;
Reiche discloses decrypting the information from a cookie to generate a value.
Reiche states information is “determined” from an encrypted and Uuencoded cookie.
EX1005, 10:44-47, 10:21-24. A POSITA would understand that in order for information to be determined from such a cookie, the cookie must be both decoded and decrypted. EX1002, ¶229. A POSITA would further understand decrypting the cookie in Reiche would involve decrypting a binary value: Reiche states the cookie is Uuencoded, which requires a binary value. Id.; see also EX1005, 10:21-24, 2:24-
26.
Claim element 4[c]. determining whether the destination address in the resulting derived value matches a destination address of a client machine on which the Web browser is running;
As explained above, it would have been obvious, in view of Reiche and
Stubbs, to include a destination address, such as an IP address, in the cookie along with other information about the transaction. Supra, VI.B.2.
Reiche already discloses in steps 262 and 264 checking information in the cookie against memory table 122. EX1005, 10:44-47. In the obvious combination where the IP address is included in the cookie (supra VI.B.3, citing EX1007), it would have been obvious to check the IP address. EX1002, ¶231. Notably, Reiche
54 Petition for IPR of U.S. Patent 6,374,359 discloses the Web browser user IP address was previously stored by AD 124 in memory table 122—the same table being checked in steps 262 and 264. EX1005,
8:64-9:1, 10:44-47. Thus, it would have been obvious and efficient to verify the IP address against memory table 122 when verifying the information in the cookie.
EX1002, ¶231.
Claim element 4[d]. if the destination addresses match, determining whether the user name and password in the resulting derived value match the user's user name and password; and
It would have been obvious to a POSITA, in view of the combined teachings of Reiche and Stubbs, to verify the user name and password from the cookie after verifying the IP address.
Reiche discloses the “last verification” performed after checking the values from memory table 122 ensures “the user has access to the URL requested[.]”
EX1005, 10:50-52; see also Figure 2e (Step 282 “Basic authentication”). Reiche confirms this verification includes Basic Authentication, which verifies a userid and password contained in a “basic-cookie.” EX1005, 11:1-9; EX1009, § 11.1. Thus,
Reiche discloses “determining whether the user name and password in the resulting derived value match the user's user name and password” after verifying information in the cookie. See EX1005, Figures 2d and 2e (showing steps 262 and 264 related to checking cookie information before step 282 “Basic authentication”).
55 Petition for IPR of U.S. Patent 6,374,359
EX1005, Figure 2d (annotated) EX1005, Figure 2e (annotated)
Because Reiche already discloses first checking the cookie information available in memory table 122 before the Basic Authentication step, it would be obvious to check the cookie modified in light of Stubbs in the same order. See
EX1005, 10:44-47, 11:1-9; EX1002, ¶234. This would mean checking the IP address from memory table 122 before checking the username and password. Moreover, a
POSITA would have been motivated to verify the IP address before the userid- password combination because verifying the IP address is more computationally efficient than verifying the userid and password. EX1002, ¶234. Detecting address mismatches first would avoid the additional steps of retrieving the userid and password for verification. Id. Thus, to improve efficiency, a POSITA would be
56 Petition for IPR of U.S. Patent 6,374,359 motivated to perform the userid-password verification after verifying the IP addresses. Id.
Furthermore, it also would have been obvious to a POSITA to verify the user name and password after verifying the IP address, because there are a limited number of orders in which these operations can be performed—either the userid and password are checked before the IP addresses or after. EX1002, ¶235; see also KSR,
550 U.S. at 421 (“When there is a design need or market pressure to solve a problem and there are a finite number of identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.”); see also Bayer Pharma AG v. Watson Labs., Inc., 874 F.3d 1316, 1329
(Fed. Cir. 2017) (affirming finding of obviousness where claimed element was one of two approaches, quoting KSR).
Claim element 4[e]. if the user name and password match, enabling the user to interact with the application.
Reiche discloses allowing the user to interact with the requested content following all of the verification steps, including Basic Authentication. EX1005,
11:1-11, Figure 2e (step 282 “Basic authentication” precedes step 285 “Establish connection and user views requested information”). It would be obvious to a
POSITA that allowing the user to view the requested page from the customer server
57 Petition for IPR of U.S. Patent 6,374,359 when the user name and password in the cookie matches is “enabling the user to interact with the application.” EX1002, ¶236.
Ground 3
The combination of Reiche, Fisher, and the LDAP Draft, when considered with the knowledge of a POSITA, renders Claims 7, 8, and 9 obvious under 35
U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche, Fisher, and the LDAP Draft
A POSITA would have been motivated to apply the authentication technique taught by Reiche as modified by Fisher, to LDAP directory services described in the
LDAP Draft. Reiche, as modified by Fisher, presents a secure authentication method to authenticate to an LDAP directory. See, e.g., EX1005, Abstract; EX1006, vii
(Preface).
The LDAP Draft describes standardized techniques for interacting with an
LDAP directory. LDAP directories—which are just directories with information configured according to the LDAP specification—were widely used at the time of the ’359 Patent to host a variety of information. EX1002, ¶238, see also EX1001,
4:23-26; EX1011. For example, LDAP directories were commonly used to maintain user records and required authenticated access controls to protect the directory information. EX1002, ¶238; EX1011, § 3 (describing example directory entries for
58 Petition for IPR of U.S. Patent 6,374,359 a person and her employer). Reiche, as modified by Fisher, presents a secure authentication method to authenticate to an LDAP directory like those disclosed in the LDAP Draft. EX1002, ¶238-39.
In view of the widespread use of LDAP directories, it would have been obvious to use the authentication scheme in Reiche to control access to an interface for an LDAP directory (e.g., an LDAP interface). Reiche specifically describes the need to protect access to user records, which—as exemplified in the LDAP Draft— would commonly be stored in an LDAP directory on a server. See EX1005, 3:60-64
(“For example, it may be permissible for anyone in administration to obtain a list of company personnel, but only selected individuals may have access to salary information.”), 3:8-21. Accordingly, design incentives and market forces would also have prompted a POSITA to use Reiche in combination with the LDAP Draft to authenticate users seeking access to information stored in an LDAP directory . KSR,
550 U.S. at 401.
Similarly, it would have been obvious that the LDAP interface used with
Reiche should be a graphical user interface, or GUI. Reiche discloses generally using a GUI for receiving user authentication information. EX1005, 5:19-22 (“invok[ing] on the display screen a dialog box with user ID and password fields that must be completed by the user”), 2:45-48; EX1002, ¶241. Thus, it would have been obvious to a POSITA to provide an LDAP GUI to interact with a system combining the
59 Petition for IPR of U.S. Patent 6,374,359 authentication and GUI described in Reiche with the well-known and standard
LDAP directory and interface. EX1002, ¶241.
2. Claim 7
The method as described in claim 6 wherein the given application is an (sic)
Lightweight Directory Access Protocol (LDAP) GUI interface.
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 6. Supra, VI.A.4.
Claim 7 merely limits the obvious method of Claim 6 to the well-known context of an “LDAP GUI interface.” It would be obvious to a POSITA to use the secure authentication method disclosed in Reiche, as modified by Fisher, to authenticate a user attempting to interact with an LDAP directory like those disclosed in the LDAP Draft. See VI.A.4. In such a configuration, the given application would be a Lightweight Directory Access Protocol (LDAP) GUI interface. In this combination, to gain the benefit of Reiche’s authentication control, the interface for the LDAP directory would be part of customer server 126 in Reiche and available at the originally requested URL. See, e.g., EX1005, 10:39-11:10;
EX1002, ¶242. Accordingly, it would be obvious to a POSITA to modify Reiche such that the “given application”—the resource in Reiche that the user seeks to access—is an LDAP GUI.
60 Petition for IPR of U.S. Patent 6,374,359
LDAP directories and interfaces to such directories were well-known before the ’359 Patent.6 EX1011, §§ 2-3; see also EX1001, 1:35-39, 4:21-26.
The ’359 Patent does not does not describe the LDAP GUI itself and merely claims an LDAP GUI with reference to the prior art LDAP Draft. EX1001, 4:18-26. Patent
Owner did not invent the LDAP GUI described in the LDAP Draft, and limiting
Claim 6 to such a well-known application is not a patentable distinction. See Brown v. Piper, 91 U.S. 37, 41, 23 L. Ed. 200 (1875) (“The answer is, that this was simply the application by the patentee of an old process to a new subject, without any exercise of the inventive faculty, and without the development of any idea which can be deemed new or original in the sense of the patent law.”).
3. Claim 8
The method as described in claim 7 wherein the user interacts with the LDAP
GUI interface to take a given action.
The combination of Reiche, Fisher, and the LDAP Draft disclose or render obvious all elements of Claim 7. Supra, VI.C.2.
6 During prosecution the Examiner concluded that claims adding reference to LDAP (original Claims 8, 9) were obvious in view of Reiche because of the known uses of LDAP. EX1004, 80, 83-85.
61 Petition for IPR of U.S. Patent 6,374,359
Claim 8 merely includes a user action using the “LDAP GUI interface.” It is obvious a user interacting with the LDAP interface for authentication would then use the LDAP interface to take an action, such as connecting to the LDAP directory and other “LDAP operations”:
See, e.g., EX1011, § 4. Accordingly, taking an action with the LDAP interface is a routine and expected use of the LDAP interface, and is, in fact, the entire purpose of providing such an interface. EX1002, ¶245.
4. Claim 9
The method as described in claim 7 wherein the user interacts with the LDAP
GUI interface to log off from the LDAP GUI without having to exit the Web browser.
62 Petition for IPR of U.S. Patent 6,374,359
The combination of Reiche, Fisher, and the LDAP Draft disclose or render obvious all elements of Claim 7. Supra, VI.C.2.
Claim 9 adds a user logging off from the LDAP GUI without having to exit the Web browser. During prosecution of the ’359 Patent, the Examiner concluded that this claim was obvious in light of Reiche. EX1004, 121; see also EX1002, ¶247.
The Examiner specifically cited the disclosure in Reiche at column 11, line 11-14, which confirms that after the user finishes viewing the requested information in
Reiche, the user can exit the browser or exit the site to perform other actions. Id.;
EX1005, 11:11-15; see also, Figure 2e.
Figure 2e
63 Petition for IPR of U.S. Patent 6,374,359
Reiche further teaches that if the user has navigated away for long enough, any prior authentication will time out. Id., 9:45-51, 10:11-15; EX1002, ¶247. Thus, all a user has to do to log off from the Reiche system without exiting the browser is leave the requested content and wait for the time to expire. Claim 9 is thus obvious for the same reasons as stated for Claim 7. EX1002, ¶¶247-49.
Ground 4
The combination of Reiche, Fisher, and Goodman when considered with the knowledge of a POSITA, renders Claim 10 obvious under 35 U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche, Fisher, and Goodman
A POSITA would also be motivated to replace the Set-Cookie header in
Reiche with the JavaScript-based SetCookie function disclosed in Goodman because that would provide the developer with more control of the cookies, particularly in the likely case where JavaScript was already being used in the website. EX1002,
¶250. In addition, Goodman, like Reiche and Fisher, is directed to configuring websites for interaction with Web browser users.; see, e.g., EX1005, Abstract;
EX1006, vii (Preface); EX1010, 13-14, 159, 413.
JavaScript is a programming language that enables dynamic webpage functionality embedded within HTML code. EX1002, ¶251. For example, Fisher discusses JavaScript as enabling a web page to “read form information, react to
64 Petition for IPR of U.S. Patent 6,374,359 mouse clicks, modify input fields, and so on.” EX1006, 414. Goodman discloses setting a cookie using JavaScript, instead of the Set-Cookie HTTP header. EX1010,
160-62. Such a use of JavaScript would provide more flexibility for a Web developer and would depend less on configuration of Web servers (which could be outside of the developer’s control). EX1002, ¶251. Thus, substitution of JavaScript from
Goodman for the Set-Cookie HTTP headers in Reiche would have been a predictable variation with predictable benefits. KSR, 550 U.S. at 401. Further, it would have been obvious to a POSITA implementing dynamic HTML webpages to include
JavaScript and use JavaScript to set a cookie. EX1002, ¶251; see also, e.g., EX1006,
414.
2. Claim 10
Claim element 10. A method of enabling a Web browser user to interact with a given application running on a Web server, comprising the steps of:
The preamble of Claim 10 is identical to the preamble of Claim 1.
Accordingly, the preamble of Claim 10 is obvious for the same reasons as the preamble of Claim 1.
Claim element 10[a]. upon a valid user login at the Web server, constructing a cookie;
Reiche discloses constructing a cookie upon a valid login by the user. AD 124 at customer server 120 constructs a cookie after AD 124 “verif[ies] that the client
65 Petition for IPR of U.S. Patent 6,374,359
100 did in fact logon to the authentication server 110[.]” EX1005, 10:1-3, 15-24. AD verification daemon 112 authenticates user login information provided by AD 124 and provides to AD 124 a status code indicating whether the Web browser user has been successfully authenticated. EX1005, 10:3-17. Receipt of this status code indicates a valid login has occurred, and AD 124 then “constructs a cookie out of memory table 122 row ID, client ID and the new transaction ID.” EX1005, 10:15-
21.
Claim element 10[b]. returning the cookie to the Web browser in a refresh page the redirects HTTP flow back to itself with a given parameter;
Reiche discloses or renders obvious returning the cookie to the Web browser and redirecting HTTP flow back to itself with a given parameter. Specifically,
Reiche teaches “AD 124 on the customer server 120 issues, to the client browser 100, a 302-redirect to the original URL requested in step 200 and, this time, includes the cookie in the HTTP response header.” EX1005, 10:24-27. As described in Section V, a “refresh page” is a page containing HTML code for causing a Web browser to refresh the page. An example of such a refresh page would be a page having the Refresh metatag described in Fischer, which is what the ’359 Patent includes in Figure 7:
66 Petition for IPR of U.S. Patent 6,374,359
EX1001, Figure 7 (emphasis added)
While the use of a header-redirect in Reiche does not alone constitute a
“refresh page,” this element is still obvious in view of Reiche in combination with the teachings of Fisher. As explained in VI.A.1, a POSITA would be motivated to substitute the use of Fisher’s Refresh metatag for the header-redirect mechanism in
Reiche. When the HTML-Refresh metatag from Fisher is substituted for the 302- redirect described in Reiche, instead of issuing the header-redirect, AD 124 would provide the Web browser with a webpage having the Refresh metatag from Fisher.
This modification of Reiche is obvious for the same reasons as described with respect to a “refresh object” in element 1[b], supra VI.A.2.
67 Petition for IPR of U.S. Patent 6,374,359
Modified to use Refresh metatag
EX1005, Figure 2d (annotated)
As explained by Fisher, this metatag is HTML code for causing a Web browser to refresh a page, making this page from AD 124 a “refresh page.” EX1002,
¶257; EX1006, 207-208. Accordingly, the modified system would include “a refresh page the redirects HTTP flow back to itself.”
It would also have been obvious to a POSITA to use HTML code in the page to set the cookie, instead of relying on HTTP headers. For example, instead of using the traditional HTTP header to set a cookie, Goodman teaches a webpage comprising
HTML and JavaScript can set a cookie—that is, the cookie is returned to the browser using the webpage and its contents. EX1010, 160-62. Such a use of JavaScript would
68 Petition for IPR of U.S. Patent 6,374,359 provide more flexibility for a Web developer and would depend less on the Web server (which could be outside of the developer’s control). EX1002, ¶258. A developer might also prefer to use JavaScript to set a cookie if the website used
JavaScript for other purposes, such as browser-side verification of cookie values and/or having the user’s browser extract values from cookies to be used by
JavaScript programs. For a website using JavaScript anyway, or needing to use cookies to store values used by the website’s JavaScript programs, using JavaScript to also set such cookies could result in a more reliable, faster, and or more maintainable implementation. Thus, a POSITA would have found it obvious to return the cookie to the Web browser using something in the HTML code for the page itself, i.e., embedded JavaScript as from Goodman. Id.
As for inclusion of “a given parameter,” Reiche discloses or renders obvious inclusion of such a parameter. Reiche discloses the general use of such parameters, including a userid, password, transaction ID, client IP address, expiry time, and checksum. See, e.g., EX1005, 4:65-67, 5:6-11, 6:37-44. Specifically, Reiche discloses the cookie contains “the user ID and the authentication server user information” such as a password, for storage “in the user’s browser” to enable the browser to “automatically release the authentication information (user ID, password, and any other authentication information)” to the authentication server. See, e.g.,
EX1005, 6:37-56.
69 Petition for IPR of U.S. Patent 6,374,359
As another example, Reiche discloses a parameter specifying “the cookie expiry time limit” passed to AD 124 at step 252—before AD 124 sets the cookie and redirects the Web browser. RFC 2109 specifies a similar parameter, Max-Age, which can be used to indicate the cookie is no longer valid:
EX1008, § 4.2.2. RFC 2109 also indicates Netscape’s original proposal included an
“Expires” value to perform a similar function. Id., § 10.1.2. Accordingly, even while
Reiche is silent on whether the “cookie expiry time limit” is included with the cookie, it would have been obvious to a POSITA to provide to the Web browser with this parameter. EX1002, ¶260.
Claim element 10[c]. returning the cookie back to the Web server;
As described above for Claim 5, a method for returning the cookie to the Web server is disclosed in Reiche. Accordingly, this clause of Claim 10 is obvious for the same reasons as Claim 5.
Claim element 10[d]. at the Web server, using the returned cookie and the given parameter to determine if the cookie is valid; and
Reiche discloses determining if the cookie set on a browser is valid. After the redirection and reconnection to AD 124 in Reiche, AD 124 proceeds to extract
70 Petition for IPR of U.S. Patent 6,374,359 information from the cookie for verification against stored values in memory table 122. EX1005, 10:44-49, Figure 2d (step 264 “Is cookie information correct”):
EX1005, Figure 2d
Further, Reiche discloses or renders obvious using the “given parameter” in the determination of whether the cookie is valid. For example, the information extracted from the cookie in Reiche for verification includes parameters such as the
“row ID, client ID and transaction ID.” EX1005, 10:44-47. As another example, it would have been obvious that the “cookie expiry time limit” parameter disclosed in
Reiche could also be checked to ensure the cookie has not expired. See, EX1005,
10:11-17; EX1008, §§ 4.2.2 and 4.3.3.; and EX1002, ¶260.
Claim element 10[e]. enabling the user to interact with the given application if the cookie is valid.
71 Petition for IPR of U.S. Patent 6,374,359
While the validation process in Claim 10 (element 10[d]) differs from Claim 1
(element 1[c]), once the cookie is validated as described above, the final clause of
Claim 10 is identical to the final clause of Claim 1. Accordingly, this clause of
Claim 10 is obvious for the same reasons as the corresponding clause of Claim 1.
Ground 5
The combination of Reiche, Fisher, Goodman, and Stubbs, when considered with the knowledge of a POSITA, renders Claims 11, 12, and 13 obvious under 35
U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche, Fisher, Goodman, and Stubbs
As described above, a POSITA would be motivated to combine Reiche,
Fisher, and Stubbs (supra, VI.B.1), and a POSITA would be motivated to combine
Reiche, Fisher, and Goodman (supra, VI.D.1). For the same reasons, it would have been obvious to combine Reiche, Fisher, Goodman, and Stubbs. Nothing in the teachings of Stubbs or Goodman conflicts with each other, and both references remain useful for improving the authentication method taught by Reiche. EX1002,
¶265.
2. Claim 11
Claim element 11. The method as described in claim 10 wherein the cookie is an ASCII string constructed by the following steps comprising:
72 Petition for IPR of U.S. Patent 6,374,359
concatenating into a derived value a userid, a password and other information;
encrypting the derived value to generate a binary string; and
encoding the binary string.
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 10. Supra, VI.D.2.
Claim 11 only differs from Claim 2 in that Claim 11 requires an ASCII string.
Reiche states encoding the cookie produces an ASCII string—the cookie is
Uuencoded, which encodes “binary data in the American Standard Code for information Interchange (ASCII) format.” EX1005, 2:23-26, 10:21-24.
Additionally, RFC 2068 specifies the “US-ASCII coded character set” under Basic
Rules for HTTP/1.1. EX1009, § 2.2. Claim 11 is therefore obvious for the same reasons as Claims 1, 2, and 10.
3. Claim 12
The method as described in claim 11 wherein the other information is a client
IP address.
The combination of Reiche and Fisher disclose or render obvious all elements of Claim 11. Supra, VI.E.2.
Claim 12 only differs from Claim 3 in that Claim 12 requires a “client IP address” while Claim 3 requires a “client destination address.” As noted above,
Reiche discloses the Web browser’s IP address is stored; therefore, it would have
73 Petition for IPR of U.S. Patent 6,374,359 been obvious to include the IP address in the cookie. Supra section VI.B.2; EX1005,
8:65 9:6; EX1002, ¶269. Thus, Claim 12 is obvious for the same reasons as Claims 3 and 11.
4. Claim 13
Claim element 13. The method as described in claim 12 wherein the step of determining whether the cookie is valid comprises:
decoding the ASCII string to generate a resulting binary value;
decrypting the resulting binary value to generate a resulting derived value;
determining whether the IP address in the resulting derived value matches an
IP address of a client machine on which the Web browser is running;
if the IP addresses match, determining whether the user name and password in the resulting derived value match the user's user name and password; and
if the user name and password match, enabling the user to interact with the application.
The combination of Reiche, Fisher, and Stubbs disclose or render obvious all elements of Claim 12. Supra, VI.E.3.
Claim 13 only differs from Claim 4 in that Claim 13 requires the cookie is an
ASCII string, and Claim 13 discusses an “IP address” rather than the “destination address” of Claim 4. Reiche instructs a cookie is Uuencoded “in the American
Standard Code for information Interchange (ASCII) format.” EX1005, 2:23-26; see
74 Petition for IPR of U.S. Patent 6,374,359 also VI.D.3, supra. Reiche also states the IP address is a “client destination address.”
See, e.g., EX1005, 2:13-14 (“the IP number” is a “four-byte destination address”).
Accordingly, Claim 13 is obvious for the same reasons as Claims 4 and 12.
Ground 6
The combination of Reiche, Fisher, Goodman, and the LDAP Draft when considered with the knowledge of a POSITA, renders Claims 14, 15, and 16 obvious under 35 U.S.C. § 103.
1. A POSITA would have been motivated to combine Reiche, Fisher, Goodman, and the LDAP Draft
A POSITA would be motivated to apply the authentication technique taught by Reiche, as modified by Fisher and Goodman, to LDAP directory services described in the LDAP Draft (supra, VI.C.1, VI.D.1. Reiche, as modified by Fisher,
Goodman, and Stubbs, presents a secure authentication method to authenticate to an
LDAP directory. See, e.g., EX1005, Abstract; EX1006, vii (Preface). Nothing in the teachings of the LDAP Draft or Goodman conflicts with the other, and both references remain useful for improving the cookie-based authentication technique taught by Reiche. EX1002, ¶273.
2. Claim 14
The method as described in claim 10 wherein the given application is an
Lightweight Directory Access Protocol (LDAP) GUI interface.
75 Petition for IPR of U.S. Patent 6,374,359
The combination of Reiche, Fisher, and Goodman disclose or render obvious all elements of Claim 10. Supra, VI.D.2.
Claim 14 is obvious for the same reasons as Claim 7.
3. Claim 15
The method as described in claim 14 wherein the user interacts with the LDAP
GUI interface to take a given action.
The combination of Reiche, Fisher, and the LDAP Draft disclose or render obvious all elements of Claim 14. Supra, VI.F.2.
Claim 15 is obvious for the same reasons as Claim 8.
4. Claim 16
The method as described in claim 10 wherein the user interacts with the LDAP
GUI interface to log off from the LDAP GUI without having to exit the Web browser.
The combination of Reiche, Fisher, and Goodman disclose or render obvious all elements of Claim 10. Supra, VI.D.2.
Claim 16 is obvious for the same reasons as Claims 9 and 15.
76 Petition for IPR of U.S. Patent 6,374,359
VII. CONCLUSION
Petitioners respectfully request that inter partes review of the ’359 Patent be instituted and that the Challenged Claims be cancelled as unpatentable under 35
U.S.C. § 318(b).
77 Petition for IPR of U.S. Patent 6,374,359
Respectfully submitted, BAKER BOTTS L.L.P.
July 11, 2019 /Brian W. Oaks/ Date Brian W. Oaks (Reg. No. 44,981) 98 San Jacinto Blvd., Suite 1500 Austin, Texas 78701 Phone: (512) 322-5470 Facsimile: (512) 322-3621
Christopher V. Ryan (Reg. No. 54,759) 98 San Jacinto Boulevard, Suite 1500 Austin, TX 78701-4078 Phone: (512) 322-2586 Facsimile: (512) 322-3686
Mark Speegle (Reg. No. 77,512) 98 San Jacinto Boulevard, Suite 1500 Austin, TX 78701-4078 Phone: (512) 322-2536 Facsimile: (512) 322-3636
ATTORNEYS FOR PETITIONERS
78 CERTIFICATE OF COMPLIANCE
Pursuant to 37 C.F.R. § 42.24(d), the undersigned certifies that the foregoing
Petition, exclusive of the exempted portions as provided in 37 C.F.R. § 42.24(a), contains 13,682 words which is no more than 14,000 words and therefore complies with the type-volume limitations of 37 C.F.R. § 42.24(a). The word count was calculated by starting with Microsoft Word’s total document word count and subtracting the words for the Table of Contents, the Exhibit List, the Mandatory
Notices, the Certificate of Compliance, and the Certificate of Service.
Dated: July 11, 2019 /Brian W. Oaks/ Brian W. Oaks (Reg. No. 44,981) 98 San Jacinto Blvd., Suite 1500 Austin, Texas 78701 Phone: (512) 322-2500 Facsimile: (512) 322-2501
LEAD ATTORNEY FOR PETITIONERS CERTIFICATE OF SERVICE
In accordance with 37 C.F.R. §§ 42.6(e) and 42.105, the undersigned certifies that on the 11th day of July, 2019, a complete and entire copy of the PETITION
FOR INTER PARTES REVIEW OF CLAIMS 1-16 OF U.S. PATENT NO.
6,374,359 (“petition”), Power of Attorney and related Exhibits were served on Patent
Owner at the correspondence address of record for the subject patent,
IBM CORPORATION INTELLECTUAL PROPERTY LAW-ZIP 4054 11400 BURNET ROAD AUSTIN TX 78758 via Express Mail or by means at least as fast and reliable as Express Mail.
Additionally, a courtesy copy was served via FEDERAL EXPRESS on the Patent
Owner’s counsel at the following address:
Kevin K. McNish John M. Desmarais Karim Z. Oussayef Desmarais LLP 230 Park Avenue New York, NY 10169
Dated: July 11, 2019 /Brian W. Oaks/ Brian W. Oaks (Reg. No. 44,981) 98 San Jacinto Blvd., Suite 1500 Austin, Texas 78701
LEAD ATTORNEY FOR PETITIONERS
2