unified patents v. grecia, ipr2016-00602

8/20/2019 Unified Patents v. Grecia, IPR2016-00602

1/58

IPR2016–00602 Petition

U.S. Patent 8,887,308

i

DOCKET NO.: 098173–0966641

Filed on behalf of Unified Patents Inc.

By: Paul C. Haughey, Reg. No. 31,836

Scott Kolassa, Reg. No. 55,337Kilpatrick Townsend & Stockton LLP

Two Embarcadero Center, Eighth Floor

San Francisco, CA 94111–3834

Tel: (415) 576–0200

Email: [email protected]

Jonathan Stroud, Reg. No. 72,518

Unified Patents Inc.

1875 Connecticut Av. NW, Floor 10

Washington D.C., 20009Tel: (650) 999–0455

Email: [email protected]

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

UNIFIED PATENTS INC.

Petitioner

v.

WILLIAM GRECIA

Patent Owner

IPR 2016–00602

Patent 8,887,308

PETITION FOR I NTER PARTES REVIEW OF

U.S. PATENT NO. 8,887,308

CHALLENGING CLAIM 1

UNDER 35 U.S.C. § 312 AND 37 C.F.R. § 42.104


2/58


U.S. Patent 8,887,308

i

TABLE OF CONTENTS

I. MANDATORY NOTICES ........................................................................ - 1 -

A.

Real Party–in–Interest ...................................................................... - 1 -

B. Related Matters ................................................................................. - 1 -

C. Counsels ........................................................................................... - 2 -

D. Service Information, Email, Hand Delivery, and Postal .................. - 2 -

II. CERTIFICATION OF GROUNDS FOR STANDING ............................. - 2 -

III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED ............... - 2 -

A. Prior Art Patents and Printed Publications ....................................... - 3 -

1. U.S. Patent 6,891,953, filed on June 27, 2000 and issued

on May 10, 2005 (“DeMello” (EX1006)), which is prior

art under 35 U.S.C. § 102(b). ................................................. - 3 -

2. U.S. Pub. 2008/0313264, filed on Jun. 12, 2007 and

published on Dec. 18, 2008 (“Pestoni” (EX1007)), which

is prior art under 35 U.S.C. § 102(b). .................................... - 3 -

3. U.S. Pat. 8,001,612, filed Aug. 12, 2005 and issued Aug.

16, 2011 (“Wieder” (EX1008)), which is prior art under

35 U.S.C. § 102(e). ................................................................ - 3 -

B. Grounds for Challenge ..................................................................... - 3 -

IV. OVERVIEW OF THE ’308 PATENT ....................................................... - 4 -

A. Priority Date of the ’308 Patent........................................................ - 4 -

B. Summary of the ’308 Patent ............................................................. - 4 -

C. Person of Ordinary Skill in the Art ................................................ - 10 -

V. CLAIM CONSTRUCTION ..................................................................... - 11 -

A. “verified web service” .................................................................... - 12 -


3/58


U.S. Patent 8,887,308

ii

B. “verification data” .......................................................................... - 13 -

C. “verification token” ........................................................................ - 13 -

D.

“authorization object” .................................................................... - 16 -

E. “credential assigned to the apparatus of a)” ................................... - 17 -

F. “apparatus of (a)” ........................................................................... - 18 -

G. “recognized” ................................................................................... - 18 -

VI. PROPOSED REJECTIONS SHOWING THAT PETITIONER HAS A

REASONABLE LIKELIHOOD OF PREVAILING ............................... - 19 -

A. Ground 1: Claim 1 is unpatentable as obvious over DeMello

(EX1006) in view of the admitted prior art and Wieder

(EX1008). ....................................................................................... - 20 -

B. Ground 2: Claim 1 is unpatentable as obvious over Pestoni

(EX1007) in view of the admitted prior art and Wieder

(EX1008). ....................................................................................... - 39 -

VII. CONCLUSION ......................................................................................... - 52 -


4/58


U.S. Patent 8,887,308

iii

EXHIBIT LIST

Exhibit No. Description

1001 U.S. Patent No. 8,533,860 to Grecia.



1004 Grecia v. Amazon.com, No. 2:14-cv-00530 (W.D. Wash. Dec.

22, 2014) (Joint claim construction statement by Patent Owner

and Amazon), and Ex. C

1005 Sony Network Entertainment Int’l v. Grecia, IPR2015-00422,Preliminary Response (PTAB Mar. 11, 2015)

1006 U.S. Patent No. 6,891,953 to DeMello et al., Prior Art under 35

U.S.C. § 102(b)

1007 U.S. Pub. No. 20080313264 to Pestoni, Prior Art under 35

U.S.C. § 102(b)

1008 U.S. Pat. 8,001,612 to Wieder, Prior Art under 35 U.S.C. §

102(e)

1009 Declaration of Ravi S. Cherukuri & Exhibits A–D

1010 Unified Patents LLC Voluntary Interrogatories


5/58


U.S. Patent 8,887,308

- 1 -

I. MANDATORY NOTICES

A. Real Party–in–Interest

Pursuant to 37 C.F.R. § 42.8(b)(1), Petitioner certifies that Unified is the real

party–in–interest, and further certifies that no other party exercised control or

could exercise control over Unified’s participation in this proceeding, the filing of

this petition, or the conduct of any ensuing trial. See EX1010, Unified Patents

LLC Voluntary Interrogatories.

B.

Related Matters

U.S. Patent No. 8,887,308 (“ ’308 Patent” (EX1003)) is a continuation of

U.S. Patent No. 8,533,860 (“ ’860 Patent” (EX1001)), which is a continuation of

U.S. Patent No. 8,402,555 (“ ’555 Patent (EX1002)). An IPR petition on the ’860

Patent was filed Feb. 17, 2016 (IPR2016–00600). Since Dec. 6, 2013, Grecia has

asserted the ’308 Patent against Amazon.com; American Express; Apple;

MasterCard; Samsung; Sony Network Entertainment; and Visa. Grecia has also

asserted the ’860 Patent against each of the foregoing, as well as Adobe Systems;

AT&T; Charter Communications; Comcast; Digital Entertainment Content

Ecosystem; DirecTV; DISH Network; Google; Microsoft; RCN Telecom Services;

Time Warner Cable; Vudu; Walt Disney; and WideOpenWest Finance. Finally,

Grecia has asserted the ’555 Patent against the following five of the foregoing:

Adobe Systems; American Express; DISH Network; MasterCard; and Visa.


6/58


U.S. Patent 8,887,308

- 2 -

A Petition for Inter Partes review was filed by Sony Network Entertainment

International LLC, IPR2015–00422, PTAB, December 14, 2014 and dismissed by

request of the parties.

C.

Counsels

Lead Counsel for Petitioner is Paul C. Haughey (Reg. No. 31,836), of

Kilpatrick Townsend & Stockton LLP. Back–up Counsel is Jonathan Stroud (Reg.

No. 72,518), of Unified, and Scott E. Kolassa (Reg. No. 55,337), of Kilpatrick

Townsend & Stockton LLP.

D.

Service Information, Email, Hand Delivery, and Postal

Unified consents to electronic service at

[email protected], [email protected], and

[email protected].

II.

CERTIFICATION OF GROUNDS FOR STANDING

Petitioner certifies pursuant to Rule 42.104(a) that the patent for which

review is sought is available for inter partes review and that Petitioner is not

barred or estopped from requesting and inter partes review challenging the patent

claims on the grounds identified in this Petition.

III.

OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

Pursuant to Rules 42.22(a)(1) and 42.104(b(1)–(2), Petitioner challenges

claim 1 of the ’308 Patent.


7/58


U.S. Patent 8,887,308

- 3 -

A. Prior Art Patents and Printed Publications

The following references are pertinent to the grounds of unpatentability

explained below:1

1.

U.S. Patent 6,891,953, filed on June 27, 2000 and issued on May 10, 2005

(“ DeMello” ( EX1006)), which is prior art under 35 U.S.C. § 102(b).

2.

U.S. Pub. 2008/0313264, filed on Jun. 12, 2007 and published on Dec. 18,

2008 (“ Pestoni” (EX1007)), which is prior art under 35 U.S.C. § 102(b).

3. U.S. Pat. 8,001,612, filed Aug. 12, 2005 and issued Aug. 16, 2011

(“Wieder ” (EX1008)), which is prior art under 35 U.S.C. § 102(e).

B.

Grounds for Challenge

This Petition, supported by the declaration of Ravi S. Cherukuri (“Cherukuri

Decl.”) requests cancellation of challenged claim 1 of the ’308 Patent as

unpatentable under 35 U.S.C. §103.

1 The ’308 Patent issued from a patent application filed prior to enactment of

the America Invents Act (“AIA”). Accordingly, pre–AIA statutory framework

applies.


8/58


U.S. Patent 8,887,308

- 4 -

IV. OVERVIEW OF THE ’308 PATENT

A. Priority Date of the ’308 Patent

The ’308 Patent resulted from Application 13/888,051, filed on May 6, 2013

as a continuation of Application No. 13/740,086, filed on Jan. 11, 2013, now the

’860 Patent, which is a continuation of Application No. 13/397,517, filed on Feb.

15, 2012, now the ’555 Patent, which is a continuation of Application No.

12/985,351, filed on Jan. 6, 2011, now abandoned, which is a continuation of

Application No. 12/728,218, filed on Mar. 21, 2010, now abandoned. Although

not listed on the ’308 Patent, in the 11–27–2012 response in the prosecution

history of the ’555 Patent, Patent Owner claimed priority to his Provisional

Application No. 61/303,292 (filed Feb. 10, 2010) to swear behind Baiya U.S. Pub.

No. 20110288946. Petitioner does not believe the ’308 Patent is entitled to the

Feb. 10, 2010 priority date, but assumes that is the effective date for the purposes

of this petition since all the prior art is more than a year earlier than this date.

B.

Summary of the ’308 Patent

The ’308 Patent is directed to Digital Rights Management (DRM). The prior

art was alleged to tie media to a particular user or limited number of devices:

“The current metadata writable DRM measures do not offer a

way to provide unlimited interoperability between different

machines. Therefore, a solution is needed to give consumers the


9/58


U.S. Patent 8,887,308

- 5 -

unlimited interoperability between devices ….” (’308 Patent at

3:1 – 3:5).

“DRM schemes for e–books include embedding credit card

information and other personal information inside the metadata

area of a delivered file format and restricting the compatibility

of the file with a limited number of reader devices and

computer applications.” Id ., 2:19–23.

The alleged innovation of the ’308 Patent is to obtain a membership

identification reference (e.g., Facebook ID) from a website providing membership

and write it into the metadata of the media. This allows anyone with the

membership reference ID to access the media on any device. The claim elements

of claim 1 generally correspond to the steps of Fig. 6 of the ’308 Patent, copied

below:


10/58


U.S. Patent 8,887,308

- 6 -

Claim 1 of the ’308 Patent is simple but lengthy, and is summarized below

with the letters corresponding to the elements in the claim charts below, and the

numbers corresponding to Fig. 6 above:

Preamble: Transforming a user request for cloud (Internet) digital content

into an authorization object.

(a) (602) Receive user request, with a verification token, for content access.

(b) (604) The verification token is authenticated using a verification token


11/58


U.S. Patent 8,887,308

- 7 -

database. Patent Owner admitted the corresponding steps B and C of the

parent ’860 Patent are in the prior art (as discussed below).

(c) (606) Establish an API connection with a verified web service.

(d) (608) A verified web service account identifier (e.g., Facebook ID) is

requested from the user.

(e) (610) The verified web service account identifier is received.

(f) (612)The verification token or verified web service account identifier is

written into the content metadata.

With respect to the similar parent ’860 Patent, Patent Owner has suggested

that the particular order set forth above is required, and that all corresponding 6

modules of Fig. 1 must be present and separate. See Sony Network Entertainment

Int’l v. Grecia, IPR2015-00422 at 3–4, 17–18 (PTAB Mar. 11, 2015) (Preliminary

Response) (“Sony v. Grecia Preliminary Response” (EX1005)). However, the

Provisional Application never mentioned the word “module” as used in the claims,

and did not have the module diagram of Fig. 1. The ’308 Patent suggests it would

be obvious to vary the order of the steps:

“In this document, relational terms such as `first` and

second`, and the like may be used solely to distinguish

one entity or action from another entity or action without

necessarily requiring or implying any actual such


12/58


U.S. Patent 8,887,308

- 8 -

relationship or order between such entities or actions.”

’308 Patent, 4:61–65.

Fig. 3 of the ’308 Patent, copied below, shows an embodiment where a user

obtains content using GUI 301 on the left, using a “verification token” that is

authenticated. This corresponds to the first two steps, 602 and 603, which are

admitted prior art for the corresponding ’860 Patent claim elements. Note the

same described system performs both steps. Then, the user uses GUI 307 on the

right to contact a “verified web service” (e.g., Facebook) to verify the user using an

electronic ID (e.g., Facebook login). The same system performs the last 3 steps.


13/58


U.S. Patent 8,887,308

- 9 -

Petitioner notes that the term “excelsior enabler” as used in the specification

simply means user. Patent Owner characterized it as follows: “authorized users

(excelsior enablers).” June 12, 2012 response to office action in ’555 Patent. The

term “enabler” was also originally in the parent ’555 Patent claims, but was

replaced with “user.” “Excelsior” refers to the main, or first user: “[T]he excelsior

enabler and secondary enablers defined comprises human beings or computerized

mechanisms programmed to process steps of the invention as would normally be

done manually by a human being.” ’308 Patent, 5:13–17.Summary of Relevant

Prosecution File History

The claims in the parent ’555 Patent were originally rejected as obvious

under §103 over Baiya U.S. Pre-Grant Publication Number 2011/0288946

(“ Baiya”) in view of U.S. Patent 7,526,650 to Wimmer (“Wimmer ”). The

Examiner’s reasons for allowance noted that Baiya and Wimmer taught the first

two elements of the claims, which correspond to the first two elements of the ’308

Patent claims. The ’860 Patent was allowed with an Examiner’s Amendment and

no rejection, and the reasons for allowance listed Baiya and Wimmer as the closest

prior art. Neither of them show a user’s membership used to brand digital content

so it could be used on multiple devices. Baiya describes a content management

system for a group or a business, where libraries for documents and other media


14/58


U.S. Patent 8,887,308

- 10 -

are established and authorized users are given keys to access those libraries.

Wimmer describes branding video content with an end user's personal identity

information as a deterrent against unauthorized redistribution. Thus, the Examiner

found no reference where a user’s membership was used to brand digital content so

it could be used on multiple devices. This feature, however, is clearly present in

the prior art references discussed herein.

The ’308 Patent is a continuation of the ’860 Patent. Claim 1 as issued was

presented in a preliminary amendment, and was allowed in a first office action

with an Examiner’s amendment. The reasons for allowance cited Baiya and

Wimmer as the closest prior art, and referred in particular to elements c) and d) of

claim 1 (relating to communicating with the verified web service and obtaining the

verified web service identifier). A terminal disclaimer to obviate an obviousness–

type double patenting rejection was filed prior to the first action by the Examiner.

C.

Person of Ordinary Skill in the Art

One of ordinary skill in the art at time of the earliest claimed effective filing

date of the ’308 Patent (Feb. 10, 2010) would possess at least a university degree

or have equivalent professional experience related to electronics and/or software,

with some experience in digital rights management such as two years of work

experience. See Cherukuri Decl. (EX1009) at ¶¶ 4-10, 28-32. The claims of the


15/58


U.S. Patent 8,887,308

- 11 -

’308 Patent are directed to a DRM system used with standard computers

communicating over known network means. Thus, one of ordinary skill in the art

requires knowledge of DRM programs, generally. ( Id. at ¶ 22.

V.

CLAIM CONSTRUCTION

Claim terms of a patent in inter partes review are normally given the

“broadest reasonable construction in light of the specification.” See 37 C.F.R. §

42.100(b): see also In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1279–81

(Fed. Cir. 2015).

The following discussion proposes constructions and support for those

constructions. Any claim terms not included in the following discussion should be

given their ordinary meaning in light of the specification, as commonly understood

by those of ordinary skill in the art. The broadest reasonable interpretation of a

claim term may be the same as or broader than the construction under the standard

set forth in Phillips v. AWH Corp, 415 F.3d 1303 (Fed. Cir. 2005), but it cannot be

narrower. See Facebook, Inc. v. Pramatus AV LLC , 2014 U.S. App. LEXIS 17678,

*11 (Fed. Cir. 2014). The constructions proposed below should be applied

regardless of whether the terms are interpreted under the Phillips standard or the

“broadest reasonable interpretation” standard.

There have been no claim construction orders yet in the District Court

litigations involving the ’860 Patent. There has been a joint claim construction


16/58


U.S. Patent 8,887,308

- 12 -

statement by Patent Owner and Amazon. See Grecia v. Amazon.com, No. 2:14-cv-

00530 (W.D. Wash. Dec. 22, 2014) (Joint claim construction statement by Patent

Owner and Amazon), and Ex. C (“Grecia v. Amazon.com Claim Construction”

(EX1004)); see also 37 C.F.R. § 42.62 and F.R.E. 801(d)(2). See also Cherukuri

Decl. (EX1009) at ¶ 13.

A.

“verified web service”

Outside the claims, this term only appears once in the ’308 patent:

“The web service equipped with the API is usually a well–

known membership themed application in which the users must

use an authentic identification. Some example includes

Facebook in which as a rule, members are required to use their

legal name identities. A reference number or name with the

Facebook Platform API represents this information. Other

ver i f ied web services in which real member names are required

such as the LinkedIn API and the PayPal API and even others

could be used, but for this discussion, Facebook will be used

only as an example of how the authentication element of the

invention is utilized.” (’308 Patent at 10:41–51, emphasis

added.) There is no discussion of what is meant by “verified.”

In the Grecia v. Amazon litigation, for the parent ’860 Patent, Patent Owner

proposed “a web service accessible with an authenticated credential” and Amazon

proposed “a web service that is used to authenticate the identity of a user or


17/58


18/58


U.S. Patent 8,887,308

- 14 -

the encrypted digital media.” ‘308 Patent at 6: 38–40. The absence of

“membership” in the claim suggests a broader meaning is intended. In claim 1 of

the parent ’860 Patent, one option for the verification token was a “credit card,”

such as that used to buy the media, and other token examples are set forth in the

following from the ’308 Patent:

“At step 702, one or more media items are selected by the user

to form the encrypted digital media. ….

According to various embodiments of the present invention, the

verification is facilitated by at least one token handled by at

least one excelsior enabler. Examples of the token include, and

are not limited to, a structured or random password, e–mail

address associated with an e–commerce payment system used

to make an authorization payment, or other redeemable

instruments of trade for access rights of digital media.Examples of e–commerce systems are PayPal, Amazon

Payments, and other credit card services.

According to an embodiment of the present invention, an

identifier for the digital media is stored in a database with

another database of a list of associated tokens for cross–

reference identification for verification.” Id . at 8:34–56.

Per the kodekey quote above, another option is the serial number assigned to

the digital media. Id . at 6:38–40. The intent is to allow verification of user of the

media, as opposed to verifying the media serial number. In another example in the


19/58


U.S. Patent 8,887,308

- 15 -

’308 patent, the token refers to something which identifies the media purchased,

rented or a media membership – essentially a purchase or transaction identifier or

receipt:

“According to an embodiment of the present invention, the

database of a list of associated tokens includes Instant Payment

Notification (IPN) received from successful financial

e–commerce transactions that includes the identifier for the

digital media; import of CSV password lists, and manually

created reference phrases.

For this discussion, the structured or random password example

will be used as reference. The structured or random passwords

can be devised in encoded schemes to flag the apparatus of

permission type such as:

1) Purchases can start a password sequence with "P" following

a random number, so further example would be

"PSJD42349MFJDF". 2) Rentals can start or end a password

sequence with "R" plus (+) the number of days a rental is

allowed, for example "R7" included in "R7SJDHFG58473"

flagging a seven day rental. 3) Memberships can start or end a

password sequence with "M" plus (+) optionally the length of

months valid for example "M11DFJGH34KF" would flag aneleven–month membership period.” Id . at 8:57–9:8.

From claim 1 of the ’308 Patent, element b), the “verification token” is

something that is stored in a database and authenticated. All the examples quoted


20/58


U.S. Patent 8,887,308

- 16 -

above describe the token as something that identifies a user as opposed to a

particular machine, which is the basic thrust of the alleged invention. Accordingly,

Petitioner submits the broadest reasonable interpretation of a “verification token”

is any data that can be used to verify identity or rights to content, such as identity

of a user by verifying a user name or other identifying information, or an identifier

or other information indicating user rights to content.

D.

“authorization object”

This term is only found in the claim of this continuation, having been added

in the preliminary amendment without explanation. It does not occur in the

specification. The specification does use the term “authorization token” once in

the background without explanation. The claim itself describes the “authorization

object” in element (f) as something created by writing either the “received

verification data” or the “received query data” to the data store. The “query data”

is defined in element c) of the claim as the “verified web service account

identifier” (construed above). The claim also says the “authorization object” is

used by the “apparatus” as user access rights. Accordingly, using the above

“verification data” construction, Petitioner submits the broadest reasonable

interpretation of a “authorization object” is any data that includes at least one of

the verification data (as defined above) or an identifier for a “verified web


21/58


U.S. Patent 8,887,308

- 17 -

service” (as defined above), that indicates user access rights associated with the

digital content.

E.

“credential assigned to the apparatus of a)”

The ’308 Patent specification describes a credential as follows:

“The membership credentials are usually comprised of a login

element comprising a name, phrase, or e–mail address, and a

secret password.” ’308 Patent at 11:11–13.

“For example, to retrieve the FBID from Facebook to cross–

reference with the FBID stored in the digital media metadata

requires the enabler to possibly physically need to enter their

login and password credentials to the GUI connected to the

apparatus.” Id . at 12:63–67.

The context of the claim refers to the apparatus of element a), which is the

user device that will receive the digital content. The ’308 Patent describes using an

ID corresponding to a user, instead of an ID linked to a particular device, to

authorize content downloads for a device (apparatus). See, e.g., id . at 3: 1–8 &

5:8–13. The example ID is a Facebook ID (FBID). Id . at 12:58–62. In the claim,

the “credential” is used as permission to communicate with the verified web

service (e.g., a login and password). Thus, Petitioner submits the broadest

reasonable interpretation of “credential” is any information or data that permits


22/58


U.S. Patent 8,887,308

- 18 -

access to a service, such as a user name, phrase, e–mail address, certificate, other

login or password.

F.

“apparatus of (a)”

Element a) of claim 1 refers to a request is received “through an apparatus in

process with at least one CPU.” The term “apparatus” is used generically in many

instances in the claim. In other instances, reference is made to a “database

apparatus” and to “the apparatus in (a),” [referring to the element a) apparatus].

Later in the claim the “apparatus in (a) is described as having a credential assigned

to it (element c).

From the ’308 Patent description, the access request comes from the user

(“enabler,” see Fig. 4). The user device has the credentials assigned. Thus,

Petitioner submits the broadest reasonable interpretation of “apparatus of (a)” is the

user device.

G. “recognized”

In element a) of claim 1, there is reference to “the verification token is

recognized by the apparatus as a verification token.” Element b) refers to “a

database recognized by the apparatus of a) as a verification token database.”

Element c) recites “wherein the apparatus assigned credential is recognized as a

permission to conduct a data exchange session ….” Element f) recites “the

created computer readable authorization object is recognized by the apparatus of


23/58


U.S. Patent 8,887,308

- 19 -

(a) as user access rights ….” The term “recogniz” (with e, ed or ing endings) only

appears twice in the ‘308 patent, in unrelated uses. The background refers to

“…embedded copy protection schemes also recognized as an early form of DRM.”

’308 Patent at 1:67–2:1. The description refers to “and optionally to their

recognized friends and family.” Id . at 5:11–12. It is not referred to in the file

history.

Thus, the meaning must be determined from the context of the usage in the

claim itself. That context shows a usage indicating that a characteristic is assumed

or acted on, or simply that received or sent data or a database has a certain

characteristic. Thus, Petitioner submits the broadest reasonable interpretation of

“recognized” is identifying, assuming, acting upon, or acknowledging a

characteristic of data or a database.

VI.

PROPOSED REJECTIONS SHOWING THAT PETITIONER HAS A

REASONABLE LIKELIHOOD OF PREVAILING

The references addressed below anticipate and/or render obvious the claimed

subject matter, and are corroborated by the opinion in the Cherukuri Declaration

(EX1009).


24/58


U.S. Patent 8,887,308

- 20 -

A. Ground 1: Claim 1 is unpatentable as obvious over DeMell o

(EX1006) in view of the admitted prior art and Wieder (EX1008).

DeMello describes a system for delivery of electronic books or other media.

Id . at

4:41–49. A purchaser can link a book to a “persona” so that it can be read on

multiple user devices (readers) or shared with others associated with the same

persona. The user provides PASSPORT credentials (a user ID and a password –

PASSPORT is Microsoft’s single sign–on service). An activation server

authenticates the user using the PASSPORT credentials in communication with the

PASSPORT servers. The PASSPORT ID is associated with the purchaser’s

persona and written to an activation certificate. Id . at 13: 21–35.


25/58


U.S. Patent 8,887,308

- 21 -

As shown in Fig. 4 of DeMello above, the user requests content at a retail

site 71 on the left, and there is “user authentication,” as noted below box 72. As

described below, user authentication can be performed by establishing a

membership using authentication credentials (e.g., Amazon.com log–on

credentials), which is a verification token. A separate HTTPS connection 70 on

the right is used to establish a connection with an Activation Site 75, where a

user’s PASSPORT ID is used to verify the user and brand the metadata of the

content.

Preamble. DeMello discloses a DRM system which authorizes access to

digital content and contains the other limitations of the preamble, using the “cloud”

(defined in claim 25 of the parent ’860 Patent as the Internet). An “access request”

is the user using the browser to try to buy a book or other content. The

“authorization object” as construed above can be the “verified web service account

identifier,” shown to be the PASSPORT ID in DeMello in element (c) below. The

construction of the authorization object is described in element (f) below. The

claim chart below shows the specific quotations for these limitations.

Since the servers in the instances of DeMello are accessed over the Internet,

the “cloud” digital content limitation is met. As described above, “cloud” is a

synonym for “Internet” and the servers in DeMello are accessed over the Internet,


26/58


U.S. Patent 8,887,308

- 22 -

thus the cloud digital content element is shown. See also Cherukuri Decl.

(EX1009) at Ex. C.

’308 Patent (emphasis

added)

Prior Art (emphasis added)

1. A process for

transforming a user

access request for cloud

digital content into a

computer readable

authorization object, the

process for transforming

comprising:

DeMello (EX1006)

“A server architecture for a digital rights

management system that distributes and protects

rights in content.” DeMello at Abstract, ll. 1–2.

Content is cloud content being accessed over the

Internet: “…communications over the wide area

network 52, such as the Internet.” Id . at 8:24–25.

[Internet=cloud]

An access request is through a browser: “Using a

browser or the "bookstore pages" or reader 90 or 92,

user chooses book(s) via mechanisms that the retail site

implements (step 200).” Id. at 26:1–3.

A user and associated device(s) accesses the serverarchitecture (i.e., a cloud system) using the Internet to

acquire cloud digital content. Id. at Abstract, 25:66–

26:15, 26:1–3, 9:6–14.

A computer readable authorization object. See

analysis below for element (f). Id. at 7:14–20, 6:11–

16, 9:33–39 and 13:31–39.

(a) This element requires an access request (which eventually results in a

metadata read/write to a “data store,” or metadata, as further described in element

(f) of claim 1) along with a verification data (token) from an apparatus (a user

device). This element also recites a CPU and memory.


27/58


U.S. Patent 8,887,308

- 23 -

The described data store (e.g., metadata) is where the verification data

(token) is written. This is described as a write to meta–data in the claims of the

parent ’555 and ’860 Patents, more generically referred to as a write request to a

“data store” in claim 1 of the ’308 Patent. DeMello describes writing to metadata,

a registry, or a user’s device as indicated in element (f) below.

Patent Owner admits the element corresponding to this element in the parent

’860 Patent, and the following element corresponding to (b) are shown in the prior

art:

“…communicating access rights over the Internet to a

license server–the first and second steps of method claim

1 in the ‘860 patent–was well known in the digital rights

management field.” Preliminary Response, IPR2015–

00422, p. 14 (EX1005). See also p. 6, lines 6–7:“Clearly, many prior art systems taught the verification

of a token through a GUI interface.”

Patent Owner filed a terminal disclaimer to obviate an obviousness–type

double patenting rejection over the ’555 and ’860 Patents. Thus, Patent Owner has

acquiesced in this claim being obvious over the corresponding claim in the ’555

and ’860 Patents, and thus the differences in the first two elements admitted to be

in the prior art for the ’860 Patent are obvious. These differences are clearly

obvious, consisting mainly of reciting a CPU and the data store being a memory,


28/58


U.S. Patent 8,887,308

- 24 -

storage or database. These elements are also shown in the prior art as set forth in

the claim chart below.

Claim 1 of the parent ’555 Patent describes verification data (verification

token) as a membership verification token [this was alleged vs. the Amazon Kindle

logon, for example]. The ’860 Patent describes a list of possible verification

tokens including a password and an email address, which can correspond to a

membership, but also a credit card, a rights token, etc. This claim of the ’308

Patent simply recites a verification token, without limiting what it can be.

DeMello teaches “user authentication” and establishing a membership

relationship with a retailer (left of Fig. 4), which inherently would include

providing a token, such as a retailer password and/or email (e.g., Amazon log–on

credentials). User authentication and establishing a membership are obvious in

view of the admitted prior art. The admitted prior art steps are described in the

parent ‘555 Patent as verifying membership for site to buy content, and DeMello

recites establishing such a membership relationship. It would be obvious to use the

verification token of the admitted prior art to establish a membership relationship.

The communication with the Bookstore server includes the name of the

purchaser, credit card data, billing data, or other user data that is used to

authenticate the user, together or each separately constitute verification data


29/58


U.S. Patent 8,887,308

- 25 -

provided by a user, wherein the verification data is recognized by the apparatus as

a verification token. Id . at 16:16–38, 40:23–29. See Cherukuri Decl. (EX1009) at

¶ 74.

Other embodiments. DeMello describes a variety of DRM options, such as

individualized or fully individualized, and obtaining content before or after

activation (PASSBOOK verification). These DRM options contain various other

verifications or authentications that also meet various ones of the list of

verification token options described in the ’860 Patent claims and included in the

claim construction above of “verification token.” The list of options for the

verification and authentications could read on, for example, the fulfilment site 73

of Fig. 4 and other variations set forth in the Cherukuri Decl. (EX1009) at ¶¶ 69-83

such as the BookID, which is verified and written as metadata of content, similar to

the content code entered in the KODEKEY GUI of Fig. 3 of the ’308 Patent. As

described above in the Summary of the ’308 Patent, the ’308 Patent specifies that

other orders of steps are intended to be covered, and thus various combinations of

embodiments meet the claim. For example, activation (obtaining PASSPORT ID)

could be done, and is described as being done, before or after buying the content.


30/58


U.S. Patent 8,887,308

- 26 -

a) receiving an

access request for

cloud digital

content through anapparatus in

process with at

least one CPU, the

access request

being a write

request to a data

store, wherein the

data store is at

least one of:

a memoryconnected to the at

least one CPU;

a storage

connected to the at

least one CPU;

and

a database

connected to the at

least one CPUthrough the

Internet; wherein

the access request

further comprises

verification data

provided by at

least one user,

wherein the

verification data is

recognized by theapparatus as a

verification token;

then

The corresponding element in the ’860 Patent is admitted

prior art.

DeMello (EX1006) –Retail site (Fig. 4)

“Using a browser or the "bookstore pages" or reader 90 or

92, user chooses book(s) via mechanisms that the retail site

implements (step 200). The user then pays for the titles, if

payment is required (step 202).” Id. at 26:1–4.

The user’s devices (i.e., apparatus) include hardware and

software that facilitates communication with the server

architecture of a DRM system. Id. at 8:5–34, 22:43–52.

The user’s devices and server architecture of a DRM system

includes at least one CPU, memory and storage connected to

the CPU. Id. at 7:14–8:34. The server architecture of the

DRM system also includes database(s), which constitutes a

data store. Id. at 10:7–8, 10:23–25, 28:29–32.

The claimed “access request” is met by communication with

a server of the DRM system, specifically a Bookstore server:

“Bookstore servers 72 may communicate with users via web browsing software (e.g., by providing web pages for viewing

with a MICROSOFT INTERNET EXPLORER browser or a

NETSCAPE NAVIGATOR browser). Through this

communication [access request], bookstore servers 72 may

allow users to shop for eBook titles, establish their

membership relationship with the retailer [verification

token], pay for their transactions, and access proof–of

purchase pages (serve–side receipts).” Id . at 9:9–16.


31/58


U.S. Patent 8,887,308

- 27 -

(b) The corresponding element in the ’860 Patent was also admitted by

Patent Owner to be in the prior art. The difference from the ’860 Patent is clearly

obvious, the authentication involving a recognized verification token database.

DeMello shows authenticating the username and other credentials (verification

token) of this element as described in the chart below, and also in a variety of

embodiments. Since various options for the authentication token are shown in

DeMello, various options for authentication of the token are also shown. The

authentication can be of the credit card or membership information by the retail

site (e.g., Amazon log–on). For devices already activated, there can be

authentication of the PASSPORT ID or other information as described in more

detail in Cherukuri Decl. (EX1009) at ¶¶ 72-75. Also, the Book ID can be the

verification token. These all correspond to the admitted prior art.

Wieder (EX1008) describes a “usage–rights repository” 24 (Wieder Fig. 1)

for storing “usage–rights tokens” (a token database) used for validation of user

ownership by different “experience providers” that allow custom playlists (e.g.,

Apple iTunes, Microsoft Windows Media). Wieder , 4:46–5:39; 8:24–28; 15:1–4.

The database stores the tokens which include “Token–Owner,” “Usage–Rights,”

and “Purchase–Record.” Id . at Fig. 13, 7:30–31. It is inherent in DeMello that the

credit card data are authenticated using a database of membership records of


32/58


U.S. Patent 8,887,308

- 28 -

customers of an online book store. It is obvious to combine DeMello with Wieder ,

which shows authenticating a “Purchase–Record” (verification token).

Because Wieder and DeMello both relate to Digital Rights Management, and

both relate to supporting multiple users or user devices, it would be obvious to

combine Wieder with DeMello to implement a database of user personas associated

with multiple user readers. Also, DeMello specifically refers to “credit card

validation” and “requiring the users to authenticate themselves,” thus referencing

the many standard ways of doing this, of which Wieder is just one example.

Because DeMello describes linking content to a PASSPORT ID instead of a device

ID, it would be obvious to add the PASSPORT ID to the token contents shown in

Fig. 13 of Wieder , thus providing a database of PASSPORT IDs. Additionally, it

would be obvious to include in the record of the database other information, such

as the username and other credentials identified in DeMello. The Wieder database

is also described as including other information, and it would be obvious to include

the other data of DeMello, and it would be obvious to do this in a single database

or multiple databases. Wieder thus shows more details of actions specifically

described in DeMello. See Cherukuri Decl. (EX1009) at ¶¶ 84-93.


33/58


U.S. Patent 8,887,308

- 29 -

b) authenticating

the verification

token of (a) using

a databaserecognized by the

apparatus of (a) as

a verification

token database;

then

The corresponding element in the ’860 Patent is admitted

prior art.

DeMello (EX1006) – Retail site authentication:

“After the buying customer has selected the titles he/she

wishes to purchase and decides to complete an order, the

merchant will process the order according to their existing

methods (e.g., credit card validation, billing, etc.). This

may include requiring the users to authenticate themselves

(for those which require a membership record from their

customers) …” DeMello at 40:23–29.

Wieder (EX1008):“There may also be one or more usage-rights repositories

(usage-rights authorities) 24 [token database]. The usage-

right repository utilizes a common "standard for usage-rights

tokens" 25 so that a user's collection of compositions,

represented by the set of usage-rights tokens a user acquires,

may be recognized and usable with all experience-providers.

Each usage-rights token may be defined to limit use to only

a specific individual user or a group of specific users (e.g., a

family).” Wieder at 8:37–47.

“A secure database of all issued tokens may be maintained

in the usage-rights repository.” Id . at 14:11–12.

“Usage-Rights Representations:

In one embodiment, the token may represent a receipt of

ownership or allowable usage that may be understood and

validated by any experience-provider 26.” Id . at 15:1–4.

Token applicable to multiple devices:

“In one preferred embodiment, the token may be defined to

be valid for all available (network interface-able) user-

devices and their corresponding formats. This is a major

convenience for user's since they no longer need to be


34/58


U.S. Patent 8,887,308

- 30 -

concerned with the details of user-device formats, format

translations and compatibility problems. The user is

guaranteed that their token will be good for use with all their

user-devices.” Id . at 15:13–19.

(c) This element relates to obtaining a “verified web service account

identifier” using standard API communications. DeMello discloses the “apparatus

of (a)” of this element as a reader, which uses an API of a verified web service (the

PASSPORT server). The claim recites that “the verified web service is a part of

the database apparatus.” The PASSPORT server of the PASSPORT membership

system and its associated database storing PASSPORT credentials is thus the

“database apparatus” of this element.

Element (c) further relates to is establishing communication between “the

apparatus of (a)” and the database apparatus using an API related to a verified web

service (e.g., Facebook). Patent Owner admitted that such APIs for verified web

services are known in the prior art:

“The web service equipped with the API is usually a

well–known membership themed application in which

the users must use an authentic identification. Some

example includes Facebook in which as a rule, members

are required to use their legal name identities. A

reference number or name with the Facebook Platform

API represents this information. Other verified web


35/58


U.S. Patent 8,887,308

- 31 -

services in which real member names are required such

as the LinkedIn API and the PayPal API and even others

could be used ….” ’308 Patent, 10:41–51

In DeMello, a user is prompted at the reader (“the apparatus of (a)”) to login

using PASSPORT credentials to authenticate the user at the PASSPORT server (a

verified web service). The reader then sends the login credentials to the

PASSPORT server via the API of the PASSPORT server to authenticate the user at

the PASSPORT server. Id. at 9:6–14; 23:6–10, 23:19–23. It is obvious that the

reader in DeMello would formulate its request according to the protocol specified

by the API related to the verified web service (the PASSPORT server). The

PASSPORT server meets the claim construction definition of a verified web

service that authenticates the identity of a user. Id. at 13:31–35, 13:54–61.

DeMello discloses that the API communication between the reader and the

PASSPORT server requires a credential assigned to the reader. In DeMello, the

reader prompts a user to provide login credentials (e.g., PASSPORT™ credentials)

to connect to the PASSPORT server via the API of the PASSPORT server to

authenticate the user at the PASSPORT server. Thus, the claimed “credential” is

shown by the PASSPORT credentials of DeMello, which correspond to the

Facebook credentials example in the ’308 Patent.


36/58


U.S. Patent 8,887,308

- 32 -

The credential assigned to the reader enables the reader and the PASSPORT

server to conduct a data exchange session to complete a verification process. Id . at

23:6–10, 23:19–23; 24:33–35. The data exchange session is shown by the

exchange of the user name and password for the activation certificate, which

contains the PASSPORT ID. Thus, the PASSPORT ID in the data exchange

includes “query data” which “comprises at least one verified web service account

identifier.”

The data exchange session is both explicitly described and is inherent, since

the activation certificate would not be communicated unless it was requested or

understood to be requested. See Cherukuri Decl. (EX1009) at ¶¶ 72, 75. Note that

this element simply says that “the data exchange session is also capable of an

exchange of query data” (Emphasis added). The actual exchange of the query data

described in this element is set forth in elements (d) and (e) discussed below.

c) establishing an API

communication between the apparatus

of (a) and a database

apparatus, the database

apparatus being adifferent database from

the verification token

database of (b) wherein

the API is related to a

verified web service,

wherein the verified

DeMello (EX1006)

Establishing an API communication between the reader

and the PASSPORT server: “At step 150, the reader

client opens into the integrated bookstore feature and

connects, via secure sockets layer (SSL), to theactivation servers 94, where users are prompted to login

using, in this example, their PASSPORT™ credentials

(step 152).” Id. at 23:5–17 “Activation Server 94

includes a PASSPORT object 96 and an activation

server ISAPI Extension DLL 98. The PASSPORT

object 96 provides the required interfaces into the


37/58


U.S. Patent 8,887,308

- 33 -

web service is a part of

the database apparatus,

wherein establishing the

API communicationrequires a credential

assigned to the

apparatus of (a),

wherein the apparatus

assigned credential is

recognized as a

permission to conduct a

data exchange session

between the apparatus

of (a) and the databaseapparatus to complete

the verification process,

wherein the data

exchange session is also

capable of an exchange

of query data, wherein

the query data

comprises at least one

verified web serviceaccount identifier; then

PASSPORT.TM. servers that authenticate the end–

users using, for example, their hotmail accounts (or

other PASSPORT credentials).” Id. at 13:30–35.

The API is related to a verified web service

[PASSPORT], which is capable of facilitating a data

exchange session to complete a verification process

[authentication of PASSPORT credentials], wherein the

data exchange session is capable of an exchange for

query data (e.g., PASSPORT ID):

“At step 150, the reader client opens into the

integrated bookstore feature and connects, via secure

sockets layer (SSL), to the activation servers 94, whereusers are prompted to login [requesting] using, in this

example, their PASSPORT.TM. credentials (step

152). …Once user's PASSPORT.TM. credentials are

authenticated (step 156), a PASSPORT.TM. API is

queried for the user alias and e–mail address (step

158). Id. at 23:18–21. “The secure repository

executable and activation certificate are then

downloaded to the client (steps 188 and 190 ).” Id. at

24:33–35. [the “upload” and “download” shows thedata exchange session]

“PASSPORT ID-The persona ID associated with the

user, which is provided by the user during

activation.…” Id. at 15:65–16:51.


38/58


U.S. Patent 8,887,308

- 34 -

(d) This element describes the request of “query data” that includes the

“verified web service identifier” already described as the “verified web service

account identifier” in element (c). DeMello, for example, shows the “query data,”

defined as the “verified web service identifier” in this element, is requested from

the reader by a request for login credentials (e.g., PASSPORT™ credentials) and

the PASSPORT ID. The request for the query data (“query data request”) is a

request for the PASSPORT ID or the other IDs described above.

d) requesting the

query data, from

the apparatus of

(a), from the API

communication

data exchange

session of (c),

wherein the

query data

request is a

request for the at

least one verified

web service

identifier;

then

DeMello (EX1006) The request for the verified web service identifier by the reader,

from the API communication data exchange session is shown

by the request for the PASSPORT ID and login credentials

(e.g., PASSPORT™ credentials):

“At step 150, the reader client opens into the integrated

bookstore feature and connects, via secure sockets layer (SSL),

to the activation servers 94, where users are prompted to login

[requesting] using, in this example, their PASSPORT.TM.

credentials (step 152).” Id . at 23:6–10.

“PASSPORT ID-The persona ID associated with the user,

which is provided by the user during activation.

…” Id. at 15:65–16:51.

(e) This element describes the actual receipt of “query data” that includes the

“verified web service identifier” already described as the “verified web service

account identifier” in element (c). The “query data” (verified web service

identifier) – the PASSPORT ID or the hardware ID – is received from the reader


39/58


U.S. Patent 8,887,308

- 35 -

in DeMello, showing this element. This element is part of element (d), since a

requested element is clearly received. Receiving an identification reference is also

shown in the quoted sections below.

e) receiving the

query data

requested in (d)

from the API

communication

data exchange

session of (c);and

DeMello (EX1006)

“At step 150, the reader client … connects, via secure sockets

layer (SSL), to the activation servers 94, where users are

prompted to login [requesting] using, in this example, their

PASSPORT.TM. credentials (step 152).” Id . at 23:6–10.

“PASSPORT ID-The persona ID associated with the user,

which is provided by the user during activation.

…” Id. at 15:65–16:51.

(f) This element requires that an “authorization object” be written to a data

store (e.g., metadata). As defined above, and as can be seen from the claim, the

“authorization object” is described in this element as being one of two things – the

“verification data” (verification token) or the “verified web service identifier” (e.g.,

the PASSPORT ID) Thus, the “authorization object” is shown in DeMello in

multiple ways, by any of the types of user data or the PASSPORT ID.

Patent Owner admits this was shown in the prior art for the verification

token in the corresponding element of the parent ’860 Patent:

This disclosure corresponds to, for example, the first,

second, and sixth steps of claim 1 of the ‘860 patent as

illustrated in Figure 3 at 301, 303, and 305 (i.e., receiving


40/58


U.S. Patent 8,887,308

- 36 -

a write request and authentication) and 302 (i.e., writing

the verification token into the metadata). Wimmer

stops there, however, and critically lacks the third, fourth,and fifth steps of claim 1 of the ‘860 patent ….

Sony v. Grecia Preliminary Response (EX1005) at p. 13, emphasis added. See also

Cherukuri Decl. (EX1009) at ¶¶ 22-27, 82.

DeMello discloses this element in several ways. In one example, the

PASSPORT ID (the verified web service identifier) is part of the activation

certificate, as described above, and the public key of the user's activation certificate

is cryptographic hashed with meta–data. The PASSPORT ID is written into

(“stores” into) a registry ( Id . at 16:48–49), which constitutes metadata because it is

associated with the content. See Cherukuri Decl. (EX1009) at ¶¶ 72, 76. In

another example, when a reader is not yet activated, a purchase request results in

the fulfillment server directing the purchase to the activation server to activate the

user’s reader. Id. at 41:63–42:2. The activation server requests and authenticates

the user’s PASSPORT login and password, which are the verification token in this

instance. See id . at 13:30–35. For “fully individualized” security, the PASSPORT

ID is later written to an “encrypted blob” (a data store) associated with the digital

content, along with the book title and other information.


41/58


U.S. Patent 8,887,308

- 37 -

This element further requires a “cross–referencing” of the authorization

object during subsequent user access attempts to verify permission. DeMello

checks a DRM license, with the activation certificate, on subsequent accesses. Id .

at 11:49–55. As noted, the activation certificate contains both user data and the

PASSPORT ID.

In other embodiments, the hardware ID is written to metadata and the

purchaser credit card and name (a verification token) are written into the eBook

title metadata. Id . at 5:45–48. See Cherukuri Decl. (EX1009) at ¶¶ 72, 78, 81.

Although DeMello completely shows this element as described above, it is

also obvious to write the data to a data store based on the Patent Owner’s

admissions. The Patent Owner admits that prior–art systems exist that embed

credit card information and other personal data information inside the metadata

area of a delivered file. Accordingly, for this reason, and because both the ’308

Patent and DeMello relate to Digital Rights Management and to use of a verified

web service to authenticate a user membership and to enable use of multiple

devices, as described above, it would be obvious to combine DeMello with the

prior art admitted by the Patent Owner. See Cherukuri Decl. (EX1009) at ¶ 93 and

Ex. C, element (c).


42/58


U.S. Patent 8,887,308

- 38 -

f) creating a

computer

readable

authorizationobject by writing

into the data store

of (a) at least one

of:

the received

verification data

of (a); and

the receivedquery data of (e);

wherein

the created

computer

readable

authorization

object is

recognized by theapparatus of (a)

as user access

rights associated

to the cloud

digital content,

wherein the

computer

readable

authorization

object is processed by the

apparatus of (a)

using a cross–

referencing action

during subsequent

DeMello (EX1006)

The authorization object (PASSPORT ID or user name) is

written (sealed, stored, downloaded) to a data store (meta– data, registry or reader):

PASSPORT ID as a verification token written to metadata:

“…stores the PASSPORT ID in the registry [metadata] on

the user's computing device, …” Id . at 16:48–49.

“the PASSPORT ID is contained in the activation

certificate , …” Id . at 15:65–16:51. “the key is a symmetric

key 14A that is sealed with a cryptographic hash of meta–

data 12 or, in the case of level 5 titles, with the public key of

the user's activation certificate.” Id . at 6:42–45.

Purchaser name or billing information as a verification token

written to metadata:

“An "individually sealed" title is an eBook whose meta–data

includes information related to the legitimate purchaser (e.g.,

the user's name or credit card number, the transaction ID

…..” Id . at 5:45–48.

Cross–referencing during subsequent accesses is shown by:“The download request URL must provide, as part of the

encrypted parameters, information such that the license

module can individually seal each license. These parameters

include, for level 5 copies, the encrypted activation

certificate downloaded to the end–user during activation of

their reader software. A licensed eBook cannot be opened

unless the required license is present and available to the

reader.” Id. at 22:34 –42.

“Preferably, the key pair in the activation certificate is persistently associated with an authenticatable “persona,”

such that a device can be “activated” to read content that

has been individualized for that persona, but not content that

has been “fully individualized” for other personas.” Id. at

2:41–45.


43/58


44/58


U.S. Patent 8,887,308

- 40 -

’308 Patent

(emphasis added)

Pestoni (EX1007) (emphasis added)

1. A process for

transforming a useraccess request for

cloud digital content

into a computer

readable

authorization object,

the process for

transforming

comprising:

Pestoni (EX1007)

“In accordance with the domain management for digitalmedia, a device accesses a domain administrator . . . to

obtain a domain membership license . . . [that] indicates . . .

the device is part of a domain . . .. The device also obtains

multiple pieces of protected content . . .. The device also

accesses a license server to obtain, for . . . [the] protected

content, a content license that is bound to the domain. The

content license permits the device to play back the piece of

content to the user.” Pestoni at Abstract.

(a) As noted, Patent Owner has admitted as prior art the corresponding

element in the parent ’860 Patent. Preliminary Response, IPR2015–00422, pp. 6

and 14 (EX1005). This element is similar, and requires receiving an access request

(which eventually results in a metadata read/write), along with a verification token,

through an apparatus in process with a CPU (the user device). In Pestoni, “an

access request for cloud digital content [is received] through an apparatus in

process with at least one CPU” when content playback module 214 [apparatus] of

device 202 [CPU], concurrently submits content and join–domain requests 240,

220 [access request], where the join–domain request 240 includes user credentials,

such as a user id and password. Id. at [0038], [0039], [0041], [0067].


45/58


U.S. Patent 8,887,308

- 41 -

a) receiving an

access request

for cloud

digital contentthrough an

apparatus in

process with at

least one CPU,

the access

request being

a write request

to a data store,

wherein the

data store is atleast one of: a

memory

connected to

the at least one

CPU; a

storage

connected to

the at least one

CPU; and adatabase

connected to

the at least one

CPU through

the Internet;

wherein the

access request

further

comprises

verificationdata provided

by at least one

user, wherein

the

verification

The corresponding element in the ’860 Patent is

admitted prior art.

receiving an access request . . . Pestoni discloses concurrently submitting content and join–

domain requests 240, 220:

“[0038] ….To join a domain, device 202 issues a join-

domain request 220 to domain administrator 102.”

“[0067] Device 202 communicates with content provider

104 to obtain pieces of protected content. Protected content

can be obtained by device 202 before it joins a domain, after

it joins a domain, or concurrently with joining a domain.

The protected content is bound to a particular domain via itscontent license, as discussed in more detail below. Device

202 [apparatus with CPU] submits a content request 240 to

content provider 104, requesting one or more pieces of

protected content.”

“When the user desires to play back a new piece of

protected content on device A, device A obtains the domain

membership license if it has not already done so, [and]

obtains the protected content . . ..” Id. at [0101].

“The process implemented by device 202 in joining a

domain may be implemented by . . . content playback

module 214. Id. at [0038]. The “[p]rotected content can be

obtained . . . concurrently with joining a domain . . ..” Id. at

[0067]. In this case, device 202, through content playback

module 214, concurrently submits “a content request 240

to content provider 104” and “a join–domain request 220

to domain administrator 102” Id. at [0038], [0067].

“FIG. 6 illustrates an example computing device 600 that . .

. can be . . . device 202.” Id . at [0105]. “Computing device

600 includes one or more processors or processing units

602.” Id . at [0106].


46/58


U.S. Patent 8,887,308

- 42 -

data is

recognized by

the apparatus

as averification

token; then

the access request being a write request to a data store

connected to a CPU

In Pestoni, the access request constitutes a “write request”

to content license store 210, which is “connected to the atleast one CPU” of device 202:

“The content license is . . . sent to the device [CPU] . . .

[which] maintains the content license in its content license

store [210].” Id . at [0096]; also see, id. at [0034].

“FIG. 6 illustrates an example computing device 600 that . .

. can be . . . device 202.” Id . at [0105]. “Computing device

600 includes . . . one or more computer readable media 604

which can include one or more memory and/or storagecomponents 606.” Id . at [0106].

the access request comprises verification data . . .

In Pestoni, the request for domain membership license

includes a user id and password, which constitutes

“verification data” that is “recognized by the apparatus as a

verification token.” Id . at [0039], [0041].

“The join–domain request includes various parameters . . .[such as] a device certificate, user credentials, and

optionally a device description.” Id . at [0039].

“The user credentials can take any of a variety of different

forms, such as a user id and password, a digital certificate

attesting to the user’s identity and digitally signed by a trust

authority, and so forth.” Id . at [0041].

(b) As noted, the corresponding element in the ’860 Patent was admitted by

Patent Owner to be in the prior art. In Pestoni, for example, the user id/password

[verification token] included in the access request is authenticated using domain


47/58


U.S. Patent 8,887,308

- 43 -

administer 102, which compares against stored passwords. Pestoni at [0038],

[0041], [0045].

As described above in Ground 1, Wieder describes a “usage–rights

repository” 24 (Wieder Fig. 1) for storing “usage–rights tokens” (a token database)

used for validation of user ownership by different “experience providers” that

allow custom playlists (e.g., Apple iTunes, Microsoft Windows Media). Wieder ,

4:46–5:39; 8:24–28; 15:1–4. The database stores the tokens which include

“Token–Owner,” “Usage–Rights,” and “Purchase–Record.” Id . at Fig. 13, 7:30–31.

In Pestoni, “authenticating the verification token of (a) using a database

recognized by the apparatus of (a) as a verification token database” occurs when

the content playback module 214 [apparatus] sends the user id and password

[verification token] to domain administer 102, which verifies by comparing against

a stored password, as shown in the claim chart below. It is obvious to combine

Pestoni with the token database of Wieder , which shows authenticating a

“Purchase–Record” (verification token).

Because Wieder and Pestoni both relate to Digital Rights Management, and

both relate to supporting multiple users or user devices, it would be obvious to

combine Wieder with Pestoni to implement a database of user domains associated

with multiple user readers. The Wieder database is also described as including


48/58


U.S. Patent 8,887,308

- 44 -

other information, and it would be obvious to include the other data of Pestoni, and

it would be obvious to do this in a single database or multiple databases. Wieder

thus shows more details of actions specifically described in Pestoni. See

Cherukuri Decl. (EX1009) at ¶¶ 108-111.

b)

authenticating

the

verification

token of (a)using a

database

recognized by

the apparatus

of (a) as a

verification

token

database; then

The corresponding element in the ’860 Patent is admitted prior

art.

“The process implemented by device 202 in joining a domain may be implemented by . . . content playback module 214. . . [which] . .

. issues a join–domain request 220 to domain administrator 102.”

Pestoni at [0038].

“The join–domain request includes various parameters . . . [such

as] a device certificate, user credentials, and optionally a device

description. Id. at [0039]. “The user credentials can take any of a

variety of different forms, such as a user id and password, a

digital certificate attesting to the user’s identity and digitally

signed by a trust authority, and so forth.” Id . at [0041].

“The domain join request is received by the domain administrator

(act 404), which checks whether the user credentials are valid

(act 406). The domain administrator may optionally also check

whether the device certificate is valid.” Id . at [0090].

“Domain request approval module 224 [of domain administrator

102] obtains and verifies that the user credentials from request

220 are correct. This verification can take different forms, such ascomparing a password (or hash thereof) against a stored password

(or hash thereof), accessing a remote service (not shown) to verify

that the received password matches the received user id, . . . and so

forth.” Id. at [0045].


49/58


U.S. Patent 8,887,308

- 45 -

Wieder (EX1008):

“There may also be one or more usage-rights repositories (usage-

rights authorities) 24 [token database]. The usage-right repository

utilizes a common "standard for usage-rights tokens" 25 so that auser's collection of compositions, represented by the set of usage-

rights tokens a user acquires, may be recognized and usable with

all experience-providers. Each usage-rights token may be defined

to limit use to only a specific individual user or a group of specific

users (e.g., a family).” Wieder at 8:37–47.

“A secure database of all issued tokens may be maintained in the

usage-rights repository.” Id . at 14:11–12.

“Usage-Rights Representations:

In one embodiment, the token may represent a receipt of

ownership or allowable usage that may be understood and

validated by any experience-provider 26.” Id . at 15:1–4.

Token applicable to multiple devices:

“In one preferred embodiment, the token may be defined to be

valid for all available (network interface-able) user-devices and

their corresponding formats. This is a major convenience for user'ssince they no longer need to be concerned with the details of user-

device formats, format translations and compatibility problems.

The user is guaranteed that their token will be good for use with all

their user-devices.” Id . at 15:13–19.

Elements (c)–(e), as described under Ground 1 above, set forth using an API

to communicate with a verified web service to request (d) and receive (e) a

“verified web service account identifier.” As described above, the use of an API to

access a verified web service is admitted prior art. In addition, since both DeMello

and Pestoni were assigned to Microsoft, and both relate to very similar digital


50/58


51/58


U.S. Patent 8,887,308

- 47 -

being a

different

database from

the verificationtoken database

of (b) wherein

the API is

related to a

verified web

service,

wherein the

verified web

service is a

part of thedatabase

apparatus,

wherein

establishing

the API

communication

requires a

credential

assigned to theapparatus of

(a), wherein

the apparatus

assigned

credential is

recognized as a

permission to

conduct a data

exchange

session between the

apparatus of

(a) and the

database

apparatus to

the API is related to a verified web service of the database

apparatus . . .

Use of an API is inherent in computer–server communication(request) from user (communications console) and Grecia

admits APIs to communicate with verified web services were

known:

“A more detailed description of API that can be used for an

apparatus can be found in the book, "Professional Web APIs

with PHP: eBay, Google, Paypal, Amazon, FedEx plus Web

Feeds", by Paul Reinheimer, Wrox publishers (2006). ….The

web service equipped with the API is usually a well–known

membership themed application in which the users must use anauthentic identification. Some example includes Facebook in

which as a rule, members are required to use their legal name

identities. A reference number or name with the Facebook

Platform API represents this information. Other verified web

services in which real member names are required such as the

LinkedIn API and the PayPal API and even others could be

used, but for this discussion, Facebook will be used only as an

example of how the authentication element of the invention is

utilized.” Grecia at 10: 24–51.

wherein establishing the API communication requires a

credential assigned to the apparatus of a) . . .

In Pestoni, establishing communication with the license server

requires a digital certificate [credential] assigned to playback

module 214 of device 202 [apparatus]:

wherein establishing the communication requires a credential

“Trust authority 120 digitally signs and issues digital

certificates [credentials]. Trust authority 120 is an entity,typically a service implemented on one or more computing

devices, that is trusted by . . . license server 106.” Pestoni at

[0020].

“Digital certificates are well–known to those skilled in the art.


52/58


U.S. Patent 8,887,308

- 48 -

complete the

verification

process,

wherein thedata exchange

session is also

capable of an

exchange of

query data,

wherein the

query data

comprises at

least one

verified web

service

account

identifier; then

A digital certificate can be generated by a trust authority that

attests to the trustworthiness of a particular entity [playback

module 214 of device 202]. The digital certificate is digitally

signed by a trust authority using a private key of the trustauthority.” Id . at [0024]

“Device ID 302 is typically assigned by a trust authority, such as

a trust authority 120. Id. at [0050].

exchange of query data that comprises web service account

identifier . . .

In Pestoni, “query data comprising at least one verified web

service account identifier” occurs when playback module 214 of

device 202 sends to license server 106 a content license request252 [query data] comprising a domain ID [verified web service

account identifier]:

Playback module 214 of “[d]evice 202 sends a content license

request 252 to license server 106. Content license request 252

includes various parameters . . . [including] a domain ID

[verified web service account identifier].” Id. at [0072].

“The domain ID [verified web service account identifier] is anidentifier of domain 204 that device 202 is part of . . . [and] to

which the content license should be bound. As discussed above,

the domain ID is obtained by device 202 from domain

administrator 102 as part of domain member ship license 222.

Id. at [0073].

Elements (d) and (e) set forth requesting and receiving the verified web

service identifier from the data exchange session. In Pestoni, the content license

generator 260 of the license server 106 generates a content license. Id . at [0079].

Because the content license includes the domain ID, the content license generator

260 must necessarily request and receive the domain ID before generating the


53/58


U.S. Patent 8,887,308

- 49 -

content license. Id . at [0079]. Thus, Pestoni inherently discloses these elements

and it would be obvious to one of skill in the art to implement Pestoni with a

request and corresponding reception. See Cherukuri Decl. (EX1009) ¶¶ 97-102.

d) requesting the query data,

from the apparatus of (a),

from the API communication

data exchange session of (c),

wherein the query data

request is a request for the at

least one verified web service

identifier;

In Pestoni, “requesting the query data . . . from the

. . . data exchange session” inherently occurs when

“[c]ontent license generator 260 generates a

content license.” Id . at [0079].

Because the “content license includes . . . a

domain ID,” the content license generator 260

must necessarily request the domain ID beforegenerating the content license. Id . at [0079].

e) receiving the query data

requested in (d) from the API

communication data

exchange session of (c); and

Same as (d)

(f) Element (f) is shown.

Patent Owner admits this was shown in the prior art for the verification

token in the corresponding element of the parent ’860 Patent:

This disclosure corresponds to, for example, the first,

second, and sixth steps of claim 1 of the ‘860 patent as

illustrated in Figure 3 at 301, 303, and 305 (i.e., receiving

a write request and authentication) and 302 (i.e., writing

the verification token into the metadata). Wimmer

stops there, however, and critically lacks the third, fourth,

and fifth steps of claim 1 of the ‘860 patent ….


54/58


55/58


U.S. Patent 8,887,308

- 51 -

See Cherukuri Decl. (EX1009) at ¶¶ 98-102. Additionally, Pestoni refers to

the content metadata (par. 0071) as including a key ID which identifies the content,

which associates the content license, which contains the domain ID, as set forth in

the below claim chart.

Other embodiments. The “verification token” is also shown by user

credentials, such as a user id and password, a digital certificate and other

parameters in Pestoni, with the “query data” being shown by the Domain ID,

Domain Certificate or other parameters as set forth in Cherukuri Decl. (EX1009) at

¶¶ 97-100. Not only does the ’308 Patent say the order of steps can be different, as

noted above, but Pestoni says the same in paragraph [0097].

f) creating a

computer readable

authorization object

by writing into the

data

unified patents v. grecia, ipr2016-00602

Documents