Implicit L.L.C. v. F5 Networks, Inc.

Filing 57

CLAIM CONSTRUCTION ORDER (Illston, Susan) (Filed on 5/6/2015)

1
2
3
4

UNITED STATES DISTRICT COURT

5

NORTHERN DISTRICT OF CALIFORNIA

6
IMPLICIT L.L.C.,

7

Case No. 14-cv-02856-SI

Plaintiff,
8
v.

CLAIM CONSTRUCTION ORDER

9
F5 NETWORKS, INC.,

10

Defendant.

United States District Court
Northern District of California

11
12
13

On March 18, 2015, the Court held a joint tutorial and Markman hearing regarding the

14

construction of one disputed term in one patent owned by plaintiff Implicit L.L.C. (“Implicit”).

15

Having considered the parties’ oral arguments and papers submitted, the Court construes the

16

disputed term as follows.

17
BACKGROUND

18
19

I.

Procedural History
Implicit filed this case against F5 Networks, Inc. (“F5”) on June 20, 2014.

20

Dkt. 1

21

(Complaint). In this patent infringement suit, Implicit accuses F5’s products of infringing U.S.

22

Patent No. 8,694,683 (“the ’683 patent”). See Dkt. 1-2 (the ’683 patent). The ’683 patent is a

23

continuation application or “child” of U.S. Patent No. 6,629,163 (“the ’163 patent”). See Dkt. 44-

24

3 (the ’163 patent). As a continuation application, the ’683 patent shares a common specification

25

with the “parent” ’163 patent.1 Because statements made by the patent owner during prosecution

26
27
28

1

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 . . . .”).

1

of the ’163 patent can be pertinent to claim construction of a related patent,2 such as the later-

2

issued continuation ’683 patent asserted in this case, it is relevant that the United States Patent and

3

Trademark Office (“PTO”) granted a request for the ’163 patent to undergo ex parte

4

reexamination (“Reexam”) on January 17, 2009.3 The ’163 patent emerged from Reexam on June

5

22, 2010, with additional claim limitations that were held to be patentable over prior art.4 See Dkt.

6

44-3 (the ’163 patent) at 29-31.
The present case is not the first time that Implicit has asserted the ’163 patent family

8

against F5. Approximately one month after the ’163 patent issued from Reexam, Implicit filed

9

Case No. 10-cv-33655 against F5 on July 30, 2010; Case No. 10-cv-37466 against Hewlett-

10

Packard Company (“HP”), on August 23, 2010; and Case No. 10-cv-42347 against Juniper

11
United States District Court
Northern District of California

7

Networks, Inc. (“Juniper”), on September 20, 2010. Implicit accused each of the defendants of

12

infringing two patents: the ’163 patent and U.S. Patent No. 7,771,857 (“the ’857 patent”) that

13

issued May 4, 2010, as a continuation “child” application from the ’163 patent. See Dkt. 44-4 (the

14

’857 patent). The cases were determined to be related and assigned to this Court.

15

In the previous Case No. 10-cv-3365 between Implicit and F5, all parties agreed that the

16

purpose and result of the ’163 patent Reexam was to differentiate the ’163 patent claims from the

17
2

18
19

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 . . . .”).
3

20
21

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).
4

22
23
24

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' . . . .”).
5

25

See Implicit Networks, Inc. v. F5 Networks, Inc., Case No. 3:10-cv-03365-SI (N.D. Cal. 2010).

6

26

See Implicit Networks, Inc. v. Hewlett-Packard Company, Case No. 3:10-cv-03746-SI (N.D. Cal.
2010).

27

7

28

See Implicit Networks, Inc. v. Juniper Networks, Inc., Case No. 3:10-cv-04234-SI (N.D. Cal.
2010).
2

prior art, specifically David Mosberger, “Scout: A Path-Based Operating System,” Doctoral

2

Dissertation Submitted to the University of Arizona (“Mosberger”). See Implicit Networks, Inc. v.

3

F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *1 (N.D. Cal. Feb. 29, 2012); see

4

also Dkt. 43-6 (Mosberger). The Court found that certain statements made by Implicit during the

5

’163 patent Reexam constituted a disclaimer that effectively narrowed the scope of the invention

6

disclosed in the ’163 patent specification. See Implicit Networks, Inc. v. F5 Networks, Inc., No. C

7

10-cv-3746 SI, 2012 WL 669861, at *3 (N.D. Cal. Feb. 29, 2012) (“Implicit's Amendment and

8

Response makes clear that what it was disclaiming in the prior art was use of preconfigured

9

sequences of routines, in other words preconfigured paths.”). On March 30, 2013, this Court

10

granted summary judgment in favor of F5 and Juniper,8 concluding that Implicit’s ’163 and ’857

11
United States District Court
Northern District of California

1

patents were invalid over prior art that was not considered by the PTO. See Dkt. 1-3 at 15; see

12

also Implicit Networks Inc. v. F5 Networks Inc., No. C 10-cv-4234 SI, 2013 WL 1007250 (N.D.

13

Cal. Mar. 13, 2013), appeal dismissed (June 17, 2013), appeal dismissed (June 20, 2013). In

14

addition, based in part on Implicit’s ’163 patent Reexam disclaimer, the Court found that F5’s

15

products did not infringe the ’163 and ’857 patents. See id.; see also Dkt. 1-3 at 26-29.

16

Less than three months after this Court invalidated the ’163 and ’857 patents, Implicit filed

17

another continuation application from the ’163 patent9 on June 6, 2013, that later issued as the

18

’683 patent now being asserted against F5 in this case. See Dkt. 1-2 (the ’683 patent).

19
20
21
22
23
24
25
26
27
28

8

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

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.”).
3

1

II.

Factual Background

2

A. General Technical Background

3

The ’683 patent relates generally to a computer system for processing messages, where

4

“[a] message is a collection of data that is related in some way, such as [a] stream of video or

5

audio data or an email message.” Dkt. 43 (Implicit Opening Brief) at 4:13-20 (quoting the ’683

6

patent at col. 2:49-51). When a message (i.e., a collection of related data) is sent across the

7

internet between computer systems, it is broken down by the transmitting system into smaller

8

pieces called “packets” for transport; the packets are sent across the network; and then the packets

9

must be reassembled by the receiving system. Id. Each individual packet comprises layers of

10

data, where each layer contains data in a different format. Id.

United States District Court
Northern District of California

11

For example, as shown in the figure below, a single message may contain five packets,

12

where each packet includes three layers of data in three different formats: (1) a Transmission

13

Control Protocol (“TCP”) layer with data in a TCP format, where the TCP layer is nested within

14

(2) an Internet Protocol (“IP”) layer with data in an IP format, and where the IP layer is nested

15

within (3) an Ethernet (“ENET”) layer with data in an Ethernet format. Id. at 4:21-23.

16
17
18
19
20
21

To break down and reassemble the packetized messages having layers of data in different

22

formats, computer systems use software routines to process the data at each layer of the packet and

23

then convert the data into another format that is compatible with the next layer. Id. at 5:6-15. The

24

sending and receiving computers systems must have numerous individual software routines

25

available to process message packets that include layers of data in a variety of formats. See Dkt.

26

1-2 (the ’683 patent) at col. 1:45-48. To process the packetized message described above, the

27

receiving computer system will use a sequence of three software routines: (1) first, the packet is

28

processed by a software routine associated with an ENET protocol, (2) then the packet is
4

1

processed by a software routine associated with an IP protocol, (3) and finally, the packet is

2

processed by a software routine associated with a TCP protocol. See Dkt. 43 (Implicit Opening

3

Brief) at 5:6-15. Thus, upon receiving a message packet, the computer system will search for the

4

correct sequence of software routines needed to process the packet according to the sequence of

5

layered data formats within the packet. See Dkt. 1-2 (the ’683 patent) at col. 2:4-11. While this

6

description is a general overview, the technology has developed over time. A familiarity with the

7

relevant prior art systems is important to understanding the invention disclosed in the ’683 patent.

8
9

B. The Prior Art Mosberger System
The prior art Mosberger system is relevant to the present case because it was considered by

11
United States District Court
Northern District of California

10

the PTO during the ’163 patent Reexam and ’683 patent prosecution, and Mosberger was front

12

and center in the earlier Case No. 10-cv-3365 between the parties. The ’683 patent relates to a

13

system that is based in part on prior art technology disclosed by Mosberger, thus a description of

14

Mosberger provides the technical context for understanding the ’683 patent.

15

Implicit went to great lengths to differentiate the ’163 patent from Mosberger during the ’163

16

patent Reexam. Statements during the Reexam that describe Implicit’s own understanding of

17

Mosberger and the invention disclosed in the ’163 patent can be pertinent to construing the claims

18

in the related ’683 patent.10

Additionally,

19

In the early days of computer networking, there were only a limited number of computer

20

applications (e.g., internet browsers, email), and therefore a limited number of different types of

21

packetized messages being transmitted and received between computer systems. See Dkt. 43

22

(Implicit Opening Brief) at 5:16-6:5.

23

predictable, thus the sequences of software routines needed to process the packets could be

24

“purpose-built” for specific applications; in other words the sequences were preconfigured11 and

The data formats within these layered packets were

25
10

26
27

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

28

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
5

1

built into the system itself prior to receiving any message packets. See id. However, the purpose-

2

built systems were only able to process message packets that matched the particular application,

3

and if the system needed to handle a packet containing data in a new format, the developer had to

4

take the system off-line, write code for new software routines that can process the new data

5

format, recompile and rebuild the system, and then put it back online. See id.
Mosberger describes one such prior art system that was prebuilt with a finite set of

7

preconfigured sequences of routines and could not dynamically adapt to process message packets

8

containing layers of data in new formats. During the ’163 patent Reexam, Implicit represented its

9

own understanding of the invention disclosed in the ’163 patent by citing to the patent

10

specification (common to the related continuation ’683 patent in suit) and distinguishing the

11
United States District Court
Northern District of California

6

invention from prior art systems like Mosberger:
ii. The Specification Shows That The ‘Sequence of Components12
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

12
13
14

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.

15
16
17
18
19
20
21

Consistent with the above, the ’163 specification further teaches that
‘when a packet of a message is received, the conversion system in

22
23
24
25
26
27
28

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

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).
6

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.

1
2
3
4

See Dkt. 43-7 (’163 patent Reexam 9/1/2009 Amendment and Response) at 18 (emphasis added).

5
6

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

7
preconfigured sequences of routines, in other words preconfigured paths.”
8
9
10

United States District Court
Northern District of California

11

Dkt. 1-3 (Order

Granting Summary Judgment)13 at 24:4-5; see also Dkt. 44-17 (Claim Construction Order)14 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

12
undergoing Reexam. This distinction is important because the Federal Circuit has held that a
13
14
15

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

16
the application of prosecution disclaimer involves statements from prosecution of a familial patent
17
relating to the same subject matter as the claim language at issue in the patent being construed,
18

those statements in the familial application are relevant in construing the claims at issue.”).

19
In the present case, Implicit again describes Mosberger at length and annotates a Mosberger figure
20

to differentiate the ’683 patent from the Mosberger prior art system.

21
22
///
23
///
24
25
13

26

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

27

14

28

Implicit Networks, Inc. v. F5 Networks, Inc., No. C 10-cv-3746 SI, 2012 WL 669861, at *3
(N.D. Cal. Feb. 29, 2012).
7

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11

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

12

builds the system’s functionality by identifying the appropriate “modules” (i.e., individual

13

software routines) and connecting them into a “module graph” (i.e., a sequence). Id.; see also 43-

14

6 (Mosberger) at 6 (“A modular design supports a mix-and-match approach that allows building

15
16
17
18
19
20
21
22
23
24
25
26
27

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

28
8

1

finite set of preidentified sequences of routines and paths; thus these systems could not process

2

message packets containing new data formats. See id. at 8:1-9; Dkt 43-10 (the ’683 patent

3

prosecution history) at 11 (“[T]he paths are created independently of the messages. . . .

4

Importantly, this set of paths is finite; Mosberger does not teach creation of new paths after

5

initialization.”). If the Mosberger system needed to process a message packet containing a new

6

data format, the developer had to take the system off-line, write code for new modules (i.e.,

7

individual software routines), add the new modules to the appropriate locations within a new

8

module graph (i.e., sequence of routines) and describe their connections to other modules within

9

the graph, recompile and rebuild the entire system, and then put the system back online. Dkt. 43

10

(Implicit Opening Brief) at 8:1-9.

United States District Court
Northern District of California

11

In sum, Mosberger discloses a system that, upon receiving a message packet, identifies the

12

appropriate path to process the packet from a finite set of preconfigured paths that are based on

13

preconfigured sequences of routines, where the paths and sequences were created and existed

14

before the first message packet was received. See Dkt 43-10 (the ’683 patent prosecution history)

15

at 12.

16
17

C. The ’683 Patent

18

As networked computer systems (e.g., the Internet) became more pervasive, many new

19

data formats were developed for communicating between systems. See Dkt. 43-1 (the ’683 patent)

20

at col. 1:54-57. Because a system may receive data “in many different formats that may not be

21

known until the data is received,” the purpose-built prior art systems with paths based on

22

preconfigured sequences of routines were not flexible enough to process all of the new data

23

formats flowing through networks. Dkt. 43 (Implicit Opening Brief) at 8:11-17 (quoting the ’683

24

patent at col. 1:54-57).

25

To address this problem, the system disclosed in the ’683 patent is “a technique for

26

dynamically identifying a series of [] routines for processing data” in received message packets

27

that provides a computer system with flexibility to handle new data formats that may not be

28

known until the message packet is received. Id. (quoting the ’683 patent at 2:4-11). Implicit
9

1

contends that the ’683 patent and U.S. Patent No. 7,730,211 (“the ’211 patent”)15 specifications

2

disclose a preferred embodiment that creates paths after messages arrive based on information in

3

the received message packets. Dkt. 43 (Implicit Opening Brief) at 8:18-22. These paths are

4

created by using a Label Map Get module to select not only (a) pre-identified sequences of

5

routines that existed before the first message packet was received, but also (b) sequences of

6

routines that are dynamically identified and come into existence only after the first message packet

7

was received. Id.
The Court finds it helpful at this juncture in the technical discussion to introduce the

9

dispute between the parties: F5 contends that the ’683 patent cannot create paths by using (a) pre-

10

identified sequences of routines that existed before a first message packet was received, because

11
United States District Court
Northern District of California

8

Implicit’s statements to the PTO during the ’163 Reexam disclaimed the use of pre-identified

12

sequences of routines. See Dkt. 44 (F5 Responsive Brief) at 7:7-28, 8:20-9:19.

13

Continuing with the description of the ’683 patent, Implicit explains the general procedure

14

for processing data in a received message packet. See Dkt. 43-1 (the ’683 patent) at col. 2:4-6,

15

Figure 1. First, the Driver receives a message packet from an external network (e.g., the Internet).

16

See id. at col. 4:1-15. After receiving the packet, the system calls the Message Send, Demux, and

17

Label Map Get modules. See id. The Label Map Get module is invoked to identify the correct

18

sequence of routines for processing the packet. See id.

19

The Label Map Get module is described in both of the ’683 and ’211 patents. See Dkt. 43-

20

1 (the ’683 patent) at col. 3:62-67 (“The dynamic identification of conversion routines is described

21

in [the ’211 patent].”). The ’211 patent discloses the Label Map Get module in Figure 8.16 See

22
23
24
25
26

15

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.”).
16

27
28

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

1

Dkt. 43-11 (the ’211 patent) at col. 7:17-8:14, Figure 8. As explained in the following sections,

2

the Label Map Get module is the functionality that can select not only (a) a pre-identified

3

sequence of routines that existed before the first message packet was received, but also (b) a

4

sequence of routines that was dynamically identified and came into existence after the first

5

message packet was received. See Dkt. 43 (Implicit Opening Brief) at 8:18-22.

6
7

i. (a) Selecting a pre-identified sequence of routines that existed before a first
message packet was received

8

To select a pre-identified sequence of routines, the Label Map Get module first checks
9
10

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

11
United States District Court
Northern District of California

patent) at col. 7:17-8:14, Figure 8. During system initialization and before any message packets
12
13

are received, the embodiment can “prime the cache” with addresses for pre-identified sequences of
routines.17

Id. at col. 3:34-35.

In other words, before receiving any message packets, the

14
embodiment can prefill the system with addresses (i.e., locations in memory) for pre-identified
15
sequences of routines. If the primed cache contains an address for a pre-identified sequence of
16
routines that can be used to process the message packet, then the Label Map Get module returns
17
the address for that pre-identified sequence. Id. at col. 7:44-52. Notably, the prior art Mosberger
18
19
20

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.”).

21
During the March 18, 2015, tutorial and Markman hearing, the parties did not dispute that
22

the ’683 and ’211 patents disclose an embodiment that may use pre-identified (i.e., pre-

23
configured) sequences of routines, similar to the prior art Mosberger system. However, in the
24
prior Case No. 10-cv-4234, the Court held that Implicit disclaimed this functionality from the
25
26
17

27
28

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

1

shared patent specification during the ’163 Reexam: Implicit’s response “makes clear that what it

2

was disclaiming in the prior art was use of preconfigured sequences of routines, in other words

3

preconfigured paths.” Dkt. 1-3 (10-cv-03365 Order Granting Summary Judgment) at 24:4-5; see

4

also Dkt. 44-17 (10-cv-03365 Claim Construction Order) at 6:2-10. Nonetheless, the Court also

5

found that Implicit “did not disclaim the ability to create a sequence of [] routines by relying in

6

some part on predefined ‘configuration information,’ but only the use of pre-configured paths.” Id

7

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’

9

shared specification may rely in some part on “predefined configuration information” to

10

dynamically identify the sequence of routines, this embodiment does not identify the complete

11
United States District Court
Northern District of California

8

sequence of routines needed to fully process the message packet until after the system receives a

12

first message packet. The embodiment of the Label Map Get module described in the following

13

section complies with the Court’s finding that an embodiment may rely in some part on predefined

14

configuration information and Implicit’s ’163 patent Reexam disclaimer that the invention does

15

not use pre-configured sequences of routines that existed before receiving a first message packet.

16
17
18

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

19
identify a sequence of routines after the system receives a first message packet. If no pre20
identified sequence of routines existing in the primed cache can be used to process the packet, then
21
the Label Map Get module invokes the Search Edge Space module to search for individual
22
software routines that can be dynamically identified and sequenced together to process the packet.
23

See Dkt. 43-11 (the ’211 patent) at col. 7:61-65, Figure 8 (step 8-05). The Search Edge Space

24
module searches for suitable routines by comparing the available individual routines to the
25

received packets’ layered data formats. Id. at col. 7:61-65, col. 9:4-7. If the Search Edge Space

26
module identifies the correct routines that can be sequenced together to process the message
27
packet, the Label Map Get module returns the address corresponding to that dynamically
28
12

1

identified sequence of routines. Id.
For example, the ’683 patent discloses an embodiment that dynamically identifies a

3

complete sequence of routines by using the Label Map Get module to (1) select the first three

4

software routines that have been identified and exist before the system received a first message

5

packet (i.e., relying in some part on predefined configuration information), and then, because the

6

first three routines cannot process the packet completely, the embodiment again uses the Label

7

Map Get feature to (2) dynamically identify the final two routines that are necessary to complete

8

the sequence and perform final processing of the packet. See Dkt. 43-1 (the ’683 patent) at col.

9

4:1-44. In sum, this embodiment dynamically identifies a sequence of five individual software

10

routines by relying in some part on predefined configuration information (the first three routines),

11
United States District Court
Northern District of California

2

and where the complete sequence of routines exists after the system received a first message

12

packet. See id.

13

Therefore, this embodiment is in accordance with the Court’s earlier finding that the ’683

14

patent may rely in some part on predefined configuration information and Implicit’s disavowal

15

made during the ’163 Reexam. See Dkt. 43-7 (’163 Reexam 9/1/2009 Amendment and Response)

16

at 18 (“[T]he sequence of routines (or ‘path’) is not configured prior to receiving the first packet of

17

a message. . . . [T]he sequence of routines in the ’163 invention is not identified until the incoming

18

message is received.”). During the March 18, 2015, tutorial and Markman hearing, the parties did

19

not dispute that the Label Map Get module disclosed in the ’683 and ’211 patents can dynamically

20

identify a sequence of routines after receiving a first message packet (i.e., does not use pre-

21

identified sequences of routines), which, as Implicit explained during the ’163 Reexam, departs

22

drastically from the prior art Mosberger system. See id.

23

By dynamically identifying a sequence of routines after receiving a first message packet,

24

the invention disclosed in the ’683 patent can be reconfigured “on-the-fly” to process incoming

25

message packets containing new data formats, thereby overcoming the drawbacks in the prior art

26

Mosberger system. See Dkt. 43 (Implicit Opening Brief) at 11:1-17. Once the Label Map Get

27

module has identified the appropriate sequence of routines to process the received message packet,

28

the system creates a path (based on the sequence) that will process the packet’s layers in
13

1

accordance with the sequence of routines.

2
3

iii. Path Creation and Packet Processing

4

To process the received message packet, the invention disclosed in the ’683 patent creates

5

a path based on the identified sequence of routines. After the Label Map Get module returns an

6

address corresponding to a sequence of routines, where the sequence is either (a) a pre-identified

7

sequence that existed before receiving a first message packet or (b) a dynamically identified

8

sequence that exists after receiving a first message packet, the Demux module selects the sequence

9

indicated by the address and creates a path to process the packet. See Dkt. 43-1 (the ’683 patent)

10

at col. 4:13-25.

United States District Court
Northern District of California

11

For example, as shown in Figure 1 of the ’683 patent, the path is represented by a series of

12

five path entries (151-155). See id. The system will then queue the packet so that it can be

13

processed by the path comprising the sequence of routines.

14

completely processing the first packet of a message, the system temporarily stores the sequence of

15

routines as a “session” so that the same sequence can be quickly found when subsequent packets

16

of the same message are received. See id. at col. 2:55-61.

See id. at col. 2:53-56.

After

17

Thus, the ’683 and ’211 patent specifications disclose an embodiment that can create a

18

path based on (a) a pre-identified (i.e., pre-configured) sequence of routines that existed before a

19

first message packet was received and (b) a sequence of routines that is dynamically identified and

20

exists after a first message packet is received. However, the parties dispute whether Implicit’s

21

disclaimer made during the ’163 patent Reexam disclaimer should be relevant to construing the

22

’683 patent claims as set forth in this Order, thereby excluding the use of (a) a pre-identified

23

sequence of routines that existed before a first message was received.

24
LEGAL STANDARD

25
26

Claim construction is a matter of law. Markman v. Westview Instr., Inc., 517 U.S. 370,

27

372 (1996).

Terms contained in claims are “generally given their ordinary and customary

28

meaning.” Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005). “[T]he ordinary and
14

1

customary meaning of a claim term is the meaning that the term would have to a person of

2

ordinary skill in the art in question at the time of the invention.” Id. at 1312. In determining the

3

proper construction of a claim, a court begins with the intrinsic evidence of record, consisting of

4

the claim language, the patent specification, and, if in evidence, the prosecution history. Id. at

5

1313; see also Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). “The

6

appropriate starting point . . . is always with the language of the asserted claim itself.” Comark

7

Communications, Inc. v. Harris Corp., 156 F.3d 1182, 1186 (Fed. Cir. 1998); see also Abtox, Inc.

8

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

10

light of their ordinary and accustomed meaning, unless examination of the specification,

11
United States District Court
Northern District of California

9

prosecution history, and other claims indicates that the inventor intended otherwise. See Electro

12

Medical Systems, S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1053 (Fed. Cir. 1994). The

13

specification can provide guidance as to the meaning of the claims, thereby dictating the manner in

14

which the claims are to be construed, even if the guidance is not provided in explicit definitional

15

format. SciMed Life Systems, Inc. v. Advanced Cardiovascular Systems, Inc., 242 F.3d 1337, 1344

16

(Fed. Cir. 2001). Although claims are interpreted in light of the specification, this “does not mean

17

that everything expressed in the specification must be read into all the claims.” Raytheon Co. v.

18

Roper Corp., 724 F.2d 951, 957 (Fed. Cir. 1983). For instance, limitations from a preferred

19

embodiment described in the specification generally should not be read into the claim language.

20

See Comark, 156 F.3d at 1187. However, it is a fundamental rule that “claims must be construed

21

so as to be consistent with the specification.” Phillips, 415 F.3d at 1316. Therefore, if the

22

specification reveals an intentional disclaimer or disavowal of claim scope, the claims must be

23

read consistently with that limitation. Id.

24

A disavowal of claim scope requires that “the specification [or prosecution history] make

25

[] clear that the invention does not include a particular feature,” SciMed Life Sys., 242 F.3d at

26

1341, or is clearly limited to a particular form of the invention, Edwards Lifesciences LLC v. Cook

27

Inc., 582 F.3d 1322, 1330 (Fed. Cir. 2009). See Hill-Rom Servs., Inc. v. Stryker Corp., 755 F.3d

28

1367, 1372 (Fed. Cir.) cert. denied, 135 S. Ct. 719 (2014). For example, the Federal Circuit has
15

1

held that a disclaimer applies when the patentee makes statements such as “the present invention

2

requires . . .” or “the present invention is . . .” or “all embodiments of the present invention

3

are . . .” See id. (citing Regents of Univ. of Minn. v. AGA Med. Corp., 717 F.3d 929, 936 (Fed.

4

Cir. 2013); Honeywell Int'l, Inc. v. ITT Indus., Inc., 452 F.3d 1312, 1316-19 (Fed. Cir. 2006);

5

SciMed, 242 F.3d at 1343-44).

6

invention’ as a whole, this description limits the scope of the invention.” Verizon Servs. Corp. v.

7

Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007).

“When a patent thus describes the features of the ‘present

Finally, the Court may also consider the prosecution history of the patent, if in evidence.

9

Markman, 52 F.3d at 980. The prosecution history can often inform the meaning of the claim

10

language by demonstrating how the inventor understood the invention and whether the inventor

11
United States District Court
Northern District of California

8

limited the invention in the course of prosecution, making the claim scope narrower than it would

12

be otherwise. Phillips, 415 F.3d at 1317. In most situations, analysis of this intrinsic evidence

13

alone will resolve claim construction disputes. See Vitronics, 90 F.3d at 1583. Courts should not

14

rely on extrinsic evidence in claim construction to contradict the meaning of claims discernable

15

from examination of the claims, the written description, and the prosecution history. See Pitney

16

Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1308 (Fed. Cir. 1999) (citing Vitronics, 90

17

F.3d at 1583).

18
19

DISCUSSION

20

The parties dispute the construction of one term that appears in independent Claims 1, 10,

21

16, and 24 of the ’683 patent: “sequence of routines” (Claims 1 and 24), “list of routines” (Claim

22

16), and “list of conversion routines” (Claim 10).

23
24
25
26
27

///

28

///
16

1
2
3
4
5

Claim Term
“sequence of routines”
Claims 1, 4, 5, 6, 8, 9, 24,
28, 30
“list of routines”
Claim 16

6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

“list of conversion routines”
Claim 10

Implicit’s Proposed
Construction
No construction necessary;
ordinary and customary
meaning applies.
Alternative: “an ordered
arrangement of software
routines”
No construction necessary;
ordinary and customary
meaning applies.
Alternative: “an ordered
arrangement of software
routines for changing data

F5’s Proposed Construction
“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”
“a 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”

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:1714:28. Relevant for the purposes of this claim construction, Claim 1 is treated by the parties as
17

1

representative18:
Claim 1. A first apparatus for receiving data from a second apparatus, the first

2

apparatus comprising:

3
4

a) a processing unit; and
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.

5
6
7
8
9
10

United States District Court
Northern District of California

11

Dkt. 1-2 (the ’683 patent) at col. 14:20-35 (emphasis added).

12

Although the claim language sets forth that the invention receives a message packet, and

13

then, based on information in the received packet, creates a path that indicates a sequence/list of

14

routines, the claim language does not explicitly state whether the sequence/list of routines was

15

identified before or after the system received the packet of the message.

16

In support of using the ordinary meaning, Implicit points to dependent Claims 8 and 9 that

17

narrow the scope of Claim 1. Dkt. 43 at 15:1-16:3. Claim 8, which depends from Claim 1,

18

requires the invention to “identify an address associated with the information, wherein the address

19

indicates the routines in the sequence of routines of the created path.” Dkt. 1-2 (the ’683 patent) at

20

col. 14:60-64. And Claim 9, which depends from Claim 8, further requires the invention “to use

21

the address to select the sequence of routines from a plurality of sequences of routines that are

22

stored . . . prior to receiving the packet of the message.” Id. at col. 14:65-15:2.

23

Implicit contends that Claim 9 covers sequences of routines that are identified and stored

24

in the system before receiving a packet of the message. Dkt. 43 at 15:14-23. F5 disagrees,

25

arguing that Claim 9 does not disclose selecting from a plurality of sequences that were identified

26
27
28

18

Implicit states that the ’683 patent’s independent Claims 1 and 10 are illustrative. See Dkt. 43 at
12:24.
18

1

and existed before the system received a packet of the message; rather, it relates to the last step of

2

Claim 1, where the system processes “subsequent packets in the message.” Dkt. 44 at 19:6-20:11.

3

In other words, F5 asserts that Claim 9 relates to selecting the sequence of routines from a

4

plurality of sequences of routines that were stored after the received packet arrived so that the

5

system can process the “subsequent packets” of that same message. Although the Court is not

6

evaluating the validity of Claim 9 in this Order, the term “the packet of the message” in dependent

7

Claim 9 appears to be indefinite as lacking proper antecedent basis, because Claim 1 recites both

8

“a received packet” and “subsequent packets,” making it unclear which “packet” Claim 9

9

references.19 Therefore, the Court finds that dependent Claims 8 and 9 do not provide clear

10

support for the either party’s proposed construction.

United States District Court
Northern District of California

11

The Court next turns to the ’683 patent specification and the related parent ’163 patent

12

prosecution history. While the claim language itself, standing alone, may not be conclusive in

13

showing whether the claims require that the sequence/list of routines be identified after the first

14

packet of a message was received, Implicit’s statements in the specification buttressed by the

15

prosecution history make it sufficiently clear. From the beginning of the specification common to

16

the ’163 and ’683 patents, the inventors’ basis for distinguishing their invention was its ability to

17

dynamically identify a sequence of software routines for processing data. In the Background, the

18

inventors stated, “These [prior art] computer systems typically use predefined configuration

19

information to load the correct combination of [software] routines for processing data.” Dkt. 1-2

20

(the ’683 patent) at col. 1:48-50. The inventors specifically state that these prior art systems had

21

drawbacks because they “can be expected to receive data and to provide data in many different

22

formats that may not be known until the data is received. The overhead of statically[sic] providing

23

each possible series of conversion routines is very high.” Id. at col. 1:54-59. The specification

24
25
26
27
28

19

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.).
19

1

then indicates that “[i]t would be desirable to have a technique for dynamically identifying a series

2

of [software] routines for processing data.” Id. at col. 2:4-11.

3

During the prosecution of the parent ’163 patent and in response to the PTO’s office

4

action, Implicit devoted an entire section of its response to further explain these prior art

5

disavowals in the first column of the specification shared by the ’163 and ’683 patents:

6
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

7
8

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.

9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21

Dkt. 43-7 (’163 patent Reexam 9/1/2009 Amendment and Response) at 18.

22

Implicit’s description of the invention as disclosed in the shared specification and the

23

resulting disavowal is clear and unmistakable. See Cordis Corp. v. Medtronic AVE, Inc., 339 F.3d

24

1352, 1358 (Fed. Cir. 2003) (“Such a disclaimer requires clear and unmistakable statements of

25

disavowal.”).

26

disavowals made during the prosecution of ancestor patent applications,” such as the parent ’163

27

patent. Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1333 (Fed. Cir. 2003). The Court

28

recognizes that “[i]n general, a prosecution history disclaimer will only apply to a subsequent

The Federal Circuit has held that “prosecution disclaimer may arise from

20

1

patent if that patent contains the same claim language as its predecessor.” Regents of Univ. of

2

Minnesota, 717 F.3d at 943 (citing Ventana Med. Sys. v. Biogenex Labs., Inc., 473 F.3d 1173,

3

1182 (Fed. Cir. 2006)).

4

However, the case before the Court presents “[t]he sole exception [] when the disclaimer is

5

directed to the scope of the invention as a whole, not a particular claim.” Id.; see also Ormco

6

Corp. v. Align Tech., Inc., 498 F.3d 1307, 1314–15 (Fed. Cir. 2007) (finding a disclaimer applied

7

to a related patent when the patent owner’s statements “w[ere] not associated with particular

8

language from [the] claims” but were instead directed to the “present invention” and the “overall

9

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

11
United States District Court
Northern District of California

10

language at issue in the patent being construed, those statements in the familial application are

12

relevant in construing the claims at issue.” Ormco, 498 F.3d at 1314 (Fed. Cir. 2007) (emphasis

13

added) (citing Wang Lab., Inc. v. Am. Online, Inc., 197 F.3d 1377, 1384 (Fed. Cir. 1999); Jonsson

14

v. Stanley Works, 903 F.2d 812, 818 (Fed. Cir. 1990)). The Court finds that Implicit’s statements

15

during the ’163 patent Reexam readily meet the exception to the general rule. Here, the ’163 and

16

’683 patents’ specifications have the same content. None of the above quoted statements from the

17

’163 patent Reexam were directed to a specific claim; rather, the description was directed to the

18

scope of the invention as a whole as it is disclosed in the shared specification. Moreover,

19

Implicit’s statements were related to the same subject matter as the claim term now being

20

construed in the related continuation ’683 patent.20

21

Implicit made it definitively clear to the PTO and the public that the sequence of routines

22

(or ‘path’) as disclosed in the ’163 patent specification is not configured before receiving the first

23

packet of a message. Omega Eng'g, Inc., v. Raytek Corp., 334 F.3d 1314, 1324 (Fed. Cir. 2003)

24
25
26
27
28

20

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

1

(“As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice

2

function of the intrinsic evidence and protects the public's reliance on definitive statements made

3

during prosecution.”). Therefore, the Court finds that the prosecution disclaimer from the ’163

4

patent Reexam attaches to the construction of the ’683 patent claims and narrows the scope of the

5

disputed term.
Implicit attempts to avoid the doctrine of prosecution disclaimer by advancing several

7

arguments for concluding otherwise, but the Court is unconvinced. First, Implicit argues that a

8

preferred embodiment disclosed in the ’211 patent specification, which is incorporated by

9

reference in the ’683 patent, supports the ordinary meaning of the term. As discussed above in the

10

Background, the parties do not dispute that the ’211 patent discloses an embodiment that may use

11
United States District Court
Northern District of California

6

sequences of routines that are identified and exist before a first message packet arrives, similar to

12

the prior art Mosberger system.

13

embodiment from the shared patent specification during the ’163 patent Reexam. See N. Am.

14

Container, Inc. v. Plastipak Packaging, Inc., 415 F.3d 1335, 1346 (Fed. Cir. 2005) ("[W]e have

15

previously explained that limitations may be construed to exclude a preferred embodiment if the

16

prosecution history compels such a result.”). Furthermore, Implicit’s disclaimer is not inconsistent

17

with other embodiments disclosed in the shared specification.

18

GlaxoSmithKline LLC, 713 F.3d 1090, 1097 (Fed. Cir. 2013) ("[T]he applicants’ disclaimer in this

19

case is not necessarily inconsistent with other possible embodiments or even the dependent claims

20

. . . .”); see also Phillips, 415 F.3d at 1316 (“Claims must be construed so as to be consistent with

21

the specification.”). As discussed above, an embodiment of the Label Map Get feature disclosed

22

in the ’683 patent specification complies with Implicit’s disclaimer and with the Court’s finding in

23

the earlier Case No. 10-03365 that the invention may rely in some part on “predefined

24

configuration information.” Dkt. 1-3 (10-03365 Order Granting Summary Judgment) at 24:4-5.

25

This embodiment dynamically identifies a sequence of routines by using the Label Map Get

26

module to select the first three software routines that were identified and existed before the system

27

received a first message packet, then the Label Map Get module dynamically identifies the final

28

two routines that are necessary to complete the sequence of routines and fully process the packet.

Nonetheless, the Court finds that Implicit disclaimed this

22

Biogen Idec, Inc. v.

1

See Dkt. 43-1 (the ’683 patent) at col. 4:1-44.

This embodiment complies with Implicit’s

2

disclaimer because it does not identify the complete sequence of five routines needed to process

3

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

5

meaning of the term. The Court disagrees. Implicit argues that during the prosecution of the ’683

6

patent, Implicit did not disclaim any scope of the claim term now being construed. However, this

7

is immaterial. For a disclaimer in a parent patent to be rescinded, permitting recapture of the

8

disclaimed scope in a later related continuation patent, “the prosecution history must be

9

sufficiently clear to inform the examiner that the previous disclaimer, and the prior art that it was

10

made to avoid, may need to be re-visited.” Hakim v. Cannon Avent Grp., PLC, 479 F.3d 1313,

11
United States District Court
Northern District of California

4

1318 (Fed. Cir. 2007). There is no evidence in the ’683 patent prosecution history, much less

12

sufficiently clear evidence, that informed the examiner that the disclaimer Implicit made during

13

the ’163 patent Reexam would need to be revisited.

14

Finally, Implicit argues that there was no disavowal made during the ’163 patent Reexam

15

because the PTO rejected the disavowal. See Dkt. 44 at 20:22-21:2 (“In effect, the PTO was

16

saying that Implicit would have to narrow its claim language because there is no disavowal.”).

17

Again, the Court disagrees. Any statement made by Implicit during prosecution is given weight,

18

serves the patent prosecution history’s public notice function, and may be considered to constitute

19

a disclaimer, just as this Court found in the previous case.21 See Elkay Mfg. Co. v. Ebco Mfg. Co.,

20

192 F.3d 973, 979 (Fed. Cir. 1999) (“Arguments made during the prosecution of a patent

21

application are given the same weight as claim amendments.”). Therefore, Implicit’s statements

22

constitute a disavowal regardless of whether or not the Examiner accepted the arguments.
F5’s proposed construction, however, is no more helpful as it attempts to limit the term

23
24
25
21

26
27
28

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:210.
23

1

more narrowly than warranted by Implicit’s prosecution history disavowal.22 Several of the

2

proposed words do not find support in the specification or the prosecution history.
Sequence/List of routines, therefore, is construed as “a sequence [list] of software

3
4

routines that was not identified (i.e., configured) prior to receiving a first packet of the message.”

5
CONCLUSION

6

For the foregoing reasons and for good cause shown, the Court adopts the construction set

7
8

our above.

9
10
IT IS SO ORDERED.

United States District Court
Northern District of California

11
12

Dated: May 6, 2015

13
________________________
SUSAN ILLSTON
United States District Judge

14
15
16
17
18
19
20
21
22
23
24
25
26
27

22

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.

28
24