Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 1 of 6
`
`Michael A. Shennan (SBN 94783)
`
`Wesley W. Monroe (SBN 14921l)
`wmonroe@stubbs alderton. com
`Stanley H. Thompson, Jr. (SBN 198825)
`sthornpson@stubb s al derton. com
`Viviana Boero Hedrick (SBN 239359)
`vhedrick@stubbsalderton.com
`STUBBS, ALDERTON & MARKILES, LLP
`ß26A Véntura Blvd., 2oth Floor
`Sherman Oaks, CA 91403
`(818) 444-4s00
`Telephone
`(8t8) 444-4s20
`Facsimile:
`Attorneys for Personal\ileb Technologies, LLC
`and Level3 Communications, LLC
`fAdditional Attomeys listed below]
`I.INITED STATES DISTRICT COURT
`
`NORTHERN DISTRICT OF CALIFORNIA
`
`SAN JOSE DIVISION
`
`IN RE PERSONALWEB TECHNOLOGIES,
`LLC, ET AL., PATENT LITIGATION
`
`CASE NO.: 5:18-md-02834-BLF
`
`AMAZON.COM, INC., et al.,
`
`Plaintiffs,
`
`PERSONALWEB TECHNOLOGIES, LLC, Et
`à1,,
`
`PERSONALWEB TECHNOLOGIES, LLC
`and LEVEL 3 COMMUNICATIONS, LLC,
`
`Counterclaimants,
`
`Case No.: 5: 18-cv-007ó7-BLF
`DECLARATION OF PATRICK
`MCCLORY IN SUPPORT OF'
`PERSONALWEB TECHNOLOGIES, LLC
`AND LEVEL 3 COMMUNICATIONS,
`LLC'S OPPOSTTION TO AMAZON.COM,
`INC. AND AMAZON WEB SERVICES,
`INC.'S MOTION FOR SUMMARY
`JUDGMENT ON DECLARATORY
`JUDGMENT CLAIMS AND DEFENSES
`UNDER THE CLAIM PRECLUSION AND
`KESSLER DOCTRINE
`
`Date: February 7,2019
`Time: 2:00 PM
`Courtroom 3, 5th Floor
`Dept.:
`Hon. Beth L. Freeman
`Judge:
`
`AMAZON.COM, INC. and AMAZON WEB
`SERVICES,INC.,
`
`Trial Date: March 16,2020
`
`Counterdefendants.
`
`I 2 3 4 5 6 7 8 9
`
`10
`
`11
`
`12
`l3
`
`T4
`
`15
`
`16
`I7
`l8
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`4813.1t#086e, v.3
`
`CASE NO: 5:18-md-02834-BLF
`CASE NO: 5:18-cv-00767-BLF
`
`

`

`Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 2 of 6
`
`I, Patrick McClory, declare as follows:
`1.
`I am over the age of l8 and cornpetent to make this declaration. The facts herein are,
`unless otherwise stated, based upon personal knowledge, and if called upon to clo so, I could, and
`woul<] testify to their truth under oath. I subrnit this declaration in support of Personal'Web and Level
`
`3 Communications' Opposition to Amazon.com, Inc., and Amazon Web Services, Inc.'s Motion for
`
`Summary Judgnent of Declaratory Judgment Claims and Defenses Under the Clairn Preclusion and
`
`Kessler Doctrine.
`2.
`AmazonWeb Services Certifred Developer frorn 2014 to 2016, and a Senior Consultant employed by
`
`I was an Amazon Web Services Certified Solutions Architect from 2013 to 2015, an
`
`Amazon Web Services fi'om 2013 to 2014. Additionally, I have been consulting to customers on the
`use of A'WS since 201I and continue to advise customers in their use of this platform both from a
`strategic and an engineering perspective. I am personally familiar with the Amazon Web Services
`
`product called "Simple Storage Selvice", "Amazon 53" or simply "S3," having consulted on hundreds
`
`of projects involving 53. A summary of rny experience and qualifications profile is attached hereto
`
`as Exhibit A.
`3.
`objects up to 5 terabytes in size; migrating data; configuring lifecycle policies; creating, updating, and
`
`53 includes several sub-systems servicing an entire suite of features including: storing
`
`deleting tags for objects; copying objects between buckets; replacing object tag sets;modifying access
`
`controls; restoring archived objects fiom archival subsysterns such as Amazon Glacier; irnplementing
`
`version control; replicating objects across AWS Regions; managing access; and applying encryption
`
`and controlling access to stored data.. These features are described, for example, in AWS's Frequcntly
`
`Asked Questions and 53 descriptions, true and correct copies of which are attached hereto as Exhibits
`
`B-D,
`
`4.
`upload is a process by which an 53 customer using an 33 interface can upload large objects (up to 5
`
`I am personally farniliar with an 33 functionality called "multipart upload." Multipaft
`
`terabytes) to 53. The process requires a series of transactions in which a customer, sometimes using
`
`an AWS-provided tool such as the AWS 53 CLI (Cornmand Line Interface), breaks up an object into
`
`smaller parts, uploads each part temporarily to 53, and then instructs 53 to assemble the parts together
`
`1 2 aJ 4 5 6 7 8I
`
`10
`
`11
`
`t2
`
`13
`
`T4
`l5
`
`16
`
`t7
`
`18
`
`19
`
`20
`2I
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`MC
`
`KES
`
`CASE NO: 5:1
`CASENO:5:
`
`

`

`Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 3 of 6
`
`to fonn the rnultipart object to be stored on 53. The parts are stored ternporarily in 53 during a
`rnultipart upload, and cannot be accessed by an anonyÍrous browser, i.e., a browser operated by
`someone who does not have credentials to access the 53 bucket to which the multipart upload is being
`made. The parts also cannot be accessed by the 53 custorner except with the
`CompleteMultipartUpload command. The parts are only stored long enough to create the aggregate
`object but are not otherwise accessiblo once a rnultipart upload is completed or abofted by the 53
`
`As parl of the multipart upload process, an 53 user may generate MD5 hashes for each
`
`customet.
`5,
`part that is being uploaded, to be compared to the 53 seler-calculated ETag for each respective part.
`The ETag for a rnultipart upload part is an MD5 hash of the content of that part. These ETags are
`generated for each part and used to verify the part did not get comrpted during the upload. Only if the
`pafi's content did not get comrpted will it be used by 53 to assemble the parts into the large object for
`storage when the customer sends a "CompleteMultipartUpload" command. As part of the process, an
`53 customer can use 33 specific multipart upload commands to copy an object that they previously
`had uploaded to 53 and use it as one of the parts that form the fìnal Multipart upload object.
`6.
`I have been informed that PersonalWeb was a plaintiff in PersonalWeb Technol.ogies
`LLC and Level 3 Communications tt. Amazon.cr¡m, Inc, et al., Case No. 6:1 1-cv-00ó58 in the Eastern
`District of Texas ("the Texas Action"). I was provided and reviewed the claim charts for the
`preliminary Infringement Contentions ("PICs") for the patents asserted in the Texas Action in which
`personalWeb identified aspects of the Amazon Simple Storage Service ("S3") as the accused
`instrumentality, produced in this current litigation at AMZ-PWT-00005796-5838,
`AMZ_PWT_00005848-5925, AMZ_PWT_00005941-5986, AMZ_PWT_00005994-6147,
`AMZ-PWT-O0O 0 6 I 5 9-6 2 5 4, and AMZ-PWT-0 0 A0626 4 - 63 7 4'
`Upon reviewing the PICs, I reached the conclusion that they were directed to the
`i.
`multipart upload functionality of 53. I reached this conclusion by reviewing the evidence cited in the
`charts. For exarnple, the chart for U,S. Patent No, 7,802,310 contains the following statements and
`
`citations to evidence:
`
`1 2 ^J 4 5 6 7 8 9
`
`10
`
`11
`
`t2
`t3
`t4
`
`15
`l6
`t7
`l8
`t9
`
`20
`
`27
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`

`

`Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 4 of 6
`
`a. "When perfonning a multipart upload, Amazon 53 automatically generates a hash
`to identify and retrieve the data being uploadcd."
`b. "Objects greater than 5GB in size require the use of the multipart upload API."
`c, A description of the use of ETags in multipart uploads, including a graphic of a
`description of the ETag response header from the 53 API Reference.
`d. An excerpt of the 53 Developer Guide stating that "[m]ultipart uploading is a three-
`
`step process..."
`e. An excerpt of the 53 Developer Guide describing the "Parts Upload Step" for a
`
`multipart upload,
`f. An excerpt of the S3 Developer Guide describing the "Multipart upload Completion
`(or Abort)" step for a multipart upload.
`g. A description of a sample PUT request from the 53 Developer Guide as including
`"the upload ID that you get in response to your Initiate Multipart upload request."
`h. A description of a sample response to a PUT request from the 53 Developer Guide
`as including "the ETag header" and a statement that "[y]ou need to retain this value
`
`for use when you send the Cornplete Multiparl upload request."
`i. An excerpt from the 53 API Reference describing the Cornplete Multipart upload
`operation, graphics frorn the 53 API Reference showing the request and response
`elements for the operation, sample syntax from the 53 API Reference for a POST
`
`request used to carry out the for the Cornplete Multipart upload operation, and a
`
`sample response that "indicates that an object was successfully assembled,"
`
`including the xml tag "CompleteMultipartUploadRcsult."
`j. Excerpts from the 53 API Reference showing how a PUT request can be used to
`copy bytes from an existing object to make it a part during a multipart upload
`
`operation using the x-amz-copy-source header.
`k. Excerpts frorn the 53 API Reference showing the behavior of conditional headers
`used with the x-amz-copy-source header during a multipart upload'
`
`1 2 J 4 5 6 7 8 9
`
`10
`
`11
`
`12
`l3
`t4
`
`15
`
`16
`
`T7
`
`18
`
`19
`
`20
`2t
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`

`

`Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 5 of 6
`
`8.
`Based on my experience with the 53 multipart upload functionality, I recognize lhat
`the above statements referred to operations perfonned during rnultipart upload. They are not referring
`to operations perfonned during the service of webpage files to anonymous browsers in response to
`requests from an anonymous browser. In order to use 53 to serve webpage files to anonymous
`browsers, an 53 customer has to take affumative steps to make an 53 bucket availablc as a website
`endpoint, as opposed to a REST endpoint which is the normal, default endpoint for a multipart
`uploaded object, as shown, for exarnple, on pages 87-96 and 338-339 of the 33 Developer Guide
`produced in this case at AMZ_PWT_00000278. True and correct copies of pages 87-96 and 338-339
`of the 53 Developer Guide are attached as Exhibit E hereto. Alternatively, an 53 customer would have
`to configure an 53 bucket, or a specific object in an 53 bucket, to be publicly accessible, and therefore
`capable of being referenced in a URI. This public accessibility is not the dcfault configuration.
`g.
`The Prelìrninary Infringement Contcntions also contained excerpts frorn the 53 API
`Reference showing how GET and HEAD operations are implemented and how a PUT request can be
`used to copy an existing object using the x-amz-copy-source header. Conditional HTTP GET requests
`are not used during Multipart upload. Using the x-amz-copy-source header in a PUT request may be
`used to copy an object previously stored on 53 but would use the ETag in a different way than a
`conditional HTTp GET request. The x-amz-copy-source header in a PUT request would be acted on
`upon an ETag match of uploaded client <lata, whereas in a conditional HTTP GET request an lf-None-
`Match hcader woukl be acted on upon an ETag mismatch of cached server data.
`10. All the evidence described in paragraphs 7 and 9 above was recited in supporl of all the
`preliminary Infringernent Contentions directed to the Multipart upload feature of 53 for the asserted
`
`patents in the Texas Action. Therefore, my conclusions above regarding the '310 Patent Preliminary
`Infringement Contentions applies to all the Preliminary Infringement Contentions directed to 53 for
`the asserted patents, i.e.,that all are directed to the Multipart upload feature of 53'
`1i. To summarize, anonyïnous browsers (meaning browsers without access to AWS
`account credentials) cannot use the 53 Multipart upload features without additional coordination via
`an application that has access to an appropriate set of AWS account credentials. The 53 multipart
`upload series of transactions sirnply does not involve serving 53 object content using conditional
`
`I 2 J 4 5 6 7 8 9
`
`10
`
`l1
`t2
`
`13
`l4
`
`15
`
`16
`t7
`
`18
`
`t9
`
`20
`2l
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`NO:
`NO
`
`5:1
`:5:
`
`

`

`Case 5:18-md-02834-BLF Document 338 Filed 01/09/19 Page 6 of 6
`
`HTTP GET requests, From the perspective of a network engineer. the 53 Multipart upload system and
`
`the website endpoint system involve different netwolk transactions and confìgurations. They are
`
`dillèLent processes operating in diff'erent ways to provide different finctionality to diflerertt types oÍ'
`
`customers using 53 in dil'lèrent ways. In one, the custonler uses certain functionalities of 53 to upload
`
`large fìles in order to store theur for a given period of timel in the other, the customer uses other
`
`firnctionalities of S3 to control the distribution of webpage content to anonymous bt'owsers and to
`
`instruct them when they are re-permitted to re-use previously cached webpage content or must instead
`
`get new webpage content in rendering a webpage. Tllese respective distinct fìrnctionalities involve
`
`diffelent transactions. use ETags in different methods, and are priced difTerently,
`12. I am làmiliar with an Amazon product called CloudFront, which is a content delivery
`
`network, or CDN. A CDN is a server that acts as teu"ìporary storage aud temporarily stores requests to
`
`f'urther downstreant servers to optimize barrdwidth f'or end users as well as website operators. They
`
`reduce unnecessal'ily redundant requests f'or the same resource by serving the same content fì'om the
`
`CDN's local and temporary storage rather than nraking requests to the origin server. CloudFront
`
`always was and is a separate product fiom 53. In my review of'the cllarts fbl the PICs lìlr the Texas
`
`Action, I did not see ariything relating to CloudFront as an accused instrumentality.
`
`I declal'e under penalty of peLjury under the laws of the United States of America that the
`
`fbregoing I tlue and correct.
`
`Executed on January 9, 2019 in
`
`\rb-L
`
`Calif.omia.
`
`Patrick McClory
`
`I 2 J 4 5 6 7 I 9
`
`l0
`ll
`l2
`l3
`t4
`l5
`l6
`t7
`l8
`
`19
`
`20
`2l
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`rso
`MS.I
`
`E
`
`t-
`
`F
`
`