throbber
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-00793
`Patent 8,887,308
`____________________________________________________________
`
`
`PRELIMINARY RESPONSE BY PATENT OWNER WILLIAM
`GRECIA
`
`
`
`
`
`
`
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`INTRODUCTION .......................................................................................... 3
`
`BACKGROUND ............................................................................................ 5
`
`I. The ‘308 Patent ........................................................................................ 6
`
`A. Written Description ............................................................................... 8
`
`B. The ‘308 Patent Claim ......................................................................... 11
`
`II. File History of the ‘308 Patent ............................................................... 13
`
`A. Examiner’s Reasons for Allowance .................................................... 14
`
`B. Apple’s App. No. 12/766,337 ............................................................. 17
`
`III. Mastercard’s Asserted References ......................................................... 18
`
`A. Ameerally ............................................................................................ 18
`
`B. Muller .................................................................................................. 20
`
`IV. Claim Construction ................................................................................ 21
`
`ARGUMENT ................................................................................................ 21
`
`CONCLUSION ............................................................................................. 25
`
`
`
`2
`
`
`
`
`
`

`

`INTRODUCTION
`
`William Grecia owns U.S. Patent No. 8,887,308 (the “‘308 patent”),
`
`which claims “[a] process for transforming a user access request for cloud
`
`digital content into a computer readable authorization object . . . .” (Ex. 1001
`
`(‘308 patent) at 14:31-33.) This process includes the following six steps, all
`
`of which must be performed before the access request is transformed into a
`
`computer readable authorization object that may be cross referenced in later
`
`access requests by a user:
`
`• receiving a digital content access request through an apparatus (first
`
`apparatus), where the request is a write request to a data store and
`
`comprises verification data recognized by the first apparatus as a
`
`verification token; then
`
`• authenticating the token using a verification token database; then
`
`• establishing a connection between the first apparatus and a database
`
`apparatus using an application programmable interface (“API”)
`
`related to a verified web service (second apparatus), wherein
`
`establishing the API connection requires a credential assigned to the
`
`first apparatus and the verified web service completes a verification
`
`process through an exchange of query data that includes a verified
`
`web service account identifier; then
`
`3
`
`

`

`• requesting the verified web service account identifier; then
`
`• receiving the verified web service account identifier; and, lastly,
`
`• creating the computer readable authorization object by writing at least
`
`one of the verification token or the account identifier into the data
`
`store.
`
`The ‘308 patent creates a computer readable authorization object that has the
`
`capacity for future use: “wherein the created computer readable
`
`authorization object . . . is processed by the [first] apparatus . . . using a
`
`cross-referencing action during subsequent user access requests . . . .” (Ex.
`
`1001 (‘308 patent) at 14:31-33.)
`
`The Examiner supported allowance of the ‘308 patent by reasoning
`
`that, although the prior art taught authentication of tokens and writing these
`
`tokens into a data store, no one had yet taught steps 3, 4, and 5—viz.,
`
`“establishing an API communication between the apparatus of (a) and a
`
`database apparatus” and requesting from the apparatus (a) at least one
`
`verified web service account identifier to complete the verification process.
`
`(Ex. 2001 (Notice of Allowance) at 6-7.)
`
`
`
`Mastercard’s asserted prior art—Apple’s iTunes system—is repetitive
`
`of the prior art that the Examiner considered. Indeed, this prior art lacks an
`
`API connection related to a verified web service to complete the verification
`
`4
`
`

`

`process by requesting and receiving a verified web service account
`
`identifier.
`
`In fact, none of Mastercard’s references mentions an API connection.
`
`Rather, Mastercard relies on its expert in 2017 to say, “The iTunes Music
`
`Store necessarily includes an API for interacting with iTunes.” (Ex. 1007
`
`(Alexander Decl.) ¶ 118.) 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 alone an API connection
`
`related to a verified web service, as required by the ‘308 patent claim.
`
`For this and four other reasons discussed below, Grecia respectfully
`
`requests that the Board deny Mastercard’s Petition in its entirety.
`
`
`
`BACKGROUND
`
`This section has four parts. Grecia first describes the ‘308 patent.
`
`Second, he describes pertinent portions of the file history. Third, Grecia
`
`discusses the prior art references that Mastercard asserts against the ‘308
`
`5
`
`

`

`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 ‘308 Patent
`
`Claim 1 sets forth the precise order in which six steps should be
`
`performed to create the computer readable authorization object, an object
`
`that is available for a user’s future access requests.1
`
`First, “receiving an access request for cloud digital content through an
`
`apparatus [i.e., the apparatus of (a)] . . . the access request being a write
`
`request to a data store . . . the access request further comprises verification
`
`data provided by at least one user . . . recognized by the apparatus as a
`
`verification token; then . . . .” (Petition Ex. 1001 (‘308 patent) at 14:34-44.)
`
`Second, “authenticating the verification token of (a) using a database
`
`recognized by the apparatus of (a) as a verification token database; then . . .
`
`.” (Id. at 14:45-47.)
`
`
`1
`See Mformation Techs., Inc. v. Research in Motion Ltd., 764 F.3d
`
`1392, 1398 (Fed. Cir. 2014) (“[A] claim ‘requires an ordering of steps when
`
`the claim language, as a matter of logic or grammar, requires that the steps
`
`be performed in the order written, or the specification directly or implicitly
`
`requires’ an order of steps.”) (internal citation omitted).
`
`6
`
`

`

`Third, “establishing an API communication between the apparatus of
`
`(a) and a database apparatus . . . wherein the API is related to a verified web
`
`service . . . wherein establishing the API communication requires a
`
`credential assigned to the apparatus of (a) . . . wherein the data exchange
`
`session . . . comprises at least one verified web service account identifier;
`
`then . . . .” (Id. at 14:48-62.)
`
`Fourth, “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 . .
`
`.” (Id. at 14:63-66.)
`
`Fifth, “receiving the query data requested in (d) from the API
`
`communication data exchange session of (c); and . . . .” (Id. at 15:1-2.)
`
`Sixth, “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 user access requests . . . .” (Id. at 15:3-
`
`13.)
`
`7
`
`

`

`A. Written Description
`
`The ‘308 patent claims a process that “work[s] as a front-end to
`
`encrypted files as an authorization agent for decrypted access.” (Ex. 1001 at
`
`5:39-40.) Thus, the invention claimed in the ‘308 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:
`
`The ‘308 patent describes the various modules as being distinct and
`
`
`
`assigns an order for each module’s use.
`
`8
`
`

`

`At the front of the method/system/apparatus, “[t]he 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.” (Ex. 1001 at 5:46-51.)
`
`“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
`
`establishes communication with the at least one communication console.”
`
`(Ex. 1001 at 5:57-61.)
`
`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:5-7.) 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:7-9.) “The branding module 112 brands
`
`metadata of the encrypted digital media by writing the membership
`
`9
`
`

`

`verification token and the electronic identification into the metadata.” (Id. at
`
`6:9-12.)
`
`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 gate-keeping function.
`
`The ‘308 patent teaches that the first apparatus (“apparatus of (a)”)
`
`requests and receives the account identifier via an API connection made
`
`possible by an authenticated credential: “[t]he 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
`
`10
`
`

`

`51920566446”
`
`(Id. at 10:51-64.)
`
`B. The ‘308 Patent Claim
`
`Claim 1 of the ‘308 patent is reproduced as follows with annotations
`
`from Figure 1:
`
`[102, 104, 106, 108, 110, 112] A process for
`
`transforming a user access request for cloud digital
`
`content into a computer readable authorization
`
`object, the process for transforming comprising:
`
`a) [102] 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
`
`b) [104] authenticating the verification token of (a)
`
`using a database recognized by the apparatus of (a)
`
`as a verification token database; then
`
`11
`
`

`

`c) [106] 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 web service is 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
`
`d) [108] 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
`
`e) [110] receiving the query data requested in (d)
`
`from the API communication data exchange
`
`session of (c); and
`
`f) [112] creating a computer readable authorization
`
`object by writing into the data store of (a) at least
`
`12
`
`

`

`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 user
`
`access requests to determine one or more of a user
`
`access permission for the cloud digital content.
`
`II.
`
`File History of the ‘308 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 that the Examiner discussed when
`
`stating the reasons for allowance share some of the attributes of the Apple
`
`iTunes system that Mastercard now asserts against the ‘308 patent—namely,
`
`the authentication of a verification token and writing the token into a data
`
`store.
`
`Second, the section briefly discusses another Apple patent application,
`
`for which the grandparent of the ‘308 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 ‘308 patent and
`
`13
`
`

`

`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 ‘308 patent: Baiya
`
`et al. PG Pub. 20110288946, Method and System of Managing Digital
`
`Multimedia Content (“Baiya”); and Chris Wimmer, U.S. Patent 7,526,650,
`
`Personal Identifiers for Protecting Video Content (“Wimmer”). (Ex. 2001.)
`
`In short, the Examiner found that while Baiya and Wimmer disclose certain
`
`of the ‘308 patent limitations, these references lack disclosure of
`
`“transforming a user access request for cloud digital content into a computer
`
`readable authorization object” by establishing a connection with a verified
`
`web service that then requests a verified web service identifier. (Id. at 6-7.)
`
`
`
`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
`
`14
`
`

`

`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]).)
`
`
`
`As the Examiner recognized, Baiya does not suggest “transforming a
`
`user access request for cloud digital content into a computer readable
`
`authorization object” according to the invention claimed in the ‘308 patent
`
`because, for example, Baiya only practices the first and second steps of
`
`claim 1 of the ‘308 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 ‘308 patent as
`
`illustrated in Figure 1 at 102 and 104.
`
`15
`
`

`

`The Examiner also cited Figure 5 of Wimmer as disclosing some of
`
`the limitations of the ‘308 patent. The disclosure corresponding to Figure 5
`
`of Wimmer suggests, for example, the limitations of the first, second, and
`
`sixth steps of claim 1 of the ‘308 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 ‘308 patent as
`
`illustrated in Figure 1 at 102, and 104 (i.e., receiving a write request and
`
`authentication) and 112 (i.e., writing the verification token into the
`
`metadata).
`
`
`
`Again, while Wimmer contained some of the limitations of the ‘308
`
`patent claim, Wimmer was missing “a process for transforming a user
`
`access request for cloud digital content into a computer readable
`
`authorization object with the steps of . . . c) establishing an API
`
`16
`
`

`

`communication between the apparatus of (a) and a database apparatus . . .
`
`wherein the API is related to a verified web service, wherein the verified
`
`web service is part of the database apparatus . . . to complete the
`
`verification process . . . wherein the query data comprises at least one
`
`verified web service account identifier . . . d) requesting the query data, from
`
`the apparatus of (a) . . . wherein the query data request is a request for the
`
`at least one verified web service identifier . . . .” (Ex. 2001 at 6-7 (emphasis
`
`in original).)
`
`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.)
`
`For among other reasons, the claims under examination and the ‘555 patent
`
`17
`
`

`

`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
`
`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
`
`18
`
`

`

`network.” (Ex. 1004 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 data provided by at least one
`
`user) is authenticated and then the user is granted access to the digital
`
`content. “At step 314, the digital media purchase system 100 receives one of
`
`the unique promotional codes.” (Id. 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 a verified web service
`
`account identifier: “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
`
`19
`
`

`

`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.
`
`In other words, Ameerally does not use the connection with the
`
`verified web service to request and receive the verified web service account
`
`identifier.
`
`B. Muller
`
`
`
`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:
`
`[W]hen the decision 506 determines that
`
`authentication was successful, then an encrypted
`
`version of the selected digital media item that has
`
`been purchased is retrieved 510. . . . Then, the
`
`encrypted version of the selected digital media
`
`item is sent 512 to the requestor (client).
`
`(Ex. 1005 at [0061].)
`
`20
`
`

`

`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
`
`Patent Owner has identified five limitations in the ‘308 patent that are
`
`not present in the prior art references that Mastercard asserts in its Petition.
`
`Any one of these five reasons would support denial of the Petition.
`
`First, Mastercard relies on the iTunes Music Store as both the
`
`“verification token database” and “database apparatus,” contrary to the claim
`
`language of the ‘308 patent.
`
`Claim 1 of the ‘308 patent requires as a second step, “authenticating
`
`the verification token of (a) using a database recognized by the apparatus of
`
`(a) as a verification token database . . . .” (Ex. 1001 at 14:45-47.) And next,
`
`the ‘308 patent claim requires, “establishing an API communication between
`
`the apparatus of (a) and . . . a different database from the verification token
`
`database of (b) . . . .” (Id. at 14:48-51.)
`
`The promotional database of Ameerally does not authenticate until the
`
`user is logged into the iTunes Music Store: “The iTunes application is
`
`21
`
`

`

`required to access the iTunes Music Store, through which the song code is
`
`redeemed.” (Petition at 35; see also Ex. 1004 (Ameerally), FIG. 5 (“Gift
`
`certificates, prepaid cards, song codes and allowances must be redeemed
`
`through the iTunes Music Store . . . .”) (emphasis added).) Contrary to the
`
`‘308 patent, however, Mastercard points to the iTunes Music Store as both
`
`the “verification token database” of step (b) and the “database apparatus” of
`
`step (c): “[A]s disclosed in Ameerally and Muller, the client computer and
`
`iTunes media player interface running on the client computer (i.e.,
`
`components comprising apparatus of (a)) establishes an API communication
`
`with the iTunes media server.” (Petition at 34 (emphasis in original).)
`
`Second, the prior art Mastercard asserts fails to even mention API, let
`
`alone “an API communication between the apparatus of (a) and a database
`
`apparatus . . . .” (Id. at 14:48-49.)
`
`Mastercard explains this deficiency as follows: “The ‘308 Patent
`
`acknowledges that the implementation of an ‘Applications Programmable
`
`Interface (API)’ was well known in the art at the time of the patent
`
`application.” (Paper 1 at 34.) That misses the point. Patent Owner claims “an
`
`API communication between the apparatus of (a) and a database apparatus . .
`
`. [that] complete[s] the verification process . . . .” (Id. at 14:48-58.)
`
`Mastercard’s charge is to come forward with a reference disclosing this
`
`22
`
`

`

`limitation or to provide a persuasive rationale for combining references to
`
`meet the limitation. In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)
`
`(“[T]here must be some articulated reasoning with some rational
`
`underpinning to support the legal conclusion of obviousness”).
`
`Mastercard falls far short of this, failing to provide a reference with
`
`even a suggestion of use of an API communication and relying on its expert
`
`to argue: “[t]he iTunes Music Store necessarily includes an API for
`
`interacting with iTunes.” (Ex. 1007 (Alexander Decl.) ¶ 118.)
`
`Third, the asserted prior art references fail to disclose “a credential
`
`assigned to the apparatus of (a) . . . .” (Ex. 1001 at 14:53-55.) At a
`
`fundamental level, Mastercard’s references cannot teach an API credential
`
`assigned to the apparatus of (a), as these references never mention API.
`
`Setting that deficiency aside, though, Mastercard points to the “password
`
`token” taught in Muller to meet the credential limitation. (Petition at 38-39.)
`
`Muller makes clear, however, that the “password token” is assigned to the
`
`user rather than the device (i.e., “apparatus of (a)”): “The password token is
`
`random value (e.g., 128 bit string) that is different for every user. The media
`
`storage server provides the password token to the client as a result of a
`
`successful authentication of the user.” (Ex. 1005 (Muller) at [0055].) In
`
`other words, contrary to the claim language of step (c) of the ‘308 patent, the
`
`23
`
`

`

`“password token” is assigned to the user and provided to the device “as a
`
`result of successful authentication of the user.” (Id.)
`
`Fourth, what Mastercard argues to be the “verified web service
`
`account identifier” is “sent” to the device (i.e., apparatus of (a)) in Muller,
`
`instead of requested from and received by the apparatus of (a), as required in
`
`the ‘308 patent. “[T]he media access information is sent 320. Here, the
`
`media access information is sent from the media commerce server to the
`
`client, namely, the media player operating on the client.” (Ex. 1005 (Muller)
`
`at [0055].) In short, if the media access information is the query data and the
`
`client is the apparatus of (a), as Mastercard argues, Muller never teaches or
`
`suggests that the client requests and then receives the media access
`
`information.
`
`Fifth, the “computer readable authorization object” Mastercard points
`
`to in Muller is good for one access request only, rather than “subsequent
`
`user access requests . . . .” (Ex. 1001 at 15:12-13.) “Once the identified
`
`‘open’ transaction is closed 406, the client is no longer able to download the
`
`digital media content for a purchased digital media item from a media
`
`storage server (FIG. 1A).” (Ex. 1005 (Muller) at [0058].)
`
`24
`
`
`
`
`
`

`

`
`
`CONCLUSION
`
`For the reasons set forth above, Patent Owner respectfully requests
`
`that the Board deny Mastercard’s petition as to the challenged claim.
`
`
`
`Dated: May 22, 2017
`
`Respectfully submitted,
`
`/Isaac Rabicoff/
`
`Isaac Rabicoff (Reg. No. 74,147)
`Rabicoff Law LLC
`73 W Monroe St
`Chicago, IL 60603
`isaac@rabilaw.com
`(773) 669-4590
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`25
`
`
`
`
`
`
`
`

`

`CERTIFICATE OF SERVICE UNDER 37 C.F.R. 42.6 (e)(4)
`
`
`It is hereby certified that on this 22nd day of May, 2017, a copy of the
`foregoing document was served via Electronic Mail upon the following:
`
`
`
`
`
`
`
`
`Joseph R. Lanser, jlanser@seyfarth.com
`Reg. No. 44,860
`SEYFARTH SHAW LLP
`131 S. Dearborn Street
`Chicago, Illinois 60013
`Tel: (312) 460-5895
`
`Brian Michaelis, bmichaelis@seyfarth.com
` Reg. No. 34,221
`SEYFARTH SHAW LLP
`Two Seaport Lane, Suite Three
`Boston, Massachusetts 02210-2028
`Tel: (617) 946-4830
`
`David A. Klein, daklein@seyfarth.com
` Reg. No. 46,835
`SEYFARTH SHAW LLP
`Two Seaport Lane, Suite Three
`Boston, Massachusetts 02210-2028
`Tel: (617) 946-4901
`
`Joseph Walker, jmwalker@seyfarth.com
`Reg. No. 66,798
`SEYFARTH SHAW LLP
`131 S. Dearborn Street
`Chicago, Illinois 60013
`Tel: (312) 460-5267
`
`
`Chicago IP Docket, chiipdocket@seyfarth.com
`
`SEYFARTH SHAW LLP
`
`131 S. Dearborn Street
`
`Chicago, Illinois 60013
`
`
`
`26
`
`

`

`/Isaac Rabicoff/
`
`Isaac Rabicoff
`Reg. No. 74,147
`Counsel for William Grecia
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`27
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket