Filed on behalf of William Grecia
`By: Isaac Rabicoff (isaac@rabilaw.com)
`Rabicoff Law LLC
`73 W Monroe St
`Chicago, IL 60603
`Tel: (773) 669-4590
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________________________________________
`
`MASTERCARD INTERNATIONAL INCORPORATED
`Petitioner
`
`v.
`
`WILLIAM GRECIA
`Patent Owner
`_____________________________________________________________
`
`Case No.: IPR2017-00791
`Patent 8,533,860
`____________________________________________________________
`
`
`
`
`
`
`
`
`PRELIMINARY RESPONSE BY PATENT OWNER WILLIAM
`GRECIA
`
`
`
`
`
`
`
`
`
`
`
`EWS-005472
`
`Early Warning Services 1033
`IPR of U.S. Pat. No. 8,887,308
`
`
`By: Isaac Rabicoff (isaac@rabilaw.com)
`Rabicoff Law LLC
`73 W Monroe St
`Chicago, IL 60603
`Tel: (773) 669-4590
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________________________________________
`
`MASTERCARD INTERNATIONAL INCORPORATED
`Petitioner
`
`v.
`
`WILLIAM GRECIA
`Patent Owner
`_____________________________________________________________
`
`Case No.: IPR2017-00791
`Patent 8,533,860
`____________________________________________________________
`
`
`
`
`
`
`
`
`PRELIMINARY RESPONSE BY PATENT OWNER WILLIAM
`GRECIA
`
`
`
`
`
`
`
`
`
`
`
`EWS-005472
`
`Early Warning Services 1033
`IPR of U.S. Pat. No. 8,887,308
`
`
`
`TABLE OF CONTENTS
`
`INTRODUCTION .......................................................................................... 3
`
`BACKGROUND ............................................................................................ 5
`
`I. The ‘860 Patent ........................................................................................ 5
`
`A. Written Description ............................................................................... 6
`
`B. Exemplary Claim from the ‘860 Patent............................................... 12
`
`II. File History of the ‘860 Patent ............................................................... 15
`
`A. Examiner’s Reasons for Allowance .................................................... 15
`
`B. Apple’s App. No. 12/766,337 ............................................................. 19
`
`III. Mastercard’s Asserted References ......................................................... 20
`
`A. Ameerally ............................................................................................ 20
`
`B. Gautier ................................................................................................. 22
`
`C. Taylor .................................................................................................. 22
`
`D. Frakes ................................................................................................... 23
`
`E. Zweig ................................................................................................... 23
`
`IV. Claim Construction ................................................................................ 24
`
`ARGUMENT ................................................................................................ 24
`
`CONCLUSION ............................................................................................. 28
`
`
`
`
`
`
`
`2
`
`EWS-005473
`
`
`
`INTRODUCTION
`
`William Grecia owns U.S. Patent No. 8,533,860 (the “‘860 patent”),
`
`which claims, among other things, “[a] method for authorizing access to
`
`digital content using a cloud system . . . .” (Ex. 1001 (‘860 patent) at 14:31-
`
`32.) The method includes the following six steps, all of which must be
`
`performed before authorized access to the digital content is granted:
`
`• receiving a digital content access request from a communications
`
`console (first apparatus), where the request includes a token
`
`corresponding to the digital content requested;
`
`• authenticating the token;
`
`• establishing a connection with the first apparatus using an application
`
`programmable interface (“API”) related to a verified web service
`
`(second apparatus), wherein the web service completes a verification
`
`process;
`
`• requesting at least one identification reference;
`
`• receiving the at least one identification reference; and
`
`• writing at least one of the verification token or the identification
`
`reference into the metadata of the digital content.
`
`The Examiner supported allowance of the ‘860 patent by reasoning
`
`that, although the prior art taught authentication of tokens and writing these
`
`
`
`3
`
`EWS-005474
`
`
`
`tokens into the metadata of digital content, no one had yet taught steps 3, 4,
`
`and 5—viz., “establishing a connection with a verified web service” and
`
`“requesting [and receiving] at least one identification reference from the at
`
`least one communications console . . . .” (Ex. 2001 at 13-15.)
`
`
`
`Mastercard’s asserted prior art—Apple’s iTunes system—is repetitive
`
`of the prior art that the Examiner considered. All of this prior art lacks an
`
`API connection related to a verified web service to complete the verification
`
`process by requesting and receiving an identification reference.
`
`In fact, none of Mastercard’s references mentions an API connection.
`
`Rather, Mastercard relies on its expert in 2017 to say, “Use of an API such
`
`as the iTunes store search API to communicate with the iTunes store (i.e.,
`
`server) is well known to one of ordinary skill in the art at the time of the
`
`invention.” (Ex. 1019 (Cherukuri Decl.) ¶ 131.) Of course, Mastercard’s
`
`expert’s argument cannot be incorporated into the Petition. See, e.g., 37
`
`C.F.R. § 42.6(a)(3) (“Arguments must not be incorporated by reference from
`
`one document into another document.”). Even if Mastercard was permitted
`
`to incorporate its expert’s argument into the Petition, however, the expert
`
`argument could not in any event stand in as a placeholder where disclosure
`
`or teaching of a prior art reference should have been. In short, Mastercard
`
`fails to assert one prior art reference that suggests an API connection—let
`
`
`
`4
`
`EWS-005475
`
`
`
`alone an API connection related to a verified web service, as required by the
`
`‘860 patent claims
`
`Instead, the Mastercard references disclose what the Examiner
`
`determined other prior art discloses: authenticating and writing verification
`
`tokens into the metadata of the digital content—steps 1, 2, and 6 of the ‘860
`
`method.
`
`
`
`For this reason, Grecia respectfully requests that the Board deny
`
`Mastercard’s petition as to all challenged claims.
`
`BACKGROUND
`
`This section has four parts. Grecia first describes the ‘860 patent.
`
`Second, he describes pertinent portions of the file history. Third, Grecia
`
`discusses the prior art references that Mastercard asserts against the ‘860
`
`patent. And, fourth, Patent Owner concludes with a statement that he does
`
`not believe that claim construction is required to resolve this controversy
`
`between him and Mastercard.
`
`I.
`
`The ‘860 Patent
`
`In summary, claim 1 consists of six steps: First, “receiving a digital
`
`content access request” that includes “a verification token provided by a first
`
`user corresponding to the digital content . . . .” (Ex. 1001 at 14:38-46.)
`
`Second, “authenticating the verification token . . . .” (Id.)
`
`
`
`5
`
`EWS-005476
`
`
`
`Third, “establishing a connection with the at least one
`
`communications console . . . wherein the API is related to a verified web
`
`service . . . .” (Id. at 14:51-55.)
`
`Fourth, “requesting the at least one identification reference from the at
`
`least one communications console . . .” and, then fifth, “receiving the at least
`
`one identification from the at least one communications console . . . .” (Id. at
`
`14:60-15:2.)
`
`Sixth, “writing at least one of the verification token or the
`
`identification reference into the metadata.” (Id. at 15:3-4.)
`
`A. Written Description
`
`The ‘860 patent claims methods, systems, and apparatuses that “work
`
`as a front-end to encrypted files as an authorization agent for decrypted
`
`access.” (Ex. 1001 at 5:37-39.) Thus, the invention claimed in the ‘860
`
`patent is akin to a gatekeeper who authorizes access to the encrypted digital
`
`content behind him.
`
`Fig. 1, for example, shows a system containing six modules that lay at
`
`the front-end of the encrypted content:
`
`
`
`6
`
`EWS-005477
`
`
`
`The ‘860 patent describes the various modules as being distinct and
`
`
`
`assigns an order for each module’s use.
`
`At the front of the method/system/apparatus, “The first receipt module
`
`102 receives a branding request from at least one communications console of
`
`the plurality of data processing devices. The branding request is a read or
`
`write request of metadata of the encrypted digital media and includes a
`
`membership verification token corresponding to the encrypted digital
`
`media.” (Id. at 5:45-50.)
`
`“Subsequently, the authentication module 104 authenticates the
`
`membership verification token. The authentication is performed in
`
`connection with a token database. Further, the connection module 106
`
`
`
`7
`
`EWS-005478
`
`
`
`establishes communication with the at least one communication console.”
`
`(Id. at 5:56-60.)
`
`There is only one request module and, as described, the request
`
`module “108 requests at least one electronic identification reference from
`
`the at least one communication console.” (Id. at 6:4-6.) In contrast, however,
`
`there are two receipt modules. While the first receipt module has already
`
`received the verification token, “[t]he second receipt module 110 receives
`
`the at least one electronic identification reference from the at least one
`
`communication console.” (Id. at 6:6-8.) “The branding module 112 brands
`
`metadata of the encrypted digital media by writing the membership
`
`verification token and the electronic identification into the metadata.” (Id. at
`
`6:8-11.)
`
`In context, each module has a specific role and operates in a specific
`
`order. For example, if the branding module were able to brand the metadata
`
`of the digital media prior to the successful completion of the previous
`
`modules’ tasks, the system would fail to perform its gatekeeping function.
`
`Fig. 3 illustrates an example of the process claimed in the ‘860 patent:
`
`
`
`8
`
`EWS-005479
`
`
`
`
`
`“A user posts a branding request via the Kodekey GUI interface 301.” (Id. at
`
`6:65-66.) In response, “The Kodekey GUI interface 301 prompts the user to
`
`enter the token and press the redeem button present on the Kodekey GUI
`
`interface 301.” (Id. at 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
`
`
`
`9
`
`EWS-005480
`
`
`
`read/write and store the tokens, also referred to as the token database.” (Id.
`
`at 7:6-10.)
`
`While many prior art systems no doubt taught the verification of a
`
`token through a GUI interface, these next steps are where the invention
`
`claimed in the ‘860 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 ‘860 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. at 7:10-11.)1 The identification reference 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. at 7:11-19.)
`
`
`1
`“Upon an access request of the digital media, the excelsior enabler
`
`[i.e., first user] interacts with the apparatus . . . to enter membership
`
`credentials in a GUI front-end connected to the API. . . . Once the enabler
`
`successfully sign[s] in to the GUI element then the apparatus will query the
`
`API for at least one electronic identification reference, in this discussion is
`
`the FBID.” (Ex. 1001 at 11:8-24.)
`
`
`
`10
`
`EWS-005481
`
`
`
`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 through a second GUI, a verified web service (i.e.,
`
`APIwebsite.com GUI 307), through which an identification reference 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 ‘860 patent.
`
`
`
`The ‘860 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. at 5:38-39): “The product metadata 302 is
`
`read/writable metadata associated with the digital media to be acquired.”
`
`(Id. at 7:3-4 (emphasis added).) Simply put, the invention claimed in the
`
`‘860 patent does not handle the digital content itself, but rather acts as a
`
`gatekeeper to that content. The invention authorizes access by ultimately
`
`writing the verification token or the identification reference into the
`
`metadata of the digital content. To extend the gatekeeper metaphor, the
`
`digital content itself is behind the gatekeeper who authorizes decrypted
`
`access by completing the process claimed in the ‘860 patent.
`
`
`
`11
`
`EWS-005482
`
`
`
`The ‘860 patent teaches that the “verified web service” requests and
`
`receives the identification reference via an API connection made possible by
`
`an authenticated credential: “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
`
`(Id. at 10:51-64.)
`
`
`B.
`
`Exemplary Claim from the ‘860 Patent
`
`Claim 1 of the ‘860 patent is an exemplary claim, and it is reproduced
`
`as follows with annotations from Figures 1 and 3:
`
`
`
`12
`
`EWS-005483
`
`
`
`A method for authorizing access to digital content
`
`using a cloud system [Fig. 3] comprising
`
`connected modules [102, 104, 106, 108, 110, 112]
`
`in operation as one or more of a cloud computing
`
`or a cloud storage in connection with devices and
`
`users, wherein the digital content is at least one of
`
`encrypted or not encrypted, the method facilitating
`
`access rights between a plurality of data processing
`
`devices, the method comprising:
`
`[102, 301] receiving a digital content access
`
`request from at least one communications console
`
`of the plurality of data processing devices, the
`
`access request being a read or write request of
`
`metadata of the digital content, wherein the read or
`
`write request of metadata is performed in
`
`connection with a combination of at least one
`
`device and the cloud system, the request
`
`comprising a verification token provided by a first
`
`user corresponding to the digital content, wherein
`
`the verification token is one or more of a
`
`password, e-mail address, payment system, credit
`
`card, authorization ready device, rights token, or
`
`one or more redeemable instruments of trade;
`
`
`
`[104, 303, 304, 305] authenticating the verification
`
`token;
`
`13
`
`
`
`
`
`EWS-005484
`
`
`
`
`
`[106, 306, 307] establishing a connection with the
`
`at least one communications console, wherein the
`
`communications console is a combination of a
`
`graphical user interface (GUI) and an Application
`
`Programmable Interface (API) wherein the API is
`
`related to a verified web service, the web service
`
`capable of facilitating a two way data exchange
`
`session to complete a verification process wherein
`
`the data exchange session comprises at least one
`
`identification reference;
`
`
`
`[108, 307, 308, 309] requesting the at least one
`
`identification reference from the at least one
`
`communications console, wherein the
`
`identification reference comprises one or more of a
`
`verified web service account identifier, letter,
`
`number, rights token, e-mail, password, access
`
`time, serial number, address, manufacturer
`
`identification, checksum, operating system
`
`version, browser version, credential, cookie, or
`
`key;
`
`
`
`[110, 309, 308, 307, 306] receiving the at least one
`
`identification reference from the at least one
`
`communications console; and
`
`
`
`
`
`14
`
`EWS-005485
`
`
`
`[112, 302] writing at least one of the verification
`
`token or the identification reference into the
`
`metadata.
`
`II.
`
`File History of the ‘860 Patent
`
`This section emphasizes two aspects of the file history bearing on
`
`Mastercard’s Petition. First, the section discusses the Examiner’s reasons for
`
`allowance, because the closest references the Examiner discussed when
`
`stating the reasons for allowance share some of the attributes of the Apple
`
`iTunes system Mastercard now asserts against the ‘860 patent—namely, the
`
`authentication of a verification token corresponding to the digital content
`
`and writing the token into the metadata of the digital content.
`
`Second, the section briefly discusses another Apple patent application,
`
`for which the parent of the ‘860 patent, U.S. Patent No. 8,402,555 (the “‘555
`
`patent”), was cited as prior art under section 103. The examiner’s reasoning
`
`in that other prosecution underscores how both the ‘860 patent and Apple’s
`
`improvements on its systems and processes differ from the prior art that
`
`Mastercard asserts in its Petition.
`
`A. Examiner’s Reasons for Allowance
`
`During examination, the Examiner cited the following two references
`
`as being the closest materials to the subject matter of the ‘860 patent: Baiya
`
`et al. PG Pub. 20110288946, Method and System of Managing Digital
`
`
`
`15
`
`EWS-005486
`
`
`
`Multimedia Content (“Baiya”); and Chris Wimmer, U.S. Patent 7,526,650,
`
`Personal Identifiers for Protecting Video Content (“Wimmer”). (Ex. 2001 at
`
`13-15.) In short, the Examiner found that while Baiya and Wimmer disclose
`
`certain of the ‘860 patent limitations, these references lack disclosure of
`
`“facilitating access rights between a plurality of data processing devices” by
`
`establishing a connection with a verified web service that then requests an
`
`identification reference. (Id.)
`
`
`
`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]).
`
`
`
`16
`
`EWS-005487
`
`
`
`
`(Ex. 2001 at 13-14.) The Examiner then notes that the Content Manager uses
`
`an API protocol “for access control authentication and authorization
`
`information.” (Id. at 14 (citing paragraph [0064]).)
`
`
`
`As the Examiner recognized, Baiya does not suggest “facilitating
`
`access rights between a plurality of data processing devices” according to
`
`the invention claimed in the ‘860 patent because, for example, Baiya only
`
`practices the first and second steps of claim 1 of the ‘860 patent. Indeed, in
`
`Baiya, “At 440 the Content Manager receives a request for access to content
`
`from a second user, where prior to sharing the content with the second user,
`
`the second user is authenticated 445.” (Ex. 2002 (Baiya) at [0078].) This
`
`disclosure corresponds to, for example, the first and second steps of claim 1
`
`of the ‘860 patent as illustrated in Figure 3 at 301, 303, and 305. Baiya stops
`
`there, however, and critically lacks the third, fourth, and fifth steps of claim
`
`1 of the ‘860 patent: establishing a connection with a verified web service
`
`(306 and 307), requesting an identification reference (307, 308, and 309),
`
`and a second receipt, this time of the identification reference (309, 308, 307,
`
`and 306).
`
`The Examiner also cited Figure 5 of Wimmer as disclosing some of
`
`the limitations of the ‘860 patent. The disclosure corresponding to Figure 5
`
`
`
`17
`
`EWS-005488
`
`
`
`of Wimmer suggests, for example, the limitations of the first, second, and
`
`sixth steps of claim 1 of the ‘860 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 (Wimmer) at 6:22-28).) 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, though, and lacks the third, fourth, and fifth
`
`steps of claim 1 of the ‘860 patent: establishing a connection with a verified
`
`web service (306 and 307), requesting an identification reference (307, 308,
`
`and 309), and a second receipt, this time of the identification reference (309,
`
`308, 307, and 306).
`
`
`
`
`
`
`
`18
`
`EWS-005489
`
`
`
`B. Apple’s App. No. 12/766,337
`
`Mastercard’s Petition is based on numerous Apple applications
`
`relating, essentially, to the 2006 version of the iTunes service. Another
`
`Apple application, filed April 23, 2010, is part of the ‘555 patent’s file
`
`history. (Ex. 2004 (App. No. 12/766,337 Office Actions).) In that Apple
`
`prosecution, the examiner cited the ‘555 patent as prior art under section
`
`103, and some of the examiner’s discussion there highlights the elements
`
`that Mastercard’s asserted references are simply missing.
`
`The ‘337 application was ultimately granted. During prosecution,
`
`however, the examiner rejected the claims under examination based on the
`
`‘555 patent rendering the claims obvious under section 103. (Ex. 2004 at 3-
`
`11.) For among other reasons, the claims under examination and the ‘555
`
`patent both disclosed or taught the apparatus requesting and receiving the
`
`identification reference after the verification token had been authenticated:
`
`“in response to determining that the second user is known [i.e.,
`
`authentication], identifying credentials associated with the second user (e.g.,
`
`MAC address and FBID) (if the comparison action proves to be true, then
`
`access rights is granted to the secondary enabler. The current MAC address
`
`of the networking card as part of The App and the FBID retrieved are
`
`appended to the established metadata information the encrypted digital
`
`
`
`19
`
`EWS-005490
`
`
`
`media asset and access rights can be granted to a plurality of secondary
`
`enablers.) . . . . .” (Ex. 2005 (‘555 patent) at 14:12-18.)
`
`In other words, both Apple’s 2010 digital rights management (DRM)
`
`system and the ‘555 patent disclose and teach what Mastercard’s asserted
`
`references (Apple’s 2006 DRM system) lack: establishing a connection with
`
`a verified web service and then requesting and receiving an identification
`
`reference as steps performed prior to granting access to the digital media.
`
`III. Mastercard’s Asserted References
`
`A. Ameerally
`
`
`
`This is a patent application assigned to Apple Computer, Inc. relating
`
`to “[a] method of operating a digital media purchase system, receiving a
`
`unique promotional code from one of a plurality of consumers via a data
`
`network.” (Ex. 1003 at Abstract.) “The receipt [of a unique promotional
`
`code] is in association with a user account of the one consumer with the
`
`digital media purchase system. . . . A user account of the one consumer with
`
`the media purchase system is configured to enable access to the determined
`
`particular digital media from the media purchase system.” (Id. at [0009].)
`
`
`
`Figure 3 of Ameerally and its corresponding disclosure demonstrate
`
`that the promotional code (i.e., verification token corresponding to the
`
`digital content) is authenticated and then the user is granted access to the
`
`
`
`20
`
`EWS-005491
`
`
`
`digital content. “At step 314, the digital media purchase system 100 receives
`
`one of the unique promotional codes.” (Ex. 1003 at [0038].) “At step 316, it
`
`is determined what is the particular digital media content associated with the
`
`received promotional code.” (Id. at [0039].) “At step 318, the particular
`
`digital media content determined to be associated with the received
`
`promotional code is made accessible to the consumer 312.” (Id. at [0042].)
`
`
`
`Ameerally does not teach establishing an API connection related to a
`
`verified web service and requesting and receiving an identification
`
`reference: “Step 317 includes processing associated with user accounts with
`
`the digital media purchase system 100. If the user is already logged in to an
`
`account with digital media purchase system 100, then processing continues
`
`at step 318. Otherwise, the user is prompted to log into an account (if the
`
`user has previously created an account) or to create an account.” (Id. at
`
`[0041].)
`
`Ameerally assumes the connection with the verified web service—
`
`either the user (i) is already logged into the web service, (ii) logs into the
`
`web service, or (iii) creates an account with the web service. However the
`
`connection with the verified web service is established, though, the user is
`
`granted access to the digital content at step 318.
`
`
`
`21
`
`EWS-005492
`
`
`
`In other words, Ameerally does not use the connection with the verified web
`
`service to request and receive the identification reference.
`
`B. Gautier
`
`
`
`This application was also assigned to Apple Computer and teaches a
`
`purchase and distribution system based on the authentication of a buy
`
`request. Once the buy request corresponding to the digital content is
`
`authenticated, the user is granted access to the digital content:
`
`[O]nce an access request has been received, the
`
`access request is authenticated 604.
`
`. . .
`
`[W]hen the decision 606 determines that the
`
`authentication was successful, then an encrypted
`
`version of the selected media item that has been
`
`purchased is retrieved 610.
`
`
`(Ex. 1011 at [0077], [0078].)
`
`
`C. Taylor
`
`This is a publication describing how to use the promotional code
`
`system disclosed in Ameerally. The user is told to log into her iTunes
`
`account and then redeem the promotional code. (Ex. 1009.)
`
`Similar to Ameerally, there is no disclosure, teaching, or suggestion
`
`that Apple uses the connection with the verified web service (i.e., iTunes) to
`
`
`
`22
`
`EWS-005493
`
`
`
`request, receive, and then write the identification reference into the metadata
`
`of the digital content.
`
`D.
`
`Frakes
`
`This publication describes another embodiment disclosed in
`
`Ameerally. The user is told to log into her iTunes account and then redeem
`
`the promotional code. (Ex. 1008.) In addition, the publication demonstrates
`
`that the code, once authenticated and the user is granted access, is written
`
`into the metadata of the digital content. (Id. at 5 (showing purchase date).)
`
`E.
`
`Zweig
`
`
`
`This is another application assigned to Apple Computer teaching
`
`encryption techniques that uniquely mark each piece of digital content. (See
`
`generally Ex. 1004.) Authorized access has already been granted a first user:
`
`“[T]he digital content user system residing in the user device authorized by
`
`the digital content store to access the digital content in the encrypted digital
`
`content may include an untrusted software, e.g., an untrusted client
`
`software.” (Id. at [0030].) Zweig teaches granting authorized access to a
`
`second user based on the encryption techniques disclosed: “Accordingly,
`
`certain embodiments of the present invention enable user B to obtain
`
`authorization from digital content store 115 to access the content in the copy
`
`at operation 515.” (Id. at [0030].)
`
`
`
`23
`
`EWS-005494
`
`
`
`IV. Claim Construction
`
`
`
`Patent Owner does not believe that any term requires construction to
`
`resolve this controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200
`
`F.3d 795, 803 (Fed. Cir. 1999) (“only those terms need be construed that are
`
`in controversy, and only to the extent necessary to resolve the controversy”).
`
`ARGUMENT
`
`Mastercard’s Petition relies primarily on Ameerally, which teaches
`
`access to digital content after a unique promotional code is authenticated.
`
`(Ex. 1003 at [0039], [0042].) Frakes also teaches that the promotional code
`
`is written into the metadata of the digital content. (Ex. 1008 at 5 (showing
`
`purchase date).)
`
`These references cannot anticipate or render obvious the ‘860 patent
`
`claims because these references teach that access to the digital content is
`
`authorized with a single apparatus using just three steps of receiving the
`
`verification token corresponding to the digital content, authenticating the
`
`token, and writing the token into the metadata of the digital content.
`
`The ‘860 patent, on the other hand, requires an API connection to be
`
`established to a secondary apparatus to complete the six claimed steps that
`
`must be performed before access to the digital content is authorized.
`
`
`
`24
`
`EWS-005495
`
`
`
`In claim 1 of the ‘860 patent, for example, the verification token is
`
`received and authenticated. Claim 1 goes on to require “establishing a
`
`connection with the at least one communications console . . . wherein the
`
`API is related to a verified web service, the web service capable of
`
`facilitating a two way data exchange to complete a verification process . . . .”
`
`(Ex. 1001 at 14:51-57.)
`
`The ‘860 patent teaches that the API connection is established on both
`
`the machine and user level. First, the apparatus has been assigned an API
`
`key or ID: “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 also could include an Application
`
`ID.” (Id. at 10:51-56.)
`
`Second, the connection to the web service is made on the user level as
`
`well: “Upon an access request of the digital media, the excelsior enabler
`
`[i.e., first user] interacts with the apparatus . . . to enter membership
`
`credentials in a GUI front-end connected to the API. . . . Once the enabler
`
`successfully sign[s] in to the GUI element then the apparatus will query the
`
`API for at least one electronic identification reference, in this discussion is
`
`the FBID.” (Id. at 11:8-24.)
`
`
`
`25
`
`EWS-005496
`
`
`
`Mastercard’s references do not teach establishing a connection and
`
`requesting and receiving the identification references before authorizing
`
`access to digital content. Mastercard points to Ameerally, where the user is
`
`not logged into her iTunes account and prompted to enter her Apple ID.
`
`(Paper 2 (Petition) at 43-44.) At most, however, the user is establishing a
`
`connection with the verified web service (i.e., iTunes) but then granted
`
`authorized access to the digital content: “If the user is already logged in to
`
`an account with digital media purchase system 100, then processing
`
`continues at step 318. . . . At step 318, the particular digital media content
`
`determined to be associated with the received promotional code is made
`
`accessible to the consumer 312.” (Ex. 1003 at [0041], [0042].)
`
`In other words, assuming Ameerally establishes the connection with
`
`the verified web service when iTunes prompts the user to input her Apple
`
`ID, Ameerally does not use that connection to request and receive the
`
`identification reference, as disclosed in the ‘860 claims.
`
`Mastercard admits this by lumping together the steps of “establishing
`
`the connection,” “requesting the identification reference,” and “receiving the
`
`identification reference” and pointing to the same prior art teachings to meet
`
`these different elements. (Paper 2 at 41-44, 57-58, 60-61, 66.) Simply put, if
`
`the user’s Apple ID is used in Ameerally to establish the connection, that
`
`
`
`26
`
`EWS-005497
`
`
`
`Apple ID cannot then also be
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
