Campbell et al v. Facebook Inc.

Filing 159

EXHIBITS re 149 Opposition/Response to Motion,,,,, filed byFacebook Inc.. (Attachments: # 1 Chorba Decl. - Exhibit L (filed under seal), # 2 Chorba Decl. - Exhibit M (filed under seal), # 3 Chorba Decl. - Exhibit N (filed under seal), # 4 Chorba Decl. - Exhibit O (filed under seal), # 5 Chorba Decl. - Exhibit P (filed under seal), # 6 Chorba Decl. - Exhibit Q (filed under seal), # 7 Chorba Decl. - Exhibit R (Redacted), # 8 Chorba Decl. - Exhibit S (filed under seal), # 9 Chorba Decl. - Exhibit T (filed under seal), # 10 Chorba Decl. - Exhibit U (filed under seal), # 11 Chorba Decl. - Exhibit V (filed under seal), # 12 Chorba Decl. - Exhibit W (Redacted), # 13 Chorba Decl. - Exhibit X)(Related document(s) 149 ) (Chorba, Christopher) (Filed on 1/16/2016)

EXHIBIT W
REDACTED VERSION OF DOCUMENT(S)
SOUGHT TO BE SEALED

Lieff Cabraser Heimann & Bernstein, LLP
275 Battery Street, 29th Floor
San Francisco, CA 94111-3339
t 415.956.1000
f 415.956.1008

July 24, 2015

VIA E-MAIL
Joshua Jessen, Esq.
Gibson, Dunn & Crutcher LLP
1881 Page Mill Road
Palo Alto, California 94304
[e-mail]
RE:

Campbell v. Facebook, Inc., N.D. Cal. Case No. 13-cv-05996-PJH

Dear Josh:
I write regarding Plaintiffs’ Interrogatory No. 8 and Request for Production No 41.
As an initial matter, to the extent Facebook objects to the terms used in Interrogatory
No. 8, these are Facebook’s employees’ own terms used to describe Facebook’s internal data
systems in a presentation at a public symposium. See Bronson, et al, TAO: Facebook’s
Distributed Data Store for the Social Graph, USENIX ATC'13 Proceedings of the 2013 USENIX
conference on Annual Technical Conference, § 3.1 (June, 2013)1 (the “Bronson Article”). As
such, at this stage in the case, it is Facebook, not Plaintiffs, that is in the best in position to
define and understand these terms.
For reference, Interrogatory No. 8. requests that Facebook:
Identify all facts relating to the Processing of each Private Message
sent or received by Plaintiffs containing a URL2, including, for
each Private Message:
(A)
all Objects that were created during the Processing of the
Private Message, including the (id) and the Object Type for each

Av ailable at https://research.facebook.com/publications/161988287 341248/tao-facebook-s-distributeddata-store-for-the-social-graph/.
2 Each such Priv ate Message has been identified by each Plaintiff in Ex hibit 1 to his respective Objections
and Responses to Defendant’s First Set of Interrogatories.
1

S an Franci sco

New Y ork

Nashvi l l e

www.l i effcabraser.com

Joshua Jessen, Esq.
July 24, 2015
Page 2
Object, as well as any Key -> Value Pair(s) contained in each
Object;
(B)
all Objects that were created specifically when the
embedded URL was shared, including the (id) and the Object Type
for each Object, as well as any Key -> Value Pair(s) contained in
each Object;
(C)
all Associations related to each Private Message, identified
by the Source Object, Association Type, and Destination Object, as
well as any Key -> Value Pair(s) contained in each Association;
(D)
the database names and table names in which each
Association and Object is stored;
(E)
each application or feature in Facebook that uses the
Objects or Associations created for each Private Message; and
(F)
how each Object associated with the Private Message was
used by Facebook.
The terms “id,” “Objects,” “Object Type,” “Source Object,” “Destination Object,”
“Association,” “Association Type,” and “Key -> Value Pair” are all used in the Bronson Article in
the context of describing Facebook’s TAO data store. As described at page 50 of the Bronson
Article:
TAO objects are typed nodes, and TAO associations are typed
directed edges between objects. Objects are identified by a 64-bit
integer (id) that is unique across all objects, regardless of object
type (otype). Associations are identified by the source object (id1),
association type (atype) and destination object (id2). At most one
association of a given type can exist between any two objects. Both
objects and associations may contain data as key→value pairs. A
per-type schema lists the possible keys, the value type, and a
default value. Each association has a 32-bit time field, which plays
a central role in queries.
Objects and associations are further described in the Bronson Article as follows:
Object: (id) → (otype, (key value)∗)
Assoc.: (id1, atype, id2) → (time, (key value)∗)