Network Protection Sciences, LLC v. Juniper Networks, Inc. et al

Filing 189

CLAIM CONSTRUCTION ORDER (whalc1, COURT STAFF) (Filed on 1/14/2013)

1
2
3
4
5
6

IN THE UNITED STATES DISTRICT COURT

7
FOR THE NORTHERN DISTRICT OF CALIFORNIA
8
9

11
For the Northern District of California

United States District Court

10

NETWORK PROTECTION SCIENCES,
LLC,
Plaintiff,

12
13
14
15

No. C 12-01106 WHA

CLAIM CONSTRUCTION ORDER
v.
FORTINET, INC.,
Defendant.
/

16
INTRODUCTION

17
18

In this patent infringement action involving network firewalls, the parties seek

19

construction of six phrases found in the asserted patent. On December 21, 2012, a tentative

20

claim construction order was issued, and the parties were invited to file five-page critiques of the

21

constructions therein. After consideration of the supplemental briefing, final constructions of the

22

six phrases are set forth below.

23
24

STATEMENT
The technology described in United States Patent No. 5,623,601 dates to 1994. Although

25

the modern internet was still unknown to large sections of the general public at the time,

26

networked computing had been around for decades. Computer viruses and other network

27

security threats were already a problem of substantial concern. Computer firewalls — network

28

barriers that analyze packets of information to determine whether they should be let through —

1

were a relatively recent response to these threats. The technology at issue in this action relates to

2

firewall technology intended to improve network security and user convenience.

3

Plaintiff Network Protection Sciences (“NPS”) is asserting 54 of the 59 claims in the

4

’601 patent against defendant Fortinet, Inc. The parties seek construction of six phrases

5

appearing in this patent. This claim construction order follows a tentative claim construction

6

order, oral argument, and subsequent briefing by defendant Fortinet (NPS submitted to the

7

constructions in the tentative claim construction order without further critique (Dkt. No. 188)).

8
9

1.

CLAIM CONSTRUCTION LEGAL STANDARD.

Claim construction is from the perspective of one of ordinary skill in the pertinent art at

11
For the Northern District of California

United States District Court

10

ANALYSIS

the time the patent was filed. Chamberlain Group, Inc. v. Lear Corp., 516 F.3d 1331, 1335

12

(Fed. Cir. 2008). While claim terms “are generally given their ordinary and customary

13

meaning,” the “claims themselves provide substantial guidance as to the meaning of particular

14

claim terms.” As such, other claims of the patent can be “valuable sources of enlightenment as

15

to the meaning of a claim term.”

16

Critically, a patent’s specification “is always highly relevant to the claim construction

17

analysis.” Phillips v. AWH Corp., 415 F.3d 1303, 1312–15 (Fed. Cir. 2005) (en banc) (internal

18

quotations omitted). Indeed, claims “must be read in view of the specification, of which they are

19

a part.” Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc),

20

aff’d, 517 U.S. 370 (1996). Finally, courts also should consider the patent’s prosecution history,

21

which “can often inform the meaning of the claim language by demonstrating how the inventor

22

understood the invention and whether the inventor limited the invention in the course of

23

prosecution, making the claim scope narrower than it would otherwise be.” These components

24

of the intrinsic record are the primary resources in properly construing claim terms. Although

25

courts have discretion to consider extrinsic evidence, including dictionaries, scientific treatises,

26

and testimony from experts and inventors, such evidence is “less significant than the intrinsic

27

record in determining the legally operative meaning of claim language.” Phillips, 415 F.3d at

28

1317–18 (internal quotations omitted).
2

1

While this order acknowledges that the parties have a right to the construction of all

2

disputed and litigated claim terms by the time the jury instructions are settled, the Court will

3

reserve the authority, on its own motion, to modify the constructions in this order if further

4

evidence — intrinsic or extrinsic — warrants such a modification. Given that claim construction

5

is not a purely legal matter, but is (as the Supreme Court describes it) a “mongrel practice” with

6

“evidentiary underpinnings,” it is entirely appropriate for the Court to adjust its construction of

7

claims prior to instructing the jury if the evidence compels an alternative construction, or if one

8

side or the other advances a spin on the words that is unwarranted. Markman, 517 U.S. at 378,

9

390. The parties should be aware, however, that they are not invited to ask for reconsideration of
the constructions herein. Motions for reconsideration may be made only in strict accordance

11
For the Northern District of California

United States District Court

10

with the rules of procedure, if at all.

12

2.

THE ’601 PATENT.

13

The ’601 Patent, entitled “Apparatus and Method for Providing a Secure Gateway for

14

Communication and Data Exchanges Between Networks,” was filed on November 21, 1994, and

15

issued on April 22, 1997. Milkway Networks Corporation is the assignee, and plaintiff is

16

Milkway’s successor-in-interest. In 2011, Fortinet filed a request for reexamination, and in May,

17

2012 the USPTO issued a reexamination certificate for the patent confirming all claims (1–41)

18

and adding new claims (42–59).

19

In this action, NPS is asserting 54 of the 59 claims in the ’601 patent, including both

20

method and apparatus claims. The six claim terms for which the parties seek constructions can

21

be found, inter alia, in claims 1, 10, and 11 (reproduced below with the relevant claim terms

22

italicized).

23

Claim 1 covers the following method (col. 14:11–42):

25

A method of providing a secure gateway between a private
network and a potentially hostile network, comprising the steps
of:

26

(a)

24

27
28

1.

addressing communications packets directly to a host on
the potentially hostile network as if there were a
communications path to the host, but encapulating [sic]
the packets with a hardware destination address that
matches a device address of the gateway;
3

1

(b)

accepting at the gateway communications packets from
either network that are encapsulated with a hardware
destination address which matches the device address of
the gateway;

(c)

determining at the gateway whether there is a process
bound to a destination port number of an accepted
communications packet;

(d)

establishing transparently at the gateway a first
communications session with a source address/source port
of the accepted communications packet if there is a
process bound to the destination port number, else
dropping the packet;

(e)

establishing transparently at the gateway a second
communications session with a destination
address/destination port of the accepted communications
packet if a first communications session is established;
and

(f)

transparently moving data associated with each
subsequent communications packet between the respective
first and second communications sessions, whereby the
first session communicates with the source and the second
session communicates with the destination using the data
moved between the first and second sessions.

2
3
4
5
6
7
8
9

11
For the Northern District of California

United States District Court

10

12
13
14
15
16

Claim 10 covers the following method (cols. 15:45–16:14):
10.

17

A method of providing a secure gateway between a private
network and a potentially hostile network, comprising the steps
of:

18

(a)

addressing communications packets directly to a host on
the potentially hostile network as if there were a
communications path to the host, but encapulating [sic]
the packets with a hardware destination address that
matches a device address of the gateway;

(b)

accepting from either network all TCP/IP packets that are
encapsulated with a hardware destination address which
matches the device address of the gateway;

(c)

determining whether there is a proxy process bound to a
port for serving a destination port number of an accepted
TCP/IP packet;

(d)

establishing a first communications session with a source
address/source port number of the accepted TCP/IP packet
if there is [sic] proxy process bound to the port for serving
the destination port number, else dropping the packet;

(e)

determining if the source address/source port number of
the accepted packet is permitted to communicate with a
destination address/destination port number of the

19
20
21
22
23
24
25
26
27
28

4

1

accepted packet by referencing a rule base, and dropping
the packet if a permission rule cannot be located;

2
(f)

establishing a second communications session with the
destination address/destination port number of the
accepted TCP/IP packet if a first communications session
is established and the permission rule is located; and

(g)

transparently moving data associated with each
subsequent TCP/IP packet between the respective first and
second communications sessions, whereby the first session
communicates with the source and the second session
communicates with the destination using the data moved
between the first and second sessions.

3
4
5
6
7
8

Dependent claim 11 covers the following method (col. 16:15–23):
9
11.
11
For the Northern District of California

United States District Court

10

12
13

A method of providing a secure gateway between a private
network and a potentially hostile network as claimed in claim 10
wherein the step of determining involves checking a table to
determine if a custom proxy process is bound to the destination
port number, and passing the packet to a generic proxy process if
a custom proxy process is not bound to the destination port
number, the generic proxy process being executed to establish the
first and second communications sessions and to move the data
between the first and second communications sessions.

14
The patent addresses a basic concern created by the existence of public and private
15
computer networks. Private networks, such as single corporation’s intranet, are relatively secure
16
and often store trade secret and confidential information that must be shielded from public
17
exposure. Public networks, such as the internet, are accessible to anyone with the right hardware
18
and software, and as a consequence attract sabotage, vandalism, and espionage. When a private
19
network connects to a public network, it becomes exposed to these threats. To deal with the
20
problem, secure gateways are installed between the networks to serve as “firewalls” (col.
21
1:23–40).
22
At the time of the invention, firewalls suffered from known disadvantages that
23
compromised their security or inconvenienced users. One firewall technology in the prior art
24
was the “packet filter.” Packet filters were (and are) host-based applications that permitted
25
certain kinds of communications over predefined ports and used pre-defined rule sets to
26
determine what information to let through. Because an operating system such as UNIX running
27
TCP/IP (the communication protocol for the internet) could have 64K communication ports, it
28
was considered impractical to maintain a comprehensive rule base (col. 2:35–45).
5

1

Another firewall technology, “dual homed gateways,” blocked direct traffic and required

2

the public and private networks to each communicate with the gateway. When implemented at

3

the application level, users could (and can) only access specific public services allowed by the

4

gateway. These application level firewalls, however, were inefficient because they generally

5

required the user to execute time-consuming extra operations or to use specially-adapted

6

network-service programs (col. 3:4–22). Also, application level firewalls required application

7

interfaces for each public network service and did not support applications using dynamic port

8

allocations assigned in real time (col. 3:48–52).

gateway station to accept all IP packets with a certain encapsulation. The invention provided for

11
For the Northern District of California

The claimed invention allegedly overcame these problems by modifying a secure

10

United States District Court

9

communication sessions to be initiated between (i) the source network (the network sending the

12

packet) and (ii) the destination network (the network receiving the packet). The “payload” data

13

in the packet were then passed between the two sessions. The new process was more efficient

14

for the user because from the user’s perspective the information was passed as if no gateway

15

existed. The invention also provided for a generic proxy process to handle data such that the

16

gateway could use all 64K ports available on a UNIX operating system and could support

17

dynamic port allocation (cols. 4:17–5:55).

18

A.

19

The parties dispute the term “session.” Both provide constructions, but NPS argues that

“Session”

20

“session” is a term of art that preferably should be given its ordinary meaning. The parties’

21

proposed constructions are provided below:

22
23
24
25
26
27
28
6

1

NPS’ PROPOSED CONSTRUCTION

FORTINET’S PROPOSED
CONSTRUCTION

2
Plain and ordinary meaning; or

3

The application level network
gateway and source maintain a
connection and transfer information,
or the application level network
gateway and destination maintain a
connection and transfer information.

A connection between two functional
units, such as two terminals, stations,
or computers, that allows them to
communicate for a period of time or a
logical association that is established
and maintained between two
functional units that allows them to
communicate.

4
5
6
7
8
9

govern, as understood by one of ordinary skill in the art in 1994.

11
For the Northern District of California

United States District Court

10

This order concludes that the plain and ordinary meaning of the term “session” should

NPS’ proposed alternative construction for “session” is turgid and unhelpful. Its

12

proposal to use the ordinary meaning fares better. NPS does not provide much explanation for

13

its argument that the term should be given its ordinary meaning. Nevertheless, it was a

14

straightforward term in 1994 (and today).

15

Fortinet’s only challenge to using the ordinary meaning of the term “session” is that the

16

patent “always” referred to a session as including the transfer of information. Fortinet’s

17

assertion is incorrect. Information could be transferred during a session, for example by a proxy

18

process or by the kernel (the program at the core of the computer operating system that

19

supported programs running at the application level). The specification also disclosed a situation

20

where a proxy process handling communications would not transfer information. The proxy

21

process could determine that a session had not ended and could wait for data packets to arrive

22

(col. 11:56–65). If a proxy process could wait for data to arrive during an active session but

23

without transferring data, it is clear that a session did not necessarily require information

24

transfer.

25
26
27

This order concludes that the plain and ordinary meaning of the term “session” should
govern (subject to a possible refinement after the trial evidence is heard).
B.

“Proxy process”

28
7

1
2
3

The parties dispute the term “proxy process.” The parties’ proposed constructions are as
follows:
NPS’ PROPOSED CONSTRUCTION

FORTINET’S PROPOSED
CONSTRUCTION

4
5

An application layer process adapted
to handle a respective service.

6

or (at oral argument):

7

An application layer process adapted
to handle communications across a
gateway for a respective service.

8

A program running on an application
level network gateway that initiates
the first session and second session,
and relays “the data portion of each
packet” between the sessions.
or (in its critique):
an application layer process that
relays the ‘data portion of each
packet’ between the first and second
communications sessions.

9

11
For the Northern District of California

United States District Court

10

12
13
14
15
16
17
18
19

This order finds that the term should be construed as: “an application layer process
adapted to handle communications for a network service.”
The term “proxy” was defined in the patent specification. To wit:
When the gateway station 14 is initialized, a system configuration
file is examined to determine what network services are to be
supported by the gateway station 14. In order to maximize
performance efficiency of the gateway station 14, commonly used
services are supported by processes adapted to most efficiently
handle communications for each respective service. These
processes are called “proxies.”
(Col. 9:47–54.) NPS’ proposed constructions are reworded versions of this definition.
Fortinet contends in its claim construction critique that this text does not evince a clear

20

intention to define the term “proxy.” Based on the plain language, this order disagrees.

21

Similarly, Fortinet contends that this text does not purport to define claim language, only a

22

preferred embodiment. Although this language does appear in relation to Figure 6 in the patent,

23

there is no express indication that the patentee intended to limit this definition to Figure 6 alone,

24

or intended to vary the definition elsewhere in the patent.

25

Fortinet also asserts that it is improper to rely on an isolated passage of the specification

26

in support of a broad construction. Fortinet’s attempt to define the patent differently than it was

27

defined by the patentee himself is unpersuasive.

28
8

1

Fortinet asserts that NPS’ proposed construction is an attempt to scrub the patent of its

2

reliance on a “proxy concept,” and that the term should be construed to require a process that

3

“actually acts as a proxy.” At oral argument, Fortinet explained that the patent should be viewed

4

through a particular technological lens — what Fortinet refers to as a “proxy everything”

5

environment. This is an attempt to limit the scope of the claims generally by creating a limiting

6

context. Otherwise, Fortinet contends, NPS’ definition could be read to include any process,

7

even processes that are not proxies, or “any communications service.”

8

Fortinet’s desire to ignore the definition in the specification is improper. “It is a

9

well-established axiom in patent law that a patentee is free to be his or her own lexicographer,
and thus may use terms in a manner contrary to or inconsistent with one or more of their

11
For the Northern District of California

United States District Court

10

ordinary meanings.” Hormone Research Found., Inc. v. Genentech, Inc., 904 F.2d 1558, 1563

12

(Fed. Cir. 1990) (citation omitted). “When a patentee explicitly defines a claim term in the

13

patent specification, the patentee’s definition controls.” Martek Biosciences Corp. v. Nutrinova,

14

Inc., 579 F.3d 1363, 1380 (Fed. Cir. 2009).

15

Aside from this general principle of patent claim construction, the specific limitations

16

requested by Fortinet are unwarranted. In its claim construction briefing, Fortinet asserts that the

17

term proxy process should be limited to include (i) the concept of relaying a data packet between

18

communication sessions, and (ii) the concept that the proxy process initiated the communication

19

sessions. Fortinet’s critique of the tentative claim construction order repeats this argument,

20

stating that “[f]undamentally, any ‘proxy’ necessarily breaks a single communications session

21

into two sessions and relays data between them.” Fortinet insists that the term “‘proxy process’

22

ought to incorporate — somewhere — the concept of a proxy” as Fortinet understands the term.

23

Yet, Fortinet fails to address how its proposed construction addresses situations in the patent

24

where a proxy process deviates from Fortinet’s proposed limitations.

25

NPS agrees that a proxy process can relay data, but does not agree that it should always

26

be so limited. In support, NPS cites examples in the specification where a proxy process did

27

something else, such as verifying an IP address. Fortinet’s limitation, therefore, goes too far.

28
9

1

In its critique, Fortinet offers a compromise construction: “an application layer process

2

that relays the ‘data portion of each packet’ between the first and second communications

3

sessions.” Fortinet’s compromise remains too restrictive because a proxy process in the patent

4

does not necessarily relay data between communications sessions. Fortinet’s assertion that “a

5

proxy always relays and must necessarily relay the data portions of packets between two

6

communications sessions” (Dkt. No. 187 at 3 (emphasis added)) is incorrect. This is evident

7

from claim 18, which discloses a situation where a proxy process relays data from the kernel to

8

another proxy process, to wit: “whereby the TCP/IP packet is passed by a modified kernel of an

9

operating system of the secure gateway to the proxy process which extracts the data from the
packet and passes the data from a [sic] one of the . . . communications sessions to a proxy

11
For the Northern District of California

United States District Court

10

process . . . [which] executes data screening algorithms” (col. 17:31–38).

12

NPS concedes that a proxy process can relay data, but the patent discloses situations

13

where the data is relayed between communications sessions, between the kernel and a proxy

14

process, and between proxy processes. The Court’s construction — “an application layer

15

process adapted to handle communications for a network service” — remains the most suitable

16

because the various forms of data relay and other disclosed proxy process activities are within

17

the general scope of “handling communications.”

18

As for whether the proxy process initiated the communication session, Fortinet concedes

19

that NPS cites examples from the specification where the gateway or kernel initiated the

20

communications. Fortinet contends that these examples are ambiguous. This order disagrees. In

21

particular, Figure 6, which was a “flow diagram of . . . TCP routing by a modified UNIX kernel

22

in accordance with the invention” (col. 6:65–67), showed that the kernel started a session with a

23

source prior to delivering a packet to a proxy process. The fact that elsewhere in the patent the

24

proxy process initiated the communication session only demonstrates that both ideas were

25

disclosed.

26

Another objection by Fortinet in its papers points out a flaw in NPS’ original proposed

27

construction. A close comparison of the definition in the specification and NPS’ proposed

28

construction reveals that NPS has omitted the concept of handling communications. This
10

1

omission unjustifiably broadens the scope of the claim language and is easily corrected. At oral

2

argument, NPS conceded this point by offering compromise construction that included the

3

concept of communications. In order to align the construction with the definition, this order

4

specifies that the proxy process handles “communications for a network service.”

5

The full construction of “proxy process” therefore shall remain: “an application layer

6

process adapted to handle communications for a network service.” Fortinet’s concern that this

7

construction could be warped to encompass “any communications process” is noted. This order

8

reserves the authority to modify the construction at a later time if necessary.

9

C.

“Generic proxy process”

During briefing and oral argument, the parties modified and narrowed their differences

11
For the Northern District of California

United States District Court

10

over this term, but they still dispute the term “generic” as it modifies the term “proxy process.”

12

The parties’ current proposed constructions are shown below:

13

NPS’ PROPOSED CONSTRUCTION

FORTINET’S PROPOSED
CONSTRUCTION

14
15
16
17
18
19
20
21
22

A proxy process that serves any
application not already served by a
dedicated custom proxy process.

A process which can handle a service
for which a dedicated or custom proxy
process is not running.
or (at oral argument):
A proxy process which can handle a
service for which a dedicated custom
proxy process is not running.
or:
A “proxy process” that serves any
service not already served by a
dedicated or “custom” proxy process.

23

This order construes “generic proxy process” as “a proxy process which can handle

24

communications for a network service for which a dedicated or custom proxy process is not

25

running.”

26

Aside from the underlying disagreement over “proxy process,” one aspect of the parties’

27

dispute over this term is whether the terms “dedicated” and “custom” should be listed in the

28

conjunctive or the disjunctive. The specification referred to the generic proxy process operating
11

1

wherever there was not a “dedicated proxy process” (col. 5:48–52). It is also clear from the

2

specification that the inventor anticipated that a generic proxy process could support a network

3

service until a new, custom proxy process was written (col. 12:52–55). Thus, the invention

4

conceived of at least three proxy scenarios: a dedicated proxy, a generic proxy, and a custom

5

proxy that displaced a generic proxy already in use. Fortinet’s construction in the conjunctive

6

cannot accommodate all three possibilities and is therefore too narrow. This order will use the

7

disjunctive phrasing “dedicated or custom.”

between “handle a service” and “serves any application.” Here, Fortinet’s proposed construction

10

strays too far afield from the definition of proxy provided by the inventor, and the phrase “serves

11
For the Northern District of California

The other significant distinction between the proposed constructions lies in the gap

9

United States District Court

8

any application” is ambiguous.

12

A “generic proxy process” was a specific type of “proxy process.” Once again, NPS’

13

construction strays from the definition of “proxy process” in the specification. For clarity and

14

consistency, this order will rely on the inventor’s definition.

15

In sum, a “generic proxy process” shall be construed to mean “a proxy process which can

16

handle communications for a network service for which a dedicated or custom proxy process is

17

not running.”

18

D.

19

During briefing, both parties modified their proposed constructions of this term, but the

20

parties still dispute “process bound to a destination port number.” The parties’ latest proposed

21

constructions are:

22

“Process bound to a destination port number”

NPS’ PROPOSED CONSTRUCTION

FORTINET’S PROPOSED
CONSTRUCTION

23
24
25

Plain and ordinary meaning; or

Proxy process that is bound to the port
on the gateway that matches the
destination port number of the
incoming packets.

Process assigned or linked to a
destination port number.

26

or:

27

Proxy process bound to a destination
port.

28
12

1
2
3

This order construes “process bound to a destination port number” as meaning a “process
assigned to a destination port number.”
The parties do not appear to dispute the “destination port number” component of the

4

term, and the parties did not address the issue in their briefs or at oral argument. Fortinet

5

nevertheless provides a proposed construction for this element. Fortinet’s construction defines

6

“destination port number” as “the port on the gateway that matches the destination port number

7

of the incoming packets.” Compared with a plain meaning construction, Fortinet’s proposal for

8

this segment is wordy and potentially confusing. Fortinet also does not explain why explication

9

of “destination port number” is necessary.
The parties’ dispute involves two issues. First, they dispute whether “process” must be

11
For the Northern District of California

United States District Court

10

construed to refer to a “proxy process.” This is the focus of the parties’ dispute over this term,

12

both in the briefing and at oral argument. Here, Fortinet again offers its unsubstantiated

13

contention that the patent taught a “proxy everything” environment. Fortinet further contends

14

that the intrinsic evidence shows that “process bound” always meant a “proxy process.”

15
16
17

What Fortinet’s contentions do not account for is how the term was actually used in the
claims. The disputed term appeared in claim 1 in the following clauses:
(c) determing at the gateway whether there is a process bound to
a destination port number of an accepted communications packet;

18
19
20
21
22
23
24
25

(d) establishing transparently at the gateway a first
communications session with a source address/source port of the
accepted communications packet if there is a process bound to the
destination port number, else dropping the packet;
(Col. 14:23–29 (emphasis added).) In claim 10, the term was used differently:
(c) determining whether there is a proxy process bound to a port
for serving a destination port number of an accepted TCP/IP
packet;
(d) establishing a first communications session with a source
address/source port number of the accepted TCP/IP packet if there
is [sic] proxy process bound to the port for serving the destination
port number, else dropping the packet;

26
(Col. 15:56–64 (emphasis added).) In claim 11, there was another variation.
27
28

11. A method . . . as claimed in claim 10 wherein the step of
determining involves checking a table to determine if a custom
proxy process is bound to the destination port number, and
13

1

passing the packet to a generic proxy process if a custom proxy
process is not bound to the destination port number . . . .

2
(Col. 16:15–20 (emphasis added).) The reader will note the progression: a “process” was
3
claimed in claim 1, but a “proxy process” and a specific type of “proxy process” appeared in
4
claims 10 and 11, respectively. It seems clear that the drafter intended to refer to different types
5
of processes being bound. Fortinet’s construction of the disputed term to mean “proxy process”
6
in claim one would therefore require reading a limitation from the specification into the claims,
7
or limiting a broader claim based on subsequent narrower claims. This would be improper.
8
Fortinet’s construction would also render the language in claims 10 and 11 that specifies a
9
“proxy process” superfluous.
10
should be understood to refer specifically to the UNIX “bind” command but does not propose to
For the Northern District of California

United States District Court

Second, the parties dispute the meaning of the word “bound.” Fortinet asserts that bound
11
12
include that limitation in the construction. Instead, Fortinet asserts that a POSA would have
13
considered the ordinary meaning of the term bound to mean the bind command.
14
It is useful to note at this point that Fortinet’s assumption of a UNIX environment is
15
faulty. It is true that the patent used UNIX to describe an embodiment of the patent (see cols.
16
9:41–10:24). However, the claims of the patent were not limited to the UNIX operating system.
17
For example, claim 19 described an apparatus that included “an operating system executable by
18
the gateway station, a kernel of the operating system having been modified . . .” (col:17:41–50
19
(emphasis added)). Claim 20, which was dependent on claim 19, covered an apparatus “wherein
20
the operating system [was] a Unix operating system” (col. 18:9–12).
21
NPS also wishes to use the ordinary meaning of the term “bound,” but disagrees that it
22
must include the UNIX bind command. NPS offers “assigned or linked” as an alternative
23
meaning for “bound.” NPS cites several places in the specification where the term “assigned” is
24
used in relation to the concept of something being “bound,” but does not cite any support in the
25
specification for “linked.” The use of the term “assigned” to explain “bound” is evident.
26
“Linked” is not.
27
Upon review of Fortinet’s critique, it remains clear that only the word “bound” in the
28
disputed term requires a construction. Helpfully, the patent itself provided a definition:
14

1

On system initialization, any proxy given operating rights by the
system administrator is said to “bind” to the port to which the
proxy has been assigned. Thereafter, the process is said to be
“bound” to the port.

2
3

(Col. 9:54–57.) Fortinet argues that this was not a definition, but rather a factual description of a
4
series of events: the system initialized, and then a process assigned to a port was subsequently
5
bound in the sense of the UNIX “bind” command. This reading is not justified from the plain
6
language of the patent, and is premised on Fortinet’s unduly narrow assumption that the patent
7
required a UNIX environment.
8
In its critique, Fortinet argues that the above quote from column 9 of the patent requires
9
that the term bound include the concept of “operating rights.” Fortinet thus proposes “assigned
10
construction for bound. This construction is rejected. Column 9 also states “[w]hen the gateway
For the Northern District of California

United States District Court

to and given operating rights with respect to a specific communications port” as an alternative
11
12
station 14 is initialized, the generic proxy binds to port 59813, provided that the systems
13
administrator has given it operating rights to do so” (col 9:61–64 (emphasis added)). Fortinet’s
14
new construction renders the final clause in this sentence superfluous.
15
Accordingly, this order retains the tentative construction: “process bound to a destination
16
port number” should be construed as meaning a “process assigned to a destination port number.”
17
E.

“Transparently”

18
The parties dispute the term “transparently.” The parties’ proposed constructions are
19
shown below:
20
21

NPS’ PROPOSED CONSTRUCTION

22

Such that clients on networks can run
network service applications without
extra procedures or modifications to
accomplish communications across a
gateway.

23
24

FORTINET’S PROPOSED
CONSTRUCTION
Appearing to the initiator to be one
direct communications session.

25
26

This order adopts Fortinet’s proposed construction of “transparently”: “appearing to the

27

initiator to be one direct communications session.” Fortinet cites multiple instances in the patent

28

specification and in the declaration of NPS’ expert during reexamination where “transparently”

15

1

was defined in this manner or explained in terms of whether the communications session appears

2

to be direct.

3

NPS objects on several grounds, none of which are persuasive. First, NPS argues that

4

this construction is improper because it defines the term with a description of the subjective

5

result of the claimed method. NPS cites West v. Quality Gold, Inc., No. 10-3124, slip op. at

6

9–10 (N.D. Cal. Sept. 16, 2011) (Judge Jeremy Fogel), for the proposition that claims should not

7

be defined by the subjective opinion of an individual practicing an invention. NPS’s reliance on

8

West is misplaced. NPS conflates subjective opinion with a subjective experience of an

9

objective fact. Unlike the phrase “pleasing appearance” in West, “transparency” in Fortinet’s
proposed construction does not require a subjective evaluation. Whether a communication

11
For the Northern District of California

United States District Court

10

session appears to be direct is only based on whether there is an objectively perceptible

12

intermediary. An intermediary either appears and is perceived by the client, or it does not. This

13

does not require a subjective opinion.

14

Second, NPS asserts that the patent specification stated that “communications are said to

15

be transparent because the client . . . does not have to run extra procedures or modify the

16

network source code.” NPS’ paraphrase misstates the patent language. The full section cited by

17

NPS stated:

18
19
20

The apparatus in accordance with the invention is, however,
configured to provide a transparent interface between the
interconnected networks so that clients on either network can run
standard network service applications transparently without extra
procedures, or modifications to accomplish communications
across the secure gateway.

21
(Col. 6:28–34.) NPS’ interpretation of this passage improperly turns the last 12 words into an
22
explanation of the word “transparently.” The passage did not state that the network service
23
applications were transparent because they were run without extra procedures or modifications.
24
Rather, transparency was one of three distinct characteristics of network service applications in
25
the patented invention. Further, Fortinet’s proposed construction allows this passage to be read
26
without rendering the last 12 words in the sentence redundant.
27
Third, NPS points out that during reexamination, Fortinet’s proposed definition of
28
transparently was something more akin to NPS’ current construction, and that Fortinet has since
16

1

changed its tune. At the time, Fortinet was pushing to define transparency as not requiring a user

2

login. This is similar to NPS’ current proposal, which references “extra procedures” that NPS

3

argues applied to user logins.

4

Despite this similarity, Fortinet’s prior position is materially different from NPS’ current

5

construction. NPS’s construction not only references extra procedures, it also references

6

“modifications.” Fortinet’s prior position and NPS’ current position are thus not directly

7

comparable. The fact that Fortinet previously relied on a materially different construction casts

8

doubt over Fortinet’s current position, but it does not help NPS in equal measure. Nor is there

9

any basis to deem Fortinet estopped from advancing a different position in this proceeding.
At oral argument, NPS’ counsel stated they would accept the same definition of

11
For the Northern District of California

United States District Court

10

transparently that Fortinet advanced during reexamination. However, the record in this action

12

did not contain adequate briefing on that construction. Based on the available evidence, the

13

tentative claim construction order adopted Fortinet’s proposal for “transparently” — “appearing

14

to the initiator to be one direct communications session” — and invited the parties to address the

15

issue of Fortinet’s contention at reexamination in their critiques.

16
17

Both parties agree with the tentative construction in their critiques. This order holds that
no modification is necessary.

18

F.

19

The parties dispute the term “accepting at the gateway.” The parties’ proposed

20

“Accepting at the gateway”

constructions are provided below:

21
22
23
24
25
26
27
28
17

1

NPS’ PROPOSED CONSTRUCTION

FORTINET’S PROPOSED
CONSTRUCTION

2

4

Allowing received packets to be
processed by the gateway even though
the packets designate an IP destination
address other than that of the gateway.

5

or (at oral argument):

6

Allowing received packets to be
processed by a gateway with
application level security and data
screening capability even though the
packets designate an IP destination
address other than that of the gateway.

3

7
8
9

This order holds that the ordinary meaning of the term to a POSA in 1994 should govern.

11
For the Northern District of California

United States District Court

10

Retaining for further evaluation and
processing at the application level
network gateway.

Although the parties do not recognize their common ground, they agree that “accepting at the

12

gateway” meant “receiving” packets at the gateway instead of rejecting them. This is simply a

13

plain meaning construction of the term, and it is supported in particular by Figure 6 in the patent,

14

which showed the first packet processing step on a UNIX embodiment as “receive data packet.”

15

Moreover, at oral argument both parties agreed that a plain meaning construction would be

16

acceptable to them.

17

This order agrees that a plain language construction charts a better course. Both parties’

18

constructions attempt to read in additional limitations to the claim term, but neither provides an

19

adequate justification for doing so. Fortinet’s construction adds the additional element of

20

“retaining for further evaluation.” It is clear from the claim language and from Figure 6 of the

21

patent, however, that the disputed term only referred to the first step in the packet processing

22

process, and not to retention after receipt. Fortinet’s construction is also ambiguous because it is

23

not clear whether “retaining” refers to receipt at the application level network gateway, or receipt

24

at the gateway before being retained for processing at the application level.

25

NPS attempts to include a limitation based on the IP destination address of the packet.

26

NPS does not explain why this limitation should be read into the claim and did not address this

27

issue at oral argument. The closest NPS comes to justifying this position is its assertion that

28

language in the patent supports the interpretation that the gateway would accept packets
18

1

regardless of their IP address. This is equivalent to arguing that accepting packets regardless of

2

IP destination address was an implied result of the other claims. It does not justify adding an

3

additional concept to the definition of the claim term.

4

Neither party has justified their constructions, and this order shall hold the parties to their

5

common ground at oral argument: the plain meaning of the term to a POSA in 1994 shall

6

govern.

7

CONCLUSION

8

The constructions set forth above will apply in this action. The Court reserves the

9

authority, on its own motion, to modify these constructions if further evidence warrants such a
modification (but counsel may not move to reconsider them). The Court thanks counsel for their

11
For the Northern District of California

United States District Court

10

efforts in illuminating the meaning of the foregoing terms.

12
13

IT IS SO ORDERED.

14
15

Dated: January 14, 2013.

WILLIAM ALSUP
UNITED STATES DISTRICT JUDGE

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