throbber
Atty Docket No. FABO-028/00US
`309101-2070
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`FACEBOOK, INC.
`Petitioner
`
`v.
`
`EVOLUTIONARY INTELLIGENCE, LLC
`Patent Owner
`
`
`
`Case IPR2014-00093
`U.S. Patent No. 7,010,536
`
`
`
`FACEBOOK REQUEST FOR RECONSIDERATION
`UNDER 37 C.F.R. § 42.71(c)
`
`
`
`
`
`
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`INTRODUCTION .......................................................................................... 1
`I.
`LEGAL STANDARDS .................................................................................. 2
`II.
`III. ARGUMENT .................................................................................................. 3
`A.
`The Petition Established that Claim 15 Is Anticipated by
`Cooper (Petition Ground 2) .................................................................. 3
`1.
`The Petition Established that the Real Key Is a “Register” ....... 5
`2.
`The Petition Established that the Real Key “Forms Part
`of” the File Management Program “Container” ........................ 7
`The Petition Established that a Software Product File Is a
`“Container” that Is “Added” to the File Management
`Program “Container” ................................................................. 8
`The Petition Established that the Real Key “Controls”
`Whether A Software Product File Container Is Added to
`the File Management Program Container ................................ 15
`The Petition Established that Claim 16 Is Obvious over Cooper
`in View of Fortune and Veditz (Petition Ground 3) .......................... 17
`IV. CONCLUSION ............................................................................................. 17
`
`3.
`
`4.
`
`B.
`
`
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`I.
`
`
`INTRODUCTION
`
`On October 23, 2013, Facebook, Inc. (“the Petitioner”) filed a petition
`
`requesting inter partes review (“IPR”) of U.S. Patent No. 7,010,536, seeking a
`
`narrow review of only claims 15 and 16 (“the ’536 patent”) based on three grounds
`
`of unpatentability:
`
`Ground Claims
`
`Basis for Challenge
`
`1
`
`2
`
`3
`
`15 & 16 Anticipated by Zhang under 35 U.S.C. § 102(e)
`
`15
`
`16
`
`Anticipated by Cooper under 35 U.S.C. § 102(e)
`
`Obvious over Cooper in view of Fortune and Veditz under 35
`U.S.C. § 103(a)
`
`
`(Paper No. 20 (“Petition”) at 4; see also Paper No. 1.)
`
`
`
`On April 28, 2014, the Board issued a decision declining to institute IPR
`
`based on any of these grounds. (Paper No. 12 (“Decision”).) The Petitioner
`
`respectfully seeks reconsideration of that decision as to Grounds 2 and 3. As
`
`explained in detail below, the Board’s decision to not institute IPR based on those
`
`grounds was based on clearly erroneous factual findings as to the Cooper
`
`reference, and the application of that reference under the broadest reasonable
`
`constructions adopted by the Board. The Petitioner accordingly respectfully
`
`requests that the Board find that its Petition has established a reasonable likelihood
`
`1
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`that the Petitioner will prevail in showing that claims 15 and 16 are unpatentable
`
`based on Grounds 2 and 3.
`
`
`
`This request
`
`is authorized under 37 C.F.R. § 42.71(c), and prior
`
`authorization of the Board is not required for filing of such a request. 37 C.F.R.
`
`§ 42.71(d). This request is timely because it was filed within 30 days of the
`
`Board’s decision. 37 C.F.R. § 42.71(d)(2).
`
`II. LEGAL STANDARDS
`
`“When rehearing a decision on petition, a panel will review the decision for
`
`an abuse of discretion.” 37 C.F.R. §42.71(c). An abuse of discretion “occurs when
`
`a court misunderstands or misapplies the relevant law or makes clearly erroneous
`
`findings of fact.” Renda Marine, Inc. v. U.S., 509 F.3d 1372, 1379 (Fed. Cir. 2007)
`
`(quoting PPG Indus., Inc. v. Celanese Polymer Specialties Co., 840 F.2d 1565,
`
`1572 (Fed. Cir. 1988). “A finding is clearly erroneous when, despite some
`
`supporting evidence, ‘the reviewing court on the entire evidence is left with the
`
`definite and firm conviction that a mistake has been committed.’” Forest Labs.,
`
`Inc. v. Abbott Labs., 339 F. 3d 1324, 1328 (Fed. Cir. 2003) (quoting United States
`
`v. United States Gypsum Co., 333 U.S. 364, 395 (1948)).
`
`2
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`III. ARGUMENT
`A. The Petition Established that Claim 15 Is Anticipated by Cooper
`(Petition Ground 2)
`
`
`
`As explained in the Petition, Cooper “describes techniques for ‘temporarily
`
`encrypting and securing access to software objects.’” (Petition at 28 (quoting
`
`Cooper, 1:36-39).) In particular, Cooper “describes a technique for allowing
`
`companies to promote computer software products by distributing them on a “try-
`
`before-buying’ basis.” (Petition at 28.) A software vendor encrypts the software
`
`files distributed to a prospective customer, and a “file management program”
`
`running on the customer’s computer is responsible for managing and controlling
`
`access to the encrypted software. (Petition at 28-29 (citing Cooper, 8:22-38).)
`
`
`
`When a user attempts to access an encrypted software product file, the file
`
`management program generates and validates a decryption key referred to as a
`
`“real key” to determine whether to permit access. (Petition at 41-42 (citing Cooper,
`
`16:9-46, 18:10-43).) If the real key is valid, the encrypted software product file “is
`
`applied as an input” to the decryption engine of the file management program so
`
`that the product can be used. (Cooper, 16:24-26 (“Before real key 421 is utilized to
`
`decrypt encrypted software products . . . it is tested to determine its validity.”),
`
`16:41-46 (“The encrypted software object 437 is applied as an input to decryption
`
`engine 439.”); see also Petition at 41 (citing Cooper, 18:10-43 (“[T]he TSR reads
`
`and decrypts this data before passing it back to the application”), 16:9-46).)
`3
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`
`The Decision identifies four reasons for concluding that the Petition failed to
`
`establish a reasonable likelihood that Cooper anticipates claim 15. All four of those
`
`reasons relate to a single limitation, present in both claims 15 and 16, that requires
`
`“at least one acquire register for controlling whether the container adds a register
`
`from other containers or adds a container from other containers when interacting
`
`with them.” The four reasons are listed below:
`
`1.
`
`2.
`
`3.
`
`4.
`
`“Cooper is silent as to whether the ‘real key’ is a ‘register,’
`much less an ‘acquire register,’ associated with the ‘file
`management program’ container within the meaning of claim
`15.”
`
`“Cooper . . . is silent as to which ‘container’ includes the ‘real
`key’ as a ‘register.’”
`
`“[W]e are not persuaded that once the ‘real key’ is used to
`decrypt software, the decrypted software, as a ‘register’ or
`‘container,’ is added to the file management program.”
`
`“Although Cooper discloses that the ‘real key’ is used for
`encryption/decryption, we are unpersuaded that the ‘real key’
`controls adding a ‘container’ or ‘register’
`to
`the file
`management program.”
`
`(Decision at 17-18.)
`
`4
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`
`As explained below, the Board’s reasons were based on clearly erroneous
`
`findings of fact as to the Cooper reference and how the Cooper reference maps to
`
`the claims as construed by the Board. Each reason is addressed in turn below.
`
`The Petition Established that the Real Key Is a “Register”
`
`1.
`The first reason identified by the Board is that “Cooper is silent as to
`
`
`
`whether the ‘real key’ is a ‘register,’ much less an ‘acquire register,’ associated
`
`with the ‘file management program’ container within the meaning of claim 15.”
`
`(Decision at 17 (underlining added).) Because the Board construed the term
`
`“register” to mean “value or code associated with a container” (Decision at 10
`
`(underlining added)), this reason concerns whether the real key qualifies as a
`
`“register.” As discussed below, because the real key is both (1) a “value” and (2)
`
`“associated with a container,” the Board’s conclusion that the real key is not a
`
`“register” was clearly erroneous.
`
`
`
`First, the real key is certainly a “value.” The term “register,” under its
`
`broadest reasonable construction as adopted by the Board, encompasses a wide
`
`range of information. As explained above, Cooper explains that the real key is
`
`information generated by the file management program from a number of values
`
`including a product key, customer key and a machine identification value. (Cooper,
`
`16:19-23, 18:27-30, 3:7-9, 8:2-6; see also Petition at 41-42 (citing Cooper, 16:9-
`
`46, 18:10-43).) After the real key is generated, its value is evaluated and if valid,
`
`5
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`used for decryption operations. (Cooper, 16:24-27, 16:39-46, 18:30-39.) Thus, to
`
`the extent that the Board concluded that the real key is not a “value,” it erred.
`
`
`
`Second, the real key is “associated with” the container recited in claim 15
`
`(i.e., the file management program in Cooper). In particular, Cooper explains that
`
`“FIGS. 19, 20, 21, 22, and 23 depict operations of the file management program.”
`
`(Cooper, 16:5-8 (underlining added).) These figures, and their associated
`
`descriptions, clearly show that the file management program container (1)
`
`generates the real key; (2) validates the real key; and (3) uses the real key to
`
`perform decryption. (Cooper, 16:19-23 (“Decryption engine 413 provides as an
`
`output real key 421.”), 16:5-8 & Fig. 23 (showing that decryption engine 413 is
`
`part of the file management program), 16:24-27 (“Before real key 421 is utilized to
`
`decrypt software products . . . it is tested to determine its validity.”), 16:39-46
`
`(“The validated real key 441 is also supplied as an input to decryption engine
`
`439.”); see also Petition at 41-42 (citing Cooper, 18:10-43, 16:9-46).) As
`
`confirmed by
`
`the
`
`foregoing disclosures, Cooper discloses
`
`logical and
`
`programmatic relationships between the file management program container and
`
`the real key. The “real key” is therefore “associated with” the file management
`
`program. Thus, the Board clearly erred to the extent that it concluded that the real
`
`key is not a register associated with the container of claim 15.
`
`6
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`2.
`
`The Petition Established that the Real Key “Forms Part of”
`the File Management Program “Container”
`
`
`
`
`
`The second reason identified by the Board is that “Cooper . . . is silent as to
`
`which ‘container’ includes the ‘real key’ as a ‘register.’” (Decision at 18.) As
`
`explained in the preceding section, the “real key” register is “associated with” the
`
`file management program container. To the extent the Board’s statement above
`
`reflects a separate conclusion that the “real key” does not “form part of” the file
`
`management program, it erred.
`
`
`
`Claims 15 and 16 do not specify any particular way in which the acquire
`
`register must be stored to be part of the container. These claims merely recite “a
`
`plurality of registers, the plurality of registers forming part of the container,”
`
`including the acquire register. The claims under their broadest reasonable
`
`construction do not mandate a particular way the registers and container must be
`
`arranged in physical memory or storage for the registers to “form[] part of the
`
`container.” They do not require, for example, that the registers and container be
`
`stored in contiguous or connected blocks of memory.
`
`
`
`This is confirmed by the broadest reasonable construction of “container”
`
`adopted by the Board, which merely requires “a logically defined data enclosure”
`
`(Decision at 9 (underlining added)). The Board explained that the term “logically
`
`defined” under its broadest reasonable construction requires nothing more than
`
`7
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`“contained within.” (Decision at 9.) Cooper amply discloses that the “real key”
`
`register is “contained within” a “logically defined data enclosure” (i.e., the file
`
`management program container), and forms part of it. As summarized in the
`
`preceding section and in the Petition, the file management program (1) generates
`
`the real key; (2) validates the real key; and (3) uses the real key to perform
`
`decryption. (E.g., Cooper, 16:5-8 (“FIGS. 19, 20, 21, 22, and 23 depict operations
`
`of the file management program.” (underlining added)).) Although Cooper does
`
`not disclose that the real key is stored in physical memory that is contiguous to
`
`memory storing other aspects of the file management program, the claims do not
`
`require it (though certainly the real key value would reside in memory accessed
`
`and controlled by the executing file management program). Rather, the above-
`
`described logical and programmatic relationships between the “real key” acquire
`
`register and the “file management program” container more than satisfy the
`
`requirement that the acquire register be “contained within” and therefore “forms
`
`part of” the container.
`
`
`
`3.
`
`The Petition Established that a Software Product File Is a
`“Container” that Is “Added” to the File Management
`Program “Container”
`
`
`
`As to the third reason identified by the Board, the Decision states: “[W]e are
`
`not persuaded that once the ‘real key’ is used to decrypt software, the decrypted
`
`8
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`software, as a ‘register’ or ‘container,’ is added to the file management program.”
`
`(Decision at 18.) This conclusion is based on a clearly erroneous factual finding.
`
`
`
`To begin with, the Decision appears to be based on a misunderstanding of
`
`the Petition. The Petition did not identify the “decrypted software” as the other
`
`“container” added to the file management program container. The Petition instead
`
`identified the encrypted software program by arguing that:
`
`When a user attempts to access an encrypted software product file, the
`file management program uses the ‘real key’ to determine whether
`access will be permitted. . . . The ‘real key’ accordingly qualifies as an
`‘acquire register’ because it is used to control whether the container
`(e.g., the file management program) will add a container (e.g., a
`software product file) from other containers (e.g., the group of
`software product files on disk) . . . .”
`
`(Petition at 41 (underlining added).) Thus, the Petition specifically pointed to the
`
`software product file stored on disk—i.e., the encrypted software—as the
`
`“container added to the file management program.”1 With the proper “container”
`
`identified, an explanation as to how that container is “added” is straightforward.
`
`
`
` 1
`
` Figure 25 of Cooper also refers to “side files.” The “side files” are not decrypted
`
`versions of the encrypted software product files. They represent a portion of the
`
`original content of the encrypted file that had to be removed in order to
`
`9
`
`
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`
`As explained in the Petition, the file management program reads the
`
`encrypted software product file from disk and decrypts it. (Petition at 41 (citing
`
`Cooper, 18:10-43, 16:9-46); see also id. at 42 (quoting Cooper, 18:10-43 (“When
`
`the application reads the data from the encrypted file, the TSR reads and decrypts
`
`this data before passing it back to the application.”)).) In particular, Figure 23 of
`
`Cooper—which as explained above, describes an operation of the file management
`
`program (see Cooper, 16:5-8)—clearly depicts the addition of the encrypted
`
`software product file (437) to the file management program container (represented
`
`below by decryption engine 439):
`
`
`
`accommodate the encryption header added by the system of Cooper. (See Cooper,
`
`17:31-35 (“Each encrypted software product has associated with it a side file which
`
`contains the front portion of the file which has been displaced to accommodate
`
`encryption header 451 without altering the size of the file, and without altering the file
`
`10
`
`name. ”).)
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`
`
`Cooper, explaining the above figure, states that “[t]he encrypted software object
`
`437 is applied as an input to the decryption engine 439.” (Cooper, 16:42-44, 16:5-8
`
`& Fig. 23 (showing that decryption engine 413 is part of the file management
`
`program); see also Cooper, 8:32-34 (“Once the trial mode of operation key exists,
`
`an encrypted application can only be run if it is initiated by the file management
`
`program.”); Petition at 39, 41 (citing Cooper, 8:32-38, 16:9-46).) Because the
`
`encrypted software product file is input into the file management program
`
`container, it is “added” to that container.
`
`
`
`Moreover, Cooper discloses this limitation even if the decrypted software
`
`product file is mapped as the “other container.” This is because the file
`
`management program, after decryption is completed, controls and executes the
`
`software in the now decrypted file:
`
`11
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`the encrypted
`then kicks off
`The file management program
`application. The code which is resident in the operating system of the
`user-controlled data processing system maintains control over the
`operating system. It monitors the use of the trial mode of operation
`keys to allow files to be decrypted and loaded into memory, but
`prevents the encrypted files from being decrypted and copied to
`media.
`
`(Cooper, 8:43-47 (underlining added); see also Petition at 39-40.) Cooper makes
`
`clear that the code that is performing the decryption functions is the TSR portion of
`
`the file management program. (Cooper, 8:22-28.) Thus, the decrypted software
`
`product file separately qualifies as an “added” container for purposes of claim 15.
`
`
`
`These conclusions are consistent with the broadest reasonable constructions
`
`as adopted by the Board. In particular, claims 15 and 16 do not specify or require a
`
`specific way in which a container (or register) must be “added” to a container.
`
`Certainly there can be no requirement of physically adding a container in light of
`
`the Board’s construction of “container” as simply “a logically defined data
`
`enclosure” (Decision at 9 (underlining added)). The “adding” step is accomplished
`
`in Cooper when an encrypted software product file is selected and input into the
`
`file management program container for decryption.
`
`
`
`As further explained in the Petition, the encrypted software product file
`
`container is added “from other containers” as required by claims 15 and 16. More
`
`12
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`specifically, Cooper explains that the encrypted software products are stored in a
`
`plurality of directories and files on the computer, as shown in Figure 25 below:
`
`
`
`(Cooper, Fig. 25, 17:26-31 (“Each of these files is representative of a directory
`
`name of a particular encrypted software product.”); see also Petition at 41.) Cooper
`
`further explains that the encrypted software files are logically organized in a
`
`hierarchical directory structure. (Cooper, Fig. 25, 17:26-31 (“Each of these files is
`
`representative of a directory name of a particular encrypted software product.”).)
`
`Cooper therefore satisfies this limitation because the file management program
`
`adds the selected software product from the directory in which the encrypted
`
`software product resides. (See Petition at 41.) Selecting one encrypted software
`
`product from among the other products is sufficient to satisfy the “from other
`
`containers” limitation under its broadest reasonable construction.
`
`13
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`
`Lastly, although it is not clear from the Decision, to the extent that the Board
`
`suggested that the encrypted software product file and/or the file management
`
`program are not “containers,” any such suggestion would constitute clear error. In
`
`particular, as discussed previously, the Board broadly construed the term
`
`“container” as “a logically defined data enclosure which encapsulates any element
`
`or digital segment (text, graphic, photograph, audio, video, or other), or set of
`
`digital elements.” (Decision at 9.) The Board’s analysis of the ’536 patent makes
`
`clear that this definition under its broadest reasonable construction is expansive.
`
`(Decision at 8 (“The ’536 patent states that a container . . . ‘at a minimum
`
`encapsulates a single bit . . . and at maximum all defined cyberspace . . . . The ’536
`
`patent does not describe that [sic] the terms ‘logically defined’ or ‘encapsulated’ as
`
`limited to ‘structured information as a whole’ regardless of its internal structure or
`
`‘wrapping data’ in preparation for transmission. The claims also do not require
`
`such limitations.”).) Software files—i.e., logically-organized digital data—stored
`
`on disk or in memory surely qualify as “containers” under the Board’s
`
`construction. Accordingly, both the file management program and the encrypted
`
`software product file recited in Cooper are “containers.”
`
`
`
`Therefore, for the foregoing reasons, the Board’s third reason for declining
`
`to find an RLP as to Cooper was clearly erroneous.
`
`14
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`4.
`
`The Petition Established that the Real Key “Controls”
`Whether A Software Product File Container Is Added to
`the File Management Program Container
`
`
`
`Regarding the Board’s fourth reason, the Decision states: “Although Cooper
`
`discloses that the ‘real key’ is used for encryption/decryption, we are unpersuaded
`
`that the ‘real key’ controls adding a ‘container’ or ‘register’ to the file management
`
`program.” (Decision at 18.)
`
`
`
`As explained above, the Petition established that the file management
`
`program and encrypted software product file are “containers” and that the
`
`encrypted software product file is “added” to the file management program. As
`
`also discussed above, the Petition further established that the real key is a
`
`“register” that “forms part of” the file management program container. Thus, the
`
`only remaining issue is whether the real key “controls” the step of adding the
`
`encrypted software product container to the file management program container.
`
`As explained below, the Board’s conclusion that the real key does not control this
`
`step was clearly erroneous.
`
`
`
`In particular, Cooper explains that a validation step is performed on the real
`
`key before a selected encrypted software product file can be input to the file
`
`management program. (Cooper, 16:24-25 (“Before real key 421 is utilized to
`
`decrypt encrypted software products . . . it is tested to determine its validity.”); id.,
`
`16:42-44 (“The encrypted software object 437 is applied as an input to the
`
`15
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`decryption engine. The validated real key is also supplied as an input to the
`
`decryption engine 439.”).) If the real key is not valid, the encrypted software
`
`product file is not input into the file management program for decryption. (Cooper,
`
`16:36-41 (“FIG. 21 is a block diagram of the validation testing. . . . If the texts
`
`match, the software object is decrypted in accordance with step 433; however, if
`
`the validation text portions do not match, a warning is post [sic] in accordance with
`
`step 435.”); see also id., 18:31-39.) Because the real key must first be validated
`
`before the encrypted software product file can be input to the file management
`
`program for decryption, the real key thus controls whether the encrypted software
`
`product file will be added to the file management program.
`
`
`
`This conclusion is consistent with the language of claims 15 and 16, which
`
`do not under their broadest reasonable construction require a particular way in
`
`which the acquire register must “control” the “adding” step. The “controlling”
`
`requirement is satisfied because the real key, as a result of a check of its validity,
`
`determines whether an encrypted software product file can be input to the file
`
`management program for decryption.
`
`
`
`Accordingly, for all of the reasons explained above and in its Petition, the
`
`Petitioner respectfully requests that the Board find a reasonable likelihood that the
`
`Petitioner will prevail in showing that claim 15 is anticipated by Cooper.
`
`16
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`B.
`
`The Petition Established that Claim 16 Is Obvious over Cooper in
`View of Fortune and Veditz (Petition Ground 3)
`
`
`
`The Board’s decision not to institute IPR based on Ground 3 was based
`
`entirely on its conclusions regarding Ground 2. (Decision at 18 (“Petitioner argues
`
`that Cooper discloses an ‘acquire register,’ as recited by claim 16, for the same
`
`reasons discussed above in the asserted ground of the anticipation of claim 15 by
`
`Cooper. We are not persuaded by this argument in this asserted ground for the
`
`same reasons discussed above.”).) As explained above, the Board’s conclusions as
`
`to Ground 2 were clearly erroneous. Therefore, the Petitioner respectfully requests
`
`that the Board find that it has also established a reasonable likelihood of showing
`
`that claim 16 would have been obvious over Cooper, Fortune and Veditz.
`
`IV. CONCLUSION
`
`For the foregoing reasons, the Petitioner respectfully requests that the Board
`
`find that it has established a reasonable likelihood of showing that claims 15 and
`
`16 are unpatentable based on Ground 2 and Ground 3 identified in its Petition
`
`and accordingly institute inter partes review of the ’536 patent.
`
`Respectfully submitted,
`
`/Heidi L. Keefe/
`Heidi L. Keefe
`Reg. No. 40,673
`Lead Counsel for Petitioner
`Facebook, Inc.
`
`
`
`By:
`
`
`
`
`
`
`
`17
`
`Dated: May 28, 2014
`
`COOLEY LLP
`ATTN: Patent Group
`1299 Pennsylvania Ave., NW, Suite 700
`Washington, D.C. 20004
`Tel: (650) 843-5001
`Fax: (650) 849-7400
`
`
`
`
`
`
`
`
`

`
`Atty Docket No. FABO-028/00US
`309101-2070
`
`
`Certificate of Service
`
`
`
`Pursuant to 37 C.F.R. § 42.6(e), the undersigned certifies that on May 28,
`
`2014, a complete copy of the Facebook Request for Reconsideration, was served
`
`via FEDERAL EXPRESS on the Patent Owner by serving the correspondence
`
`address of record as follows:
`
`
`
`Orrick, Herrington & Sutcliffe, LLP
`IP Prosecution Department
`2050 Main Street, Suite 1100
`Irvine CA 92614
`
` courtesy copy was also served via FEDERAL EXPRESS on the Patent Owner at
`
` A
`
`Evolutionary Intelligence, LLC
`c/o Gutride Safier LLP
`835 Douglass Street
`San Francisco CA 94114
`
`By:
`
`
`/Heidi Keefe/
`Heidi L. Keefe
`Reg. No. 40,673
`
`the following address:
`
`
`
`
`
`
`
`
`
`COOLEY LLP
`ATTN: Patent Group
`1299 Pennsylvania Ave., NW, Suite 700
`Washington, D.C. 20004
`Tel: (650) 843-5001
`Fax: (650) 849-7400
`
`18

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