Oracle Corp. v. Parallel Networks, LLP (588 F. Supp. 2d 549, 2008)

MEMORANDUM OPINION

SUE L. ROBINSON, District Judge.

I. INTRODUCTION

On June 30, 2006, Oracle Corporation and Oracle U.S.A. Inc. (collectively, “Oracle” or “plaintiffs”) filed this action for declaratory judgment against EpicRealm Licensing, LP. (D.I. 1) Defendant, a patent licensing firm, is owner and assignee of United States Patent Numbers 5,894,554 (“the '554 patent”) and 6,415,335 (“the '335 patent”), which are directed to a system for creating and managing custom web sites. (Id.; D.I. 10 at 16) Plaintiffs seek a judgment that they do not infringe the '554 or '335 patent, and that both patents are invalid and/or unenforceable. (Id.; D.I. 339) Currently pending before the court are plaintiffs’ motions for summary judgment of noninfringement (D.I. 204), invalidity (D.I. 206), no willful infringement (D.I. 208) and to exclude defendant from asserting damages based on plaintiffs’ foreign sales (D.I. 212). Also before the court are defendant’s motions for partial summary judgment of literal infringement (D.I. 223) and that plaintiffs’ prior art references do not anticipate (D.I. 216).

II. BACKGROUND

A. The Parties and Litigation History

Plaintiffs manufacture, sell and license software products for customers to use in conjunction with the delivery of dynamic web pages.

Defendant previously brought several actions for infringement of the '554 and '335 patents in the United States District Court for the Eastern District of Texas. That litigation was consolidated in November 2005 (hereinafter, “the Texas litigation”). Plaintiffs were not named in the Texas litigation. An Oracle customer, Safelite Group, Inc. (“Safelite”), was named as a defendant. Safelite asserted counterclaims that the '554 and '335 patents are invalid, and filed a third party complaint against plaintiffs for indemnification. Defendant and Safelite settled the Texas litigation and filed a stipulation of dismissal with the court on June 26, 2006. (D.I. 282, ex. 22) A stipulation of dismissal was also filed with respect to Safelite’s third party complaint against plaintiffs. On June 29, 2006, the court entered orders dismissing both complaints. (D.I. 1 at ¶¶ 26-27)

Plaintiffs brought their declaratory judgment suit in this court on June 30, 2006. (Id.) In the complaint, plaintiffs allege that, in a letter to Clark Consulting, Inc. (a party to the Texas litigation), defendant stated that Clark was required to provide discovery regarding Clark’s use of software proprietary to plaintiffs. (Id. at ¶ 24) Plaintiffs also claim that defendant demanded and received discovery from Safelite regarding its use of Oracle software. (Id. at ¶25) Defendant moved to transfer venue and consolidate with the Texas litigation. This court denied defendant’s motions on March 26, 2007. (D.I. 21)

Defendant thereafter answered the complaint on May 3, 2007, in which it admitted an actual controversy exists between the parties for jurisdictional purposes, admitted that it sought discovery from Clark, but denied that it requested discovery specifically relating to Safelite’s use of Oracle software. (D.I. 25 at ¶ 25) Defendant also brought a counterclaim of patent infringement. (Id.) Plaintiffs amended their complaint on October 15, 2007, to add a claim that the '554 and '335 patents are unenforceable due to inequitable conduct. (D.I. 369) Discovery is now closed, and trial is currently scheduled to commence January 12,2009. (D.I. 29)

B. Technological Background and the Patents-at-Issue

The basic three-tiered architecture of the internet includes what is known as a desktop tier, an intermediate tier, and an enterprise tier. The desktop tier is composed of a client program (web browser, such as Microsoft Internet Explorer ®) located on a user’s desktop computer, which sends and receives requests for information over the internet. The intermediate tier comprises one or more web servers, which receive and process user requests and return completed web pages to the client for viewing. The enterprise tier is synonymous with data services; it comprises one or more back-end database servers which store the information used to make web pages.

Formerly, most web sites provided only “static” web pages, or pages whose content was not subject to change. When a web client (a computer with a web browser) identified a web site, the browser program connected to the web, and the web server operating the web site received the request and retrieved the specific file requested by the web client — no file modification occurred. Over time, web sites began to provide dynamic web pages, ie., web pages that are generated anew in response to a specific request of the web client. To generate dynamic web pages, the Common Gateway Interface (“CGI”) was developed. CGI is a protocol for identifying a command, running it, and returning output from a web server. Once created, a CGI application does not have to be modified to retrieve new data and generate a dynamic page; it does so automatically.

The processing of dynamic web pages requires more processor time, memory, and/or other system resources than is the case with static web pages. As the number of users’ dynamic web page requests increased, so too did the demand on web server resources, resulting in slowed response time, failure to provide the requested content, or the crashing of the web server. The tools that generate CGI applications do not solve these problems.

The patents-in-suit disclose systems for efficiently managing dynamic web page generation requests. The architecture of the patented system is depicted in figure 4 of the patents. First, a web client initiates a request for a static or dynamic web page. ('554 patent, col. 4, 11. 55-57) The request is routed to a web server. (Id. at I. 57) Instead of the web server processing the request, an “interceptor” intercepts the request and routes it to a “dispatcher.” (Id. at 11. 58-60) The dispatcher identifies one or more “page servers,” or a server connected to the data source. (Id., col. 5, II. 37-39)

The dispatcher maintains a variety of information on each page server to select the appropriate page server. (Id., col. 5, 11. 54-59) The patents provide several scenarios in which the dispatcher selects a page server. The first is “connection caching,” whereby a dispatcher determines that a particular page server “has access to the requisite data” in the data source. (Id., col. 5, 11. 60-67) Alternatively, the dispatcher may determine that a particular page server “already has the necessary data cached in the page server’s page cache[],” even though another page server may also be logged into the appropriate data source, and select the server containing the cached data. (Id., col. 6, 11. 1-11) Lastly, the dispatcher may determine that multiple page servers are logged into the appropriate data source, in which case the dispatcher will select the “least busy” page server. (Id., col. 6, 11. 12-19) This “load balancing” can “significantly increase performance at a busy web site.” (Id.)

The patents provide that, while a page server is processing the request for data retrieval, the web server is free to concurrently process other web client requests, promoting web site efficiency. (Id., col. 6, 11. 21-27) The page server dynamically generates a web page in response to the web client request, and the web page is either transmitted back to the web client or stored on a machine that is accessible to the web server for later retrieval. (Id. at col. 6,11. 27-31)

Defendant asserts that plaintiffs infringe claims 1-5 and 7-11 of the '554 patent and claims 2 and 16 of the '335 patent. The asserted independent claims of the '554 patent read as follows:

1. A computer-implemented method for managing a dynamic Web page generation request to a Web server, said computer-implemented method comprising the steps of:

routing said request from said Web server to a page server, said page server receiving said request and releasing said Web server to process other requests, wherein said routing step further includes the steps of intercepting said request at said Web server, routing said request from said Web server to a dispatcher, and dispatching said request to said page server;

processing said request, said processing being performed by said page server while said Web server concurrently processes said other requests; and dynamically generating a Web page in response to said request, said Web page including data dynamically retrieved from one or more data sources.

9. A networked system for managing a dynamic Web page generation request, said system comprising:

one or more data sources;

a page server having a processing means;

a first computer system including means for generating said request; and

a second computer system including means for receiving said request from said first computer, said second computer system also including a router, said router routing said request from said second computer system to said page server, wherein said routing further includes intercepting said request at said second computer, routing said request from said second computer to a dispatcher, and dispatching said request to said page server said page server receiving said request and releasing said second computer system to process other requests, said page server processing means processing said request and dynamically generating a Web page in response to said request, said Web page including data dynamically retrieved from said one or more data sources.

11. A machine readable medium having stored thereon data representing sequences of instructions, which when executed by a computer system, cause said computer system to perform the steps of:

routing a dynamic Web page generation request from a Web server to a page server, said page server receiving said request and releasing said Web server to process other requests wherein said routing step further includes the steps of intercepting said request at said Web server, routing said request from said Web server to a dispatcher, and dispatching said request to said page server; processing said request, said processing being performed by said page server while said Web server concurrently processes said other requests; and dynamically generating a Web page, said Web page including data retrieved from one or more data sources.

Claims 2 of the '335 patent depends from claim 1. Those claims read as follows:

1. A computer-implemented method for managing a dynamic Web page generation request to a Web server, said computer-implemented method comprising the steps of:

routing a request from a Web server to a page server, said page server receiving said request and releasing said Web server to process other requests wherein said routing step further includes the steps of:

intercepting said request at said Web server and routing said request to said page server;

processing said request, said processing being performed by said page server while said Web server concurrently processes said other requests; and dynamically generating a Web page in response to said request, said Web page including data dynamically retrieved from one or more data sources.

2. The computer-implemented method in claim 1 wherein said step of routing said request includes the steps of: routing said request from said Web server to a dispatcher; and dispatching said request to said page server.

Asserted claim 16 of the '335 patent depends from claim 15, as follows:

15. A computer-implemented method comprising the steps of: transferring a request from an HTTP-compliant device to a page server, said page server receiving said request and releasing said HTTP-compliant device to process other requests wherein said transferring step further includes the steps of:

intercepting said request at said HTTP-compliant device and transferring said request to said page server; processing said request, said processing being performed by said page server while said HTTP-compliant device concurrently processes said other requests; and

dynamically generating a page in response to said request, said page including data dynamically retrieved from one or more data sources.

16. The computer-implemented method in claim 15 wherein said step of transferring said request includes the steps of: transferring said request from said HTTP-compliant device to a dispatcher; and dispatching said request to said page server.

C. Accused Products

Defendant asserts that the following Oracle products infringe the patents-in-suit: (1) the Oracle Web Cache Products, beginning in November 2000 with Release 1.0.2 and all subsequent releases (“the Web Cache products”); (2) the Oracle Application Server Products beginning in April 2003 with Release lOgRl (9.0.4) and all subsequent releases (“the Application Server products”); (3) the Oracle Database Products with Real Application Clusters (“RAC”) beginning in May 2005 with Release 10gR2 (10.2.0.1.0) for JDBC and all subsequent releases and beginning in October 2007 with Release llg (11.1) for OCI and all subsequent releases (“the Database products”). These products will be discussed in more detail infra in the context of the parties’ infringement/noninfringement arguments.

III. STANDARD OF REVIEW

A court shall grant summary judgment only if “the pleadings, depositions, answers to interrogatories, and admissions on file, together with the affidavits, if any, show that there is no genuine issue as to any material fact and that the moving party is entitled to judgment as a matter of law.” Fed.R.Civ.P. 56(c). The moving party bears the burden of proving that no genuine issue of material fact exists. See Matsushita Elec. Indus. Co. v. Zenith Radio Corp., 475 U.S. 574, 586 n. 10, 106 S.Ct. 1348, 89 L.Ed.2d 538 (1986). “Facts that could alter the outcome are ‘material,’ and disputes are ‘genuine’ if evidence exists from which a rational person could conclude that the position of the person with the burden of proof on the disputed issue is correct.” Horowitz v. Fed. Kemper Life Assurance Co., 57 F.3d 300, 302 n. 1 (3d Cir.1995) (internal citations omitted). If the moving party has demonstrated an absence of material fact, the nonmoving party then “must come forward with ‘specific facts showing that there is a genuine issue for trial.’ ” Matsushita, 475 U.S. at 587, 106 S.Ct. 1348 (quoting Fed.R.Civ.P. 56(e)). The court will “view the underlying facts and all reasonable inferences therefrom in the light most favorable to the party opposing the motion.” Pa. Coal Ass’n v. Babbitt, 63 F.3d 231, 236 (3d Cir.1995). The mere existence of some evidence in support of the nonmoving party, however, will not be sufficient for denial of a motion for summary judgment; there must be enough evidence to enable a jury reasonably to find for the nonmoving party on that issue. See Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 249, 106 S.Ct. 2505, 91 L.Ed.2d 202 (1986). If the nonmoving party fails to make a sufficient showing on an essential element of its case with respect to which it has the burden of proof, the moving party is entitled to judgment as a matter of law. See Celotex Corp. v. Catrett, 477 U.S. 317, 322, 106 S.Ct. 2548, 91 L.Ed.2d 265 (1986).

IV. DISCUSSION

A. Infringement

Defendant moves for partial summary judgment of infringement of the '554 patent, arguing that the accused products infringe because they literally meet every limitation of claim 11 of the '554 patent. (D.I. 224 at 1) Plaintiffs move for summary judgment of noninfringement of both the '554 and the '335 patents, arguing that the accused products do not infringe because they do not literally meet the “intercepting,” “releasing,” and “dispatcher” limitations common to the asserted claims of both patents. (D.I. 204 at 1-2) The parties do not dispute the physical characteristics of the accused products. (D.I. 204 at 1, ¶2; D.I. 224 at 1) Accordingly, the question of whether the accused products literally infringe the patents-in-suit turns on the court’s claim construction and may be resolved on summary judgment. See Gen. Mills, Inc. v. Hunt-Wesson, Inc., 103 F.3d 978, 983 (Fed.Cir.1997).

1. The Accused Products

a. Web Cache products

Web Cache is a cache server, which is a software program designed to maintain a cache, or local store, of frequently used web pages. (D.I. 270 at ¶ 28) Web Cache sits in front of a web server and receives a web client’s request for content before the web server does. (Id. at ¶ 28) If Web Cache has the requested content in its cache (a “cache hit”), Web Cache returns the requested content to the web client. (Id.) Cache hits are handled completely by Web Cache. (Id. at ¶ 30) If Web Cache does not have the requested content in its cache (a “cache miss”), Web Cache sends the web client’s request to a web server for processing. (Id. ¶ 28) The web servers sitting behind Web Cache that originate new content in the event of a cache miss are called “origin servers.” (Id.) Web Cache’s purpose is to cache frequently requested content in order to reduce the load on the origin servers. (Id. at 1132)

Web Cache performs its caching function by assigning each received web request to a “fiber” within the Web Cache program. (Id.) Each fiber is an independent unit of execution. (Id.) Web Cache fibers that connect to web clients and search the cache for requested content are called “Front End” fibers. (Id.) Web Cache fibers that connect to an origin server and add new content to the cache are called “Back End” fibers. (Id.)

When Web Cache receives a request from a web client, Web Cache first creates a new Front End fiber to handle that request. (Id. at ¶ 33) The Front End fiber then compares the Universal Resource Locator (“URL”) of the request to the URLs of previously-requested content stored in the cache. (Id. at ¶ 34) If the comparison yields a cache hit, the Front End fiber returns the requested content to the web client and the processing is complete. (Id.) Web Cache then, unless commanded otherwise, destroys the Front End fiber. (Id.)

If the URL comparison yields a cache miss, then Web Cache creates a Back End fiber, which communicates the URL of the request to an origin server and then waits for the origin server to process the request and return the content. (Id. at ¶ 35) The Front End and Back End fibers wait until either the origin server returns the requested content or a time-out error occurs. (Id.) Once the origin server locates the requested content, it returns the content to the web client via the Front End and Back End fibers, and the content is inserted into the cache so that Web Cache can satisfy future requests for the same content without involving an origin server. (Id. at ¶ 36) Web Cache then destroys the Front End and Back End fibers. (Id.)

Web Cache can be configured in several different ways. (Id. at ¶30) Users can configure a system to use a single Web Cache in front of multiple origin servers, with Web Cache maintaining a cache of content requested from each origin server and distributing cache misses among the multiple origin servers. (Id. at ¶ 31)

During normal operation, Web Cache receives TCP acknowledgments from Oracle HTTP Server (“OHS”) (id. at ¶58), which is the web server component of the Application Server products to be discussed hereafter (id. at ¶ 75).

During TCP communication between two computers, the operating system of the receiving computer will, upon receiving a TCP segment, transmit a transport layer acknowledgment (“ACK”) message. (Id. at ¶ 66) If the sending computer does not receive the ACK message within a certain time, it will resend the TCP segment. (Id.) Once the sending computer receives the ACK message, it discards the received packets from the TCP memory buffer, which frees some of the memory allocated to the TCP buffer by the operating system. (Id. at ¶¶ 66, 68)

b. Application Server products

The Application Server products contain multiple software programs, such as OHS and Oracle Containers For Java (“OC4J”). (Id. at ¶ 75) OHS is the web server component of the Application Server products. (Id.) The OHS software program contains several built-in functions, including the HTTP Listener and a collection of modules. (Id.) The HTTP Listener receives incoming web client requests and passes them to the appropriate processing module. (Id. at ¶ 76) The modules perform various functions related to the processing of web client requests. (Id. at ¶ 77)

In the default configuration, there are 256 instances, or copies, of the OHS program. (Id. at ¶ 81) Where Web Cache is not present or where a web client’s request is a cache miss, one of the instances of OHS accepts the web client’s request for processing. (Id.) The OHS instance processes the request by calling each module in the order in which the modules were loaded into memory when the OHS program was first started. (Id. at ¶ 82) When it calls a module, the OHS instance compares the URL of the request against a list of types of web page content to determine whether the request is the type of request that the module is designed to process. (Id.) Once the OHS instance identifies the correct module to use, the OHS instance processes the request using that module. (Id.)

If the OHS instance calls all of the modules and no module is capable of processing the request, the OHS instance will attempt to satisfy the request by accessing the content from the computer’s local storage, e.g., files on the computer’s hard drive. (Id. at ¶ 88) If the OHS instance cannot satisfy the request from accessing the local storage, then the OHS instance will send an error message to the web client indicating that the requested content was not found. (Id.) Once the OHS instance either sends the requested web page content or an error message, the OHS instance is done processing the request. (Id.)

One of OHS’s modules, mocLoc4j, enables OHS to communicate with OC4J. (Id. at ¶ 78) OC4J is designed to contain a user’s Java-based software applications. (Id. at ¶ 80) A user using OC4J would design a Java-based software application and then use OC4J to run that application when it is requested by a web client. (Id.) When a web client requests content that requires processing by a Java-based software application, and that request is not handled by Web Cache, an OHS instance uses mod_oc4j to route those requests to an OC4J program. (Id. at ¶ 79) The OHS instance then waits until OC4J returns the completed request. (Id. at ¶ 84) Once OC4J has returned the requested content to the OHS instance, the OHS instance sends the requested content to the web client. (Id.) Because OHS instances can process only one request at a time, requests made while an OHS instance is engaged in responding to a request — either processing the request itself or waiting for some other component to process the request — must be handled by some other OHS instance. (Id. at ¶¶ 84-85)

Users of the Application Server products can change some of the configuration details concerning how mod_oc4j communicates with OC4J instances. (Id. at ¶ 86) As an initial matter, users must configure OHS with mod_oc4j. (Id.) Having done that, where users have also configured the Application Server product to have more than one OC4J instance, mod_oc4j will load balance requests among the multiple OC4J instances. (Id.) Users can configure mod_oc4j to perform one of eight different load balancing policies: Random, Round Robin, Random with Local Affinity, Round Robin with Local Affinity, Random using Routing Weight, Round Robin using Routing Weight, Metrics Based, and Metric Based with Local Affinity. (Id.)

Round Robin is the default load balancing configuration. (Id. at ¶ 87) Round Robin is based on a simple sequential algorithm. (Id. at ¶ 89) Mod_oc4j maintains a list of the OC4J instances and sends requests to those OC4J instances according to their listed order. (Id.) If the OC4J instance slated to handle the next request is still busy processing a previously-received request, then mod_oc4j will skip over it and send the request to the next available OC4J instance on the list. (Id.)

Metrics Based and Metric Based with Local Affinity are the only two load balancing configurations that enable mod_oc4j to route requests based on metrics from OC4J instances. (Id. at ¶ 87) To use either of these load balancing configurations, the user must reconfigure mod_oc4j. (Id.)

c. Database products

The Database products consist primarily of a Relational Database Management System (“RDBMS”). (Id. at ¶ 126) An RDBMS is a package of software programs that control organization, storage, management, and retrieval of data in a database based on a relational model. (Id.) An RDBMS primarily services requests for data stored in the database. (Id.) Those requests are typically made in the form of database queries, which are requests for data that are made in a language that the database management system can understand. (Id.)

The Database products do not store web pages. (Id. at ¶¶ 127-128) Data retrieved from the Database product may be displayed in a web browser as part of a web page, but the web page is typically constructed by a separate application (e.g., OC4J or mocLplsql) or by a web client’s browser. (Id. at ¶ 127) For example, where the Database product is working in conjunction with the Application Server product, a web client request seeking Java-based content will pass from OHS to OC4J using mod_oc4j. (Id. at ¶ 128) OC4J can retrieve data from the Database product via an application programming interface (“API”) called JDBC and then construct a web page incorporating the database data. (Id.)

Application servers and other database clients can connect to and query the Database products in several ways. (Id. at ¶ 129) API is one such way. (Id.) API is not a separate executable software program; rather, it is a set of standardized function calls that permit a software program to issue high-level commands through a library that is linked into the program. (Id.) JDBC is an industry standard set of APIs that provide the interface for connecting from Java applications to relational databases, like the Database products, to issue database queries. (Id. at ¶ 130) C and C++ applications can also connect to the Database products using APIs called Oracle Call Interface (“OCI”) and the Oracle C++ Call Interface (“OCCI”), respectively. (Id. at ¶ 131) For example, OCI consists of a set of C-language software APIs that provide a low-level interface to the database. (Id.) OCI has APIs for administering the database (including system start-up and shutdown) and for using PL/SQL or SQL to query, access, and manipulate data. (Id.) Both JDBC and OCI are libraries that enable OHS to issue commands to the Database products. (Id.) Both the Application Server products and the Database products contain software code for these libraries. (Id.)

Oracle Real Application Clusters (“RAC”) is a database option in which a single database is accessed by multiple instances on multiple computers, or “nodes.” (Id. at ¶ 132) Atypical RAC instance groups multiple database instances running on multiple nodes. (Id.) These nodes communicate with each other and share a common pool of disks. These disks house all of the data files that comprise the database. (Id.) A RAC database instance can generate a web page. (Id. at ¶ 139)

2. Establishing Infringement

To establish direct infringement, “every limitation set forth in a claim must be found in an accused product, exactly.” Southwall Tech., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1575 (Fed.Cir.1995). “If any claim limitation is absent from the accused device, there is no literal infringement as a matter of law.” Bayer AG v. Elan Pharm. Research Corp., 212 F.3d 1241, 1247 (Fed. Cir.2000). Significant to the case at bar, if an accused product does not infringe an independent claim, it also does not infringe any claim depending thereon. Wahpeton Canvas Co. v. Frontier, Inc., 870 F.2d 1546, 1553 (Fed.Cir.1989).

To establish indirect infringement, defendant has available two theories: active inducement of infringement and contributory infringement. See 35 U.S.C. § 271(b) & (c). To establish active inducement of infringement, defendant must show that plaintiffs “knew or should have known [their] actions would induce actual infringements.” DSU Med. Corp. v. JMS Co., Ltd., 471 F.3d 1293, 1306 (Fed. Cir.2006). To establish contributory infringement, defendant must show that plaintiffs sell “a component of a patented machine ... knowing the same to be especially made or especially adapted for use in an infringement of such patent, and not a staple article or commodity of commerce suitable for substantial noninfringing use.” Golden Blount, Inc. v. Robert H. Peterson Co., 365 F.3d 1054, 1061 (Fed.Cir.2004) (quoting 35 U.S.C. § 271(c)). Liability under either theory, however, depends on defendant having first shown direct infringement. Joy Technologies, Inc. v. Flakt, Inc., 6 F.3d 770, 774 (Fed.Cir.1993).

3. Direct Infringement

The court’s infringement analysis begins and ends with the “releasing” limitation. This is so because the “releasing” limitation is common to the asserted claims of both patents, and its absence from the accused products is dispositive of both plaintiffs’ and defendant’s infringement motions. In other words, because the court does not find, on the record at bar, a genuine issue of material fact with respect to whether the accused products literally meet the “releasing” limitation, the accused products do not infringe.

The court construes the “releasing” limitation as follows: “said page server receiving said request and releasing said Web server to process other requests” means “freeing the Web server to process other requests.” Defendant presents two basic infringement paradigms through which it argues that the accused products meet the “releasing” limitation. One paradigm treats Web Cache as the “Web server” and OHS (the web server software program within the Application Server products) as the “page server.” The other paradigm treats OHS as the “Web server” and either OC4J or a RAC database instance as the “page server.” Defendant argues that, in both paradigms, the “page server” frees the “Web server” to process other requests.

Defendant posits two theories for “releasing” that it applies to both paradigms. Defendant’s first theory (“the delegation theory”) is that a “page server” processing a request frees the “Web server” to process other requests because the “Web server” no longer has the duty to process that request. (D.I. 224 at 19, 26, 34) Put another way, once a “Web server” delegates the processing of a request to a “page server,” the “Web server” is then freed to process other requests. (D.I. 324 at 11-12) Defendant’s second theory (“the ACK theory”) is that, by acknowledging receipt of a request by sending an ACK message, a “page server” frees the “Web server” from having to further process the request and enables it to instead process other requests. (D.I. 224 at 20, 26-27, 34) Put another way, the “Web server” devotes resources to a request until the “page server” acknowledges via an ACK message that the “page server” will process the request; if the “Web server” receives the ACK message, the “Web server” then knows that it can stop devoting resources to processing that request and can devote resources to processing other requests. (D.I. 324 at 12-13) The evidence to which the parties cite, however, shows that the accused products do not function consistent with these theories.

a. “Releasing” where Web Cache is-the “Web Server”

Where Web Cache is considered to be the “Web server” and OHS the “page server,” defendant argues that Web Cache is freed to process other requests by either OHS’s processing of a request or its sending of an ACK message to Web Cache. (D.I. 224 at 34) However, Web Cache’s source code does not support defendant’s arguments.

Web Cache processes requests using a finite number of Front End and Back End fibers. For each request it receives, Web Cache creates a Front End fiber and, in the event of a cache miss, a Back End fiber. Web Cache functions as a “Web server” only through these fibers.

The fibers for each request function independently from the fibers for any other request. Web Cache may process several requests simultaneously using different Front End and Back End fibers but, as plaintiffs’ expert, Dr. Paul C. Clark, explains from the source code, no set of fibers may ever be tasked to more than one request at a time. Freeing Web Cache to process other requests, then, would require OHS (the “page server”) to free the set of fibers assigned to a particular request to process other requests. Web Cache’s source code, however, establishes that the Front End and Back End fibers assigned to each request always wait — that is, they do not process any other request — until OHS has processed and returned the request or a time-out occurs. Other Web Cache fibers were never tasked with processing that particular request in the first instance and so cannot be “freed” by OHS’s processing of that request. Forwarding, or “delegating,” the request to OHS, then, does not free Web Cache to process other requests.

Neither does OHS sending an ACK message to Web Cache free it to process other requests. Plaintiffs and defendant agree that OHS’s sending of an ACK message frees TCP buffer memory in Web-Cache. Plaintiffs, however, present evidence that freeing TCP buffer memory has no effect on processing other requests. First, releasing TCP buffer memory does not affect web server functionality and so does not free Web Cache to process other requests. Second, even if an ACK message could affect web server functionality, it does so only for that fiber tasked with processing that request; because the fibers function independently and only ever process one request at a time, this means that receiving an ACK message from OHS has no effect on Web Cache’s ability to process other requests.

Defendant in rebuttal does not cite to anything beyond Finkel’s declaration and its own claim construction analysis, neither of which presents a detailed analysis of Web Cache’s function. The court finds that this is insufficient to create a genuine issue of material fact with respect to whether the accused products meet the “releasing” limitation where Web Cache is considered to be the “Web server.”

b. “Releasing” where OHS is the “Web Server”

Similar to its Web Cache argument, defendant argues that, where OHS is considered to be the “Web server” and either OC4J or a RAC database instance the “page server,” OHS is freed to process other requests by either OC4J or the RAC database instance processing of a request or sending an ACK message to Web Cache. (D.I. 224 at 19-20, 26) However, as with Web Cache, OHS’s source code does not support defendant’s arguments.

OHS’s instances receive and process requests. OHS functions as a “Web server” only through these instances, which function independently. OHS’s source code reveals that each OHS instance can process only one request at a time. Thus, freeing OHS to process other requests would require the “page server” to free the OHS instance assigned to a particular request to process other requests. The source code also reveals that, where an OHS instance forwards a request to OC4J or a RAC database instance, the OHS instance is unavailable to process another request until it returns the completed request or an error message. Forwarding, or “delegating,” the request to the “page server” does not free the OHS instance to process other requests.

Neither does the “page server” sending an ACK message to OHS free it to process other requests. Here again, plaintiffs and defendant agree that the “page server” sending an ACK message frees TCP buffer memory in OHS. However, as with Web Cache, plaintiffs present evidence that freeing TCP buffer memory has no effect on processing other requests. First, releasing TCP buffer memory does not allow an OHS instance to process other requests; as the source code reveals, an OHS instance only ever processes one request at a time and always waits for the “page server,” irrespective of whether an ACK message frees its TCP buffer memory while it waits. Second, OHS instances have their own individual TCP buffers and do not share TCP connections. Thus, one OHS instance receiving an ACK message cannot free another OHS instance to process other requests.

Defendant cites Clark’s deposition testimony and the testimony of plaintiffs’ expert, Dr. Michael Ian Shamos, for the proposition that receipt of ACK messages frees resources. Even accepting that as true, defendant cites no evidence suggesting that the freeing of resources equates to the freeing of an OHS instance to process additional requests. Defendant otherwise in rebuttal does not cite to anything beyond Finkel’s declaration and its own claim construction analysis, neither of which presents a detailed analysis of OHS’s function. The court finds that defendant’s evidence is insufficient to create a genuine issue of material fact with respect to whether the accused products meet the “releasing” limitation where OHS is considered to be the “Web server.”

3. Indirect Infringement

Because plaintiffs do not directly infringe the patents-in-suit, plaintiffs cannot be found to indirectly infringe the patents-in-suit.

B. Validity

1. Collateral Estoppel

As a threshold matter, defendant asserts that collateral estoppel prevents plaintiffs from asserting invalidity in this case based upon the Texas litigation.

The party seeking to invoke collateral estoppel bears the burden, Dici v. [Commonwealth of] Pennsylvania, 91 F.3d 542, 548 (3d Cir.1996), of showing the following four elements are present: (1) the previous determination was necessary to the decision; (2) the identical issue was previously litigated; (3) the issue was actually decided in a decision that was final, valid, and on the merits; and (4) the party being precluded from relitigating the issue was adequately represented in the previous action.

Novartis Pharmaceuticals Corp. v. Abbott Laboratories, 375 F.3d 1328, 1333 (Fed. Cir.2004) (quoting Hawksbill Sea Turtle v. FEMA 126 F.3d 461, 475 (3d Cir.1997)).

In the Texas litigation, Safelite asserted invalidity counterclaims against defendant, subsequently filed a third party complaint against plaintiffs for indemnification and, shortly thereafter, settled the case. Pursuant to the stipulation of dismissal filed in the Texas litigation, Safelite agreed to dismiss all of its claims against defendant with prejudice. Plaintiffs contributed a third of the cost of Safelite’s settlement with defendant. (D.I. 281 at 10-11) The parties dispute, however, whether plaintiffs’ payment to Safelite was pursuant to an indemnity agreement, in other words, whether plaintiffs were in privity with Safelite when its invalidity claim was settled and dismissed.

The court need not address this particular issue, insofar as it is clear on all other relevant grounds that collateral estoppel is inappropriate in this case. Defendant does not, and cannot, argue that the validity of the '554 and/or '335 patents was “previously litigated,” or that any “determination” on validity was ever made by a judge or jury. The fact that the court ordered a dismissal with prejudice in the Texas litigation, pursuant to the parties’ stipulation, has no bearing on whether “the merits” of the validity issues were ever “decided” in a final decision for collateral estoppel purposes. Defendant’s argument to the contrary warrants no further comment.

2. Anticipation

Plaintiffs move for summary judgment that the following references anticipate the '554 and '335 patents: (1) the Oracle Webserver 1.0 product (“Oracle 1.0”); (2) the Oracle Webserver 2.0 product (“Oracle 2.0”); (3) U.S. Patent No. 6,249,241 to Popp et al. (“Popp”); (4) Lagoze et ah, Dienst: “Implementation and Reference Manual,” Cornell University Technical Report TR-95-1514 (May 5, 1995) (“Dienst”); and (5) any of the foregoing in combination with Garland et al, “Implementing Distributed Server Groups for the World Wide Web,” Carnegie Mellon University, Technical Report CMU-CS-95-114 (January 25, 1995) (“Garland”). Defendant’s motion for partial summary judgment of no anticipation is not in alignment with plaintiffs’ motion. Defendant moves for judgment that the following references describing Oracle 1.0 and Oracle 2.0 do not, themselves, anticipate the claims: (1) “Oracle Webserver User’s Guide, Release 1.0, Part No. A34986-2” (the “1.0 User’s Guide”); (2) “The Oracle Webserver: A Technical Discussion” (hereinafter, “Reference 503”); (3) “Understanding SQL*Net,” Release 2.2, part no. A32090-1 (“SQL*Net 2.2”); (4) “Understanding SQL*Net,” Release 2.3, part no. A42484-1 (“SQL*Net 2.3”); all of which are relevant to Oracle 1.0, and (5) “Oracle Webserver 2.0, Technical Note, March 1996” (hereinafter, “Reference 605”); and (6) the “Oracle Webserver User’s Guide Release 2.0 Production,” Part No. A23646-1 (the “2.0 User’s Guide”), which describe Oracle 2.0.

a. Anticipation standards

Under 35 U.S.C. § 102(a), “a person shall be entitled to a patent unless the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the application for patent.”

A claim is anticipated only if each and every limitation as set forth in the claim is found, either expressly or inherently described, in a single prior art reference. Verdegaal Bros., Inc. v. Union Oil Co., 814 F.2d 628, 631 (Fed.Cir.1987).

Anticipation requires that each limitation of a claim must be found in a single reference. Although [the Federal Circuit has] permitted the use of additional references to confirm the contents of the allegedly anticipating reference, ... we have made clear that anticipation does not permit an additional reference to supply a missing claim limitation.

Teleflex, Inc. v. Ficosa North America Corp., 299 F.3d 1313, 1335 (Fed.Cir.2002). That is, additional references may be used only to shed light on what a prior art reference would have meant to those skilled in the art at that time, not for a specific teaching, as this would be indicative of an attempt to improperly “combine the teachings of the references to build an anticipation.” Studiengesellschaft Kohle, m.b.H. v. Dart Industries, Inc., 726 F.2d 724, 727 (Fed.Cir.1984).

A single prior art reference may expressly anticipate a claim where the reference explicitly discloses each and every claim limitation. However, the prior art need not be ipsissimis verbis (i.e., use identical words as those recited in the claims) to be expressly anticipating. Structural Rubber Prods. Co. v. Park Rubber Co., 749 F.2d 707, 716 (Fed.Cir.1984).

A single prior art reference also may anticipate a claim where one of ordinary skill in the art would have understood each and every claim limitation to have been disclosed inherently in the reference. Continental Can Co. USA Inc. v. Monsanto Co., 948 F.2d 1264, 1268 (Fed. Cir.1991). The Federal Circuit has explained that an inherent limitation is one that is necessarily present and not one that may be established by probabilities or possibilities. Id. That is, “the mere fact that a certain thing may result from a given set of circumstances is not sufficient.” Id. “[I]nherency operates to anticipate entire inventions as well as single limitations within an invention.” Sobering Corp. v. Geneva Pharms. Inc., 339 F.3d 1373, 1380 (Fed.Cir.2003). The recognition of an inherent limitation by a person of ordinary skill in the art before the critical date is not required to establish inherent anticipation. Id. at 1377.

An anticipation inquiry involves two steps. First, the court must construe the claims of the patent in suit as a matter of law. Key Pharms. v. Hercon Labs. Corp., 161 F.3d 709, 714 (Fed.Cir.1998). Second, the finder of fact must compare the construed claims against the prior art to determine whether the prior art discloses the claimed invention. Id.

b. The references’s availability as prior art

i. The patents’ priority date

At issue in both motions is whether defendant is entitled to a priority date of earlier than April 23, 1996, the patents’ filing date. Defendant argues that plaintiffs cannot prove that any of their asserted references antedate its invention. Defendant claims that the inventions were conceived in August 1995 and reduced to practice as early as November 1995. More specifically, defendant claims that “Virtuoso,” later renamed the “ForeSite Application Server,” was the first commercial embodiment of the claimed inventions. (D.I. 218 at 21) Plaintiffs contend that defendant has offered no proof that Virtuoso embodied all of the elements of the claimed inventions. (D.I. 267 at 18)

Defendant’s evidence regarding prior invention may be summarized as follows: (1) Keith Lowery, named co-inventor of the '554 and '335 patents, testified at his deposition that he had all of the pieces of the invention working in experimental form sometime between August and October 1995 (D.I. 222, ex. 24 at 53); (2) Lowery sent a draft of a conceptual description of a product to a Bob West on September 15, 1995 (D.I. 221, ex. 17 at EPIC000172); (3) on October 15, 1995, InfoSpinner, Inc., a company formed to develop the invention, published a press release entitled “In-foSpinner Status” which defendant asserts discusses the development of the claimed inventions (D.I. 221, ex. 15); (3) Lowery testified that he demonstrated a prototype of the application server product to Software AG in January 1996 (D.I. 222, ex. 24 at 113); and (4) on February 28, 1996, InfoSpinner signed a distribution agreement with Software AG for Virtuoso (Id., ex. 18). All of these events precede the patents’ April 23,1996 priority date.

Plaintiffs assert that defendant is not entitled to an earlier priority of invention. Plaintiffs point to several pieces of evidence in support of their position: (1) named co-inventor Andrew Levine testified that the InfoSpinner press release did not disclose a dispatcher and page servers (D.I. 272, ex. 77 at 104-05); and (2) Shamos declared that he has reviewed defendant’s proffered evidence and does “not believe such evidence supports an invention date earlier than the filing date ... For example, none of the documents ... discloses the claimed step of the page server ‘releasing’ the Web server, which all the asserted claims require.” (D.I. 271 at ¶ 46 n. 3). (D.I. 267 at 17-18) Shamos’s statement is highly conclusory and, taken alone, would not withstand summary judgment. Levine’s testimony, however, suffices to raise a genuine issue of material fact with respect to whether the claimed invention was conceived prior to April 1996.

ii. Public availability of Oracle 1.0 and Oracle 2.0

Defendant asserts that neither Oracle 1.0 or Oracle 2.0 are prior art because Oracle cannot prove that the products were known or used by others in this country. (D.I. 219 at 19-20) Katrina Mon-tinola, plaintiffs’ Director of Engineering in the Network Products Division from 1990 to 1996, submitted a declaration in which she states that Oracle 1.0 was functional by the end of July 1995, released to the public in beta form on September 25, 1995 and was commercially released in October 1995. (D.I. 268 at ¶¶5-6, 8) In support, Montinola references a press release dated September 25, 1995, stating that Oracle 1.0 (“Web Server”) had been released (in beta form) the week prior at the “International Oracle User Group conference” (id.; D.I. 214, ex. 53), and a copy of her presentation on Oracle 1.0 given at that conference (D.I. 214, ex. 41). She also cites an October 30, 1995 press release stating that Oracle 1.0 was “formally launched” to the public at large on that date. (Id., ex. 55)

Montinola also states that Oracle 2.0 was disclosed to the public in February 1996. (Id. at ¶ 13) In support, she relies upon a press release dated February 21, 1996, stating that plaintiffs unveiled Oracle 2.0 at “Internet Expo '96” that same day. (Id.; D.I. 214, ex. 58) The foregoing establishes that defendant is not entitled to judgment that plaintiffs cannot prove that Oracle 1.0 or Oracle 2.0 are statutory prior art.

iii. Publication date of the relevant documentary references

Several of the documentary references at issue are undated or contain only the year of copyright on their face. In her declaration, Montinola provides the following publication dates for the references at issue.

(1) the 1.0 User’s Guide: October 30, 1995

(2) Reference 503: September 25, 1995

(3) SQL*Net 2.2: August 1995

(4) SQL*Net 2.3: March 1996

(5) Reference 605: March 1996

(6) the 2.0 User’s Guide: April 1996

(D.I. 268 at ¶¶ 6, 7, 9,16)

Montinola’s proffered date for the 1.0 User’s Guide coincides with the formal launch of Oracle 1.0, as described by the references discussed supra. The proffered date for the 2.0 User’s Guide actually post-dates the February 1996 public “unveiling” of Oracle 2.0; Montinola states that Oracle 2.0 was commercially released no later than April 1996. (Id. at ¶ 15) The court is satisfied that Montinola’s proffered testimony creates an issue of fact with respect to the publication dates of the references at issue in this case. Defendant is not entitled to judgment that plaintiffs cannot prove that Oracle 1.0 or Oracle 2.0 are statutory prior art.

c. Oracle 1.0

i. Background

According to the 1.0 User’s Guide, Oracle 1.0 operated in the following manner. A user’s web browser sent a request to the “Oracle Web Listener,” or “a commercial quality HTTP server that services document requests.” (D.I. 214, ex. 40 at ORCL000022) The Web Listener could handle a large amount of simultaneous requests. (Id.) First, the Web Listener “determines whether th[e] request is for a static document or a dynamic document. If the request is for a static document, the Web Listener sends the file and the associated type information directly to the client. If the request is for a dynamic document, it is created ‘on the fly’ by a program invoked by the Web Listener, in compliance with [CGI].” (Id.) This program was called the “Oracle Web Agent.” Once the Web Listener starts the Web Agent, the Web Listener “makes several environment variables available to the Web Agent in compliance with the CGI specification.” (Id. at ORCLOOOH5)

The Web Agent then connects to the “Oracle7 Server.”

In order to connect to an Oracle 7 server, the Web Agent requires certain information, such as which server to connect to and what username and password to use. This information is stored ... as part of a Web Agent service. The Web Agent determines which service to use by parsing the ... environment variable ... set up by the Web Listener[.]

(Id.) The Oraele7 Server executes the PL/ SQL procedure that was specified as part of the request. (Id.)

ii. “Dispatching”

The parties’ primary disagreement with respect to Oracle 1.0 and Oracle 2.0 is whether either performed “dispatching” as required by the claims. By its order of the same date, the court has construed “dispatching said request to said page server” as that limitation appears in the asserted claims as “[analyzing a request to make an informed selection as to which page server should process the request based on a variety of information (both static and dynamic), and sending the request to the selected page server.”

In describing Oracle 1.0, plaintiffs rely primarily on the 1.0 User’s Guide, which they also assert discloses “dispatching” as required by the claims. However, plaintiffs also rely upon SQL*Net 2.2 and SQL*Net 2.3 in support for their argument that Oracle 1.0 performs “dispatching” using SQL*Net. (D.I. 207 at 13; D.I. 257 at ¶¶ 50-52) According to plaintiffs, the Web Agent is the dispatcher in Oracle 1.0. It is a “separate program” invoked by the Web Listener when a request for a dynamic document is received. (D.I. 207 at 12) Plaintiffs cite the declaration of Shamos, who relies upon the following passage from the 1.0 User’s Guide:

The Oracle Web Agent is a program that is invoked by the Oracle Web Listener when a request for a database procedure is received. It handles the details of making a connection to the Oracle7 Server. A Web Agent will connect to a single Oracle7 Server, using a specific database username and password which are specified as part of a Web Agent service. To connect to different servers, or different schemas on the same server, multiple Web Agent services may be configured on a single Oracle Webserver....

(D.I. 207 at 12; D.I. 257 at ¶ 48, citing D.I. 214, ex. 40 at ORCL000023) Additionally, the 1.0 User’s Guide provides that “[w]hen a request from a Web browser comes in, the Web Listener will extract the service name that is embedded in the URL and find out which parameters to use by reading the owa.cfg [configuration] file.” (D.I. 214, ex. 40 at ORCLOOOU7) Shamos states that this configuration file is dynamic information used to make an informed choice of which Web Agent service is to be invoked to process the request. (D.I. 257 at ¶ 48)

Defendant argues that the Web Agent does not make an “informed selection” because there is only one Oracle7 (page) server that is capable of processing a given request; the Web Agent makes the “only” selection it can possibly make. (D.I. 281 at 16; D.I. 273 at ¶ 41) Shamos admits that an “informed selection” cannot occur absent multiple page servers. Plaintiffs point out, however, that the 1.0 User’s Guide states that the Web Agent can connect to one of a variety of different database servers:

A Web Agent will connect to a single Oracle7 server, using a specific database username and password which are specified as part of a Web Agent service. To connect to different servers, or different schemas on the same server, multiple Web Agent services may be configured on a single Oracle Web Server.

(D.I. 214, ex. 40 at ORCL000023) (emphasis added) The more technical section of the 1.0 User’s Guide, that explaining precisely “[h]ow the Oracle Web Agent [w]orks,” provides:

1. The Web Agent connects to the Oracle? server. In order to connect to an Oracle7 server, the Web Agent requires certain information, such as which server to connect to and what username to use. This information is stored in the owa.cfg file ... as part of a Web Agent Service.

(Id. at ORCLOOOH4) (emphasis added) Plaintiffs state, without further support, that the foregoing demonstrates that Oracle 1.0 chooses from more than one page server and, therefore, meets the “dispatching” limitation. (D.I. 320 at 16) In its own motion, defendant argues that the 1.0 User’s Guide discloses only one server, also without citing any testimony in support. (D.I. 219 at 24; D.I. 323 at 6-7) Absent any direct evidence regarding how a person of ordinary skill in the art would interpret the foregoing disclosure and, more importantly, absent any indication of a lack of a genuine issue of material fact on this point, the court declines to grant judgment in favor of either party with respect to the 1.0 User’s Guide.

iii. “Dispatching”: plaintiffs’ alternate theory

Plaintiffs have an alternative theory on why the “dispatching” limitation is met. The 1.0 User’s Guide states that SQL*Net may optionally be used between the Web Agent and the Oracle7 server. (D.I. 214, ex. 40 at ORCL000022) Shamos relies on SQL*Net 2.2 to describe what he terms “SQL*Net dispatching.” As described by SQL*Net 2.2, a “Network Listener” receives a request and has several options on how to establish connections and route the request. (D.I. 214, ex. 49 at ORCL0180664, fig. A-9) Shamos opines that “dispatching” also occurred using the method of load balancing described in SQL*Net 2.3, which describes a later version of SQL*Net. (D.I. 257 at ¶ 52; D.I. 214, ex. 50 at ORCL01808646-47)

The court finds that plaintiffs’ use of multiple references to describe the purported “dispatching” function of the Web Agent of Oracle 1.0 falls into the category of conduct prohibited by Studiengesells-chaft Kohle. 726 F.2d at 727. The references to SQL*Net present in the 1.0 User’s Guide are limited and general. Plaintiffs do not offer SQL*Net 2.2 (or SQL*Net 2.3) to shed light on SQL*Net generally, but to make the argument that a specific function of SQL*Net constitutes “dispatching” in and of itself. Plaintiffs may certainly use the discussion of SQL*Net in the 1.0 User’s Guide in a motivation to combine argument under 35 U.S.C. § 103, but it may not broaden anticipation so as to reach their alternative argument regarding “dispatching” in this manner. For this reason, the court grants defendant’s motion for partial summary judgment of no anticipation based on the 1.0 User’s Guide in combination with SQL*Net 2.2 or SQL*Net 2.3. Because plaintiffs do not assert that either SQL*Net 2.2 or SQL*Net 2.3 are, in and of themselves, anticipatory references, the court also grants defendant’s motion of no anticipation by either SQL*Net 2.2 or SQL*Net 2.3.

d. Oracle 2.0

With respect to Oracle 2.0, plaintiffs rely interchangeably upon the 2.0 User’s Guide and Reference 605 in support of their anticipation arguments. Nowhere in their papers do plaintiffs clearly assert that either reference discloses all of the claimed limitations. Plaintiffs predominantly discuss the 2.0 User’s Guide in their arguments. Plaintiffs cite both references for their purported disclosures of “dispatching.” (D.I. 207 at 21) In their own motion, plaintiffs rely solely on Reference 605 for the “intercepting” limitation (id, citing D.I. 214, ex. 44; D.I. 257 at ¶¶ 86-87), but cite a portion of the 2.0 User’s Guide in response to defendant’s motion (D.I. 267 at 36, citing D.I. 214, ex. 42 at ORCL01816643).

There is no indication that plaintiffs are attempting to use one reference to broadly shed light on the disclosure of the other, such as may constitute a limited exception to the prohibition against using multiple references for anticipation. Plaintiffs’ motion for summary judgment of anticipation based on Oracle 2.0 must be denied for this fundamental reason. The court will turn to defendant’s motion for partial summary judgment that the 2.0 User’s Guide and Reference 605 do not anticipate the claims at issue.

i. Background

As described by Reference 605, Oracle 2.0 comprises a Web Listener, Web Request Broker, including a Web Request Broker Dispatcher (“WRB Dispatcher”) and Web Request Broker Engines (“WRBXs”), and the Webserver SDK. The Web Listener delivers incoming requests to the Web Request Broker. (D.I. 214, ex. 44 at ORCL000763) The WRB Dispatcher “decide[s] what type of object is being requested” so that it may dispatch the request to the appropriate WRBX. (Id. at ORCL000766) “The WRB Dispatcher performs dynamic load balancing between multiple instances of a WRB Service, and the Webmaster can configure each WRB Service to have a minimum and maximum number of instances.” (Id.) The WRB Dispatcher examines a WRB configuration file in order to decide what type of object is being requested. (Id.) If no suitable WRBX is found, the request is passed back to the Web Listener for standard processing. (Id.)

ii. “Dispatching”

Defendant argues that neither the 2.0 User’s Guide or Reference 605 anticipate the asserted claims because neither disclose “dispatching.” That is, the references “only disclose that the WRB Dispatcher narrows the universe of WRBXs capable of processing a request based on: (1) the request; (2) a configuration file; and (3) whether a WRBX is already processing another request,” and do not “disclose how the WRB Dispatcher chooses between the WRBXs capable of processing the request that are not already processing another request.” (D.I. 219 at 34) Put another way, “a random selection would not be an ‘informed selection.’ ” (Id. at 35)

Plaintiffs admit that, when two or more WRBXs are free at once,