UNITED STATES PATENT AND TRADEMARK
`OFFICE
`
`
`_________________
`_________________
`
`
`
`Before the Patent Trial and Appeal Board
`
`
`
`
`
`DISH NETWORK L.L.C., Petitioner,
`
`
`v.
`
`William Grecia, Patent Owner.
`
`
`_________________
`
`
`U.S. Patent No. 8,887,308
`Filing Date: May 6, 2013
`Issue Date: November 11, 2014
`Title: Digital Cloud Access —PDMAS Part III
`
`
`__________________
`
`
`
`
`
`
`
`Preliminary Response by Patent Owner William Grecia
`
`
`
`
`EWS-005335
`
`Early Warning Services 1029
`IPR of U.S. Pat. No. 8,887,308
`
`
`OFFICE
`
`
`_________________
`_________________
`
`
`
`Before the Patent Trial and Appeal Board
`
`
`
`
`
`DISH NETWORK L.L.C., Petitioner,
`
`
`v.
`
`William Grecia, Patent Owner.
`
`
`_________________
`
`
`U.S. Patent No. 8,887,308
`Filing Date: May 6, 2013
`Issue Date: November 11, 2014
`Title: Digital Cloud Access —PDMAS Part III
`
`
`__________________
`
`
`
`
`
`
`
`Preliminary Response by Patent Owner William Grecia
`
`
`
`
`EWS-005335
`
`Early Warning Services 1029
`IPR of U.S. Pat. No. 8,887,308
`
`
`
`Table of Contents
`
`INTRODUCTION ............................................................... 1
`
`BACKGROUND ................................................................. 1
`
`The ‘308 Patent .................................................................. 2
`
`Tiu .............................................................................. 12
`
`Fetterman ....................................................................... 16
`
`ARGUMENT ................................................................... 17
`
`Claim Construction ............................................................ 17
`
`I. The Board should decline to institute inter partes review because
`
`neither Tiu nor Fetterman teach or suggest transforming a user
`
`access request for cloud digital content into a computer readable
`
`authorization object. ........................................................ 23
`
`A. “Receiving an access request for cloud digital content through an
`
`apparatus . . . the access request being a write request to a data store
`
`. . . 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 . . . .” ........................................ 24
`
`
`
`i
`
`EWS-005336
`
`
`
`B. “Authenticating the verification of (a) using a database
`
`recognized by the apparatus of (a) as a verification token database.”
`
`
`
`26
`
`C. “Wherein establishing the API communication requires a
`
`credential assigned to the apparatus of (a) . . . .” ........................... 28
`
`D. “Requesting . . . from the apparatus of (a) . . . the at least one
`
`verified web service identifier . . . .” ............................................. 29
`
`E. “Receiving the query data requested in (d) from the API
`
`communication data exchange session of (c).” ............................. 29
`
`F. “Creating a computer readable authorization object by writing
`
`into the data store of (a) at least one of: the received verification data
`
`of (a); and the received query data of (e) . . . .” ............................. 30
`
`CONCLUSION ................................................................. 30
`
`
`
`
`
`ii
`
`EWS-005337
`
`
`
`Exhibit List
`
`Exhibit No.
`
`
`Description
`
`2001
`
`2002
`2003
`
`
`
`
`
`
`
`
`
`
`2014-09-19 Notice of Allowance and Fees Due
`(PTOL-37)
`U.S. Pub. No. 2011/0288946 to Baiya et al.
`U.S. 7,526,650 to Wimmer
`
`iii
`
`EWS-005338
`
`
`
`INTRODUCTION
`
`William Grecia is the owner and inventor of U.S. Patent No.
`
`8,887,308 (hereinafter, the “‘308 patent”). The Examiner allowed the
`
`‘308 patent claim over two references that, while teaching some steps of
`
`the ‘308 claim, did not “establish[] an API communication between the
`
`apparatus of (a) and a database apparatus . . . .” (Ex. 2001 (Reasons for
`
`Allowance).) The prior art references did not use an API “related to a
`
`verified web service . . . .” (Id.) They did not use this API connection “to
`
`complete the verification process, wherein the data exchange session . . .
`
`comprises at least one verified web service account identifier . . . .” (Id.)
`
` The Board should decline to institute inter partes review here
`
`because the references DISH Network L.L.C (“DISH”) asserts against
`
`the ‘308 patent claim lack not only an API connection between the
`
`apparatus of (a) and a verified web service (as found by the Examiner),
`
`but these references also neither teach nor suggest a verification token or
`
`account identifier that is transformed into a computer readable
`
`authorization object.
`
`BACKGROUND
`
`In this section, Patent Owner describes the ‘308 patent and the
`
`Examiner’s reason for allowance. This section also sets forth the
`
`
`
`1
`
`EWS-005339
`
`
`
`pertinent teachings of Tiu and Fetterman—the references DISH asserts
`
`as references under 35 U.S.C. § 103.
`
`The ‘308 Patent
`
`
`
`The ‘308 patent claims a single process, six step method, for
`
`transforming a user access request for cloud digital content into a
`
`computer readable authorization object that operates as a permission
`
`token. (Petition Ex. 1001 (‘308 patent) col. 14:31-15:14.)1
`
`Fig. 3 illustrates an example of the process claimed in the ‘308
`
`patent. The elements and processes described with reference to Fig. 3
`
`delineate the distinctions between the claimed invention and the prior
`
`art:
`
`
`1
`
`
`
`
`2
`
`The ‘308 patent has been filed as Exhibit 1001 with the Petition.
`
`EWS-005340
`
`
`
`
`
`“A user posts a branding request via the Kodekey GUI interface 301.”
`
`(Petition Ex. 1001 (‘308 patent) col. 6:66-67.) 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.”
`
`(Petition Ex. 1001 (‘308 patent) col. 7:1-4.) The token is then
`
`
`
`3
`
`EWS-005341
`
`
`
`authenticated: “The Kodekey GUI interface is connected to the database
`
`305 via the internet 304 through the networking card 303. The database
`
`305 is the database used to read/write and store the tokens, also referred
`
`to as the token database.” (Id., 7:7-11.)
`
`Clearly, many prior art systems taught the verification of a token
`
`through a GUI interface, but these next steps are where the invention
`
`claimed in the ‘308 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 ‘308 patent teaches a
`
`process of establishing a new and distinct connection with a verified web
`
`service: “The user is redirected to the APIwebsite.com GUI 307 through
`
`the internet 306.” (Id., 7:11-12.) The account identifier is then requested,
`
`received, and written into the metadata: “The APIwebsite.com is the
`
`GUI to the membership API in which the electronic ID is collected and
`
`sent back to the Kodekey GUI interface 301. . . . The database 309 is the
`
`database connected to the web service membership in which the user’s
`
`electronic ID is queried from.” (Id., 7:12-20.)
`
`The ‘308 patent teaches that the apparatus requests and receives
`
`the account identifier via an API connection made possible by a
`
`credential assigned to the apparatus: “The Facebook API system, as well
`
`
`
`4
`
`EWS-005342
`
`
`
`as others, operates based on an access authentication system called from a
`
`connected apparatus (which is usually an Internet powered desktop or
`
`browser based application) with an API Key, an Application Secret Key
`
`and could also include an Application ID. For example, the Facebook
`
`API Application Keys required to establish a data exchange session with
`
`the connected apparatus might look like:
`
`API Key
`
`37a925fc5ee9b4752af981b9a30e9a73gh
`
`Application Secret
`
`f2a2d92ef395cce88eb0261d4b4gsa782
`
`Application ID
`
`51920566446”
`
`(Petition Ex. 1001 (‘308 patent) col. 10:51-64 (emphasis added).)
`
`In other words, after the user posts a branding request through a
`
`first GUI (i.e., Kodekey GUI 301) and the user’s verification token is
`
`authenticated in a first database (i.e., database 305), the system
`
`establishes a new connection through a second GUI, a verified web
`
`service (i.e., APIwebsite.com GUI 307), through which an account
`
`identifier is requested, received, and written into the metadata (i.e.,
`
`
`
`5
`
`EWS-005343
`
`
`
`product metadata 302). The prior art simply does not teach the use of a
`
`verified web service in the manner claimed in the ‘308 patent.
`
`
`
`The ‘308 patent’s description of the metadata underscores that this
`
`invention “will work as a front-end to encrypted files as an authorization
`
`agent for decrypted access” (id., 5:39-40): “The product metadata 302 is
`
`read/writable metadata associated with the digital media to be acquired.”
`
`(Id., 7:4-5 (emphasis added).) Simply put, the invention claimed in the
`
`‘308 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 account identifier 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 ‘308 patent.
`
`
`
`The ‘308 patent has one claim, reproduced here with annotations
`
`to Figure 3 and pertinent teachings from the specification:
`
`A process for transforming a user access request
`
`for cloud digital content into a computer
`
`readable authorization object, the process for
`
`transforming comprising:
`
`
`
`
`
`6
`
`EWS-005344
`
`
`
`a) [301, 303, 304, and 305] 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) [305] authenticating the verification token of
`
`(a) using a database recognized by the
`
`apparatus of (a) as a verification token
`
`database; then
`
`
`c) [306] establishing an API communication
`
`between the apparatus of (a) and a database
`
`apparatus, the database apparatus being a
`
`different database from the verification token
`
`7
`
`
`
`EWS-005345
`
`
`
`database of (b) [309] 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) [col. 10:51-64], 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) [307; 308; and 309] 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) [307; 308; and 309] receiving the query data
`
`requested in (d) from the API communication
`
`data exchange session of (c); and
`
`
`
`
`
`8
`
`EWS-005346
`
`
`
`f) [301; 302] 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 to
`
`determine one or more of a user access
`
`permission for the cloud digital content.
`
` (Petition Ex. 1001 (‘308 patent) col. 14:31-15:14.)
`
`
`
`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”) (Ex. 2002); and Chris Wimmer, U.S.
`
`Patent 7,526,650, Personal Identifiers for Protecting Video Content
`
`(“Wimmer”) (Ex. 2003). (Ex. 2001.) In short, the Examiner found that
`
`while Baiya and Wimmer disclose certain of the ‘308 patent limitations,
`
`these references lack disclosure of establishing a connection between an
`
`
`
`9
`
`EWS-005347
`
`
`
`apparatus and a verified web service in order to request and receive an
`
`account identifier. (Id.)
`
`Closer examination of the Baiya and Wimmer disclosures
`
`illustrates the novelty and non-obviousness of the ‘308 patent, as
`
`determined by the Examiner.
`
`In Baiya, a user accesses digital media through an interface called
`
`the Content Manager [0022]:
`
`Baiya discloses a process of ‘the management of
`
`digital multimedia content comprises a
`
`computer-implemented digital multimedia
`
`content management system comprising the
`
`following computer executable components: an
`
`upload component that allows a first user to tag
`
`the digital media content with one or more
`
`attributes . . . a grouping component that groups
`
`the digital media content according to the one or
`
`more attributes; a licensing component that
`
`attaches one or more keys to the digital media
`
`content; a security component that encrypts the
`
`digital media content; and a sharing component
`
`that allows one or more second users to access
`
`the digital media content [sic] (Fig. 3-4 and
`
`paragraphs [0008]).
`
`
`
`10
`
`
`
`EWS-005348
`
`
`
`(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]).)
`
`
`
`The Examiner cited, among other things, Figure 5 of Wimmer as
`
`disclosing some of the limitations 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 (U.S. 7,526,650) col. 6:22-28).)
`
`As the Examiner recognized, the disclosure in Baiya and Wimmer
`
`corresponds to, for example, the first, second, and sixth steps of claim 1
`
`of the ‘308 patent as illustrated in Figure 3 at 301, 303, and 305 (i.e.,
`
`receiving a write request and authentication) and 302 (i.e., writing the
`
`verification token into the metadata). The Examiner allowed the ‘308
`
`patent over Baiya and Wimmer, however, because these references
`
`lacked disclosure or teaching of establishing an API connection between
`
`
`
`11
`
`EWS-005349
`
`
`
`the apparatus and the verified web service and requesting and receiving
`
`an account identifier from the apparatus and through the established API
`
`connection. (Ex. 2001 at 6.)
`
`
`
`Tiu
`
`Tiu is a Patent Application Publication titled, “Multimedia
`
`Aggregation in an Online Social Network.” (Petition Ex. 1004 at 1.)
`
`Tiu’s Abstract stresses that a social network (e.g., Friendster) may
`
`exercise greater control over third-party digital content (e.g., Flickr)
`
`published on the social network’s user pages when this invention is used:
`
`Multimedia content is featured on user pages of
`
`an online social network using embed codes that
`
`are generated using a configuration file
`
`associated with the source ID for the
`
`multimedia content and a content ID for the
`
`multimedia content. The configuration file, the
`
`source ID and the content ID are stored locally
`
`by the online social network so that any changes
`
`to the embed codes can be made by changing
`
`the configuration file associated with the source
`
`and regenerating the embed codes. By managing
`
`multimedia content in this manner, greater
`
`control may be exercised by the online social
`
`network over the multimedia content that are
`
`featured on its user pages.
`
`12
`
`
`
`EWS-005350
`
`
`
`(Id.) Taking Petitioner’s example of Friendster as the social network and
`
`Flickr as the third-party content provider, Tiu offers Friendster more
`
`control over Flickr photographs posted on Friendster user pages because
`
`“[t]he configuration file, the source ID and the content ID are stored
`
`locally by the online social network. . . .” (Id.) Friendster has control
`
`because “any changes to the embed codes can be made by changing the
`
`configuration file associated with the source and regenerating the embed
`
`codes.” (Id.)
`
`
`
`According to Tiu, social networks such as Friendster may receive
`
`content from Flickr and other external sites through an application
`
`server: “The application server 251 is further configured to receive data
`
`feeds, e.g., RSS feeds, from a third party server 280 through an
`
`application programming interface (API) 290 that third parties may use
`
`to send data to the application server 251 for storage in one of the
`
`databases managed by the application server 251.” (Petition Ex. 1004
`
`(Tiu) [0025].) For example, “the content of the user’s pictures that is
`
`displayed in section 330 is supplied from an external web site 362 (e.g.,
`
`Flickr) using an RSS feed . . . .” (Id. [0028].)
`
`
`
`“On a global basis, whenever an RSS feed reaches its maximum
`
`lifetime, a query is issued to the external web site for the latest
`
`
`
`13
`
`EWS-005351
`
`
`
`information. The query that is issued to an external web site for content
`
`associated with a user includes the user ID and password of that user as
`
`proof that access to the user’s account maintained by the external web
`
`site is authorized.” (Petition Ex. 1004 (Tiu) [0029-30].) Importantly, Tiu
`
`states that Tiu keeps the query “hidden” at the user level because the
`
`query contains the confidential username and password for entry into the
`
`Flickr account: “The issued query is kept hidden at the user level and
`
`preferably encoded or encrypted so that the user ID and password
`
`contained in the query can be kept confidential.” (Id. [0030].)
`
`
`
`Tiu goes onto describe what is at the user level: “The direct
`
`streaming from the external video sites 451, 452, 453 is enabled using
`
`embed codes . . . .” (Petition Ex. 1004 (Tiu) [0031].) “[E]mbed codes for
`
`video files are generated from a source ID (which identifies the externl
`
`source of the video file) and a content ID (which is an identifier of the
`
`video file used by the external source) using configuration files . . . .” (Id.
`
`[0033].)
`
`
`
`Tiu describes how third party content is displayed on a social
`
`network user’s page. The user selects a video to view on a third party site
`
`and “[t]he user’s display includes a hyperlink ‘Post to Friendster.’”
`
`(Petition Ex. 1004 (Tiu) [0035].) “[T]he user is prompted in step 516 for
`
`
`
`14
`
`EWS-005352
`
`
`
`user ID and password corresponding to the user’s account at the online
`
`social network. Upon submission of this information, the external video
`
`site transmits this information along with the particulars of the video file,
`
`such as the source ID . . . and the content ID . . . to the social network . .
`
`. .” (Id.)
`
`The user’s ID and password for the third party website (or
`
`authentication thereof) are not included within this transmission from the
`
`external site to the social network for two reasons. First, “The user ID
`
`and password are provided by the user when the user sets up his or her
`
`landing page to retrieve content from external web sites through RSS
`
`feeds.” (Petition Ex. 1004 (Tiu) [0030].) In other words, Tiu teaches that
`
`a user establishes the connection between, for example, Friendster and
`
`Flickr at the outset of setting up a Friendster landing page by providing
`
`the user ID and password for the Flickr account. Second, the external
`
`site’s transmission of content to the social network does not include the
`
`user ID and password because those are “kept hidden at the user level . .
`
`. .” (Id.)
`
`If the user’s Friendster ID and password are authenticated, the
`
`social network stores the source ID and content ID. (Petition Ex. 1004
`
`(Tiu) [0037].) Each of the source ID and the content ID are used to
`
`
`
`15
`
`EWS-005353
`
`
`
`generate the embed code. (Id.) The external site user ID and password,
`
`on the other hand, are not disclosed by Tiu as being used to generate the
`
`embed code. This follows from Tiu’s teaching that the external site does
`
`not include the user ID and password in its transmission to the social
`
`network (id. [0035]) because the social network already has them and, in
`
`any event, keeps them “hidden at the user level . . . .” (Id. [0030].)
`
`Fetterman
`
`
`
`
`
`Fetterman is a Patent Application Publication entitled, “Sytems
`
`and Methods for Network Authentication.” (Petition Ex. 1006 at 1.) The
`
`Abstract provides in pertinent part that Fetterman teaches “the
`
`application program interface further configured to receive the generated
`
`authentication code and allow an application to communicate digital
`
`data with a web-based social network.” (Id.) In other words, the
`
`application program interface (“API”) facilitates communication
`
`between an application and a social network—not a communication
`
`between a user’s computer and the social network as Petitioner suggests.
`
`(Petition at 31-32; see also id. Ex. 1011 (Goldberg Decl.) ¶ 73.)
`
`
`
`Fetterman teaches that a social network such as Facebook assigns
`
`API keys to the vendor of the third-party application (rather than the
`
`user’s computer): “api__key Uniquely assigned to the vendor, and
`
`
`
`16
`
`EWS-005354
`
`
`
`identifiers, among other things, the list of acceptable source IPS for this
`
`call.” (Petition Ex. 1006, Fig. 2.) Fetterman again teaches that the social
`
`network API is assigned to the vendor of the application, not the user’s
`
`computer:
`
`[T]he application program interface 105 is a web
`
`service that may provide the third-party
`application 115 access to some or all of the
`
`information found in the distributed database
`135 and/or the volatile cache memory 130. For
`
`example, the third-party application 115, such as
`
`the third-party application for the generation of
`
`a birthday card, may access a distributed
`
`database and/or volatile cache memory
`
`associated with a social network through an
`
`application program interface for the social
`
`network.
`(Id. [0023].)
`
`
`
`ARGUMENT
`
`Claim Construction
`
`DISH’s construction of “recognized” is in error. The error is
`
`material, as the Board could decline to institute inter partes review based
`
`on DISH’s erroneous construction. See, e.g., Vivid Techs., Inc. v. Am Sci. &
`
`Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (“[O]nly those terms need
`
`
`
`17
`
`EWS-005355
`
`
`
`be construed that are in controversy, and only to the extent necessary to
`
`resolve the controversy.”).
`
`“Recognize” connotes either pre-established knowledge of
`
`something: “to know or remember (someone or something) because of
`
`previous knowledge or experience.” www.merriam-
`
`webster.com/dictionary/recognize. Or, “recognize” connotes
`
`acknowledging something, whether based on pre-established knowledge
`
`or not: “to accept or be aware that (something) is true or exists.” Id.
`
`DISH argues that “recognized” need not imply pre-determined
`
`knowledge: “identifying, assuming, acting upon, or acknowledging a
`
`characteristic of data or a database.” (Petition at 20.)
`
`For example, to meet the ‘308 patent’s limitation “wherein the
`
`verification data is recognized by the apparatus as a verification token . . .
`
`[,]” (id. Ex. 1001 (‘308 patent) col. 14:43-44 (emphasis added)), DISH
`
`argues that Tiu teaches verification data recognized by the apparatus of
`
`(a) as a verification token when a user shares her Flickr user ID and
`
`password with Friendster. (Id. at 42.) The Flickr user ID and password,
`
`DISH maintains, are “recognized” because they are “authenticated”:
`
`“Because the apparatus, or user device, prompts the user for, or accepts,
`
`the verification data, and then acts upon that data by trying to
`
`
`
`18
`
`EWS-005356
`
`
`
`authenticate it in the next step ((b) [B1]), the apparatus ‘recognizes’ the
`
`verification data.” (Id. at 42.) According to DISH, the apparatus of (a)
`
`had no prior knowledge of the verification token.
`
`To meet the ‘308 patent’s limitation that the verification token be
`
`authenticated “using a database recognized by the apparatus of (a) as a
`
`verification token database . . . [,]”(Petition, Ex. 1001 (‘308 patent) col.
`
`14:43-44 (emphasis added)), DISH argues that Tiu obviously shows that
`
`the Flickr database authenticates the user ID and password and thus “the
`
`user’s device (‘apparatus of (a)’) ‘recognizes,’ i.e., identifies or
`
`acknowledges, database 250, as the claimed ‘verification token
`
`database.’” (Id. at 45.) Again, identify or acknowledge is enough to
`
`“recognize.” According to DISH, the apparatus of (a) does not
`
`“recognize” based on pre-determined data associated with the apparatus
`
`of (a).
`
`DISH argues that Fetterman discloses “apparatus assigned
`
`credentials . . . recognized as a permission to conduct a data exchange
`
`session between the apparatus of (a) and the database apparatus . . .”
`
`[,]”(Petition, Ex. 1001 (‘308 patent) col. 14:55-58 (emphasis added))
`
`because Fetterman’s credentials are “acted upon.” (Petition at 51-52.)
`
`
`
`19
`
`EWS-005357
`
`
`
`Finally, DISH argues that “the created computer readable
`
`authorization object is recognized by the apparatus of (a) as user access
`
`rights associated to the cloud digital content . . .” (Petition, Ex. 1001
`
`(‘308 patent) col. 15:7-9 (emphasis added)) because “the web browser of
`
`the apparatus recognizes, i.e., identifies or acts upon, the computer
`
`readable authorization object . . . .” (Id. at 64.)
`
`The claim language and the specification demonstrate that
`
`“recognized” means “to know because of previous knowledge or
`
`experience.” The apparatus of (a) receives the access request that
`
`“comprises verification data provided by at least one user, wherein the
`
`verification data is recognized by the apparatus as a verification token . . .
`
`.” (Petition, Ex. 1001 (‘308 patent) col. 14:42-44 (emphasis added).)
`
`That the verification data is “recognized” by the apparatus of (a)
`
`as a verification token cannot simply mean that data is “acted upon” or
`
`“authenticated,” as DISH argues as indicated above. The specification of
`
`the ‘308 patent teaches that the “digital media assets used in this system
`
`are encrypted . . . as part of the apparatus or as part of a connection usually
`
`an Internet server.” (Petition, Ex. 1001 (‘308 patent) col. 5:34-38
`
`(emphasis added).) The specification further teaches that the “branding
`
`request is a read or write request of metadata of the encrypted digital
`
`
`
`20
`
`EWS-005358
`
`
`
`media and includes a membership verification token corresponding to the
`
`digital media.” (Id., col. 5:48-51 (emphasis added).) “According to an
`
`embodiment of the present invention, the membership verification token
`
`is a kodekey. The kodekey is a unique serial number assigned to the encrypted
`
`digital media.” (Id., col. 6:38-40 (emphasis added).)
`
`Thus, the claim language and specification demonstrate that the
`
`digital content is part of the apparatus of (a) (id., col. 5:34-38) and the
`
`verification token is assigned to the digital content. (Id., cols. 5:48-51 &
`
`6:38-40.) The verification data is “recognized” by the apparatus of (a) as
`
`a verification token because the apparatus knows the token has been
`
`assigned to the digital content subject of the access request.
`
`The verification token is authenticated by a database “recognized
`
`by the apparatus of (a) as a verification token database . . . .” (Petition,
`
`Ex. 1001 (‘308 patent) col. 14:45-47 (emphasis added).) DISH’s use of
`
`“recognized” meaning “acted upon” cannot be correct in light of the
`
`claim language itself, for “recognized” and “authenticated” are argued to
`
`have the same meaning. (Petition at 42 (“then acts upon that data by
`
`trying to authenticate it in the next step”).)
`
`The credential assigned to the apparatus of (a) is “recognized as a
`
`permission to conduct a data exchange session . . . .” (Petition, Ex. 1001
`
`
`
`21
`
`EWS-005359
`
`
`
`(‘308 patent) col. 14:45-47 (emphasis added).) Such recognition is based
`
`on the apparatus of (a)’s predetermined knowledge of the credential and
`
`what the credential is for: “The collective API keys are usually
`
`embedded in the source code of the apparatus . . . and could be included
`
`in the encrypted digital media metadata and inserted on-the-fly into calls
`
`made to the API from the connected apparatus. This allows dynamic
`
`API connection of the apparatus using keys issued to individual content
`
`providers . . . .” (Id., col. 10:65-11:4.)
`
`The “authorization object” is “recognized by the apparatus of (a) as
`
`user access rights associated to the cloud digital content . . . .” (Petition,
`
`Ex. 1001 (‘308 patent) col. 15:7-9 (emphasis added).) Such recognition at
`
`the bottom of claim 1 is founded upon the entire “process for
`
`transforming a user access request for cloud digital content into a
`
`computer readable authorization object . . . .” (Id., col. 14:31-33.)
`
`Indeed, the apparatus of (a) received what it recognized as a verification
`
`token that had been assigned to the digital content. (Id., cols. 5:48-51 &
`
`6:38-40.) Once the verification token was authenticated, the apparatus of
`
`(a) established a connection with a verified web service that it knew was
`
`made possible through the credential that had been assigned to the
`
`apparatus of (a). (Id., col. 10:65-11:4.) It was then the verification token
`
`
`
`22
`
`EWS-005360
`
`
`
`and the account identifier that the apparatus of (a) used to create the
`
`authorization object. (Id., col. 15:3-6.)
`
`Recognition in claim 1 of the ‘308 patent is all founded on pre-
`
`determined data that is received, authenticated, requested, received, and
`
`ultimately transformed. DISH’s Petition misses this essential point and
`
`its proposed construction of “recognized” should be rejected.
`
`I.
`
`
`
`
`The Board should decline to institute inter partes review because
`neither Tiu nor Fetterman teach or suggest transforming a user
`access request for cloud digital content into a computer readable
`authorization object.
`
`DISH’s comparison of Tiu and Fetterman to the ‘308 patent falls
`
`apart at the very start when DISH points to the user’s device as the
`
`apparatus of (a). (Petition at 36 (“Broadly understood, this claim element
`
`would be met by receipt at the user’s device of a request for the digital
`
`content.”).) The user device does not run the Friendster and Flickr
`
`servers, and yet it is these servers that DISH continually points to as
`
`disclosing the functions performed by the apparatus of (a). (See, e.g., id.
`
`Ex. 1011 (Goldberg Decl.) ¶ 99.)
`
`
`
`DISH’s comparison falters at each step of the ‘308 patent’s
`
`process:
`
`
`
`23
`
`EWS-005361
`
`
`
`A. “Receiving an access request for cloud digital content
`through an apparatus . . . the access request being a write
`request to a data store . . . 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 . . . .”
`
`
`DISH argues that an access request for cloud digital content is
`
`
`
`disclosed in Tiu when an individual uses his computer to tie third-party
`
`photos or videos to his social network’s landing page. (Petition at 37.)
`
`DISH asserts that this access request is a write request, as the content ID
`
`and source ID of the media is written to a database at the social network.
`
`(Id. at 38.) “Alternatively and additionally . . . the EMBED code written
`
`to the apparatus as part of the HTML page . . . will reside in the memory
`
`or storage of the user’s device . . . .” (Id. at 39.)
`
`
`
`DISH points to the user device as the “apparatus of (a),” yet the
`
`user device does not receive the write request as claimed in the ‘308
`
`patent. If the access request is to write the content ID and source ID to
`
`the data store (Petition at 38), then “the particulars of the video file are
`
`stored in the multimedia content database of the online social network . .
`
`. .” (Ex. 1004 (Tiu) [036].) The social network, not the user, receives the
`
`write request.
`
`
`
`24
`
`EWS-005362
`
`
`
`DISH says that “alternatively and additionally” the
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
