Opinion
No. C10-3365 SI No. C 10-3746 SI No. C 10-4234 SI
02-29-2012
IMPLICIT NETWORKS, INC., Plaintiff, v. F5 NETWORKS, INC., Defendant. IMPLICIT NETWORKS, INC., Plaintiff, v. HEWLETT-PACKARD COMPANY, Defendant IMPLICIT NETWORKS, INC., Plaintiff, v. JUNIPER NETWORKS, INC., Defendant.
CLAIM CONSTRUCTION ORDER
On January 18 and 19, 2012, the Court held a Markman hearing regarding the construction of nine disputed claims in two patents owned by plaintiff. Having considered the arguments of counsel and the papers submitted, the Court construes the disputed claims as follows.
BACKGROUND
1. Procedural Background
Plaintiff filed Case No. 10-3365 against F5 Networks on July 30, 2010; Case No. 10-3746 against Hewlett-Packard Company on August 23, 2010; and Case No. 10-4234 against Juniper Networks, Inc., on September 20, 2010. In these related cases, plaintiff accuses defendants' products of infringing two patents owned by plaintiff: U.S. Patent No. 6,629,163, as issued September 30, 2003 ("'163 Patent") and as it emerged after reexamination on June 22, 2010 ("'163 Reexam"); and U.S. Patent No. 7,711,857 ("'857 Patent"), issued May 4, 2010 as a continuation application from '163.
Other cases were also related, but those cases have been voluntarily dismissed. See, e.g., Case Nos. 09-5628, 10-720, 10-3606.
Although they are not being construed, the terms of U.S. Patent No. 7,730,211 (the "211 patent") are also involved, since the application for the '211 patent (U.S. Patent Application No. 11/933,093) was incorporated into the '857 patent and referred to in the '163 reexamination.
2. Factual Background
According to the complaints in these cases, the heart of the patents' invention is a networking process where "discrete computer function[s], e.g., processing http server requests over tcp/ip, streaming a video web-based client, or managing voice-over-ip calls, would be built into a discrete software module, called a 'bead.'" The system devised could "dynamically" "receive a stream of data - say video - determine what services were necessary to render that content and where the content was to be rendered, and then assemble - or string together - the requisite service beads (modules) at run-time." See, e.g., FAC [Docket No. 31, Case No. 10-3365], ¶ 16. This system, according to plaintiff, dramatically departed from the prior art where a developer of applications had to anticipate who would use the applications and for which devices and content, and then build-in the ability to handle the anticipated demands. Id., ¶ 11. The prior art model had many shortfalls, including an "ever-increasing complexity, cost, and processing overhead . . . Given that all anticipated uses had to be preconfigured at build-time, any unanticipated new use, e.g., a different format or a different device, would simply break the system. The developer had to have the foresight to specify explicitly all possible configurations in advance, a difficult task in a rapidly changing world." Id., ¶ 12.
As noted above, the '163 Patent entered reexamination in 2008 and emerged in June 2010 with additional limitations. All parties agree that the purpose and result of the reexamination was to distinguish the '163 series ofpatents from the prior art found in David Mosberger, "Scout: A Path-Based Operating System," Doctoral Dissertation Submitted to the University of Arizona. See, e.g., Hosie Decl., [Docket No. 72], Ex. G at 11. 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. . . ." '163 Reexam, Ex. D to Parties' Amended Joint Claim Construction and Prehearing Statement (emphasis in original showing terms added in reexam).
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 ofthe 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 written description 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. SciMedLife Systems, Inc. v. Advanced Cardiovascular Systems, Inc., 242 F.3d 1337, 1344 (Fed. Cir. 2001). In other words, the specification may define claim terms "by implication" such that the meaning may be "found in or ascertained by a reading of the patent documents." Vitronics, 90 F.3d at 1584 n.6.
In addition, the claims must be read in view of the specification. Markman, 52 F.3d at 978. 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.
Finally, the Court may consider the prosecution history of the patent, if in evidence. Markman, 52 F.3d at 980. The prosecution history limits the interpretation of claim terms so as to exclude any interpretation that was disclaimed during prosecution. See Southwall Technologies, Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995). 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). However, it is entirely appropriate "for a court to consult trustworthy extrinsic evidence to ensure that the claim construction it is tending to from the patent file is not inconsistent with clearly expressed, plainly apposite, and widely held understandings in the pertinent technical field." Id. Extrinsic evidence "consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises." Phillips, 415 F.3d at 1317. All extrinsic evidence should be evaluated in light of the intrinsic evidence. Id. at 1319.
DISCUSSION
The parties' claim construction dispute centers on nine terms. The Court will address each in turn.
During the Markman hearing the parties agreed that one of the disputed terms Identifying...a Sequence of Components...Such That the Output Format... Match[es] the Input Format of the Next Component should be given its plain meaning. See Transcript pg. 73 [Docket No. 87 at 5]. While defense counsel clarified that the agreement to use "plain meaning" extended only to the "such that" part of the clause, id. at 73-74, defendants' claim construction demonstrative slides used during the second day of the Markman hearing confirm that defendants' "current proposed construction" for the whole phrase was its "plain meaning." Therefore, the Court finds that the term is not currently in dispute and will not construe it.
1. Non-predefined sequence of components
+--------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +---------------+----------------------------------+-----------------------------------¦ ¦ ¦ ¦A sequence of conversion ¦ ¦ ¦Sequence of components ¦ ¦ ¦"non-predefined¦ ¦routines that was not identified ¦ ¦sequence of ¦changeable runtime. ¦ ¦ ¦components" ¦ ¦in or determinable from ¦ ¦ ¦Component: plain meaning. In ¦ ¦ ¦'163 patent, ¦ ¦configuration information in ¦ ¦Claims 1, 15, ¦the alternative, one or more ¦ ¦ ¦35 ¦ ¦place before the first packet of ¦ ¦ ¦software routines. ¦ ¦ ¦ ¦ ¦a message was received. ¦ +--------------------------------------------------------------------------------------+
As an initial matter, the Court finds that components should be given the definition specifically provided for it in the specification: "software routines." See '163 Reexam (Reexamination Certificate) at Col. 1:27-29 & Col. 2:32 ("each component being a software routine").
The '163 and '857 patent specifications are largely identical. Therefore, the Court refers to the '163 Patent specification, unless otherwise specifically noted.
The more difficult question is the definition for non-predefined, a phrase that was added to the claims in the '163 reexamination. All parties agree that the phrase was introduced in order to distinguish '163 from the Mosberger prior art. See, e.g., Plaintiff's Opening Claim Construction Brief [Case No. 10-3365 Docket No. 60] at 11; Defendants' Claim Construction Brief [Case 10-3365 Docket No. 63] at 8. Defendants attempt to impose a significant limitation on the term by arguing that the sequence of routines cannot be identified or "determinable from configuration information" in place before the first packet of a message is received. For support, defendants rely primarily on a September 1, 2009 Amendment and Response submitted by Implicit during the '163 Reexam. See 9/1/09 Amendment and Response, Hogan Decl.[Docket No. 65], Ex. L. In that Response, Implicit cited to the '163 specification distinguishing prior art systems which "typically use predefined configuration information" to load the correct series of conversion routines that make up the "path." Id., at 18. However, 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. Id., ("the sequence of conversion routines (or 'path') is not configured prior to receiving the first packet of a message."); see also 2/8/10 Amendment and Response, Hosie Decl., Ex. D at 16. Implicit did not disclaim the ability to create a sequence of conversion routines by relying in some part on predefined "configuration information," but only the use of pre-configured paths.
To accept defendants' argument would also call into question a preferred embodiment of the '163 Patent. That embodiment uses the "label map get" feature, which plaintiff contends is a database that exists at the time of first packet inspection to "identify a sequence of conversion routines for processing the packet." '163 Specification at Col. 4:12-15.
Plaintiff's definition, however, is no more helpful as it attempts to introduce "changeable at runtime," words which themselves would need to be construed. The Court is mindful that "[t]he terms, as construed by the court, must 'ensure that the jury fully understands the court's claim construction rulings and what the patentee covered by the claims.'" Power-One, Inc. v. Artesyn Techs., Inc., 599 F.3d 1343, 1348 (Fed. Cir. 2010) (quoting Sulzer Textil A.G. v. Picanol N.V., 358 F.3d 1356, 1366 (Fed. Cir. 2004)). Plaintiff's proposed definition does nothing to advance this goal. The proposed words do not find support in the specification and do not appear to be necessary because the claim itself identifies the time frame during which the sequence must be non-predefined - i.e., before "the first packet was received."
Non-predefined sequence of components, therefore, is construed as "a sequence of software routines that was not identified before the first packet of a message was received."
2. Dynamically Identify[ing] a [Message Specific] Sequence of Components
+-----------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +------------+----------------------------------+-----------------------------------¦ ¦"dynamically¦ ¦After receiving the first packet of¦ ¦identify ¦ ¦a ¦ ¦[ing] a ¦ ¦ ¦ ¦[message ¦Selecting at runtime a ¦message, identifying and selecting ¦ ¦specific] ¦ ¦ ¦ ¦sequence of ¦sequence of ¦individual components to create a ¦ ¦components" ¦ ¦ ¦ ¦ ¦components/selecting at ¦sequence of conversion routines ¦ ¦'857 patent,¦ ¦ ¦ ¦Claims 1, 4,¦runtime a sequence of ¦that was not identified in or ¦ ¦10 ¦ ¦ ¦ ¦ ¦components for the message ¦determinable from predefined ¦ ¦'163 patent,¦ ¦ ¦ ¦Claims 1, ¦ ¦configuration information ¦ ¦15, 35 ¦ ¦ ¦ +-----------------------------------------------------------------------------------+
The term dynamically identify[ing] was also added to the '163 Patent in the reexamination. The parties' proposed constructions are, essentially, restatements of their proposals for non-predefined discussed above. The Court also notes that dynamically identifying] is expressly defined in the claims themselves. For example, Claim 1 provides that "wherein dynamically identifying includes selecting individual components to create the non-predefined sequence of components after the first packet is received." '163 Reexam, Col. 1:36-39. Having already construed non-predefined as "a sequence of software routines that was not identified before the first packet of a message was received," and finding dynamically identify[ing] already defined in the claims, the Court rejects both parties' proposed constructions and adopts the plain meaning for dynamically identify[ing] a [message specific] sequence of components.
3. "Processing" [and Variants]
+--------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +---------------+----------------------------------+-----------------------------------¦ ¦"...processing"¦ ¦ ¦ ¦and "all ¦ ¦ ¦ ¦variants" ¦ ¦ ¦ ¦ ¦Manipulating data with a ¦Performing input to output format ¦ ¦'163 patent ¦ ¦ ¦ ¦Claims 1, 15, ¦program. ¦conversion. ¦ ¦35 ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦'857 patent ¦ ¦ ¦ ¦Claims 1, 4, 10¦ ¦ ¦ +--------------------------------------------------------------------------------------+
Variants include: "Processing [the] [packets of] [a/each] message," "Processing [the/a plurality of] packets of [a/the/each] message[s]," "Process[ing][es] the next packet of the message," etc.
During the Markman hearing, defendants proposed this revised definition of processing and variants.
In proposing their preferred construction for processing, as well as input/output format
discussed below, defendants are attempting to require that the patent cover only embodiments where the data in each of the packets of a message is "converted" in some manner. The Court recognizes that the patent claims and specification repeatedly use the term "conversion." However, Claim 15 omits any reference to "conversion" and speaks only of "processing" packets of a message. Moreover, the '163 Specification itself explains, "a conversion routine may be used for routing a message, and may perform no conversion of the message." '163 Patent Col. 14:17-19. Therefore, defendants' argument that the claim language limits the invention to "conversion" of data within each packet is not well taken. With respect to the narrower issue of how to construe processing, the Court finds that plaintiff's proposal should be adopted and construes processing [and variants] as "manipulating data with a program."
See, e.g., Defendants' Claim Construction Slides, "The Claim Language Limits the Invention to Conversion."
4. Input/Output Format
+------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +------------+----------------------------------+------------------------------------¦ ¦ ¦Input format: ¦Input format: ¦ ¦ ¦ ¦ ¦ ¦"Input/ ¦Structure or appearance of data ¦Format for data that is input into a¦ ¦Output ¦ ¦ ¦ ¦Format." ¦to be processed. ¦conversion routine. ¦ ¦ ¦ ¦ ¦ ¦'163 patent ¦Output format: ¦Output format: ¦ ¦Claim 1 '857¦ ¦ ¦ ¦patent ¦Structure or appearance of the ¦Format of data that it output from a¦ ¦Claims 1, 4,¦ ¦ ¦ ¦10 ¦data that results from ¦conversion routine and is different ¦ ¦ ¦ ¦from ¦ ¦ ¦processing. ¦ ¦ ¦ ¦ ¦the input format. ¦ +------------------------------------------------------------------------------------+
During the Markman hearing, defendants proposed this revised definition of input/output format.
Consistent with their arguments regarding processing, defendants attempt to limit input/output format to performing "conversion" of data so that the "format" of the output data of a packet is "different" from the input. Plaintiff attempts to maintain a broader functionality by relying on "manipulating" data and argues that defendants' attempted limitation is without support. As above, the Court agrees with plaintiff that "conversion" is not a necessary limitation with respect to the processing of each packet and finds that plaintiff's proposed construction is consistent with the claim language and the specification. See, e.g., '163 Patent at Col. 6:31-33 ("[t]he terms 'media,' 'label,' and 'format' are used interchangeably to refer to the output of a protocol."). Therefore, input/output format are construed as the "structure or appearance of data to be processed" and the "structure or appearance of the data that results from processing."
5. Selecting Individual Components
+-----------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +------------+----------------------------------+-----------------------------------¦ ¦"Selecting ¦ ¦Sequentially selecting the ¦ ¦individual ¦ ¦individual ¦ ¦components" ¦ ¦ ¦ ¦ ¦Selecting components that are ¦conversion routines of the sequence¦ ¦'163 patent ¦ ¦by ¦ ¦Claims 1, ¦not bound together by a ¦ ¦ ¦15, 35 ¦ ¦comparing the input and output ¦ ¦ ¦compiler. ¦formats ¦ ¦'857 patent ¦ ¦ ¦ ¦claims 1, 4,¦ ¦of the conversion routines. ¦ ¦10 ¦ ¦ ¦ +-----------------------------------------------------------------------------------+
The Court finds that neither party's proposed construction is particularly useful. Plaintiffs proposed construction includes words - "bound" and "compiler" - that themselves would need construing. However, defendants' proposal incorporates limitations that are not supported by the claim language or specification. For example, defendants point to no language in either the claims or the specification to support their intended limitation that the selection of individual components must be "sequential." Defendants contend that the prosecution history supports their "sequential" limitation by relying on plaintiff's October 23, 2009 interview summary with the PTO. 10/23/09 Summary, Hogan Decl., Ex. M at 2. There, plaintiff admitted that the "selecting individual components" limitations required "identifying the sequential order of the components based on the received packet." Id. However, identifying a sequential order is not the same as "sequentially selecting" individual components proposed by defendants.
Defendants also attempt to limit the means of selecting individual components to requiring a comparison of input and output formats of the software routines. Plaintiff argues that this "edge comparison" is only one method of selecting components covered by the claims. Plaintiff's Claim Construction Brief at 18-19. Plaintiff does not provide additional examples of methods for selecting individual components, other than referring to Label Map Get routine. Id. However, the Label Map Get routine itself ensures that the output format of each software routine "is compatible with the input format" of the next. See '163 Patent Col. 4:51-53. The Court also finds persuasive the repeated representations plaintiff made in the reexamination process regarding how the patent uses the format information of the packets to "identify individual components." In particular, "[t]he system of the '163 Patent uses this format information to dynamically identify components necessary for processing the entire message, such that the format of the output data of one module is compatible with the format of the input data of the next module." 9/1/09 Amendment and Response, Hogan Decl, Ex L at 22; see also id. ("Mosberger does not teach to define the input and output formats of the data that is processed by the modules, or to use these formats to make a run-time decision about how to assemble the modules."). The Court finds that, based on the claim language, teachings of the specification and the prosecution history, a necessary part of selecting individual components is determining the compatibility between the output of one software routine and the input of the next Therefore, selecting individual components is construed as "selecting the individual software routines of the sequence so that the input and output formats of the software routines are compatible."
6. "Create/Form [the...Sequence of Components]."
+---------------------------------------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +----------------------------------------------+----------------------------------+-----------------------------------¦ ¦"Create/form [the...sequence of components]" ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦'163 patent Claims 1, 15, 35 ¦Instantiate in memory. ¦Plain meaning. ¦ ¦ ¦ ¦ ¦ ¦'857 patent Claims 1, 4, 10 ¦ ¦ ¦ +---------------------------------------------------------------------------------------------------------------------+
Plaintiff's proposal for this term attempts to incorporate words which themselves would need to be construed, e.g., instantiate and memory. Plaintiff offers little support or reasoning for incorporating these additional words into the definition. Read in context, the Court does not find that the phrases "create the sequence of components" and "form the sequence of components" need any clarification. Therefore, create/form [the . . . sequence of components] is given its plain meaning.
7. Based on the First Packet of the Message
+------------------------------------------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +--------------------------------------------+----------------------------------+----------------------------------------¦ ¦ ¦Plain meaning, no ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦construction needed. In the ¦ ¦ ¦"based on the first packet of the message" ¦ ¦Based on the format of the data of the ¦ ¦ ¦alternative, relying on ¦ ¦ ¦'163 patent Claim 15 ¦ ¦first packet. ¦ ¦ ¦information in the first ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦packet of the message. ¦ ¦ +------------------------------------------------------------------------------------------------------------------------+
Plaintiff argues that defendants are attempting to introduce "format" to restrict the invention to relying on the underlying format of the data being processed - in order to identify the sequence of components - and exclude the ability to rely on header information. Defendants respond that the term "format" is used throughout the specifications and prosecution history as a key means by which the various components are placed into a sequence to process the packets of a message. While the input and output formats of the packets are a key aspect of selecting individual components to form the processing sequence, there is little to support limiting the demultiplexing method discussed in Claim 15 to using only information disclosed in or by the "format" of the data in first packet of a message. Therefore, the Court construes based on the first packet of the message as "relying on information in the first packet of the message."
8. Message[s]
+--------------------------------------------------------------------------------------------------------+ ¦Claim Term ¦Implicit's Proposed Construction ¦Defendants' Proposed Construction ¦ +------------------------------+----------------------------------+--------------------------------------¦ ¦ ¦ ¦A collection of data in a particular ¦ ¦"Message[s]" ¦A collection or stream of ¦ ¦ ¦ ¦ ¦format and that is related in some ¦ ¦'163 patent Claims 1, 15, 35 ¦data that is related in some ¦ ¦ ¦ ¦ ¦way, such as a stream of video or ¦ ¦'857 patent Claims 1, 4, 10 ¦way. ¦ ¦ ¦ ¦ ¦audio data or an email message. ¦ +--------------------------------------------------------------------------------------------------------+
In the specification, plaintiff defined message as: "a collection of data that is related in some way, such as a stream of video or audio data or an email message." '163 Patent Col. 2:45-47. The question here is whether, in light of the examples given in that definition (e.g., stream of video or email message), the definition of message should be restricted to data in a particular format, as defendants contend. The Court finds it should not reach that question on claim constriction. Message, itself, has been clearly defined in the specification. Whether any particular form of data transmission falls within the express definition of message is a question for the trier of fact. Therefore, message[s] is construed as "a collection of data that is related in some way, such as a stream of video or audio data or an email message."
9. State Information
+-----------------------------------------------------------------------------------------+ ¦ ¦Implicit's Proposed ¦ ¦ ¦Claim Term ¦ ¦Defendants' Proposed Construction ¦ ¦ ¦Construction ¦ ¦ +--------------------+---------------------------+----------------------------------------¦ ¦"State ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦information" ¦ ¦ ¦ ¦ ¦Information specific to a ¦Information specific to a conversion ¦ ¦'163 patent claims ¦ ¦ ¦ ¦ ¦component for a specific ¦routine for a specific message that is ¦ ¦1, 15, 35 ¦ ¦ ¦ ¦ ¦message. ¦not related to an overall path. ¦ ¦'857 patent Claims ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦1, 4, 10 ¦ ¦ ¦ +-----------------------------------------------------------------------------------------+
During the Markman hearing, defendants offered a new proposed construction.
--------
The parties agree that state information is information specific to a software routine (component) for a specific message. What the parties do not agree on is defendants' attempt to add, as a further limitation, "not related to an overall path." To support their additional limitation, defendants rely on Implicit's 9/1/09 Amendment and Response where Implicit - in distinguishing Mosberger - argued that "claim 1 is directed to a method in which state information for a specific component is stored on a component-by-component basis and is not information related to an overall path, as the Office Action describes Mosberger." 9/1/09 Amendment and Response, Hogan Decl., Ex, L at 24. Plaintiff, in Reply, asserts that the Amendment and Response was simply pointing out that the "novel element" the claim is directed to is the component-by-component rather than overall path storing, and that Implicit was not adding a limitation that the state information could not also relate to the overall sequence or path. Reply at 14. The Court, however, finds Implicit's statement in the reexamination was clear. State information is "not information related to an overall path." This is consistent with the way state information is actually used in the claims and consistent with other language in the claims. See, e.g., '163 Patent Col. 1:48-50 ("retrieving state information relating to performing the processing of the component with the previous packet of the message"); 1:54-56 ("storing state information relating to the processing of the component with packet for use when processing the next packed of the message"); but see Col. 1:39-42 ("storing an indication of each of the identified components so that the non-predefined sequence does not need to be re-identified for subsequent packets of the message"). State information, therefore, is construed as "information specific to a software routine for a specific message that is not information related to an overall path."
CONCLUSION
For the foregoing reasons and for good cause shown, the Court adopts the constructions set out above.
IT IS SO ORDERED.
________________________
SUSAN ILLSTON
United States District Judge