`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