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-cv-05600-BLF Document 1 Filed 09/12/18 Page 1 of 20
`
`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 Plaintiffs
`[Additional Attorneys listed
`below]
`
`
`
`UNITED STATES DISTRICT COURT
`
`NORTHERN DISTRICT OF CALIFORNIA
`SAN FRANCISCO DIVISION
`
`CASE NO.:
`
`COMPLAINT FOR PATENT
`INFRINGEMENT
`DEMAND FOR JURY TRIAL
`
`
`
`PERSONALWEB TECHNOLOGIES, LLC, a
`Texas limited liability company, and
`LEVEL 3 COMMUNICATIONS, LLC,
`a Delaware limited liability company,
`
`
`Plaintiffs,
`
`v.
`
`SLACK TECHNOLOGIES, INC., a Delaware
`corporation,
`
`
`
`
`
`Defendant.
`
`
`
`
`
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 2 of 20
`
`Plaintiff PersonalWeb Technologies, LLC (“Plaintiff” or “PersonalWeb”) files this Complaint
`for patent infringement against Defendant Slack Technologies, Inc. (“Defendant”). Plaintiff
`PersonalWeb Technologies, LLC alleges:
`
`PRELIMINARY STATEMENT
`PersonalWeb and Level 3 Communications, LLC (“Level 3”) are parties to an
`1.
`agreement between Kinetech, Inc. and Digital Island, Inc. dated September 1, 2000 (the “Agreement”).
`Pursuant to the Agreement, PersonalWeb and Level 3 each own a fifty percent (50%) undivided
`interest in and to the patents at issue in this action: U.S. Patent Nos. 6,928,442, 7,802,310, and
`8,099,420 (“Patents-in-Suit”). Level 3 has joined in this Complaint pursuant to its contractual
`obligations under the Agreement, at the request of PersonalWeb.
`Pursuant to the Agreement, Level 3 has, among other rights, certain defined rights to
`2.
`use, practice, license, sublicense and enforce and/or litigate the Patents-in-Suit in connection with a
`particular field of use (“Level 3 Exclusive Field”). Pursuant to the Agreement PersonalWeb has,
`among other rights, certain defined rights to use, practice, license, sublicense, enforce and/or litigate
`the Patents-in-Suit in fields other than the Level 3 Exclusive Field (the “PersonalWeb Patent Field”).
`All
`infringement allegations, statements describing PersonalWeb, statements
`3.
`describing any Defendant (or any Defendant’s products) and any statements made regarding
`jurisdiction and venue are made by PersonalWeb alone, and not by Level 3. PersonalWeb alleges that
`the infringements at issue in this case all occur within, and are limited to, the PersonalWeb Patent
`Field. Accordingly, PersonalWeb has not provided notice to Level 3—under Section 6.4.1 of the
`Agreement or otherwise—that PersonalWeb desires to bring suit in the Level 3 Exclusive Field in its
`own name on its own behalf or that PersonalWeb knows or suspects that Defendant is infringing or
`has infringed any of Level 3’s rights in the patents.
`
`
`
`
`1
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 3 of 20
`
`THE PARTIES
`Plaintiff PersonalWeb Technologies, LLC is a limited liability company duly organized
`4.
`and existing under the laws of Texas with its principal place of business at 112 E. Line Street, Suite
`204, Tyler, TX 75702.
`Plaintiff Level 3 Communications, LLC is a limited liability company organized under
`5.
`the laws of Delaware with its principal place of business at 100 CenturyLink Drive, Monroe,
`Louisiana, 71203.
`PersonalWeb’s infringement claims asserted in this case are asserted by PersonalWeb
`6.
`and all fall outside the Level 3 Exclusive Field. Level 3 is currently not asserting patent infringement
`in this case in the Level 3 Exclusive Field against any Defendant.
`Defendant Slack Technologies, Inc. is, upon information and belief, a Delaware
`7.
`corporation having a principal place of business and regular and established place of business at 500
`Howard Street, 1st Floor, San Francisco, California 94105.
`
`JURISDICTION AND VENUE
`The court has subject matter jurisdiction pursuant to 28 U.S.C. §§ 1331 and 1338(a)
`8.
`because this action arises under the patent laws of the United States, 35 U.S.C. §§ 1 et seq.
`Venue is proper in this federal district pursuant to 28 U.S.C. §§ 1391(b)–(c) and
`9.
`1400(b) because Defendant is incorporated in the State of Delaware and, on information and belief,
`has a regular and established place of business in this District and has committed acts of infringement
`in this District.
`This court has personal jurisdiction over Defendant because, in addition to the
`10.
`allegations in above paragraphs, on information and belief, Defendant is domiciled in this District.
`Further, on information and belief, Defendant purposefully directed activities at residents of
`California, the claims herein arise out of and relate to those activities, and assertion of personal
`jurisdiction over Defendant would be fair.
`
`
`
`
`2
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 4 of 20
`
`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 BACKGROUND
`The Patents-in-Suit cover fundamental aspects of cloud computing, including the
`11.
`identification of files or data and the efficient retrieval thereof in a manner which reduces bandwidth
`transmission and storage requirements.
`The ability to reliably identify and access specific data is essential to any computer
`12.
`system or network. On a single computer or within a small network, the task is relatively easy: simply
`name the file, identify it by that name and its stored location on the computer or within the network,
`and access it by name and location. Early operating systems facilitated this approach with standardized
`naming conventions, storage device identifiers, and folder structures.
`Ronald Lachman and David Farber, the inventors of the Patents-in-Suit, recognized
`13.
`that the conventional approach for naming, locating, and accessing data in computer networks could
`not keep pace with ever-expanding, global data processing networks. New distributed storage systems
`use files that are stored across different devices in dispersed geographic locations. These different
`locations could use dissimilar conventions for identifying storage devices and data partitions.
`Likewise, different users could give identical names to different files or parts of files—or unknowingly
`give different names to identical files. No solution existed to ensure that identical file names referred
`to the same data, and conversely, that different file names referred to different data. As a result,
`expanding networks could not only become clogged with duplicate data, they also made locating and
`controlling access to stored data more difficult.
`Lachman and Farber developed a solution: replacing conventional naming and storing
`14.
`conventions with system-wide “substantially unique,” content-based identifiers. Their approach
`assigned substantially unique identifiers to “data items” of any type: “the contents of a file, a portion
`of a file, a page in memory, an object in an object-oriented program, a digital message, a digital
`scanned image, a part of a video or audio signal, or any other entity which can be represented by a
`sequence of bits.” Applied system-wide, this invention would permit any data item to be stored,
`located, managed, synchronized, and accessed using its content-based identifier.
`To create a substantially unique, content-based identifier, Lachman and Farber turned
`15.
`to cryptography. Cryptographic hash functions, including MD4, MD5, and SHA, had been used in
`
`
`
`3
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 5 of 20
`
`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
`
`
`computer systems to verify the integrity of retrieved data—a so-called “checksum.” Lachman and
`Farber recognized that these same hash functions could be devoted to a vital new purpose: if a
`cryptographic hash function was applied to a sequence of bits (a “data item”), it would produce a
`substantially unique result value, one that: (1) virtually guarantees a different result value if the data
`item is changed; (2) is computationally difficult to reproduce with a different sequence of bits; and
`(3) cannot be used to recreate the original sequence of bits.
`These cryptographic hash functions would thus assign any sequence of bits, based on
`16.
`content alone, with a substantially unique identifier. Lachman and Farber estimated that the odds of
`these hash functions producing the same identifier for two different sequences of bits (i.e., the
`“probability of collision”) would be about 1 in 2 to the 29th power. Lachman and Farber dubbed their
`content-based identifier a “True Name.”
`Using a True Name, Lachman and Farber conceived various data structures and
`17.
`methods for managing data (each data item correlated with a single True Name) within a network—
`no matter the complexity of the data or the network. These data structures provide a key-map
`organization, allowing for a rapid identification of any particular data item anywhere in a network by
`comparing a True Name for the data item against other True Names for data items already in the
`network. In operation, managing data using True Names allows a user to determine the location of
`any data in a network, determine whether access is authorized, and to selectively provide access to
`specific content not possible using the conventional naming arts.
`On April 11, 1995, Lachman and Farber filed their patent application, describing these
`18.
`and other ways in which content-based “True Names” elevated data-processing systems over
`conventional file-naming systems. The first True Name patent issued on November 2, 1999. The last
`of the Patents-in-Suit has expired, and the allegations herein are directed to the time period before
`expiration of the last of the Patents-in-Suit.
`PersonalWeb has successfully enforced its intellectual property rights against third
`19.
`party infringers, and its enforcement of the Patents-In Suit is ongoing. This enforcement has resulted
`in PersonalWeb obtaining settlements and granting non-exclusive licenses regarding the Patents-in-
`Suit.
`
`
`
`4
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 6 of 20
`
`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
`
`
`GENERAL BACKGROUND
`A webpage is a type of document that is typically retrieved over the World Wide Web,
`20.
`made viewable and formatted (rendered) by a web browser, and displayed electronically. A “webpage”
`often refers to what is visible in a browser, but sometimes also refers to a computer file (“webpage
`file” or “webpage base file”), usually written in Hypertext Markup Language (“HTML”) or a
`comparable markup language. Such HTML files typically include text, formatting, and references
`(hyperlinks) to other web contents, such as style sheets, scripts, and images. Web contents referenced
`in an HTML or similar file are also called “webpage assets” or “asset files” herein. The web browser
`coordinates the retrieval of the various asset files of a webpage and renders the webpage for display
`from the webpage base file and the asset files referenced in the webpage base file.
`On the World Wide Web, hyperlinks generally include Uniform Resource Identifiers
`21.
`(“URIs”), which each typically include an address of a server from which the asset file could be
`retrieved (e.g., “www.website.com”), a “path” to the location of that asset file on that server (e.g.,
`“/directory/”), and a filename (e.g., “filename.ext”).
`On the Internet, a web browser typically retrieves a webpage base file from a remote
`22.
`web server and retrieves referenced asset files from the same or different servers. The web browser
`retrieves a webpage base file and asset files by making a GET “request” to a web server using the
`Hypertext Transfer Protocol (“HTTP”), an industry standard. The web server may respond to such a
`request with a HTTP “response” that includes the requested web content.
`A static webpage is delivered exactly as stored, as web content in the web server’s file
`23.
`system or memory. In contrast, a dynamic webpage is generated by a web server application, usually
`driven by server-side software, upon receipt of a request from a browser (user). For example, a picture
`of a building might be delivered as static content (a picture) whereas the latest traffic conditions may
`be delivered dynamically based on real time traffic information.
`The speed of a browser retrieving webpage base files and incorporated asset files can
`24.
`be increased by the browser storing previously retrieved webpage base files and asset files in a browser
`“cache” on the computer running the browser. If a browser’s user later requests a previously retrieved
`webpage base file or requests a webpage that includes an asset file previously used by the browser in
`
`
`
`5
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 7 of 20
`
`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
`
`
`rendering the same or a different webpage (for example, by reloading a webpage or visiting the same
`webpage again), the browser may use the cached webpage base file or asset file rather than having to
`download the same file repeatedly over the Internet again.
`Two computers communicating over the Internet usually are not directly connected to
`25.
`each other but rather interact via chains of network appliances and other computers (e.g., “switches”
`and “intermediate” servers). Many intermediate servers have caches similar to and complementing
`the browser cache that store webpage base files and assets that pass through that intermediate server.
`If a browser or server requests a file from the intermediate server that is present in that intermediate
`server’s cache, the intermediate server can use the content in its cache to respond to the request rather
`than send the request upstream towards the web server from which the file initially originated (also
`called the “origin server”).
`Responses to HTTP requests may include header elements (control elements) and a
`26.
`body (the “object” that was requested). Under HTTP, web servers can include a “cache-control”
`header with a response including a webpage or asset file. A “cache-control” header includes one or
`more directives that instruct browsers and intermediate server caches (“intermediate caches”) as to
`whether and for how long the file (object) included in the response may be cached. HTTP also
`provides for including other headers in responses that provide similar types of instructions to browsers
`and intermediate caches. Collectively, these other headers and directives in a “cache-control” header
`are referred to herein as “cache-control headers.”
`Given that webpage content changes, sometimes rather quickly and regularly, a
`27.
`problem that website owners face is effectively instructing a browser that is re-rendering a previously
`cached webpage that one or more of its cached files for that webpage are no longer the correct and
`authorized content (the content of those files has changed) and similarly reauthorizing the use of those
`cached files whose content has not changed.
`On one hand, website owners want to encourage the browsers that render their web
`28.
`pages to use cached files so as to reduce the number of requests for these files that are being made to
`their webpage servers. Therefore, they frequently will set cache-control headers that authorize the
`browser to cache their webpage and asset files so they are on hand when the browser needs to render
`
`
`
`6
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 8 of 20
`
`that webpage again. On the other hand, website owners want the browsers to use the latest authorized
`files so that their users do not see the wrong content when viewing their webpage.
`
`DEFENDANT’S BACKGROUND
`On information and belief, Defendant has operated a website located at slack.com, and
`29.
`has done so since before expiration of the last to expire of the Patents-in-Suit, which has operated to
`provide authorized webpage content to its users in the manner herein described.1
`On information and belief, Defendant’s web servers utilized a system of notifications
`30.
`and authorizations to control the distribution of content, e.g., what webpage content may be served
`from web servers and intermediate caches and what cached webpage content a browser is re-authorized
`to use to render Defendant’s webpage(s).
`On information and belief, Defendant’s system and its associated method of providing
`31.
`webpage content, used “conditional” HTTP GET requests with If-None-Match headers and associated
`content-based ETag values for various webpage and/or asset files required to render various webpages
`of the Defendant.
`On information and belief, Defendant’s system and associated method used these
`32.
`ETags to instruct both the intermediate cache servers and the endpoint caches at browsers to verify
`whether they were still authorized to reuse the previously cached webpage base files of Defendant and
`to instruct them to obtain newly authorized content in rendering Defendant’s webpage when that
`content had changed.
`On information and belief, Defendant thereby reduced the bandwidth and computation
`33.
`required by its origin servers and any intermediate cache servers to field user requests to render
`Defendant’s webpages as those servers only need to serve files whose content has changed. On
`information and belief, this has allowed for the efficient update of cached information only when such
`
`
`1 While the complaint is sometimes written in the present or present perfect tense, all specific
`allegations are directed to the system’s operations and the method’s performance in the relevant time
`period.
`
`
`
`7
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 9 of 20
`
`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
`
`
`content has changed, thereby reducing transaction overhead and bandwidth and allowing the
`authorized content to be served from the nearest cache.
`34. More particularly, on information and belief, each of Defendant’s webpages included
`a webpage base file (e.g., a main or initial HTML file) and one or more asset files referenced in the
`webpage base file. On information and belief, the references in the webpage base file to the asset files
`needed to render the webpage were typically Uniform Resource Identifiers (“URIs”), which each
`typically included a filename, the address of a server from which the asset file could be retrieved, and
`a “path” to the location of that asset file on that server.
`On information and belief, when Defendant created a webpage base file for a webpage,
`35.
`whether dynamic or static, that webpage base file included a sequence of bits and an associated ETag
`value was generated by Defendant by applying a hash function to the sequence of bits; wherein any
`two webpage base files comprising identical sequences of bits had identical associated ETag values.
`Thus, on information and belief, when a webpage base file’s content was changed and a new associated
`ETag value was generated by Defendant, it thereafter instructed the respective service by intermediate
`cache servers or use by endpoint caches such as browser caches to no longer use the previous webpage
`base file’s content.
`On information and belief, when an intermediate cache server or a browser requested
`36.
`a webpage from the Defendant for the first time, it sent an HTTP GET request with the webpage’s
`URI and Defendant’s origin server or an upstream cache server responded by sending an HTTP 200
`(OK) response message containing the webpage base file, along with its respective associated ETag.
`On information and belief, the intermediate cache server or a browser then sent individual HTTP Get
`requests, each with an asset URI that was referenced in the webpage base file, and Defendant’s origin
`server or an upstream cache server responded by sending individual HTTP 200 responses containing
`the requested asset files, along with their respective associated ETags. On information and belief,
`upon receipt of the HTTP 200 responses, the intermediate cache server or browser cached the webpage
`and asset files with their associated URI and associated ETag values and the browser used them in
`rendering the requested web page of the Defendant. On information and belief, the intermediate cache
`servers and browser caches were caused to maintain databases/tables which mapped the URIs of
`
`
`
`8
`COMPLAINT
`
`
`
`

`

`
`
`Case 5:18-cv-05600-BLF Document 1 Filed 09/12/18 Page 10 of 20
`
`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
`
`
`asset/webpage base files to their respective responses and, if applicable, associated cache-control
`headers and ETags.
`On information and belief, by responding to an HTTP GET request for a given webpage
`37.
`by transmitting content of a webpage/asset file with an associated ETag, Defendant instructed the
`browser cache and all intermediate cache servers, to use an HTTP conditional GET request the next
`time that webpage/asset file is requested. More specifically, on information and belief, the browser or
`intermediate cache is instructed to include the ETag in the HTTP conditional GET request with an “If-
`None-Match” header to re-verify that they are still authorized to serve or use that content or determine
`that they are no longer authorized to use that content and therefore must use new content.
`On information and belief, Defendant did this, for example, by causing cache-control
`38.
`headers to be included in HTTP responses containing its webpage/asset files. On information and
`belief, Defendant benefits from using the ETags to control the distribution of its webpage content by
`communicating to a downstream cache and to a browser which of Defendant’s cached webpage base
`files it is reauthorized to serve/use and what newly authorized files it must first obtain in
`serving/rendering Defendant’s webpages.
`39. More particularly, on information and belief, when a browser again requested the
`Defendant’s webpage, the browser, based on the cache-control headers received in the original
`response, sent a conditional GET request with an If-None-Match header using the associated ETag
`value and the URI for the webpage base file so as to be notified whether the browser still had
`Defendant’s authority to render the webpage with its locally cached webpage base file.
`On information and belief, under most circumstances, a responding intermediate cache
`40.
`server, having an ETag for that URI responded to the request by determining whether it had the same
`associated ETag value in its list of associated ETag values for that URI. If it had no ETag value for
`that URI, the request was passed up to an upstream intermediate cache server capable of responding
`or, if none, to the Defendant’s origin server which performed the response.
`On information and belief, if the responding server had the webpage content for that
`41.
`URI and there was a match between the ETag it received in the request with the ETag it currently had
`associated for that URI, it sent back an HTTP 304 (Not Modified) response message; this message
`
`
`
`9
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 11 of 20
`
`notifying the browser that the same webpage content was present at the responding server and that the
`browser was still authorized to use that previously cached webpage base file to render the webpage.
`On information and belief, upon receipt of the HTTP 304 response, the browser accessed the locally
`cached webpage base file in rendering the webpage.
`On information and belief, if the webpage base file’s associated ETag sent by the
`42.
`browser in the conditional GET If-None-Match request did not match the associated ETag maintained
`at the responding server (or other intermediate cache servers further upstream or the origin server) for
`that URI, the responding server sent back an HTTP 200 response along with the new webpage base
`file and its new ETag value. The HTTP 200 response indicated to the browser that it was not
`authorized to use (or serve, in the case of an intermediate cache server receiving the HTTP 200
`response) the previously cached webpage base file. In response to receiving the HTTP 200 response,
`the browser (or intermediate cache server) was instructed to update its respective cache with the new
`webpage base file and associated ETag. The browser subsequently read the new webpage base file
`and the asset file URIs contained therein to render the webpage.
`On information and belief, for a particular asset file URI in the webpage base file for
`43.
`which there was a matching entry in the browser’s cache and that cache entry did not include an
`associated ETag value, the browser was allowed to use the cached content of the previously received
`asset file, subject to the asset file’s cache-control headers. On information and belief, if the cache-
`control headers did not allow the cached asset file content to be re-used or if there was no entry in the
`browser’s cache for the asset file’s URI, the browser sent an HTTP GET request with the asset file’s
`URI; and the responding intermediate or origin server responded to the GET request by sending the
`asset file for that URI and, if any, the corresponding cache-control headers and/or associated ETag
`with an HTTP 200 response. On information and belief, in response to receiving the HTTP 200
`response, the browser cached the asset file, if any, and its cache-control headers and/or associated
`ETag and used the newly received asset files in rendering Defendant’s webpage. On information and
`belief, if the downstream intermediate cache or the browser was later required to again serve or render
`the webpage, it went through the above process to determine which file content it still had authority
`
`
`
`
`10
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 12 of 20
`
`to access or whether it needed to access different authorized content to serve or render the webpage
`via the HTTP 304 and HTTP 200 responses.
`On information and belief, the browser repeated this process for various asset files for
`44.
`which it had an associated ETag value and asset files with URIs in the webpage base file.
`On information and belief, in this manner, Defendant used ETag values based on the
`45.
`asset files’ content to control the behavior of downstream intermediate cache servers and endpoint
`caches to assure that they only accessed and used Defendant’s latest authorized webpage content to
`serve or to render its webpages.
`
`FIRST CLAIM FOR RELIEF
`INFRINGEMENT OF U.S. PATENT NO. 6,928,442
`PersonalWeb repeats and realleges paragraphs 1–47, as if the same were fully stated
`
`46.
`
`herein.
`
`On August 9, 2005, United States Patent No. 6,928,442 (the “’442 patent”) was duly
`47.
`and legally issued for an invention entitled “Enforcement and Policing of Licensed Content Using
`Content-Based Identifiers.” PersonalWeb has an ownership interest in the ’442 patent by assignment,
`including the exclusive right to enforce the ’442 patent within the PersonalWeb Patent Field, and
`continues to hold that ownership interest in the ’442 patent.
`Defendant has infringed at least claims 10 and 11 of the ’442 patent by its manufacture,
`48.
`use, sale, importation, and/or offer for sale of products or services, and/or controlling the distribution
`of its webpage content in the manner described herein. Defendant’s infringement is literal and/or
`under the doctrine of equivalents and Defendant is liable for its infringement of the ’442 patent
`pursuant to 35 U.S.C. § 271.
`For example, claim 10 covers “a method, in a system in which a plurality of files are
`49.
`distributed across a plurality of computers.” On information and belief, Defendant has used a system
`of notifications and authorizations to distribute a plurality of files, e.g., Defendant’s files containing
`content necessary to render its webpages, across a plurality of computers such as production servers,
`
`
`
`
`11
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 13 of 20
`
`origin servers, intermediate cache servers and endpoint caches used by browsers rendering
`Defendant’s webpages.
`Claim 10 then recites the act of “obtaining a name for a data file, the name being based
`50.
`at least in part on a given function of the data, wherein the data used by the function comprises the
`contents of the particular file.” As set forth above, on information and belief, Defendant generated or
`otherwise obtained ETags for its webpage and asset files used to render its webpages using a hash
`function, wherein the ETags were based on the contents of the particular files. Moreover, Defendant
`caused the intermediate caches servers and endpoint caches to obtain the ETags in HTTP 200
`responses sent from Defendant’s origin servers. On information and belief, Defendant caused
`intermediate cache servers and its origin servers to obtain ETags in conditional GET messages from
`endpoint and intermediate caches, as described supra.
`Claim 10 then recites the act of “determining, using at least the name, whether a copy
`51.
`of the data file is present on at least one of said computers.” On information and belief, as set forth
`above, Defendant has caused its origin severs and the intermediate cache servers between an endpoint
`cache and one of its origin servers to, in response to receiving a conditional GET request with an If-
`None-Match header, determine whether it has a file present that matches the URI in the conditional
`GET and to compare the ETag in the conditional GET to the ETag for that URI and determine whether
`a copy of the content having that ETag is present.
`Claim 10 then recites the act of “determining whether a copy of the data file that is
`52.
`present on a at least one of said computers is an unauthorized copy or an unlicensed copy of the data
`file.” On information and belief, as set forth above, if there was a match, the origin or intermediate
`cache server determined that the copy of the file present at the downstream intermediate cache server
`and/or the endpoint cache was an authorized or licensed copy of the data file. Conversely, if there was
`no match, it determined that the copy of the file present at the downstream intermediate cache server
`and/or the endpoint cache was an unauthorized copy of the data file. Likewise, if the browser
`determined that it had a file with a matching URI, the browser determined that it was still authorized
`to use that file.
`
`
`
`
`12
`COMPLAINT
`
`
`
`

`

`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-cv-05600-BLF Document 1 Filed 09/12/18 Page 14 of 20
`
`Defendant’s acts of infringement caused damage to PersonalWeb and PersonalWeb is
`53.
`entitled to recover from Defendant the damages sustained by PersonalWeb as a result of Defendant’s
`wrongful acts in an amount subject