Cirba Inc. (d/b/a Densify) v. VMware, Inc.

Opinion

IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF DELAWARE CIRBA INC. (d/b/a DENSIFY) and : CIRBA IP, INC., : Plaintiffs, : v. : C.A, No. 19-742-LPS VMWARE, INC., : Defendant. : Kenneth L, Dorsney and Cortlan S$. Hitch, MORRIS JAMES LLP, Wilmington, Delaware Courtland L. Reichman and Michael G. Flanigan, REICHMAN JORGENSEN LEHMAN & FELDBERG LLP, Redwood Shores, California Sarah O. Jorgensen, REICHMAN JORGENSEN LEHMAN & FELDBERG LLP, Atlanta, Georgia Christine E. Lehman and Aisha Mahmood Haley, REICHMAN JORGENSEN LEHMAN & FELDBERG LLP, Washington, District of Columbia Khue V. Hoang and Wesley L. White, REICHMAN JORGENSEN LEHMAN & FELDBERG LLP, New York, New York Attorneys for Plaintiffs Cirba Inc, (d/b/a Densify) and Cirba IP, Inc. Amne Shea Gaza, Robert M. Vrana, and Samantha G. Wilson, YOUNG CONAWAY STARGATT & TAYLOR, LLP, Wilmington, Delaware Arturo J, Gonzdlez, Michael A. Jacobs, and Richard S.J. Hung, MORRISON & FOERSTER LLP, San Francisco, California Bita Rahebi, MORRISON & FOERSTER LLP, Los Angeles, California Lily Li, MORRISON & FOERSTER LLP, Palo Alto, California Scott F. Llewellyn, MORRISON & FOERSTER LLP, Denver, Colorado Andrea L. Scripa and Shaun P, deLacy, MORRISON & FOERSTER LLP, New York, New York Neal F. Burstyn, MORRISON & FOERSTER LLP, Washington, District of Columbia Attorneys for Defendant VMware, Inc. MEMORANDUM OPINION

February 24, 2022 Wilmington, Delaware

Ce J udge:

This consolidated action involves 11 patents. Plaintiffs Cirba Inc. (d/b/a Densify) and Cirba IP, Inc. (collectively, “Plaintiffs” or “Densify”) assert U.S. Patent Nos, 8,209,687 (the “?687 patent”), 9,654,367 (the “’367 patent”), 10,523,492 (the “492 patent”), and 10,951,459 (the “’459 patent”) against Defendant VMware, Inc. (“Defendant” or “VMware”). Densify’s patents relate to virtualization technology and management of virtual environments. VMware counterclaims for infringement of its U.S. Patent Nos. 8,875,266 (the “’2.66 patent”), 8,336,049 (the “049 patent”), 9,521,151 (the “’151 patent”), 9,379,995 (the “’995 patent”), 9,766,945 (the patent”), 10,025,638 (the “’638 patent”), and 10,261,842 (the “842 patent”). Following a nine-day trial in January 2020 on Densify’s ’687 and °367 patents, a jury found that VMware infringed the asserted claims of both patents. Post-trial, the Court dismissed Cirba Inc. for lack of standing, vacated the jury’s verdict, and ordered a new trial. Presently before the Court is the issue of claim construction. The parties dispute terms found in Densify’s °687, °492, and ’459 patents as well as in VMware’s °995, °945, °638, and patents. The parties submitted technology tutorials (see D.I. 1091, 1093), objections to the tutorials (D.I. 1099, 1100), a joint claim construction brief (D.1. 1094), and exhibits (D.I. 1095-1 & -2; DI. 1096-1 to -35), including expert declarations (D.I. 1095-1 Exs. A-19 to A-21; D.L. 1095-2 Exs. B-2, B-13 & -14). The Court held a claim construction hearing on December 22, 2021, at which both sides presented oral argument. (D.I. 1114) (“Tr.”) After the hearing, the parties submitted supplemental briefing relating to two of the disputed terms. (See D.I. 1142)

1 VMware asserted infringement of eight patents; however, the Court previously found the asserted claims of VMware’s U.S. Patent No. 10,069,752 (the “’752 patent”) invalid. (See D.1. 839 at 25-28; D.I. 840)

I. LEGAL STANDARDS The ultimate question of the proper construction of a patent is a question of law. See Teva Pharms. USA, Inc. v. Sandoz, Inc., 574 U.S. 318, 321 (2015) (citing Markman v. Westview Instruments, Inc. (“Markman IF’), 517 U.S. 370, 388-91 (1996)). “It is a bedrock principle of patent law that the claims of a patent define the invention to which the patentee is entitled the right to exclude.” Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en bane) (internal quotation marks omitted). “[T]here is no magic formula or catechism for conducting claim construction.” Jd at 1324. The Court is free to attach the appropriate weight to appropriate sources “in light of the statutes and policies that inform patent law.” Id. “(T]he words of a claim are generally given their ordinary and customary meaning,” which is “the meaning that the term would have to a person of ordinary skill in the art [((“POSA”)] in question at the time of the invention, i.e., as of the effective filing date of the patent application.” Jd. at 1312-13 (internal quotation marks omitted), “[TJhe ordinary meaning of a claim term is its meaning to the ordinary artisan after reading the entire patent.” /d at 1321 (internal quotation marks omitted). The patent “specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.” Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). While “the claims themselves provide substantial guidance as to the meaning of □

particular claim terms,” the context of the surrounding words of the claim also must be considered. Phillips, 415 F.3d at 1314. Furthermore, “[o]ther claims of the patent in question, both asserted and unasserted, can also be valuable sources of enlightenment” because “claim terms are normally used consistently throughout the patent.” Jd. It is likewise true that “[d]ifferences among claims can also be a useful guide.” Id. “For example, the presence of a dependent claim that adds a particular limitation gives rise to a

presumption that the limitation in question is not present in the independent claim.” Jd. at 1314- 15, This presumption of claim differentiation is “especially strong when the limitation in dispute is the only meaningful difference between an independent and dependent claim, and one party is urging that the limitation in the dependent claim should be read into the independent claim.” SunRace Roots Enter. Co. v. SRAM Corp., 336 F.3d 1298, 1303 (Fed. Cir. 2003). It is also possible that “the specification may reveal a special definition given to a claim

term by the patentee that differs from the meaning it would otherwise possess. In such cases, the inventor’s lexicography governs.” Phillips, 415 F.3d at 1316, It bears emphasis that “[e]ven when the specification describes only a single embodiment, the claims of the patent will not be read restrictively unless the patentee has demonstrated a clear intention to limit the claim scope using words or expressions of manifest exclusion or restriction.” Hill-Rom Servs., Inc. v. Stryker Corp., 755 F.3d 1367, 1372 (Fed. Cir. 2014) (internal quotation marks omitted). In addition to the specification, a court should “consider the patent’s prosecution history, if it is in evidence.” Markman v. Westview Instruments, Inc, (“Markman f”}, 52 F.3d 967, 980 (Fed. Cir, 1995) (en banc), aff'd, 517 U.S. 370 (1996). The prosecution history, which is “intrinsic evidence,” “consists of the complete record of the proceedings before the [U.S. Patent and Trademark Office] and includes the prior art cited during the examination of the patent.” Phillips, 415 F.3d at 1317. “{T]he prosecution history can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be.” /d. Sometimes, “the district court will need to look beyond the patent’s intrinsic evidence and to consult extrinsic evidence in order to understand, for example, the background science or

the meaning of a term in the relevant art during the relevant time period.” Teva, 574 U.S. at 331. “Rxtrinsic evidence consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises.” Markman £, 52 F.3d at 980. For instance, technical dictionaries can assist the court in determining the ordinary and customary meaning of a term because such dictionaries “endeavor to collect the accepted meanings of terms used in various fields of science and technology.” Phillips, 415 F.3d at 1318. In addition, expert testimony can be useful “to ensure that the court’s understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or to establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field.” Id. Nonetheless, courts must not lose sight of the fact that “expert reports and testimony [are] generated at the time of and for the purpose of litigation and thus can suffer from bias that is not present in intrinsic evidence.” Jd. Overall, while extrinsic evidence “may be useful to the court,” it is “less reliable” than intrinsic evidence, and its consideration “is unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence.” Jd. at 1318-19. Where the intrinsic record unambiguously describes the scope of the patented invention, reliance on any extrinsic evidence is improper. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1308 (Fed. Cir. 1999) (citing Vitronics, 90 F.3d at 1583). Finally, “[t]he construction that stays true to the claim language and most naturally aligns with the patent’s description of the invention will be, in the end, the correct construction.” Renishaw PLC v. Marposs SpA, 158 F.3d 1243, 1250 (Fed. Cir. 1998). It follows that “a claim interpretation that would exclude the inventor’s device is rarely the correct interpretation.” Osram GmbH vy. Int’l Trade Comm'n, 505 F.3d 1351, 1358 (Fed. Cir. 2007) (internal quotation marks omitted).

Il. CONSTRUCTION OF DISPUTED TERMS FOUND IN DENSIFY’S PATENTS A. °687 Patent 1. “evaluating each virtual guest against each virtual host and other virtual guests using one or more rule sets pertaining to said technical, business and workload constraints”?

Densify This limitation has already been fully construed by the Court (see D.I. 356) as: “evaluating each virtual machine against each virtual host and other virtual machines using one or more rule sets pertaining to said technical, business and workload constraints” No further construction is necessary or appropriate, VMware “evaluating each virtual machine against each virtual host and each virtual machine against other virtual machines, in each case using one or more rules pertaining to each of technical, business and workload constraints associated with the corresponding virtual machine” Court “evaluating each virtual machine against each virtual host and other virtual machines, in each case using one or more rule sets pertaining to each of technical, business and workload constraints” In November 2019, in connection with the first trial, the Court construed the term “evaluating each virtual guest against each virtual host and other virtual guests” found in claims 2, 3, and 7 of the 687 patent. (See D.I. 356 at 4-6) The Court adopted VMware’s construction, concluding that the claim term required each virtual machine (“VM”) to be evaluated against each virtual host in the virtualized environment.’ (See id.) During post-trial briefing, however, a

This term appears in claims 3 and 7 of the ’687 patent. The parties’ attempt to reach a post-hearing resolution with respect to this term failed, so they submitted supplemental claim construction briefing. (See D.I. 1142) While Densify complains that VMware’s responsive letter brief “includes new arguments and material” (D.I. 1146), the Court agrees with VMware that Densify has had ample opportunity to respond, and Densify’s “vague reference to alleged ‘new arguments and material’ in VMware’s one-page responsive brief neither warrants delaying the proceedings nor justifies giving [it] yet another chance to reargue its position” (D.L. 1148). 3 Densify does not dispute the requirement that all VMs be evaluated. (See DI. 1094 at 28-29; Tr. at 11-12)

new dispute relating to this term emerged involving whether each VM must be evaluated using rules for all three constraints.* (See D.I. 761 at 2-5; see also D.I. 754 at 7) Accordingly, the Court ordered further claim construction to resolve this dispute before the upcoming trial. (See D.I. 1003 | 13) The Court has not previously construed the precise term the parties have now put before it,’ and doing so is necessary to resolve the parties’ “fundamental dispute” as to claim

scope. O2 Micro Int'l Ltd. v. Beyond Innovation Tech, Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008). In this context, contrary to Densify’s contention (see D.1. 1094 at 7), the Court does not view VMware’s proposal as a motion for reconsideration and does not require a demonstration of good cause. VMware argues that, in the absence of claim construction, the jury will not know (1) whether each VM requires an association with ail three of the claimed constraints (i.e., technical, business, and workload) and (2) whether each evaluation between a VM and host or a VM and

4 Densify contends that the issue it raised in supplemental post-trial briefing was narrow and singular. (See D.I. 1142 at 6) In Densify’s view, the only claim construction dispute the Court’s Scheduling Order permitted to be briefed was whether every VM must have a business rule. (See id) Accordingly, Densify continues, there is no further dispute to be decided, since VMware has made clear it is not arguing each VM must have a business rule, “disclaim[ing] the only position that was to be briefed.” (/d.) (citing Tr. at 30) The Court disagrees with Densify. The Scheduling Order contemplates further construction in relation to the “dispute for the ’687 patent that [Densify] first raised in the parties’ supplemental post-trial briefing.” (D.L 1003 { 13) The “post-trial claim construction dispute” reasonably encompasses more than the narrow issue of whether every VM must have a business rule. For instance, in opposing VMware’s post-trial position, Densify argued that “VMware’s interpretation [of the claim language] ignores the ‘evaluating’ and ‘one or more rules sets’ language,” suggesting the parties’ dispute implicated these broader questions of claim scope. (D.I. 761 at 3) Regardless, it is clear from the parties’ claim construction briefing and supplemental briefing that the parties have a genuine, material dispute as to the scope of this claim term. In the Court’s view, construction is necessary. 5 By contrast, in Nuance Communications, Inc. v. ABBYY USA Software House, Ine., 813 F.3d 1368, 1372-73 (Fed. Cir. 2016), a case relied on by Densify for its position that the Court should not further construe this term (see D.I. 1094 at 29), the plaintiff sought a new construction of the exact same claim term that had already been construed.

another VM (as opposed to all evaluations in the aggregate) must use one or more rule sets for each of the three constraints. (See id. at 31) The Court agrees with VMware that Densify’s □

“non-construction leaves these issues uncertain,” which would be improper in the circumstances presented here. (Ud) VMware contends that each of the three constraints must be associated with each VM, such that a VM with just two associated constraints would not meet the claim limitation.® (id) In support, VMware points to the language of claim 7, describing its “obtaining” limitation as element 7A and its “evaluating” limitation as element 7B. (/d. at 13-14) VMware argues that the phrase “associated with a corresponding virtual machine” in element 7A modifies the three constraints, rather than the “data set,” noting that “‘[mJodifiers should be placed next to the words they modify.” (éd. at 14) (quoting HTC Corp. v. [PCom GmbH & Co., KG, 667 F.3d 1270, 1274 (Fed. Cir. 2012)) Further, since element 7A already describes “a data set for each of said plurality of virtual machines,” it would be redundant to note again that each data set is “associated with a corresponding virtual machine.” (/d.) Plaintiffs, however, suggest that it is the information (pertaining to the constraints) contained in the data sets that is associated with a corresponding VM, not the “constraints” themselves.’ (id. at 24, 28)

6 Densify argues that VMware’s construction requires that every VM be associated with “rules” pertaining to each of the three constraints. (See, e.g., D.L. 1094 at 3, 23-24). VMware clarified, however, that its proposed construction requires that every VM be associated with all three “constraints,” not with the “rules” or “rule sets” pertaining to those constraints. (/d. at 13, 19) Densify also contends that VMware’s construction improperly reads “rule sets” out of the claim, replacing it with “rules.” (Ud. at 3) VMware responds that the distinction between “rules” and “ryle sets” is not significant (see Tr. at 41) and, in any event, ultimately agreed to Densify’s preferred “rule sets” in VMware’s supplemental claim construction briefing (see DI. 1142 at 8 & Ex. B-1). Accordingly, the Court’s construction uses “rule sets.” 7 Densify offers an analogy involving a rule providing that everyone with a dietary restriction be seated at the same table. (See Tr. at 48-49) By applying this rule to a data set (1.¢., a group of people), one could obtain information pertaining to dietary restrictions, which could include that

The Court finds Plaintiffs’ position more persuasive. As Plaintiffs explain, the first step of the method recited in claim 7 is to obtain information (i.e., a data set) about each VM. (id. at 23) The parties appear to agree that “said data sets” referenced in element 7B refers back to the data set referenced in element 7A. (See id. at 15) The second step is to evaluate those data sets using the “rule sets” recited in element 7B. (/d. at 23) Notwithstanding the close proximity of the phrase “associated with a corresponding virtual machine” to the three constraints, the Court is not persuaded that a person of ordinary skill in the art (POSA) would read the plain language of element 7A to require that the data set associated with each VM must contain information pertaining to all three constraints. Nor is the Court persuaded that the highlights on Densify’s Dr. Madisetti’s trial demonstrative (see id. at 14-15) or the specification compels that conclusion, Accordingly, the Court’s construction omits Defendant’s proposed addition of the phrase “associated with the corresponding virtual machine” imported from element 7 AS Turning to the second issue, VMware argues that each evaluation must use one or more rules for each of the three constraints, such that the claim limitation would not be met where an evaluation skips a rule pertaining to even one of the three constraints. (/d. at 31) In support, VMware points to the specification, which describes evaluations that account for all three constraints and does not describe rules being skipped for any evaluation. (See id. at 16-17)

a person has no dietary restrictions. (See id.) In such an instance, what is obtained is information pertaining to a constraint, but not a constraint itself. 8 This conclusion is further supported by the absence of any “obtaining” (i.c., element 7A) limitation in claim 3 of the 687 patent, in which the disputed claim term is also found. VMware does not specifically address the distinction between claims 3 and 7, or whether the rationale underlying its proposed construction would require the term to have a different meaning in claims 3 and 7.

At the claim construction hearing, Densify conceded this point, stating that, “[o|f course, each and every evaluation must have rules pertaining to each of the three constraints.” (Tr. at 43) It further clarified its position that the claim limitation is not met if there is simply one or

more rule sets “in the cloud” or in the aggregate that pertain to each of the three constraints; rather, each evaluation requires one or more rule sets for each of the three constraints. (/d. at 48; see also id. at 50 (reiterating same)) Resolving any remaining doubt about its position, Densify stated that it agreed with Dr. Madisetti’s testimony at trial that an evaluation lacking even one constraint would not infringe. (See id. at 43-44 (referring to D.I. 590 at 618; D.L 511 at DDX-3.3 (“spiderweb” graphic)); see also D.1. 1142 at 6) For those reasons, the Court is persuaded that a POSA would understand each required evaluation must use one or more tule sets pertaining to all three constraints in order to satisfy the claim.’ The phrase “in each case” in the Court’s construction reflects this understanding. B. Terms Common to the °459 and °492 Patents 1. “source system” / “source computer system” □□ □

Densify “a physical, virtual, or hypothetical system from which applications and/or data are moved or are to be moved” “a system from which applications and/or data are to be moved”

9 VMware clarifies that it is not arguing that al/ rule sets used in each evaluation must pertain to all three constraints. (See D.I. 1094 at 32) Nor should the Court’s construction be read to require this. VMware further notes that its position applies only to “the evaluations on which [Densify] relies to show infringement.” (D.I. 1142 at 8-9) VMware recognizes that the claims at issue are “comprising” claims, which allow for additional evaluations apart from the claimed “evaluations.” (Id, see also Tr. at 32) The Court’s construction incorporates this understanding as well. 10 This term appears in claims 1, 12, and 23 of the ’492 patent and claims 1-3, 9-10, 16-17, 22- 23, 26-34, 40-41, 47-48, 53-54, and 57-63 of the patent. The °459 patent is a continuation of the ’492 patent and shares a common specification.

are to be moved” The parties have two disputes with respect to this claim term: (1) whether the term

enicompasses physical, virtual, or hypothetical systems, and (2) whether the term is subject to a temporal limit. As to both issues, the Court agrees with Densify. The parties agree that the patentees acted as their own lexicographer for this term, pointing to the common specification’s definition of a “source system” as “a system from which applications and/or data are to be moved.” (°492 patent at 5:56-57) Densify described this definition as an express definition of “source system” during both IPR proceedings and at a Section 101 hearing on the ’492 patent; the construction VMware now proposes is the same one the PTAB adopted when instituting the IPR. (See D.I. 1094 at 35-36) The parties agree that the Court’s construction should have this express definition as its foundation. With respect to the first issue, the specification explains that “systems may be physical systems, virtual systems or hypothetical models.” (°492 patent at 5:64-65) Despite this disclosure, VMware argues that Densify’s proposed construction improperly narrows the disputed term’s scope. (See D.I. 1094 at 36) Somewhat incongruously, VMware also criticizes Densify for including hypothetical systems within the claim scope. (See id. at 42) (“[Densify] now argues ‘system’ includes ‘hypothetical systems.’”) Although VMware appeared to concede at the hearing that the systems can be hypothetical (see Tr. at 70-72), the Court agrees with Densify that — particularly given the seeming inconsistencies in VMware’s position — there is a need at this stage to explicitly define what the systems can be. (See id at 57) In the Court’s view, the specification’s disclosure that the systems may be physical, virtual, or hypothetical is “consistent with the express definition while providing more specificity.” (D.I. 1094 at 38)

Moreover, while VMware suggests that Densify’s construction is unduly narrowing, it does not provide any examples of systems that may be improperly excluded under Densify’s proposal. As to the second issue, VMware argues its construction is consistent with the specification’s express definition and reflects the patent’s disclosure of only forward-looking “analysis” activity. (Id, at 36-37) Densify concedes that the compatibility analysis is forward- looking, but notes that the term to be construed is “source system,” not analysis. (See Tr. at 59) The Court agrees with Densify that the patent does not place a temporal limit on the claimed “source system” — that is, it does not exclude systems that have already been moved or are currently being moved. (See id at 59-60) Finally, the Court agrees with Densify that components are not excluded from the scope of “source system,” as the specification does not limit “source systems” to entire systems. (See, e.g.,°492 patent at 6:28-32) (“[A] ‘system’ ... can encompass any entity [capable of being analyzed] for any type of compatibility and should not be considered limited to existing or hypothetical physical or virtual systems.”) 2. “target system” / “target computer system”!!

Densify “a physical, virtual, or hypothetical system to which applications and/or data are moved or are to be moved” “a system to which applications and/or data from a source system are to be moved” Court “a physical, virtual, or hypothetical system to which applications and/or data are moved or are to be moved”

\1 This term appears in claims 1, 4-6, 9, 11-12, 15-17, 20, 22-23, 26-28, 31, and 33 of the *492 patent and claims 1-3, 9-10, 16-17, 22-23, 26-34, 40-41, 47-48, 53-54, and 57-63 of the °459 patent. il

The parties assert nearly identical arguments in support of their construction of “target system” / “target computer system” as for “source system” / “source computer system.” (See 1094 at 42-44) The same reasoning underlying the Court’s construction of “source system” applies to this term. 3. “place” terms [Term ——sd|SséDensify [VMware | Court 492 patent terms”? “for placing the source Plain and | “for moving applications and/or | Plain and ordinary systems on target ordinary data from source systems onto meaning. No systems” meaning target systems” construction is necessary. “to determine whether “to determine whether the systems can or can applications and/or data can or not be placed together on can not be moved from the a specific target system” systems together onto a specific target system” “placing the source “moving applications and/or data systems onto the target from the source systems onto the systems” target systems” 459 patent terms? “determining a placement | Plain and “determining movement of Plain and ordinary of source computer ordinary applications and/or data from meaning. No systems on target meaning source computer systems onto construction is necessary, computer systems” target computer systems” “determine a placement “determine a movement of of at least one source applications and/or data from system from the at least one source system collection of computer from the collection of systems on at least one computer systems onto at least target system from the one target system from the collection of computer collection of computer systems” systems”

!2 These terms appear in claims 1, 12, and 23 of the 492 patent. 13 These terms appear in claims 1, 32, and 63 of the ’459 patent.

“one or more other “one or more source systems source systems|,| either from which applications already placed on the and/or dataf,] have either specific target system, or already moved onto the being evaluated for specific target system or are placement onto the being evaluated for movement specific target system” onto the specific target system” “to determine if the “to determine if applications specific source system and/or data can be moved can be placed with those from the specific source other source systems on system, with applications the specific target and/or data from those other system” source systems, onto the specific target system” “placing the specific “moving applications and/or source system on the data from the specific source specific target system” system onto the specific target system” “issue instructions to “issue instructions to move place the at least one applications and/or data from source system on the at the at least one source system least one target system in onto the at least one target accordance with the system in accordance with the determined placement” determined movement” The parties dispute the meaning of the “place” terms used in the °492 and °459 patents, which are directed to the placement of source systems on target systems. First, the parties disagree as to whether the word “placement” should be limited to “movement.” The Court agrees with Densify that the specification does not limit the scope of the “place” terms to exclude all other actions aside from “moving,” as it additionally includes references to, for example, “consolidating,” “stacking,” and “transferring.” (See D.I. 1094 at 45- 46) (citing °459 patent at 2:5-7, 18-20, 13:37-40) That some of these actions involve moving applications and/or data does not compel the narrowing construction VMware secks. (See id. at 47-49) Instead, the Court agrees with Densify that “place” should be given its plain and ordinary

meaning in this context, which is broader than “move,” and may include, as Densify argues, “put|ting] in a particular position” or “a suitable place.” (Jd. at 45) (citing D.I. 1095-2 Ex. B-1) Second, the parties dispute whether the “source systems” being placed should be limited to the “applications and/or data” within those source systems. A POSA would not read the specification as teaching that a “source system” is merely the applications and/or data within it. (See id. at 50-51) Similarly, the claim language does not foreclose placing an entire source system (and not merely its contents) on a target system. (See id.) C. *492 Patent 1. “the systems” / “the source systems” / “the target systems”!

Not indefinite and no construction necessary; antecedent basis is reasonably certain. VMware □ Indefinite for lack of a reasonably certain antecedent basis. Court Not indefinite.

VMware argues “the systems,” “the source systems,” and “the target systems” each lack

a reasonably certain antecedent basis and are thus indefinite. The Court disagrees. As to “the systems,” VMware points to the following language: evaluating [1] one or more source systems against [2] other source systems and against [3] one or more target systems using at least one rule set that evaluates parameters of the systems to determine whether fe systems can or can not be placed together on a specific target system ...; (°492 patent cl. 1) (emphasis added)

14 These terms appear in claims 1, 12, and 23 of the °492 patent.

Densify contends that the °492 patent makes clear that both bolded “the systems” terms encompass both “the source systems [1] and [2]” and “the target systems [3].” arguing that the preamble and claim language provide the antecedent basis for “the systems” and pointing to several instances in which the specification describes both the

source systems and target systems as “systems.” (D.I. 1094 at 54) VMware responds that a target system cannot be “placed” on another target system (a point which Densify concedes). (/d. at 56, 59) In VMware's view, then, the second bolded “the systems” term cannot encompass “the target systems [3].” (id. at 56) Densify counters that, while indeed a target system cannot be “placed” on another target system, the specification teaches that, when stacking multiple source entities onto a target, the source entities and targets coexist in the same operating system environment. (/d. at 59) Thus, a POSA would understand that determining compatibility between source entities and targets would require determining whether source systems and a specific target system can be placed together on that target system or in its environment. (See id.; see also Tr. at 90) The Court agrees with Densify that a POSA would understand from the specification that

a target system cannot be “placed” on another target system. (See Tr. at 99) (“You have to try really hard not to understand the claim in light of what the specification teaches.”) Accordingly, despite the existence of some ambiguity as to whether the second bolded “the systems” term

encompasses “the target systems [3],” VMware has not shown that this claim is indefinite. See generally Phillips, 415 F.3d at 1327 (“[A]mbiguity in... claim language should .. . be resolved in a manner that would preserve the patent’s validity.”). As to “the source systems,” VMware points to the following language: A computer implemented method for placing [1] source systems on target systems, the method comprising:

evaluating [2] one or more source systems against [3] other source systems and against one or more target systems using at least one rule set that evaluates parameters of the systems to determine whether the systems can or can not be placed together on a specific target system... ; and placing the source systems onto the target systems .... (°492 patent cl. 1) (emphasis added) VMware argues it is impossible to determine which “source systems” must be placed in order to infringe, citing several possibilities, such as the preamble’s “[1] source systems,” all of the “[2] one or more source systems,” or each of the “[3] other source systems” as possible contenders. (See D.I. 1094 at 57) Densify responds that it is clear from the claim language that the bolded “source systems” refers to the “[2] one or more source systems” and the “[3] other source systems” that are evaluated against each another. Ud. at 60) The Court agrees with Densify that VMware has not met its burden to show this term is indefinite. As Densify explained at the hearing, “there is really only one plausible way to look at this,” which is “that the source systems are the ones that get placed, and the target systems are the ones on which the source systems are placed.” (Tr. at 92) A POSA would understand that the source systems being placed are the “one or more source systems” and the “other source systems.” Finally, as to “the target systems,” VMware points to the following language: A computer implemented method for placing source systems on [1] target systems, the method comprising: evaluating one or more source systems against other source systems and against [2] one or more target systems using at least one rule set that evaluates parameters of the systems to determine whether the

systems can or can not be placed together on [3] a specific target system... ; and placing the source systems onto the target systems .... (°492 patent cl. 1) (emphasis added) VMware asserts it is not clear if infringement requires placement on one or all target systems, arguing that the most reasonable antecedent for the bolded “target systems” is the singular “{3] a specific target system.” (D.I. 1094 at 58) Densify counters that the only reasonable antecedent of the plural “the target systems” is the also plural “[2] one or more target systems.” (Jd. at 60-61) Here, too, the Court agrees with Densify. VMware has not met its burden to show this term is indefinite. 2. “at least one of a compatibility score, and a number of transfers”!

Densify Plain and ordinary meaning. Alternatively: “a compatibility score and/or a number of transfers” VMware “at least one compatibility score and at least one of a number of transfers” Court “at least one compatibility score and at least one of a number of transfers”

The parties dispute what “at least one of? modifies here. Densify argues the plain and ordinary meaning of the phrase makes clear that the “one or more criteria” used to select the placement solution can be at least one of either a compatibility score, a nurnber of transfers, or both. (D.I. 1094 at 63) In support, it points to instances in which the specification contemplates some, but not all, of the criteria being selected. (See id. at 63-64)

15 This term appears in claims 3, 14, and 25 of the ’492 patent.

By contrast, VMware contends that the claims require at least one compatibility score and

at least one of a number of transfers, (/d. at 64) In support, it relies on SuperGuide Corp. v. DirecTV Enterprises, Inc., 358 F.3d 870, 885-86 (Fed. Cir. 2004), in which the Federal Circuit applied grammatical and stylistic principles to conclude that “at least one of’ followed by elements joined by “and” (rather than “or”) requires at least one element of each type. See also SIMO Holdings Inc. v. Hong Kong uCloudlink Network Tech. Ltd., 983 F.3d 1367, 1377 (Fed. Cir. 2021) (“When there is a straightforward, parallel construction that involves all nouns or verbs in a series, a prepositive or postpositive modifier normally applies to the entire series,” and this principle “has particular force when the term joining the items in a series is ‘and’”). As Densify notes, the SuperGuide presumption is rebuttable. (See Tr. at 103) In Rex Medical, L.P. v. Intuitive Surgical, Inc., 2020 WL 2128795, at *6 (D. Del. May 5, 2020), for example, the Court found the presumption inapplicable because “at least one of’ in that case modified a list of two, rather than three items, and because interpreting the disputed phrase in the conjunctive would have rendered “at least one of” superfluous in that context. Significantly, however, the Court in Rex Medical also explained that a “disjunctive construction is required in order for the plain words of {the claim] to make sense.” /d. at *7 (emphasis added). There, the parties disputed the meaning of “at least one of the first jaw and the second jaw,” and the Court reasoned that a conjunctive construction would nonsensically permit more than one “first jaw” and more than one “second jaw.” Jd. Further, the Court found “nothing in the specification that

supports an apparatus with more than one set of jaws.” Id. By contrast, here, embodiments in the specification support a conjunctive construction by allowing for selection of a workload placement solution based on both a compatibility score and

a number of transfers. (See D.I. 1094 at 64-65) (citing, e.g., °492 patent at 35:41-46) Moreover,

as VMware explains, a conjunctive construction would not render “at least one of” superfluous in this context. (See Tr. at 109-10) The specification provides examples involving multiple compatibility scores and varying numbers of transfer sets, and the “at least one of” helpfully indicates that there may be more than one of either of those items. (See id.) Accordingly, in the Court’s view, neither the claim language nor the specification “rebuts the presumption that the . . . patentee intended the plain and ordinary meaning of this language.” SuperGuide, 358 F.3d at 887. Thus, the Court adopts VMware’s proposed construction, 3. “determining at least one optimal combination of applications operable independently on the target system”!®

Densify Not indefinite. Plain and ordinary meaning. Alternatively, “capable of operating independently from one another.” (D.I. 1142 Ex. A-1 at 8 VMware Indefinite. Court Not indefinite. “Capable of operating independently from one another.”

VMware contends this term is indefinite because a POSA would not be able to determine with reasonable certainty what it means for applications to be “operable independently” or what they must operate independently of. (D.I. 1094 at 68) The Court disagrees. VMware suggests the applications could perhaps operate independently of each other or of the source systems on which they are running, but the intrinsic record does not make clear which of these interpretations applies. (See id, at 68-69) Densify counters that the specification supports only one possible meaning: that the applications are capable of operating independently from one another. (D.I. 1142 at 12; id Ex. A-1 at 8) VMware argues this position is

'6 This term appears in claims 9, 20, and 31 of the ’492 patent.

inconsistent with the position Densify took in its reply brief and at the hearing, in which Densify asserted that a POSA would understand the applications are “operable independently on the target system.” (D.I. 1142 at 10) But these positions are not incompatible; they are, in fact, not really even two separate positions. Instead, as Densify explains, it has asserted all along that the applications must be “able to be operated independently of each other on the target system.” (id. at 12 (emphasis omitted); D.I. 1094 at 67) In support, Densify points to a passage in the specification describing “multi-dimensional rule-based compatibility analysis,” which describes assessing the compatibility of transferring multiple source entities to a target system. (D.I. 1094 at 70) There, the patent discloses two types of target systems: “concrete” and “malleable.” (492 patent at 30:10-23) Where a target system is “concrete,” the source entities are “assumed to be required to conform to the target,” while where a target is “malleable” it is “generally adaptable in accommodating source entities.” (id) Densify argues a POSA would understand that when a target system is “concrete,” the target may not be able to accommodate each of the applications’ individual requirements. (D.t. 1094 at 70) Therefore, the applications must be “operable independently on the target system” □□

that is, they would not require or rely on individual target system accommodations to be able to operate on the target system. (/d.) While VMware is correct that the specification excerpt upon which Densify relies —

which never uses the words “operable” or “independent” — does not provide robust guidance as to this claim term (see id. at 71), the Court is nonetheless persuaded that (as Dr. Madisetti testified) a POSA would understand with reasonable certainty the claim scope here. (See DI. 1095-2 Ex. B-13 9 36-40) VMware has not shown by clear and convincing evidence that the

term is indefinite. See BASF Corp. v. Johnson Matthey Inc., 875 F.3d 1360, 1365 (Fed. Cir, 2017). 4. “a 1-to-1 compatibility analysis”

Densify “an analysis that evaluates the compatibility of every possible source-target pair combination in a collection of systems on a 1-to-! basis” VMware “an analysis that evaluates the compatibility of every system in a collection of systems as a source system against every system in the collection of systems as a target system on a 1-to-1 basis” Court “an analysis that evaluates the compatibility of every system in a collection of systems as a source system against every system in the collection of systems as a target system on a 1-to-1 basis” The patentees acted as their own lexicographer for this term, indicating in the specification that “[t]he 1-to-1 compatibility analysis evaluates the compatibility of every possible source-target pait combination in the collection of systems . . . on a 1-to-| basis.” (492 patent at 7:19-21) Both parties’ proposed constructions reflect this express definition. However, VMwate argues its construction provides further clarity to the meaning of “every possible source-target pair combination.” (D.I. 1094 at 72) At the claim construction hearing, Densify described VMware’s construction as “a more detailed recitation of what they believe ‘every possible’ means,” but added that Densify did not discern any meaningful difference in the parties’ constructions. (Tr. at 122-23) Indeed, the parties appear to agree that the 1-to-1 compatibility analysis produces a score for each source- target system pairing that exists in a collection of systems. (See D.I. 1094 at 71-72) In VMware’s view, however, the further detail in its proposed construction reflects that the phrase

'7 This term appears in claims 1, 12, and 23 of the *492 patent.

“every possible” requires an exhaustive analysis. (Tr. at 124) Since the specification reflects this understanding, and Densify does not dispute it, the Court will adopt VMware’s construction to resolve any ambiguity VMware contends may otherwise exist. (See id. at 125) 5. “an N-to-1 compatibility analysis”

Densify “an analysis that evaluates the compatibility of each of N source systems separately and individually against a common target system” VMware “an analysis that evaluates the compatibility of each of N source systems against a common target system” Court “an analysis that evaluates the compatibility of each of N source systems separately and individually against a common target system”

The parties agree the specification teaches that a goal of the claimed “N-to-1 compatibility analysis” is to determine whether multiple source systems can operate together on the same target system, and that the outcome of such an analysis is a single compatibility score for the transfer set as a whole. (See D.I. 1094 at 75-77) (citing ’492 patent at 7:26-31) Densify argues, however, that its construction is necessary to clarify that the N-to-1 compatibility analysis does not involve evaluating the combination of N source systems against the common target system. (/d. at 78) VMware responds that Densify does not explain how “separate” and “individual” evaluations could determine if the N source systems could operate together on the same target. (Id. at 76-77) [t notes further that its proposed construction is supported by the specification, and is the same construction Densify proposed in the °492 patent IPR proceedings. (/d. at 76)

18 This term appears in claims 1, 12, and 23 of the ’492 patent.

VMware’s proposal, however, does not appear to resolve the parties’ dispute. The Court finds it appropriate, therefore, to look more closely at the specification for further guidance. See Phillips, 415 F.3d at 1315 (specification is “the single best guide to the meaning of a disputed term”). In Densify’s view, the specification teaches that the N-to-1 compatibility analysis involves separate evaluations of each individual source system against the common target. □□□□□ 1094 at 75-76) In support, it points to the specification’s description of how the N-to-1 compatibility score is calculated. Cd.) (citing ’492 patent at 30:46-60) That portion of the specification teaches that determining the compatibility between N source entities and a single target involves “/s/eparately evaluat[ing] each source entity against the target.” (492 patent at

30:50) (emphasis added) This description is followed by examples in which source systems □□□□ s2, and s3) are evaluated separately and individually against a common target system (s16); that

is, the specification describes three separate evaluations of (1) “sl against $16,” (2) “s2 against 516,” and (3) “s3 against s16,” rather than one evaluation of the combination of s1 + s2 + s3 against s16. (Id. at 30:62-65; see also id. fig. 24(c) (separately evaluating each source entity against target)) The Court finds Densify’s citations to the specification persuasive and, accordingly, adopts Densify’s proposed construction.

D. °459 Patent 1. “the source systems”!?

Densify Not indefinite. Plain and ordinary meaning. Alternatively: “the specific source system and those other source systems” VMware Indefinite for lack of a reasonably certain antecedent basis. Court “the specific source system and one or more other source systems”

VMware argues the term “the source systems” claimed in the ’459 patent lacks a reasonably certain antecedent basis and is indefinite. The Court disagrees. VMware points to the following language: evaluate compatibility between [1] the specific source system from [2] the plurality of source systems and [3] one or more other source systems either already placed on the specific target system, or being evaluated for placement onto the specific target system, to determine if the specific source system can be placed with those other source systems on the specific target system, by evaluating one or more rules that operate against attributes or data relating to the source systems;

(459 patent cl. 1) (emphasis added) Densify argues that a POSA would be reasonably certain that the bolded “the source systems” term above refers to “[1] the specific source system from [2] the plurality of source systems” and the “[3] one or more other source systems.”*° (D.I. 1094

19 This term appears in claims 1, 31, and 63 of the ’459 patent. Densify has agreed that claim 63 should read “the source systems,” consistent with claims 1 and 31, rather than “the two or more source systems.” (D.I. 1094 at 82 1.17) 20 Aithough Densify took a different position in its opening brief, it conceded at the claim construction hearing that, “[clandidly, [its] opening position was a mistake.” (Tr. at 143)

at 83; Tr. at 141, 144) In VMware’s view, however, the term is susceptible to multiple interpretations. (See D.[. 1094 at 82) Despite the ambiguity suggested by VMware, the Court agrees with Densify that the plain language of the claims and the specification provide a POSA with enough information to understand what “the source systems” refers to in this context. (See Tr. at 144) As Densify explained at the hearing, it would be unreasonable for “the source systems” to refer to “[2] the plurality of source systems,” as such a reading would include those source systems that are not being evaluated. (/d.) VMware has not shown by clear and convincing evidence that this term is indefinite. Il. CONSTRUCTION OF DISPUTED TERMS FOUND IN VMWARE’S PATENTS A. °995 Patent 1. “snapshot”!

Densify “data that contains configuration and resource usage information of a distributed computer system at a particular moment in time” VMware “data at a particular moment in time” Court “data that contains configuration and resource usage information of a distributed computer system at a particular moment in time” The parties agree that a “snapshot” is data “at a particular moment in time.” (See DL. 1094 at 85) VMware argues, however, that the additional language in Densify’s proposed construction renders superfluous the claims’ “wherein” clause, which states: “wherein the

This term appears in claims 1, 9, and 17 of the °995 patent.

snapshot includes configurations and resource usage information of at least some components of the distributed computer system.” (995 patent cls. 1, 9, 17) Densify responds that its proposed construction simply reflects the express definition in the specification, namely: “[a]s used herein a snapshot of a distributed computer system contains at least configuration and resource usage information of the distributed computer system at a particular moment in time.” (/d. at 7:53-56) Densify argues that its construction does not render the claims’ “wherein” clause superfluous, as here the term “snapshot” appears in the same limitation as the “wherein” clause, with the phrase as a whole operating as a single limitation, mutually reinforcing that the claimed “snapshot” must contain at least a configuration and resource usage information, as distinguished from other types of data. (See D.I. 1094 at 86-87) The Court will adopt Densify’s construction, which incorporates the specification’s express definition. VMware does not dispute that the language on which Densify relies is an

express definition for “snapshot.” Moreover, unlike in IpLearn, LLC v. Kenexa Corp., 2013 WL §730610 (D. Del. Oct. 22, 2013), this case does not involve a suggestion that the Court import a different limitation from a dependent claim into an independent claim such that the language in the dependent claim may be rendered superfluous. Instead, here the terms are part of the same limitation of the same claim, and Densify’s construction serves to reinforce the patentee’s express definition for “snapshot” (which the parties appear to agree controls).

2. “iteratively traversing a resource hierarchy””

Densify Indefinite for failure to point out with particularity and distinctly claim the subject matter such that one of ordinary skill in the art would be reasonably apprised of the bounds of the asserted claims. VMware Not indefinite. This term should not be construed as it takes its plain and ordinary meaning. Alternatively, this term should be construed as “repeatedly moving along resources that are organized in a hierarchy, such as in ranks, layers, ora tree structure.” Court Not indefinite. “Repeatedly moving along resources that are organized in a hierarchy, such as in ranks, layers, or a tree structure.” Densify contends that the disputed term is indefinite, arguing a POSA would understand the patent to teach three possible meanings for “iteratively traversing” without being able to reasonably ascertain which one applies. (See D.I, 1094 at 95) In Densify’s view, the patent teaches that “iteratively traversing” could mean (1) simply repeatedly “moving” along the hierarchy (by moving among nodes); (2) repeatedly “adjusting” operations at nodes on the hierarchy (which would require only a single movement from a first to a second node}; or (3) repeatedly moving along the hierarchy and performing the adjustment operation at each node. (See id. at 92-95) VMware agrees with Densify that the patent teaches the first of these three meanings of “iteratively traversing;” it argues, however, that Densify’s proposed second and third possible meanings are based on improper importations of limitations into the claims. (See id, at 99-100) The Court agrees with VMware that the two other “possible meanings” Densify identifies are not supported by the plain language of the claims or the specification. VMware notes correctly that

22 This term appears in claims 1, 9, and 17 of the ’995 patent. 23 The parties agree that “resource hierarchy” means “resources organized in ranks, layers, or a tree structure.” (D.1. 1094 at 92) 27

the claims recite “iteratively traversing,” not “iteratively adjusting.” (Id.) The specification does not equate “traversing” and “adjusting,” nor mandate that “traversing” include adjusting. (See id.) Moreover, while certain embodiments may illustrate “iteratively traversing” by starting from the bottom layer in the resource hierarchy and moving up (see, e.g.,’995 patent at 13:6-10), the patent does not limit “iteratively traversing” to “moving higher in the hierarchy or moving laterally after first moving higher,” as Densify argues. (D.I. 1094 at 98) The parties appear to generally agree that the plain meaning of iteratively is “repeatedly” and that “traversing” means moving. Accordingly, the Court adopts VMware’s alternative construction. 3. “target resource allocation”

“desired resource allocation” This term should not be construed as it takes its plain and ordinary meaning. Court

The parties appear to agree that the term “target” connotes a goal or an objective. They disagree as to whether the Court’s construction should involve some measure of a person’s subjective intentions. (See D.L. 1094 at 101-03) Densify points to the patent’s Background, which states that “[r]esource allocation techniques . . . are important to ensure that the clients are operating at desired or target levels.” patent at 114-17) (emphasis added) The Court agrees with VMware, however, that a POSA would not read the Background as equating “target” with “desired.” (See D.I. 1094 at

24 This term appears in claims 1, 9, and 17 of the ’995 patent.

102) The word “target” in this context could be understood either to reiterate the “desired” modifier or (if the “or” is disjunctive) indicate another type of level that is distinct from “desired.” Besides its lack of specification support, Densify’s proposed “desired” could confusingly suggest to the jury that it must assess subjective intentions. (See id.) Densify’s contention that the jury will be confused without a construction, a conclusion Densify reaches based on reference to meanings of “target” that plainly do not apply (e.g., “a mark or point at which

someone fires or aims”), is unpersuasive. (See id.) Instead, as VMware notes, the specification supports an understanding that the plain and ordinary meaning of “target” as used in the patent is

a “goal” or “objective.” (/d. at 101) (citing "995 patent at 11:43-48 (describing exemplary target resource allocation as “resource allocation goal”)) Accordingly, no construction is necessary. 4. “resource configuration action””

“action relating to resource configuration in accordance with resource allocation recommendation” This term should not be construed as it takes its plain and ordinary meaning. Court

Densify provides no persuasive reason to recast the claimed phrase “resource configuration action” to an “action relating to resource configuration.” (D.1. 1094 at 103) Densify further contends that the resource configuration action must be “in accordance with” the resource allocation recommendation. (See id. at 104) The claims state that “the

resource allocation recommendation specifies at least one resource configuration action ....”

25 ‘This term appears in claims 1, 9, and 17 of the °995 patent.

(°995 patent cls. 1,9, 17) The Court agrees with VMware that an action “in accordance with” a recommendation is vaguer than an action specified by the recommendation. (See D.I. 1094 at 104) Hence, Densify’s proposed substitution may confuse a jury by implying that performing the specified “resource configuration action” depends on other unidentified requirements in the recommendation. (See id.) Nor does the specification support Densify’s construction. While the specification identifies exemplary actions that can be specified by the resource allocation recommendation (see °995 patent at 9:4-18), it does not require that the claimed resource configuration action be “in accordance with” that recommendation (see D.1. 1094 at 105). The plain language of the claims makes clear that the resource configuration actions are tied to the resource allocation recommendation, which “specifies” those actions. 5. “capacity expansion action”

Densify “action relating to capacity expansion in accordance with resource allocation recommendation” VMware This term should not be construed as it takes its plain and ordinary meaning. Court Plain and ordinary meaning. No construction is necessary.

The parties assert the same arguments with respect to this claim term as with the “resource configuration action” term. For the same reasons, the Court concludes that construction is not necessary.

26 This term appears in claims 1, 9, and 17 of the ’995 patent.

B. Patent 1. “calculating a target resource configuration””’

Densify “calculating a desired resource configuration” This term should not be construed as it takes its plain and ordinary meaning. Court Plain and ordinary meaning. No construction is necessary.

As with the term “target resource allocation” found in the °995 patent, Densify proposes exchanging the ordinary word “target” for the more subjective word “desired.” (See DI. 1094 at 110) For the same reasons discussed with respect to the ’995 patent, the Court finds VMware’s position more persuasive. Further support for the Court’s conclusion is found in the fact that, unlike with the °995 patent, the term “desired” does not even appear in the °945 patent. While the specification describes the calculation of an “ideal” resource configuration, Densify does not explain how this description compels the construction it seeks. (See id. at 109) (citing ’945 patent at 6:43-58) C. °638 Patent 1. “operationally distinct cloud computing facilities””*

Densify Indefinite for failure to point out with particularity and distinctly claim the subject matter such that one of ordinary skill in the art would be reasonably apprised of the bounds of the asserted claims. VMware Not indefinite. This term should not be construed as it takes its plain and ordinary meaning. Court Not indefinite. Plain and ordinary meaning.

27 This term appears in claims 1, 8, and 15 of the ’945 patent. 28 This term appears in claims 10 and 19 of the °638 patent.

Densify argues the intrinsic record provides insufficient guidance as to what it means for a cloud computing facility to be “operationally distinct.” (See D.I. 1094 at 116) VMware counters that a POSA would understand that “operationally distinct” cloud computing facilities “function separately from one another.” (See id. at 111) It notes that “operationally” ordinarily means “functionally” and “distinct” ordinarily means “separate.” (/d. at 117; see also Tr. at 159) The specification uses the term “operationally distinct” only once — in connection with Figure 10 — and states that the cloud-computing facilities “are geographically and operationally distinct.” (°638 patent at 12:56-13:2) VMware argues this supports its construction, as it describes distinct cloud-computing facilities that function separately from one another while being centrally managed. (See DI. 1094 at 111-12) In the Court’s view, the specification does not provide such clarity. The prosecution history reveals that the Examiner expressed confusion as to the meaning of “operationally distinct,” noting that the claim language does not shed light on the term’s meaning and adding that the specification suggests “it is only necessary that the node[s] operate independent of each other in some way.” (D.I. 1095-2 Ex. B-3 at 10) In response, the applicant explained that the facilities are “operationally distinct” because “the virtual data centers are themselves large distributed systems that include interfaces and abstraction layers that provide access to well-defined sets of services that are carried out entirely within the virtual data centers.” (D.I. 1032-13 Ex. T at 24) Densify argues the applicant’s response provides little guidance, leaving it unclear (among other things) whether facilities must be “geographically distinct.” (See D.I. 1094 at 115- 16) VMware responds that the patent discusses “geographically distinct” and “operationally distinct” as separate concepts, and the claims only require that the cloud computing facilities be

“operationally” distinct. (/d. at 118; Tr. at 161, 169) A POSA would understand that the applicant’s response reiterates that “operationally distinct” cloud computing facilities “function separately from one another.” The Court’s conclusion that VMware’s plain and ordinary meaning construction provides sufficient guidance as to the term’s meaning, and that this term is not indefinite, is further supported by the fact that, although the PTAB did not ultimately decide the issue of what qualifies as “operationally distinct,” it was nonetheless able to analyze the term in relation to the prior art. See generally Sonix Tech. Co. v. Publ’ns Int'l, Ltd., 844 F.3d 1370, 1379-80 (Fed. Cir. 2017), 2. “cloud-connector server?”

Densify dedicated server computer or virtual machine running within a server computer that interfaces to users on a remote computer and that interfaces to remote cloud-connector nodes” VMware This term should not be construed as it takes its plain and ordinary meaning. Alternatively, this term should be construed as “a dedicated server computer or virtual machine running within a server computer.” Court “g dedicated server computer or virtual machine running within a server computer that interfaces to users on a remote computer and that interfaces to remote cloud-connector nodes” Densify argues the term “cloud-connector server” has no plain and ordinary meaning, pointing to the patentee’s representation during prosecution that “‘cloud-connector server’ . □ . do[es] not have [a] well-known or accepted meaning[] within the computing arts.” (D.I. 1094 at 122) (citing D.I. 1095-2 Ex. B-4 at 12) The patentee further stated that the phrase was “developed for the current application” and should be understood according to the definitions provided in the application. (D.L. 1095-2 Ex. B-4 at 12) The patentee provided an express

29 This term appears in claims 10 and 19 of the °638 patent.

definition for “cloud-connector server” as “a dedicated server computer or virtual machine running within a server computer that interfaces to users on a remote computer and that interfaces to remote cloud-connector nodes.” (/d. at 11) Densify proposes that the Court adopt this definition as its construction. The Court agrees with Densify that “‘the patentee acted as his own lexicographer and clearly set forth a definition of the disputed claim term in . . . [the] prosecution history.’” (D.IL. 1094 at 125) (quoting CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002)) VMware offers no persuasive intrinsic evidence casting doubt on that definition, and concedes that the patentee’s definition should inform the Court’s understanding of the term. (See id. at 121) VMware also agrees with Densify that, as disclosed in the specification, the cloud- connector server can be a physical server computer or a virtual machine. (See id.) (citing ’638 patent at 13:5-8, 12:51-57) Accordingly, the Court will adopt Densify’s construction, which is consistent with both the plain language of the claims and the specification, as well as the express definition given during prosecution. 3. “cloud-connector node”?

Densify “an application or set of applications running within a virtual machine installed within each computing-facility of the multiple cloud-computing-facility aggregation, in a virtual data center management server, cloud director, or management system” VMware “an application or set of applications that connects the cloud-computing server with a cloud- computing facility” Court “an application or set of applications that connects the cloud-computing server with a cloud- computing facility”

3° This term appears in claims 10 and 19 of the ’638 patent.

As with “cloud-comnector server,” the patentee stated during prosecution that “cloud- connector node” does not have a well-known meaning in the art. (See DI. 1095-2 Ex. B-4 at 12) Densify notes that the patentee also represented that a cloud-connector node “is generally implemented as an application or set of applications running within a virtual machine.” (Ud) Additionally, the patentee described the claimed cloud-connector nodes as being “installed in a virtual data center management server, cloud director, or management system within a cloud- computing facility of the multiple cloud-computing facility.” (D.L 1032-13 Ex. T at 26) The Court agrees with VMware, however, that the patentee’s use of “generally” to describe the way in which “a cloud-connector node” is implemented suggests that other examples (beyond applications “running within a virtual machine”) are possible and detracts from Densify’s argument that the statement relied on by Densify should be read as an express definition. (See D.I. 1094 at 128) Nor is that statement a clear disavowal of claim scope. (See id. at 130) Absent lexicography or a clear disavowal of claim scope, the fact that dependent claims 14 and 23 expressly limit the cloud-connector node to a “virtual appliance” (i.e., an application or set of applications running within a virtual machine) provides another reason — under the doctrine of claim differentiation — not to limit independent claims 10 and 19 in a manner that would result in their scope being no broader than that of the dependent claims. (See id. at 128) Moreover, the specification provides support for VMware’s construction, describing the “cloud- connector node” as a means to connect the cloud-computing server with a cloud-computing facility. (See, e.g., 7638 patent at 12:33-38, 51-55, 13:15-36) For similar reasons, the prosecution history also does not support requiring the nodes to be installed “in a virtual data center management server, cloud director, or management system.”

These limitations are not persuasively supported by the evidence Densify cites and would render

express claim language superfluous. (See D.I. 1094 at 129) D. Patent 1. “distributed resource scheduling module”*!

Densify This is a means-plus-function term subject to § 112,96. The term is indefinite for lack of sufficiently definite corresponding structure. Functions: - receiving a recommended change to a virtual architecture of the virtual computing environment at a distributed resource scheduling module; ~ determining, by the distributed resource scheduling module, an impact on current workload in the virtual computing environment if the recommended change is performed; - determining, by the distributed resource scheduling module, an impact on future workload in the virtual computing environment if the recommended change is performed; - calculating, by the distributed resource scheduling module, a combined impact on current and future workload from the determined impact on current workload in the virtual computing environment if the recommended change is performed and from the determined impact on future workload in the virtual computing environment if the recommended change is performed; - determining, by the distributed resource scheduling module, that the combined impact is above a threshold; and — inresponse to determining that the combined impact on current and future workload is above the threshold, performing the recommended change to the virtual architecture of the virtual computing environment. Structure: Insufficient. VMware Not a means-plus-function term subject to §112, § 6 and not indefinite. This term should not be construed as it takes its plain and ordinary meaning. That plain and ordinary meaning is “distributed resource scheduler” (D.I. 1094 at 133). If this limitation is subject to § 112, | 6: Function: receiving a recommended change 31 This term appears in claim 1 of the ’842 patent.

Structure: conventional software modules for receiving recommended changes to virtual environments for evaluation Function: determining . . . an impact on current workload Structure: conventional software for scoring recommended changes, e.g., “based on [their] improvement in the cluster imbalance metric and on its risk-adjusted costs and benefits” before the “imbalance metric is recomputed incorporating that move” Function: determining . . . an impact on future workload Structure: conventional software for scoring recommended changes based on a “predicted load,” such as one based on a “pattern matching predictor,” “‘polyfit’ prediction” or “simple step prediction” Function: calculating ...a combined impact on current and future workload Structure: conventional software for “sum[ming]” impact scores, such as “scorfing] as the sum of current and future impact, weighted by confidence in the future prediction” Function: determining . . . that the combined impact is above a threshold Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis 1109 at 159 Court Not a means-plus-function term subject to §112, { 6 and not indefinite. The plain and ordinary meaning of this term is “distributed resource scheduler.” Densify argues the term “distributed resource scheduling module” (“DRS module”) is subject to 35 U.S.C. § 112, 7 6 and is indefinite because the specification does not disclose adequate corresponding structure. (D.I. 1094 at 133-36) The Court must first evaluate whether means-plus-function claiming applies. If it applies, the Court then identifies the function and determines whether the specification discloses sufficient structure to perform the function. Where, as here, a claim does not use the word “means,” there is a rebuttable presumption that means-plus-function claiming does vot apply, although that presumption is not a “strong” one. Williamson vy. Citrix Online, LLC, 792 F.3d 1339, 1349 (Fed. Cir. 2015); see also Zeroclick, LLC v. Apple Inc., 891 F.3d 1003, 1007 (Fed. Cir. 2018). “Module,” however, is a

“well-known nonce word that can operate as a substitute for ‘means.’” Williamson, 792 ¥.3d at 1350. Densify argues, as a consequence, that means-plus-function claiming applies. “When evaluating whether a claim limitation invokes § 112, { 6, the essential inquiry remains whether the words of the claim are understood by persons of ordinary skill in the art to have a sufficiently definite meaning as the name for structure.” Zeroclick, 891 F.3d at 1007 (internal quotation marks omitted); see also Greenberg v. Ethicon Endo-Surgery, Inc., 91 F.3d 1580, 1583 (Fed. Cir. 1996) (“What is important is . . . that the term, as the name for structure, has a reasonably well understood meaning in the art.”). VMware argues that DRS modules were well-known in the art as of the 7842 patent’s filing date. (D.I. 1094 at 131) In support, it points to testimony from earlier in this case from both Densify’s Dr. Madisetti and VMware’s Dr. Menascé recognizing that distributed resource schedulers, and their resource allocation function, were well-known in the art. (Ud. at 131-32 (citing D.I. 789-2 Ex. B-1 {J 25, 30; D.L. 789-1 Ex. A-1 4 10-13; id Ex. A-2 35-36); see also Tr. at 173 (“There is no dispute between the parties or their experts .. . that [DRS] modules were well known in the art.”)) In VMware’s view, the background of the ’842 patent’s specification provides further support, describing “[clonventional techniques for [DRS].” (D.1. 1094 at 132) (citing °842 patent at 1:47-51) During prosecution, the applicant similarly described “conventional techniques for [DRS].” (/d. at 138) (citing D.I. 1032-14 Ex. U at 17304) Densify responds that there is no discussion of what these allegedly “conventional techniques” are, and that, unlike in 2M Solutions LLC v. Sterra Wireless America, Inc., 2016 WL 1298961 (D. Del. Mar. 31, 2016), upon which VMware relies, the claim here does not describe in detail how the limitation (i.e., the DRS module) works. (See D.I. 1094 at 136) The Court, however, is persuaded that there is sufficient evidence — including intrinsic evidence and

testimony from both parties’ experts — showing that DRS modules were well-known structures in the art at the time of the ’842 patent’s filing. Accordingly, the patent’s use of this conventional class of structures does not invoke § 112, | 6, and the disputed term is not indefinite. 2. “a non-transitory computer-readable storage medium comprising instructions that, when executed in a computing device, causes the computing device to carry out the steps of”

Densify This is a means-plus-function term subject to § 112, 46. The term is indefinite for lack of sufficiently definite corresponding structure. Functions: the steps listed in the claim Structure: Insufficient. YMware Not a means-plus-function term subject to §112, { 6 and not indefinite. As preambles, these terms are not limiting, merely identify well-known claim forms (non-transitory computer- readable storage media and computer systems), and should not be construed. If this limitation is subject to § 112, 4 6: Function: receiving a recommended change Structure: conventional software modules for receiving recommended changes to virtual environments for evaluation Function: determining . . . an impact on current workload Structure: conventional software for scoring recommended changes, e.g., “based on [their] improvement in the cluster imbalance metric and on its risk-adjusted costs and benefits” before the “imbalance metric is recomputed incorporating that move” Function: determining . . . an impact on future workload Structure: conventional software for scoring recommended changes based on a “predicted load,” such as one based on a “pattern matching predictor,” “‘polyfit’ prediction” or “simple step prediction” Function: calculating ... a combined impact on current and future workload Structure: conventional software for “sum{ming]” impact scores, such as “scor[ing] as the sum of current and future impact, weighted by confidence in the future prediction” Function: determining .. . that the combined impact is above a threshold 32 This term appears in claim 12 of the ’842 patent.

Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis

Structure: conventional software for implementing recommended changes in a virtual environment soe Court

The parties agree that claim 12’s preamble is limiting in that it specifies “instructions that, when executed in a computing device, cause[] the computing device to carry out the steps of” the recited method. (D.I. 1094 at 149) Densify argues that, absent the preamble’s recitation of “computer-readable storage medium comprising instructions,” the claim would have no structure that enables the steps set forth in the body of the claim. Ud. at 146) In Densify’s view, this structure is insufficiently detailed such that a POSA would not have an adequate indication of the structure claimed. (See id.) Accordingly, despite the term’s lack of the word “means,” Densify believes it has overcome the presumption that § 112, 6 does not apply. (See id.) The Court disagrees. This case can be distinguished from Arendi S.\A.R.L. v. LG Electronics, Inc., 2019 WL 3891150, at *12-13 (D, Del. Aug. 19, 2019), in which the claims provided little or no detail regarding the claimed algorithm, and “the specification include[d] no specific protocols, no flow-charts, and no other description of how the claimed ‘inserting’ function is to be implemented.” Here, by contrast, the claim outlines a specific, detailed, multi- step set of instructions informing a POSA as to how those instructions are executed and how they interact. (See D.I, 1094 at 150; Tr. at 184 (“Critically, the steps are specific. The operations and objectives of the instructions are clear within the language of the claims. The inputs and outputs are also clear.... And each step follows from the next. It’s clear from the claim language itself how they interact.”)) Moreover, VMware points out that Densify has no expert support for its 40

position that the term lacks structure, as Densify’s expert, Dr. Madisetti, was instructed to simply assume the preamble here was a means-plus-function term. (See D.I. 1094 at 150) Accordingly, the Court concludes that § 112, { 6 does not apply, and the disputed term is not indefinite. 3. “a virtual management computer configured to”?

Densify This is a means-plus-function term subject to § 112, 96. The term is indefinite for lack of sufficiently definite corresponding structure. Functions: the steps listed in the claim Structure: Insufficient. VMware Not a means-plus-function term subject to §112, 6 and not indefinite. As preambles, these terms are not limiting, merely identify well-known claim forms (non-transitory computer- readable storage media and computer systems), and should not be construed. If this limitation is subject to § 112, 6: Function: receiving a recommended change Structure: conventional software modules for receiving recommended changes to virtual environments for evaluation Function: determining .. . an impact on current workload Structure: conventional software for scoring recommended changes, e.g., “based on [their] improvement in the cluster imbalance metric and on its risk-adjusted costs and benefits” before the “imbalance metric is recomputed incorporating that move” Function: determining . .. an impact on future workload Structure: conventional software for scoring recommended changes based on a “predicted load,” such as one based on a “pattern matching predictor,” “‘polyfit’ prediction” or “‘simple step prediction” Function: calculating .. .a combined impact on current and future workload Structure: conventional software for “‘sum[ming]” impact scores, such as “scorfing] as the sum of current and future impact, weighted by confidence in the future prediction” Function: determining . . . that the combined impact is above a threshold 33 This term appears in claim 17 of the ’842 patent.

4]

Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis Function: perform[ing} the recommended change Structure: conventional software for implementing recommended changes in a virtual environment D.I. 1109 at 181 Court Not a means-plus-function term subject to §112, 4] 6 and not indefinite.

Densify acknowledges that the “issues with this term mirror th[ose]” of the previous term, as “a virtual management computer configured to” appears in the preamble of claim 17 and precedes identical instructions. (D.I. 1094 at 153) Accordingly, the Court reaches the same conclusion here. Section 112, | 6 does not apply, and the disputed term is not indefinite. 4. “a combined impact on current and future workload”**

Densify Indefinite for failure to point out with particularity and distinctly claim the subject matter such that one of ordinary skill in the art would be reasonably apprised of the bounds of the asserted claims. ~ VMware Not indefinite. These terms should not be construed as they take their plain and ordinary meaning. Court Not indefinite. Plain and ordinary meaning.

In response to Densify’s indefiniteness arguments (see, ¢.g., D.I. 1094 at 156), VMware points out that this claim term uses ordinary English words — “impact,” “current,” “future,” “combined,” and “workload” — and should take its plain meaning, consistent with the claim language and specification. (See id at 155, 157) The claims, for example, explain what is needed to calculate the “combined impact” — the determined “impact on current workload” from

34 This term appears in claims 1, 12, and 17 of the ’842 patent.

performing a recommended change and the determined “impact on future workload” from performing a recommended change — and require that the result must be an “impact” comparable to threshold. Ud. at 157-58; °842 patent cls. 1, 12, 17) Figure 5 of the patent discloses an example of this process, and the specification describes exemplary “impacts,” including “improvement in the cluster imbalance metric” and “improved performance” resulting from performing a recommended change. (See ’842 patent fig. 5, 9:15-17, 10:17-19) In Densify’s view, however, the disclosures regarding how to combine impacts in cases in which one or both workloads are negatively impacted are “opaque and inconsistent.” (DL. 1094 at 157) For example, the patent discloses embodiments in which the performed change would “improve current, but hurt future cluster imbalance” or “hurt current but improve future cluster imbalance.” (’842 patent at 9:59-67) In such scenarios, the patent teaches that consideration of the combined impact may involve a “cost-benefit analysis” or may be “challenging to analyze.” Ud.) The Court agrees with VMware that the examples in the specification on which Densify relies “simply address different ways in which the impacts on current and future workloads might be considered.” (D.I. 1094 at 158) The existence of some imprecision or variation in the specification relating to the ways in which “combined impact” is calculated does not compel a finding of indefiniteness. Instead, the plain meaning of the term, which is consistent with the claim language and specification, provides a POSA with reasonable certainty as to the bounds of the asserted claims at issue. (See D.I. 1095-1 Ex. A-20 49 55-59) Densify has not proven indefiniteness by clear and convincing evidence. IV. CONCLUSION An appropriate Order follows.