Cirba Inc. v. VMware, Inc.

Full title: CIRBA INC. d/b/a DENSIFY and CIRBA IP, INC., Plaintiffs, v. VMWARE, INC.…

Court: United States District Court, D. Delaware

Date published: Feb 24, 2022

C. A. 19-742-LPS (D. Del. Feb. 24, 2022)

Opinion

C. A. 19-742-LPS

02-24-2022

CIRBA INC. d/b/a DENSIFY and CIRBA IP, INC., Plaintiffs, v. 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. Anne Shea Gaza, Robert M. Vrana, and Samantha G. Wilson, YOUNG CONAWAY STARGATT & TAYLOR, LLP, Wilmington, Delaware Arturo J. Gonzalez, 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.

STARK, U.S. District Judge:

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.

Anne Shea Gaza, Robert M. Vrana, and Samantha G. Wilson, YOUNG CONAWAY STARGATT & TAYLOR, LLP, Wilmington, Delaware

Arturo J. Gonzalez, 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

STARK, U.S. District Judge: 1

This consolidated action involves 11 patents. Plaintiffs Cirba Inc. (d/b/a Density) 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"). Density'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 '"266 patent"), 8, 336, 049 (the '"049 patent"), 9, 521, 151 (the "'151 patent"), 9, 379, 995 (the "'995 patent"), 9, 766, 945 (the "'945 patent"), 10, 025, 638 (the "'638 patent"), and 10, 261, 842 (the "'842 patent").¹

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.I. 839 at 25-28; D.I. 840)

Following a nine-day trial in January 2020 on Density'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 Density's '687, '492, and '459 patents as well as in VMware's '995, '945, '638, and '842 patents. The parties submitted technology tutorials (see D.I. 1091, 1093), objections to the tutorials (D.I. 1099, 1100), ajoint claim construction brief (D.I. 1094), and exhibits (D.I. 1095-1 & -2; D.I. 1096-1 to -35), including expert declarations (D.I. 1095-1 Exs. A-19 to A-21; D.I. 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) 2

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 II), 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 banc) (internal quotation marks omitted). "[T]here is no magic formula or catechism for conducting claim construction." Id. 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." Id. at 1312-13 (internal quotation marks omitted). "[T]he ordinary meaning of a claim term is its meaning to the ordinary artisan after reading the entire patent." Id. 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." Id.

It is likewise true that "[differences 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 3 presumption that the limitation in question is not present in the independent claim." Id. 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 7"), 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." Id.

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 4 the meaning of a term in the relevant art during the relevant time period." Teva, 574 U.S. at 331. "Extrinsic evidence consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises." Markman I, 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." Id. 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." Id. 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 v. Int'l Trade Comm % 505 F.3d 1351, 1358 (Fed. Cir. 2007) (internal quotation marks omitted). 5

II. 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" ²

2 This term appears in claims 3 and 7 of the '687 patent.

I 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 6 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 If 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. 02 Micro Int'l Ltd. v. Beyond Innovation Tech, Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008). In this context, contrary to Density's contention (see D.I. 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.

3 Densify does not dispute the requirement that all VMs be evaluated. (See D.I. 1094 at 28-29; Tr. at 11-12)

4 Density contends that the issue it raised in supplemental post-trial briefing was narrow and singular. (See D.I. 1142 at 6) In Density'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, Density 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." (Id.) (citing Tr. at 30) The Court disagrees with Density. The Scheduling Order contemplates further construction in relation to the "dispute for the '687 patent that [Density] first raised in the parties' supplemental post-trial briefing." (D J. 1003 113) 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, Density 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, Inc., 813 F.3d 1368, 1372-73 (Fed. Cir. 2016), a case relied on by Density 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.

VMware argues that, in the absence of claim construction, the jury will not know (1) whether each VM requires an association with all 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 7 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 Density's "non-construction leaves these issues uncertain," which would be improper in the circumstances presented here. (Id.)

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. (Id. 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 "'[modifiers should be placed next to the words they modify.'" (Id. at 14) (quoting ETC Corp. v. IPCom 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." (Id.) 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) 8

6 Density argues that VMware's construction requires that every VM be associated with "rules" pertaining to each of the three constraints. (See, e.g., D.I. 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. (Id. at 13, 19) Density also contends that VMware's construction improperly reads "rule sets" out of the claim, replacing it with "rules." (Id. at 3) VMware responds that the distinction between "rules" and "rule sets" is not significant (see Tr. at 41) and, in any event, ultimately agreed to Density's preferred "rule sets" in VMware's supplemental claim construction briefing (see D J. 1142 at 8 & Ex. B-l). Accordingly, the Court's construction uses "rule sets."

7 Density 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 (i.e., a group of people), one could obtain information pertaining to dietary restrictions, which could include that 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.

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 7 A. (See Id. at 15) The second step is to evaluate those data sets using the "rule sets" recited in element 7B. (Id. 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 (POS A) would read the plain language of element 7 A 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 Density'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 7A.⁸

8 This conclusion is further supported by the absence of any "obtaining" (i.e., 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.

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. (Id. 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) 9

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. (Id. 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.L 590 at 618; D.L 511 at DDX-3.3 ("spiderweb" graphic)); see also D.L 1142 at 6)

For those reasons, the Court is persuaded that a POSA would understand each required evaluation must use one or more rule 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.

9 VMware clarifies that it is not arguing that all 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.L 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.

B. Terms Common to the '459 and '492 Patents

1. "source system" / "source computer system" ¹⁰

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 '459 patent. The '459 patent is a continuation of the '492 patent and shares a common specification.

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

VMware "a system from which applications and/or data are to be moved"

10

Court "a physical, virtual, or hypothetical system from which applications and/or data are moved or are to be moved"

The parties have two disputes with respect to this claim term: (1) whether the term encompasses physical, virtual, or hypothetical systems, and (2) whether the term is subject to a temporal limit. As to both issues, the Court agrees with Density.

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) Density 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 Density's proposed construction improperly narrows the disputed term's scope. (See D.I. 1094 at 36) Somewhat incongruously, VMware also criticizes Density for including hypothetical systems within the claim scope. (See Id. at 42) ("[Density] 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 Density 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) 11 Moreover, while VMware suggests that Density's construction is unduly narrowing, it does not provide any examples of systems that may be improperly excluded under Density'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" ¹¹

11 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.

Density "a physical, virtual, or hypothetical system to which applications and/or data are moved or are to be moved",

VMware "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"

12

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 D.I. 1094 at 42-44) The same reasoning underlying the Court's construction of "source system" applies to this term.

3. "place" terms

Term	Density	VMware	Court
492 patent terms 12
"for placing the source systems on target systems" "to determine whether the systems can or can not be placed together on a specific target system" "placing the source systems onto the target systems"	Plain and ordinary meaning	"for moving applications and/or data from source systems onto "to determine whether applications and/or data can or can not be moved from the systems together onto a specific target system" "moving applications and/or data from the source systems onto the target systems"	Plain and ordinary meaning. No target systems" construction is necessary
'459 patent terms 13
"determining a placement of source computer systems on target computer systems" "determine a placement of at least one source system from the collection of computer systems on at least one target system from the collection of computer systems"	Plain and ordinary meaning.	"determining movement of applications and/or data from source computer systems onto target computer systems" "determine a movement of applications and/or data from at least one source system from the collection of computer systems onto at least one target system from the collection of computer systems"	Plain and ordinary meaning No construction is necessary.

13

"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" "placing the specific source system on the specific target system" "issue instructions to place the at least one source system on least one target system in accordance with the determined placement"

"one or more source systems from which applications and/or data[, ] have either already moved onto the specific target system or are being evaluated for movement onto the specific target system" "to determine if applications and/or data can be moved from the specific source system, with applications and/or data from those other source systems, onto the specific target system" "moving applications and/or data from the specific source system onto the specific target system" "issue instructions to move applications and/or data from the at the at least one source system onto the at least one target system in accordance with the determined movement"

12 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.

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 seeks. (See Id. at 47-49) Instead, the Court agrees with Densify that "place" should be given its plain and ordinary 14 meaning in this context, which is broader than "move," and may include, as Density argues, "put[ting] in a particular position" or "a suitable place." (Id. at 45) (citing D.I. 1095-2 Ex, B-l)

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" ¹⁴

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

Density 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

the systems

can or can not be placed together on a specific target system . . .;

('492 patent cl. 1) (emphasis added) 15

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). (Id. 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. (Id. 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:

16

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. (Id. 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

17

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." (Id. 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" ¹⁵

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

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 number 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) 18

By contrast, VMware contends that the claims require at least one compatibility score and at least one of a number of transfers. (Id. at 64) In support, it relies on Super Guide 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 Density notes, the SuperGuide presumption is rebuttable. (See Tr. at 103) hi 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." Id. 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." Id. 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, 19 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" ¹⁶

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

Density Not indefinite. Plain and ordinary meaning. Alternatively, "capable of operating independently from one another." (D.I. 1142 Ex. A-l at 8)

VMware Indefinite.

Court Not indefinite. "Capable of operating independently from one another."

VMware contends this term is indefinite because a POS A 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-l at 8) VMware argues this position is 20 inconsistent with the position Densify took in its reply brief and at the hearing, in which Density 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.I. 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. (Id.)

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 D.I. 1095-2 Ex. B-13 ¶¶ 36-40) VMware has not shown by clear and convincing evidence that the 21 term is indefinite. See BASF Corp. v. Johnson Matthey Inc., 875 F.3d 1360, 1365 (Fed. Cir. 2017).

4. "a 1-to-l compatibility analysis" ¹⁷

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

Densify "an analysis that evaluates the compatibility of every possible source-target pair combination in a collection of systems on a 1-to-l 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-l 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-l basis"

The patentees acted as their own lexicographer for this term, indicating in the specification that "[t]he 1-to-l compatibility analysis evaluates the compatibility of every possible source-target pair combination in the collection of systems ... on a 1-to-l basis." ('492 patent at 7:19-21) Both parties' proposed constructions reflect this express definition. However, VMware 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-l 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 22 "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" ¹⁸

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

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. (Id. 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) It notes further that its proposed construction is supported by the specification, and is the same construction Densify proposed in the '492 patent IPR proceedings. (Id. at 76) 23

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 Density's view, the specification teaches that the N-to-1 compatibility analysis involves separate evaluations of each individual source system against the common target. (D.I. 1094 at 75-76) In support, it points to the specification's description of how the N-to-1 compatibility score is calculated. (Id.) (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 evaluating] each source entity against the target." ('492 patent at 30:50) (emphasis added) This description is followed by examples in which source systems (s1, s2, and s3) are evaluated separately and individually against a common target system (s16); that is, the specification describes three separate evaluations of (1) "s1 against S16," (2) "s2 against s16," 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 Density's citations to the specification persuasive and, accordingly, adopts Density's proposed construction. 24

D. '459 Patent

1. "the source systems" ¹⁹

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 n.17)

Density 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 25 at 83; Tr. at 141, 144) In VMware's view, however, the term is susceptible to multiple interpretations. (See D.I 1094 at 82)

20 Although Densify took a different position in its opening brief, it conceded at the claim construction hearing that, "[c]andidly, [its] opening position was a mistake." (Tr. at 143)

Despite the ambiguity suggested by VMware, the Court agrees with Density 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. (Id.) VMware has not shown by clear and convincing evidence that this term is indefinite.

III. CONSTRUCTION OF DISPUTED TERMS FOUND IN VMWARE'S PATENTS

A. '995 Patent

1. "snapshot" ²¹

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

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 D.I. 1094 at 85)

VMware argues, however, that the additional language in Density's proposed construction renders superfluous the claims' "wherein" clause, which states: "wherein the 26 snapshot includes configurations and resource usage information of at least some components of the distributed computer system." ('995 patent els. 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." (Id. 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 5730610 (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). 27

2. "iteratively traversing a resource hierarchy" ²²

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

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, or a tree structure."

Court Not indefinite. "Repeatedly moving along resources that are organized in a hierarchy, such as in ranks, layers, or a tree structure."23

23 The parties agree that "resource hierarchy" means "resources organized in ranks, layers, or a tree structure." (D.I. 1094 at 92)

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 Density'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 Density'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 28 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 Density 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" ²⁴

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

Density "desired resource allocation"

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 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.I. 1094 at 101-03)

Density points to the patent's Background, which states that "[Resource allocation techniques ... are important to ensure that the clients are operating at desired or target levels." ('995 patent at 1:14-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 29 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 Density 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." (Id. 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" ²⁵

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

Densify "action relating to resource configuration 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.

Densify provides no persuasive reason to recast the claimed phrase "resource configuration action" to an "action relating to resource configuration." (D.I. 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. . . ." 30 ('995 patent els. 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, Density'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 Density'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.I. 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 "²⁶

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

Density "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. 31

B. '945 Patent

1. "calculating a target resource configuration" ²⁷

27 This term appears in claims 1, 8, and 15 of the '945 patent.

Densify "calculating a desired resource configuration"

VMware 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 D.I. 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" ²⁸

28 This term appears in claims 10 and 19 of the '638 patent.

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.

32

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." (Id. 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 D.L 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.L 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.L 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.L 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 33 "operationally" distinct. (Id. 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" ²⁹

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

Densify "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"

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 "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"

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.I. 1095-2 Ex. B-4 at 12) The patentee provided an express 34 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." (Id. 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.I. 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" ³⁰

30 This term appears in claims 10 and 19 of the '638 patent.

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"

35

As with "cloud-connector server," the patentee stated during prosecution that "cloud-connector node" does not have a well-known meaning in the art. (See D.I. 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." (Id.) 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.I. 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 Density'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., '638 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." 36 These limitations are not persuasively supported by the evidence Density cites and would render express claim language superfluous. (See D.I. 1094 at 129)

D. '842 Patent

1. "distributed resource scheduling module" ³¹

31 This term appears in claim 1 of the '842 patent.

Density This is a means-plus-function term subject to § 112, ¶ 6. 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 - in response 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,

37

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 Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis (D.I. 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, "

Density argues the term "distributed resource scheduling module" ("DRS module") is subject to 35 U.S.C. § 112, ¶ 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 not apply, although that presumption is not a "strong" one. Williamson v. 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 38 "well-known nonce word that can operate as a substitute for 'means.'" Williamson, 792 F.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 '842 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. Menasce recognizing that distributed resource schedulers, and their resource allocation function, were well-known in the art. (Id. at 131-32 (citing D.I. 789-2 Ex. B-l ¶¶ 25, 30; D.I. 789-1 Ex. A-l ¶¶ 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 "[conventional techniques for [DRS]." (D.I. 1094 at 132) (citing '842 patent at 1:47-51) During prosecution, the applicant similarly described "conventional techniques for [DRS]." (Id. 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 M2M Solutions LLC v. Sierra 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 39 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' ³²

32 This term appears in claim 12 of the '842 patent.

Density This is a means-plus-function term subject to § 112, ¶ 6. 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 "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

40

Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis Function: performing] the recommended change Structure: conventional software for implementing recommended changes in a virtual environment (D.I. 1109 at 169)

Court Not a means-plus-function term subject to §112, ¶ 6 and not indefinite.

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. (Id. 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 41 position that the term lacks structure, as Density'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" ³³

33 This term appears in claim 17 of the '842 patent.

Density This is a means-plus-function term subject to § 112, ¶ 6. 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," "'polyfif 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

42

Structure: conventional software for comparing scores to thresholds, such as by cost benefit analysis Function: performing] 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, ¶ 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" ³⁴

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

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 Density's indefiniteness arguments (see, e.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 43 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 a threshold. (Id. at 157-58; '842 patent els. 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 Density'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." (D.I. 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." (Id.)

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 ¶¶ 55-59) Densify has not proven indefiniteness by clear and convincing evidence.

IV. CONCLUSION

An appropriate Order follows. 44

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 Density'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.I. 1148).