Opinion
Case No. 2:20-cv-00015-JRG
01-07-2021
MONARCH NETWORKING SOLUTIONS LLC, Plaintiff, v. CISCO SYSTEMS, INC., Defendant.
CLAIM CONSTRUCTION MEMORANDUM AND ORDER
On November 20, 2020, the Court held a hearing to determine the proper construction of the disputed claim terms within in United States Patent Nos. 8,451,844 (the "'844 Patent"); 8,451,845 (the "'845 Patent"); 9,019,965 (the "'965 Patent"); and 8,130,775 (the "'775 Patent") (collectively, "the Asserted Patents"). Having reviewed the arguments made by the parties at the hearing and in their claim construction briefing (Dkt. Nos. 88, 96, 103), having considered the intrinsic evidence, and having made subsidiary factual findings about the extrinsic evidence, the Court hereby issues this Claim Construction Memorandum and Order. See Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) (en banc); see also Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015).
TABLE OF CONTENTS
I. BACKGROUND ................................................................................................................ 3 II. APPLICABLE LAW .......................................................................................................... 7 III. THE PARTIES' STIPULATED TERMS ......................................................................... 13 IV. CONSTRUCTION OF NON-MEANS-PLUS-FUNCTION TERMS .............................. 13
A. "IPv4 destination address" / "IPv4 address of said destination terminal" ... 13
B. "destination port number" ............................................................................ 18
C. "an operator prefix" ..................................................................................... 22
D. "an interconnection equipment of the IPv6 domain with the IPv4 destination address" ............................................................................................................... 25
E. "regularizing" ............................................................................................... 29
F. "link" ............................................................................................................ 33
G. "if necessary" ............................................................................................... 38
H. "modifying the data packet using the regularized address" ......................... 42
I. "the replacement process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address" ................................................................................. 44 I. CONSTRUCTION OF MEANS-PLUS-FUNCTION TERMS ........................................ 47
J. "means for constructing ..." / "means for generating ..." / "means for routing ..." ....................................................................................................................... 49
K. "means for extracting ..." / "means for generating ..." / "means for routing ..." ..................................................................................................................... 60
L. "first means for advertising ..." / "second means for advertising ..." ......... 72
M. "means for obtaining ..." ............................................................................ 78
N. "means for identifying ..." .......................................................................... 80
O. "means for regularizing ..." ......................................................................... 84
P. "means for routing ..." ................................................................................. 91 II. CONCLUSION ................................................................................................................. 93
I. BACKGROUND
Plaintiff Monarch Networking Solutions LLC ("Plaintiff") alleges that Defendant Cisco Systems, Inc. ("Defendant") infringes the Asserted Patents. Shortly before the start of the November 20, 2020 hearing, the Court provided the parties with preliminary constructions with the aim of focusing the parties' arguments and facilitating discussion.
Plaintiff contends that the Asserted Patents relate to improved techniques for routing data between and within network domains. Dkt. No. 88 at 5. According to Plaintiff, the '844 Patent discloses and claims an improved system to facilitate the migration and transformation from IPv4 (Internet Protocol version 4) networks to IPv6 (Internet Protocol version 6) networks, solving many of the drawbacks inherent in the stateful techniques used previously. Id. at 5.
Citations to the parties' filings are to the filing's number in the docket (Dkt. No.) and pin cites are to the page numbers assigned through ECF.
The Abstract of the '844 Patent states the following:
A method of receiving a data packet from an IPv4 domain in an IPv6 domain, the data packet comprising an IPv4 destination address and a destination port number. The method comprises the following steps: constructing an IPv6 destination address by concatenating an operator prefix, the IPv4 destination address, and the destination port number; generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 data packet; and routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address, the constructed address belonging to a range of IPv6 addresses routable to an interconnection equipment of the IPv6 domain with the IPv4 destination address.
Claim 1 of the '844 Patent is an illustrative claim and recites the following elements (disputed terms in italics):
1. A method of receiving a data packet from an IPv4 domain in an IPv6 domain, said data packet comprising an IPv4 destination address and a destination port number, said method comprising the following steps:
constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number;
generating an IPv6 data packet from the IPv6 constructed
destination address and the received IPv4 packet; and
routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address, said constructed address belonging to a range of IPv6 addresses routable to an interconnection equipment of the IPv6 domain with the IPv4 destination address.
Regarding the '845 Patent, Plaintiff contends that it also discloses and claims an improved system to facilitate the migration and transformation from IPv4 networks to IPv6 networks. Id. at 6. According to Plaintiff, the '845 Patent solution constitutes an improvement over prior solutions because it permits the gateway to transform packets received from an IPv6 domain that includes IPv4 destination address and port number for delivery on an IPv4 network without being required to maintain state for all incoming and outgoing connections, as is required for the prior Network Address Translation techniques. Id.
The Abstract of the '845 Patent states the following:
A method of receiving an IPv6 data packet in an IPv6 domain connected to an IPv4 domain, said packet comprising an IPv6 destination address and an IPv6 source address. The method comprises the following steps: identifying an IPv6 destination address constructed by concatenating an operator prefix, an IPv4 destination address, and a destination port number; if necessary, regularizing at least one address of the data packet and modifying the data packet; and routing the modified data packet to its destination.
Claim 1 of the '845 Patent is an illustrative claim and recites the following elements (disputed terms in italics):
1. A method for receiving an IPv6 data packet in an IPv6 domain connected to an IPv4 domain, said packet comprising an IPv6 destination address and an IPv6 source address, said method being executed in a home gateway adapted to connect a user terminal to said IPv6 domain, and comprising the following steps:
identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address and a destination port number;
if necessary, regularizing at least one of the IPv6 source address and the IPv6 destination address of the data packet by replacing said at least one IPv6 address, the replacement
process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address, and modifying the data packet using the regularized address; and routing the [IPv6] data packet to its destination.
Regarding the '965 Patent, Plaintiff contends that it also permits operators to connect private IPv4 network domains with IPv6 network domains without requiring the operator to maintain state and translation tables within its network, as required by the prior available solutions. Id. According to Plaintiff, the '965 Patent solution permits IPv4 packets in a first IPv4 domain to be routed to terminals in a second private IPv4 domain via an IPv6 domain by using stateless address translation and encapsulation. Id. at 6-7.
The Abstract of the '965 Patent states the following:
A data packet routing system is provided wherein: at least one terminal belonging to a private IPv4 network is connected to a gateway itself connected to an IPv6 network; at least one interface device at the interface between said IPv6 network and a public IPv4 network implements a translation function comprising exchanging a private IPv4 address with a public IPv4 address. The gateway allocates to the terminal an IPv6 address by providing an IPv6 prefix with the private IPv4 address of the terminal in its private IPv4 network; said gateway verifying whether IPv4 address conflict exists, and if IPv4 it does exist, for replacing said private IPv4 address locally with a substitute private IPv4 address. A method is provided that routes an IPv4 data packet sent by a source terminal belonging to a first IPv4 domain via an IPv6 domain to a destination terminal belonging to a second IPv4 domain.
Claim 1 of the '965 Patent is an illustrative claim and recites the following elements (disputed terms in italics):
1. A method of routing an IPv4 data packet sent by a source terminal belonging to a first IPv4 domain, via an IPv6 domain, to a destination terminal belonging to a second IPv4 domain, said second IPv4 domain being private, said method comprising, on reception of said IPv4 data packet from said source terminal:
constructing an IPv6 destination address;
encapsulating the IPv4 data packet in an IPv6 data packet carrying said IPv6 destination address; and
routing said IPv6 data packet in said IPv6 domain; wherein the IPv6 destination address is constructed by combining an IPv6 prefix and the private IPv4 address of said destination terminal in the second IPv4 domain.
Regarding the '775 Patent, Plaintiff contends that it claims an improved way of routing data across packet-switched networks in the form of "pseudo-wires." Id. at 7. According to Plaintiff, the '775 Patent teaches systems and methods that enable the two pseudo wires to share a link along their shared path, thus reducing or eliminating consumption of extra network resources. Id.
The Abstract of the '775 Patent states the following:
A method is provided for setting up at least two pseudo-wires able to broadcast a stream of data, wherein a first pseudo-wire is set up between an input router of a packet-switched network and first output router of the packet-switched network, and a second pseudo-wire is set up between the input router and a second output router of the packet-switched network. A first link of the first pseudo-wire is set up between the first output router and an intermediate router of the packet-switched network. A second link of the second pseudo-wire is set up between the second output router and the intermediate router. A third link of both pseudo-wires is set up between the intermediate router and the input router.
Claim 1 of the '775 Patent is an illustrative claim and recites the following elements (disputed terms in italics):
1. A method of setting up at least two pseudo-wires able to broadcast a data stream, comprising:
setting up a first pseudo-wire comprising a first link set up between an input router of a packet-switched network and an intermediate router of the packet-switched network and a second link set up between said intermediate router and a first output router of the packet-switched network; and
setting up a second pseudo-wire between said input router and a second output router of the packet-switched network, wherein the second pseudo-wire comprises said first link and a third link set up between said intermediate router and said second output router, said first link being shared by the first and second pseudo-wires.
II. APPLICABLE LAW
A. Claim Construction
"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, 415 F.3d at 1312 (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). To determine the meaning of the claims, courts start by considering the intrinsic evidence. Id. at 1313; C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 861 (Fed. Cir. 2004); Bell Atl. Network Servs., Inc. v. Covad Commc'ns Grp., Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). The intrinsic evidence includes the claims themselves, the specification, and the prosecution history. Phillips, 415 F.3d at 1314; C.R. Bard, Inc., 388 F.3d at 861. The general rule—subject to certain specific exceptions discussed infra—is that each claim term is construed according to its ordinary and accustomed meaning as understood by one of ordinary skill in the art at the time of the invention in the context of the patent. Phillips, 415 F.3d at 1312-13; Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1368 (Fed. Cir. 2003); Azure Networks, LLC v. CSR PLC, 771 F.3d 1336, 1347 (Fed. Cir. 2014) (quotation marks omitted) ("There is a heavy presumption that claim terms carry their accustomed meaning in the relevant community at the relevant time.") cert. granted, judgment vacated, 135 S. Ct. 1846 (2015).
"The claim construction inquiry . . . begins and ends in all cases with the actual words of the claim." Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1248 (Fed. Cir. 1998). "[I]n all aspects of claim construction, 'the name of the game is the claim.'" Apple Inc. v. Motorola, Inc., 757 F.3d 1286, 1298 (Fed. Cir. 2014) (quoting In re Hiniker Co., 150 F.3d 1362, 1369 (Fed. Cir. 1998)) overruled on other grounds by Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015). First, a term's context in the asserted claim can be instructive. Phillips, 415 F.3d at 1314. Other asserted or unasserted claims can also aid in determining the claim's meaning, because claim terms are typically used consistently throughout the patent. Id. Differences among the claim terms can also assist in understanding a term's meaning. Id. For example, when a dependent claim adds a limitation to an independent claim, it is presumed that the independent claim does not include the limitation. Id. at 1314-15.
"[C]laims 'must be read in view of the specification, of which they are a part.'" Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc)). "[T]he 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.'" Id. (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). This is true because a patentee may define his own terms, give a claim term a different meaning than the term would otherwise possess, or disclaim or disavow the claim scope. Phillips, 415 F.3d at 1316. In these situations, the inventor's lexicography governs. Id.
The specification may also resolve ambiguous claim terms "where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone." Teleflex, Inc., 299 F.3d at 1325. But, "'[a]lthough the specification may aid the court in interpreting the meaning of disputed claim language, particular embodiments and examples appearing in the specification will not generally be read into the claims.'" Comark Commc'ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (quoting Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988)); see also Phillips, 415 F.3d at 1323. "[I]t is improper to read limitations from a preferred embodiment described in the specification—even if it is the only embodiment—into the claims absent a clear indication in the intrinsic record that the patentee intended the claims to be so limited." Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 913 (Fed. Cir. 2004).
The prosecution history is another tool to supply the proper context for claim construction because, like the specification, the prosecution history provides evidence of how the U.S. Patent and Trademark Office ("PTO") and the inventor understood the patent. Phillips, 415 F.3d at 1317. However, "because the prosecution history represents an ongoing negotiation between the PTO and the applicant, rather than the final product of that negotiation, it often lacks the clarity of the specification and thus is less useful for claim construction purposes." Id. at 1318; see also Athletic Alts., Inc. v. Prince Mfg., 73 F.3d 1573, 1580 (Fed. Cir. 1996) (ambiguous prosecution history may be "unhelpful as an interpretive resource").
Although extrinsic evidence can also be useful, it is "'less significant than the intrinsic record in determining the legally operative meaning of claim language.'" Phillips, 415 F.3d at 1317 (quoting C.R. Bard, Inc., 388 F.3d at 862). Technical dictionaries and treatises may help a court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but technical dictionaries and treatises may provide definitions that are too broad or may not be indicative of how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid a court in understanding the underlying technology and determining the particular meaning of a term in the pertinent field, but an expert's conclusory, unsupported assertions as to a term's definition are not helpful to a court. Id. Extrinsic evidence is "less reliable than the patent and its prosecution history in determining how to read claim terms." Id. The Supreme Court has explained the role of extrinsic evidence in claim construction:
In some cases, however, 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. See, e.g., Seymour v. Osborne, 11 Wall. 516, 546 (1871)
(a patent may be "so interspersed with technical terms and terms of art that the testimony of scientific witnesses is indispensable to a correct understanding of its meaning"). In cases where those subsidiary facts are in dispute, courts will need to make subsidiary factual findings about that extrinsic evidence. These are the "evidentiary underpinnings" of claim construction that we discussed in Markman, and this subsidiary factfinding must be reviewed for clear error on appeal.Teva Pharm. USA, Inc. v. Sandoz, Inc., 574 U.S. 318, 331-32 (2015).
B. Departing from the Ordinary Meaning of a Claim Term
There are "only two exceptions to [the] general rule" that claim terms are construed according to their plain and ordinary meaning: "1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of the claim term either in the specification or during prosecution." Golden Bridge Tech., Inc. v. Apple Inc., 758 F.3d 1362, 1365 (Fed. Cir. 2014) (quoting Thorner v. Sony Comput. Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012)); see also GE Lighting Sols., LLC v. AgiLight, Inc., 750 F.3d 1304, 1309 (Fed. Cir. 2014) ("[T]he specification and prosecution history only compel departure from the plain meaning in two instances: lexicography and disavowal."). The standards for finding lexicography or disavowal are "exacting." GE Lighting Sols., 750 F.3d at 1309.
Some cases have characterized other principles of claim construction as "exceptions" to the general rule, such as the statutory requirement that a means-plus-function term is construed to cover the corresponding structure disclosed in the specification. See, e.g., CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1367 (Fed. Cir. 2002).
To act as his own lexicographer, the patentee must "clearly set forth a definition of the disputed claim term," and "clearly express an intent to define the term." Id. (quoting Thorner, 669 F.3d at 1365); see also Renishaw, 158 F.3d at 1249. The patentee's lexicography must appear "with reasonable clarity, deliberateness, and precision." Renishaw, 158 F.3d at 1249.
To disavow or disclaim the full scope of a claim term, the patentee's statements in the specification or prosecution history must amount to a "clear and unmistakable" surrender. Cordis Corp. v. Bos. Sci. Corp., 561 F.3d 1319, 1329 (Fed. Cir. 2009); see also Thorner, 669 F.3d at 1366 ("The patentee may demonstrate intent to deviate from the ordinary and accustomed meaning of a claim term by including in the specification expressions of manifest exclusion or restriction, representing a clear disavowal of claim scope."). "Where an applicant's statements are amenable to multiple reasonable interpretations, they cannot be deemed clear and unmistakable." 3M Innovative Props. Co. v. Tredegar Corp., 725 F.3d 1315, 1326 (Fed. Cir. 2013).
C. Definiteness Under 35 U.S.C. § 112 , ¶ 2 (pre-AIA) / § 112(b) (AIA)
Patent claims must particularly point out and distinctly claim the subject matter regarded as the invention. 35 U.S.C. § 112, ¶ 2. A claim, when viewed in light of the intrinsic evidence, must "inform those skilled in the art about the scope of the invention with reasonable certainty." Nautilus Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 910 (2014). If it does not, the claim fails § 112, ¶ 2 and is therefore invalid as indefinite. Id. at 901. Whether a claim is indefinite is determined from the perspective of one of ordinary skill in the art as of the time the application for the patent was filed. Id. at 911. As it is a challenge to the validity of a patent, the failure of any claim in suit to comply with § 112 must be shown by clear and convincing evidence. BASF Corp. v. Johnson Matthey Inc., 875 F.3d 1360, 1365 (Fed. Cir. 2017). "[I]ndefiniteness is a question of law and in effect part of claim construction." ePlus, Inc. v. Lawson Software, Inc., 700 F.3d 509, 517 (Fed. Cir. 2012).
When a term of degree is used in a claim, "the court must determine whether the patent provides some standard for measuring that degree." Biosig Instruments, Inc. v. Nautilus, Inc., 783 F.3d 1374, 1378 (Fed. Cir. 2015) (quotation marks omitted). Likewise, when a subjective term is used in a claim, "a court must determine whether the patent's specification supplies some standard for measuring the scope of the [term]." Ernie Ball, Inc. v. Earvana, LLC, 502 F. App'x 971, 980 (Fed. Cir. 2013) (citations omitted). The standard "must provide objective boundaries for those of skill in the art." Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364, 1371 (Fed. Cir. 2014).
D. Means-Plus-Function Limitations
Where a claim limitation is expressed in "means plus function" language and does not recite definite structure in support of its function, the limitation is subject to 35 U.S.C. § 112, ¶ 6. Braun Med., Inc. v. Abbott Labs., 124 F.3d 1419, 1424 (Fed. Cir. 1997). In relevant part, 35 U.S.C. § 112, ¶ 6 mandates that "such a claim limitation 'be construed to cover the corresponding structure . . . described in the specification and equivalents thereof.'" Id. (citing 35 U.S.C. § 112, ¶ 6). Accordingly, when faced with means-plus-function limitations, courts "must turn to the written description of the patent to find the structure that corresponds to the means recited in the [limitations]." Id.
Construing a means-plus-function limitation involves multiple steps. "The first step in construing [a means-plus-function] limitation is a determination of the function of the means-plus-function limitation." Medtronic, Inc. v. Advanced Cardiovascular Sys., Inc., 248 F.3d 1303, 1311 (Fed. Cir. 2001). Once a court has determined the limitation's function, "the next step is to determine the corresponding structure disclosed in the specification and equivalents thereof." Id. A "structure disclosed in the specification is 'corresponding' structure only if the specification or prosecution history clearly links or associates that structure to the function recited in the claim." Id. Moreover, the focus of the "corresponding structure" inquiry is not merely whether a structure is capable of performing the recited function, but rather whether the corresponding structure is "clearly linked or associated with the [recited] function." Id .
III. THE PARTIES' STIPULATED TERMS
The parties agreed to the constructions of the following terms/phrases in their November 6, 2020 P.R. 4-5(d) Joint Claim Construction Chart.
| Claim Term/Phrase | Agreed Construction |
|---|---|
| "concatenating"• '844 Patent Claims 1, 3, 5, 6, 9, 10• '845 Patent Claims 1, 8 | "appending one item to the end of another so asto form a single unit in a contiguous pattern" |
| "home gateway"• '844 Patent Claim 12• '845 Patent Claims 1, 8 | "any equipment for interconnecting a privatenetwork and a network operated by a serviceprovider, the private network being either a homenetwork or a business network" |
| "combining"• '965 Patent Claim 1 | Plain and ordinary meaning. |
IV. CONSTRUCTION OF NON-MEANS-PLUS-FUNCTION TERMS
The parties dispute the meaning of nine non-means-plus-function terms/phrases.
A. "IPv4 destination address" / "IPv4 address of said destination terminal"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "IPv4 destinationaddress" / "IPv4 addressof said destinationterminal" | Plain and ordinary meaning. | "32 bits formatted according toInternet Protocol version 4identifying the destinationequipment" |
1. The Parties' Positions
The parties dispute whether an IPv4 destination address must be construed as 32 bits in length, as Defendant proposes, or if an IPv4 destination address can include "numerous options" for encoding, as Plaintiff proposes. Plaintiff agrees that when used within an IPv4 packet, IPv4 addresses are typically comprised of 32-bits. Dkt. No. 88 at 8. Plaintiff argues that the claims detail concatenating an IPv4 address with other information to form an IPv6 address, which is 128-bits wide. Id. Plaintiff contends that the IPv4 address can be encoded or represented differently within an IPv6 address for an IPv6 packet than it is within an IPv4 packet. Id.
According to Plaintiff, there are numerous options for encoding IPv4 address information into bit patterns, and the claims are not limited to any particular encoding scheme for the IPv4 address when using it to construct an IPv6 address. Id. (citing Dkt. No. 88-5 at 30:17-31:23). Finally, Plaintiff argues that Defendant's importation of a "destination equipment" limitation should be rejected. Id. (citing '844 Patent at 8:62-9:38).
Defendant responds that the intrinsic record repeatedly states that an IPv4 address has 32 bits. Dkt. No. 96 at 11 (citing '844 Patent at 1:61-62, 6:21-24, 9:26-30, 10:33-37, Figs. 2, 4; '845 Patent at 7:26-29, 10:28-32, 15:37-42, Figs 2, 4, 7; '965 Patent at 3:57-60, Figs. 7a, 7b). According to Defendant, the 32-bit nature of IPv4 addresses is fundamental to the technology evolution that drove the need for the patented inventions. Id. at 12 (citing '844 Patent 10:33-37; '845 Patent at 15:37-42).
Defendant also argues that the extrinsic evidence confirms that an IPv4 address has 32 bits. Id. at 11 (citing Dkt. No. 96-10 at 7, 18; Dkt. No. 96-13 at 5; Dkt. No. 96-15 at 4). Defendant contends that Plaintiff's argument that 32 bit addresses can be denoted by humans in non-binary ways does not change the 32-bit nature of the data within the claimed packets. Id. Defendant argues that the claims refer to a "destination IPv4 address" as being within a data packet, not as denoted by a human. Id.
Plaintiff replies that the specification teaches that the bit encodings depicted in Figs. 2 and 4 of the '844 and '845 Patents are exemplary and not intended to be limiting. Dkt. No. 103 at 4 (citing '845 Patent at 6:51-55, 11:62-63; '844 Patent at 5:53-57, 8:58-61). Plaintiff also argues that even if an IPv4 address is implemented with a length of 32-bits in an IPv4 header, that does not mean that an IPv4 address must be encoded as exactly 32 bits in an IPv6 header. Id. (citing Dkt. No. 88-5 at 30:17-31:23). Plaintiff contends that there are numerous options for encoding a data value, such as an address. Id. (citing Dkt. Nos. 103-1, 103-2, 103-3, 103-4).
2. Analysis
The term "IPv4 destination address" appears in Claims 1, 3, 5, 6, and 10 of the '844 Patent; Claims 1 and 8 of the '845 Patent; and Claims 21, 23, 25, and 26 of the '965 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The term "IPv4 address of said destination terminal" appears in Claims 1, 3, 9, and 14 of the '965 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the intrinsic and extrinsic evidence indicates that the term "IPv4 destination address" should be construed to mean an "address formatted according to Internet Protocol version 4 indicating a destination."
The specification explains that the reason for creating a larger address space via the IPv6 protocol is because IPv4 addresses were running out. '844 Patent at 1:61-62 ("It is commonly accepted in the IP service provider community that IPv4 public addresses are going to run out."). The specification teaches that because IPv4 addresses have fewer bits than IPv6 addresses, the destination IPv4 address can be directly inserted into the larger IPv6 addresses along with additional appended fields to construct a 128-bit destination IPv6 address. See, e.g., '844 Patent 10:33-37 ("The receiving method of the invention thus inserts both the 32 bits of the destination IPv4 address of the received IPv4 packet and the 16 bits of the destination port dest-port to constitute a constructed destination IPv6 address that is referred to as IPv4inIPv6_dest_address."); '845 Patent at 15:37-42 ("The destination port number dest-port is inserted into the right-hand part of the IPv6 constructed destination address. It therefore inserts both the 32 bits of the destination IPv4 address of the received IPv4 packet and the 16 bits of the destination port dest-port to constitute an IPv6 constructed destination address IPv4in IPv6_dest_address."). Thus, the specification indicates that the "IPv4 destination address" must be an "address formatted according to Internet Protocol version 4 indicating a destination."
Defendant argues that an IPv4 destination address must be construed as 32 bits in length. The specification does depict and describe an IPv4 address as having 32 bits. See, e.g., '844 Patent at Figs. 2, 4; 6:21-24; 9:26-30; 10:33-37; '845 Patent Figs. 2, 4, 7; 7:26- 29; 10:28-32; 15:37-42; '965 Patent at Figs. 7a; 7b; 3:57-60. However, the Court disagrees that the 32-bit nature of IPv4 addresses is a critical aspect of the patented inventions. Instead, what is critical is that the recited address be in a format that is a useable IPv4 destination address. See, e.g., '844 Patent at 13:22-28 ("To summarize, the invention makes possible a first phase of migration of IP connectivity services towards IPv6 using packet routing mechanisms that takes the following factors into account: Service operators suffer a problem of running out of IPv4 addresses.").
For example, the specification teaches that in one embodiment a 32-bit destination IPv4 address can be directly inserted into the larger IPv6 addresses along with additional appended fields to construct a 128-bit destination IPv6 address. See, e.g., '844 Patent 10:33-37 ("The receiving method of the invention thus inserts both the 32 bits of the destination IPv4 address of the received IPv4 packet and the 16 bits of the destination port dest-port to constitute a constructed destination IPv6 address that is referred to as IPv4inIPv6_dest_address."); '845 Patent at 15:37-42 ("The destination port number dest-port is inserted into the right-hand part of the IPv6 constructed destination address. It therefore inserts both the 32 bits of the destination IPv4 address of the received IPv4 packet and the 16 bits of the destination port dest-port to constitute an IPv6 constructed destination address IPv4in IPv6_dest_address."). Accordingly, the critical feature of the invention is that an "IPv4 destination address" is an address formatted according to Internet Protocol version 4 indicating a destination.
Turning to the extrinsic evidence, RFC 791 distinguishes between names, addresses, and routes. Dkt. No. 96-10 at 7. Specifically, it states that "A name indicates what we seek. An address indicates where it is. A route indicates how to get there." Id. at 7. Thus, consistent with the intrinsic evidence, there is nothing that necessarily limits the recited "address" to 32 bits in length.
The '965 Patent states that this standard is the basis for the "conventional version of the IP address system known as the 'IPv4 system.'" See '965 Patent at 2:25-28.
That said, RFC 791 does state that "[a]ddresses are fixed length of four octets (32 bits)." Dkt. No. 96-10 at 10, see also id. at 8. Likewise, Newton's Telecom Dictionary also defines an "Internet protocol address" as "a unique 32-bit number for a specific TCP/IP host on the Internet." Dkt. No. 96-13 at 5, see also Dkt. No. 96-15 at 5 (defining "IP Address" as "a 32-bit address"). Plaintiff also agrees that "IPv4 addresses, when used within an IPv4 packet, are typically comprised of 32-bits." Dkt. No. 88 at 8. However, the claim language itself details concatenating an IPv4 address with other information to form an IPv6 address, which is 128-bits wide. Thus, in the context of the intrinsic evidence, a person of ordinary skill in the art would understand that the recited "IPv4 destination address" is not necessarily limited to 32 bits in length, but instead is an "address formatted according to Internet Protocol version 4 indicating a destination."
Plaintiff argues that there are numerous options for encoding IPv4 address information into bit patterns, and that the claims are not limited to any particular encoding scheme for the IPv4 address when using it to construct an IPv6 address. Dkt. No. 88 at 8. To be clear, the Court's construction neither adopts nor rejects the encoding schemes discussed by Plaintiff. Specifically, the intrinsic evidence does not disclose any of the encoding schemes presented by Plaintiff. Thus, whether a particular encoding scheme meets the requirement of an "address formatted according to Internet Protocol version 4 indicating a destination" is a factual issue, and not a claim construction dispute. The Court has resolved the parties' claim construction dispute by rejecting Defendant's 32 bits in length requirement. See O2 Micro Int'l v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008) ("When the parties present a fundamental dispute regarding the scope of a claim term, it is the court's duty to resolve it."). It is now the parties' task to convince the fact finder whether something does or does not fall within the scope of the properly construed claims.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "IPv4 destination address" to mean "address formatted according to Internet Protocol version 4 indicating a destination," and • the term "IPv4 address of said destination terminal" to mean "address formatted according to Internet Protocol version 4 indicating the destination terminal."
B. "destination port number"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "destination portnumber" | Plain and ordinary meaning.In the alternative: "a portdesignation for destinationdevices" | "16 bit integer used by Internettransport protocols to distinguishamong multiple simultaneousconnections to a singledestination host" |
1. The Parties' Positions
The parties dispute whether a "destination port number" is 16 bits in length, as Defendant proposes. Plaintiff argues that Defendant seeks to impose a specific bit-encoding scheme on the claimed destination port number. Dkt. No. 88 at 9. Plaintiff contends that the '844 Patent discloses different encoding options for encoding port number information. Id. (citing '844 Patent at 10:4-8, 5:4-19, 7:43-67, Fig. 2). According to Plaintiff, the specification contemplates encoding port information differently than that proposed by Defendant's construction. Id. Finally, Plaintiff argues that Defendant's construction introduces elements not present in the claims that will lead to juror confusion. Id. at 9-10.
Defendant responds that the specifications of the '844 and '845 Patents confirm that the claimed "destination port number," "dest-port," is 16-bits in length. Dkt. No. 96 at 14 (citing '844 Patent at 10:33-37; '845 Patent at 12:13-18, 15:37-42, 13:29-37, 13:47-55, 14:61-66). Defendant argues that the extrinsic evidence defines a "port number" as having 16 bits. Id. (citing Dkt. No. 96-13; Dkt. No. 96-14). Regarding Plaintiff's arguments, Defendant contends that a "range of port numbers" and "destination port number" have different meanings. Id. at 14-15 (citing '844 Patent at 14:33-35, 16:13-15; '845 Patent at 18:32-34, 18:49-54).
Plaintiff replies that the claims recite "a destination port number," which means one or more destination port numbers. Dkt. No. 103 at 4. Plaintiff argues that Defendant's construction improperly limits this term to a single destination port value. Id. According to Plaintiff, the specification describes how multiple ports (or a range of ports) can be encoded using a value that includes a "ports_pattern/length_of_unvariable." Id. at 4-5 (citing '844 Patent at 7:50-51). Plaintiff argues that Defendant's singular, specific encoding format is inconsistent with the specification. Id. at 5.
2. Analysis
The term "destination port number" appears in Claims 1, 3, 5, 6, and 10 of the '844 Patent; and Claims 1, 6, and 8 of the '845 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. Unlike with the previous terms, the claims here do not recite an "IPv4" destination port number, but instead recite a "destination port number."
As discussed above, IPv6 addresses have substantially more bits (i.e., 4x) than IPv4 addresses. '844 Patent at 6:21-22; '845 Patent at 7:26-27; '965 Patent at 3:57-58. Moreover, the specification discusses a range of port numbers. Referring to Fig. 2, the specification states that "the address shared@IPv4 and the range of port numbers ports_pattern/length_of_unvariable are located in the prefix IPv6_prefix_ports_range of the home gateway 20." '844 Patent at 10:9-13. Thus, the specification discloses a range of ports as a ports_pattern and length_of_unvariable. Id. at 7:65-67 ("[T]he range of authorized port numbers for the home gateway 20 is a range of port numbers reserved for that gateway."), 11:32-35 ("In this situation, the method includes a step PR2 of verifying that this destination port number dest-port belongs to the range of port numbers ports_pattern/length_of_unvariable authorized for the gateway 20."). Accordingly, there is no indication that the patentees intended to limit the destination port number to a specific bit length given that it may be related to a range of port numbers.
Furthermore, the intrinsic and extrinsic evidence indicates that the "destination port number" is a number indicating a logical point of connection with a destination device. The Newton's Telecom Dictionary explains that a port number is "[a] logical point of connection, most especially in the context of TCP (Transmission Control Protocol, which is part of the TCP/IP protocol suite developed for what we now know as the Internet." Dkt. No. 96-13 at 6. Likewise, Technopedia states that "[a] port number is the logical address of each application or process that uses a network or the Internet to communicate." Dkt. No. 96-14 at 2.
The specification further states that "[c]learly, if the IPv4 address assigned to the home gateway 20 is a public address shared between a plurality of gateways, it is necessary for the source port number contained in the IPv6 constructed source address of the received data packet to belong to the range of port numbers reserved for this gateway." '845 Patent at 14:52-56. Accordingly, the Court construes "destination port number" to mean "number indicating a logical point of connection with a destination device."
Defendant argues that the specifications confirm that the claimed "destination port number" is 16-bits in length. Dkt. No. 96 at 14. The Court agrees that the specification discloses an embodiment where the destination port number is 16-bits. However, the specification and extrinsic evidence also indicates that this is within the context of the IPv4 standard. For example, the specification states that "said data packet includes an IPv4 destination address and an IPv4 destination port number." '844 Patent at 3:2-3 (emphasis added). Similarly, Claim 5 of the '844 Patent recites "said data packet comprising an IPv4 destination address and an IPv4 destination port number." '844 Patent at Claim 5 (emphasis added). Accordingly, the intrinsic evidence indicates that when the patentees wanted to limit the claims to "IPv4," they did so explicitly.
Finally, Defendant's construction introduces elements not present in the claims that would confuse a jury. Defendant's construction includes the terms "Internet transport protocols," "multiple simultaneous connections," and "single destination host." These terms do not appear in the specification, and reading them in would confuse, rather than clarify, the scope of the claims.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "destination port number" to mean "number indicating a logical point of connection with a destination device."
C. "an operator prefix"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "an operator prefix" | Plain and ordinary meaning. | "a prefix assigned to an InternetService Provider by its RegionalInternet Registry" |
1. The Parties' Positions
The parties dispute whether the patentees explicitly defined the term "operator prefix" in the specification and during prosecution. Plaintiff argues that there is no evidence that the inventors intended to limit the term's meaning, and therefore, its plain and ordinary meaning should control. Dkt. No. 88 at 10. Plaintiff contends that the specification contemplates that the network operator may be an entity other than an Internet Service Provider ("ISP"). Id. (citing '844 Patent at 1:30-39, 9:2-3, 8:30-32). Plaintiff argues that Defendant's construction is incorrect because it would restrict the universe of "operators" to ISPs. Id.
Plaintiff next argues that the portion of the specification that describes Figure 2 uses permissive language and describes only an embodiment of the invention. Id. at 11 (citing '844 Patent at 9:7-12). Plaintiff contends that other passages of the specification establish that the operator may not be identical to that service provider, with the network operator being the same as the service provider only "[i]n some circumstances." Id. Plaintiff further contends that the specification and claims do not limit an operator to always being an ISP. Id.
Defendant responds that "operator prefix" is not a well-known term in the art. Dkt. No. 96 at 15. Defendant contends that during the '845 Patent's prosecution, the patentees told the Patent Office that the "expression 'operator prefix' is explicitly defined at page 18, lines 18-22 as the prefix assigned to an Internet service provider by its Regional Internet Registry." Id. (citing Dkt. No. 96-7; Dkt. No. 96-5; '844 Patent at 9:6-12; '845 Patent at 10:10-15). Defendant argues that its construction is a direct quote of the patentee's definition. Id. at 16. Defendant further argues that the phrase "operator prefix" is a single phrase used by the patentees in a specifically defined way. Id.
Plaintiff replies that the "operator prefix" concept is the same in both the '844 and '845 Patents, which is defined as the "left-hand part" of the IPv6 address that "identifies a subnetwork of the domain." Dkt. No. 103 at 5 (citing '844 Patent at 6:25-40, 9:44-47; '845 Patent at 7:30-35, 10:46-49). Plaintiff argues that Defendant's construction improperly restricts the term to "operators" who happen to also be ISPs. Id. According to Plaintiff, the specification states an "operator" can be, but is not necessarily, an ISP. Id. (citing '844 Patent at 1:37-39).
Plaintiff further contends that Defendant's reliance on the Fig. 2 "example" improperly limits the claims to a preferred embodiment. Id. Plaintiff argues that Defendant restricts the term to only the exact prefix assigned by the Regional Internet Registry ("RIR"). Id. Plaintiff contends that the operator may delegate different prefixes to its various "subnetworks," without first obtaining those prefixes from the RIR. Id. (citing '844 Patent at 6:54-57). Finally, Plaintiff argues that the patentees never disclaimed claim scope, and merely pointed to an exemplary description of an operator prefix. Id.
2. Analysis
The term "an operator prefix" appears in Claims 1, 3, 5, 6, 9, and 10 of the '844 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the patentees explicitly defined the term "operator prefix" in the specification, as indicated in the prosecution history.
"Operator prefix" was originally in the claims filed in the application for '845 Patent. In response to a 35 U.S.C. ¶ 112, second paragraph rejection, the patentees argued that the "expression 'operator prefix' is explicitly defined at page 18, lines 18-22 as the prefix assigned to an Internet Service Provider by its Regional Internet Registry." Dkt. No. 96-7 at 9 (emphasis added). The portion of the specification referenced by the patentees states that "this prefix is advantageously chosen so that it is inscribed in the IPv6 operator prefix IPv6-prov assigned to the IP connectivity service provide by its Regional Internet Registry (RIR) and thus includes this operator prefix in its first bits." Dkt. No. 96-7 at 7.
The same rejection and argument was made during the prosecution of the '844 Patent. Dkt. No. 96-6 at 5. The portions of the specifications referenced include the '844 Patent at 9:6-12, and the '845 Patent at 10:10-15. Moreover, Plaintiff agrees that "operator prefix" concept is "the same in both the '844 and '845 patents." Dkt. No. 103 at 5. Thus, the Court adopts this definition because it is was clearly and unambiguously defined by the patentees in the file history. Vitronics Corp., 90 F.3d at 1582 (A patentee's definition governs "so long as the special definition of the term is clearly stated in the patent specification or file history").
Plaintiff argues that there is no evidence that the patentees intended to limit the term's meaning and, therefore, its plain and ordinary meaning should control. Dkt. No. 88 at 10. Plaintiff contends that the specification indicates that the "operator" may be an ISP, but that the specification also indicates this is not always the case. Id. Regarding the prosecution history, Plaintiff argues that the patentees "merely pointed to an exemplary description of an operator prefix." Dkt. No. 103 at 5. The Court disagrees.
As indicated above, the patentees argued that "operator prefix" was "explicitly defined" in the specification. Dkt. No. 96-7 at 9. The Court finds that the "notice function is critical because it provides competitors with the necessary information upon which they can rely to shape their behavior in the marketplace." Litton Sys., Inc. v. Honeywell, Inc., 145 F.3d 1472, 1474 (Fed. Cir. 1998) (Gajarsa, J., dissenting). Indeed, the "[p]ublic notice of the scope of the right to exclude, as provided by the patent claims, specification and prosecution history, is a critical function of the entire scheme of patent law." Id. Accordingly, the Court holds the patentees to the express definition they argued for in the prosecution history.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "an operator prefix" to mean "a prefix assigned to an Internet Service Provider by its Regional Internet Registry."
D. "an interconnection equipment of the IPv6 domain with the IPv4 destination address"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "an interconnectionequipment of the IPv6domain with the IPv4destination address" | Plain and ordinary meaning.In the alternative: "A routingor switching device in the IPv6domain that routes the IPv6data packet using the IPv6constructed destinationaddress, with the IPv6constructed destination addressincluding the IPv4 destinationaddress" | "an equipment that is addressablein the IPv6 domain thatinterconnects the IPv6 domainand IPv4 domain and isaddressable by the IPv4destination address of the datapacket" |
1. The Parties' Positions
The parties agree that the claimed "interconnection equipment" is in an IPv6 domain. The parties dispute whether the claimed "interconnection equipment" must interconnect IPv4 and IPv6 domains. Plaintiff argues that the constructed address includes the IPv4 destination address. Dkt. No. 88 at 12 (citing '844 Patent at Figs. 2, 4). According to Plaintiff, the received IPv4 data packet is encapsulated in an IPv6 data packet and routed through the IPv6 domain. Id. (citing '844 Patent at 10:38-58, 11:49-54).
Plaintiff also argues that Defendant's construction should be rejected because it uses the term "addressable," which is not recited within the specification. Id. Plaintiff further contends that Defendant's construction requires the interconnection equipment to be addressable in the IPv6 domain and the IPv4 domain from which the packet originates. Id. Plaintiff argues that the claim language specifies that the interconnection equipment is not only addressable in the IPv6 domain, but also that it resides on the IPv6 domain. Id.
Defendant responds that the claim and specification confirms that interconnection equipment connects IPv4 and IPv6 networks. Dkt. No. 96 at 17. According to Defendant, the '844 Patent seeks to allow "IPv6 domains . . . to interconnect with IPv4 domains." Id. (citing '844 Patent at 2:46-55). Defendant argues that the interconnection is facilitated by equipment that is dual-stack. Id. (citing '844 Patent at 3:35-37, 13:51-56). Defendant contends that the home gateway interconnection equipment is described as bridging IPv4 and IPv6 networks. Id. (citing '844 Patent at 5:4-19, 7:32-34, 7:63-8:8, 8:58-9:4, 9:62-10:8, 10:64-11:2, Fig. 1). Defendant argues that Plaintiff's construction is wrong because it requires the device to be "in the IPv6 domain," and does not require the device to "interconnect" an IPv6 domain with an IPv4 domain. Id. at 18.
Plaintiff replies that Defendant's construction limits "interconnection" to mean only interconnecting domains of different types. Dkt. No. 103 at 6. Plaintiff argues that the specification teaches that interconnecting equipment is used to interconnect different networks regardless of whether they are the same type or not. Id. (citing '844 Patent at 1:45-47, 9:59-60). Plaintiff next argues that Defendant's construction requires that interconnection equipment "interconnects the IPv6 domain and [the] IPv4 domain." Id. Plaintiff contends that the only IPv4 domain recited in the claims is the one from which IPv4 packets are received (the source address), which Plaintiff argues is different than the domain with the IPv4 destination address to which the IPv6 data packets are routed. Id. (citing '844 Patent at 3:35-37).
Finally, Plaintiff argues that Defendant's requirement that the interconnection equipment be "addressable by the IPv4 destination address" is nonsensical. Id. Plaintiff contends that Defendant's proposal requires that the interconnection equipment be the destination of the IPv4 packet. Id. Plaintiff argues that this is inconsistent with both the claim context and specification. Id. (citing '844 Patent at 3:35-39, 14:38-42). According to Plaintiff, the interconnection equipment is a pass-through device and not the destination. Id. (citing Dkt. Nos. 103-7, 103-8, 103-9).
2. Analysis
The phrase "an interconnection equipment of the IPv6 domain with the IPv4 destination address" appears in Claims 1 and 5 of the '844 Patent. The Court finds that the phrase is used consistently in the claims and is intended to have the same general meaning in each claim. Claims 1 and 5 recite "constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number." '844 Patent at Claim 1 and 5. The claim language indicates that the phrase "with the IPv4 destination address" modifies the constructed address by reciting the step of "routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address . . . ." Id. (emphasis added). The constructed address includes the IPv4 destination address, as described in the preferred embodiment shown in Figures 2 and 4.
Specifically, the specification states that the received IPv4 data packet is encapsulated in an IPv6 data packet and routed through the IPv6 domain. '844 Patent at 10:38-58 ("One implementation of the invention encapsulates the received IPv4 packet in an IPv6 packet"), 11:50-54 ("Clearly an encapsulated data packet represents a first phase of migrating to IPv6 addressing. It enables routing of IPv4 packets under the IPv6 protocol in the IPv6 domain 1, but after de- encapsulation the IPv4 packets are received and processed under the IPv4 protocol, which makes it necessary for the home gateway 20 to be able to manage an IPv4 address."). The specification further states that the "IPv6 constructed destination address is routable in the IPv6 domain and contains the payload carried by the IPv4 data packet." '844 Patent at 3:16-19. Accordingly, the Court construes the phrase "with the IPv4 destination address" to mean "with the IPv6 constructed destination address including the IPv4 destination address."
The Court further construes the phrase "interconnection equipment of the IPv6 domain" to mean "router of the IPv6 domain." Figure 3 illustrates the steps of "constructing," "generating," and "routing." The specification describes these steps taking place in the access node 40. '844 Patent at 9:62-10:63. The specification states that "[t]he IPv6 domain 1 described with reference to FIG. 1 includes at least one access node 40 of the invention." Id. at 9:48-49. Accordingly, the intrinsic evidence indicates that the term "interconnection equipment of the IPv6 domain" means "router of the IPv6 domain."
Turning to Defendant's construction, the Court does not adopt it because it incorrectly requires an interconnection between "the IPv6 domain and [the] IPv4 domain." The only IPv4 domain recited in the claim is the one from which IPv4 packets are received (the source address), which is different than the domain with the IPv4 destination address to which the IPv6 data packets are routed. In other words, it is the IPv4 destination address that is routed through the IPv6 domain via the recited IPv6 data packet. Indeed, the specification states that the "IPv6 constructed destination address is routable in the IPv6 domain and contains the payload carried by the IPv4 data packet." '844 Patent at 3:16-19.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "interconnection equipment of the IPv6 domain" to mean "a router of the IPv6 domain," and • the term "with the IPv4 destination address" to mean "with the IPv6 constructed destination address including the IPv4 destination address."
E. "regularizing"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "regularizing" | Plain and ordinary meaning.In the alternative: "conforming[the IP address] to thedestination IP domain" | "confirming IP addresses bycreating or using an entry in anaddress translation table of thegateway" |
1. The Parties' Positions
The parties dispute whether "regularizing" means creating or using an entry in an address translation table (known as a "NAT table"), as Defendant proposes. Plaintiff argues that regularizing is nothing more than conforming IP addresses by either replacing a native address with a constructed one, or vice versa. Dkt. No. 88 at 14. Plaintiff contends that the exemplary embodiments described in the specification reinforce that the invention "enables transformation of an IPv4 packet entering an IPv6 domain and an IPv6 packet leaving an IPv6 domain to go to an IPv4 domain without it being necessary to maintain a table of correspondence between the IPv4 and IPv6 address . . . ." Id. at 14-15 (citing '845 Patent at 7:20-24). Plaintiff further contends that there is no requirement to update a NAT. Id. at 15 (citing '845 Patent at 4:36-39, 5:12-17, 10:61-11:13, 16:21-31).
Plaintiff also argues that inserting Defendant's language into Claim 2 results in a circuitous construction. Id. Plaintiff contends that Claim 5 clashes with Defendant's construction. Id. at 16. Plaintiff argues that Claim 5 suggests that the data needed to regularize the address is already in the NAT table, and the method does not require that the NAT table of the gateway is modified at all. Id.
Defendant responds that the claims support its construction. Dkt. No. 96 at 18 (citing '845 Patent at Claims 1, 2, 5). Defendant argues that the specification confirms that the home gateway includes an NAT table, and that "regularizing" involves that NAT table. Id. at 19 (citing '845 Patent at 16:64-67, 1:51-60; '845 Patent at 16:23-31, 4:7-19, 4:32-39, 5:7-34, 6:42-47, 11:7-13, 13:19-28). Defendant contends that Plaintiff does not identify an example of "regularizing" without a NAT table. Id.
Defendant also argues that the '845 Patent claims only IPv6-to-IPv6 translations, unlike the '844 Patent, which, according to Defendant, claims IPv4-to-IPv6 translations. Id. Defendant argues that the claimed "regularizing" changes between constructed IPv6 addresses and native IPv6 addresses, and does not relate to IPv4-to-IPv6 translations. Id. (citing '845 Patent at 16:23-31). Defendant contends that IPv6-to-IPv6 translations are all discussed as requiring the home gateway's NAT table. Id. (citing '845 Patent at 4:7-19, 4:32-39, 5:7-43, 6:42-47, 13:19-28, 16:23-44). Defendant notes that its revised construction is consistent with Claims 2 and 5, and that Plaintiff's argument that its construction requires "updating" is no longer relevant. Id. at 20.
Plaintiff replies that Defendant's narrow interpretation that the claims only cover a packet moving from an IPv6 domain to another IPv6 domain is wrong. Dkt. No. 103 at 6. Plaintiff argues that the relevant element originally stated "routing the modified data packet to its destination" and was corrected to state "routing the IPv6 data packet to its destination." Id. Plaintiff contends that the correction clarified that the antecedent basis for the packet that is routed to its destination is the IPv6 packet originally received and possibly modified. Id. Plaintiff argues that the specification also describes the home gateway transforming packets from IPv6 into IPv4 and vice versa. Id. at 7 (citing '845 Patent at 3:26-29). Plaintiff further argues that the preamble states that the data packet is received "in an IPv6 domain connected to an IPv4 domain . . . ." Id.
Finally, Plaintiff contends that NAT tables are not a necessary part of regularizing the address(es), because the claims are not limited to IPv6-to-IPv6 connections. Id. Plaintiff further contends that the passages cited by Defendant do not always require a NAT table as part of regularizing. Id. Plaintiff argues that Figure 5 includes three steps before routing a packet with constructed addresses. Id. (citing '845 Patent at 13:19-28).
2. Analysis
The term "regularizing" appears in Claims 1, 2, 5, and 8 of the '845 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the term should be given its plain and ordinary meaning, because the claim language itself recites what "regularizing" means. Claim 1 recites that regularizing means replacing said at least one IPv6 address by either replacing a native address with a constructed one, or vice versa. Claim 2, which depends from Claim 1, adds steps to regularizing the source address, which includes "creating an entry in an address translation table." Claim 5, which depends from Claim 1, adds additional steps to regularizing the destination address, which includes "searching an address translation table of the gateway." Thus, the claim language indicates what "regularizing" means.
Regarding Defendant's construction, the Court does not adopt it because it is not consistent with the claim language. The independent claims do not require a NAT table as part of the recited "regularizing." Indeed, the dependent claims indicate that when a NAT table is required, the patentees explicitly recited it in the claims. For example, dependent Clam 2 recites "creating an entry in an address translation table," and dependent Claim 5 recites "searching an address translation table of the gateway."
The specification is consistent with the claims and indicates that "regularizing" may include a number of steps but that a NAT table may only be required in one step. For example, Figure 5 includes three steps (i.e., R1, R21, R22) that occur before step R24, which is the step that "creates an entry in the address translation table of the gateway associating the native source address and the source address constructed." '845 Patent at 13:26-27. In other words, a NAT table entry is not created until after the packet is modified in step R22. Id. at 13:19-25 ("A step R22 for choosing an IPv6 constructed source address . . . and modifies the data packet by replacing the native source address with this constructed address."). Accordingly, the Court rejects Defendant's construction.
Although it is not directly presented in its proposed constructions, Defendant contends that the parties have a fundamental dispute regarding whether the claims of the '845 Patent are limited to only IPv6-to-IPv6 translations, and exclude IPv4-to-IPv6 translations (and vice versa). Dkt. No. 96 at 19 (citing '845 Patent 4:7-19, 4:32-39, 5:7-43, 6:42-47, 13:19-28, 16:23-44). The specification indicates that the claims are not as limited as Defendant contends. In addition to the IPv6-to-IPv6 exchanges cited by Defendant, the specification also describes the home gateway transforming packets from IPv6 into IPv4 and vice versa. '845 Patent at 3:26-29 ("The data packet is therefore sent in IPv4 or IPv6, transformed if necessary into an IPv6 data packet to route it in the IPv6 domain, and if necessary transformed back into an IPv4 data packet.").
The claims support this interpretation because the preamble states that the data packet is received "in an IPv6 domain connected to an IPv4 domain . . . ." Thus, packet delivery to the IPv4 domain is possible. Having resolved the parties' dispute, the Court finds that no further construction is necessary. See U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997) ("Claim construction is a matter of resolution of disputed meanings and technical scope, to clarify and when necessary to explain what the patentee covered by the claims, for use in the determination of infringement. It is not an obligatory exercise in redundancy."); see also O2 Micro, 521 F.3d at 1362 ("[D]istrict courts are not (and should not be) required to construe every limitation present in a patent's asserted claims.").
3. Court's Construction
For the reasons set forth above, the term "regularizing" is given its plain and ordinary meaning.
F. "link"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "link" | "a connection between aninterface on a first device andan interface on a seconddevice" | "part of a pseudo-wire (i.e., asegment) with its own label that isused when broadcasting datastreams" |
1. The Parties' Positions
The parties dispute: (1) whether a "link" is part of a pseudo-wire (i.e., a segment); and (2) whether a "link" must have its own label. Plaintiff argues that the specification gives examples that show the endpoints of a link each terminate on a particular interface on a device. Dkt. No. 88 at 20 (citing '775 Patent at 8:5-8, 6:60-7:2). Plaintiff contends that the specification shows that to set up a link, one must identify both the device (e.g., SPE or T-PE1) and the particular interface (e.g., if2 or IFE) where the link will terminate on that device. Id. Plaintiff argues that a link is not merely any connection between two devices. Id.
Plaintiff further contends that this plain meaning of "link" is supported by extrinsic evidence. Id. (citing Dkt. No. 88-8). Plaintiff argues that Defendant's construction attempts to re-define a "link" as a "segment," which Plaintiff contends has a different meaning from the term "link" to one skilled in the art. Id. Plaintiff further argues that the only use of the term "segment" in the specification appears in citations to a prior art document titled "An Architecture for Multi-Segment Pseudo-Wire Emulation Edge-to-Edge." Id. (citing '775 Patent at 2:1-2). Plaintiff contends that this document says that a "segment" connects two "provider edge" devices, which are devices located at the edge of the network. Id. at 21.
Plaintiff also argues that "segment" is different from a "link" as shown in Figures 2 and 3. Plaintiff agrees that the '775 Patent includes embodiments in which each link is assigned a label, but argues that it further teaches that the link can carry multiple different labels. Id. (citing '775 Patent at 7:25-26, 8:1-5).
Defendant responds that the claims and specification confirm that a link "is part of a pseudo-wire" Dkt. No. 96 at 20 (citing '775 Patent at 2:15-19, 6:25-48, 7:30-67, 8:58-9:10). Defendant contends that these multi-part pseudo-wires are also known as multi-segment pseudo-wires. Id. (citing '775 Patent at 1:66-2:2). Defendant further contends that the specification explains that each "link" is associated with its own label. Id. at 21 (citing '775 Patent at 7:25-67, 9:59-65, 10:21-23, 10:42-63, Figs. 3, 5). Defendant argues that the labels are "used when broadcasting data streams." Id. (citing '775 Patent at 7:25-29; Dkt. No. 96-12).
Regarding Plaintiff's construction, Defendant argues that each link is assigned a single label, and the data packets traversing a path can carry multiple labels to determine which links to traverse. Id. Defendant contends that Plaintiff cannot show that a link is ever assigned multiple labels. Id. Defendant concedes that a data packet can carry multiple labels to identify multiple links, but argues that each link has a single, unique label. Id. at 22. Defendant also argues that the Court should reject Plaintiff's construction because it is not definitional regarding the types of links claimed in the '775 Patent. Id. Defendant also contends that the extrinsic evidence cited by Plaintiff has nothing do with pseudo-wires. Id.
Plaintiff replies that "segment" has a special meaning in the art, and this meaning is not synonymous with "part." Dkt. No. 103 at 9. Plaintiff argues that not all links are part of pseudo-wires, and that other types of links are known in the art. Id. (citing '775 Patent at 1:34-42). Plaintiff contends that Defendant incorrectly argues that any reference to "link" in the prior art necessarily discloses a "pseudo-wire." Id. Plaintiff further argues that Defendant's construction risks confusing the jury into thinking that data traversing a link must carry exactly one label. Id. Plaintiff also argues that Defendant's construction improperly imports an unclaimed "label" limitation from a preferred embodiment. Id.
2. Analysis
The term "link" appears in Claims 1-7 of the '775 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the specification indicates that a link is a connection between the interfaces of two routers. For example, the specification states "[t]he packets sent to the first output router T-PE2 are directed to the interface if2 of the intermediate router S-PE. This interface if2 constitutes a first end of the link L2." Id. at 8:5-8 (emphasis added); see also id. at 6:60-7:2 ("the pseudowires pw1 and pw2 are set up at the initiative of the input router T-PE1 and setting them up is based on the exchange of set-up messages ... [the] first set-up message includes an identifier SAII of the input router T-PE1 [and] an identifier of an input interface IFE associated with an equipment connected to the input router.") (emphasis added). These examples show that in order to set up a link, one must identify both the device (e.g. SPE or T-PE1) and the particular interface (e.g.,if2 or IFE) where the link will terminate on that device.
Regarding the "segment" issue, the Court agrees with Plaintiff that the intrinsic evidence indicates that the term "segment" has a different meaning from the term "link" to one skilled in the art. Dkt. No. 88 at 20. The only use of the term "segment" in the specification appears in citations to a prior art document titled "An Architecture for Multi-Segment Pseudo-Wire Emulation Edge-to-Edge." '775 Patent at 2:1-2. This document defines a "PW [pseudo-wire] Segment" as "[a] part of a single-segment or multi-segment PW, which is set up between two PE [provider edge] devices, T-PEs and/or S-PEs." Dkt. No. 88-8 at 7. In other words, this document appears to define a "segment" as connecting two "provider edge" devices, which are devices located at the edge of the network.
For example, in Figures 2 and 3, these would be the devices labeled T-PE1, T-PE2, and T-PE3, located at the edges of network labeled "PSN" (packet switched network).
Image materials not available for display.
Fig. 2(AA)
Image materials not available for display.
Fig. 3
'775 Patent at Figs. 2, 3. The links in these figures (e.g., L1) do not "span" the entire PSN network from "edge-to-edge." Rather, the links span only part of the PSN (e.g. from T-PE1 to SPE) and do not go all the way from edge to edge. Thus a "segment" is different from the "links" illustrated in Figures 2 and 3.
More importantly, the term "segment" does not appear in the specification. The term does appear in the prosecution history, but the patentees explicitly stated that the "segment" was "between the input router and an intermediary router," consistent with Figures 2 and 3. Dkt. No. 88-10 at 8. Thus, the patentees indicated that they were not giving "link" the same meaning as the prior art document's definition of "segment."
Regarding the label issue, the Court finds that it is not required and could be confusing to the jury. The specification does indicate that each "link" is associated with its own label. For example, the specification states that "[t]he set-up message SIG1 also includes a label lbl1 associated with the first link L1." '775 Patent at 7:25-26; see also id. at 7:49-67, 9:59-65, 10:21-23, 10:42-63. Similarly, the specification explains that links L2 and L3 also have their own labels—lbl2 and lbl3 respectively. Id . at Figs. 3, 5; 7:25-64. The specification also states that "[t]his label is used by the input router T-PE1 and the intermediate router S-PE when broadcasting data streams." Id . at 7:25-29.
However, the specification also teaches that the link can carry multiple different labels. For example the specification states that "[o]n reception of a data packet sent by the input router T-PE1, the intermediate router S-PE uses the label added to the packet by the input router to determine to which output interface if2, if3 to direct the data packet." Id. at 8:1-5. Accordingly, a packet traveling along link L1 from T-PE1 to SPE can have one of at least two different labels, indicating which of two interfaces (if2 or if3) the data packet should be directed to so it can be routed to the next link (L2 or L3). Accordingly, the Court does not adopt this portion of Defendant's construction.
During the claim construction hearing, Defendant argued that the first link is part of a "pseudo-wire." The Court agrees but does not adopt Defendant's construction, because the claims explicitly recite that the links are part of respective pseudo-wires. For example, Claim 1 recites "setting up a first pseudo-wire comprising . . . setting up a second pseudo-wire . . . ." '775 Patent at Claim 1. Defendant has failed to provide a persuasive reason to define "link" as "part of a pseudo-wire (i.e., a segment)," when it is explicitly recited in its proposed construction.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "link" to mean "connection between an interface of a first router and an interface of a second router."
G. "if necessary"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "if necessary" | Plain and ordinary meaning;In the alternative: "If the datapacket's IP header isnonconforming with itsdestination IP domain" | Indefinite |
1. The Parties' Positions
The parties dispute whether the term "if necessary" is indefinite. Plaintiff argues that Claim 1 of the '845 Patent provides the context for this term. Dkt. No. 88 at 12-13. Plaintiff contends that the gateway will regularize one or both of the IPv6 source and destination addresses by replacing that IPv6 address, if necessary. Id. at 13. According to Plaintiff, if an IPv6 address is constructed, it may be replaced with a native address, but if the address is a native one, then it may be replaced with a constructed IPv6 address. Id. Plaintiff argues that the nature of the IPv6 addresses in the received packet and the specified destination of the packet determines which of these replacements is necessary. Id. Plaintiff further argues that the specification indicates that the need for regularization depends on the nature of the packet. Id. (citing '845 Patent at 3:18-29, 13:5-8, 13:17-25, 16:18-28).
Defendant responds that the claim and the specification do not inform a person of ordinary skill in the art when it is necessary to perform the claimed "regularizing" step. Dkt. No. 96 at 22. Defendant contends that Plaintiff's interpretation finds no intrinsic support and contradicts the claims. Id. at 23. According to Defendant, the home gateway always receives an IPv6 packet and sends an IPv6 packet. Id. Defendant also argues that the only destination addresses that reach the "if necessary, regularizing" step are constructed IPv6 destination addresses. Id. at 23-24. Defendant contends that it would always be "necessary" to regularize under Plaintiff's understanding. Id. at 24.
Plaintiff replies that even if the packet must already include a constructed destination address, it may or may not be necessary to regularize the source address. Dkt. No. 103 at 7. Plaintiff contends that in other embodiments, it may not be necessary to regularize the addresses at all. Id. (citing the '845 Patent at Fig. 8). According to Plaintiff, the various situations that make regularizing necessary are laid out in the patent and self-evident from the claims. Id.
2. Analysis
The term "if necessary" appears in Claims 1 and 8 of the '845 Patent. The Court finds that the term is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the phrase is not indefinite, and should be construed to mean "if the IPv6 source address is classified as a native address or if the IPv6 destination address is a constructed address."
Starting with the claim language, Claim 1 is a method claim executed in a home gateway. The gateway may be connected to both an IPv6 domain and an IPv4 domain, and receives an IPv6 packet that includes both an IPv6 source address and an IPv6 destination address. After receiving this packet, the first step of Claim 1 specifies that the gateway identifies that the IPv6 destination address was constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number. Then, "if necessary," the gateway will regularize one or both of the IPv6 source and destination addresses by replacing the IPv6 address. The determination of whether it is necessary depends on whether the IPv6 source address is classified as a native address or if the IPv6 destination address is a constructed address. This understanding comes from the embodiments disclosed in the specification.
The specification states that the need for regularization depends on the nature of the packet. A person of ordinary skill would understand that IPv4 and IPv6 cannot natively communicate with each other. The '845 Patent describes a solution for this problem:
In the context of migration from IPv4 to IPv6, consider a first terminal equipment of an IPv4 domain that can send and receive only IPv4 data packets. In parallel with this, a second terminal equipment of the IPv6 domain can send and receive only IPv6 data packets. According to the invention, if one of these equipments is seeking to send a data packet to the other, it uses its own protocol, but the data is routed in the IPv6 domain using the IPv6 protocol.'845 Patent at 3:18-29 (emphasis added). Thus, the nature of the packet determines whether regularizing the IPv6 address is necessary, because the addresses provided for a data packet must match or comply with the protocol used by the transporting network. The specification further clarifies what "if necessary" means in the context of the claim language when considered in the context of the disclosed embodiments. In the "first implementation of the invention," the specification discloses the following:
The data packet is therefore sent in IPv4 or IPv6, transformed if necessary into an IPv6 data packet to route it in the IPv6 domain, and if necessary transformed back into an IPv4 data packet.
If the IPv6 destination address is classified as a constructed address, the
transmission method of the invention executes a step R2 of regularizing the source address of the packet to be transmitted.
...
If the source address is constructed, the data packet is routed to its destination in the step R3.Id. at 13:5-8, 17-25 (emphasis added). In the "second implementation of the invention," the specification discloses when it is necessary to regularize an address in a received "IPv4inIPv6-pt" packet:
If the source IPv6 address is classed as a native address, the method of the invention executes, before this routing step, a step R22 for choosing an IPv6 constructed source address whose source port number is in the authorized range ports_pattern/length_of_unvariable assigned to the gateway 20 and modifies the data packet by replacing the native source address with this constructed address.
When the packet IPv4inIPv6-pt reaches the home gateway 20, the gateway executes the step R'1 described above of identifying the destination address. If a native destination address is identified, the data packet is routed directly to the destination user terminal in a step R'3.Id. at 16:18-28 (emphasis added). As discussed above, Claim 1 requires "identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address and a destination port number." '845 Patent Claim 1. In other words, the claim language requires the packet to include a constructed destination address. Thus, it is only "necessary" to regularize the "at least one IPv6 address" when the IPv6 source address is classified as a native address or if the IPv6 destination address is a constructed address. Given this construction for "if necessary," the Court finds that the claims, viewed in light of the specification, inform those skilled in the art about the scope of the invention with reasonable certainty. Accordingly, Defendant has failed to prove by clear and convincing evidence that the term is indefinite.
If a constructed destination address is identified, for example with the aid of an identifier contained in the destination address, the step of regularizing the method of the invention of receiving a data packet includes a step R'21 of searching the translation table of the home gateway for an entry containing the constructed destination address.
3. Court's Construction
For the reasons set forth above, the Court construes: • the term "if necessary" to mean "if the IPv6 source address is classified as a native address or if the IPv6 destination address is a constructed address."
H. "modifying the data packet using the regularized address"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "modifying the datapacket using theregularized address" | Plain and ordinary meaning. | Indefinite |
1. The Parties' Positions
The parties dispute whether the phrase "modifying the data packet using the regularized address" is indefinite. Defendant first contends that the step of "modifying the data packet using the regularized address" in Claim 1 cannot mean "plac[ing] . . . the new IP address(es) in the header of the packet," because the step of "regularizing" requires "replacing" the IPv6 addresses in the IPv6 packet. Defendant next contends that Claim 8 is indefinite because it improperly claims a mixed method and apparatus.
Plaintiff argues that the phrase "modifying the data packet using the regularized address" follows the "regularizing" step described above. Dkt. No. 88 at 17. Plaintiff contends that once the IPv6 address is regularized, the data packet is modified using the regularized address. Id. (citing '845 Patent at 3:26-29). Plaintiff argues that the specification is entirely consistent with this plain and ordinary meaning. Id. (citing '845 Patent at 3:26-40, 5:27-34, 12:1-26, 12:19-46, 14:22-44).
Defendant responds that "modifying" is indefinite because the specification fails to disclose any other type of modification made to the IPv6 data packets. Dkt. No. 96 at 24. According to Defendant, the only way to understand the claimed "modifying" is as a second replacement of the regularized addresses in the IPv6 header, which Defendant contends is not disclosed. Id.
Defendant further argues that Claim 8 is indefinite because it improperly claims a mixed method and apparatus. Dkt. No. 96 at 25. Defendant contends that Claim 8 of the '845 Patent recites "a device" with structural elements and also recites the step of "modifying the data packet . . . ." Id. Defendant argues that this makes Claim 8 a system claim that improperly claims the method step of "modifying." Id.
Plaintiff replies that there are no redundancies in the claims. Dkt. No. 103 at 8. Plaintiff argues that Claim 1 of the '845 Patent claims "replacing . . . [an] address" then "modifying the data packet using the regularized address." Id. According to Plaintiff, the specification describes these as separate, but related functions. Id. (citing '845 Patent at 11:7-13, 13:19-28). Plaintiff contends that the address is part of the IP packet header and may be replaced in the receiving router before modifying the data packet with the replacement address. Id.
2. Analysis
The phrase "modifying the data packet using the regularized address" appears in Claims 1 and 8 of the '845 Patent. The Court finds that the phrase is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the phrase is not indefinite, and should be given its plain and ordinary meaning.
Claim 1 of the '845 Patent recites "replacing . . . [an] address" then "modifying the data packet using the regularized address." The specification describes these as related functions. See, e.g., '845 Patent at 11:7-13 ("[A] step R2 of regularizing an address of the data packet ... This step may lead to modification of the data packet. The modified data packet is then routed to its destination (step R3)."). The disputed phrase may appear redundant of the recited "replacement process," but that does not make the claims indefinite.
A person of ordinary skill in the art would understand that the data packet is modified by replacing the source or destination address with a constructed or native address, depending on whether the packet was received by the home gateway or was being sent by the home gateway, as described in Figures 5 and 8. The Court disagrees with Defendant's contention that the only way to understand the claimed "modifying" is as a second replacement of the regularized addresses in the IPv6 header.
Regarding Claim 8, a plain reading of the claim shows that "modifying the data packet" is a second function of the means for regularizing. Specifically, Claim 8 recites:
means for regularizing, if necessary, at least one of the IPv6 source address and the IPv6 destination address of the data packet by (1) replacing said at least one IPv6 address, . . . and (2) modifying the data packet using the regularized address'845 Patent Claim 8 (annotated). Accordingly, a person of ordinary skill in the art would understand this claim as not including mixed methods and apparatuses.
3. Court's Construction
For the reasons set forth above, the phrase "modifying the data packet using the regularized address" is given its plain and ordinary meaning.
I. "the replacement process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address"
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "the replacementprocess belonging to agroup comprisingreplacement of aconstructed address witha native address andreplacement of a nativeaddress with aconstructed address" | Plain and ordinary meaning | Indefinite |
1. The Parties' Positions
The parties dispute whether the phrase "the replacement process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address" is indefinite, because it is an "open" Markush group. Plaintiff contends that Claim 1 describes that one or both of the IPv6 addresses in the data packet are regularized "by replacing said at least one IPv6 address." Dkt. No. 88 at 16. Plaintiff argues that the embodiments described in the specification support this conclusion. Id. at 17 (citing '845 Patent at 4:32-35, 5:22-34). Defendant responds that this phrase is indefinite because it impermissibly claims a Markush group with the open-ended term "comprising." Dkt. No. 96 at 25-26 (citing Abbott Labs. v. Baxter Pharm. Prod., Inc., 334 F.3d 1274, 1280 (Fed. Cir. 2003); MPEP § 2173.05(h)).
Plaintiff replies that the specification describes the addresses as either "replacing the constructed destination address in the IPv6 data packet with [a] native address. . . ." or "replac[ing] the native address . . . with the constructed address . . . ." Dkt. No. 103 at 8 (citing '845 Patent at 16:32-44). According to Plaintiff, no other replacement technique is disclosed. Id. Plaintiff argues that the replacement here is "one or more of the enumerated members of the claimed group," and thus not indefinite. Id.
2. Analysis
The phrase "the replacement process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address" appears in Claims 1 and 8 of the '845 Patent. The Court finds that the phrase is used consistently in the claims and is intended to have the same general meaning in each claim. The Court further finds that the phrase is not indefinite, and should be given its plain and ordinary meaning.
Defendant argues that the claims improperly sets forth an "open" Markush group by reciting "comprising," instead of "consisting of." Dkt. No. 96 at 25 (citing Abbott Labs., 334 F.3d at 1280). Plaintiff contends that Defendant's argument contradicts the Federal Circuit's approach to a Markush limitation. Dkt. No. 103 at 8. The Court agrees with Plaintiff.
In Lexington Luminance LLC v. Amazon.com Inc., the district court determined that a claim was indefinite as an improper Markush group because "it fail[ed] to narrow down the composition of the claimed substrate to any degree of substantial certainty." 601 F. App'x 963, 967 (Fed. Cir. 2015). The Federal Circuit concluded that "the district court erred" because the "issue . . . is whether the claim is indefinite, not whether it recites an 'improper' Markush group" Id. at 968. The panel further stated that "[d]efiniteness involves more than an examination of the technical correctness of the use of a Markush expression that may have slipped past the examining process. It involves evaluation of the claim in light of the written description." Id. (emphasis added). The panel concluded that the written description "provide[d] a clear description" of the claimed components. Id.
Here, the specification indicates that the addresses are replaced, dependent on the direction of the exchange, either by "replacing the constructed destination address in the IPv6 data packet with [a] native address . . ." or "replac[ing] the native address . . . with the constructed address . . . ." See, e.g.,'845 Patent at 13:19-25 (In "step R22 . . . the gateway 20 . . . modifies the data packet by replacing the native source address with this constructed address."), 16:32-34 ("In the step R23, the method of the invention replaces the constructed destination address in the IPv6 data packet with this native address."). With this understanding, the Court finds that the claims are not indefinite.
However, the Court does not agree with Plaintiff's argument that the replacement is one or "more of the enumerated members" of the claimed group. Dkt. No. 103 at 8. Instead, the replacement is one of the enumerated members of the claimed group. Abbott Labs., 334 F.3d at 1281 ("If a patentee desires mixtures or combinations of the members of the Markush group, the patentee would need to add qualifying language while drafting the claim."). Accordingly, the claims are limited to either replacement of a constructed address with a native address or replacement of a native address with a constructed address.
3. Court's Construction
For the reasons set forth above, the phrase "the replacement process belonging to a group comprising replacement of a constructed address with a native address and replacement of a native address with a constructed address" is given its plain and ordinary meaning.
I. CONSTRUCTION OF MEANS-PLUS-FUNCTION TERMS
The parties agree that the following disputed phrases are governed by 35 U.S.C. § 112, ¶ 6. The parties also generally agree on the recited function. The parties, however, disagree on the corresponding structure, and whether five of the phrases are indefinite. The parties' approach to their constructions of these means-plus-function is generally unhelpful. Plaintiff's proposed constructions take the general form of "[a] device for [sending or receiving] . . . including the hardware elements conventionally found in a standard computer or a dedicated router, including a processor, a random-access memory (RAM), a read-only memory (ROM), and telecommunications means for communicating with a network as described at" Plaintiff's proposed constructions confuse the scope of method claims with the scope of means-plus-function claims.
While a method claim can cover many ways of doing the claimed method, the use of means-plus-function claims limits the scope of those claims to "the corresponding structure . . . described in the specification and equivalents thereof." The problem with Plaintiff's approach is that it eliminates any distinction between the different functions, which effectively makes the claims much broader than § 112, ¶ 6 allows. Accordingly, the Court rejects Plaintiff's generic structure because it is not "clearly linked or associated with the claimed function." Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1219 (Fed. Cir. 2003)
Defendant adopts the opposite extreme and either improperly reads limitations into the claims through its proposed structure or contends that the term is indefinite. The claim language generally includes well-known operations in computer science, and would be understood to describe an algorithm. See, e.g., Dkt. No. 88-5 at 17:3-18:12, 26:9-15. Likewise, the parties agree that the term "concatenating" means "appending one item to the end of another so as to form a single unit in a contiguous pattern." Dkt. No. 105-1 at 1. Thus, as discussed in more detail below, the Court rejects Defendant's unnecessary limitations where asserted, and disagrees that the terms are indefinite because a person of ordinary skill in the art would understand that the specification discloses sufficient corresponding structure.
J. "means for constructing ..." / "means for generating ..." / "means for routing ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for constructingan IPv6 destinationaddress byconcatenating anoperator prefix, saidIPv4 destinationaddress, and thedestination portnumber"(Term 11a) | This term is governed by 35U.S.C. § 112(6).Function: "constructing anIPv6 destination address byconcatenating an operatorprefix, said IPv4 destinationaddress, and the destinationport number"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "constructing an IPv6destination address byconcatenating an operator prefix,said IPv4 destination address, andthe destination port number"Structure: The processor 251 ofdevice 25 and the addresstranslation table (NAT table) ofmemory 255 within device 25found within home gateway 20 oraccess node 40. |
| "means for generatingan IPv6 data packetfrom the IPv6constructed destinationaddress and the receivedIPv4 packet"(Term 11b) | This term is governed by 35U.S.C. § 112(6).Function: "generating an IPv6data packet from the IPv6constructed destination addressand the received IPv4 packet"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "generating an IPv6data packet from the IPv6constructed destination addressand the received IPv4 packet"Structure: indefinite. |
| "means for routing thegenerated IPv6 datapacket in the IPv6domain using the IPv6constructed destinationaddress"(Term 11g) | This term is governed by 35U.S.C. § 112(6).Function: "routing thegenerated IPv6 data packet inthe IPv6 domain using theIPv6 constructed destinationaddress"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "routing the generatedIPv6 data packet in the IPv6domain using the IPv6constructed destination address"Structure: The IPv6 routing coreof access node 40. |
|---|
1. The Parties' Positions
The parties agree that the disputed phrases are governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties disagree on the corresponding structure, and whether the specification discloses an algorithm. Regarding the phrase "means for constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number," Plaintiff argues that Defendant's structure fails to recite much of the router structure described in the patent. Dkt. No. 88 at 22. Plaintiff also argues that Defendant's construction improperly includes the NAT table as part of the identified structure. Id.
Plaintiff further contends that Figure 6a discloses the structure for receiving a data packet, and it includes a processor, RAM, ROM, telecommunication means, and computer program code for executing the steps of the invention. Id. (citing '844 Patent at 12:38-57). Plaintiff also argues that the receiving device of Figure 6a includes a "computer program" that "includes instructions for executing the steps of the method of the invention of receiving a data packet described above with reference to FIG. 3." Id. (citing '844 Patent at 12:53-57). Plaintiff contends that Figure 3 illustrates the steps that are coded into the router's receiving hardware and software for performing address construction. Id. (citing '844 Patent at 5:65-67, 10:25-11:15).
Plaintiff next argues that Defendant's structure omits most of the hardware of the receiving device depicted in Figure 6a and all of the algorithms described in the specification. Id. at 23 (citing Dkt. No. 88-5 at 17:3-18:12, 26:9-15, 46:16-22). Plaintiff also argues that Defendant's construction focuses on inclusion of a NAT table even though the specification highlights the stateless nature of the disclosed operation. Id. (citing '844 Patent at 13:43-56). Plaintiff contends that the "means for constructing" limitation is stateless and correlates to a router on the IPv6 domain that does not require a NAT table to construct the IPv6 address. Id. Plaintiff further argues that the '844 Patent only describes a NAT table in conjunction with the home gateway on the private gateway. Id. (citing '844 Patent at 11:42-48).
Regarding the phrase "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet," Plaintiff argues that the '844 Patent teaches that the access equipment in claim 6 can receive an "IPv4 data packet," "construct[] source and destination IPv6 addresses" for the packet, and "generate[] an IPv6 data packet." Dkt. No. 88 at 24 (citing '844 Patent at 12:17-22). Plaintiff contends that the '844 Patent also teaches the "converse operation" of reconstructing an IPv4 data packet from a received IPv6 data packet. Id. at 24 (citing '844 Patent at 12:29-34). Plaintiff also contends that the specification describes the "device adapted to implement both the receiving method and the sending method of the invention," i.e., the corresponding structure for performing these functions. Id. (citing '844 Patent at 12:38-13:22).
Plaintiff next argues that the structures for sending and receiving are described as "the hardware elements conventionally found in a standard computer or a dedicated router, namely a processor 251 [& 261], a random-access memory (RAM) 252 [& 262], a read-only memory (ROM) 253 [& 263], and telecommunications means 254 [& 264] for communicating with the network 1." Id. (citing '844 Patent at 12:41-46, 12:60-65). Plaintiff contends that these structural elements are described "with reference to FIG. 6a" and "FIG. 6b." Id. Plaintiff further contends that Figures 2 and 4 describe the specific bit fields that are used to construct an IPv6 address. Id.
Plaintiff also argues that the term is not indefinite because the '844 Patent specifically indicates that the function is performed by either a dedicated router or a standard computer configured as a router. Id. (citing Dkt. No. 88-5 at 51:24-52:2, 52:16-19, 60:9-13). Plaintiff contends that the '844 Patent provides examples of how to generate IPv4 and IPv6 packets. Id. at 25 (citing '844 Patent at Figs. 2, 4).
Regarding the phrase "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address," Plaintiff argues that its structure includes a "dedicated router." Id. at 31 (citing Dkt. No. 88-5 at 56:25-57:7, 58:23-59:4, 62:3-14). Plaintiff contends that Defendant's construction recites the specific structure of an IPv6 routing core of access node 40. Id. at 31-32. Plaintiff argues that the specification teaches that the access node 40 includes the receiving device that it has identified as structure for this term. Id. at 32 (citing '844 Patent at 12:38-41). Plaintiff further argues that the algorithm for implementing the flowchart of Figure 3 includes the routing step that is detailed in the specification. Id. (citing '844 Patent at 8:39-44, 8:62-9:4, 9:48-61, 10:25-11:15). Plaintiff contends that Defendant's construction is a single component of a router. Id.
Defendant responds that the "means for constructing . . ." includes NAT tables, which it contends is specifically identified in the specification as performing the claimed functions and as being a component of the corresponding structure. Dkt. No. 96 at 26. Defendant argues that the specification describes the two routers that contain the structure for the claimed "constructing" and "extracting" functions as a "home gateway 20" and an "access node 40." Id. (citing '844 Patent at 7:4-28). Defendant contends that home gateway 20 and access node 40 are dual-stack routers that can send and receive IPv4 and IPv6 packets. Id. (citing '844 Patent at 7:4-13, 9:48-56). According to Defendant, both include a device 25 "for receiving a data packet," which includes a NAT table and performs the step of constructing an IPv6 destination address. Id. at 26-27 (citing '844 Patent at 10:13-31, 12:39-41, 12:47-50; Dkt. No. 96-8 at ¶¶ 41-42).
Defendant further argues that home gateway 20 and access node 40 also include a device 26 "for sending a leaving packet," which includes the step of extracting an IPv4 address from an IPv6 address. Id. at 27 (citing '844 Patent at 12:29-34, 12:58-60, 12:66-13:3; Dkt. No. 96-8 at ¶¶ 64-66). According to Defendant, the '844 Patent's home gateway 20 and access node 40 contain two sets of NAT tables, and no other structure specifically corresponding to these functions is disclosed. Id. (citing Dkt. No. 96-8 at ¶¶ 39, 44, 62, 69).
Defendant also argues that Plaintiff cannot explain how "stateless operation" actually relates to any claim term. Id. Defendant contends that Plaintiff confuses the scope of method claims with the scope of means-plus-function claims. Id. at 27-28. Defendant further argues that Plaintiff's structure is unrelated to the claimed function, and have nothing to do with "constructing" or "extracting" data packets. Id. at 28.
Regarding the phrase "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet," Defendant argues that the '844 Patent does not include an algorithm for "generating," and a person of ordinary skill in the art could not generate the '844 Patent's special three-part address simply by employing "a standard computer or dedicated router" from the prior art. Id. at 29 (citing Dkt. No. 96-8 at ¶¶ 46-52, 71-80). Defendant contends that the three-part address structure recited within this means-plus-function term is the allegedly inventive aspect, and requires more than the "standard computers" or "dedicated routers" that were well-known in the prior art. Id. Defendant argues that expert testimony illustrates that those skilled in the art would not recognize these limitations as having a known structure. Id. at 30.
Regarding the phrase "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address," Defendant argues that its structure corresponds to the two types of claimed routing functions. Id. Defendant contends that the parties agree that properly configured routers can route IPv4 and IPv6 packets. Id. Defendant argues that the '844 Patent describes different structures for routing IPv6 and IPv4 packets. Id. at 31. According to Defendant, the "IPv6 routing core" performs the routing function with respect to the IPv6 packets. Id. (citing '844 Patent at 10:59-63). Defendant contends that no other structure is disclosed for this function. Id. (citing Dkt. No. 96-8 at ¶¶ 58, 83).
Regarding the phrase "means for constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number," Plaintiff replies that the algorithm for "constructing" is disclosed in the claim itself. Dkt. No. 103 at 10. Plaintiff argues that concatenation was a well-known computer algorithm. Id. (citing Dkt. No. 88-5 at 17:3-18:12, 26:9-15). Plaintiff also contends that Figure 4 provides an example of an IPv6 address created by concatenation, and the steps for constructing that address are described. Id. (citing '844 Patent at 10:23-31).
Plaintiff further argues that Defendant's reliance on a NAT table as the structure implementing these terms is wrong and contrary to the preferred embodiment. Id. Plaintiff contends that the IPv6 addresses are constructed (and deconstructed) by embedding relevant IPv4 information in the constructed IPv6 address. Id. Plaintiff argues that no additional state or address tables are required. Id. (citing '844 Patent at 2:51-55, 3:46-52, 6:13-20). Plaintiff further argues that NAT tables are never mentioned in the context of "constructing" an IPv6 address or "extracting" data from an IPv6 address. Id. (citing '844 Patent at 11:25-48).
Regarding the phrase "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet," Plaintiff replies that the specification associates the functions of "generating" an IPv4 or IPv6 data packet with the "home gateway 20" and "access node 40," and teaches that these consist of "the hardware elements conventionally found in a standard computer or a dedicated router . . . ." Id. at 11 (citing '844 Patent at 12:17-34, 12:41-46, 12:60-65). Plaintiff also argues that generating IP data packets is a standard router function. Id. (citing Dkt. No. 88-5 at 60:9-13).
Plaintiff further contends that an algorithm is provided by Figures 2 and 4, and their corresponding descriptions. Id. (citing '844 Patent at 12:20-22). Plaintiff argues that a person of ordinary skill in the art would understand that IPv4 and IPv6 data packets are generated by prepending such headers to a data payload to form a packet. Id. (citing Dkt. No. 88-5 at 51:24-52:2).
Regarding the phrase "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address," Plaintiff replies that Defendant proposes different structures for IPv6 routing without any apparent reason. Id. at 13. Plaintiff contends that a person of ordinary skill in the art would understand an IP router discloses structure for routing IP packets. Id. (citing Dkt. Nos. 103-7, 103-8, 103-9).
2. Analysis
The term "means for constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number" appears in Claim 5 of the '844 Patent. The term "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet" appears in Claim 5 of the '844 Patent. The term "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address" appears in Claim 5 of the '844 Patent.
Defendant contends that only the "generating" term in claim 5 requires an algorithm. Defendant argues that the specification fails to disclose an algorithm for this term, and thus the phrase and claim is indefinite. See Mobile Telecomms. Techs., LLC v. Amazon.com, Inc., No. 2:13-CV-883-JRG-RSP, 2014 U.S. Dist. LEXIS 156454, at *64 (E.D. Tex. Nov. 5, 2014) ("On balance, the function of generating a specific type of message, particularly upon receiving another specific type of message, is not performable by any general purpose computer without special programming.").
As with all § 112, ¶ 6 computer processing steps, the Court has to determine when a step crosses the line from the simplistic to the abstract, thereby requiring an algorithm. See, e.g., Katz Interactive Call Processing Patent Litig. v. Am. Airlines, Inc., 639 F.3d 1303, 1316 (Fed. Cir. 2011) (holding that it is "not necessary to disclose more structure than the general purpose processor that performs those functions" because such functions are "coextensive with the structure disclosed."). Indeed, Defendant agrees that a number of the disputed processing steps do not require an algorithm, and only require a generic structure with certain structural limitations.
a. "means for constructing ..."
The parties dispute whether the appropriate structures for the "means for constructing . . ." includes a NAT table, as Defendant proposes. The Court finds that the algorithm for "constructing" is disclosed in the claim itself: "concatenating an operator prefix, said IPv4 destination address, and the destination port number." Additionally, Figures 2 and 4 provide examples of an IPv6 address prefix created by concatenation. Accordingly, the Court finds that the corresponding structure disclosed in the specification is "access node 40 with a device 25 that includes a processor programmed to perform the step of constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number as illustrated in Figures 2 and 4."
Turning to Defendant's construction, Defendant's reliance on a NAT table as the structure implementing this term is contrary to the preferred embodiment. The IPv6 addresses are constructed by embedding relevant IPv4 information in the constructed IPv6 address. Therefore, no additional state or address tables are required, as expressly indicated by the specification:
The general principle of the invention relies on constructing an IPv6 address from an IPv4 address, a predetermined operator prefix, and a port number. This enables [packet] transformation . . . without it being necessary to maintain a table of correspondence between the IPv4 and IPv6 addresses in an access node to the IPv6 domain.'844 Patent at 6:13-20; see also id. at 3:46-52 ("Thus the invention makes it possible to route an IPv4 data packet in the form of an IPv6 data packet via an equipment interconnecting the IPv6 domain with an IPv4 domain and to route the packet to its final destination using the payload contained in the packet received by said interconnecting equipment to its destination without having recourse to state tables that are laborious to maintain."). Furthermore, NAT tables are not mentioned in the context of "constructing" an IPv6 address.
b. "means for generating ..."
Defendant argues that the specification fails to disclose an algorithm for "generating," and a person of ordinary skill in the art could not generate the '844 Patent's special three-part address simply by employing "a standard computer or dedicated router" from the prior art. Dkt. No. 96 at 29 (citing Dkt. No. 96-8 at ¶¶ 46-52, 71-80). Defendant further contends that the three-part address is the core of the '844 Patent's alleged invention. Id.
Plaintiff argues that the functions are "well-known computer algorithms." Dkt. No. 103 at 10. Defendant responds that this is not the proper standard for definiteness. Dkt. No. 96 at 30. The Court disagree with Defendant's contention, and finds that the specification discloses an algorithm for generating by encapsulating or translating:
In a step PA2, the receiving device of the invention generates an IPv6 data packet IPv4inIPv6-pt from the IPv6 constructed destination address IPv4inIPv6_dest_address and the received IPv4 data packet. One implementation of the invention encapsulates the received IPv4 packet in an IPv6 packet: the IPv6 source address of which is one of the IPv6 addresses that IPv6/IPv4_Access_Node 40 owns (for one of its interfaces); and whose IPv6 destination address is the address IPv4inIPv6_dest_address.'844 Patent at 10:38-58 (emphasis added). Accordingly, the Court finds that the corresponding structure disclosed in the specification is "access node 40 with a device 25 that includes a processor programmed to perform the step of encapsulating the received IPv4 packet in an IPv6 packet or translating the received IPv4 packet IPv4-in-pt into an IPv6 packet."
Another implementation translates the received IPv4 packet IPv4-in-pt into an IPv6 packet with which is associated the construct IPv6 address after previously extracting from the received IPv4 packet its destination IPv4 address, its destination port, its sort IPv4 address, and its source port. Note, however, that if the final destination of the data packet is an IPv4 terminal 21, 22 of the home network 2 of the gateway 20, only the encapsulation is valid. The translation applies when the data packet is going to an IPv6 terminal of the home network 2.
c. "means for routing ..."
With respect to IPv6 packets, the specification states that the "IPv6 routing core" performs the routing function: "In step PA3, the IPv6 data packet IPv4inIPv6-pt generated using the IPv6 constructed destination address is routed in the IPv6 domain 1. [T]he packet IPv4inIPv6-pt therefore enters the IPv6 routing core of the access node IPv6/IPv4_Access_Node 40." '844 Patent at 10:59-63. Accordingly, the Court finds that the corresponding structure disclosed in the specification is access node 40 with a device 25 that includes a processor programmed to perform the step of routing the IPv6 data packet using the IPv6 routing core of the access node
3. Court's Construction
In light of the evidence, the Court finds that the term "means for constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number" in Claim 5 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number" • Corresponding Structure: "access node 40 with a device 25 that includes a processor programmed to perform the step of constructing an IPv6 destination address by concatenating an operator prefix, said IPv4 destination address, and the destination port number as illustrated in Figures 2 and 4"
In light of the evidence, the Court finds that the term "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet" in Claim 5 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet" • Corresponding Structure: "access node 40 with a device 25 that includes a processor programmed to perform the step of encapsulating the received IPv4 packet in an IPv6 packet or translating the received IPv4 packet IPv4-in-pt into an IPv6 packet"
In light of the evidence, the Court finds that the term "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address" in Claim 5 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address" • Corresponding Structure: "access node 40 with a device 25 that includes a processor programmed to perform the step of routing the IPv6 data packet using the IPv6 routing core of the access node"
K. "means for extracting ..." / "means for generating ..." / "means for routing ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for extractingthe IPv4 destinationaddress and thedestination port numberfrom the IPv6destination address"(Term 11c) | This term is governed by 35U.S.C. § 112(6).Function: "extracting the IPv4destination address and thedestination port number fromthe IPv6 destination address"Structure: A home gateway oraccess node with a device forsending a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b." | This term is governed by 35U.S.C. § 112(6).Function: "extracting the IPv4destination address and thedestination port number from theIPv6 destination address"Structure: "The processor 261 ofdevice 26 and the addresstranslation table (NAT table) ofmemory 265 within device 26found within home gateway 20 oraccess node 40." |
| "means for generatingan IPv4 data packetfrom the IPv6 datapacket, said packetincluding said IPv4destination address andsaid destination portnumber"(Term 11b) | This term is governed by 35U.S.C. § 112(6).Function: "generating an IPv4data packet from the IPv6 datapacket"Structure: A device forsending a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "generating an IPv4data packet from the IPv6 datapacket, said packet including saidIPv4 destination address and saiddestination port number"Structure: indefinite. |
|---|---|---|
| "means for routing theIPv4 data packet to itsIPv4 destination"(Term 11h) | This term is governed by 35U.S.C. § 112(6).Function: "routing the IPv4data packet to its IPv4destination"Structure: A device forsending a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "routing the IPv4 datapacket to its IPv4 destination"Structure: Thetelecommunications means 264within home gateway 20 oraccess node 40. |
1. The Parties' Positions
The parties agree that the disputed phrases are governed by 35 U.S.C. § 112, ¶ 6. The parties also generally agree on the recited function. The parties disagree on the corresponding structure, and whether the specification discloses an algorithm. Regarding the phrase "means for extracting the IPv4 destination address and the destination port number from the IPv6 destination address," Plaintiff argues that Claims 6 through 9 include "sending a packet" functionality, which involves extracting address information from a previously constructed IPv6 packet. Dkt. No. 88 at 25. Plaintiff contends that Defendant's construction reflects only a subset of the "sending a packet" functionality and algorithms described in the specification, and it also improperly requires a NAT table. Id. (citing '844 Patent at 13:43-56). Plaintiff further contends that there is no NAT table required or implicated in the de-encapsulation operation. Id. (citing '844 Patent at 11:20-38).
Plaintiff also argues that Figure 6b discloses "the structure of a device of the invention for sending from an IPv6 domain to an IPv4 destination address." Id. at 26 (citing '844 Patent at 6:7-9). Plaintiff contends that this device includes a processor, RAM, ROM, telecommunication means, and computer program code for executing the steps of the invention. Id. (citing '844 Patent at 12:58-13:10). Plaintiff argues that the sending device of Figure 6b includes a "computer program" code that "includes instructions for executing the steps of the method of the invention of sending a data packet described above with reference to FIG. 5." Id. (citing '844 Patent at 13:6-10).
Plaintiff further argues that Figure 5 is a flowchart including the steps of identifying a constructed address (e.g., via extraction), generating an IPv4 packet, and routing that packet toward its destination. Id. (citing '844 Patent at 11:16-41). Plaintiff contends that the first step, identification of a constructed packet, involves reading (or extracting) the bits contained in the IPv6 header regarding the destination address. Id. According to Plaintiff, the specification teaches that the "sending" device performs the converse operation, and this process is further detailed in the specification by reference to the address fields illustrated in Figures 2 and 4. Id. (citing '844 Patent at 11:14-24, 12:29-34). Plaintiff also contends that this bit extraction would be responsible for extracting the previously concatenated IPv4 address and port information. Id.
Plaintiff further argues that Defendant's structure omits most of the hardware of the sending device depicted in Figure 6b and all of the algorithms described in the specification. Id. (citing Dkt. No. 88-5 at 62:15-64:10). Plaintiff contends that the additional instructions are part of the computer code instructions provided with the sending device it has identified as corresponding structure. Id. at 27 (citing '844 Patent at 13:6-10).
Regarding the phrase "means for generating an IPv4 data packet from the IPv6 data packet, said packet including said IPv4 destination address and said destination port number," Plaintiff argues that '844 Patent teaches that the access equipment in claim 6 can receive an "IPv4 data packet," "construct[] source and destination IPv6 addresses" for the packet, and "generate[] an IPv6 data packet." Dkt. No. 88 at 24 (citing '844 Patent at 12:17-22). Plaintiff contends that the '844 Patent also teaches the "converse operation" of reconstructing an IPv4 data packet from a received IPv6 data packet. Id. at 24 (citing '844 Patent at 12:29-34). Plaintiff also contends that the specification describes the "device adapted to implement both the receiving method and the sending method of the invention," i.e., the corresponding structure for performing these functions. Id. (citing '844 Patent at 12:38-13:22).
Plaintiff next argues that the structures for sending and receiving are described as "the hardware elements conventionally found in a standard computer or a dedicated router, namely a processor 251 [& 261], a random-access memory (RAM) 252 [& 262], a read-only memory (ROM) 253 [& 263], and telecommunications means 254 [& 264] for communicating with the network 1." Id. (citing '844 Patent at 12:41-46, 12:60-65). Plaintiff contends that these structural elements are described "with reference to FIG. 6a" and "FIG. 6b" Id. Plaintiff further contends that Figures 2 and 4 describe specifically the bit fields that are used to construct an IPv6 address. Id.
Plaintiff also argues that the term is not indefinite because the '844 Patent specifically indicates that the function is performed by a dedicated router or a standard computer configured as a router. Id. (citing Dkt. No. 88-5 at 51:24-52:2, 52:16-19, 60:9-13). Plaintiff contends that the '844 Patent provides examples of how to generate IPv4 and IPv6 packets. Id. at 25 (citing '844 Patent at Figs. 2, 4).
Regarding the phrase "means for routing the IPv4 data packet to its IPv4 destination," Plaintiff argues Defendant's expert agreed that routers perform routing. Dkt. No. 88 at 32 (citing Dkt. No. 88-5 at 56:25-57:7, 58:23-59:4, 62:3-14). Plaintiff further argues that Defendant's expert was unable to describe the operation of the telecommunication means. Id. (citing Dkt. No. 88-5 at 52:24-53:18). Plaintiff contends that the algorithm for implementing the flowchart of Figure 5 is detailed in the specification. Id. at 33 (citing '844 Patent at 11:16-41). Plaintiff further contends that the computer instructions encoded in the sending device perform routing in the known standard manner. Id. (citing '844 Patent at 12:58-13:10).
Regarding the phrase "means for extracting the IPv4 destination address and the destination port number from the IPv6 destination address," Defendant responds that the "means for extracting . . ." includes NAT tables, which it contends is specifically identified in the specification as performing the claimed functions and as being a component of the corresponding structure. Dkt. No. 96 at 26. Defendant argues that the specification describes the two routers that contain the structure for the claimed "constructing" and "extracting" functions as a "home gateway 20" and an "access node 40." Id. (citing '844 Patent at 7:4-28). Defendant contends that home gateway 20 and access node 40 are dual-stack routers that can send and receive IPv4 and IPv6 packets. Id. (citing '844 Patent at 7:4-13, 9:48-56). According to Defendant, both include a device 25 "for receiving a data packet," which includes a NAT table and performs the step of constructing an IPv6 destination address. Id. at 26-27 (citing '844 Patent at 10:13-31, 12:39-41, 12:47-50; Dkt. No. 96-8 at ¶¶ 41-42).
Defendant further argues that home gateway 20 and access node 40 also include a device 26 "for sending a leaving packet," which includes the step of extracting an IPv4 address from an IPv6 address. Id. at 27 (citing '844 Patent at 12:29-34, 12:58-60, 12:66-13:3; Dkt. No. 96-8 at ¶¶ 64-66). According to Defendant, the '844 Patent's home gateway 20 and access node 40 contain two sets of NAT tables, and no other structure specifically corresponding these functions is disclosed. Id. (citing Dkt. No. 96-8 at ¶¶ 39, 44, 62, 69).
Defendant also argues that Plaintiff cannot explain how "stateless operation" actually relates to any claim term. Id. Defendant contends that Plaintiff confuses the scope of method claims with the scope of means-plus-function claims. Id. at 27-28. Defendant further argues that Plaintiff's structure is unrelated to the claimed function, and has nothing to do with "constructing" or "extracting" data packets. Id. at 28.
Regarding the phrase "means for generating an IPv6 data packet from the IPv6 constructed destination address and the received IPv4 packet," Defendant argues that the '844 Patent does not include an algorithm for "generating," and a person of ordinary skill in the art could not generate the '844 Patent's special three-part address simply by employing "a standard computer or dedicated router" from the prior art. Id. at 29 (citing Dkt. No. 96-8 at ¶¶ 46-52, 71-80). Defendant contends that the three-part address structure recited within this means-plus-function term is the allegedly inventive aspect, and requires more than the "standard computers" or "dedicated routers" that were well-known in the prior art. Id. Defendant argues that expert testimony illustrates that those skilled in the art would not recognize these limitations as having a known structure. Id. at 30.
Regarding the phrase "means for routing the generated IPv6 data packet in the IPv6 domain using the IPv6 constructed destination address," Defendant argues that its structure corresponds to the two types of claimed routing functions. Id. Defendant contends that the parties agree that properly configured routers can route IPv4 and IPv6 packets. Id. Defendant further argues that the '844 Patent describes different structures for routing IPv6 and IPv4 packets. Id. at 31. According to Defendant, the "telecommunications means 264" sends IPv4 packets to network 1 with respect to the IPv4 packets. Id. (citing '844 Patent at 9:50-56, 12:64-65). Defendant contends that no other structure is disclosed for this function. Id. (citing Dkt. No. 96-8 at ¶¶ 58, 83).
Regarding the phrase "means for extracting the IPv4 destination address and the destination port number from the IPv6 destination address," Plaintiff replies that extracting, or deconstructing a previously constructed IPv6 address into its parts is a basic router operation. Dkt. No. 103 at 10. Plaintiff also argues that extraction is simply selecting a range of bits from a given location, and that exemplary bit locations are shown in both Figures 2 and 4. Id. According to Plaintiff, an extraction operation is the converse of construction. Id. (citing '844 Patent at 12:29-34).
Plaintiff further argues that Defendant's reliance on a NAT table as the structure implementing these terms is wrong and contrary to the preferred embodiment. Id. Plaintiff contends that the IPv6 addresses are constructed (and deconstructed) by embedding relevant IPv4 information in the constructed IPv6 address. Id. Plaintiff argues that no additional state or address tables are required. Id. (citing '844 Patent at 2:51-55, 3:46-52, 6:13-20). Plaintiff further argues that NAT tables are never mentioned in the context of "constructing" an IPv6 address or "extracting" data from an IPv6 address. Id. (citing '844 Patent at 11:25-48).
Regarding the phrase "means for generating an IPv4 data packet from the IPv6 data packet, said packet including said IPv4 destination address and said destination port number," Plaintiff replies that the specification associates the functions of "generating" an IPv4 or IPv6 data packet with the "home gateway 20" and "access node 40," and teaches that these consist of "the hardware elements conventionally found in a standard computer or a dedicated router . . . ." Id. at 11 (citing '844 Patent at 12:17-34, 12:41-46, 12:60-65). Plaintiff also argues that generating IP data packets is a standard router function. Id. (citing Dkt. No. 88-5 at 60:9-13).
Plaintiff further contends that an algorithm is provided by Figures 2 and 4, and their corresponding descriptions. Id. (citing '844 Patent at 12:20-22). Plaintiff argues that a person of ordinary skill in the art would understand that IPv4 and IPv6 data packets are generated by prepending such headers to a data payload to form a packet. Id. (citing Dkt. No. 88-5 at 51:24-52:2).
Regarding the phrase "means for routing the IPv4 data packet to its IPv4 destination," Plaintiff replies that Defendant proposes different structures for IPv6 routing without any apparent reason. Id. at 13. Plaintiff contends that a person of ordinary skill in the art would understand an IP router discloses structure for routing IP packets. Id. (citing Dkt. Nos. 103-7, 103-8, 103-9).
2. Analysis
The term "means for extracting the IPv4 destination address and the destination port number from the IPv6 destination address" appears in Claims 6 and 10 of the '844 Patent. The term "means for generating an IPv4 data packet from the IPv6 data packet, said packet including said IPv4 destination address and said destination port number" appears in Claims 6 and 10 of the '844 Patent. The term "means for routing the IPv4 data packet to its IPv4 destination" appears in Claims 6 and 10 of the '844 Patent.
Defendant contends that only the "generating" term requires an algorithm. Defendant argues that the specification fails to disclose an algorithm for this term, and thus the term and claim are indefinite. See Mobile Telecomms. Techs., 2014 U.S. Dist. LEXIS 156454, at *64 ("On balance, the function of generating a specific type of message, particularly upon receiving another specific type of message, is not performable by any general purpose computer without special programming.").
As with all § 112, ¶ 6 computer processing steps, the Court has to determine when a step crosses the line from the simplistic to the abstract, thereby requiring an algorithm. See, e.g., Katz, 639 F.3d at 1316 (holding that it is "not necessary to disclose more structure than the general purpose processor that performs those functions" because such functions are "coextensive with the structure disclosed."). Indeed, Defendant agrees that a number of the disputed processing steps do not require an algorithm, and only require a generic structure with certain structural limitations.
a. "means for extracting ..."
The parties dispute whether the appropriate structures for the "means for extracting . . ." includes a NAT table, as Defendant proposes. The Court finds that the algorithm for "extracting" is disclosed in the specification as determining whether the IPv6 data packet is an IPv6 packet encapsulating an IPv4 packet using the header of the received packet. '844 Patent at 11:20-24. Additionally, Figures 2 and 4 provide examples of an IPv6 address prefix that may be used to determine whether the IPv6 data packet is an IPv6 packet encapsulating an IPv4 packet using the header of the received packet. Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 with a device 26 that includes a processor programmed to perform the step of determining whether the IPv6 data packet is a standard IPv6 packet or an IPv6 packet encapsulating an IPv4 packet using the header of the received packet."
Turning to Defendant's construction, Defendant's reliance on a NAT table as the structure implementing this term is contrary to the preferred embodiment. As discussed above for the "generating" term in Claim 5, the IPv6 addresses are constructed by embedding relevant IPv4 information in the constructed IPv6 address without a state or address table. Likewise, additional state or address tables are not required to reverse the process and extract the IPv4 destination address and the destination port number from the IPv6 destination address. Furthermore, NAT tables are never mentioned in the context of "extracting."
b. "means for generating ..."
Defendant argues that the specification fails to disclose an algorithm for "generating," and a person of ordinary skill in the art could not generate the '844 Patent's special three-part address simply by employing "a standard computer or dedicated router" from the prior art. Dkt. No. 96 at 29 (citing Dkt. No. 96-8 at ¶¶ 46-52, 71-80). Defendant further contends that the three-part address is the core of the '844 Patent's alleged invention. Id.
Plaintiff argues that the functions are "well-known computer algorithms" Dkt. No. 103 at 10. Defendant responds that this is not the proper standard for definiteness. Dkt. No. 96 at 30. The Court disagree with Defendant's contention, and finds that the specification discloses an algorithm for generating by de-encapsulating:
If it is an IPv6 packet encapsulating an IPv4 packet, the sending method includes a first step PR1 of generating an IPv4 packet from the received IPv6 packet. This may entail de-encapsulating the IPv4 packet contained in the packet IPv4inIPv6-pt. Such de-encapsulation yields the packet IPv4-in-pt initially sent by the sender terminal in the IPv4 domain 3 and, in particular, its destination port number dest-port.'844 Patent at 11:9-38 (emphasis added). Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 with a device 26 that includes a processor programmed to perform the step of de-encapsulating the IPv4 packet contained in the packet IPv6 data packet to yield the IPv4 destination address and the destination port number."
c. "means for routing ..."
With respect to routing the IPv4 data packet, the specification states that the home gateway includes an internal network address translation (NAT) for processing the IPv4 data packet:
Note that an internal network address translation (NAT) device is often included in this kind of home gateway if it serves a plurality of user terminals 21, 22 in its home network. The packet IPv4-in-pt received from the outside is then processed by the internal NAT of the home gateway 20 and re-transmitted to the final destination terminal 21 in the home network.'844 Patent at 11:42-48 (emphasis added). Defendant argues that the corresponding structure is the "telecommunications means 264." Dkt. No. 96 at 31. The Court does not adopt "telecommunications means" because it construes a means-plus-function term as a "means." Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 with a device 26 that includes a processor programmed to perform the step of routing the IPv4 data packet to its IPv4 destination by processing the IPv4 data packet with the internal address translation table (NAT table) of the home gateway."
3. Court's Construction
In light of the evidence, the Court finds that the term "means for extracting the IPv4 destination address and the destination port number from the IPv6 destination address" in Claims 6 and 10 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "extracting the IPv4 destination address and the destination port number from the IPv6 destination address" • Corresponding Structure: "home gateway 20 with a device 26 that includes a processor programmed to perform the step of determining whether the IPv6 data packet is a standard IPv6 packet or an IPv6 packet encapsulating an IPv4 packet using the header
of the received packet"
In light of the evidence, the Court finds that the term "means for generating an IPv4 data packet from the IPv6 data packet, said packet including said IPv4 destination address and said destination port number" in Claims 6 and 10 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "generating an IPv4 data packet from the IPv6 data packet, said packet including said IPv4 destination address and said destination port number" • Corresponding Structure: "home gateway 20 with a device 26 that includes a processor programmed to perform the step of de-encapsulating the IPv4 packet contained in the packet IPv6 data packet to yield the IPv4 destination address and the destination port number"
In light of the evidence, the Court finds that the term "means for routing the IPv4 data packet to its IPv4 destination" in Claims 6 and 10 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "routing the IPv4 data packet to its IPv4 destination" • Corresponding Structure: "home gateway 20 with a device 26 that includes a processor programmed to perform the step of routing the IPv4 data packet to its IPv4 destination by processing the IPv4 data packet with the internal address translation table (NAT table) of the home gateway"
L. "first means for advertising ..." / "second means for advertising ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "first means foradvertising to the IPv4domain IPv4 addressesof network equipmentsconnected to the IPv6domain"(Term 11d) | This term is governed by 35U.S.C. § 112(6).Function: "advertising to theIPv4 domain IPv4 addresses ofnetwork equipments connectedto the IPv6 domain"Structure: A device forsending or receiving a datapacket including the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "advertising to theIPv4 domain IPv4 addresses ofnetwork equipments connected tothe IPv6 domain"Structure: indefinite. |
| "second means foradvertising in the IPv6domain IPv6 addressesconstructed from IPv4addresses of the IPv4domain"(Term 11d) | This term is governed by 35U.S.C. § 112(6).Function: "advertising in theIPv6 domain IPv6 addressesconstructed from IPv4addresses of the IPv4 domain"Structure: A device forsending or receiving a datapacket including the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b | This term is governed by 35U.S.C. § 112(6).Function: "advertising in theIPv6 domain IPv6 addressesconstructed from IPv4 addressesof the IPv4 domain"Structure: indefinite. |
1. The Parties' Positions
The parties agree that the disputed phrases are governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties disagree on the corresponding structure, and whether the specification discloses an algorithm. Plaintiff argues that the structure for performing this network advertisement is described in the specification as a dedicated router or standard computer performing routing functions, together with associated hardware and software as shown and described in conjunction with Figures 6a and 6b. Dkt. No. 88 at 27. Plaintiff further argues that the advertisements themselves are described as industry standard routing announcements made by the router to identify the addresses or address prefixes for which it provides routing support. Id. According to Plaintiff, the routing announcements include interior gateway protocol (IGP) advertisements and border gateway protocol (BGP) advertisements. Id.
Plaintiff further contends that the specification describes access equipment in an IPv6 domain that includes an interface to at least one IPv4 domain, which is capable of receiving a data packet from an IPv4 domain in an IPv6 domain, and sending a constructed IPv6 data packet to a different IPv4 domain. Id. (citing '844 Patent at 4:31-46, Figs. 6a and 6b). Plaintiff argues that in one embodiment the access equipment comprises an access node that interfaces to a public IPv4 network. Id. (citing '844 Patent at 4:48-54, 7:4-6, 9:48-51, 9:57-10:31). According to Plaintiff, the access node includes "the hardware elements conventionally found in a standard computer or a dedicated router," including a processor, random access memory (RAM), a read-only memory (ROM) and telecommunications equipment for communicating with the network. Id. (citing '844 Patent at 4:54, 6:4-9, 12:38-13:22, Figs. 6a, 6b).
Plaintiff also argues that the specification explains that for incoming IPv4 calls, an IPv4/IPv6 interconnection or access node "is inserted into the path via dedicated advertisements under the interior gateway protocol (IGP) or the border gateway protocol (BGP)." Id. at 28 (citing '844 Patent at 14:1-4, 14:21-25). Plaintiff contends that the router may broadcast advertisements to the IPv4 domain access nodes to which it interfaces that data packets addressed to the IPv4 addresses specified in the advertisement should be sent to it. Id. (citing '844 Patent at 4:48-58, 10:13-19). Plaintiff further contends that the routing advertisements may be sent using industry standard advertising protocols, which include IGP or the BGP. Id. (citing '844 Patent at 10:19-22, 14:1-4, 14:21-25).
Plaintiff also argues that the routers also may transmit a routing advertisement in the IPv6 domain for IPv6 addresses constructed from IPv4 addresses. Id. (citing '844 Patent at 4:48-58, 8:39-9:4). Finally, Plaintiff contends that the specification identifies specific protocols used for transmitting those routing advertisements as including the IGP or BGP routing advertisements. Id. According to Plaintiff, the claimed advertising is common functionality performed by routers in computer networks. Id. at 29 (citing Dkt. No. 88-5 at 66:3-67:23).
Defendant responds that the specification discloses two "advertising" functions: (1) advertising to the IPv4 domain addresses of equipment connected to the IPv6 domain; and (2) advertising to the IPv6 domain addresses constructed from IPv4 addresses. Dkt. No. 96 at 31 (citing '844 Patent at Claim 7). Defendant contends that these special advertisement functions are critical to the '844 Patent's purpose. Id. Defendant argues that the "advertising" terms are indefinite because the specification does not disclose a structure or algorithm for either special advertising function. Id. at 32 (citing Dkt. No. 96-8 at ¶¶ 90-96).
Defendant further argues that Plaintiff's structure performs the "sending or receiving [of] a data packet," not "advertising." Id. Defendant contends that the specification does not disclose any protocol for accomplishing its claimed special advertising. Id. (citing Dkt. No. 96-8 at ¶¶ 90-96). Defendant also argues that Plaintiff's structure does not even reference router protocols for generic advertising. Id. Finally, Defendant contends that Plaintiff identifies the same structure for both "advertising" limitations, even though accomplishing these two functions "require[s] different specific structures or algorithm." Id. (citing Dkt. No. 96-8 at ¶¶ 92, 96).
Plaintiff replies that the specification explains that the same router structure corresponds to both claimed advertising functions. Dkt. No. 103 at 11. Plaintiff argues that the specification does not need to disclose how advertising messages are generated. Id. Plaintiff contends that the specification describes access node 40 as a dual-stack router capable of routing both IPv4 and IPv6 traffic. Id. at 12 (citing '844 Patent at 9:48-56, 14:1-4). Plaintiff argues that access node 40 routes IPv4 traffic from an IPv4 domain. Id. (citing '844 Patent at 9:52-10:12). Plaintiff contends that the access node advertises, using IGP or BGP protocol messages, to the IPv4 network, which includes the IPv4 addresses for which it can handle routing. Id. (citing '844 Patent at 10:13-21, 14:1-4). Plaintiff argues that these messages define how the claimed first means for advertising function is performed. Id.
Plaintiff next argues that traffic also flows in the reverse direction, from the home gateway network through the IPv6 network to the IPv4 network. Id. (citing '844 Patent at 11:61-12:34; 14:16-26). Plaintiff contends that the access node 40 uses IGP or BGP routing advertisements on the IPv6 network to indicate that it supports IPv6 packets addressed to the constructed IPv6 address. Id. (citing '844 Patent at 8:39-9:4, 14:21-25). Plaintiff argues that this discloses how the second means for advertising function is performed. Id. According to Plaintiff, the specification describes the router structures used for the access node 40. Id. (citing '844 Patent at 12:38-13:22; Figs. 6a, 6b). Plaintiff further contends that the specification also describes the advertising messages transmitted by the router. Id. (citing '844 Patent at 8:58-9:4, 10:13-21, 14:1-26).
2. Analysis
The term "first means for advertising to the IPv4 domain IPv4 addresses of network equipments connected to the IPv6 domain" appears in Claim 7 of the '844 Patent. The term "second means for advertising in the IPv6 domain IPv6 addresses constructed from IPv4 addresses of the IPv4 domain" appears in Claim 7 of the '844 Patent. The Court finds that the corresponding structure for the first and second means is a dual-stack (DS) access router with a processor programmed to perform the recited function. The specification states that "[t]he solution of the invention uses dual-stack (DS) user terminals and home gateways (i.e. user terminals and home gateways that have activated both the IPv4 and IPv6 protocol stacks). Because of this, these equipments are in a position to process (send and receive) IPv4 and IPv6 messages." '844 Patent at 13:51-56.
The specification further states that "the home gateway 20 is connected to the IPv6 network or domain of the operator by a dual-stack (DS) access router 30. This is the first router that the IPv6 and IPv4 data packets encounter when they leave the home gateway." Id. at 8:30-34. Likewise, the specification states that "[t]he IPv6 domain 1 described with reference to FIG. 1 includes at least one access node 40 of the invention . . . The access node 40 (IPv6/IPv4_Access_Node) is a particular Dual-Stack (IPv4 and IPv6) router." Id. at 9:48-52.
Thus, dual access node 40 routes IPv4 traffic from an IPv4 domain. Id. at 9:52-10:12. The access node advertises, using IGP or BGP protocol messages, to the IPv4 network the IPv4 addresses for which it can handle routing. Id. at 14:1-4. Accordingly, the "first means for advertising to the IPv4 domain IPv4 addresses of network equipments connected to the IPv6 domain" is a DS router that includes a processor programmed to perform the step of advertising to an IPv4 domain, IPv4 addresses of network equipment connected to the IPv6 domain.
The DS router is also the "second means for advertising in the IPv6 domain IPv6 addresses constructed from IPv4 addresses of the IPv4 domain." Specifically, the specification states that "the access router 30 may advertise in the upstream direction of the network (i.e. towards the network 1 of the IP connectivity service provider) the IPv6 prefixes that it routes, i.e. the prefixes IPv6_prefix_ports_range and IPv6_prefix_native of the home gateways that it serves." Id. at 8:40-44. This disclosure explains how the second means for advertising function is performed.
Finally, the '844 Patent describes the router structures used for the access node 40. Id. at 12:38-13:22, Figs. 6a, 6b. It also describes the advertising messages transmitted by the router. Id. at 8:58-9:4 (IPv6 advertising), 10:13-21 (IPv4 advertising), 14:1-26 (both IPv4 and IPv6 advertising). Accordingly, the "second means for advertising in the IPv6 domain IPv6 addresses constructed from IPv4 addresses of the IPv4 domain" is a "a dual-stack router that includes a processor programmed to perform the step of advertising in the IPv6 domain, IPv6 addresses constructed from IPv4 addresses of the IPv4 domain."
3. Court's Construction
In light of the evidence, the Court finds that the term "first means for advertising to the IPv4 domain IPv4 addresses of network equipments connected to the IPv6 domain" in Claim 7 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "advertising to the IPv4 domain IPv4 addresses of network equipment connected to the IPv6 domain" • Corresponding Structure: "a dual-stack router that includes a processor programmed to perform the step of advertising to an IPv4 domain, IPv4 addresses of network equipment connected to the IPv6 domain"
In light of the evidence, the Court finds that the term "second means for advertising in the IPv6 domain IPv6 addresses constructed from IPv4 addresses of the IPv4 domain" in Claim 7 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "advertising in the IPv6 domain IPv6 addresses constructed from IPv4 addresses of the IPv4 domain" • Corresponding Structure: "a dual-stack router that includes a processor programmed to perform the step of advertising in the IPv6 domain, IPv6 addresses constructed from IPv4 addresses of the IPv4 domain"
M. "means for obtaining ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for obtaining anIPv4 address, a range ofport numbers, and arange of authorized IPv6addresses"(Term 11i) | This term is governed by 35U.S.C. § 112(6).Function: "obtaining an IPv4address, a range of portnumbers, and a range ofauthorized IPv6 addresses"Structure: A device forsending or receiving a datapacket including the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 12:38-13:22and Figures 6a and 6b. | This term is governed by 35U.S.C. § 112(6).Function: "obtaining an IPv4address, a range of port numbers,and a range of authorized IPv6addresses"Structure: The home gateway 20or access router 30 serving homegateway 20. |
1. The Parties' Positions
The parties agree that the disputed phrase is governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties disagree on the corresponding structure. Plaintiff argues that the specification teaches that the sending and receiving devices identified by it are included in both the home gateway 20 and access router 30. Dkt. No. 88 at 33 (citing '844 Patent at 13:11-15, 13:20-22). Plaintiff contends that the structure identified by Defendant includes the structure identified by Plaintiff. Id.
Defendant responds that the Court should adopt its construction because only the home gateway 20 and access router 30 perform the "obtaining" function. Dkt. No. 96 at 32. According to Defendant, the specification unambiguously attributes the "obtaining" function to the home gateway 20 or its access router 30. Id. at 33 (citing '844 Patent at 5:4-9, 8:45-46). Defendant argues that no other structure is described as performing this function. Id. (citing Dkt. No. 96-8 at ¶ 99).
Defendant also contends that the "obtaining" function is distinct from the function of "sending or receiving" packets. Id. (citing Dkt. No. 96-8 at ¶ 104). Defendant argues that even if the access router 30 contains devices 25 and/or 26 for "sending or receiving" packets, this does not negate the fact that the home gateway and access router perform the "obtaining" function. Id.
Plaintiff replies by stating that it "reiterates its opening brief position as to this term." Dkt. No. 103 at 13.
2. Analysis
The term "means for obtaining an IPv4 address, a range of port numbers, and a range of authorized IPv6 addresses" appears in Claim 9 of the '844 Patent. The Court agrees with Defendant that the '844 Patent attributes the "obtaining" function to the home gateway 20 or its access router 30. The specification states that "[a]ccording to another aspect of the invention, such a home gateway includes means for obtaining an IPv4 address . . . ." '844 Patent at 5:4-9. Similarly, the specification states that "[t]he access router 30 obtains the IPv6 prefixes of the home gateways that it serves." '844 Patent at 8:45-46. Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 or access router 30 serving home gateway 20 that includes a processor programmed to perform the step of obtaining an IPv4 address, a range of port numbers, and a range of authorized IPv6 addresses."
3. Court's Construction
In light of the evidence, the Court finds that the term "means for obtaining an IPv4 address, a range of port numbers, and a range of authorized IPv6 addresses" in Claim 9 of the '844 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "obtaining an IPv4 address, a range of port numbers, and a range of authorized IPv6 addresses" • Corresponding Structure: "the home gateway 20 or access router 30 serving home gateway 20 that includes a processor programmed to perform the step of obtaining an IPv4 address, a range of port numbers, and a range of authorized IPv6 addresses"
N. "means for identifying ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for identifyingan IPv6 destinationaddress constructed byconcatenating an IPv6prefix, an IPv4destination address, anda destination portnumber"(Term 11e) | This term is governed by 35U.S.C. § 112(6).Function: "identifying an IPv6destination address constructedby concatenating an IPv6prefix, an IPv4 destinationaddress, and a destination portnumber"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 16:55-17:10. | This term is governed by 35U.S.C. § 112(6).Function: "identifying an IPv6destination address constructedby concatenating an IPv6 prefix,an IPv4 destination address, and adestination port number"Structure: The receiver device ofthe home gateway 20 having aprocessor 251 and memory 255 |
1. The Parties' Positions
The parties agree that the disputed phrase is governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties dispute whether the structure corresponding to this function is just the receiver device or the entire router. Plaintiff argues additional computer program code is required to enable the processor to perform the identifying function specified in the claim. Dkt. No. 88 at 29. Plaintiff contends that it identified a device for receiving data that includes a processor, RAM, ROM, telecommunication means, and programmed computer instructions for performing the "identifying" function. Id. at 29 (citing '845 Patent at 16:55-17:10). Plaintiff further contends that this structure includes the source code implementing the flowcharts depicted in Figures 3, 5, and 8 of the '845 Patent. Id. (citing '845 Patent at 10:61-11:13, 12:27-35, 13:9-14:4, 16:14-54).
Plaintiff also argues that this description includes the claimed "identifying." Id. (citing '845 Patent at 10:61-11:6, 12:34-35, 16:18-24). According to Plaintiff, the '845 Patent explains that a router identifies whether an IPv6 packet is a standard IPv6 packet or a constructed IPv6 packet based on the IPv6/IPv4_Access_Node_Service_prefix. Id. Plaintiff contends that the specification further indicates that a bit field, ADDR_TYPE_TAG, may be used to identify a constructed IPv6 address. Id. (citing '845 Patent at Fig. 8 (steps R'1-R'21)).
Defendant responds that the claim language confirms that "identifying" is part of "receiving." Dkt. No. 96 at 33 (citing '845 Patent at Claim 8). Defendant argues that the home gateway 20 includes "a device of the invention for receiving a data packet," which on receipt of the IPv6 packet, "is adapted to execute the method of the first implementation of the invention . . . This method executes the IPv6 destination address identification step R1 described above." Id. at 34 (citing '845 Patent at 12:28-35). Defendant contends that step R1 matches the claimed function, and is "advantageously executed by a receiver device included in a home gateway connected to the IPv6 domain, such as the gateway 20." Id. (citing '845 Patent at 10:61-11:4). According to Defendant, no other structure is disclosed for the "identifying" function. Id. (citing Dkt. No. 96-8 at ¶ 109).
Regarding Plaintiff's construction, Defendant contends that it is an impermissibly overbroad structure that includes elements that do not correspond with "identifying." Id. (citing Dkt. No. 96-8 at ¶¶ 109-10). Defendant argues that Plaintiff does not limit its structure to only the "receiver device," but instead points to "a standard computer or a dedicated router." Id. Defendant further argues that the specification confirms that those structures include more than simply a "receiving device," such as means for "regularizing" and "routing" data packets. Id. (citing '845 Patent at Claim 8).
Plaintiff replies that identifying a constructed address is similar to extracting the elements comprising a constructed address. Dkt. No. 103 at 12.
2. Analysis
The term "means for identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number" appears in Claim 8 of the '845 Patent. The Court finds that the corresponding structure for the means for identifying is home gateway 20. The specification states the following:
The method of receiving an IPv6 data packet in the IPv6 domain is described below with reference to FIG. 3. It is advantageously executed by a receiver device included in a home gateway connected to the IPv6 domain, such as the gateway 20, and processes data packets coming from the home gateway 2 and data packets coming from the IPv4 domain 3. This kind of method includes a step R1 of identifying the IPv6 destination address as being a IPv6 native destination address or an IPv6 destination address constructed by concatenating an access node prefix, an IPv4 destination address, and a destination IPv4 port number. It is assumed here that the gateway 20 has obtained this prefix beforehand, for example through configuration.'845 Patent at 10:61-67 (emphasis added). Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 that includes a processor programmed to perform the step of identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number."
3. Court's Construction
In light of the evidence, the Court finds that the term "means for identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number" in Claim 8 of the '845 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number" • Corresponding Structure: "the home gateway 20 that includes a processor programmed to perform the step of identifying an IPv6 destination address constructed by concatenating an IPv6 prefix, an IPv4 destination address, and a destination port number"
O. "means for regularizing ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for regularizing,if necessary, at least oneof the IPv6 sourceaddress and the IPv6destination address ofthe data packet byreplacing said at leastone IPv6 address, . . .and modifying the datapacket using theregularized address"(Term 11f) | This term is governed by 35U.S.C. § 112(6).Function: "regularizing, ifnecessary, at least one of theIPv6 source address and theIPv6 destination address of thedata packet by replacing said atleast one IPv6 address, . . . andmodifying the data packetusing the regularized address"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 16:55-17:10. | This term is governed by 35U.S.C. § 112(6).Function: Indefinite. To theextent that these terms are notfound to be indefinite, thefunction is: "regularizing, ifnecessary, at least one of the IPv6source address and the IPv6destination address of the datapacket by replacing said at leastone IPv6 address"Structure: Indefinite. |
1. The Parties' Positions
The parties agree that the disputed phrase is governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties dispute whether this term is indefinite, as Defendant contends, or if the corresponding structure can be described as "the hardware elements conventionally found in a standard computer or a dedicated router," as Plaintiff proposes.
Plaintiff argues that Claim 8 of the '845 Patent specifies: "A device for receiving an IPv6 data packet in an IPv6 domain connected to an IPv4 domain . . . said device for use in a home gateway adapted to connect a user terminal to said IPv6 domain." Dkt. No. 88 at 30. Plaintiff further argues that the specification explains that "'home gateway' refers to any equipment for interconnecting a private network and a network operated by a service provider, the private network being either a home network or a business network." Id. (citing '845 Patent at 1:45-48). Plaintiff contends that the specification also explains that the method of receiving an IPv6 data packet in the IPv6 domain is executed by a receiver device included in the home gateway. Id. (citing '845 Patent at 10:61-67).
According to Plaintiff, the receiver device "includes the hardware elements conventionally found in a standard computer or a dedicated router, namely a processor 251, a random-access memory (RAM) 252, a read-only memory (ROM) 253, and telecommunications means 254 for communicating with the network 1." Id. (citing '845 Patent at 16:55-17:10). Plaintiff argues that these routers with their associated hardware and software components are designed to support sending and receiving data packets. Id. (citing '845 Patent at 1:45-56, 16:55-17:10, Fig. 9).
Plaintiff also argues that the specification explains that these home gateways are located on the path of data packets between terminals and the IP domain of the operator. Id. (citing '845 Patent at 1:51-53). Plaintiff contends that the gateways include a table which associates the private IP address and port address of the terminal with a public IP address and port on the public network. Id. (citing '845 Patent at 1:53-56). Plaintiff argues that this table is known to those skilled in as a NAT table and several different types of NAT tables are known in the art. Id. (citing '845 Patent at 1:57-60). According to Plaintiff, the NAT table is stored on memory in or connected to the receiving device. Id. (citing '845 Patent at 16:64-17:2). Plaintiff further contends that the memory also includes programing with instructions for executing the claimed methods, including regularizing the data packet. Id. (citing '845 Patent at 5:62-64, 17:3-7).
Plaintiff next contends that in addition to the conventional router hardware and software, the specification describes several specific protocols that may be used to regularize a data packet, including those discussed in relation to steps R2, R21, R22, R23, R24, R'21, R'22, and R'23. Id. at 31 (citing '845 Patent at 5:7-34, 11:7-13, 11:45-67, 13:5-14:2, 14:15-44, 14:46-51, 16:23-52). Plaintiff argues that these protocols are executed by a computer program, either on the receiving device or a general purpose computer. Id. (citing '845 Patent at 5:62-6:2). According to Plaintiff, the program includes instruction for executing the steps of the methods and can use any programming language. Id. (citing '845 Patent at 5:65-24).
Defendant responds that this term is indefinite because: (1) there is no disclosed structure corresponding to the indefinite function of determining when it is "necessary" to perform the "regularizing;" and (2) no algorithm is disclosed for the claimed "regularizing," i.e., using a NAT table to conform IP addresses. Dkt. No. 96 at 34. Defendant agrees that IPv6-to-IPv6 NAT table translations were well known, but contends that the structure for "regularizing" is indefinite, because the specification does not disclose any structure for determining when it is necessary to perform such a "regularizing" function. Id. at 35.
Defendant further argues that how to "regularize" the special constructed addresses of the '845 Patent "was not a well-known operation to persons of ordinary skill in the art." Id. (citing Dkt. No. 96-8 at ¶ 115). Defendant contends that Plaintiff must identify a specific algorithm for accomplishing this function. Id. Defendant argues that Plaintiff has not identified an algorithm, and instead points to "the generic components of the home gateway 20." Id. (citing Dkt. No. 96-8 at ¶ 117).
Plaintiff replies that a plain reading of Claim 8 shows that "modifying the data packet" is a second function of the means for regularizing. Id. at 13 (citing '845 Patent at Claim 1). Plaintiff contends that a person of ordinary skill in the art would not understand this claim to mix methods and apparatuses. Id.
Plaintiff further contends that the specification and Claim 8 associate the function of "regularizing" with the "home gateway 20," which Plaintiff argues includes the hardware elements conventionally found in a standard computer or router. Id. Plaintiff further argues that the specification and claims disclose an algorithm. Id. Plaintiff contends that the specification describes numerous algorithms that may be used to regularize an address and then modify a data packet. Id. Plaintiff argues that several algorithms are provided by Figures 2-8 and the associated descriptions. Id. (citing '845 Patent at 3:10-16, 4:7-35, 5:7-34, 11:7-13, 11:45-67, 12:13-23, 13:5-14:2, 14:15-51, 16:23-52). Plaintiff further contends that a person of ordinary skill in the art would understand that modified packets are created by replacing the source or destination address with a constructed or native address, depending on whether the packet was received by the home gateway or was being sent by the home gateway. Id. (citing '845 Patent at Figs. 2, 4, 6, 7).
2. Analysis
The term "means for regularizing, if necessary, at least one of the IPv6 source address and the IPv6 destination address of the data packet by replacing said at least one IPv6 address, . . . and modifying the data packet using the regularized address" appears in claim 8 of the '845 Patent. Defendant contends that the claims are indefinite because: (1) there is no disclosed structure corresponding to the indefinite function of determining when it is "necessary" to perform the "regularizing;" and (2) no algorithm is disclosed for the claimed "regularizing," i.e., using a NAT table to conform IP addresses. Dkt. No. 96 at 34.
For the reasons discussed above, the Court disagrees with Defendant's contention that the specification fails to disclose when it is necessary to perform the "regularizing" function. As discussed above, the Court construes "if necessary" to mean "if the IPv6 source address is classified as a native address or if the IPv6 destination address is a constructed address." The Court's construction for this § 112(6) term captures the construction for "if necessary."
Furthermore, the specification discloses algorithms that may be used to regularize a data packet, which are illustrated in Figures 5 and 8.
Image materials not available for display.
FIG. 5
Image materials not available for display.
FIG. 8 Regarding Figure 5, the specification states the following:
If the IPv6 destination address is classified as a constructed address, the transmission method of the invention executes a step R2 of regularizing the source address of the packet to be transmitted.
In this first implementation of the invention, this entails identifying in the step R21 if the source address is a constructed address or a native address. An address is considered constructed if it is an IPv6 source address inscribed in IPv6/IPv4_Acess_Node_Service_prefix, all addresses not in this prefix being considered native source addresses. If the identifier ADDR_TYPE_TAG is used, an address is identified as constructed if the identifier ADDR_TYPE_TAG is set to "1".
If the source address is constructed, the data packet is routed to its destination in the step R3.
If the source IPv6 address is classed as a native address, the method of the invention executes, before this routing step, a step R22 for choosing an IPv6 constructed
source address whose source port number is in the authorized range ports_pattern/length_of_unvariable assigned to the gateway 20 and modifies the data packet by replacing the native source address with this constructed address.'845 Patent at 13:5-25. Regarding Figure 8, the specification states the following:
If a constructed destination address is identified, for example with the aid of an identifier contained in the destination address, the step of regularizing the method of the invention of receiving a data packet includes a step R'21 of searching the translation table of the home gateway for an entry containing the constructed destination address. If the result of this search is positive, an entry of this kind associates with the constructed destination address a native destination address IPv6_address_native_Ue of the destination terminal. In the step R'23, the method of the invention replaces the constructed destination address in the IPv6 data packet with this native address. This is particularly advantageous if the data packet IPv4-in-pt is part of a response to a data packet sent beforehand by the destination terminal 21 with its IPv6 native source address, for which the gateway stored this native address in its NAT table before sending it, as described with reference to the previous implementation of the invention. At that time it created the entry in its translation table and replaced the native address of the terminal 21 with the constructed address to enable the access node 40 to extract an IPv4 source address from it when transforming the outgoing IPv6 packet into an IPv4 packet.Id. at 16:21-52.
The step of regularizing the method advantageously further includes a step R'22 of verifying that the transport level destination port of the data packet agrees with the destination port number contained in the destination address of the packet. If the two port numbers do not agree, the packet is rejected. This must not occur if the translation was effected by the access node but this step may be used for monitoring streams coming from the access node.
3. Court's Construction
In light of the evidence, the Court finds that the term "means for regularizing, if necessary, at least one of the IPv6 source address and the IPv6 destination address of the data packet by replacing said at least one IPv6 address, . . . and modifying the data packet using the regularized address" in Claim 8 of the '845 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "regularizing at least one of the IPv6 source address and the IPv6 destination
address of the data packet and modifying the data packet using the regularized address"
• Corresponding Structure: "the home gateway 20 that includes a processor programmed to perform the step of regularizing at least one IPv6 address when:
1. if the IPv6 source address is a native address, then the program executes the steps of choosing an IPv6 constructed source address whose source port number is in the authorized range assigned to the home gateway 20; and modifying the data packet by replacing the native source address with the constructed source address as illustrated in steps R21 and R22 of Figure 5; or
2. if the IPv6 destination address is a constructed address, then the program executes the steps of searching a translation table of the home gateway 20 and locates a native destination address associated with the constructed destination address; verifying that the transport level destination port of the data packet agrees with the destination port number contained in the destination address of the packet; and modifying the data packet by replacing the constructed destination address with the native destination address as illustrated in steps R'21, R'22, and R'23 of Figure 8"
P. "means for routing ..."
| Disputed Term | Plaintiff's Proposal | Defendant's Proposal |
|---|---|---|
| "means for routing theIPv6 data packet to itsdestination"(Term 11j) | This term is governed by 35U.S.C. § 112(6).Function: "routing the IPv6data packet to its destination"Structure: A device forreceiving a data packetincluding the hardwareelements conventionally foundin a standard computer or adedicated router, including aprocessor, a random-accessmemory (RAM), a read-onlymemory (ROM), andtelecommunications means forcommunicating with a networkas described at 16:55-17:10. | This term is governed by 35U.S.C. § 112(6).Function: "routing the IPv6 datapacket to its destination"Structure: Thetelecommunications means 254within home gateway 20. |
1. The Parties' Positions
The parties agree that the disputed phrase is governed by 35 U.S.C. § 112, ¶ 6. The parties also agree on the recited function. The parties dispute whether the structure should be limited to only "telecommunication means 254." Plaintiff argues that its proposed structure captures the processor, RAM, ROM, telecommunications means, and computer program instructions (regarding Figures 3, 5, and 8) within a computer or dedicated router. Dkt. No. 88 at 33-34. Plaintiff contends that routing IPv4 and IPv6 packets is well understood in the art, and a skilled artisan would understand that a router performs routing. Id. at 34.
Plaintiff also argues that the flowcharts in Figures 3, 5, and 8 are described within the specification. Id. (citing '845 Patent at 10:61-11:13, 12:27-35, 13:9-14:4, 16:14-54). According to Plaintiff, the flowcharts explain that the device of the invention performs routing. Id. (citing '845 Patent at 11:12-13, 14:3-4, 16:53-54). Plaintiff contends that the steps detailed in Figures 3, 5, and 8 are programmed into the device structure identified by Plaintiff. Id. (citing '845 Patent at 17:3-7). Finally, Plaintiff argues that the '844 Patent also explains that "routing" is executed by routers in a known standard manner. Id.
Defendant responds that the '845 Patent has only one specific structure, the telecommunication means 254 within the home gateway 20, which Defendant contends routes the IPv6 data packet following the "identifying" and "regularizing" steps. Dkt. No. 96 at 35 (citing '845 Patent at 16:61-63; Dkt. No. 96-8 at ¶ 124). Defendant states that Plaintiff agrees and includes the "telecommunications means" in its proposal, but also includes other irrelevant structures. Id. (citing Dkt. No. 96-8 at ¶¶ 124-125).
Plaintiff replies that Defendant proposes different structures for IPv6 routing without any apparent reason. Dkt. No. 103 at 13. Plaintiff contends that a person of ordinary skill in the art would understand an IP router discloses structure for routing IP packets. Id. (citing Dkt. Nos. 103-7, 103-8, 103-9).
2. Analysis
The term "means for routing the IPv6 data packet to its destination" appears in Claim 8 of the '845 Patent. Defendant argues that the corresponding structure is the "telecommunications means 254." Dkt. No. 96 at 35. Plaintiff also includes "telecommunications means" in its proposed structure. The Court does not adopt "telecommunications means," because it would construe a means-plus-function term as a "means."
Claim 8 of the '845 Patent explicitly recites that the recited device is used in a home gateway. Each of the flowcharts in Figures 3, 5, and 8 is described within the specification. See '845 Patent at 10:61-11:13 (describing Fig. 3), 12:27-35, 13:5-14:4 (describing Fig. 5), 16:14-54 (describing Fig. 8). Each of those explain that the home gateway performs routing. Id. at 11:12-13 ("This step may lead to modification of the data packet. The modified data packet is then routed to its destination (step R3)"), 13:56-58 ("The IPv6 packet containing the constrained source IPv6 address IPv6_address_source_ports_range is routed to the IPv6 access router 30 that serves the gateway in the step R3."), 16:53-54 (describing the routing step).
Finally, the steps detailed in Figures 3, 5, and 8 are programmed into the device in the home gateway. Id. at 17:3-7 ("The read-only memory 255 constitutes a storage medium of the invention that stores the computer program of the invention. The program includes instructions for executing the steps of the method of the invention of receiving an incoming packet described above with reference to FIGS. 3, 5, and 8."). Accordingly, the Court finds that the corresponding structure disclosed in the specification is "home gateway 20 that includes a processor programmed to perform the step of routing the IPv6 data packet to its destination."
3. Court's Construction
In light of the evidence, the Court finds that the phrase "means for routing the IPv6 data packet to its destination" in Claim 8 of the '845 Patent is governed by 35 U.S.C. § 112, ¶ 6, and construes the phrase as follows: • Function: "routing the IPv6 data packet to its destination" • Corresponding Structure: "the home gateway 20 that includes a processor programmed to perform the step of routing the IPv6 data packet to its destination"
II. CONCLUSION
The Court adopts the constructions set forth in this Order for the disputed terms of the Asserted Patents. The parties are ordered to not refer to each other's claim construction positions in the presence of the jury. Likewise, in the presence of the jury, the parties are ordered to refrain from mentioning any portion of this Order, other than the actual constructions adopted by the Court. The Court's reasoning in this Order binds the testimony of any witnesses, and any reference to the claim construction proceedings is limited to informing the jury of the constructions adopted by the Court.
SIGNED this 7th day of January, 2021.
/s/_________
ROY S. PAYNE
UNITED STATES MAGISTRATE JUDGE