`OFFICE
`
`
`_________________
`_________________
`
`
`
`Before the Patent Trial and Appeal Board
`
`
`
`
`
`Unified Patents Inc., Petitioner,
`
`
`v.
`
`William Grecia, Patent Owner.
`
`
`_________________
`
`
`U.S. Patent No. 8,402,555
`Filing Date: February 15, 2012
`Issue Date: March 19, 2013
`Title: Personalized Digital Media Access System (PDMAS)
`
`
`__________________
`
`
`
`
`
`
`
`Preliminary Response by Patent Owner William Grecia
`
`
`
`
`EWS-005511
`
`Early Warning Services 1035
`IPR of U.S. Pat. No. 8,887,308
`
`
`
`Table of Contents
`
`INTRODUCTION ................................................................................................................................. 1
`BACKGROUND .................................................................................................................................... 3
`THE ‘555 PATENT ...................................................................................................................................................... 3
`DEMELLO ................................................................................................................................................................. 12
`PESTONI .................................................................................................................................................................... 17
`ARGUMENT ........................................................................................................................................ 19
`THE MANNER CLAIMED IN THE ‘555 PATENT. ............................................................................................... 19
`
`I. UPI CANNOT PREVAIL WITH DEMELLO OR PESTONI AS ANTICIPATING REFERENCES BECAUSE
`
`NEITHER REFERENCE TEACHES ESTABLISHING A CONNECTION WITH A VERIFIED WEB SERVICE IN
`
`A. UPI’s arguments are based on a misrepresentation of the claimed function of the
`
`“verified web service.” ...................................................................................................................................... 19
`
`B. DeMello and Pestoni would not invalidate even accepting UPI’s description of the
`
`‘555 patent. ........................................................................................................................................................... 21
`
`1. DeMello lacks an apparatus that connects with a verified web service to
`complete a verification process ........................................................................................................ 21
`2. Pestoni lacks a verified web service. ....................................................................................... 24
`CONNECTION WITH A VERIFIED WEB SERVICE AS CLAIMED IN THE ‘555 INVENTION. ......................... 25
`CONCLUSION .................................................................................................................................... 26
`
`
`
`II. UPI IS UNLIKELY TO PREVAIL ON THE ASSERTED OBVIOUSNESS GROUNDS BECAUSE NONE OF
`
`THE PROFFERED COMBINATIONS CURE THE FAILURE OF THE PRIOR ART TO ESTABLISH A
`
`i
`
`EWS-005512
`
`Early Warning Services 1035
`IPR of U.S. Pat. No. 8,887,308
`
`
`
`Exhibit List
`
`Exhibit No.
`
`
`Description
`
`2001
`2002
`2003
`2004
`
`
`
`
`
`
`
`
`
`
`2013-02-04 Notice of Allowability (PTOL-37)
`U.S. Pub. No. 2011/0288946 to Baiya et al.
`U.S. 7,526,650 to Wimmer
`IDS and Article (6 of 15) dated Feb. 24, 2012.
`
`ii
`
`EWS-005513
`
`
`
`INTRODUCTION
`
` William Grecia is the owner and inventor of U.S. Patent No.
`
`8,402,555 (hereinafter, the “‘555 patent”). The Examiner allowed the
`
`‘555 patent claims over two references that, while teaching some steps of
`
`the ‘555 claims, did not establish a connection between the apparatus
`
`that had received and authenticated a verification token and a database
`
`related to a verified web service: “[N]either Baiya nor Wimmer . . .
`
`suggests . . . establishing connection with the at least one
`
`communications console . . . wherein the API is [related to] a verified
`
`web service . . . .” (Ex. 2001 (Reasons for Allowance).) The prior art
`
`references did not use this API connection “to complete the verification
`
`process . . . wherein the electronic identification reference comprises a
`
`verified web service account identifier of the first user . . . .” (Id.)
`
`Mr. Grecia respectfully requests that the Board decline to institute
`
`inter partes review here for three reasons. First, Petitioner Unified Patents
`
`Inc. (“UPI”) mischaracterizes the Examiner’s reason for allowance:
`
`“[T]he Examiner found no reference where a user’s membership was
`
`used to brand digital content so it could be used on multiple devices.”
`
`(Petition at 10.) That does not approach an accurate representation of
`
`the file history. The ‘555 patent itself identifies prior art that had branded
`
`
`
`1
`
`EWS-005514
`
`
`
`digital content with membership data: “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.” (Petition Ex. 1001 (‘555 patent) col.
`
`2:18-22.)
`
`Second, because UPI’s primary references (DeMello and Pestoni)
`
`lack teaching an apparatus that establishes an API connection between it
`
`and a secondary apparatus, UPI cannot present a coherent invalidity
`
`theory. For example, UPI argues that DeMello’s bookstore server is the
`
`apparatus that authenticates the verification token received from the e-
`
`book reader. Then, however, UPI changes to the e-book reader
`
`establishing an API connection with the activation server. In short, UPI
`
`fails to point to the singular apparatus that “receives,” “authenticates,”
`
`“establishes,” “requests,” “receives (a second time),” and then “writes,”
`
`as claimed in the ‘555 patent. Instead, UPI points to an incoherent mix
`
`of devices, databases, and servers in an attempt to force DeMello and
`
`Pestoni into the ‘555 patent’s scope.
`
`Third, even if one gave UPI the ability to simply ignore the order
`
`of functions performed by the apparatus of the ‘555 patent, the invalidity
`
`
`
`2
`
`EWS-005515
`
`
`
`theory still fails. Continuing with the example from DeMello, UPI
`
`argues that the e-book reader establishes an API connection between the
`
`reader and the activation server. The server, under UPI’s theory, then
`
`requests and receives an ID and password. The server does not then write
`
`the ID and password to the metadata of the digital media, as required by
`
`the ‘555 claims, but rather creates an authentication certificate that is
`
`pushed to the e-book reader. Thus, even under UPI’s convoluted reading
`
`of the ‘555 claims and DeMello, the verified web service account
`
`identifier is, at best, written to the data store on the device, but not into
`
`the metadata of digital media to be acquired.
`
`The deficiencies of Pestoni as an invalidating reference are even
`
`more pronounced than those of DeMello.
`
`
`
`BACKGROUND
`
`
`
`In this section, Patent Owner describes the ‘555 patent and the
`
`Examiner’s reason for allowance. This section also sets forth the
`
`pertinent teachings of DeMello and Pestoni.
`
`The ‘555 Patent
`
`Fig. 3 illustrates an example of the process claimed in the ‘555
`
`patent. The elements and processes described with reference to Fig. 3
`
`
`
`3
`
`EWS-005516
`
`
`
`clearly delineate the distinctions between the claimed invention and the
`
`prior art:
`
`“A user posts a branding request via the Kodekey GUI interface 301.”
`
`(Petition Ex. 1001 (‘555 patent) col. 6:65-66.) In response, “The
`
`Kodekey GUI interface 301 prompts the user to enter the token and
`
`
`
`
`
`4
`
`EWS-005517
`
`
`
`press the redeem button present on the Kodekey GUI interface 301.”
`
`(Petition Ex. 1001 (‘555 patent) col. 6:67-7:3.) The token is then
`
`authenticated: “The Kodekey GUI interface is connected to the database
`
`305 via the internet 304 through the networking card 303. The database
`
`305 is the database used to read/write and store the tokens, also referred
`
`to as the token database.” (Id., 7:6-10.)
`
`Clearly, many prior art systems taught the verification of a token
`
`through a GUI interface, but these next steps are where the invention
`
`claimed in the ‘555 patent distinguishes itself from the prior art. Rather
`
`than completing the process between the connection established between
`
`the Kodekey GUI and the token database, the ‘555 patent teaches a
`
`process of establishing a new and distinct connection with a verified web
`
`service: “The user is redirected to the APIwebsite.com GUI 307 through
`
`the internet 306.” (Id., 7:11-12.) The account identifier is then requested,
`
`received, and written into the metadata: “The APIwebsite.com is the
`
`GUI to the membership API in which the electronic ID is collected and
`
`sent back to the Kodekey GUI interface 301. . . . The database 309 is the
`
`database connected to the web service membership in which the user’s
`
`electronic ID is queried from.” (Id., 7:11-19.)
`
`
`
`5
`
`EWS-005518
`
`
`
`The ‘555 patent teaches that the apparatus requests and receives
`
`the account identifier via an API connection made possible by a
`
`credential assigned to the apparatus: “The Facebook API system, as well
`
`as others, operates based on an access authentication system called from a
`
`connected apparatus (which is usually an Internet powered desktop or
`
`browser based application) with an API Key, an Application Secret Key
`
`and could also include an Application ID. For example, the Facebook
`
`API Application Keys required to establish a data exchange session with
`
`the connected apparatus might look like:
`
`API Key
`
`37a925fc5ee9b4752af981b9a30e9a73gh
`
`Application Secret
`
`f2a2d92ef395cce88eb0261d4b4gsa782
`
`Application ID
`
`51920566446”
`
`(Petition Ex. 1001 (‘555 patent) col. 10:50-63 (emphasis added).)
`
`In other words, after the user posts a branding request through a
`
`first GUI (i.e., Kodekey GUI 301) and the user’s verification token is
`
`authenticated in a first database (i.e., database 305), the system
`
`establishes a new connection to a verified web service (i.e.,
`
`
`
`6
`
`EWS-005519
`
`
`
`APIwebsite.com GUI 307), through which an account identifier is
`
`requested, received, and written into the metadata (i.e., product
`
`metadata 302). The prior art simply does not teach the use of a verified
`
`web service in the manner claimed in the ‘555 patent.
`
`
`
`The ‘555 patent’s description of the metadata underscores that this
`
`invention “will work as a front-end to encrypted files as an authorization
`
`agent for decrypted access” (id., 5:38-39): “The product metadata 302 is
`
`read/writable metadata associated with the digital media to be acquired.”
`
`(Id., 7:3-4 (emphasis added).) Simply put, the invention claimed in the
`
`‘555 patent does not handle the digital media itself, but rather acts as a
`
`gatekeeper to that content. The invention authorizes access by ultimately
`
`writing the verification token or the account identifier into the metadata
`
`of the digital media. To extend the gatekeeper metaphor, the digital
`
`media itself is behind the gatekeeper who authorizes decrypted access by
`
`completing the process claimed in the ‘555 patent.
`
`
`
`Claim 1 of the ‘555 patent is exemplary and reproduced here with
`
`annotations to Figure 3 and pertinent teachings from the written
`
`description:
`
`A method for monitoring access to an
`
`encrypted digital media, the method facilitating
`
`7
`
`
`
`EWS-005520
`
`
`
`interoperability between a plurality of data
`
`processing devices, the method comprising:
`
`
`[301, 303, 304, and 305] receiving an encrypted
`
`digital media access branding request from at
`
`least one communications console of the
`
`plurality of data processing devices, the
`
`branding request being a read or write request
`
`of metadata of the encrypted digital media, the
`
`request comprising a membership verification
`
`token provided by a first user, corresponding to
`
`the encrypted digital media;
`[305] authenticating the membership
`
`verification token, the authentication being
`
`performed in connection with a token database;
`[306; col. 10:50-63] establishing connection
`
`with the at least one communications console
`
`wherein the communications console is a
`
`combination of a graphic user interface (GUI)
`
`and an Applications Programmable Interface
`
`(API) protocol, wherein the API is related to a
`
`verified web service, the verified web service
`
`capable of facilitating a two way data exchange
`
`to complete a verification process;
`[307; 308; and 309] requesting at least one
`
`electronic identification reference from the at
`
`8
`
`
`
`EWS-005521
`
`
`
`least one communications console wherein the
`
`electronic identification reference comprises a
`
`verified web service account identifier of the
`
`first user;
`[307; 308; and 309] receiving the at least one
`
`electronic identification reference from the at
`
`least one communications console; and
`[301; 302] branding metadata of the encrypted
`
`digital media by writing the verification token
`
`and the electronic identification reference into
`
`the metadata.
`
` (Petition Ex. 1001 (‘555 patent) col. 14:36-64.)
`
`The Examiner cited the following two references as being the
`
`closest materials to the subject matter of the ‘555 patent: Baiya et al. PG
`
`Pub. 20110288946, Method and System of Managing Digital
`
`Multimedia Content (“Baiya”) (Ex. 2002); and Chris Wimmer, U.S.
`
`Patent 7,526,650, Personal Identifiers for Protecting Video Content
`
`(“Wimmer”) (Ex. 2003). (Ex. 2001.) In short, the Examiner found that
`
`while Baiya and Wimmer disclose certain of the ‘555 patent limitations,
`
`these references lack disclosure of establishing a connection between an
`
`apparatus and a verified web service in order to request and receive an
`
`account identifier. (Id.)
`
`
`
`9
`
`EWS-005522
`
`
`
`Closer examination of the Baiya and Wimmer disclosures
`
`illustrates the novelty and non-obviousness of the ‘555 patent, as
`
`determined by the Examiner.
`
`In Baiya, a user accesses digital media through an interface called
`
`the Content Manager [0022]:
`
`Baiya discloses a process of ‘the management of
`
`digital multimedia content comprises a
`
`computer-implemented digital multimedia
`
`content management system comprising the
`
`following computer executable components: an
`
`upload component that allows a first user to tag
`
`the digital media content with one or more
`
`attributes . . . a grouping component that groups
`
`the digital media content according to the one or
`
`more attributes; a licensing component that
`
`attaches one or more keys to the digital media
`
`content; a security component that encrypts the
`
`digital media content; and a sharing component
`
`that allows one or more second users to access
`
`the digital media content [sic] (Fig. 3-4 and
`
`paragraphs [0008]).
`
`
`(Ex. 2001 at 5.) The Examiner then notes that the Content Manager uses
`
`an API protocol “for access control authentication and authorization
`
`
`
`information.” (Id. (citing paragraph [0064]).)
`
`10
`
`EWS-005523
`
`
`
`
`
`The Examiner cited, among other things, Figure 5 of Wimmer as
`
`disclosing some of the limitations of the ‘555 patent:
`
`The branding decision engine 504 receives the
`
`metadata 302 or interpretation from the
`
`metadata reader 502 and may be employed to
`
`decide which parts or programs within a video
`content 102 are to receive a brand 104. When
`
`the branding decision engine 504 decides to
`
`brand a video content 102 or program, an
`
`indication is sent to the brand generator 508 to
`
`brand the associated video content 102.
`
`
`(Ex. 2003 (U.S. 7,526,650) col. 6:22-28).)
`
`As the Examiner recognized, the disclosure in Baiya and Wimmer
`
`corresponds to, for example, the first, second, and sixth steps of claim 1
`
`of the ‘555 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). The Examiner allowed the ‘555
`
`patent over Baiya and Wimmer, however, because these references
`
`lacked disclosure or teaching of establishing an API connection between
`
`the apparatus and the verified web service and requesting and receiving
`
`
`
`11
`
`EWS-005524
`
`
`
`an account identifier from the apparatus and through the established API
`
`connection. (Ex. 2001 at 6.)
`
`
`
`DeMello
`
`U.S. Patent No. 6,891,953 (the “‘953 patent”) issued to Microsoft
`
`Corporation on May 10, 2005 and teaches a novel method and system
`
`for binding devices to a persona so that all bound devices are only placed
`
`into the condition to accept encrypted copyrighted digital content: “The
`
`activation site ‘activates’ client-reading devices in a way that binds them
`
`to a persona, and limits the number of devices that may be activated for
`
`a particular persona, or the rate at which such devices may be activated
`
`for a particular persona.” (Petition Ex. 1006 (‘953 patent) Abstract.) As
`
`is evident from the quoted teachings of DeMello below, DeMello binds
`
`devices—not content—to the persona. DeMello repeatedly explains that
`
`binding devices rather than content to the persona provides adequate
`
`protection to copyright holders that the holders’ content will not be
`
`distributed without authority.
`
`As a first note, DeMello is cumulative of the prior art reviewed
`
`during the Examination of the ‘555 patent. The Examiner reviewed an
`
`article that generally discussed DeMello: “The most stringent form of
`
`security that Microsoft Reader offers is called owner exclusive e-books,
`
`
`
`12
`
`EWS-005525
`
`
`
`which uses traditional DRM technologies. To buy the e-book the
`
`consumer must first open Microsoft Reader, which ensures that when
`
`the book is downloaded it becomes linked to the computer’s Microsoft
`
`Passport account. Thus the e-book can only be opened with the
`
`computer with which it was downloaded, preventing copying and
`
`distribution of the text.” (Ex. 2004 (IDS and Article (6 of 15) dated Feb.
`
`24, 2012.)
`
`DeMello teaches a system built for mass distribution of valuable
`
`(copyrighted) content in digital form. DeMello recognizes that some
`
`digital content needs no protection, but “‘Fully individually’ content is
`
`encrypted content provided with a decrypted key . . . encrypted in such a
`
`way that it cannot be accessed in the absence of a ‘secure repository’ and
`
`‘activation certificate,’ which are issued by the activation server
`
`arrangement only to a particular client or set of clients, thereby limiting the
`
`use of such content to a finite number of installations.” (Petition Ex. 1006
`
`(‘953 patent) col. 2:12-18 (emphasis added).)
`
`DeMello was precise about the order of his steps and that the
`
`persona was to be tied to the device (not the content): “[T]he activation
`
`sever arrangement preferably provides a given activation certificate . . .
`
`only after authenticating credentials (e.g., username and password)
`
`
`
`13
`
`EWS-005526
`
`
`
`associated with a persona.” (Petition Ex. 1006 (‘953 patent) col. 2:12-18
`
`(emphasis added).) DeMello teaches that his process is at a stand still as
`
`long as the user does not “activate” the e-book reader: “After users
`
`purchase their eBook devices or download the reader software 90, 92
`
`from the Internet, they will be encouraged to activate their readers the
`
`first time it is launched . . . .” (Id., col. 22:43-46.) “Assuming the user has
`
`agreed to activate the reader . . . .” (Id., col. 23:3-4.)
`
`DeMello teaches that the retail website selling books is, from the
`
`user’s perspective, the same as the fulfillment site: “Essentially, the
`
`retailer uses the URL encryption object 74 to encrypt information
`
`relating to the purchase of an eBook, and includes this encrypted
`
`information as a parameter to a URL that points to the fulfillment center
`
`site.” (Petition Ex. 1006 (‘953 patent) col. 15:19-23.)
`
`DeMello assures copyright holders that the method and system are
`
`secure as follows, by way of example:
`
`• “In the example of FIG. 8, users are limited to five
`
`activations within 90 days after the first activation of the
`
`reader. . . . An example of the type of abuse that such a limit
`
`prevents would be a book club’s purchasing an eBook with
`
`its PASSPORT account and permitting thousands of its
`
`14
`
`
`
`EWS-005527
`
`
`
`members to activate their readers with the book club’s
`
`PASSPORT credentials.” (Petition Ex. 1006 ('953 patent)
`
`col. 23:41-48.)
`
`• “[O]ne aspect of resisting abuse of the DRM System is to
`
`limit the number of activations that any particular user may
`
`have with a single PASSPORT ID. If this number is not
`
`limited, dishonest users may be able [to] sign-up for a ‘public
`
`domain’ PASSPORT then share the credentials for that
`
`account with all their friends (or worse, Post it on the Web) .
`
`. . .” (Petition Ex. 1006 ('953 patent) col. 25:18-25.)1
`
` DeMello teaches a DRM scheme that “embed[s] credit card
`
`information . . . inside the metadata area of a delivered file format [that]
`
`restrict[s] the compatibility of the file with a limited number of reader
`
`devices and computer applications.” (Petition Ex. 1001 (‘555 patent) col.
`
`2:20-24.) “[T]he Encrypt() method takes the following parameters to be
`
`
`1
`
`Compare “[A] solution is needed to give consumers the unlimited
`
`interoperability between devices and ‘fair use' sharing partners for an
`
`infinite time frame while protecting commercial digital media from
`
`unlicensed distribution to sustain long-term return on investments.”
`
`(Petition Ex. 1001 (‘555 patent) col. 3:2-6.)
`
`
`
`15
`
`EWS-005528
`
`
`
`incorporated into the encrypted blob that will be used in the URL: . . .
`
`This string preferably maps to the consumer listed in the credit card used
`
`for the commercial transaction . . . .” (Petition Ex. 1006 (‘953 patent)
`
`col. 15:67-16:19.)
`
`DeMello teaches association of the device to the persona—not the
`
`content to the persona: “The secure repository and activation certificate
`
`associates the activated reader with an online persona (e.g., a
`MICROSOFT® PASSPORT™ ID) to ensure that users will be able to
`
`read their rightfully acquired titles on all instances of readers that they
`
`own or have activated to their persona (but not on non-activated readers,
`
`or readers not activated for that persona)—assuming they activate their
`
`readers using the same user ID and password every time.” (Petition Ex.
`
`1006 (‘953 patent) col. 13:21-29.)
`
`The activate certificate is pushed from the activation server to the
`
`e-book reader; the reader, not the activation server, then writes the
`
`certificate to a “fully individualized” e-book: “At step 188, the activation
`
`servers generate and digitally sign and individualized secure repository
`
`executable (tied to the uploaded machine ID) and an activation
`certificate (tied to the user’s PASSPORT™ ID). The secure repository
`
`executable and activation certificate are then downloaded to the client
`
`
`
`16
`
`EWS-005529
`
`
`
`(steps 188 and 190). The activation certificate is encrypted (for privacy
`
`reasons) and is later uploaded by the client to the download server for
`
`preparing fully individualized copies (level 5 protected titles).” (Petition
`
`Ex. 1006 (‘953 patent) col. 24:29-38 (emphasis added).)
`
`
`
`Pestoni
`
`Pestoni teaches domain management for digital media: “System
`
`100 includes one or more domain administrators 102, one or more
`
`content providers 104, one or more license servers 106, multiple (x)
`
`domains 108(1), . . ., 108(x), and one or more trusted authorities 120.
`
`Each of these components 102, 104, 106, 108, and 120 can communicate
`
`with one another over network 110. Network 110 can be any of a variety
`
`of networks, such as the Internet, a local area network, a cellular phone
`
`network, other public and/or proprietary networks, combinations
`
`thereof, and so forth.” (Petition Ex. 1007 (Pestoni) [0013].)
`
`
`
`The “join-domain request” contains pieces of information
`
`corresponding to the device (not information corresponding to the digital
`
`content): “The join-domain request includes various parameters to
`
`identify device 202 as well as the domain that device 202 is requesting to
`
`join.” (Petition Ex. 1007 (Pestoni) [0039].) “The user credentials are
`
`
`
`17
`
`EWS-005530
`
`
`
`various credentials that identify the user of device 202.” (Id. [0041].)
`
`“Domain request approval module 224 receives join-domain request 220
`
`and determines whether device 202 is permitted to join the requested
`
`domain.” (Id. [0044].) “If allowing device 202 to join the requested
`
`domain does not violate any of the restrictions imposed on the requested
`
`domain, and if the user credentials are verified, then device 202 is
`
`permitted to join the domain.” (Id. [0044].)
`
`
`
`The user device requests and receives information from the license
`
`server: “Device 202 sends a content license request 252 to license server
`
`106.” (Petition Ex. 1007 (Pestoni) [0072].) The request includes a key
`
`ID, a domain ID, and a domain certificate—all of which the device
`
`already has obtained from various sources: “[T]his key ID is obtained by
`
`device 202 from content provider 104 along with the protected content.”
`
`(Id.) “[T]he domain ID is obtained by device 202 from domain
`
`administrator 102 as part of domain membership license 222.” (Id.
`
`[0073].) “[T]he domain certificate is obtained by device 202 from
`
`domain administrator 102 as part of domain membership license 222.”
`
`(Id. [0074].)
`
`
`
`
`
`18
`
`EWS-005531
`
`
`
`
`
`ARGUMENT
`
`I.
`
`UPI cannot prevail with DeMello or Pestoni as anticipating
`references because neither reference teaches establishing a
`connection with a verified web service in the manner claimed in
`the ‘555 patent.
`
`Neither DeMello, nor Pestoni, nor any combination thereof teach
`
`the step of completing a verification process through a two way API data
`
`exchange between the apparatus and a verified web service.
`
`A. UPI’s arguments are based on a misrepresentation of the
`claimed function of the “verified web service.”
`
`
`
`Early in his declaration, Mr. Cherukuri makes the following
`
`misstatement about, and disingenuous citation to, the ‘555 patent: “The
`
`‘555 patent discloses that the purchaser’s credentials are authenticated
`
`through e.g., a web service and Facebook API system. In response to a
`
`successful authentication, in this example, Facebook provides a
`
`membership verification token. [See, e.g., ‘555 patent at 10:41-46 and
`
`11:8-24.]” (Petition Ex. 1009 (Cherukuri Decl.) ¶ 18.) This inaccuracy is
`
`blatant. The citation is misleading, but the cited portion of the ‘555
`
`patent is clear; the verification token is provided by the first user via the
`
`access request, the verification token is not related to the web service or
`
`
`
`19
`
`EWS-005532
`
`
`
`interaction with the web service, and the verification token is most
`
`certainly not provided by the web service in response to a successful
`
`authentication.
`
`Mr. Cherukuri’s testimony that the verification token issues after
`
`the user’s credential is authenticated by the verified web service is wrong:
`
`“The Facebook API system, as well as other, operates based on an
`
`access authentication system called from a connected apparatus (which
`
`is usually an Internet powered desktop or browser based application)
`
`with an API Key, an Application Secret Key and could also include an
`
`Application ID.” (Petition Ex. 1001 (‘555 patent) col. 10:50-55.)
`
`The Board should give the Cherukuri declaration no weight
`
`because of its broad misrepresentation of the ‘555 patent. Further, the
`
`Board should decline to institute inter partes review based on the Petition
`
`that sought to exploit this mischaracterization of the ‘555 patent by,
`
`among other things, misrepresenting the reason for allowance as “the
`
`Examiner found no reference where a user’s membership was used to
`
`brand digital content . . . .” (Petition at 10.) The Examiner in fact
`
`reasoned that the ‘555 patent was allowable because no other reference
`
`established a connection with a verified web service to obtain a verified
`
`web service account identifier. (Ex. 2001.)
`
`
`
`20
`
`EWS-005533
`
`
`
`UPI disparages and distorts the ‘555 patent claim, specification,
`
`and file history in order to fit DeMello and Pestoni into an invalidation
`
`theory that would otherwise be non-existent. As shown next, even
`
`accepting UPI’s misstatements regarding the ‘555 patent as true,
`
`DeMello and Pestoni still fail to invalidate the ‘555 patent under either
`
`section 102 or section 103.
`
`B. DeMello and Pestoni would not invalidate even accepting
`UPI’s description of the ‘555 patent.
`
`
`Both DeMello and Pestoni lack the API connection between the
`
`apparatus and the verified web service. This fundamental shortcoming
`
`makes UPI’s invalidity theory incoherent for both references.
`
`1. DeMello lacks an apparatus that connects with a
`verified web service to complete a verification
`process.
`
`
`UPI’s theory regarding DeMello falls apart at the very beginning
`
`of the analysis. The ‘555 process begins by “receiving an encrypted
`
`digital media access branding request from at least one communications
`
`console . . . .” (Petition Ex. 1001 (‘555 patent) col. 14:39-40.) UPI
`
`proposes that DeMello meets this limitation when the bookstore server
`
`receives a user request to buy a book with a credit card: “Through this
`
`communication [access request], bookstore servers 72 may allow users to
`
`
`
`21
`
`EWS-005534
`
`
`
`shop for e-book titles, establish their membership credentials with the
`
`retailer [verification token] . . . .” (Petition at 19 (quoting DeMello, col.
`
`9:9-16) (emphasis in original); see also id. (“The authentication can be of
`
`the credit card or membership information by the retail site (e.g.,
`
`Amazon log-on).”).) The comparison of this teaching to the first step of
`
`the ‘555 method is inapt, however, because ‘555 claims that the
`
`“membership verification token . . . correspond[s] to the encrypted
`
`digital media.” (Petition Ex. 1001 (‘555 patent) col. 14:43-45.) The credit
`
`card information in DeMello cannot be the “membership verification
`
`token,” because the credit card number corresponds to the credit card
`
`account and not the digital media, as required by the ‘555 patent.
`
`UPI’s invalidity theory fares no better on subsequent steps because
`
`UPI abandons the bookstore server as the apparatus carrying out the
`
`steps of the ‘555 method. Indeed, according to UPI, not the bookstore
`
`server but the e-book reader establishes a connection with the verified
`
`web service—the activation server in UPI’s analysis. (Petition at 25.)
`
`Even assuming UPI was allowed to ignore the claim language of
`
`the ‘555 patent—which identifies one apparatus “receiving,”
`
`“authenticating,” “connecting,” “requesting,” “receiving (a second
`
`time),” and “writing”—the flow of information is exactly opposite in
`
`
`
`22
`
`EWS-005535
`
`
`
`DeMello as compared to the ‘555 patent, no matter the various
`
`structures UPI “cherry picks” from DeMello. The apparatus requests and
`
`receives the electronic identification reference: “requesting at least one
`
`electronic identification reference from the at least one communications
`
`console wherein the electronic identification reference comprises a
`
`verified web service account identifier of the first user . . . receiving the at
`
`least one electronic identification reference from the at least one
`
`communications console . . . .” (Petition Ex. 1001 (‘555 patent) col.
`
`14:56-61.)
`
`UPI relies on the activation server as the apparatus that requests
`
`and receives the user’s PASSPORT ID. (Petition at 26 & 27.) But the
`
`activation server merely includes the PASSPORT ID in an activation
`
`certificate that is later stored on the e-book reader. (Id. at 28.) The
`
`activate certificate is pushed from the activation server to the e-book
`
`reader; the reader, not the activation server, then writes the certificate to
`
`a “fully individualized” e-book: “At step 188, the activation servers
`
`generate and digitally sign and individualized secure repository
`
`executable (tied to the uploaded machine ID) and an activation
`certificate (tied to the user’s PASSPORT™ ID). The secure repository
`
`executable and activation certificate are then downloaded to the client
`
`
`
`23
`
`EWS-005536
`
`
`
`(steps 188 and 190). The activation certificate is encrypted (for privacy
`
`reasons) and is later uploaded by the client to the download server for
`
`preparing fully individualize