unified patents v. grecia, ipr2016-00602
TRANSCRIPT
-
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
2/58
IPR2016–00602 Petition
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 -
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
3/58
IPR2016–00602 Petition
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 -
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
4/58
IPR2016–00602 Petition
U.S. Patent 8,887,308
iii
EXHIBIT LIST
Exhibit No. Description
1001 U.S. Patent No. 8,533,860 to Grecia.
1002 U.S. Patent No. 8,402,555 to Grecia.
1003 U.S. Patent No. 8,887,308 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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
5/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
6/58
IPR2016–00602 Petition
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
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
7/58
IPR2016–00602 Petition
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/20/2019 Unified Patents v. Grecia, IPR2016-00602
8/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
9/58
IPR2016–00602 Petition
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:
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
10/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
11/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
12/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
13/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
14/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
15/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
16/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
17/58
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
18/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
19/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
20/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
21/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
22/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
23/58
IPR2016–00602 Petition
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).
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
24/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
25/58
IPR2016–00602 Petition
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,
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
26/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
27/58
IPR2016–00602 Petition
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,
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
28/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
29/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
30/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
31/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
32/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
33/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
34/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
35/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
36/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
37/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
38/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
39/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
40/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
41/58
IPR2016–00602 Petition
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).
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
42/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
43/58
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
44/58
IPR2016–00602 Petition
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].
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
45/58
IPR2016–00602 Petition
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].
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
46/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
47/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
48/58
IPR2016–00602 Petition
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].
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
49/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
50/58
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
51/58
IPR2016–00602 Petition
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.
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
52/58
IPR2016–00602 Petition
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
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
53/58
IPR2016–00602 Petition
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 ….
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
54/58
-
8/20/2019 Unified Patents v. Grecia, IPR2016-00602
55/58
IPR2016–00602 Petition
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