Professional Documents
Culture Documents
IPR201600602 Petition
U.S. Patent 8,887,308
TABLE OF CONTENTS
I.
B.
Related Matters................................................................................. - 1 -
C.
Counsels ........................................................................................... - 2 -
D.
II.
III.
B.
IV.
V.
2.
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.
C.
IPR201600602 Petition
U.S. Patent 8,887,308
VI.
B.
C.
D.
E.
F.
G.
recognized ................................................................................... - 18 -
B.
VII. CONCLUSION......................................................................................... - 52 -
ii
IPR201600602 Petition
U.S. Patent 8,887,308
EXHIBIT LIST
Exhibit No.
Description
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
iii
IPR201600602 Petition
U.S. Patent 8,887,308
I.
MANDATORY NOTICES
A.
Real PartyinInterest
Related Matters
IPR201600602 Petition
U.S. Patent 8,887,308
A Petition for Inter Partes review was filed by Sony Network Entertainment
International LLC, IPR201500422, PTAB, December 14, 2014 and dismissed by
request of the parties.
C.
Counsels
Unified
consents
phaughey@kilpatricktownsend.com,
to
electronic
service
at
jonathan@unifiedpatents.com,
and
SKolassa@kilpatricktownsend.com.
II.
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.
IPR201600602 Petition
U.S. Patent 8,887,308
A.
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.
The 308 Patent issued from a patent application filed prior to enactment of
-3-
IPR201600602 Petition
U.S. Patent 8,887,308
IV.
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 11272012 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.
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
-4-
IPR201600602 Petition
U.S. Patent 8,887,308
unlimited interoperability between devices . (308 Patent at
3:1 3:5).
DRM schemes for ebooks 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:1923.
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.
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:
-5-
IPR201600602 Petition
U.S. Patent 8,887,308
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
-6-
IPR201600602 Petition
U.S. Patent 8,887,308
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
Intl v. Grecia, IPR2015-00422 at 34, 1718 (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
-7-
IPR201600602 Petition
U.S. Patent 8,887,308
relationship or order between such entities or actions.
308 Patent, 4:6165.
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-
IPR201600602 Petition
U.S. Patent 8,887,308
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:1317.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
Examiners 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 Examiners Amendment and
no rejection, and the reasons for allowance listed Baiya and Wimmer as the closest
prior art. Neither of them show a users 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
-9-
IPR201600602 Petition
U.S. Patent 8,887,308
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 users 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 Examiners amendment.
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.
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
- 10 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
IPR201600602 Petition
U.S. Patent 8,887,308
statement by Patent Owner and Amazon. See Grecia v. Amazon.com, No. 2:14-cv00530 (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.
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
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. (308 Patent at 10:4151, 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
- 12 -
IPR201600602 Petition
U.S. Patent 8,887,308
device. See Grecia v. Amazon.com Claim Construction (EX1004), Ex. C, p. 16.
The Patent Owner term of an authenticated credential does not appear in the 860
Patent and the identical specification of the continuation 308 Patent, and the
example is a Facebook login name and password to authenticate the user, not
authenticate the credential. Thus, the Amazon proposal is correct: the proper
construction is any web service that is used to authenticate the identity of a user or
a device, or, in other words, any web service which verifies an identity, such as
through a user name and password.
B.
verification data
This term is only used in the claim: verification data provided by at least
one user, wherein the verification data is recognized by the apparatus as a
verification token. Accordingly, it is describing data provided by a user which
functions as a verification token (construed below). Accordingly, it is being used
synonymously with verification token in the claim. Petitioner submits the
broadest reasonable interpretation of a verification data is a verification token or
any data that can function as a verification token.
C.
verification token
IPR201600602 Petition
U.S. Patent 8,887,308
the encrypted digital media. 308 Patent at 6: 3840. 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, email
address associated with an ecommerce payment system used
to make an authorization payment, or other redeemable
instruments of trade for access rights of digital media.
Examples of ecommerce 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:3456.
Per the kodekey quote above, another option is the serial number assigned to
the digital media. Id. at 6:3840. The intent is to allow verification of user of the
media, as opposed to verifying the media serial number. In another example in the
- 14 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
random
number,
so
further
example
would
be
- 15 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
- 16 -
IPR201600602 Petition
U.S. Patent 8,887,308
service (as defined above), that indicates user access rights associated with the
digital content.
E.
- 17 -
IPR201600602 Petition
U.S. Patent 8,887,308
access to a service, such as a user name, phrase, email address, certificate, other
login or password.
F.
apparatus of (a)
recognized
IPR201600602 Petition
U.S. Patent 8,887,308
(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:672:1. The description refers to and optionally to their
recognized friends and family. Id. at 5:1112. 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.
subject matter, and are corroborated by the opinion in the Cherukuri Declaration
(EX1009).
- 19 -
IPR201600602 Petition
U.S. Patent 8,887,308
A.
DeMello describes a system for delivery of electronic books or other media. Id. at
4:4149. 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 Microsofts single signon service).
An activation server
authenticates the user using the PASSPORT credentials in communication with the
PASSPORT servers. The PASSPORT ID is associated with the purchasers
persona
and
written
to
an
activation
- 20 -
certificate.
Id.
at
13:
2135.
IPR201600602 Petition
U.S. Patent 8,887,308
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
logon
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,
- 21 -
IPR201600602 Petition
U.S. Patent 8,887,308
thus the cloud digital content element is shown.
(EX1009) at Ex. C.
308 Patent (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:
IPR201600602 Petition
U.S. Patent 8,887,308
The described data store (e.g., metadata) is where the verification data
(token) is written. This is described as a write to metadata 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 users 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 serverthe first and second steps of method claim
1 in the 860 patentwas well known in the digital rights
management field.
00422, p. 14 (EX1005).
- 23 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
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 logon
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
- 24 -
IPR201600602 Petition
U.S. Patent 8,887,308
provided by a user, wherein the verification data is recognized by the apparatus as
a verification token. Id. at 16:1638, 40:2329. 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.
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.
- 25 -
IPR201600602 Petition
U.S. Patent 8,887,308
a) receiving an
access request for
cloud digital
content through 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 at
least one of:
a memory
connected to the at
least one CPU;
a storage
connected to the at
least one CPU;
and
a database
connected to the at
least one CPU
through the
Internet; wherein
the access request
further comprises
verification data
provided by at
least one user,
wherein the
verification data is
recognized by the
apparatus as a
verification token;
then
- 26 -
IPR201600602 Petition
U.S. Patent 8,887,308
(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 logon).
- 27 -
IPR201600602 Petition
U.S. Patent 8,887,308
customers of an online book store. It is obvious to combine DeMello with Wieder,
which shows authenticating a PurchaseRecord (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.
- 28 -
IPR201600602 Petition
U.S. Patent 8,887,308
b) authenticating
the verification
token of (a) using
a database
recognized by the
apparatus of (a) as
a verification
token database;
then
- 29 -
IPR201600602 Petition
U.S. Patent 8,887,308
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:1319.
(c)
- 30 -
IPR201600602 Petition
U.S. Patent 8,887,308
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:4151
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).
PASSPORT server via the API of the PASSPORT server to authenticate the user at
the PASSPORT server. Id. at 9:614; 23:610, 23:1923. 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:3135, 13:5461.
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.
- 31 -
IPR201600602 Petition
U.S. Patent 8,887,308
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:610, 23:1923; 24:3335.
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 a
different 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 the
activation servers 94, where users are prompted to login
using, in this example, their PASSPORT credentials
(step 152). Id. at 23:517 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
- 32 -
IPR201600602 Petition
U.S. Patent 8,887,308
web service is a part of
the database apparatus,
wherein establishing the
API communication
requires 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 database
apparatus 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 service
account identifier; then
- 33 -
IPR201600602 Petition
U.S. Patent 8,887,308
(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:610.
PASSPORT ID-The persona ID associated with the user,
which is provided by the user during activation.
Id. at 15:6516: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).
- 34 -
IPR201600602 Petition
U.S. Patent 8,887,308
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:610.
PASSPORT ID-The persona ID associated with the user,
which is provided by the user during activation.
Id. at 15:6516:51.
- 35 -
IPR201600602 Petition
U.S. Patent 8,887,308
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 metadata. The PASSPORT ID is written into
(stores into) a registry (Id. at 16:4849), 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
users reader. Id. at 41:6342:2. The activation server requests and authenticates
the users PASSPORT login and password, which are the verification token in this
instance. See id. at 13:3035. 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.
- 36 -
IPR201600602 Petition
U.S. Patent 8,887,308
This element further requires a crossreferencing 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:4955. 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:4548.
- 37 -
IPR201600602 Petition
U.S. Patent 8,887,308
f) creating a
computer
readable
authorization
object by writing
into the data store
of (a) at least one
of:
the received
verification data
of (a); and
the received
query data of (e);
wherein
the created
computer
readable
authorization
object is
recognized by the
apparatus 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:4849.
the PASSPORT ID is contained in the activation
certificate, Id. at 15:6516: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:4245.
Purchaser name or billing information as a verification token
written to metadata:
An "individually sealed" title is an eBook whose metadata
includes information related to the legitimate purchaser (e.g.,
the user's name or credit card number, the transaction ID
.. Id. at 5:4548.
Crossreferencing 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 enduser 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:4145.
- 38 -
IPR201600602 Petition
U.S. Patent 8,887,308
user access
requests to
determine one or
more of a user
access permission
for the cloud
digital content.
B.
Pestoni discloses a networked system where a user can obtain content from a
content provider. Pestoni at Abstract, [0002], [0012].
A separate domain
administrator authenticates the user, with a password, and provides the users
device with a domain membership license, which enables the users device to
obtain from a license server a content license that is bound to the users domain
membership ID and that permits the user device to access to the obtained content.
Id. Patent Owner admits that the corresponding elements to (a) and (b) of the
parent 860 Patent are in the prior art (as discussed above).
Preamble.
request for cloud digital content into a computer readable authorization object. Id.
at Abstract; FIGS. 45. Pestoni discloses a system of Internet-connected [cloud]
components for authorizing and facilitating digital-media access rights between
multiple user devices. Id. at [0013].
- 39 -
IPR201600602 Petition
U.S. Patent 8,887,308
308 Patent
(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:
(a) As noted, Patent Owner has admitted as prior art the corresponding
element in the parent 860 Patent. Preliminary Response, IPR201500422, 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 joindomain requests 240,
220 [access request], where the joindomain request 240 includes user credentials,
such as a user id and password. Id. at [0038], [0039], [0041], [0067].
- 40 -
IPR201600602 Petition
U.S. Patent 8,887,308
a) receiving an
access request
for cloud
digital content
through 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 at
least one of: a
memory
connected to
the at least one
CPU; a
storage
connected to
the at least one
CPU; and a
database
connected to
the at least one
CPU through
the Internet;
wherein the
access request
further
comprises
verification
data provided
by at least one
user, wherein
the
verification
- 41 -
IPR201600602 Petition
U.S. Patent 8,887,308
data is
recognized by
the apparatus
as a
verification
token; then
(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
- 42 -
IPR201600602 Petition
U.S. Patent 8,887,308
administer 102, which compares against stored passwords. Pestoni at [0038],
[0041], [0045].
As described above in Ground 1, Wieder describes a usagerights
repository 24 (Wieder Fig. 1) for storing usagerights 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:465:39; 8:2428; 15:14. The database stores the tokens which include
TokenOwner, UsageRights, and PurchaseRecord. Id. at Fig. 13, 7:3031.
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
PurchaseRecord (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
- 43 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
- 44 -
IPR201600602 Petition
U.S. Patent 8,887,308
Wieder (EX1008):
There may also be one or more usage-rights repositories (usagerights 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 usagerights 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:3747.
A secure database of all issued tokens may be maintained in the
usage-rights repository. Id. at 14:1112.
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:14.
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 concerned with the details of userdevice 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:1319.
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
- 45 -
IPR201600602 Petition
U.S. Patent 8,887,308
rights systems, the use of an API discussed in DeMello above is evidence of the
common practice of Microsoft programmers in implementing these systems. See
Cherukuri Decl. EX(1009) 44, 94, 105, 112.
Element (c) sets forth a data exchange session with a verified web service to
complete a verification process using a verified web service account identifier.
Pestoni describes completing the verification process by establishing a connection
with license server 106. To do so, the user device sends to the license server a
content license request 252 that includes a domain ID, which is verified web
service account identifier. Pestoni teaches that the license server 106 is a verified
web service because the license server 106 is accessible only with a domain ID,
which can only be obtained after domain administrator 102 authenticates the user
credential, such as the user id/password. Pestoni at [0038], [0041], [0045], [0072],
[0073]. This meets the verified web service claim construction above of any web
service that authenticates the identity of a user or a device.
c) establishing
an API
communication
between the
apparatus of
(a) and a
database
apparatus, the
database
apparatus
IPR201600602 Petition
U.S. Patent 8,887,308
being a
different
database from
the verification
token database
of (b) wherein
the API is
related to a
verified web
service,
wherein the
verified web
service is a
part of the
database
apparatus,
wherein
establishing
the API
communication
requires 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
database
apparatus to
- 47 -
IPR201600602 Petition
U.S. Patent 8,887,308
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
service
account
identifier; then
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
- 48 -
IPR201600602 Petition
U.S. Patent 8,887,308
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;
e) receiving the query data
requested in (d) from the API
communication data
exchange session of (c); and
- 49 -
IPR201600602 Petition
U.S. Patent 8,887,308
Sony v. Grecia Preliminary Response (EX1005) at p. 13, emphasis added. See also
Cherukuri Decl. (EX1009) at 22-27, 82.
Pestoni shows the verified web service as License Server 106, which
requests and receives Domain ID and domain certificate (id. par. 007274). A
content license is generated, and bound to the domain associated with the
Domain ID (id. par. 007982). The content license 254, bound to domain 204, is
returned to device 202, which stores the license in content license store 210. Once
device 202 has the content license, it is able to access the protected content (see id.
par. 0084)
The content license 254, bound to domain 204 and stored in content
license store 210 of device 202, obviously constitutes metadata, since this is data is
about the content stored in device content store 208 of the device 202.
In Pestoni, the computer readable authorization object [content license] is
processed . . . using a crossreferencing action when DRM module 206 [or play
back module] of device 202 processes the authorization object [content license] to
enforce usage rights [user access permission] for the protected content. Id. at
[0080]. Example usage rights include restrictions on how many times or the
amount of time content can be accessed before a new content license needs to be
obtained. Id. at [0080]
- 50 -
IPR201600602 Petition
U.S. Patent 8,887,308
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 store of (a) at
least one of: the
received
verification data of
(a); and the
received query data
of (e); wherein the
created computer
readable
authorization object
is recognized by
the apparatus of (a)
as user access
rights associated to
IPR201600602 Petition
U.S. Patent 8,887,308
the cloud digital
content, wherein
the computer
readable
authorization object
is processed by the
apparatus of (a)
using a cross
referencing action
during subsequent
user access
requests to
determine one or
more of a user
access permission
for the cloud digital
content.
VII. CONCLUSION
The Office is requested to find there is a reasonable likelihood that
Petitioners will prevail and initiate an inter partes review of Claim 1. The USPTO
is authorized to charge any fees or credit any overpayments to Deposit Account
No. 201430.
Respectfully submitted,
- 52 -
IPR201600602 Petition
U.S. Patent 8,887,308
Lead Counsel
Paul C. Haughey
Registration No. 31,836
phaughey@kilpatricktownsend.com
BackUp Counsel
Jonathan Stroud
Reg. No. 72,518
jonathan@unifiedpatents.com
- 53 -
IPR201600602 Petition
U.S. Patent 8,887,308
CERTIFICATE OF SERVICE
The undersigned hereby certifies that a copy of this Petition for Inter Partes
Review of U.S. Patent No. 8,887,308, including its supporting Exhibits (1001
1010) and Powers of Attorney has been served via Express Mail on March 3, 2016,
upon the following:
The STR3EM Team
2885 Sanford Ave SW #13208
Grandville, MI 49418
Patent Owners correspondence address
of record for U.S. Patent No. 8,887,308
With a courtesy copy served on March 3, 2016 upon Grecias lead litigation
counsel via Express Mail.
Matthew M. Wawrzyn
Wawrzyn LLC
233 S. Wacker Dr., 84th Floor
Chicago, IL 60606
matt@wawrzynlaw.com
Respectfully
Dated: March 3, 2016
By:
/Paul C. Haughey/
Paul C. Haughey
Registration No. 31,836
Counsel for Petitioners
68257193V.1
- 54 -