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