Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 1 of 12
`
`
`
`
`EXHIBIT 2
`[FILED UNDER SEAL]
`[FILED UNDER SEAL]
`
`EXHIBIT 2
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 2 of 12
`
`MICHAEL A. SHERMAN (SBN 94783)
`masherman@stubbsalderton.com
`JEFFREY F. GERSH (SBN 87124)
`jgersh@stubbsalderton.com
`SANDEEP SETH (SBN 195914)
`sseth@stubbsalderton.com
`WESLEY W. MONROE (SBN 149211)
`wmonroe@stubbsalderton.com
`STANLEY H. THOMPSON, JR. (SBN 198825)
`sthompson@stubbsalderton.com
`VIVIANA BOERO HEDRICK (SBN 239359)
`vhedrick@stubbsalderton.com
`STUBBS, ALDERTON & MARKILES, LLP
`15260 Ventura Blvd., 20th Floor
`Sherman Oaks, CA 91403
`Telephone:
`(818) 444-4500
`Facsimile:
`(818) 444-4520
`
`Attorneys for PersonalWeb Technologies, LLC
`UNITED STATES DISTRICT COURT
`NORTHERN DISTRICT OF CALIFORNIA
`SAN JOSE DIVISION
`CASE NO.: 5:18-md-02834-BLF
`IN RE PERSONAL WEB TECHNOLOGIES,
`LLC, ET AL., PATENT LITIGATION
`
`AMAZON.COM, INC. and AMAZON WEB
`SERVICES, INC.,
`
` Plaintiffs,
`v.
`
`Case No.: 5:18-cv-00767-BLF
`
`
`DECLARATION OF ERIK LA IGLESIA
`IN SUPPORT OF PERSONALWEB
`TECHNOLOGIES, LLC’S NON-
`OPPOSITION TO AMAZON.COM, INC.
`AND AMAZON WEB SERVICES, INC.’S
`MOTION FOR SUMMARY JUDGMENT
`OF NONINFRINGEMENT AND
`OPPOSITION TO MOTION
`REGARDING STANDING
`March 16, 2020
`Trial Date:
`
`
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`PERSONALWEB TECHNOLOGIES, LLC,
`and LEVEL 3 COMMUNICATIONS, LLC,
`
` Defendants.
`
`
`PERSONALWEB TECHNOLOGIES, LLC
`and LEVEL 3 COMMUNICATIONS, LLC,
`
`Counterclaimants,
`v.
`AMAZON.COM, INC. and AMAZON WEB
`SERVICES, INC.,
`
`Counterdefendants.
`
`
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 3 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`I am over the age of eighteen (18) and make this declaration of my own personal
`1.
`knowledge, under penalty of perjury.
`I have been retained as an independent expert witness by the law firm of Stubbs
`2.
`Alderton & Markiles, LLP on behalf of PersonalWeb Technologies, LLC (“PersonalWeb”) to
`testify as a technical expert in lawsuits concerning U.S. Patent No. 6,928,442 (“‘442 Patent”), U.S.
`Patent No. 7,802,310 (“‘310 Patent”), and U.S. Patent No. 8,099,420 (“‘420 Patent”) (collectively,
`“the Asserted Patents”), the lawsuits including In re PersonalWeb Technologies, LLC, et al., Patent
`Litigation, Case No.: 5:18-md-02834-BLF (Northern District of California) and Amazon.com, Inc.
`and Amazon Web Services, Inc. v. PersonalWeb Technologies, LLC and Level 3 Communications, LLC, Case
`No. 5:18-cv-00767-BLF (Northern District of California). I refer to Amazon.com, Inc. and Amazon Web
`Services, Inc. collectively as “Amazon” in this declaration.
`The asserted patent claims relate to controlling the distribution of files in a network
`3.
`of computers. Requests for content or access to content are permitted or not permitted by the
`system using specific methods that include the use of content-based identifiers. This subject matter
`includes the protocols used to transfer those files, technology such as caching to accelerate
`distribution and the configuration of such caching to optimize efficiency using content-based
`identifiers.
`I address in this declaration certain specific points raised by Amazon in its
`4.
`summary judgment motion that relates to:
`a. How Amazon CloudFront servers used MD5 ETags that were generated by applying
`the MD5 hash algorithm to the content and only the content of a webpage file to
`determine whether or not to send a message that permitted browsers to keep using
`cached version of that webpage file after the original permitted time to use that cached
`version has expired;
`b. How Amazon CloudFront servers used MD5 ETags to determine whether or a file at
`a browser was a copy of the current version of a webpage file in making the decision
`of (a); and
`c. How Amazon CloudFront servers compared an MD5 ETag sent in a conditional GET
`
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`1
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 4 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`request from a browser to see if it matched one of a plurality of stored ETags in making
`the determinations of (a) and (b).
`More particularly, as I explain below, CloudFront servers sent webpage file
`5.
`content in HTTP 200 messages with MD5 ETags and max-age values. By doing so, the
`CloudFront server instructed browsers operating under the HTTP 1.1 protocol how long they
`were permitted to use the file content without having to first check back with Amazon whether
`they may still continue to use the content after their permitted use of the content has expired.
`After the permitted time to use the content has expired, the browser sent a conditional GET
`request to which it must receive an HTTP 304 response to continue to access and use the cached
`file content.
`If the browser instead received from a CloudFront server an HTTP 200 response
`6.
`to the conditional GET request, it used the content provided in the 200 response instead of the
`previously cached content. Moreover, the CloudFront servers used MD5 ETags (i.e., ETag values
`generated by applying the MD5 hash algorithm to the file content and only the file content) in
`making the decision whether or not to continue to permit the browsers’ access to the previously
`cached file content or to provide new file content for the browser to access and use instead of the
`previously cached file content.
`The MD5 ETags informed the Amazon server whether a copy of the current
`7.
`version of the webpage file was already cached (present) at the browser or whether a copy of the
`current version needed to be provided. If a copy of the current version was determined to be
`already present at the browser, Amazon sent the HTTP 304 message permitting the browser to
`continue accessing the cached copy. If the file at the browser was determined to be a copy of the
`current file version, the CloudFront server sent the HTTP 200 message for the browser to access
`instead of the previously cached version. By using this system of HTTP 304 and 200 messages,
`Amazon enforced how long browsers accessed customer webpage file content and what webpage
`file content they accessed.
`I will now address Amazon’s three summary judgment arguments that are not
`8.
`based upon the Court’s construction of “unauthorized or unlicensed.”
`
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`2
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 5 of 12
`
`9.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`Claim 20 of the ’310 patent recites, in relevant part:
`based at least in part on said content-dependent name of said
`particular data item, the first device (A) permitting the content to be
`provided to or accessed by the at least one other computer if it is not
`determined that the content is unauthorized or unlicensed,
`otherwise, (B) if it is determined that the content is unauthorized or
`unlicensed, not permitting the content to be provided to or accessed
`by the at least one other computer.
`The evidence that I have reviewed shows that CloudFront Point of Presence (“PoP”)
`10.
`servers each make a determination to permit or not permit content to be provided to or accessed
`by a client, such as a browser, based at least on part on an MD5 ETag value, which is a content-
`dependent name of said particular data item. The CloudFront PoP servers operated during the
`relevant infringement time period in accordance with the HTTP 1.1 protocol, RFC 2616.
`Specifically, the servers communicated with connected computers communicate via messages,
`including but not limited to those specified in RFC 2616 sections regarding GET requests (“HTTP
`GET requests”) (e.g., Sec. 9.3), conditional GET requests (“HTTP conditional GET requests”)
`with If-None-Match Headers (e.g., Sec. 14.9.4), ETags (e.g., Sec. 14.19), 304 messages (“HTTP
`304 messages”) (e.g., Sec. 10.3.5), 200 messages (“HTTP 200 messages”) (e.g., Sec. 10.2.1), and
`cache control directives (e.g., Secs. 13.1, 13.2, 13.3.2-4, 14.9, 14.21, 14.26) to implement cache
`control including in instructing browsers when they were allowed to re-use previously cached
`content or had to use instead use newly provided content.
`HTTP 1.1 provides a mechanism for using ETags to instruct clients (such as
`11.
`browsers) whether or not file content stored in their caches may continue to be used to fulfill
`requests for content after their original permitted time to use the content has expired. More
`particularly, HTTP 1.1 allowed website operators to use CloudFront servers to send the file content
`in an HTTP 200 message with an “ETag” value for that content and a “max-age” value (i.e., a
`permitted time to use the content) and force a browser to check back with the server before using
`that content after the permitted time had expired. If a requested file is served along with a max-
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`3
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 6 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`age caching directive and an ETag value, the client browser cache will store the file, the max-age
`and the ETag. As long as the file’s age in the cache is less than the max-age, the client cache will
`reuse the file for future requests. (RFC 2616 @ 51-52). However, after the permitted time to use
`the content has been exceeded, conditional GETs must be used to revalidate that the client is
`permitted to keep using the cached file content for some extended period of time.
`12. The evidence I reviewed confirmed that, during the relevant time period, CloudFront
`servers Twitch servers used content-based ETags that were generated by applying the MD5 hash
`algorithm to the content, and only the content, of the associated file. My evidentiary review also
`confirmed that the servers sent the MD5 ETag along with the file content and cache control
`directives in HTTP 200 messages and subsequently compared such MD5 ETags sent by clients
`(e.g. browsers and intermediate cache servers) in conditional GET requests with the current ETag
`values for the requested file stored at the server.
`I analyzed produced source code for CloudFront servers including a version of the
`13.
`Squid Cache Server, a popular and widely available open source caching proxy server based on
`the 2.6.STABLE18 release version. Squid source code is available for download from
`http://www.squid-cache.org/ with
`the specific version available as “http://www.squid-
`cache.org/Versions/v2/2.6/squid-2.6.STABLE18.tar.gz”. The functionality relating to evaluating
`HTTP Conditional GET requests resides in the file client-side.c. References to functions and line
`number below pertain to the source code produced and printed for PersonalWeb by Amazon.
`The function clientCacheHit (lines 2898 – 3338, Bates 000345-352) is called to
`14.
`determine whether a client GET request is held within the Squid cache. The HTTP headers are
`processed to determine whether the requested URI is cached and whether the cached copy can be
`provided to the client. Code between lines 2908 and 2969 analyzes the client request to determine
`of all headers have been received and whether the URI is known to the cache. At line 2984, the
`“hit” flag is set indicating that these conditions have been met.
`At line 3101, the headers are checked for the presence of an “If-None-Match”
`15.
`header. If so, the reply that was obtained when the URI was previously cached is checked for the
`presence of an ETag (variable rep_ETag at line 3102). If the response had an ETag (checked at
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`4
`
`
`
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 7 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`line 3110), the current request’s ETag (or ETags) is obtained (as variable req_tags at line 3111)
`and compared against the response ETag (using function doesETagMatch at line 3112 setting
`variable do_ETags_match). A successful match results in the variable “is_modified” to be set to 0
`at line 3117. An unsuccessful match will cause “is_modified” to be set to 1 and the request to be
`forwarded to the origin server.
`At lines 3260 – 3306, an “is_modified” value of 0 causes Squid to create the 304
`16.
`response to the client (function httpPacked304Reply at line 3265). This concludes the process of
`detecting a conditional GET request with an ETag, comparing the ETag against the known ETags,
`authorizing the cached contents if the ETags matches and deauthorizing the cached content if the
`ETags mismatch.
`The evidence I summarize above confirmed that, during the relevant time period,
`17.
`the CloudFront PoP servers used content-based ETags that were generated by applying the MD5
`hash algorithm to the content, and only the content, of the associated file. My evidentiary review
`also confirmed that the servers sent the MD5 ETag along with the file content and cache control
`directives in HTTP 200 messages and subsequently compared such MD5 ETags sent by clients
`(e.g. browsers and intermediate cache servers) in conditional GET requests with the current ETag
`values for the requested file stored at the server. (clientCacheHit at lines 3102, 3110-12, 3117.)
`If the server processing the conditional GET request verified that the ETag sent in the “If-None-
`Match” request header of the conditional GET request matched the current MD5 ETag value of
`the requested file, the server then made a determination to permit a browser to keep using and
`accessing the cached content by sending a 304 NOT MODIFIED message to the browser.
`(clientCacheHit, at lines 3260 – 3306.)
`This capability relied on the fact that the server’s MD5 ETag value for that file was
`18.
`updated when that file’s content changed. RFC 2616 does not describe the generation of ETag
`validators or require the use of content-based ETags that changed only when the content itself
`changed but rather distinguishes weak from strong validators by requiring that strong validators
`change whenever the underlying file changed. (RFC 2616 @ 54-57.)
`19. When the Amazon PoP server responding to the conditional GET request did not
`
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`5
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 8 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`find there to be an MD5 ETag match, it made a determination not to permit a browser to keep
`using and accessing the cached content and sent an HTTP 200 OK response with new content for
`the browser to use and access instead of previously cached content in accordance with the HTTP
`protocol specification RFC 2616. Amazon’s witness, Mathew Baldwin, also provided extensive
`testimony confirming my analysis of CloudFront’s processing of HTTP conditional GET requests
`containing content-based ETags and sending 200 and 304 responses. (See Matthew Baldwin Dep.
`Tr. (10/1/19), at pps. 68-78, 83-86.)
`Claim 25 of the ’420 patent recites, in relevant part:
`20.
`(C) based at least in part on said ascertaining in step (B), selectively
`allowing a copy of the particular sequence of bits to be provided to
`or accessed by or from at least one of the computers in a network of
`computers, wherein a copy of the sequence of bits is not to be
`provided or accessed without authorization, as determined, at least
`in part, based on whether or not said first content-dependent name
`of the particular sequence of bits corresponds to one of the plurality
`of identifiers.
`The evidence I have reviewed shows that the CloudFront PoP servers selectively
`21.
`allowed a copy of a particular sequence of bits (a data item) to be accessed by a computer in a
`network, namely, a computer running a web browser. The CloudFront PoP servers stored many
`data items to which MD5 ETag identifiers had been assigned. The source code discussed above
`determined if the MD5 ETag identifier sent by a browser in a conditional GET request matched
`one of a plurality of identifiers (clientCacheHit, at lines 3102, 3110-12, 3117.). When the server
`found a match, it determined that the file content at the browser was a copy of the file content at
`the server and allowed a browser to access the cached copy by sending an HTTP 304 Not Modified
`response. (clientCacheHit, at lines 3260 – 3306.) When the server did not find a match, it made
`a determination not to allow a browser to keep accessing cached content when it sent an HTTP
`200 OK response with new content, which the browser would then use instead of cached content
`in accordance with the HTTP protocol specification RFC 2616.
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`6
`
`
`
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 9 of 12
`
`22.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`Claim 166 of the ’420 patent recites, in relevant part:
`(a2) selectively permit the particular data item to be made available
`for access and to be provided to or accessed by or from at least some
`of the computers in a network of computers, wherein the data item
`is not to be made available for access or provided without
`authorization, as resolved based, at least in part, on whether or not
`at least one of said one or more content-dependent digital identifiers
`for said particular data item corresponds to an entry in one or more
`databases, each of said one or more databases comprising a plurality
`of identifiers, each of said identifiers in each said database
`corresponding to at least one data item of a plurality of data items,
`and each of said identifiers in each said database being based, at
`least in part, on at least some of the data in a corresponding data
`item.
`The evidence I reviewed shows that the CloudFront PoP servers selectively
`23.
`permitted access to a data item to be accessed by a computer in a network, namely, a computer
`running a web browser, for the same reasons as I just discussed. The evidence supporting this
`limitation of claim 166 of the ’420 patent is the same as for the limitation in claim 25 of the ’420
`patent discussed above.
`Claim 11 of the ’442 patent recites, in relevant part:
`24.
`A method as in claim 10 further comprising: allowing the file to be
`provided from one of the computers having an authorized or
`licensed copy of the file.
`The evidence I have reviewed shows that CloudFront PoP servers allowed a file to
`25.
`be provided from the server when the file’s content had changed. Specifically, the server
`determines whether the MD5 ETag sent by a client (e.g. a browser) in an HTTP conditional GET
`request matched the current MD5 ETag value for the file at the server. When the server did not
`find a match, the server generated an HTTP 200 OK response with the new file content for the
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`7
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 10 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`browser to access and use instead of cached content, in accordance with the HTTP protocol
`specification RFC 2616.
`This description of how the CloudFront PoP servers meet this specific claim
`26.
`limitations is consistent with the plain and ordinary meaning of “allow” and “permit.”
`CloudFront PoP servers processed conditional GET request having MD5 ETags,
`27.
`which are content-based names for the requested file, received from clients during the relevant
`time period. As part of that processing, the Amazon server either allowed/permitted the browser
`to keep using the cached file content or made new file content available for access based on a
`comparison of the MD5 ETag sent in the request with the current MD5 ETag value for the file.
`I do not read, and do not believe any person of ordinary skill in the art would read,
`28.
`any of the claims to require that the system must “prevent” access forever. In the “back” button
`example provided by Amazon, no request for a file is sent to the server, so it cannot be said that
`the server did or did not prevent the cache content to be viewed as the server is not involved that
`transaction. Similarly, Amazon’s example of offline viewing of pages is irrelevant because offline
`viewing by definition likewise does not involve communications with the server.
`Asserted claim 10 [and dependent claim 11] of the ‘442 patent requires:
`29.
`“determining, using at least the name, whether a copy of the data file is present on at least one of
`said computers.” Amazon asserts that this limitation is not met because “ETags are not used to
`identify, locate or retrieve files.” [Dkt. 542, at 12 (PDF at 14/16)]
`In making this argument, Amazon appears to mistake my analysis. The accused
`30.
`ETags were used by CloudFront PoP servers to determine whether various webpage files in
`browser caches were copies of various webpage files hosted on CloudFront PoP servers. When
`Amazon determined that a file at the browser cache is a copy of the file at the server, Amazon sent
`an HTTP 304 message instructing the browser to keep using the cached copy for some extended
`time period. And, conversely, when Amazon determined that a copy of the file at the CloudFront
`PoP server was not already present at the browser cache, Amazon sent an HTTP 200 message to
`provide the browser with an actual copy of the current version. The ETag was used to match
`content in order to determine whether that content is present at a given location, i.e., to determine
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`8
`
`
`
`
`

`

`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 11 of 12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`whether a copy was present.
`By merely receiving an ETag in a conditional GET request and not doing anything
`31.
`further with it, Amazon could not know whether a copy of a given file located at the server was
`also present at the browser cache. It was necessary for Amazon to compare the content-based
`ETag with another ETag to determine whether the file located at the browser is actually a copy of
`the file located at the server, i.e., that the content of the file at the browser cache is a copy of the
`content of the file at the server. Indeed, without this determination, Amazon would not have
`known whether to send the HTTP 304 (extending the permitted time that the browser can use the
`cached copy of the file) or rather to send an HTTP 200 message with a copy of the current version
`of the file.
`All Amazon can determine with just the URI is that a file having that URI is located
`32.
`at a given computer, not whether that file is a copy of another file. This is the point of using the
`MD5 ETags—the URI and MD5 ETag are both needed to determine whether the file at the browser
`cache has the same content as the file at the webpage server, i.e., only when both the URI and the
`ETag received in the conditional GET request match the URI and ETag at the server, does Amazon
`determine that the file at the browser cache is an actual copy of the file at the server. Only when
`the two files have the same content is one a “copy” of the other.
`Claim 25 recites: “ascertaining whether or not said first content-dependent name
`33.
`for the particular sequence of bits corresponds to one of a plurality of identifiers.” This language
`does not require that the first content-dependent name is compared to more than one of a plurality
`of identifiers. It only requires that it be ascertained whether or not the content-dependent name
`corresponds to one of the plurality of identifiers.
`Similarly, claim 166 recites, “whether or not at least one of said one or more
`34.
`content-dependent digital identifiers for said particular data item corresponds to an entry in one or
`more databases, each of said one or more databases comprising a plurality of identifiers.” Again,
`this language does not require that a content-dependent digital identifier be compared to more than
`one of a plurality of identifiers in a database, only that it be ascertained whether or not it
`corresponds to one of the entries in the database, which CloudFront servers did as per my source
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`9
`
`
`
`
`

`

`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`
`Case 5:18-md-02834-BLF Document 550-3 Filed 10/25/19 Page 12 of 12
`
`code analysis set forth above.
`I reserve all rights to supplement this declaration in response to additional
`35.
`discovery, newly discovered documents, and/or reports by other experts.
`
`Executed this October 25, 2019 in Mountain View, California.
`
`
`
`__________________
`
`Erik de la Iglesia
`
`
`
`DECLARATION OF
`ERIK DE LA IGLESIA
`
`10
`
`
`
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`