UNITED STATES PATENT AND TRADEMARK OFFICE ________________________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD

________________________________

NETFLIX, INC., Petitioner,

v.

COPY PROTECTION LLC, Patent Owner.

________________________________

IPR Case No. Not Yet Assigned Patent 7,079,649

________________________________

PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 7,079,649 UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 41.100 ET SEQ.

Filed on behalf of Petitioner by: Srecko Vidmar (Reg. No. 72,937) Clayton C. James (pro hac vice motion to be filed) Carey M. Rozier (Reg. No. 63,429) Aaron Oakley (Reg. No. 73,532) Hogan Lovells US LLP One Tabor Center, Suite 1500 1200 Seventeenth Street Denver, CO 80202 Telephone: 303-899-7300

i

TABLE OF CONTENTS

Page

I. Introduction .................................................................................................. 1 II. Mandatory Notices – 37 C.F.R. § 42.8(a)(1) ................................................. 6

A. Real Parties-in-Interest – 37 C.F.R. § 42.8(b)(1) ................................. 6 B. Related Matters – 37 C.F.R. § 42.8(b)(2) ............................................ 6 C. Lead and Backup Counsel and Service Information – 37 C.F.R.

§ 42.8(b)(3) & (4) ............................................................................... 6 III. Notice of Fees Paid ....................................................................................... 7 IV. Grounds for Standing (37 C.F.R. § 42.104(a)) .............................................. 7 V. Identification of Challenge (37 C.F.R. § 42.104(b)) ...................................... 7

A. Relief Requested ................................................................................. 7 B. Necessity of Multiple Grounds ........................................................... 8 C. Threshold Requirement for Inter Partes Review ............................... 10

VI. Claim Construction ..................................................................................... 11 A. “protecting means for cryptographically protecting the

requested data set” [claims 13 and 26] .............................................. 11 B. “generating means for generating a program portion for sending

to the source of the access request” [claim 13 and 26] ...................... 11 VII. Citation of Prior Art .................................................................................... 12 VIII. Claim-by-Claim Explanation of Grounds for Unpatentability ..................... 14

A. PHOSITA ......................................................................................... 14 B. Grounds ............................................................................................ 14

1. Ground 1: Claims 1-6, 9-12, 14, 17, 19-21, and 23-25 are anticipated by Erickson ..................................................... 14

2. Ground 2: Erickson in view of Kamba renders obvious claims 7, 8, 13, 22, and 26 ...................................................... 25

3. Ground 3: Erickson in view of AAPA renders obvious claim 16 .................................................................................. 32

4. Ground 4: Erickson in view of Mihm renders obvious Claim 18 ................................................................................. 34

5. Ground 5: Kamba in view of Lagoze renders obvious claims 1, 2, 5-13, and 19-26 .................................................... 36

6. Ground 6: Kamba in view of Lagoze and further in view of AAPA renders obvious claims 3 and 4 ............................... 52

7. Ground 7: Kamba in view of Lagoze and further in view of Erickson renders obvious claims 14 and 17 ........................ 53

ii

8. Ground 8: Kamba in view of Lagoze and further in view of AAPA renders obvious claim 16......................................... 55

9. Ground 9: Kamba in view of Lagoze and further in view of Mihm renders obvious claim 18 .......................................... 56

10. Ground 10: Kamba in view of Lagoze and further in view of AAPA renders obvious claims 1-13, 16, and 19-26 ............................................................................................ 58

11. Ground 11: Kamba in view of Lagoze and further in view of AAPA and Erickson renders obvious claims 14 and 17 ..................................................................................... 59

12. Ground 12: Kamba in view of Lagoze and further in view of AAPA and Mihm renders obvious claim 18 ............... 60

1

I. INTRODUCTION

Netflix, Inc. (“Netflix” or “Petitioner”) respectfully requests inter partes

review under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42.100 of claims 1-14 and 16-

26 of U.S. Patent No. 7,079,649 (“the ’649 patent”) (Ex. 1001). Copy Protection,

LLC (“Copy Protection” or “Patent Owner”), acquired the ’649 patent from

original owner British Telecommunications plc in 2014.

The ’649 patent relates to protecting data transmitted over a computer

network such as the Internet. Each independent claim recites a program or

program portion running on a client computer that: (a) receives encrypted data

from the server; (b) decrypts the data and displays it at the client computer; and (c)

after decryption, restricts access to copy or save functions on the client.1 Several

independent claims further require that the program or program portion requests

access to data on a server.

As described in its Abstract, the alleged invention of the ’649 patent

protects documents and other data sent over a computer network to a client

computer’s display application, such as a browser, by selectively disabling that

client’s ability to copy or save that content. After repeated rejections, the BPAI

and the Examiner accepted the applicants’ argument that the combination of

1 The claims use different wording for the last limitation. Some recite “restricting or preventing access,” while others recite “selectively controlling access” or “suppressing.” Applicants represented during prosecution that these limitations all recited “similar features.” (File History of ’649 Patent, Ex. 1002, at 254.)

2

features claimed, primarily suppressing copy and save functions with respect to the

decrypted data, was not present in the prior art.

However, each element and relevant combination of elements was present in

the prior art. This Petition first presents grounds based on Erickson, a patent that

expressly discloses a program that requests access to data, receives encrypted data

at a client, decrypts that data at the client, and selectively controls access to copy

and save functions in respect to the decrypted data. (See Grounds 1-4.)

Grounds 5-12 rely on references that disclose Java applets that perform

every limitation of the independent claims. The use of Java applets in these

references is notable because the only embodiment disclosed in the ’649 patent

uses Java applets to perform the claim features. In fact, the ’649 patent’s

specification admits that the purportedly-inventive program portion responsible for

selectively disabling copy and save functions was itself a Java applet, which

disabled the browser’s normal ability to display copy and save menus by right-

clicking a mouse over portions of the webpage. The specification also admits that

this was a standard feature of Java applets: “The right mouse button function is

disabled according to usual Java operation for applets….” (Ex. 1001 at 9:8-92;

see also 4:53-65.) Vasanthan Dasan, who collaborated with colleagues at Sun

Microsystems during the development of the Java programming language and who

2 Except where noted, all bolding, quotation, or other emphases in quotations was added, and is not present in the source of the quotation.

3

worked extensively with Java applets in the 1993-1996 timeframe in his role as a

Sun engineer, confirms this feature was a default function of prior art Java applets.

(Dasan Decl., Ex. 1007, at ¶¶ 10-12.)

Java applets disabled right mouse button functionality in a manner that fully

discloses the “selective” disablement of copy and save functionality claimed in the

’649 patent. Upon clicking the right mouse button when the mouse pointer was

positioned over a Java applet in a browser, no drop-down menu would appear and

therefore no option to save or copy the data.. (Ex. 1007 at ¶¶ 31, 37.) When the

mouse pointer was positioned over non-applet regions of the same browser page,

the right mouse button functionality would, in its usual manner, trigger a drop

down menu offering copy and save functions as shown in FIG. 2 of the ’649

patent. (Ex. 1007 at ¶ 38; see also Ex. 1001 at 6:13-26, FIG. 4.) Because Java

applets disabled copy and save functionality only in regions of the webpage where

the applet was presented, while allowing those same functions on other regions of

the webpage, Java applets “selectively” controlled access to copy and save

functions.

This was not the only means by which Java applets disabled copy and save

functions. Because Java applets are downloaded from potentially untrusted third-

party servers, the Java environment was programmed to not allow (and still does

not allow) a Java applet to access the client file system. (Ex. 1007 at ¶ 34.); see

4

also David Flanagan, Java in a Nutshell, A Desktop Quick Reference for Java

Programmers, p. 197 (1996) (Ex. 1007.) Access to the system clipboard was not

available in Java 1.0. (Id.) Thus, data provided in the applet could not be saved to

the file system or copied to the clipboard. In all these ways, Java applets disabled

or suppressed copy and save functions, exactly as applicants’ claimed invention

does. In fact, applicants admitted that these features of Java applets were well

known in the art:

• “As is well known in the art, HTML code can also include a Java applet.”

(Ex. 1001 at 5:12-13.)

• “Typically, applets are used to display animated graphic symbols in a

webpage. . . as well known to those skilled in the art.” (Id. at 5:19-22.)

• “ Because the Java enabled browser is running an applet for the image

data in region 12, the functions of the right mouse button are disabled for

region 12. Therefore, if the user clicks the mouse with the right button, no

menu option is automatically provided for saving, copying or printing the

displayed data in region 12. The right mouse button function is disabled

according to usual Java operation for applets as previously described.”

(Id. at 9:2-9.)

• “ As a result of processing a Java applet, the usual copy and save

functions will not be presented to the user….” (Id. at 2:21-24.)

5

• “If the user clicks the right mouse button on the data displayed by running

the applet, no drop-down menu is provided corresponding to the menu 9

shown in FIG. 2.” (Id. at 5:25-47 (note that the drop-down menu 9 in FIG. 2

provides copy and save functions).)

During prosecution, the applicants again admitted that Java applets disabled

save or copy functions for the region in which they were displayed:

• “Because the Java enabled browser is executing an applet for the image

data in region 12, the functions of a right mouse button including print, save

or copy are disabled for region 12. Therefore, if a user clicks a right button

of the mouse for region 12, no menu option is automatically provided for

saving, copying or printing the displayed data in region 12 in order to

prevent unauthorized copying.” (Ex. 1002 at 56; see also id. at 144.)

Applicants also admitted that the Java applet is the “program portion”

recited in the claims, and that Java applets were the method they contemplated

would perform the functionality of suppressing or preventing access to copy or

save functions:

• “[I]t is the program portion (e.g., a Java applet) that is being used to restrict

access to functions that would otherwise be legitimately available at the

client . . . .” (Id. at 254.)

All the foregoing admissions constitute Applicants’ Admitted Prior Art

6

(“AAPA”). Applicants did not invent the functionality of Java applets that restricts

right mouse button copy and save functionality. This functionality was developed

by Sun Microsystems in 1993-1995 as part of the Java language environment, and

was made available for public download in 1995. (Ex. 1007 at ¶¶ 19, 31, 37.)

And, each of the other elements of the alleged invention—encryption, and

decryption, as well as the features of the dependent claims—were well known in

the art, both alone and in the claimed combinations, as demonstrated below.

II. MANDATORY NOTICES – 37 C.F.R. § 42.8(a)(1)

A. Real Parties-in-Interest – 37 C.F.R. § 42.8(b)(1)

Netflix, Inc., a Delaware corporation with a principal place of business at

100 Winchester Circle, Los Gatos, CA 95032, is the real party-in-interest.

B. Related Matters – 37 C.F.R. § 42.8(b)(2)

The ’649 patent has been asserted by Patent Owner in Copy Protection LLC

v. Netflix, Inc., Civil Action No. 14-365 (LPS) in the U.S. District Court for the

District of Delaware.

C. Lead and Backup Counsel and Service Information – 37 C.F.R. § 42.8(b)(3) & (4)

Srecko Vidmar (Reg. No. 72,937) is lead counsel. Clayton C. James (pro

hac vice motion to be filed), Carey M. Rozier (Reg. No. 63,429), and Aaron

Oakley (Reg. No. 73,532) are backup counsel. The Petitioner may be served in

this matter as follows:

7

Post and Hand Delivery HOGAN LOVELLS US LLP One Tabor Center, Suite 1500 1200 Seventeenth Street Denver, CO 80202

Email lucky.vidmar@hoganlovells.com clay.james@hoganlovells.com matt.rozier@hoganlovells.com aaron.oakley@hoganlovells.com denverIPLit@hoganlovells.com

Telephone No. 303 899 7300 Facsimile No. 303 899 7333

III. NOTICE OF FEES PAID

Fees are submitted herewith. If any additional fees are due at any time

during the inter partes review proceedings, the undersigned authorizes the Office to

charge such fees to Deposit Account No. 50-1349.

IV. GROUNDS FOR STANDING (37 C.F.R. § 42.104(a))

Petitioner certifies that the ’649 patent is available for inter partes review

and that Petitioner is not barred or estopped from requesting such review. This

Petition is being filed within one year of service on Petitioner of a complaint for

infringement.

V. IDENTIFICATION OF CHALLENGE (37 C.F.R. § 42.104(b))

A. Relief Requested

Petitioner requests cancellation of claims 1-14 and 16-26 of the ’649 patent

on the following grounds.

Ground Claims Basis Prior Art References

8

Grounds based on Erickson as primary reference 1 1-6, 9-12, 14, 17,

19-21, 23-25 §102(e) Erickson

2 7, 8, 13, 22, 26 §103 Erickson in view of Kamba 3 16 §103 Erickson in view of AAPA 4 18 §103 Erickson in view of Mihm

Grounds based on Kamba as primary reference 5 1, 2, 5-13, and

19-26 §103 Kamba in view of Lagoze

6 3, 4 §103 Kamba in view of Lagoze, and further in view of AAPA

7 14, 17 §103 Kamba in view of Lagoze, and further in view of Erickson

8 16 §103 Kamba in view of Lagoze, and further in view of AAPA

9 18 §103 Kamba in view of Lagoze, and further in view of Mihm

Grounds based on Kamba as primary reference with AAPA 10 1-13, 16, and 19-

26 §103 Kamba in view of Lagoze, and further in

view of AAPA 11 14, 17 §103 Kamba in view of Lagoze, and further in

view of AAPA and Erickson 12 18 §103 Kamba in view of Lagoze, and further in

view of AAPA and Mihm

B. Necessity of Multiple Grounds

This Petition presents three groups of Grounds, each of which renders

invalid claims 1-14 and 15-26 of the ’649 patent. Grounds 1-4 are based on

Erickson, a prior art reference under 35 U.S.C. § 102(e). In pending litigation, the

Patent Owner has indicated it may try to establish a conception date that predates

the priority date on the face of the ’649 patent, thereby raising the possibility that

Erickson may not be available as prior art. Therefore, grounds based on the

combination of Kamba and Lagoze are also presented (Grounds 5-9). Both Kamba

9

and Lagoze are statutory prior art under 35 U.S.C. § 102(b). Petitioner therefore

submits that Grounds 5-9 are meaningfully distinct from Grounds 1-4 at least

because they cannot be sworn behind.3

Grounds 5-9 are also meaningfully distinct from Grounds 1-4 because they

disclose the same embodiment described in the ’649 patent, i.e., using Java applets

to request access to data, decrypt data sent over a network, and display that data at

a client. And Java applets, in their usual and normal operation, restricted copy and

save functions at the client, so the combination of Kamba and Lagoze discloses

every feature of the independent claims in the exact manner described by the ‘649

patent.

Finally, Kamba and Lagoze are addressed in view of applicants’ admissions.

(Grounds 10-12). As noted above, the ’649 patent expressly admits that Java

applets restricted and suppressed access to copy and save functions as part of their

usual operation, and those admissions constitute AAPA. See MPEP § 2129.

Combinations relying on AAPA have been recognized as valid bases for instituting

inter partes reviews. (See, e.g., ZTE Corporation and ZTE (USA), Inc., IPR2013-

00133, Paper 61: Final Written Decision (July 21, 2014).)

3 (See, e.g., Medtronic, Inc. et al. v. Tory R. Norred, M.D., IPR2014-00395, Paper 13: Decision, Institution of Inter Partes Review, at *20 (June 27, 2014) (instituting review for claims 16 and 19-24 on the basis of both a 102(e)-based ground and a 102(b)-based ground where the Patent Owner claimed an earlier conception date but failed to present pre-institution evidence sufficient to establish the earlier conception).)

10

Finally, additional grounds are required to address dependent claims related

to particular aspects of encryption and data protection.

C. Threshold Requirement for Inter Partes Review

This Petition for inter partes review demonstrates “a reasonable likelihood

that the Petitioner would prevail with respect to at least one of the claims

challenged in the petition.” (35 U.S.C. § 314(a).) All elements of claims 1-14 and

16-26 of the ’649 patent are taught in the prior art. This Petition presents grounds

that invalidate the claims of the asserted patent based on a primary reference,

Erickson, that anticipates each limitation of the ’649 Patent’s independent claims.

Further challenges are presented based on obviousness under 35 U.S.C. § 103, and

reasons to combine are established. None of the references cited herein were of

record during original prosecution. Further, during prosecution, the Examiner

failed to appreciate applicants’ admissions that claimed limitations were embodied

in the default copy-suppression features of Java applets, and that well-known

encryption and hashing technologies existed, and in doing so erroneously found

that the mere combination of these known prior art features was patentable. The

claims of the ’649 patent are invalid under more recent precedent because they are,

at best, directed to combinations of well-known existing technologies. (See KSR

Int'l Co. v. Teleflex, Inc., 550 U.S. 398, 416 (2007) (“The combination of familiar

elements according to known methods is likely to be obvious when it does no more

11

than yield predictable results.”).)

VI. CLAIM CONSTRUCTION

The terms in claims 1-14 and 16-26 are to be given their broadest reasonable

interpretation, as understood by a PHOSITA and consistent with the disclosure of

the ’649 patent. The broadest reasonable interpretation for all means-plus-function

claim terms appear below as required by 37 C.F.R. § 42.104(b)(3).

A. “protecting means for cryptographically protecting the requested data set” [claims 13 and 26]

Claims 13 and 26 recite a means-plus-function limitation governed by 35

U.S.C. 112(f): “protecting means for cryptographically protecting the requested

data set.” Petitioner identifies col. 7, ll. 53-67 as the portion of the specification

that describes the structure, material, and acts corresponding to the claimed

function of “cryptographically protecting the requested data set.” Consistent with

that section of the specification, the structure for performing the limitation

“protecting means for cryptographically protecting the requested data set” is a

special purpose computer programmed to implement the Data Encryption Standard

(“DES”) encryption algorithm or equivalent algorithms.

B. “generating means for generating a program portion for sending to the source of the access request” [claim 13 and 26]

Claims 13 and 26 recite a means-plus-function limitation governed by 35

U.S.C. 112(f): “generating means for generating a program portion for sending to

12

the source of the access request.” Petitioner identifies col. 5, ll. 12-19, col. 6, ll.

23-49, and col. 10, ll. 32-29 as the portions of the specification that describe the

structure, material, and acts corresponding to the claimed function of “generating a

program portion for sending to the source of the access request.” Consistent with

those sections of the specification, the structure for performing that limitation is a

special purpose computer programmed to package program code transmission over

a network.

VII. CITATION OF PRIOR ART

Claims 1-14 and 16-26 are unpatentable in view of the following prior art

references taken alone or in the combinations specified in the Grounds below:

• U.S. Patent No. 5,765,152 to Erickson (“System and Method for Managing

Copyrighted Electronic Media”) was filed on October 13, 1995 (“Erickson”)

(Ex. 1003). Erickson is prior art under at least 35 U.S.C. § 102(e).

• Applicants’ Admitted Prior Art (“AAPA”) – applicants admitted, both in

the specification of the ’649 patent and during prosecution, that use of Java

applets to disable right mouse button functionality constitutes prior art.

Applicants also admitted that the DES encryption and associated hashing

algorithms (a form of data integrity protection) as well as watermarking and

other steganographic protection techniques were prior art.

• U.S. Patent No. 5,402,490 to Mihm (“Process for Improving Public Key

13

Authentication”) was filed on September 1, 1992 and published on March 28,

1995 (“Mihm”) (Ex. 1005). Mihm is prior art under at least 35 U.S.C. §

102(b).

• Kamba, Tomonari et al., “The Krakatoa Chronicle – An Interactive,

Personalized, Newspaper on the Web,” presented in the 1995 Proceedings of

the Fourth International World Wide Web Conference (“WWW4”), pp. 1-15,

1995 (available at <http://www.w3.org/Conferences/WWW4/Papers/93/>),

(“Kamba”) (Ex. 1004). Mr. Dasan, who attended WWW4, confirms that

Kamba was published and available during the conference held on December

11-14, 1995. (Ex. 1007 at ¶ 51.) Specifically, Kamba was presented as part

of the Resource Discovery presentation at WWW4, as evidenced on the

website <http://www.w3.org/Conferences/WWW4/Program_Full.html>, last

updated on Dec. 11, 1995. Therefore, Kamba is prior art under at least 35

U.S.C. § 102(b).

• Lagoze, Carl, “A Secure Repository Design for Digital Libraries,” D-Lib

Magazine, Vol. 1, No. 12, Digital Library Research Group, pp. 1-8, December

1995 (available at <http://www.dlib.org/dlib/december95/12lagoze.html>),

(“Lagoze”) (Ex. 1006). Vol. 1, No. 12 of D-Lib Magazine, in which the

Lagoze article was published, was registered with an International Standard

Serial Number (ISSN) of 1082-9873. An ISSN is a widely recognized

14

standard identifier for published serials (See http://www.loc.gov/issn/).

Lagoze therefore qualifies as prior art under at least 35 U.S.C. § 102(b).

VIII. CLAIM-BY-CLAIM EXPLANATION OF GROUNDS FOR UNPATENTABILITY

A. PHOSITA

As used herein, a person having ordinary skill in the art (“PHOSITA”) refers

to a person having at least a B.S. in Electrical Engineering, Computer Engineering,

Computer Science, or a similar discipline, as well as approximately 4-5 years of

industry experience in data transmission, display, and security in a computer

network environment, and some exposure to web browsers and Hypertext Transfer

Protocol (“HTTP”). (Clark Decl., Ex. 1009, at ¶ 24; Ex. 1007 at ¶ 16.)

B. Grounds

1. Ground 1: Claims 1-6, 9-12, 14, 17, 19-21, and 23-25 are anticipated by Erickson

Erickson discloses each limitation of claims 1-6, 9-12, 14, 17, 19-21, and 23-

25, as shown in the charts below.

Generally, Erickson discloses systems and methods for managing

copyrighted electronic media. (Ex. 1003 at Abstract.) Users connect to a server

through a computer network to enable transfer of copyrighted media to the user.

(Id. at Abstract, 18:36-40.) Using a VIEWER program running at the client, the

user can request and receive access to media stored on the server. (Id. at Abstract,

15

18:36-40, 13:34 - 14:6.) The server encrypts the requested data and transmits that

media to the VIEWER. (Id. at 4:36-42, 17:59-64, 18:36-40). The VIEWER then

decrypts and displays the media. (Id. at Abstract, 13:35-48.) After the media has

been decrypted and is being displayed, the VIEWER blocks the user from copying

or saving the media to the local client file system, thereby protecting the

copyrighted media from unauthorized dissemination. (Id. at Abstract, 14:24-31.)

These are the exact steps described in the foregoing claims of the ‘649 patent.

1[a] A method of protecting data sent from a server to a client, said method comprising: “Copyrighted electronic media are packaged in a secure electronic format, and registered on associated registration server, which serves to provide on-line licensing and copyright management for that media. Users are connected to the server, e.g., through a computer network or the Internet, to enable data transfers and to transact licenses to utilize the media.” (Ex. 1003 at Abstract.) 1[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; “[t]he DOCUMENT 20 is viewable through a system constructed according to the invention and denoted herein as a ‘VIEWER.’” (Id. at 12:62-63.) “By way of example, user 96 has a VIEWER and is connected to the network 90 through communication line 97. The user 96 can thereby access the DOCUMENT 93 through the authorization server 94 up to the minimum permissions data set forth in the DOCUMENT format.” (Id. at 18:36-40.) “….the VIEWER contacts the DOCUMENT's Registration Server and initiates an authorization transaction. After the user is …the user uses a template-like interface to request auxiliary permissions....” (Id. at, 20:51-69.)

The VIEWER disclosed by Erickson is a program portion running at a client

computer. Erickson discloses using the VIEWER to generate and upload a request

seeking authorized access to data because a program that allows a user to connect

16

to a server through a communication line in order to access data (i.e.,

DOCUMENT 93) necessarily must request access to that data. Further, Erickson

expressly discloses using the VIEWER to request auxiliary permission, i.e.,

auxiliary access to DOCUMENT 93.

1[c] cryptographically protecting the data; “In other aspects, the invention provides an encrypted electronic signature and optional data encryption, to enhance or guarantee the authenticity of the entire work, including authorship. More particularly, in other aspects, the DOCUMENT encapsulates the required data in a secure fashion using encryption; and the digital signatures are based on message digests resulting from one-way hash functions.” (Ex. 1003 at 4:36-42.) “Accordingly, the methods of the invention include, for example, the step of encrypting the media through an RSA public key algorithm .” (Id. at 8:22-26.) “The Data Container 23 contains the information representing the electronic media, typically in an original file format. If desired by the author, this data can be secured through encryption, such as through secret or public key methods known in the art.” (Id. at 11:55-59.) “Encrypted data is preferably formatted with a secret key that is generated at the encryption event, and transported using public key encryption.” (Id. at 17:45-64.)

FIG. 1A of Erickson is a schematic view of a DOCUMENT. (Id. at 10:6-7.)

As shown in FIG. 1A, the DOCUMENT includes a Data Container portion 23 that

constitutes data representing the electronic media to be transmitted, data that “can

be encrypted.” (Id. at 11:55-59.) Thus, Erickson discloses cryptographically

protecting the data that represents the electronic media.

1[d] sending the cryptographically protected data to the client; and “Encrypted data is preferably formatted with a secret key that is generated at the

17

encryption event, and transported using public key encryption. Applications compatible with system 70 are preferably based on TCP/IP, and therefore operate in the same manner as most popular Internet-compatible users.” (Ex. 1003 at 17:59-64.) “By way of example, user 96 has a VIEWER and is connected to the network 90 through communication line 97. The user 96 can thereby access the DOCUMENT 93 through the authorization server 94 up to the minimum permissions data set forth in the DOCUMENT format.” (Id. at 18:36-40.)

Erickson discloses encrypting the Data Container portion 23, which is a

portion of the DOCUMENT, and allowing a user to access that DOCUMENT over

a network 90 through a communication line 97. (Ex. 1003 at 11:55-59.) Allowing

a user to access the DOCUMENT over a network constitutes sending the

cryptographically protected data in Data Container 23 to the user (i.e., the client.).

1[e] after the running of the program portion has begun and under control of the program portion at the client, converting the cryptographically protected data to an unprotected form and “FIG. 2 illustrates a VIEWER system 30 constructed according to the invention and which is suitable for viewing the DOCUMENT 20 illustrated in FIG. 1A. The VIEWER 30 includes a series of process actuators 32a . . . 32f….Process actuator 32c interprets--and sometimes decrypts--the data formulating the media 38, so that the user can view the media 38 to evaluate whether to engage in a licensing transaction.” (Ex. 1003 at 13:34 - 14:6.) “At a minimum, however, the VIEWER must be able to interpret the data within the DOCUMENT, including, if necessary, decrypt algorithms needed to unlock any encrypted data within the DOCUMENT 36….” (Id. at 14:15-20.) 1[f] selectively controlling access to copy or save functions at the client in respect of the data in its unprotected form. “[U]sers are typically permitted to view the packaged media--through a system which unpackages the media--but cannot save or otherwise transfer the media without obtaining auxiliary permissions to do so from the authorization server.” (Id. at Abstract.)

18

“The VIEWER will not, however, typically permit furt her actions--such as copying and/or downloading of the media 38 to disk--without first obtaining auxiliary licensing permissions from the associated authorization server, as described in more detail below. The VIEWER thus provides a minimum access to the data 38, such as viewing the media contents on the user's display terminal, thereby promoting limited but fair use of the data 38.” (Id. at 14:24-31.)

Erickson discloses, after the program portion has begun to run, selectively

controlling access to copy or save functions at the client with respect to the data in

its unencrypted form because the VIEWER allows viewing of the decrypted data

38 in a DOCUMENT but prevents users from copying or saving the data unless

further permissions are selectively obtained from the authorization server. (Ex.

1009 at ¶ 36.)

2. A method as in claim 1 wherein cryptographically protecting the data comprises protecting the data by encryption. “In other aspects, the invention provides an encrypted electronic signature and optional data encryption, to enhance or guarantee the authenticity of the entire work, including authorship. More particularly, in other aspects, the DOCUMENT encapsulates the required data in a secure fashion using encryption….” (Ex. 1003 at 4:36-42.) “The invention also provides for optional encryption of the data within the secure container. Accordingly, the methods of the invention include, for example, the step of encrypting the media through an RSA public key algorithm .” (Ex. 1003 at 8:22-26.) “The Data Container 23 contains the information representing the electronic media, typically in an original file format. If desired by the author, this data can be secured through encryption, such as through secret or public key methods known in the art.” (Id. at 11:55-59.)

19

3. A method as in claim 1 wherein cryptographically protecting the data comprises protecting the integrity of the data cryptographically. “…an encrypted Digital Signature 26 is also part of the DOCUMENT 20, to facilitate authentication. While only the Signature 26 needs to be encrypted to ensure the authenticity and integrity of the DOCUMENT 20, encryption of the bulk data 23 is also preferred since this guarantees a high level of security.” (Ex. 1003 at 12:49-55.) “Encrypted data is preferably formatted with a secret key that is generated at the encryption event, and transported using public key encryption. Applications compatible with system 70 are preferably based on TCP/IP, and therefore operate in the same manner as most popular Internet-compatible users.” (Id. at 17:59-64.)

Encrypting a digital signature to ensure the integrity of a document or data,

as taught by Erickson constitutes protecting the integrity of the data

cryptographically. (Ex. 1009 at ¶¶ 37-38)

4. A method as in claim 3 wherein the integrity of the data is achieved by hashing. “More particularly, in other aspects, the DOCUMENT encapsulates the required data in a secure fashion using encryption; and the digital signatures are based on message digests resulting from one-way hash functions.” (Ex. 1003 at 4:36-42.) “(5) Digital Signature: The Digital Signature provides authenticity and integrity of all information contained in the DOCUMENT. One secure way to do this is to attach a RSA digital signature to the DOCUMENT….evidence of certification and the DOCUMENT's hash results are contained in the signature.” (Id. at 23:9-17.)

Erickson’s disclosure of using hash functions to prepare digital signatures

for transmission with the DOCUMENT constitutes protecting the integrity of the

data in the DOCUMENT by hashing. (Ex. 1009 at ¶ 39.)

5. A method as in claim 1 including authenticating that the client is permitted to receive the data. “The VIEWER also facilitates on-line licensing of DOCUMENT-packaged works.

20

Based on registration information encapsulated with the data, i.e., the Document ID, the VIEWER contacts the DOCUMENT's Registration Server and initiates an authorization transaction. After the user is authenticated (typically utilizing the user's RSA digital signature, whereby the user's key is stamped by a certification authority) , the user uses a template-like interface to request auxiliary permissions, such as shown in FIG. 7a.” (Ex. 1003 at 20:51-60.)

6. A method as in claim 1 including identifying the client to the server before the data are sent to the client. “The VIEWER also facilitates on-line licensing of DOCUMENT-packaged works. Based on registration information encapsulated with the data, i.e., the Document ID, the VIEWER contacts the DOCUMENT's Registration Server and initiates an authorization transaction. After the user is authenticated (typically utilizing the user's RSA digital signature, whereby the user's key is stamped by a certification authority), the user uses a template-like interface to request auxiliary permissions, such as shown in FIG. 7a.” (Ex. 1003 at 20:51-60.)

9[a] A method of controlling access to data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Ex. 1003 at Abstract.) 9[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[d] above. (Id. at 17:59-64; 18:36-40.)

Erickson discloses accessing a DOCUMENT that includes encrypted, i.e.,

protected, data using a VIEWER. The DOCUMENT is accessed over a network

through a server 94. Erickson therefore discloses downloading a protected copy of

data to the VIEWER.

9[c] before using said protected copy, running a program at the client so that after running the program at the client has begun at the client, the program serves to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Ex. 1003 at 13:34 - 14:6; 14:15-20.)

Erickson discloses unprotecting the data contained in the DOCUMENT

21

because Erickson discloses decrypting that data to allow a user to access, i.e., view,

the data using the VIEWER.

9[d] (b) suppress client computer copy or save functions with respect to the unprotected copy of the requested data. See citations and notes for limitation 1[f] above. (Ex. 1003 at Abstract; 14:24-31.) 10[a] A method of controlling access to data sent from a server to a client, said method comprising: See citations for limitation 1[a] above. (Ex. 1003 at Abstract.) 10[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; See citations for limitation 1[b] above. (Id. at 12:62 – 13:15; 13:49-58; 18:36-40.) 10[c] cryptographically protecting the data; See citations for limitation 1[c] above. (Id. at 4:36-42; 8:22-26; 11:55-59; 17:45-64.) 10[d] sending the cryptographically protected data to the client; and See citations for limitation 1[d] above. (Id. at 17:59-64; 18:36-40.) 10[e] after access to the program portion is permitted and under control of the program portion, converting the cryptographically protected data to an unprotected form and See citations for limitation 1[e] above. (Id. at 13:34 - 14:6; 14:15-20.) 10[f] restricting or preventing access to copy or save functions at the client in respect of the data in its unprotected form. See citations for limitation 1[f] above. (Id. at Abstract; 14:24-31; 18:36-40.)

11[a] A method of controlling access to data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Id. at Abstract.) 11[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[c] and 1[d] above. (Id. at 4:36-42; 8:22-26; 17:45-64; 18:36-40.) 11[c] running a program at the client after access to the program is permitted to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Id. at 13:34 - 14:6; 14:15-20.) 11[d] (b) restrict or prevent client computer copy or save functions with

22

respect to the unprotected copy of the requested data. See citations for limitation 1[f] above. (Id. at Abstract; 14:24-31; 18:36-40.)

12. A method as in claim 1 wherein the data are sent to the client from the server through a network. See citations for limitation 1[d] above. (Ex. 1003 at 17:59-64; 18:36-40.)

14. A method as in claim 7 wherein the program portion includes data concerning a cryptographic key, and the method including using the key to render the downloaded cryptographically protected data into an unprotected form. “The Data Container 23 contains the information representing the electronic media, typically in an original file format. If desired by the author, this data can be secured through encryption, such as through secret or public key methods known in the art.” (Ex. 1003 at 11:23-59.) The VIEWER 30 includes a series of process actuators 32a…. Process actuator 32c interprets--and sometimes decrypts--the data formulating the media 38, so that the user can view the media 38 to evaluate whether to engage in a licensing transaction.” (Id. at 13:34 - 14:6.) “At a minimum, however, the VIEWER must be able to interpret the data within the DOCUMENT, including, if necessary, decrypt algorithms needed to unlock any encrypted data within the DOCUMENT 36….” (Id. at 14:17-20.) “Publicly distributed files are registered on a registration server, and if encrypted, the key resident on the server is passed to the user via a secure channel.” (Id. at 16:56-58.)

Erickson discloses that the data in Data Container 23, which is part of the

DOCUMENT, is encrypted using secret or public key methods. Erickson further

discloses that process actuator 32c in the VIEWER decrypts that data using a key

passed to the user via a secure channel, i.e., “data concerning a cryptographic key”

is passed to the “program portion” via the secure channel. Because process

actuator 32c in the VIEWER performs the decryption with the key, it has the data

23

concerning a cryptographic key at the time of decryption.

17. A method as in claim 1 including registering the client with the server. “Any user of a VIEWER or PACKAGER who wishes to engage in an on-line transaction typically presents an RSA-based, network-standard digital signature signed by a recognized Certification Authority. Both VIEWERs and PACKAGERs will thus contain RSA-based standardized procedures for creating and managing public/private key pairs, for engaging in certification transactions, and for becoming registered users.” (Ex. 1003 at 21:32-41.) “Verify that the user is a registered user. It will look for the user's RSA key with a certification stamp from an approved certification authority. Preferably, user registration capabilities are built into all VIEWER s and PACKAGERs.” (Id. at 23:66 – 24:2.)

19[a] A method of protecting data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 9[a] above. (Ex. 1003 at Abstract.) 19[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 9[b] above. (Id. at 11:55-59; 17:59-64; 18:36-40.) 19[c] running a program at the client after access to the program is permitted to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 9[c] above. (Id. at 13:34 - 14:6; 14:15-20.) 19[d] b) restrict or prevent client computer copy and save functions with respect to the unprotected copy of the requested data. See citations for limitation 9[d] above. (Id. at Abstract; 14:24-31; 18:36-40.)

20. A method as in claim 19, wherein the program running at the client generates and uploads a request for data from the client to the server, and the protected copy of requested data is downloaded from the server to the client in response to the request. See citations and notes for limitations 1[b] and 9[b] above. (Ex. 1003 at 11:55-59; 12:62 – 13:15; 13:49-58; 17:59-64; 18:36-40.)

21. A data storage medium storing copy protected data on the client received by a method according to claim 1. “The Data Container 23 contains the information representing the electronic media,

24

typically in an original file format. If desired by the author, this data can be secured through encryption, such as through secret or public key methods known in the art.” (Ex. 1003 at 11:55-59.) “Not all process actuators 32 are required in every VIEWER, depending upon the form of the DOCUMENT 36. At a minimum, however, the VIEWER must be able to interpret the data within the DOCUMENT, including, if necessary, decrypt algorithms needed to unlock any encrypted data within the DOCUMENT 36….” (Id. at 14:15-20.) “By way of example, user 96 has a VIEWER and is connected to the network 90 through communication line 97. The user 96 can thereby access the DOCUMENT 93 through the authorization server 94 up to the minimum permissions data set forth in the DOCUMENT format.” (Id. at 18:36-40.)

Erickson discloses a data storage medium because Erickson discloses

downloading encrypted data to the VIEWER on a user’s computer system, such as

a personal computer or laptop. The encrypted data is at least temporarily stored in

a data storage medium on the client computer in order to be decrypted by the

VIEWER, thus satisfying the “storing” term of this limitation.

23[a]. A method of protecting data downloaded from a server computer to a client computer, said method comprising: See citations for claim 9[a] above. (Ex. 1003 at Abstract.) 23[b] downloading a protected copy of requested data from a server to a client; and See citations for claim 9[b] above. (Id. at 11:55-59; 17:59-64; 18:36-40.) 23[c] running a program at the client so that after running the program at the client has begun at the client, the program serves to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for claim 9[c] above. (Id. at 13:34 - 14:6; 14:15-20.) 23[d] (b) suppress client computer copy and save functions with respect to the unprotected copy of the requested data. See citations for claim 9[d] above. (Id. at Abstract; 14:24-31; 18:36-40.)

25

24. A method as in claim 23, wherein the program running at the client generates and uploads a request for data from the client to the server, and the protected copy of requested data is downloaded from the server to the client in response to the request. See citations and notes for limitations 1[b] and 9[b] above. (Ex. 1003 at 11:55-59; 12:62 – 13:15; 13:49-58; 17:59-64; 18:36-40.)

25[a]. A method of protecting data sent from a server to a client, said method comprising: See citations for limitation 1[a] above. (Ex. 1003 at Abstract.) 25[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; See citations for limitation 1[b] above. (Id. at 12:62 – 13:15; 13:49-58; 18:36-40.) 25[c] cryptographically protecting the data; See citations for limitation 1[c] above. (Id. at 4:36-42; 8:22-26; 11:55-59; 17:45-64.) 25[d] sending the cryptographically protected data to the client; and See citations for limitation 1[d] above. (Id. at 17:59-64; 18:36-40.) 25[e] after access to the program portion is permitted and under control of the program portion, converting the cryptographically protected data to an unprotected form and See citations for limitation 1[e] above. (Id. at 13:34 - 14:6; 14:15-20.) 25[f] restricting or preventing access to copy or save functions at the client in respect of the data in its unprotected form. See citations for limitation 1[f] above. (Id. at Abstract; 14:24-31; 18:36-40.)

2. Ground 2: Erickson in view of Kamba renders obvious claims 7, 8, 13, 22, and 26

The limitations in claims 7, 8, 13, 22, and 26 are similar to the other

independent claims of the ’649 patent, except that these claims recite some version

of the steps “generating a program portion at a server” and/or “downloading the

program portion to the server.” These additional limitations are disclosed by the

combination of Erickson and Kamba.

Specifically, as detailed above, Erickson discloses a program portion (the

26

VIEWER) that requests and receives data over a network from a server, decrypts

that data, and displays that data to a user while restricting access to copy and save

function at the client in respect of the unencrypted data. (Ex. 1003 at 11:55-59;

13:34 - 14:6; 14:24-31; 18:36-40.) The VIEWER is available in several formats,

including as a stand-alone application, other applications with extensions or plug-

ins implementing VIEWER functionality, applications for integration into Internet

browsers such as Mosaic and Netscape, and a “software module resident within a

computer.” (Id. at 12:62 – 13:15; 13:49-58.) Therefore, Erickson discloses that

many different types of applications could be used to decrypt the data and suppress

copy and save functions.

Like Erickson, Kamba discloses methods of sending encrypted data to a

client and using a program portion (a Java applet) to display data at the client. (Ex.

1004 at pp. 3, 4, 10.) Kamba further discloses that the Java applet is generated at a

server and transmitted to a client over a network. (Id. at p. 8.) The applet is then

run at the client in order to allow access to data. (Id.) Thus, Kamba discloses

generating a program portion at a server, downloading the program portion to the

client, and running the program portion at the client. (Ex. 1009 at ¶ 44.)

Based on Kamba’s teaching of generating a program portion at a server and

downloading that program over a network to a client in order to allow the client to

access data, a PHOSITA would have found it obvious to modify Erickson such that

27

the VIEWER is generated at a server and downloaded to the client. (Ex. 1009 at ¶¶

46.) A PHOSITA would also have found it obvious to use the Java applet of

Kamba to implement Erickson’s VIEWER functionality. (Ex. 1009 at ¶ 45.)

Erickson and Kamba are directed to the same technical endeavor – delivering

media content to a user over a network. And the solution of Kamba (a Java applet)

is the type of solution expressly contemplated by Erickson because a Java applet is

a program that can be integrated into an Internet browser such as Netscape or can

run as a stand-alone application. (Ex. 1009 at ¶ 45.; see Ex. 1003 at 12:62 –

13:15.)

7[a] A method as in claim 1 including: generating the program portion at a server, Erickson discloses each and every limitation of claim 1. (See citations for Ground 1, claim 1 above.) “When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8.)

28

(Ex. 1004 at FIG. 1.) 7[b] downloading the program portion to the client, and “When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8., see also Ex. 1004 at FIG. 1) 7[c] running the program portion on the client such that a request is uploaded to the server for a file containing the cryptographically protected data. “More particularly, in other aspects, the DOCUMENT encapsulates the required data in a secure fashion using encryption; and the digital signatures are based on message digests resulting from one-way hash functions.” (Ex. 1003 at 4:39-42.) “By way of example, user 96 has a VIEWER and is connected to the network 90 through communication line 97. The user 96 can thereby access the DOCUMENT 93 through the authorization server 94 up to the minimum permissions data set forth in the DOCUMENT format.” (Ex. 1003 at 18:36-40.) “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6).” (Ex. 1004 at p. 10.)

8. A method as in claim 7 wherein the program portion is generated in response to, and corresponds with, an earlier received request for access to the data. “When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8.)

Kamba discloses generating a program portion (a Java newspaper applet) in

response to an earlier request for access to data (a user selecting the “Create

Today’s Newspaper” button).

13[a] A server for providing access to data sets in a protected form, the server comprising: “Copyrighted electronic media are packaged in a secure electronic format, and registered on associated registration server, which serves to provide on-line licensing and copyright management for that media. Users are connected to the

29

server, e.g., through a computer network or the Internet, to enable data transfers and to transact licenses to utilize the media.” (Ex. 1003 at Abstract.) 13[b] an input for receiving a request for access to a data set; See citations for limitation 1[b] above. (Id. at 12:62 – 13:15; 13:49-58; 18:36-40.)

To the extent that the combination of Erickson and Kamba does not

expressly disclose an input on the server, a PHOSITA would understand that a

server from which users can request protected data over a computer network

necessarily includes an input for receiving that request for access to data. (Ex.

1009 at ¶ 42)

13[c] protecting means for cryptographically protecting the requested data set; and “In other aspects, the invention provides an encrypted electronic signature and optional data encryption, to enhance or guarantee the authenticity of the entire work, including authorship. More particularly, in other aspects, the DOCUMENT encapsulates the required data in a secure fashion using encryption….” (Ex. 1003 at 4:36-42.)

A PHOSITA would understand that a server that is capable of encrypting

data is a special purpose computer programmed to implement an encryption

algorithm. (Ex. 1009 at ¶ 40; see also claim construction for this limitation in

Section VI.A.) Furthermore, using the DES algorithm to perform the bulk data

encryption taught by Erickson would have been an obvious design choice to a

PHOSITA. (Ex. 1009 at ¶ 41.) As detailed in the specification of the ’649 patent,

the DES algorithm was a part of the publicly available Federal Standards, and its

use was well known to those skilled in the art in 1995. (Ex. 1009 at ¶ 41; see ‘649

patent, 7:53-64.) The system disclosed by Erickson is compatible with use of the

30

DES algorithm, as it was commonplace to use DES encryption methods for bulk

data encryption in conjunction with the RSA digital signature integrity protection

taught by Erickson. (Ex. 1009 at ¶ 41) The ’649 patent does not disclose any

unexpected results from using the well-known DES algorithm and lists it as one

“example” of algorithms available to perform the limitation.

13[d] generating means for generating a program portion for sending to the source of the access request, “When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8.)

(Ex. 1004 at FIG. 1.)

A PHOSITA would understand that a server that composes an applet to be

sent to a client is a special purpose computer programmed to package Java applet

bytecodes for transmission over a network. (Ex. 1009 at ¶¶ 79-80; see also claim

construction for this limitation in Section VI.B.)

13[e] wherein said program portion is operable and after the program

31

portion is permitted to run at the source of the access request, in use: to generate a request for access to the cryptographically protected data set; “By way of example, user 96 has a VIEWER and is connected to the network 90 through communication line 97. The user 96 can thereby access the DOCUMENT 93 through the authorization server 94 up to the minimum permissions data set forth in the DOCUMENT format.” (Ex. 1003 at 18:36-40.) 13[f] on receipt of the cryptographically protected data set, to convert it into an unprotected form; and “FIG. 2 illustrates a VIEWER system 30 constructed according to the invention and which is suitable for viewing the DOCUMENT 20 illustrated in FIG. 1A. The VIEWER 30 includes a series of process actuators 32a . . . 32f, each of which decodes and/or interprets the several elements of the DOCUMENT 20. The VIEWER 30 is connected for data transfer along data transfer line 34 to communicate and operate on the DOCUMENT 36, stored for example on a server. . . .Process actuator 32c interprets--and sometimes decrypts--the data formulating the media 38, so that the user can view the media 38 to evaluate whether to engage in a licensing transaction.” (Ex. 1003 at 13:34 - 14:6.) 13[g] to selectively control access to copy or save functions in respect of the data set when in said unprotected form. “[U]sers are typically permitted to view the packaged media--through a system which unpackages the media--but cannot save or otherwise transfer the media without obtaining auxiliary permissions to do so from the authorization server.” (Ex. 1003 at Abstract.) “The VIEWER will not, however, typically permit furt her actions--such as copying and/or downloading of the media 38 to disk--without first obtaining auxiliary licensing permissions from the associated authorization server, as described in more detail below. (Ex. 1003 at 14:24-28.)

22[a]. A computer program carrier medium containing a computer program which are executable by a computer to perform method steps for implementing a server, the method steps comprising: See citations for limitation 13[a] above. (Ex. 1003 at Abstract.) 22[b] receiving a request for access to a data set; See citations for limitation 13[e] above. (Ex. 1003 at 18:36-40.) 22[c] cryptographically protecting the requested data set; and See citations for limitation 13[c] above. (Ex. 1003 at 4:36-42.) 22[d] generating a program portion for sending to the source of the access request,

32

“When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8, see also Ex. 1004 at FIG. 3). 22[e] wherein said program portion is operable and after the program portion is permitted to run at the source of the access request, in use: generating a request for access to the cryptographically protected data set; See citations for limitation 13[d] above. (Ex. 1004 at p. 8; FIG. 1) 22[f] on receipt of the cryptographically protected data set, converting it into an unprotected form; and See citations for limitation 13[f] above. (Ex. 1003 at 13:34 - 14:6.)

26[a]. A server for providing access to data sets in a protected form, the server comprising: See citations for limitation 13[a] above. (Ex. 1003 at Abstract.) 26(b) an input for receiving a request for access to a data set; See citations and note for limitation 13[b] above. (Ex. 1003 at Abstract.) 26(c) protecting means for cryptographically protecting the requested data set; and See citations and note for limitation 13[c] above. (Ex. 1003 at 4:36-42.) 26(d) generating means for generating a program portion for sending to the source of the access request, See citations and note for limitation 13[d] above. (Ex. 1004 at p. 8; FIG. 1.) 26[e] wherein after access to the program portion is permitted and said program portion is operable, in use: to generate a request for access to the cryptographically protected data set; See citations for limitation 13[e] above. (Ex. 1003 at 18:36-40.) 26[f] on receipt of the cryptographically protected data set, to convert it into an unprotected form; and See citations for limitation 13[f] above. (Ex. 1003 at 13:34 - 14:6.) 26[g] to restrict or prevent access to copy or save functions in respect of the data set when in said unprotected form. See citations for limitation 13[g] above. (Ex. 1003 at Abstract; 14:24-28.)

3. Ground 3: Erickson in view of AAPA renders obvious claim 16

Claim 16 is taught by Erickson in view of admitted prior art in the ’649

patent. Claim 16 recites “A method as in claim 1 wherein the data is

33

steganographically marked.” As detailed above with respect to Ground 1, Erickson

discloses each and every limitation of claim 1.

The ’649 patent admits that steganographic marking techniques for ensuring

the authenticity of a document, such as watermarking, were known prior to the

alleged invention described in the ’649 patent. “Watermarking is a well-known

example of a technique termed steganography.” (’649 patent, 7:29-30.) The ‘649

patent then explains that one technique for watermarking is described in

“Disappearing Cryptography”, P. Wayner, Academic Press 1996 (ISBN 0-12-

738671-8) (“Wayner”). (’649 patent, 7:30-33.) As explained by the ‘649 patent,

“[w]atermarking gives additional security in the event the protected data is

copied,” and can be used to supplement the authentication step (step S9) of the

’649 patent. (Id. at 7:33-38.)

Erickson discloses that one purpose of data encryption is to “enhance or

guarantee the authenticity of the entire work, including authorship.” (Ex. 1003

at 4:36-42.) It would have been obvious to a PHOSITA to supplement the

encryption and authentication techniques disclosed by Erickson with the

watermarking techniques disclosed by the ’649 patent, since all were known

methods for ensuring the authenticity of a work. The use of the well-known

technique of watermarking in conjunction with Erickson’s encryption and

authentication methods would have yielded only the predictable result of

34

providing additional security to the content data during transmission over a

network. (See KSR, 550 U.S. 398, 416 (2007); see also ’649 patent, 7:33-38.)

4. Ground 4: Erickson in view of Mihm renders obvious Claim 18

Claim 18 is taught by Erickson in view of Mihm. As detailed above in

Ground 1 with reference to claim 1, Erickson teaches restricting access to data to

authorized users, and also teaches registering users with a server prior to allowing

the user to access data from that server. (See Ex. 1003 at 21:32-41; 23:66 – 24:2.)

Claim 18 adds nothing more than authenticating, in addition to the individual user,

his or her client machine. Mihm discloses a method of authenticating users that

relies on “equipment identifying” data in conjunction with cryptographic keys to

enhance the security of a networked system. Mihm further discloses data

identifying equipment in addition to data identifying the individual subscriber.

(Ex. 1005 at 13:9-20.)

A PHOSITA would have found it obvious to use the authentication methods

disclosed by Mihm to achieve or supplement the subscriber or licensee

authentication access restrictions taught by Erickson. Further, Mihm itself

includes an express coupling of individual and machine identifiers, together with

encryption, similar to the allegedly novel combination claimed by claim 18.

(Mihm 13:9-20; 2:36-41.)

18. A method as in claim 1 including: determining a machine identifier of the

35

client by analysing its hardware and/or its software configuration, “ Identifiers 80 describe the subscriber by name, address, credit information, phone numbers, and other data deemed useful to the service provider. In addition, this identifying data includes equipment identifying data (ID) 82 (see FIG. 7). Equipment ID 82 is preferably, but not necessarily, a unique identifying number which is associated with each user terminal 12.” (Ex. 1005 at 13:9-20.) “The service is accessible through user terminals that have equipment identification data (ID) associated therewith.” (Id. at 2:33-32.) transmitting the machine identifier to the server, “This identifying data may be supplied by the subscriber through paper forms sent to authentication center 30 or through electronic communications.” (Id. at 7:21-23.) combining the transmitted machine identifier with a cryptographic key to form a unique determinator for the client, “The authentication center receives an equipment ID for each terminal, generates a series of sequence numbers and uses a secret key to encrypt the sequence numbers and the equipment ID with a user ID and an error detection code to form an encrypted block.” (Id. at Abstract.) “An encrypted block of data, which includes the equipment ID and sequence numbers, is then formed. The encrypted block of data is stored in the user terminal, and the user terminal sends a log-on message to the service provider. The log-on message includes the encrypted block and the equipment ID.” (Id. at 2:36-41.) “After task 90, a task 92 encrypts the combined user ID, equipment ID, sequence number, and EDC using the current key, discussed above in connection with task 56 (see FIG. 4)…..After encryption, this data form an encrypted block 94, which is illustrated in the block diagram of FIG. 8.” (Id. at 8:9-19.) “For example, those skilled in the art may devise a similar system which does not use user IDs but which encrypts each equipment ID with its own unique encryption key.” (Id. at 13:28-31.) transmitting the unique determinator to the client, to be stored therein for use subsequently in identifying the client to the server, to permit encypted [sic] data to be downloaded thereto from the server. “…uses a secret key to encrypt the sequence numbers and the equipment ID with a

36

user ID and an error detection code to form an encrypted block. This block is programmed into an authentication module and sent to the subscriber for installation in the subscriber’s terminal. The authentication center sends a public key to network authentication nodes. When the subscriber operates the terminal to gain access to the network, a log-on message, which includes the encrypted block and an unencrypted version of the equipment ID, is sent to an authentication node. The node decrypts the encrypted block and evaluates the IDs and sequence number to determine whether to grant access to services.” (Id. at Abstract.) “As shown in FIG. 8, identifying block 112 includes two types of data. One type of data is the terminal’s equipment ID 114 and the other type of data represents other log-on parameters. Equipment ID 114 is the same equipment ID value that has been communicated to authentication center 30 and used in forming authentication block 98….Referring to FIG. 9, after task 110, a task 115 forms and sends a log-on message 116 (FIG. 8) over the link 22 (see FIG. 1) established above in task 108. Message 116 includes the current authentication block 98, identifying block 112, and a header 118.” (Id. at 10:8-18.)

5. Ground 5: Kamba in view of Lagoze renders obvious claims 1, 2, 5-13, and 19-26

As illustrated below, every element of claims 1, 2, 5-13, and 19-26 is taught

by Kamba in view of Lagoze, including using a program portion, specifically a

Java applet, to selectively control access to protected data.

Kamba discloses a personalized newspaper available through the Internet, or

World Wide Web. (Ex. 1004 at p. 1). The newspaper is implemented using a Java

applet that is transmitted to users at a remote client and then used to display

newspaper articles within a web browser. (Id.) At the user’s request, the Java

applet is generated at a server and transmitted to a user at a remote client. (Id. at

pp. 1 and 8). Once running in the user’s web browser, the Java applet allows a

37

user to request articles from a server and displays those articles to the user. (Id. at

pp. 1 and 3, FIGS. 3 and 6.)

Lagoze discloses object based designs for online digital libraries and

methods of protecting data stored and disseminated by the digital libraries. (Ex.

1006 at pp. 1, 2 and 4.) Specifically, Lagoze discloses packaging and delivering

data from a server to clients over a network. (Id. at pp. 3 and 4.) Access

conditions are imposed to prohibit unauthorized users from accessing the

disseminated data. (Id. at p. 4.) Most importantly, Lagoze discloses that a

network-accessible applet in a “safe language” such as Java can be used to decrypt

the disseminated data once it is determined that a user is authorized to view the

content. (Id. at p. 4.)

A PHOSITA would have found it obvious to modify Kamba’s Java applets

to provide the Java applet-based decryption abilities taught by Lagoze. (Ex. 1007

at ¶ 53; Ex. 1009 at ¶¶ 82-86.) Such a modification would be merely the

application of known encryption methods to achieve the predictable result of

providing secure data transmittal over a network. (See Ex. 1007 at ¶ 53; Ex. 1009

at ¶ 83.) Kamba and Lagoze are in the same field of endeavor, i.e., network based

content distribution systems, and in relevant part are both directed to the use of

Java applets for selectively controlling access to protected data in the context of

content distribution systems. (See Ex. 1007 at ¶ 53; Ex. 1009 at ¶ 83.)

38

1[a] A method of protecting data sent from a server to a client, said method comprising: “Java has a library for handling TCP/IP protocols and can access remote objects via URLs [10] easily, which allows us to have continuous bi-directional communication between server and client.” (Ex. 1004 at p. 3.) “Wrapping the delivered content with access rules gives us the ability to broaden the ISOS security framework to restrict access to disseminations. For example, the access rules might specify and enforce access only to the individual who originally requested the dissemination, or it might specify and enforce "read once" access. We are exploring mechanisms for doing this such as encrypting the data in the dissemination.” (Ex. 1006 at p. 4.) 1[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6). . . . Article files are cached, and the agent fetches new articles from the server end only if needed.” (Ex. 1004 at p. 10; see also FIGS. 3 and 6.) 1[c] cryptographically protecting the data; “We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the dissemination after authentication of the user, or some other action.” (Lagoze, p. 4.) 1[d] sending the cryptographically protected data to the client; and “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6).” (Ex. 1004 at p. 10.) “We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java….” (Ex. 1006 at p. 4.) 1[e] after the running of the program portion has begun and under control of the program portion at the client, converting the cryptographically protected data to an unprotected form and “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6).” (Ex. 1004 at p. 10.)

39

“We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the dissemination after authentication of the user, or some other action.” (Ex. 1006 at p. 4.)

As demonstrated above, Kamba discloses a content distribution system that

uses a Java applet running on a client to fetch and display data (news articles) from

a server. (Ex. 1004 at pp. 3 and 10; FIGS. 1, 3, and 4.) Kamba does not explicitly

teach encrypting the data prior to transmission, but Lagoze teaches a content

distribution system that encrypts data at a server and transmits it to a client as well

as using a Java applet to decrypt that data. (Ex. 1006 at p. 4.) The ’649 patent

itself recognizes that prior art encryption algorithms, for both encrypting and

decrypting, could be fetched using a Java applet. (Ex. 1001 at 7:53-64.)

1[f] selectively controlling access to copy or save functions at the client in respect of the data in its unprotected form. “Java [8] is an object-oriented, programming language which can be compiled to architecture-neutral, byte-code for safe execution within a Java virtual machine. A Java applet is a java program designed specifically to be embedded in HTML documents. Java applets can implement arbitrary user interfaces, and can communicate with other entities over the network.” (Ex. 1004 at p. 3.) “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6).” (Ex. 1004 at p. 10; see also FIGS. 1, 3, and 4) “We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the dissemination after authentication of the user, or some other action.” (Ex. 1006 at p. 4.)

40

Limitation 1(f) was a normal, default function of Java applets: Kamba

in view of Lagoze discloses limitation 1[f] because both references expressly

disclose Java applets and, as explained in detail in the Introduction, Java applets, as

part of their normal operation, did not enable right mouse button copy and save

functionalities, and were specifically programmed to block access to the client file

system. (See Introduction; see also Ex. 1007 at ¶¶ 42, 56.) The patentee even

admitted that this feature was a default feature of Java applets: “[t]he right mouse

button function is disabled according to usual Java operation for applets….” (Ex.

1001 at 9:8-9; 4:53-65.)

During prosecution, the applicants represented to the USPTO that disabling

right mouse button functionality constituted “selectively controlling access to copy

or save functions at the client in respect of the data in its unprotected form” and

similar limitations in the claims. (See Introduction.) Thus, Kamba in view of

Lagoze discloses limitation 1(f) and the similar limitations “suppressing copy or

save functions” and “restricting and preventing access to copy or save functions”

because the Java applets disclosed by Kamba and Lagoze disabled right mouse

click functionality using default Java functionality, as applicants admitted.

2. A method as in claim 1 wherein cryptographically protecting the data comprises protecting the data by encryption. “We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the

41

dissemination after authentication of the user, or some other action.” (Ex. 1006 at p. 4.)

5. A method as in claim 1 including authenticating that the client is permitted to receive the data. “The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the dissemination after authentication of the user, or some other action.” (Ex. 1006 at p. 4.)

6. A method as in claim 1 including identifying the client to the server before the data are sent to the client. “First, the user types in their user ID and password within a login form. After authentication by the cgi-script on the server, the user can select either ‘Change Profiles’, ‘Create Today's Newspaper’, or ‘Read Today's Newspaper’.” (Ex. 1004 at p. 7.) “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6).” (Ex. 1004 at p. 10.) “Wrapping the delivered content with access rules gives us the ability to broaden the ISOS security framework to restrict access to disseminations. For example, the access rules might specify and enforce access only to the individual who originally requested the dissemination, or it might specify and enforce "read once" access.” (Ex. 1006 at p. 4.)

7[a] A method as in claim 1 including: generating the program portion at a server, “When the user chooses the "Create Today's Newspaper" button, each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client..” (Ex. 1004 at p. 8.)

42

(Ex. 1004 at FIG. 1.) “We are exploring mechanisms for doing this such as encrypting the data in the dissemination. The terms and conditions might specify a network-available "applet" in a "safe" language (e.g., Java [10] or Python [11]) that could decrypt the dissemination after authentication of the user, or some other action.” (Ex. 1006 at p. 4.) 7[b] downloading the program portion to the client, and “… each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8; see also FIG. 1.) “The terms and conditions might specify a network-available "applet" ….” (Ex. 1006 at p. 4.) 7[c] running the program portion on the client such that a request is uploaded to the server for a file containing the cryptographically protected data. “…the applet code on the client fetch articles from the server side (see Figure 6)….Article files are cached, and the agent fetches new articles from the server end only if needed.” (Ex. 1004 at p. 10; see also FIGS. 3 and 6.)

8. A method as in claim 7 wherein the program portion is generated in response to, and corresponds with, an earlier received request for access to the data. “When the user chooses the "Create Today's Newspaper" button , each article's personal and community weights are computed, and a java newspaper applet is composed by the cgi-script and sent to the client.” (Ex. 1004 at p. 8.)

A user’s choice of the “Create Today’s Newspaper” button is a request for

access to data that triggers generation of the Java newspaper applet, which

43

subsequently delivers the data.

9[a] A method of controlling access to data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 9[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 9[c] before using said protected copy, running a program at the client so that after running the program at the client has begun at the client, the program serves to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[e], it

would have been obvious to a PHOSITA that the Java applets disclosed by Kamba

could be modified to provide the Java applet-based decryption abilities taught by

Lagoze. (Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

9[d] (b) suppress client computer copy or save functions with respect to the unprotected copy of the requested data. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

10[a] A method of controlling access to data sent from a server to a client, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 10[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 10[c] cryptographically protecting the data; See citations for limitation 1[c] above. (Ex. 1006 at p. 4.)

44

10[d] sending the cryptographically protected data to the client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 10[e] after access to the program portion is permitted and under control of the program portion, converting the cryptographically protected data to an unprotected form and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[e], it

would have been obvious to a PHOSITA that the Java applets disclosed by Kamba

could be modified to provide the Java applet-based decryption abilities taught by

Lagoze. (Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

10[f] restricting or preventing access to copy or save functions at the client in respect of the data in its unprotected form. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

11[a] A method of controlling access to data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 11[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 11[c] running a program at the client after access to the program is permitted to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[e], it

would have been obvious to a PHOSITA that the Java applets disclosed by Kamba

could be modified to provide the Java applet-based decryption abilities taught by

45

Lagoze. (Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

11[d] (b) restrict or prevent client computer copy or save functions with respect to the unprotected copy of the requested data. See citations for claim 9[d] above. (Liu, 1:55-62; 1:63-2:10; 3:22-34.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

12. A method as in claim 1 wherein the data are sent to the client from the server through a network. “Java applets can implement arbitrary user interfaces, and can communicate with other entities over the network….In addition, Java has a library for handling TCP/IP protocols and can access remote objects via URLs [10] easily, which allows us to have continuous bi-directional communication between server and client.” (Ex. 1004 at p. 3.) “In the Krakatoa Chronicle, this flexible layout control was implemented by having the applet code on the client fetch articles from the server side (see Figure 6)….and the agent fetches new articles from the server end only if needed.” (Ex. 1004 at p. 10.)

To the extent that the combination of Erickson and Kamba does not

expressly disclose an input on the server, a PHOSITA would understand that a

server from which users can request protected data over a computer network

necessarily includes an input for receiving a request for access to data. (Ex. 1009

at ¶ 42.)

13[a] A server for providing access to data sets in a protected form, the server comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 13[b] an input for receiving a request for access to a data set; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.)

46

To the extent the combination of Kamba and Lagoze does not expressly

disclose an input on the server, a PHOSITA would understand that a server from

which users can request protected data over a computer network necessarily

includes an input for receiving a request for access to data. (Ex. 1009 at ¶ 81.)

13[c] protecting means for cryptographically protecting the requested data set; and See citations for limitation 1[c] above. (Ex. 1006 at p. 4.)

As discussed above with respect to Ground 2, limitation 13[c], a PHOSITA

would understand that using the DES algorithm to perform the data encryption

taught by Lagoze would have been an obvious design choice. The use of DES in

conjunction with the security framework taught by Lagoze (CORBA) was well

known in the art. (Ex. 1009 at ¶ 87 ; see Ex. 1006 at Abstract.)

13[d] generating means for generating a program portion for sending to the source of the access request, See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.)

A PHOSITA would understand that a server that composes an applet to be

sent to a client is a special purpose computer programmed to package Java applet

bytecodes for transmission over a network. (See Ex. 1009 at ¶ 79-80; see also

claim construction for this limitation in Section VI.B.)

13[e] wherein said program portion is operable and after the program portion is permitted to run at the source of the access request, in use: to generate a request for access to the cryptographically protected data set; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 13[f] on receipt of the cryptographically protected data set, to convert it into an unprotected form; and

47

See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[e], it

would have been obvious to a PHOSITA that the Java applets disclosed by Kamba

could be modified to provide the Java applet-based decryption abilities taught by

Lagoze. (Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

13[g] to selectively control access to copy or save functions in respect of the data set when in said unprotected form. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

19[a] A method of protecting data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 19[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 19[c] running a program at the client after access to the program is permitted to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, it would have

been obvious to a PHOSITA that the Java applets disclosed by Kamba could be

modified to provide the Java applet-based decryption abilities taught by Lagoze.

(Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

19[d] b) restrict or prevent client computer copy and save functions with respect to the unprotected copy of the requested data.

48

See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

20. A method as in claim 19, wherein the program running at the client generates and uploads a request for data from the client to the server, and the protected copy of requested data is downloaded from the server to the client in response to the request. See citations for limitations 1[b] and 1[d] above. (Ex. 1004 at p. 10, FIGS. 3 and 6; Ex. 1006 at p. 4.)

21. A data storage medium storing copy protected data on the client received by a method according to claim 1. “Java applets can implement arbitrary user interfaces, and can communicate with other entities over the network. A Java-aware browser is a WWW browser that embeds Java virtual machine and can handle applet tags. Since the downloaded code runs on the client locally….” (Ex. 1004 at p. 3.)

Kamba discloses a data storage medium because Kamba discloses

downloading copy protected data to a client to run the code locally, where the

client is a computer that is capable of running an internet browser, such as a

personal computer or laptop. A PHOSITA would understand that personal

computers and laptops necessarily include data storage media to store the

downloaded material.

22[a]. A computer program carrier medium containing a computer program which are executable by a computer to perform method steps for implementing a server, the method steps comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 22[b] receiving a request for access to a data set; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 22[c] cryptographically protecting the requested data set; and

49

See citations for limitation 1[c] above. (Ex. 1006 at p. 4.) 22[d] generating a program portion for sending to the source of the access request, See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 22[e] wherein said program portion is operable and after the program portion is permitted to run at the source of the access request, in use: generating a request for access to the cryptographically protected data set; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 22[f] on receipt of the cryptographically protected data set, converting it into an unprotected form; and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, it would have

been obvious to a PHOSITA that the Java applets disclosed by Kamba could be

modified to provide the Java applet-based decryption abilities taught by Lagoze.

(Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

22[g] selectively controlling access to copy or save functions in respect of the data set when in said unprotected form. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

23[a]. A method of protecting data downloaded from a server computer to a client computer, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 23[b] downloading a protected copy of requested data from a server to a client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 23[c] running a program at the client so that after running the program at the client has begun at the client, the program serves to both: (a) unprotect the downloaded data thereby to provide access to an unprotected copy of the requested data, and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

50

For the reasons described above with respect to Ground 5, it would have

been obvious to a PHOSITA that the Java applets disclosed by Kamba could be

modified to provide the Java applet-based decryption abilities taught by Lagoze.

(Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

23[d] (b) suppress client computer copy and save functions with respect to the unprotected copy of the requested data. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

24. A method as in claim 23, wherein the program running at the client generates and uploads a request for data from the client to the server, and the protected copy of requested data is downloaded from the server to the client in response to the request. See citations for limitations 1[b] and 1[d] above. (Ex. 1004 at p. 10, FIGS. 3 and 6; Ex. 1006 at p. 4.)

25[a]. A method of protecting data sent from a server to a client, said method comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 25[b] running a program portion at the client, the program portion generating and uploading to the server a request for access to data; See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 25[c] cryptographically protecting the data; See citations for limitation 1[c] above. (Ex. 1006 at p. 4.) 25[d] sending the cryptographically protected data to the client; and See citations for limitation 1[d] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.) 25[e] after access to the program portion is permitted and under control of the program portion, converting the cryptographically protected data to an unprotected form and See citations for limitation 1[e] above. (Ex. 1004 at p. 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, it would have

51

been obvious to a PHOSITA that the Java applets disclosed by Kamba could be

modified to provide the Java applet-based decryption abilities taught by Lagoze.

(Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-86.)

25[f] restricting or preventing access to copy or save functions at the client in respect of the data in its unprotected form. See citations for limitation 1[f] above. (Ex. 1004 at pp. 3, 8, and 10; Ex. 1006 at p. 4.)

For the reasons described above with respect to Ground 5, limitation 1[f],

Kamba in view of Lagoze discloses this limitation.

26[a]. A server for providing access to data sets in a protected form, the server comprising: See citations for limitation 1[a] above. (Ex. 1004 at p. 10.; Ex. 1006 at p. 4.) 26(b) an input for receiving a request for access to a data set; See citations and note limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 26(c) protecting means for cryptographically protecting the requested data set; and See citations and note for limitation 13[c] above. (Ex. 1006 at p. 4.) 26(d) generating means for generating a program portion for sending to the source of the access request, See citations for limitation 1[b] above. (Ex. 1004 at pp. 3 and 10, FIGS. 3 and 6.) 26[e] wherein after access to the program portion is permitted and said program portion is operable, in use: to generate a request for access to the cryptographically protected data set; See citations and note for limitation 1[b] above. (Id. at at 3 and 10, FIGS. 3 and 6.) 26[f] on receipt of the cryptographically protected data set, to convert it into an unprotected form; and See citations for limitation 1[e] above. (Id. at at 10; Ex. 1006 at p. 4.) 26[g] to restrict or prevent access to copy or save functions in respect of the data set when in said unprotected form.

52

See citations and note for limitation 1[f] above. (Id. at at 3, 8, and 10; Ex. 1006 at p. 4.)

6. Ground 6: Kamba in view of Lagoze and further in view of AAPA renders obvious claims 3 and 4

As illustrated below, every limitation of claims 3 and 4 is taught by Kamba

in view of Lagoze, and further in view of AAPA.

Claim 3 recites: “A method as in claim 1 wherein cryptographically

protecting the data comprises protecting the integrity of the data

cryptographically.”

Claim 4 recites: “A method as in claim 3 wherein the integrity of the data is

achieved by hashing.”

As detailed above in Ground 5, Kamba in view of Lagoze discloses each and

every limitation of claim 1. Kamba in view of Lagoze further disclose methods of

controlling access to disseminated data in a network environment and discloses

using encryption techniques as one example of data access control. (See, e.g., Ex.

1006 at p. 4 (“We are exploring mechanisms for doing this such as encrypting the

data in the dissemination.”).)

The ’649 patent admits that the use of hashing techniques was known prior

to the alleged invention. Specifically, in describing the hashing process, the ’649

patent points to the well-known SHA hashing algorithm as a “suitable form” of

hashing for use with the system described in the ’649 patent. (’649 patent, 7:48-

53

52.) The ’649 patent then explains that the SHA algorithm is “described in more

detail in National Institute of Standards and Technology, Federal Information

Processing Standards Publication 180-1 (NIST FIPS PUB 180-1) SECURE HASH

STANDARD.” (Id. at 7:48-52.)

Hashing is one method of protecting the integrity of data. (Ex. 1009 at ¶

88.) The hashing methods described by NIST FIPS PUB 180-1 were well known

to PHOSITAs in 1995, and it was commonplace to use forms of data integrity

protection such as hashing in network-based data encryption methods. (Id.) It

would have been obvious to a PHOSITA to supplement the encryption and

authentication disclosed by Kamba in view of Lagoze with data integrity protection

like the NIST FIPS PUB 180-1 standard referenced by the ’649 patent. (Id. at ¶

89.) The use of the well-known technique of hashing, in conjunction with the

encryption and authentication methods taught by Lagoze in combination with

Kamba would have yielded merely the predictable result of providing additional

security to the data during transmission over a network. (See KSR Int'l Co. v.

Teleflex, Inc., 550 U.S. 398, 416 (2007); see also Ex. 1009 at ¶ 89.)

7. Ground 7: Kamba in view of Lagoze and further in view of Erickson renders obvious claims 14 and 17

As detailed in Ground 5, Kamba in view of Lagoze discloses each and every

limitation of claims 1 and 7. As detailed in Ground 1, Erickson discloses each and

every limitation of claims 14 and 17.

54

A PHOSITA would have found it obvious to modify the combination of

Kamba and Lagoze with the teachings of Erickson because doing so would

represent only the application of known methods to achieve the predictable result

of providing additional security to copyrighted material or other sensitive material

delivered via a network. Kamba, Lagoze, and Erickson are in the same field of

endeavor, each being directed to delivery of content over a network. Lagoze and

Erickson each teach protecting data via encryption for transmission over a

network, and decrypting the data at a client. And the Kamba-Lagoze combination

and Erickson both disclose using the program or program portion (the applet or

VIEWER, respectively) to perform the decryption. It would therefore have been

obvious to use the cryptographic methods taught by Erickson, including the use of

a cryptographic key, as the method of encrypting and decrypting the data disclosed

by Kamba in view of Lagoze and to add the additional security layer of client

registration, as taught by Erickson, to Kamba in view of Lagoze.

14. A method as in claim 7 wherein the program portion includes data concerning a cryptographic key, and the method including using the key to render the downloaded cryptographically protected data into an unprotected form. Kamba in view of Lagoze teaches each and every element of claim 7 (See Ground 5, claim 7.) “The Data Container 23 contains the information representing the electronic media, typically in an original file format. If desired by the author, this data can be secured through encryption, such as through secret or public key methods known in the art.” (Ex. 1003 at 11:23-59.)

55

The VIEWER 30 includes a series of process actuators 32a…. Process actuator 32c interprets--and sometimes decrypts--the data formulating the media 38, so that the user can view the media 38 to evaluate whether to engage in a licensing transaction.” (Ex. 1003 at 13:34 - 14:6.) “Publicly distributed files are registered on a registration server, and if encrypted, the key resident on the server is passed to the user via a secure channel.” (Ex. 1003 at 16:56-58.)

17. A method as in claim 1 including registering the client with the server. As detailed above with respect to Ground 5, Kamba in view of Lagoze teaches each and every element of claim 1. “Both VIEWERs and PACKAGERs will thus contain RSA-based standardized procedures for creating and managing public/private key pairs, for engaging in certification transactions, and for becoming registered users.” (Ex. 1003 at 21:32-41.) “Verify that the user is a registered user. It will look for the user's RSA key with a certification stamp from an approved certification authority. Preferably, user registration capabilities are built into all VIEWER s and PACKAGERs.” (Ex. 1003 at 23:66 – 24:2.)

8. Ground 8: Kamba in view of Lagoze and further in view of AAPA renders obvious claim 16

Every element of claim 16 is taught by Kamba in view of Lagoze, and

further in view of AAPA, rendering this claim unpatentable under 35 U.S.C. §103.

As detailed in Ground 5, Kamba in view of Lagoze discloses each and every

limitation of claim 1. Ground 3 above provides a detailed analysis of applicants'

admissions that steganographic marking techniques such as watermarking were

well known in the art.

It would have been obvious to a PHOSITA to supplement the encryption and

56

authentication disclosed by Lagoze in combination with Kamba with the

watermarking techniques disclosed by AAPA, as referenced by the ’649 patent.

The use of the well-known technique of watermarking in conjunction with the

encryption and authentication methods taught by Lagoze in combination with

Kamba would have done nothing more than yield the predictable result of

providing additional security to the content data during transmission over a

network. (See KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398, 416 (2007).)

9. Ground 9: Kamba in view of Lagoze and further in view of Mihm renders obvious claim 18

Every element of claim 18 is taught by Kamba in view of Lagoze, and

further in view of Mihm, rendering this claim unpatentable under 35 U.S.C. §103.

As detailed above in Ground 5, Kamba in view of Lagoze discloses each and every

limitation of claim 1.

Kamba in view of Lagoze teaches restricting access to data to users

authorized to access the data. (See Ex. 1006 at p. 4.) As detailed in the claim chart

below, Mihm discloses a method of authenticating users that utilizes equipment

identifying data in conjunction with cryptographic keys to enhance the security of

a networked system. A PHOSITA would have recognized the advantage of

employing Mihm’s system as an authentication service for an application that

delivers protected material, as disclosed by Kamba in view of Lagoze. (See Ex.

1009 at ¶ 50.) Doing so would be nothing more than the application of a known

57

authentication method to achieve the predictable result of ensuring a client

attempting to access data over a network was authorized to access that data.

18. A method as in claim 1 including: determining a machine identifier of the client by analysing its hardware and/or its software configuration, “Identifiers 80 describe the subscriber by name, address, credit information, phone numbers, and other data deemed useful to the service provider. In addition, this identifying data includes equipment identifying data (ID) 82 (see FIG. 7). Equipment ID 82 is preferably, but not necessarily, a unique identifying number which is associated with each user terminal 12..” (Ex. 1005 at 13:9-20.) “The service is accessible through user terminals that have equipment identification data (ID) associated therewith.” (Ex. 1005 at 2:33-32.) transmitting the machine identifier to the server, “This identifying data may be supplied by the subscriber through paper forms sent to authentication center 30 or through electronic communications.” (Ex. 1005 at 7:21-23.) combining the transmitted machine identifier with a cryptographic key to form a unique determinator for the client, “The authentication center receives an equipment ID for each terminal, generates a series of sequence numbers and uses a secret key to encrypt the sequence numbers and the equipment ID with a user ID and an error detection code to form an encrypted block.” (Ex. 1005 at Abstract.) “An encrypted block of data, which includes the equipment ID and sequence numbers, is then formed. The encrypted block of data is stored in the user terminal, and the user terminal sends a log-on message to the service provider. The log-on message includes the encrypted block and the equipment ID.” (Ex. 1005 at 2:36-41.) “After task 90, a task 92 encrypts the combined user ID, equipment ID, sequence number, and EDC using the current key, discussed above in connection with task 56 (see FIG. 4)…..After encryption, this data form an encrypted block 94, which is illustrated in the block diagram of FIG. 8.” (Ex. 1005 at 8:9-19.) “For example, those skilled in the art may devise a similar system which does not

58

use user IDs but which encrypts each equipment ID with its own unique encryption key.” (Ex. 1005 at 13:28-31.) transmitting the unique determinator to the client, to be stored therein for use subsequently in identifying the client to the server, to permit encypted [sic] data to be downloaded thereto from the server. “…uses a secret key to encrypt the sequence numbers and the equipment ID with a user ID and an error detection code to form an encrypted block. This block is programmed into an authentication module and sent to the subscriber for installation in the subscriber’s terminal. The authentication center sends a public key to network authentication nodes. When the subscriber operates the terminal to gain access to the network, a log-on message, which includes the encrypted block and an unencrypted version of the equipment ID, is sent to an authentication node. The node decrypts the encrypted block and evaluates the IDs and sequence number to determine whether to grant access to services.” (Ex. 1005 at Abstract.) “As shown in FIG. 8, identifying block 112 includes two types of data. One type of data is the terminal’s equipment ID 114 and the other type of data represents other log-on parameters….Referring to FIG. 9, after task 110, a task 115 forms and sends a log-on message 116 (FIG. 8) over the link 22 (see FIG. 1) established above in task 108. Message 116 includes the current authentication block 98, identifying block 112, and a header 118.” (Ex. 1005 at 10:8-18.)

10. Ground 10: Kamba in view of Lagoze and further in view of AAPA renders obvious claims 1-13, 16, and 19-26

Claims 1-13, 16, and 19-26 are obvious over Kamba in view of Lagoze and

further in view of AAPA, even if it is determined that the Java applets of Kamba

do not selectively control, suppress or restrict access to copy and save functions.

As detailed above in the Introduction, use of Java applets to disable right mouse

button functionality constitutes AAPA because applicants admit that such

functionality is the usual operation of Java applets, and therefore results simply

from the decision to use a Java applet. And because disabling right mouse button

59

functionality in a portion of a browser selectively controls access to copy or save

functions (claims 1, 13, and 22), suppresses client computer copy or save functions

(claims 9 and 23), and restricts or prevents access to copy or save functions (claims

10, 11, 19, 25, and 26), those limitations are rendered obvious by Kamba in view

of Lagoze and further in view of AAPA. (See Introduction.)

As explained in further detail in Ground 5, a PHOSITA would have found it

obvious to modify the Java applets disclosed by Kamba to provide the Java applet-

based decryption abilities taught by Lagoze. (Ex. 1007 at ¶ 53; Ex. 1009 at ¶¶ 82-

86.) Further, because Kamba in view of Lagoze and AAPA both relate to

functionality of Java applets, a PHOSITA would have understood that the applet

resulting from Kamba in view of Lagoze would perform as described by AAPA.

For the remainder of the analysis of claims 1, 2, 5-13, and 19-26, see Ground

5. For claims 3 and 4, see Ground 6. For claim 16, see Ground 8.

11. Ground 11: Kamba in view of Lagoze and further in view of AAPA and Erickson renders obvious claims 14 and 17

As detailed above in Ground 7, Erickson teaches encryption and decryption

methods using cryptographic keys stored in a program portion at the client, and

also teaches registering a client with a server. For the same reasons detailed in

Ground 7, it would have been obvious to modify the combination of Kamba in

view of Lagoze and further in view of AAPA, which discloses each and every

limitation of claim 1, to include these features of Erickson.

60

12. Ground 12: Kamba in view of Lagoze and further in view of AAPA and Mihm renders obvious claim 18

As detailed above with respect to Ground 10, Kamba in view of Lagoze and

further in view of AAPA discloses each and every limitation of claim 1. For the

same reasons detailed in Ground 9, it would have been obvious to modify the

combination of Kamba in view of Lagoze and further in view of AAPA, which

discloses each and every limitation of claim 18, to include the authentication

features of Mihm.

Dated: March 23, 2015 Respectfully submitted,

s/Srecko Vidmar/ Srecko Vidmar (Reg. No. 72,937) Clayton C. James (pro hac vice motion to be filed) Carey M. Rozier (Reg. No. 63,429) Aaron Oakley (Reg. No. 73,532) Hogan Lovells US LLP One Tabor Center, Suite 1500 1200 Seventeenth Street Denver, CO 80202 Telephone: 303-899-7300 Counsel for Petitioner Netflix, Inc.

A-1

Appendix A Table of Exhibits

Exhibit No. Description

1001 U.S. Patent No. 7,079,649 (Bramhill) (Challenged Patent)

1002 File History for U.S. Patent No. 7,079,649 1003 U.S. Patent No. 7,765,152 (Erickson) 1004 Kamba, Tomonari et al., “Process for Improving Public

Key Authentication,” “The Krakatoa Chronicle – An Interactive, Personalized, Newspaper on the Web,” pp. 1-15, 1995 (Kamba)

1005 U.S. Patent No. 5,402,490 (Mihm) 1006 Lagoze, Carl, “A Secure Repository Design for Digital

Libraries,” D-Lib Magazine, Vol. 1, No. 12, Digital Library Research Group, pp. 1-8, December 1995 (Lagoze)

1007 Declaration of Vasanthan Dasan 1008 Curriculum Vitae of Vasanthan Dasan 1009 Declaration of Paul C. Clark, DSc. 1010 Curriculum Vitae Paul C. Clark, DSc. 1011 David Flanagan, Java in a Nutshell, A Desktop Quick

Reference for Java Programmers, p. 197 (1996)

B-1

Appendix B. Certificate of Service

I certify that on March 23, 2015, a copy of this Petition was served on Patent

Owner via overnight Federal Express at the following address:

Larry Nixon Nixon & Vanderhye, PC 901 North Glebe Road 11th Floor Arlington, VA 22203 I further certify that on March 23, 2015, a copy of this Petition was served on

the Patent Owner at the following address via Federal Express:

Stephen Roth Lerner David Littenberg Krumholz & Mentlik, LLP 600 South Avenue West Westfield, NJ 07090-1497

s/Carey M. Rozier/ Carey M. Rozier (Reg. No. 63,429) Attorney for Petitioner