Summary
In Implicit, this Court held that a patentee's argument to the PTAB constituted disavowal even though the examiner did not accept that argument.
Summary of this case from Mlc Intellectual Property, LLC v. Micron Technology, Inc.Opinion
Case No. 14-cv-02856-SI
05-06-2015
IMPLICIT L.L.C., Plaintiff, v. F5 NETWORKS, INC., Defendant.
CLAIM CONSTRUCTION ORDER
On March 18, 2015, the Court held a joint tutorial and Markman hearing regarding the construction of one disputed term in one patent owned by plaintiff Implicit L.L.C. ("Implicit"). Having considered the parties' oral arguments and papers submitted, the Court construes the disputed term as follows.
BACKGROUND
I. Procedural History
Implicit filed this case against F5 Networks, Inc. ("F5") on June 20, 2014. Dkt. 1 (Complaint). In this patent infringement suit, Implicit accuses F5's products of infringing U.S. Patent No. 8,694,683 ("the '683 patent"). See Dkt. 1-2 (the '683 patent). The '683 patent is a continuation application or "child" of U.S. Patent No. 6,629,163 ("the '163 patent"). See Dkt. 44-3 (the '163 patent). As a continuation application, the '683 patent shares a common specification with the "parent" '163 patent. Because statements made by the patent owner during prosecution of the '163 patent can be pertinent to claim construction of a related patent, such as the later-issued continuation '683 patent asserted in this case, it is relevant that the United States Patent and Trademark Office ("PTO") granted a request for the '163 patent to undergo ex parte reexamination ("Reexam") on January 17, 2009. The '163 patent emerged from Reexam on June 22, 2010, with additional claim limitations that were held to be patentable over prior art. See Dkt. 44-3 (the '163 patent) at 29-31.
See Manual of Patent Examining Procedures ("M.P.E.P.") § 201.07 (2014) ("The disclosure presented in the continuation must be the same as that of the original application . . . .").
See Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350 (Fed. Cir. 2004) ("Any statement of the patentee in the prosecution of a related application as to the scope of the invention would be relevant to claim construction . . . .").
See Dkt. 43-7 ('163 Reexam 9/1/2009 Amendment and Response); Dkt. 43-8 ('163 Reexam 12/18/2009 Amendment and Response); Dkt. 43-9 ('163 Reexam 2/8/2010 Amendment and Response).
See Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *1 (N.D. Cal. Feb. 29, 2012) ("In order to distinguish Mosberger, the '163 reexamination added a number of significant limitations, including 'dynamically identifying a non-predefined sequence of components' for processing 'messages', wherein 'dynamically identifying includes selecting individual components to create the non-predefined sequence of components' . . . .").
The present case is not the first time that Implicit has asserted the '163 patent family against F5. Approximately one month after the '163 patent issued from Reexam, Implicit filed Case No. 10-cv-3365 against F5 on July 30, 2010; Case No. 10-cv-3746 against Hewlett-Packard Company ("HP"), on August 23, 2010; and Case No. 10-cv-4234 against Juniper Networks, Inc. ("Juniper"), on September 20, 2010. Implicit accused each of the defendants of infringing two patents: the '163 patent and U.S. Patent No. 7,771,857 ("the '857 patent") that issued May 4, 2010, as a continuation "child" application from the '163 patent. See Dkt. 44-4 (the '857 patent). The cases were determined to be related and assigned to this Court.
See Implicit Networks, Inc. v. F5 Networks, Inc., Case No. 3:10-cv-03365-SI (N.D. Cal. 2010).
See Implicit Networks, Inc. v. Hewlett-Packard Company, Case No. 3:10-cv-03746-SI (N.D. Cal. 2010).
See Implicit Networks, Inc. v. Juniper Networks, Inc., Case No. 3:10-cv-04234-SI (N.D. Cal. 2010).
In the previous Case No. 10-cv-3365 between Implicit and F5, all parties agreed that the purpose and result of the '163 patent Reexam was to differentiate the '163 patent claims from the prior art, specifically David Mosberger, "Scout: A Path-Based Operating System," Doctoral Dissertation Submitted to the University of Arizona ("Mosberger"). See Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *1 (N.D. Cal. Feb. 29, 2012); see also Dkt. 43-6 (Mosberger). The Court found that certain statements made by Implicit during the '163 patent Reexam constituted a disclaimer that effectively narrowed the scope of the invention disclosed in the '163 patent specification. See Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *3 (N.D. Cal. Feb. 29, 2012) ("Implicit's Amendment and Response makes clear that what it was disclaiming in the prior art was use of preconfigured sequences of routines, in other words preconfigured paths."). On March 30, 2013, this Court granted summary judgment in favor of F5 and Juniper, concluding that Implicit's '163 and '857 patents were invalid over prior art that was not considered by the PTO. See Dkt. 1-3 at 15; see also Implicit Networks Inc. v. F5 Networks Inc., No. C 10-cv-4234 SI, 2013 WL 1007250 (N.D. Cal. Mar. 13, 2013), appeal dismissed (June 17, 2013), appeal dismissed (June 20, 2013). In addition, based in part on Implicit's '163 patent Reexam disclaimer, the Court found that F5's products did not infringe the '163 and '857 patents. See id.; see also Dkt. 1-3 at 26-29.
On July 13, 2012, prior to the Court's ruling on summary judgment, Implicit and defendant HP stipulated to dismiss the case. See Implicit Networks, Inc. v. Hewlett-Packard Company, Case No. 3:10-cv-03746-SI (N.D. Cal. 2010), Dkt. 103 (Order Dismissing Case).
Less than three months after this Court invalidated the '163 and '857 patents, Implicit filed another continuation application from the '163 patent on June 6, 2013, that later issued as the '683 patent now being asserted against F5 in this case. See Dkt. 1-2 (the '683 patent).
The later issued '683 patent is the latest patent in a series or "family" of related continuation patent applications that claim benefit to the '163 patent, where each continuation application in the series must contain the same disclosure as the '163 patent. See Dkt. 1-2 (the '683 patent) at 1 ("Continuation of application No. 13/236,090, filed on Sep. 19, 2011, now abandoned, which is a continuation of application No. 10/636,314, filed on Aug. 6, 2003, now Pat. No. 8,055,786, which is a continuation of application No. 09/474,664, filed on Dec. 29, 1999, now Pat. No. 6,629,163"); see also M.P.E.P § 201.07 ("At any time before the patenting or abandonment of or termination of proceedings on his or her earlier nonprovisional application, an applicant may have recourse to filing a continuation in order to introduce into the application a new set of claims and to establish a right to further examination by the primary examiner.").
II. Factual Background
A. General Technical Background
The '683 patent relates generally to a computer system for processing messages, where "[a] message is a collection of data that is related in some way, such as [a] stream of video or audio data or an email message." Dkt. 43 (Implicit Opening Brief) at 4:13-20 (quoting the '683 patent at col. 2:49-51). When a message (i.e., a collection of related data) is sent across the internet between computer systems, it is broken down by the transmitting system into smaller pieces called "packets" for transport; the packets are sent across the network; and then the packets must be reassembled by the receiving system. Id. Each individual packet comprises layers of data, where each layer contains data in a different format. Id.
For example, as shown in the figure below, a single message may contain five packets, where each packet includes three layers of data in three different formats: (1) a Transmission Control Protocol ("TCP") layer with data in a TCP format, where the TCP layer is nested within (2) an Internet Protocol ("IP") layer with data in an IP format, and where the IP layer is nested within (3) an Ethernet ("ENET") layer with data in an Ethernet format. Id. at 4:21-23.
Image materials not available for display.
To break down and reassemble the packetized messages having layers of data in different formats, computer systems use software routines to process the data at each layer of the packet and then convert the data into another format that is compatible with the next layer. Id. at 5:6-15. The sending and receiving computers systems must have numerous individual software routines available to process message packets that include layers of data in a variety of formats. See Dkt. 1-2 (the '683 patent) at col. 1:45-48. To process the packetized message described above, the receiving computer system will use a sequence of three software routines: (1) first, the packet is processed by a software routine associated with an ENET protocol, (2) then the packet is processed by a software routine associated with an IP protocol, (3) and finally, the packet is processed by a software routine associated with a TCP protocol. See Dkt. 43 (Implicit Opening Brief) at 5:6-15. Thus, upon receiving a message packet, the computer system will search for the correct sequence of software routines needed to process the packet according to the sequence of layered data formats within the packet. See Dkt. 1-2 (the '683 patent) at col. 2:4-11. While this description is a general overview, the technology has developed over time. A familiarity with the relevant prior art systems is important to understanding the invention disclosed in the '683 patent.
B. The Prior Art Mosberger System
The prior art Mosberger system is relevant to the present case because it was considered by the PTO during the '163 patent Reexam and '683 patent prosecution, and Mosberger was front and center in the earlier Case No. 10-cv-3365 between the parties. The '683 patent relates to a system that is based in part on prior art technology disclosed by Mosberger, thus a description of Mosberger provides the technical context for understanding the '683 patent. Additionally, Implicit went to great lengths to differentiate the '163 patent from Mosberger during the '163 patent Reexam. Statements during the Reexam that describe Implicit's own understanding of Mosberger and the invention disclosed in the '163 patent can be pertinent to construing the claims in the related '683 patent.
See Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350 (Fed. Cir. 2004) ("Any statement of the patentee in the prosecution of a related application as to the scope of the invention would be relevant to claim construction . . . .").
In the early days of computer networking, there were only a limited number of computer applications (e.g., internet browsers, email), and therefore a limited number of different types of packetized messages being transmitted and received between computer systems. See Dkt. 43 (Implicit Opening Brief) at 5:16-6:5. The data formats within these layered packets were predictable, thus the sequences of software routines needed to process the packets could be "purpose-built" for specific applications; in other words the sequences were preconfigured and built into the system itself prior to receiving any message packets. See id. However, the purpose-built systems were only able to process message packets that matched the particular application, and if the system needed to handle a packet containing data in a new format, the developer had to take the system off-line, write code for new software routines that can process the new data format, recompile and rebuild the system, and then put it back online. See id.
Throughout the patents at issue, the patent prosecution histories, and the parties' filings, the terms preconfigured, preidentified, and predefined are treated as having the same meaning: the sequence of routines is configured (i.e., identified) prior to receiving a first packet of a message. See, e.g., Dkt. 43-7 ('163 patent Reexam 9/1/2009 Amendment and Response) at 18 (emphasis added).
Mosberger describes one such prior art system that was prebuilt with a finite set of preconfigured sequences of routines and could not dynamically adapt to process message packets containing layers of data in new formats. During the '163 patent Reexam, Implicit represented its own understanding of the invention disclosed in the '163 patent by citing to the patent specification (common to the related continuation '683 patent in suit) and distinguishing the invention from prior art systems like Mosberger:
ii. The Specification Shows That The 'Sequence of Components for Processing the Packets of the Message' Is Not Pre-Configured as in Mosberger, But Rather Created Dynamically After the 'First Packet of the Message' is Received
The first column of the '163 Patent is critical. It teaches that prior art 'computer systems typically use predefined configuration information to load the correct combination of routines for processing data.' Col. 1, Ins. 41-43. This statement, which must be considered in construing the claims, describes the Mosberger system. The specification then distinguishes the prior art computer systems (like Mosberger) by stating that 'it would be desirable to have a technique for dynamically identifying a series of routines for processing data.' Col. 1, Ins. 64-66. In other words, the '163 Patent clearly states that the invention requires the sequence of routines (that form the paths) to be identified at run-time, and disavows prior art systems (like Mosberger) that use pre-configured paths, which are defined at 'build-time' before the first packet of a message is received.
Consistent with the above, the '163 specification further teaches that 'when a packet of a message is received, the conversion system in
one embodiment searches for and identifies a sequence of routines (or more generally message handlers) for processing the packets of the message by comparing the input and output formats of the routines.' Col. 2, Ins. 40-45. Thus, the specification provides 'interpretive guidance' for the identifying components, namely, that the sequence of routines (or 'path') is not configured prior to receiving the first packet of a message.See Dkt. 43-7 ('163 patent Reexam 9/1/2009 Amendment and Response) at 18 (emphasis added).
In the previous Case No. 10-cv-3365, the Court gave the term "components" the definition specifically provided for it in the '163 patent specification: "software routines." See Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *3 (N.D. Cal. Feb. 29, 2012).
In the previous Case No. 10-cv-3365 between the parties, the Court found that Implicit's September 1, 2009, response "makes clear that what it was disclaiming in the prior art was use of preconfigured sequences of routines, in other words preconfigured paths." Dkt. 1-3 (Order Granting Summary Judgment) at 24:4-5; see also Dkt. 44-17 (Claim Construction Order) at 6:2-10. Critically, the above quoted statements made by Implicit during '163 Reexam were directed to the invention as disclosed in the specification shared by the '163 patent and the continuation '683 patent, and Implicit made no references to any specific '163 patent claim undergoing Reexam. This distinction is important because the Federal Circuit has held that a patent owner's statements regarding the general invention during the prosecution of a "parent" patent may be relevant to construing the claims in a related "child" continuation patent application. See Ormco Corp. v. Align Tech., Inc., 498 F.3d 1307, 1314 (Fed. Cir. 2007) ("When the application of prosecution disclaimer involves statements from prosecution of a familial patent relating to the same subject matter as the claim language at issue in the patent being construed, those statements in the familial application are relevant in construing the claims at issue."). In the present case, Implicit again describes Mosberger at length and annotates a Mosberger figure to differentiate the '683 patent from the Mosberger prior art system.
Implicit Networks Inc. v. F5 Networks Inc., No. C 10-cv-4234 SI, 2013 WL 1007250, at *14 (N.D. Cal. Mar. 13, 2013), appeal dismissed (June 17, 2013), appeal dismissed (June 20, 2013).
Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *3 (N.D. Cal. Feb. 29, 2012).
Image materials not available for display. Dkt. 43 (Implicit Opening Brief) at 6:11-7:25.
According to Implicit, Mosberger discloses three time periods relevant to the system's development and operation: implementation, path creation, and path execution. Id. The first time period (implementation) occurs before any message packets arrive, when the system programmer builds the system's functionality by identifying the appropriate "modules" (i.e., individual software routines) and connecting them into a "module graph" (i.e., a sequence). Id.; see also 43-6 (Mosberger) at 6 ("A modular design supports a mix-and-match approach that allows building the software for a particular [application] by simply selecting and combining the modules that implement the required functionality.").
The second time period (path creation) occurs during system initialization, before any messages arrive. See Dkt. 43 (Implicit Opening Brief) at 6:11-7:25. Path creation involves creating a path according to the identified sequence of routines in anticipation of receiving message packets. See Dkt. 43-10 (the '683 patent prosecution history) at 9. At this point, the paths have been created and await the receipt of message packets. See id. The third and final time period (path execution) occurs when the system receives message packets, identifies which of the previously created paths is appropriate to process a particular message, and then executes the individual routines in that path. See id.; Dkt. 43 (Implicit Opening Brief) at 6:11-7:25. Once the appropriate preconfigured path is found, the message packet is placed in the path's input queue and then processed by the path. See id.
Notably, Mosberger and prior art systems were prebuilt for specific applications with a finite set of preidentified sequences of routines and paths; thus these systems could not process message packets containing new data formats. See id. at 8:1-9; Dkt 43-10 (the '683 patent prosecution history) at 11 ("[T]he paths are created independently of the messages. . . . Importantly, this set of paths is finite; Mosberger does not teach creation of new paths after initialization."). If the Mosberger system needed to process a message packet containing a new data format, the developer had to take the system off-line, write code for new modules (i.e., individual software routines), add the new modules to the appropriate locations within a new module graph (i.e., sequence of routines) and describe their connections to other modules within the graph, recompile and rebuild the entire system, and then put the system back online. Dkt. 43 (Implicit Opening Brief) at 8:1-9.
In sum, Mosberger discloses a system that, upon receiving a message packet, identifies the appropriate path to process the packet from a finite set of preconfigured paths that are based on preconfigured sequences of routines, where the paths and sequences were created and existed before the first message packet was received. See Dkt 43-10 (the '683 patent prosecution history) at 12.
C. The '683 Patent
As networked computer systems (e.g., the Internet) became more pervasive, many new data formats were developed for communicating between systems. See Dkt. 43-1 (the '683 patent) at col. 1:54-57. Because a system may receive data "in many different formats that may not be known until the data is received," the purpose-built prior art systems with paths based on preconfigured sequences of routines were not flexible enough to process all of the new data formats flowing through networks. Dkt. 43 (Implicit Opening Brief) at 8:11-17 (quoting the '683 patent at col. 1:54-57).
To address this problem, the system disclosed in the '683 patent is "a technique for dynamically identifying a series of [] routines for processing data" in received message packets that provides a computer system with flexibility to handle new data formats that may not be known until the message packet is received. Id. (quoting the '683 patent at 2:4-11). Implicit contends that the '683 patent and U.S. Patent No. 7,730,211 ("the '211 patent") specifications disclose a preferred embodiment that creates paths after messages arrive based on information in the received message packets. Dkt. 43 (Implicit Opening Brief) at 8:18-22. These paths are created by using a Label Map Get module to select not only (a) pre-identified sequences of routines that existed before the first message packet was received, but also (b) sequences of routines that are dynamically identified and come into existence only after the first message packet was received. Id.
The '683 patent specification incorporates by reference and thus includes the '211 patent specification. See M.P.E.P. § 2163.07(b) (2014) ("Instead of repeating some information contained in another document, an application may attempt to incorporate the content of another document or part thereof by reference to the document in the text of the specification. The information incorporated is as much a part of the application as filed as if the text was repeated in the application, and should be treated as part of the text of the application as filed.").
The Court finds it helpful at this juncture in the technical discussion to introduce the dispute between the parties: F5 contends that the '683 patent cannot create paths by using (a) pre-identified sequences of routines that existed before a first message packet was received, because Implicit's statements to the PTO during the '163 Reexam disclaimed the use of pre-identified sequences of routines. See Dkt. 44 (F5 Responsive Brief) at 7:7-28, 8:20-9:19.
Continuing with the description of the '683 patent, Implicit explains the general procedure for processing data in a received message packet. See Dkt. 43-1 (the '683 patent) at col. 2:4-6, Figure 1. First, the Driver receives a message packet from an external network (e.g., the Internet). See id. at col. 4:1-15. After receiving the packet, the system calls the Message Send, Demux, and Label Map Get modules. See id. The Label Map Get module is invoked to identify the correct sequence of routines for processing the packet. See id.
The Label Map Get module is described in both of the '683 and '211 patents. See Dkt. 43-1 (the '683 patent) at col. 3:62-67 ("The dynamic identification of conversion routines is described in [the '211 patent]."). The '211 patent discloses the Label Map Get module in Figure 8. See Dkt. 43-11 (the '211 patent) at col. 7:17-8:14, Figure 8. As explained in the following sections, the Label Map Get module is the functionality that can select not only (a) a pre-identified sequence of routines that existed before the first message packet was received, but also (b) a sequence of routines that was dynamically identified and came into existence after the first message packet was received. See Dkt. 43 (Implicit Opening Brief) at 8:18-22.
In the previous Case No. 10-cv-3365, this Court found that the '163 and '893 patent specifications use the terms "media" and "label" interchangeably. See Dkt. 44-17 (10-cv-03365 Claim Construction Order) at 9:14-16.
i. (a) Selecting a pre-identified sequence of routines that existed before a first message packet was received
To select a pre-identified sequence of routines, the Label Map Get module first checks whether the system has already been primed during system initialization with "addresses" (i.e., locations in memory) that indicate pre-identified sequences of routines. Dkt. 43-11 (the '211 patent) at col. 7:17-8:14, Figure 8. During system initialization and before any message packets are received, the embodiment can "prime the cache" with addresses for pre-identified sequences of routines. Id. at col. 3:34-35. In other words, before receiving any message packets, the embodiment can prefill the system with addresses (i.e., locations in memory) for pre-identified sequences of routines. If the primed cache contains an address for a pre-identified sequence of routines that can be used to process the message packet, then the Label Map Get module returns the address for that pre-identified sequence. Id. at col. 7:44-52. Notably, the prior art Mosberger system discloses the same functionality. See Dkt. 43-7 ('163 Reexam 9/1/2009 Amendment and Response) at 13 ("[I]t is clear that the paths in Mosberger are configured (i.e., the sequence of modules comprising the paths is defined) before receiving message packets.").
See also id. at col. 11:1-3 ("In step 1505, the routine stores paths that are to be cached . . . ."), col. 11:19-21 ("The routine may also add addresses of paths to the media cache . . . to prefill the cache with paths."), Figure 15 (step 1505, "Prime caches").
During the March 18, 2015, tutorial and Markman hearing, the parties did not dispute that the '683 and '211 patents disclose an embodiment that may use pre-identified (i.e., pre-configured) sequences of routines, similar to the prior art Mosberger system. However, in the prior Case No. 10-cv-4234, the Court held that Implicit disclaimed this functionality from the shared patent specification during the '163 Reexam: Implicit's response "makes clear that what it was disclaiming in the prior art was use of preconfigured sequences of routines, in other words preconfigured paths." Dkt. 1-3 (10-cv-03365 Order Granting Summary Judgment) at 24:4-5; see also Dkt. 44-17 (10-cv-03365 Claim Construction Order) at 6:2-10. Nonetheless, the Court also found that Implicit "did not disclaim the ability to create a sequence of [] routines by relying in some part on predefined 'configuration information,' but only the use of pre-configured paths." Id at 6:26-28; see also Dkt. 1-3 (10-cv-03365 Order Granting Summary Judgment) at 26:7-9.
Although the Court found that an embodiment disclosed in the '163 and '683 patents' shared specification may rely in some part on "predefined configuration information" to dynamically identify the sequence of routines, this embodiment does not identify the complete sequence of routines needed to fully process the message packet until after the system receives a first message packet. The embodiment of the Label Map Get module described in the following section complies with the Court's finding that an embodiment may rely in some part on predefined configuration information and Implicit's '163 patent Reexam disclaimer that the invention does not use pre-configured sequences of routines that existed before receiving a first message packet.
ii. (b) Selecting a sequence of routines that is dynamically identified and exists after a first message packet was received
The Label Map Get feature disclosed in the '683 and '211 patents may also dynamically identify a sequence of routines after the system receives a first message packet. If no pre-identified sequence of routines existing in the primed cache can be used to process the packet, then the Label Map Get module invokes the Search Edge Space module to search for individual software routines that can be dynamically identified and sequenced together to process the packet. See Dkt. 43-11 (the '211 patent) at col. 7:61-65, Figure 8 (step 8-05). The Search Edge Space module searches for suitable routines by comparing the available individual routines to the received packets' layered data formats. Id. at col. 7:61-65, col. 9:4-7. If the Search Edge Space module identifies the correct routines that can be sequenced together to process the message packet, the Label Map Get module returns the address corresponding to that dynamically identified sequence of routines. Id.
For example, the '683 patent discloses an embodiment that dynamically identifies a complete sequence of routines by using the Label Map Get module to (1) select the first three software routines that have been identified and exist before the system received a first message packet (i.e., relying in some part on predefined configuration information), and then, because the first three routines cannot process the packet completely, the embodiment again uses the Label Map Get feature to (2) dynamically identify the final two routines that are necessary to complete the sequence and perform final processing of the packet. See Dkt. 43-1 (the '683 patent) at col. 4:1-44. In sum, this embodiment dynamically identifies a sequence of five individual software routines by relying in some part on predefined configuration information (the first three routines), and where the complete sequence of routines exists after the system received a first message packet. See id.
Therefore, this embodiment is in accordance with the Court's earlier finding that the '683 patent may rely in some part on predefined configuration information and Implicit's disavowal made during the '163 Reexam. See Dkt. 43-7 ('163 Reexam 9/1/2009 Amendment and Response) at 18 ("[T]he sequence of routines (or 'path') is not configured prior to receiving the first packet of a message. . . . [T]he sequence of routines in the '163 invention is not identified until the incoming message is received."). During the March 18, 2015, tutorial and Markman hearing, the parties did not dispute that the Label Map Get module disclosed in the '683 and '211 patents can dynamically identify a sequence of routines after receiving a first message packet (i.e., does not use pre-identified sequences of routines), which, as Implicit explained during the '163 Reexam, departs drastically from the prior art Mosberger system. See id.
By dynamically identifying a sequence of routines after receiving a first message packet, the invention disclosed in the '683 patent can be reconfigured "on-the-fly" to process incoming message packets containing new data formats, thereby overcoming the drawbacks in the prior art Mosberger system. See Dkt. 43 (Implicit Opening Brief) at 11:1-17. Once the Label Map Get module has identified the appropriate sequence of routines to process the received message packet, the system creates a path (based on the sequence) that will process the packet's layers in accordance with the sequence of routines.
iii. Path Creation and Packet Processing
To process the received message packet, the invention disclosed in the '683 patent creates a path based on the identified sequence of routines. After the Label Map Get module returns an address corresponding to a sequence of routines, where the sequence is either (a) a pre-identified sequence that existed before receiving a first message packet or (b) a dynamically identified sequence that exists after receiving a first message packet, the Demux module selects the sequence indicated by the address and creates a path to process the packet. See Dkt. 43-1 (the '683 patent) at col. 4:13-25.
For example, as shown in Figure 1 of the '683 patent, the path is represented by a series of five path entries (151-155). See id. The system will then queue the packet so that it can be processed by the path comprising the sequence of routines. See id. at col. 2:53-56. After completely processing the first packet of a message, the system temporarily stores the sequence of routines as a "session" so that the same sequence can be quickly found when subsequent packets of the same message are received. See id. at col. 2:55-61.
Thus, the '683 and '211 patent specifications disclose an embodiment that can create a path based on (a) a pre-identified (i.e., pre-configured) sequence of routines that existed before a first message packet was received and (b) a sequence of routines that is dynamically identified and exists after a first message packet is received. However, the parties dispute whether Implicit's disclaimer made during the '163 patent Reexam disclaimer should be relevant to construing the '683 patent claims as set forth in this Order, thereby excluding the use of (a) a pre-identified sequence of routines that existed before a first message was received.
LEGAL STANDARD
Claim construction is a matter of law. Markman v. Westview Instr., Inc., 517 U.S. 370, 372 (1996). Terms contained in claims are "generally given their ordinary and customary meaning." Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005). "[T]he ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention." Id. at 1312. In determining the proper construction of a claim, a court begins with the intrinsic evidence of record, consisting of the claim language, the patent specification, and, if in evidence, the prosecution history. Id. at 1313; see also Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). "The appropriate starting point . . . is always with the language of the asserted claim itself." Comark Communications, Inc. v. Harris Corp., 156 F.3d 1182, 1186 (Fed. Cir. 1998); see also Abtox, Inc. v. Exitron Corp., 122 F.3d 1019, 1023 (Fed. Cir. 1997).
Accordingly, although claims speak to those skilled in the art, claim terms are construed in light of their ordinary and accustomed meaning, unless examination of the specification, prosecution history, and other claims indicates that the inventor intended otherwise. See Electro Medical Systems, S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1053 (Fed. Cir. 1994). The specification can provide guidance as to the meaning of the claims, thereby dictating the manner in which the claims are to be construed, even if the guidance is not provided in explicit definitional format. SciMed Life Systems, Inc. v. Advanced Cardiovascular Systems, Inc., 242 F.3d 1337, 1344 (Fed. Cir. 2001). Although claims are interpreted in light of the specification, this "does not mean that everything expressed in the specification must be read into all the claims." Raytheon Co. v. Roper Corp. , 724 F.2d 951, 957 (Fed. Cir. 1983). For instance, limitations from a preferred embodiment described in the specification generally should not be read into the claim language. See Comark, 156 F.3d at 1187. However, it is a fundamental rule that "claims must be construed so as to be consistent with the specification." Phillips, 415 F.3d at 1316. Therefore, if the specification reveals an intentional disclaimer or disavowal of claim scope, the claims must be read consistently with that limitation. Id.
A disavowal of claim scope requires that "the specification [or prosecution history] make [] clear that the invention does not include a particular feature," SciMed Life Sys., 242 F.3d at 1341, or is clearly limited to a particular form of the invention, Edwards Lifesciences LLC v. Cook Inc., 582 F.3d 1322, 1330 (Fed. Cir. 2009). See Hill-Rom Servs., Inc. v. Stryker Corp., 755 F.3d 1367, 1372 (Fed. Cir.) cert. denied, 135 S. Ct. 719 (2014). For example, the Federal Circuit has held that a disclaimer applies when the patentee makes statements such as "the present invention requires . . ." or "the present invention is . . ." or "all embodiments of the present invention are . . ." See id. (citing Regents of Univ. of Minn. v. AGA Med. Corp., 717 F.3d 929, 936 (Fed. Cir. 2013); Honeywell Int'l, Inc. v. ITT Indus., Inc., 452 F.3d 1312, 1316-19 (Fed. Cir. 2006); SciMed, 242 F.3d at 1343-44). "When a patent thus describes the features of the 'present invention' as a whole, this description limits the scope of the invention." Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007).
Finally, the Court may also consider the prosecution history of the patent, if in evidence. Markman, 52 F.3d at 980. The prosecution history can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would be otherwise. Phillips, 415 F.3d at 1317. In most situations, analysis of this intrinsic evidence alone will resolve claim construction disputes. See Vitronics, 90 F.3d at 1583. Courts should not rely on extrinsic evidence in claim construction to contradict the meaning of claims discernable from examination of the claims, the written description, and the prosecution history. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1308 (Fed. Cir. 1999) (citing Vitronics, 90 F.3d at 1583).
DISCUSSION
The parties dispute the construction of one term that appears in independent Claims 1, 10, 16, and 24 of the '683 patent: "sequence of routines" (Claims 1 and 24), "list of routines" (Claim 16), and "list of conversion routines" (Claim 10).
| Claim Term | Implicit's ProposedConstruction | F5's Proposed Construction |
|---|---|---|
| "sequence of routines"Claims 1, 4, 5, 6, 8, 9, 24,28, 30"list of routines"Claim 16 | No construction necessary;ordinary and customarymeaning applies.Alternative: "an orderedarrangement of softwareroutines" | "a sequence [list] of softwareroutines that was not configured(i.e., the individual routinescomprising the sequence were notidentified) before the first packet ofa message was received" |
| "list of conversion routines"Claim 10 | No construction necessary;ordinary and customarymeaning applies.Alternative: "an orderedarrangement of softwareroutines for changing data | "a list of software routines that wasnot configured (i.e., the individualroutines comprising the sequencewere not identified) before the firstpacket of a message was received" |
F5's proposed construction adds a significant negative limitation on the term by excluding a sequence/list of routines that was identified (i.e., configured) before a first message packet was received. F5's primary argument is that, during the prosecution of the parent '163 patent, Implicit made repeated statements that disclaimed the use of pre-identified sequences of routines. The parties' dispute boils down to whether Implicit's disavowal in the prosecution of the parent '163 patent should be relevant to construing the related '683 patent, thereby limiting the ordinary meaning of the term "sequence/list of routines."
The Court finds that Implicit's statements made during prosecution of the parent '163 patent are pertinent to construing terms in the continuation '683 patent because they were related to the same subject matter as the term now being construed, were directed to the invention as a whole as disclosed in the specification shared by the '163 and '683 patents, and were a clear and unmistakable disavowal of claim scope. Implicit advances a series of arguments for concluding that this term does not require construction, thus the ordinary meaning should apply; however, these arguments do not overcome the Court's conclusion that Implicit's disclaimer in the parent '163 patent prosecution applies to the related '683 patent.
The Court first looks to the claim language itself. Implicit argues that the plain language of the '683 patent claims use the terms in their ordinary way, and there is no claim language or context that suggests the meaning should be limited. Dkt. 43 (Implicit Opening Brief) at 12:17-14:28. Relevant for the purposes of this claim construction, Claim 1 is treated by the parties as representative:
Implicit states that the '683 patent's independent Claims 1 and 10 are illustrative. See Dkt. 43 at 12:24.
Claim 1. A first apparatus for receiving data from a second apparatus, the first apparatus comprising:
a) a processing unit; andDkt. 1-2 (the '683 patent) at col. 14:20-35 (emphasis added).
b) a memory storing instructions executable by the processing unit to:
i) create, based on an identification of information in a received packet of a message, a path that includes one or more data structures that indicate a sequence of routines for processing packets in the message;
ii) store the created path; and
iii) process subsequent packets in the message using the sequence of routines indicated in the stored path, wherein the sequence includes a routine that is used to execute a Transmission Control Protocol (TCP) to convert one or more packets having a TCP format into a different format.
Although the claim language sets forth that the invention receives a message packet, and then, based on information in the received packet, creates a path that indicates a sequence/list of routines, the claim language does not explicitly state whether the sequence/list of routines was identified before or after the system received the packet of the message.
In support of using the ordinary meaning, Implicit points to dependent Claims 8 and 9 that narrow the scope of Claim 1. Dkt. 43 at 15:1-16:3. Claim 8, which depends from Claim 1, requires the invention to "identify an address associated with the information, wherein the address indicates the routines in the sequence of routines of the created path." Dkt. 1-2 (the '683 patent) at col. 14:60-64. And Claim 9, which depends from Claim 8, further requires the invention "to use the address to select the sequence of routines from a plurality of sequences of routines that are stored . . . prior to receiving the packet of the message." Id. at col. 14:65-15:2.
Implicit contends that Claim 9 covers sequences of routines that are identified and stored in the system before receiving a packet of the message. Dkt. 43 at 15:14-23. F5 disagrees, arguing that Claim 9 does not disclose selecting from a plurality of sequences that were identified and existed before the system received a packet of the message; rather, it relates to the last step of Claim 1, where the system processes "subsequent packets in the message." Dkt. 44 at 19:6-20:11. In other words, F5 asserts that Claim 9 relates to selecting the sequence of routines from a plurality of sequences of routines that were stored after the received packet arrived so that the system can process the "subsequent packets" of that same message. Although the Court is not evaluating the validity of Claim 9 in this Order, the term "the packet of the message" in dependent Claim 9 appears to be indefinite as lacking proper antecedent basis, because Claim 1 recites both "a received packet" and "subsequent packets," making it unclear which "packet" Claim 9 references. Therefore, the Court finds that dependent Claims 8 and 9 do not provide clear support for the either party's proposed construction.
See M.P.E.P. § 2173.05(e) ("A claim is indefinite when it contains words or phrases whose meaning is unclear. The lack of clarity could arise where a claim refers to 'said lever' or 'the lever,' where the claim contains no earlier recitation or limitation of a lever and where it would be unclear as to what element the limitation was making reference. Similarly, if two different levers are recited earlier in the claim, the recitation of 'said lever' in the same or subsequent claim would be unclear where it is uncertain which of the two levers was intended.).
The Court next turns to the '683 patent specification and the related parent '163 patent prosecution history. While the claim language itself, standing alone, may not be conclusive in showing whether the claims require that the sequence/list of routines be identified after the first packet of a message was received, Implicit's statements in the specification buttressed by the prosecution history make it sufficiently clear. From the beginning of the specification common to the '163 and '683 patents, the inventors' basis for distinguishing their invention was its ability to dynamically identify a sequence of software routines for processing data. In the Background, the inventors stated, "These [prior art] computer systems typically use predefined configuration information to load the correct combination of [software] routines for processing data." Dkt. 1-2 (the '683 patent) at col. 1:48-50. The inventors specifically state that these prior art systems had drawbacks because they "can be expected to receive data and to provide data in many different formats that may not be known until the data is received. The overhead of statically[sic] providing each possible series of conversion routines is very high." Id. at col. 1:54-59. The specification then indicates that "[i]t would be desirable to have a technique for dynamically identifying a series of [software] routines for processing data." Id. at col. 2:4-11.
During the prosecution of the parent '163 patent and in response to the PTO's office action, Implicit devoted an entire section of its response to further explain these prior art disavowals in the first column of the specification shared by the '163 and '683 patents:
ii. The Specification Shows That The 'Sequence of Components for Processing the Packets of the Message' Is Not Pre-Configured as in Mosberger, But Rather Created Dynamically After the 'First Packet of the Message' is ReceivedDkt. 43-7 ('163 patent Reexam 9/1/2009 Amendment and Response) at 18.
The first column of the '163 Patent is critical. It teaches that prior art 'computer systems typically use predefined configuration information to load the correct combination of routines for processing data.' Col. 1, Ins. 41-43. This statement, which must be considered in construing the claims, describes the Mosberger system. The specification then distinguishes the prior art computer systems (like Mosberger) by stating that 'it would be desirable to have a technique for dynamically identifying a series of routines for processing data.' Col. 1, Ins. 64-66. In other words, the '163 Patent clearly states that the invention requires the sequence of routines (that form the paths) to be identified at run-time, and disavows prior art systems (like Mosberger) that use pre-configured paths, which are defined at 'build-time' before the first packet of a message is received.
Consistent with the above, the '163 specification further teaches that 'when a packet of a message is received, the conversion system in one embodiment searches for and identifies a sequence of routines (or more generally message handlers) for processing the packets of the message by comparing the input and output formats of the routines.' Col. 2, Ins. 40-45. Thus, the specification provides 'interpretive guidance' for the identifying components, namely, that the sequence of routines (or 'path') is not configured prior to receiving the first packet of a message.
Implicit's description of the invention as disclosed in the shared specification and the resulting disavowal is clear and unmistakable. See Cordis Corp. v. Medtronic AVE, Inc., 339 F.3d 1352, 1358 (Fed. Cir. 2003) ("Such a disclaimer requires clear and unmistakable statements of disavowal."). The Federal Circuit has held that "prosecution disclaimer may arise from disavowals made during the prosecution of ancestor patent applications," such as the parent '163 patent. Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1333 (Fed. Cir. 2003). The Court recognizes that "[i]n general, a prosecution history disclaimer will only apply to a subsequent patent if that patent contains the same claim language as its predecessor." Regents of Univ. of Minnesota, 717 F.3d at 943 (citing Ventana Med. Sys. v. Biogenex Labs., Inc., 473 F.3d 1173, 1182 (Fed. Cir. 2006)).
However, the case before the Court presents "[t]he sole exception [] when the disclaimer is directed to the scope of the invention as a whole, not a particular claim." Id.; see also Ormco Corp. v. Align Tech., Inc., 498 F.3d 1307, 1314-15 (Fed. Cir. 2007) (finding a disclaimer applied to a related patent when the patent owner's statements "w[ere] not associated with particular language from [the] claims" but were instead directed to the "present invention" and the "overall method" claimed.). In addition, "[w]hen the application of prosecution disclaimer involves statements from prosecution of a familial patent relating to the same subject matter as the claim language at issue in the patent being construed, those statements in the familial application are relevant in construing the claims at issue." Ormco, 498 F.3d at 1314 (Fed. Cir. 2007) (emphasis added) (citing Wang Lab., Inc. v. Am. Online, Inc., 197 F.3d 1377, 1384 (Fed. Cir. 1999); Jonsson v. Stanley Works, 903 F.2d 812, 818 (Fed. Cir. 1990)). The Court finds that Implicit's statements during the '163 patent Reexam readily meet the exception to the general rule. Here, the '163 and '683 patents' specifications have the same content. None of the above quoted statements from the '163 patent Reexam were directed to a specific claim; rather, the description was directed to the scope of the invention as a whole as it is disclosed in the shared specification. Moreover, Implicit's statements were related to the same subject matter as the claim term now being construed in the related continuation '683 patent.
At the time that Implicit filed its September 1, 2009, Reexam Response, Claim 1 of the '163 patent recited the limitation "for the first packet of the message, identifying a sequence of [routines] for processing packets of the message." Dkt. 43-7 ('163 patent Reexam 9/1/2009 Amendment and Response) at 3. Most important, there was no language in Claim 1 that specified when the sequence of routines was identified in relation to receiving the first packet of the message.
Implicit made it definitively clear to the PTO and the public that the sequence of routines (or 'path') as disclosed in the '163 patent specification is not configured before receiving the first packet of a message. Omega Engg, Inc., v. Raytek Corp., 334 F.3d 1314, 1324 (Fed. Cir. 2003) ("As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic evidence and protects the public's reliance on definitive statements made during prosecution."). Therefore, the Court finds that the prosecution disclaimer from the '163 patent Reexam attaches to the construction of the '683 patent claims and narrows the scope of the disputed term.
Implicit attempts to avoid the doctrine of prosecution disclaimer by advancing several arguments for concluding otherwise, but the Court is unconvinced. First, Implicit argues that a preferred embodiment disclosed in the '211 patent specification, which is incorporated by reference in the '683 patent, supports the ordinary meaning of the term. As discussed above in the Background, the parties do not dispute that the '211 patent discloses an embodiment that may use sequences of routines that are identified and exist before a first message packet arrives, similar to the prior art Mosberger system. Nonetheless, the Court finds that Implicit disclaimed this embodiment from the shared patent specification during the '163 patent Reexam. See N. Am. Container, Inc. v. Plastipak Packaging, Inc., 415 F.3d 1335, 1346 (Fed. Cir. 2005) ("[W]e have previously explained that limitations may be construed to exclude a preferred embodiment if the prosecution history compels such a result."). Furthermore, Implicit's disclaimer is not inconsistent with other embodiments disclosed in the shared specification. Biogen Idec, Inc. v. GlaxoSmithKline LLC, 713 F.3d 1090, 1097 (Fed. Cir. 2013) ("[T]he applicants' disclaimer in this case is not necessarily inconsistent with other possible embodiments or even the dependent claims . . . ."); see also Phillips, 415 F.3d at 1316 ("Claims must be construed so as to be consistent with the specification."). As discussed above, an embodiment of the Label Map Get feature disclosed in the '683 patent specification complies with Implicit's disclaimer and with the Court's finding in the earlier Case No. 10-03365 that the invention may rely in some part on "predefined configuration information." Dkt. 1-3 (10-03365 Order Granting Summary Judgment) at 24:4-5. This embodiment dynamically identifies a sequence of routines by using the Label Map Get module to select the first three software routines that were identified and existed before the system received a first message packet, then the Label Map Get module dynamically identifies the final two routines that are necessary to complete the sequence of routines and fully process the packet. See Dkt. 43-1 (the '683 patent) at col. 4:1-44. This embodiment complies with Implicit's disclaimer because it does not identify the complete sequence of five routines needed to process the packet until after a first packet of the message is received.
Second, Implicit contends that the '683 patent's prosecution history supports the ordinary meaning of the term. The Court disagrees. Implicit argues that during the prosecution of the '683 patent, Implicit did not disclaim any scope of the claim term now being construed. However, this is immaterial. For a disclaimer in a parent patent to be rescinded, permitting recapture of the disclaimed scope in a later related continuation patent, "the prosecution history must be sufficiently clear to inform the examiner that the previous disclaimer, and the prior art that it was made to avoid, may need to be re-visited." Hakim v. Cannon Avent Grp., PLC, 479 F.3d 1313, 1318 (Fed. Cir. 2007). There is no evidence in the '683 patent prosecution history, much less sufficiently clear evidence, that informed the examiner that the disclaimer Implicit made during the '163 patent Reexam would need to be revisited.
Finally, Implicit argues that there was no disavowal made during the '163 patent Reexam because the PTO rejected the disavowal. See Dkt. 44 at 20:22-21:2 ("In effect, the PTO was saying that Implicit would have to narrow its claim language because there is no disavowal."). Again, the Court disagrees. Any statement made by Implicit during prosecution is given weight, serves the patent prosecution history's public notice function, and may be considered to constitute a disclaimer, just as this Court found in the previous case. See Elkay Mfg. Co. v. Ebco Mfg. Co., 192 F.3d 973, 979 (Fed. Cir. 1999) ("Arguments made during the prosecution of a patent application are given the same weight as claim amendments."). Therefore, Implicit's statements constitute a disavowal regardless of whether or not the Examiner accepted the arguments.
In the previous Case No. 10-cv-3365 between the parties, the Court found that Implicit's September 1, 2009, response "makes clear that what it was disclaiming in the prior art was use of preconfigured sequences of routines, in other words preconfigured paths." Dkt. 1-3 (Order Granting Summary Judgment) at 24:4-5; see also Dkt. 44-17 (Claim Construction Order) at 6:2-10.
F5's proposed construction, however, is no more helpful as it attempts to limit the term more narrowly than warranted by Implicit's prosecution history disavowal. Several of the proposed words do not find support in the specification or the prosecution history.
F5's proposes "a sequence [list] of software routines that was not configured (i.e., the individual routines comprising the sequence were not identified) before the first packet of a message was received," while Implicit's '163 Reexam disclaimer stated "the sequence of [] routines (or 'path') is not configured prior to receiving the first packet of a message." Dkt. 43-7 ('163 patent Reexam 9/1/2009 Amendment and Response) at 18.
--------
Sequence/List of routines, therefore, is construed as "a sequence [list] of software routines that was not identified (i.e., configured) prior to receiving a first packet of the message."
CONCLUSION
For the foregoing reasons and for good cause shown, the Court adopts the construction set our above.
IT IS SO ORDERED. Dated: May 6, 2015
/s/_________
SUSAN ILLSTON
United States District Judge