Invalidity Opinion

8/9/2019 Invalidity Opinion

http://slidepdf.com/reader/full/invalidity-opinion 1/232

IN THE UNITED STATES DISTRICT COURT

CENTRAL DISTRICT OF CALIFORNIA

WESTERN DIVISION - LOS ANGELES

NOMADIX, INC.,A Delaware Corporation

§

Plaintiff, §

§

vs. § Civil Action No. CV 07 1946 GPS

§ (VBKx)

§ Honorable Dean D. Pregerson

§

SECOND RULE LLC,

A Delaware limited liability company, §

§Defendant §

EXPERT REPORT OF PETER ALEXANDER, Ph.D.

REGARDING INVALIDITY OF

U.S. PATENTS NOS. 6,130,892, 6,636,894, 6,868,399, 7,088,727, 6,857,009

Oct. 31, 2008

1 INTRODUCTION AND BACKGROUND

I understand that plaintiff Nomadix, Inc. (“Nomadix”) accuses defendant Second Rule

LLC. (“Second Rule”) of infringing U.S. Patent Nos. 6,130,892 (“‘892 patent”), 6,636,894

(“‘894 patent”), 6,868,399 (“‘399 patent”), 7,088,727 (“‘727 patent”) and 6,857,009 (“‘009

patent”) (collectively “patents-in-suit”).

I have been retained by Second Rule as a technology expert to offer opinions regarding

validity of the patents-in-suit. I have reviewed the patent in suit along with the prosecution

histories and other relevant documents in forming opinions expressed in this report.



2

2 QUALIFICATIONS

My academic credentials include a Ph.D. from the Massachusetts Institute of Technology

in Electrical Engineering, a Masters degree from the University of Illinois (Urbana) in Electrical

Engineering, and a Bachelor of Science in Electrical Engineering from the University

Canterbury, New Zealand. My Curriculum Vitae, including a list of all cases in which I have

testified during the past four years, is attached as Attachment B.

The patents-in-suit claim inventions involving computer networking. My professional

experience in this area is extensive. I have 3 years of software design and development

experience involving networking products such as routers, bridges and gateways. From 1989

through 1992, in my capacity as the leader of a software development group at Fibronics

International, Inc., I was responsible for the creation of source code for use in products that

provided Internet layer services to other software products. Specifically, I was responsible for

the development of core Internet software protocols, such as Transport Control Protocol (“TCP”)

and Internet Protocol (“IP”), as well as higher level computer applications such as Domain Name

Services (“DNS”), File Transfer Protocol (“FTP”), Network File System (“NFS”), and Telnet

services.

The IP software included functional components such as Address Request Protocol

(“ARP”), Reverse Address Resolution Protocol (“RARP”), and Internet Control Message

Protocol (“ICMP”).

In addition I was involved with the design of software for Local Area Network (“LAN”)

bridges that carried diverse, multi-protocol traffic such as Appletalk and Novell IPX, so I also

have a broader understanding of other network protocol families.

Subsequent to this direct involvement with the design of software for bridges, routers and

servers, I have gained substantial experience with network engineering for corporate local area

networks (“LANs”) and Wide Area Networks (“WANs”). For example, from 1997 to 2003 I

was responsible for the implementation of LAN and WAN networks configured with commercial



3

products such as firewalls, load balancers, web servers, application servers, routers, layer 2

switches, and client-server applications generally.

During this period I was typically responsible for corporate networks and I managed

Information Technology (“IT”) staffs of around 10-20 people. The specific companies involved

were Syntricity, Inc., InfrastructureWorld.com, CareerPath.com and Platinum Software

Corporation. My experience includes network configurations for file servers, email servers,

firewalls, routers, layer 2 switches, Java application servers and web servers.

As a result of my involvement with the design of these networked components I am also

well versed in the computer source code for open source software systems such as the Linux

operating system, Apache web server, and the Tomcat application server.

3 METHODOLOGY USED

I am not an attorney and do not have extensive study in the law regarding patents.

Representations I make regarding the law are as I understand the law to be as explained to me by

the lawyers for defendant Second Rule. I will use my understanding of these legal principles to

analyze the alleged invalidity of the asserted claims of the patents-in-suit.

3.1 Claim Construction

According to basic principles of patent law, a determination of patent validity is a two-

step process: First, the claim language must be construed to determine its scope and meaning.

Second, the construed claim must be compared to the alleged prior art to determine whether the

claim is valid.

I understand that the Court held a claim construction hearing on September 19, 2008 for

the purpose of understanding and construing the disputed claim terms of the patents-in-suit. I

also understand that the Court issued its Claim Construction Order on October 15, 2008. In the

event that the Court provides additional constructions, I reserve the right to supplement, modify

or amend my report as necessary.



4

3.2 Validity of Patents

Although patents are presumed to be valid, this presumption can be overcome by clear

and convincing evidence. This can include evidence of anticipation of the patent, or evidence of

obviousness.

3.2.1 Anticipation

A patent claim is invalid if the claimed invention is anticipated, i.e. not new. See 35

U.S.C. § 102. For a claimed invention to be invalid because of anticipation, one must prove by

clear and convincing evidence that all of claimed elements are present in a single prior art

reference or in the public knowledge either before the applicant’s invention date, or more than

one year before the applicant’s filing date. Id.

3.2.2 Obviousness

A person is not entitled to a patent if the differences between the claimed invention and

the related prior art are such that the claimed invention as a whole would have been obvious to a

person of ordinary skill in the art at the time the invention was made. See 35 U.S.C. § 103. A

purported combination of references must include every element of the claimed invention and

cannot change the principle of operation of the primary reference or render the reference

inoperable for its intended purpose.

Obviousness is a determination of law based on various underlying determinations of

fact. In particular, these underlying factual determinations include (1) the scope and content of

the prior art; (2) the level of ordinary skill in the art at the time the claimed invention was made;

(3) the differences between the claimed invention and the prior art; and (4) the extent of any

proffered objective indicia of non-obviousness.

To ascertain the scope and content of the prior art, I have examined the field of the

inventor’s endeavor and the particular problem with which the inventor was involved at the time

the invention was made. I have also considered only the knowledge that was within the level of



5

ordinary skill at the time the invention was made, and not any knowledge gleaned from the

applicant’s disclosure.

3.3 Prior Art

It is my understanding that only information that satisfies one of the categories of prior

art under 35 U.S.C. § 102 may be used in any invalidity analysis under §§ 102 or 103.

Therefore, if the information is not properly classified as prior art under one of the subsections of

35 U.S.C. § 102, it may not be considered in an anticipation or obviousness determination.

3.3.1 35 U.S.C. § 102 Requirements for Prior Art

According to 35 U.S.C. § 102, an invention is considered “prior art” if it:

(1) was known by others in this country before the invention thereof by the applicant forpatent (35 U.S.C. § 102(a));

(2) was used by others in this country before the invention thereof by the applicant forpatent ( Id.);

(3) was disclosed in a patent or other printed publication in this or a foreign countrybefore the invention thereof by the applicant for patent ( Id.);

(4) was patented, described in a printed publication, in public use or on sale in thiscountry for more than a year prior to the date of the application for patent in the UnitedStates (35 U.S.C. § 102(b));

(5) was a patent granted on an application for patent by another filed in the United Statesbefore the invention date of the patents-in-suit. (35 U.S.C. § 102(e)); or

(6) was made in this country by another inventor who had not abandoned, suppressed, orconcealed it (35 U.S.C. § 102(g)).

3.3.2 The Invention Date

In order to determine what makes art “prior” art, with respect to some reference, one

must consider the “invention date” of the inventions at issue. Generally, the invention date of an

invention is the effective filing date of the patent. This is referred to as a “constructive reduction

to practice.” However, an earlier invention date may be established by proving that each and

every element of the claimed invention was conceived of at an earlier time, and that reasonable



6

diligence was use to reduce that conception to practice. This is referred to as “actual reduction

to practice.” Actual reduction to practice occurs when there is physical verification that the each

and every element of the conceived invention works for the intended purpose.

It is the patent owner’s burden to establish an earlier invention date than the effective

filing date of the patent. This may take the form of corroborating contemporary evidence, and

may not rest upon the testimony of the alleged inventor alone. I understand that Nomadix has

made some contentions regarding their invention dates, some of which I dispute. I understand

that a dispute between the parties has arisen with respect to Nomadix’s invention date

contentions. I reserve the right to supplement this report or submit a replacement invalidity

report, which would substitute for this report, if Nomadix attempts to assert earlier invention

dates than those listed in response to Second Rule’s Interrogatory No. 7.

3.3.3 Enablement

A reference must describe the claimed invention sufficiently to enable a person of

ordinary skill in the field to practice the invention. This entails that the reference disclose each

and every element of the claimed invention, either explicitly or inherently, with sufficient clarity

as to establish that the subject matter existed and that its existence was recognized by person of

ordinary skill in the field of the invention. An element is inherently disclosed if extrinsic

evidence (evidence other than the asserted prior art reference) makes clear that the missing

element is the inevitable outcome of the process and/or thing that is explicitly described in the

asserted prior art reference and that it would be recognized as necessarily present by persons of

ordinary skill in the relevant field. I understand then that an element is not inherently disclosed

by mere possibilities, probabilities or the mere fact that a certain thing may result from a given

set of circumstances.



7

3.3.4 Printed Publications

In order for a document to constitute a “printed publication” under 35 U.S.C. § 102 and

thus qualify as possible prior art, that document must be reasonably accessible to that portion of

the public most likely to use it (although it is not necessary that the publication be available to

every member of the public). The date that a printed publication becomes prior art is the date

that it becomes available to the public. Thus, for prior art purposes, publications may include not

only such things as books, periodicals or newspapers, but also publications that are not as widely

available to the public, such as trade catalogues, journal articles or scholarly papers that are

distributed or available to those skilled in the field of the invention. If a printed publication was

published more than one year before the application for the patent was filed, then that publication

will be prior art, regardless of the date of invention for the patent claims. See 35 U.S.C. §

102(b).

3.3.5 Prior Art in Determination of Obviousness

Even though a prior art reference may not fully anticipate a claim of a patent, it may

nevertheless render the patent claim obvious to one of ordinary skill in the art if the differences

between the subject matter set forth in the patent claim and the prior art are such that the subject

matter of the claim as a whole would have been obvious at the time the claimed inventions was

made. See 35 U.S.C. § 103.

As stated above, obviousness is a determination of law based on various underlying

determinations of fact. Objective indicia may be considered in such an analysis, including

commercial success of the patented invention, evidence of industry recognition or rewards,

whether the invention fills a long-felt but unresolved need in the field, evidence of copying,

unexpected results, and initial skepticism in the field. I am not presently aware of any

contentions by Nomadix that any of these factors are to be applied in an obviousness context.

Furthermore, there must be some evidence within the prior art as a whole to suggest the

desirability of making the combination in such a way that would produce the patented invention.



8

3.4 Written Description and Enablement Requirements

One is not entitled to a patent under 35 U.S.C. § 112 ¶ 1 if the patent’s specification does

not provide a written description of the invention in such full, clear, concise and exact terms as to

demonstrate to the public that the inventor was in possession of the invention at the time the

application for patent was made, and to enable any person skilled in the art to which it pertains to

make and use the claimed invention.

In addition, it is my understanding that the question of whether a patent claim meets the

written description and enablement requirements of 35 U.S.C. § 112 must be viewed from

perspective of any person having skill in the art. It is my understanding that to satisfy the written

description requirement a patent applicant must provide a disclosure such that any person having

skill in the art would believe the inventor was in possession of the claimed invention at the time

the patent application was filed. In other words, the written description requirement is satisfied

when the text and the drawings of the patent specification, taken as a whole, convey with

reasonable clarity to any person having skill in the art that the inventor was in possession of the

claimed invention at the time the patent application was filed. I understand that the specification

is not required to use the identical wording of the claims. I also understand that the patentee is

required to enable any person having skill in the art to make and use the full scope of the claimed

invention.

3.5 Definiteness

35 U.S.C. § 112 ¶ 2 of the Patent Act requires that a claim “particularly point out and

distinctly claim[] the subject matter which the applicant regards as his invention.” Whether a

claim particularly points out and distinctly claims the subject matter of an invention depends

upon whether a person of ordinary skill in the art would understand what is being claimed,

including the bounds of the claim, read in light of the specification. If a person or ordinary skill

in the art would understand when a claim element is satisfied, then the claim is sufficiently

definite.



9

A claim is indefinite if one skilled in the art would not understand the scope of the claim

when read in light of the specification. The definiteness requirement focuses on whether the

claims, as interpreted in view of the written description, adequately perform their function of

notifying the public of the scope of the patentee’s right to exclude. It is my understanding that

one purpose of the definiteness requirement is to prevent the patentee from broadening the

claims to include devices that he considers to be infringing, or narrow the claims to avoid prior

art, simply by interpreting the claims in the manner best suited to his particular purpose.

4 LEVEL OF ORDINARY SKILL

I was asked to give an opinion as to the educational and/or vocational qualifications of

one of ordinary skill in the subject matter taught by the patent at the time of the invention. In the

1998-2000 time period covering the application filing dates of the patents-in-suit, as well as the

timeframe of 2000 – 2005 covering the issue dates when an artisan might practice the inventions,

a hypothetical person of ordinary skill in the art to whom this patent is addressed would have had

a range of knowledge roughly equivalent to the knowledge and/or training of a person holding

the degree of Bachelor of Science in Electrical Engineering, Computer Science, or Computer

Engineering, or someone who has had one or two years experience in the design of networked

computer systems involving the configuration of client computers, server computers, and

networking subsystems such as gateways, routers and switches.

In reaching this opinion as to the qualifications of the hypothetical person of ordinary

skill in the art, I have considered the types of problems encountered in the art, the prior art

solutions to those problems, the rapidity with which innovations are made, the sophistication of

the technology, and the educational level of active workers in the field.



10

5 BACKGROUND ON NETWORKING

5.1 Overview

Computer networks utilize communications protocols in order to provide compatible

interoperation of products from various vendors. The concept of “protocol” in networking has

the same general meaning it does in ordinary life: A protocol is an agreement between parties to

follow certain rules and pre-defined policies in order to accomplish a common goal. For

example, if you want to connect one computer to another, both of the communicating computers

must “speak the same language.” A communications protocol provides the understanding of

vocabulary, grammar and syntax required for successful communication.

In networking the goal is successful interoperability of products. There are hundreds of

diverse protocols in existence, with numerous categories of different protocols. Protocols are

grouped into families that are meant to be used in a self-contained manner, just as different

nationalities may use different languages. Within a particular protocol family, different protocol

components serve different purposes.

Networking protocols are therefore usually described in terms of “protocol stacks,” which

can be visualized as layers of different functionality for a particular family of networking. The

layers of a protocol stack for any particular protocol family can be divided into four broad

categories, each of which serves a different need1. Those categories are: (1) Data Link Layer; (2)

Network Layer; (3) Transport Layer; (4) Application Layer. See figure 1 below2.

Figure 1 below depicts the flow of data packets through the Internet. As shown, a client

computer can send application data, such as a request for a web page, to a server at a remote

location. The originating application data is passed through the TCP Transport Protocol Layer,

and then through the IP Network Layer. The packet then passes through the Data Link Layer

1 The following discussion applies to packet switched networks, as claimed in the patents-in-suit.

2 The four category classification in this declaration is a simplified version of the normal seven layer network stack usually discussed in text books and standards.



11

where it is handed off to a physical device such as an Ethernet card. From there it is routed

across the Internet by passing it through a succession of intermediate computers called routers.

IP Network Layer

TCP Transport Layer

Data Link Layer

Internet

Application Layer(e.g., email client, web browser)

IP Network Layer

TCP Transport Layer

Data Link Layer

Application Layer(e.g., mail server, web server.)

Application data

TCP packet data

Client computer Server computer

Application data

Figure 1. Packet flow through the Internet Protocol Layers.

At each layer level address and control information specific to that protocol layer is

added to the packet. For example, Data Link Layer protocol information provides a way of

transferring the packet between devices on a Local Area Network (“LAN”), whereas the

Application Layer protocol information will include application specific parameters such as the

name of a web page being requested. Certain other protocols, such as Address Resolution

Protocol (“ARP”) provide a mechanism for the exchange of information between two computers

on a LAN.

At the receiving end, or remote computer, the contents of the packet are extracted as the

packet moves up through the protocol stack until the Application Layer receives the packet

“payload.” The remote server computer will typically send response packets back to the client

computer in the same manner, resulting in the client Application Layer receiving content from

the remote computer, e.g., a web page to be rendered in a web browser.



12

Each of the protocol layers has a distinct function to perform: Data Link Layer protocols

provide a mechanism for moving data packets around on a LAN. Network Layer protocols

provide for addressing of computers beyond a single LAN over much greater distances, and

Transport Layer protocols are concerned with the “transportation” of data from one computer to

another. Application Layer protocols provide for higher level activities such as processing the

request for a web page from a web browser. In the scenario depicted in the figure, a browser is

an Application Layer software component that uses the Network Layer protocol to provide a

mechanism for locating the web server, while the Transport Layer protocol is used to convey the

web page request to the located web site. Once the TCP connection has been set up, the

Application Layer protocol (e.g., HyperText Transport Protocol (“HTTP”)) allows a

conversation to be carried out between the browser and the web server.

5.2 Standards for Networking Protocols

Networking specifications and standards for different protocol families have often been

the result of vendor-specific designs. In contrast, the Internet software development community

has formulated standards though a collaborative, peer review process.

The technical specifications for protocols (such as TCP, IP and ARP) used in the Internet

have traditionally been created through a collaboration procedure called “Request for

Comments,” otherwise known as “RFCs.” When the Internet development community

converges on agreement for a set of technical specifications, an authoritative version of the RFC

is published as a standard. See, e.g., RFC 793 for the TCP protocol and RFC826 for the ARP

protocol.

The TCP/IP protocols were developed from work begun in the 1970s by engineers with

the Defense Advanced Research Projects Agency (DARPA). The first TCP specification was

published in 1974. The RFCs corresponding to the current Internet implementation were

published as standards in 1981 and 1982. The family of Internet protocols that includes TCP, IP

and ARP has been a standard for all military computer networking in the United States since



13

then, and it has evolved as the primary standard used in civilian network communications as

well. Today, there are more than 165 million web sites on the World Wide Web. Every time a

user visits any of these web sites, the TCP and IP protocols handle the computer-to-computer

communications these transactions require.

5.3 Data Link Addresses

Data Link Layer protocols primarily use a computer’s assigned “device” address when

facilitating communication between two or more computers on a LAN. A LAN address is

usually referred to as a computer’s “physical address.” There are numerous different LAN or

Link Layer protocols. They include, for example, X.25, Ethernet, Token Ring, Novell LLC, and

AppleTalk LocalTalk.

A computer’s LAN address (for a particular networking protocol family) is permanently

assigned to a computer3 and moves around with the computer. For example, when a person takes

a computer from their office to a hotel, the assigned Data Link Layer LAN address of the

computer is carried with the computer and does not change despite a change of physical location.

5.4 Network Layer Addresses

Although there are many different types of networks, this discussion will focus on the

Internet network layer protocol for simplicity. The Internet’s network layer is responsible for

providing a unified addressing scheme for all computers connected to the Internet across the

world and uses IP addresses assigned to each and every communicating computer to do so.

However, in contrast to the physical address discussed earlier, the computer’s IP address may be

assigned dynamically as the computer is moved geographically.

This occurs because individual Internet Service Providers (“ISPs”) are given blocks of IP

addresses for their own customers. In order to gain service through a particular ISP, a user must

3 For example Ethernet LAN addresses are assigned (uniquely) to individual Ethernet chips during themanufacturing of a computer. They do not change thereafter.



14

be in possession of one of the IP addresses allocated to that service provider. Hence, as a person

moves from an office to a hotel, the assigned IP address will generally have to change with the

physical location to accommodate the new service provider. The reason for such a restriction is

that ISPs can only succeed at sending and receiving Internet data packets to other ISPs if their

own addresses can be found in a predictable way.

This is analogous to the common use of zip codes. When a person visits Massachusetts

from California they have to use a different zip code in order to receive forwarded mail. The US

Postal Service knows how to route mail between different zip codes. Similarly, Internet packets

are routed from one router to the next across the Internet from one ISP to another through a

series of known paths that link the different ISPs IP address groups.

In summary, computers are typically assigned an IP address on a temporary basis

depending on the location of the office, hotel or residence they are being used in at a particular

point in time. That IP address is provided by the local ISP. On the other hand, the Data Link

Layer LAN address of a computer is invariant, and is typically fixed for the lifetime of the

computer. When the IP address is dynamically assigned by the local ISP, the final step in the

communication path requires knowledge of the computer’s (fixed) physical address on a LAN.

Thus, the correspondence between a computer’s physical address and its current IP address must

be learned.

This summarizes the problem that the patents-in-suit discuss: How to communicate with

portable computers whose Network Layer addresses (e.g., IP for the Internet) change as the

computer is moved from place to place.

5.5 Address Resolution Protocol (“ARP”)

A special protocol is provided for the purpose of determining the correspondence

between a computer’s physical address and its current IP address. It is called Address Resolution

Protocol (“ARP”).



15

This protocol, technically belonging to the Network Layer of a stack, is concerned with

finding the association between IP address and the physical LAN address of a computer.

Specifically, computers attached to a LAN can ask all other computers listening on the LAN to

reply if they have been assigned a particular IP address. This is necessary because if an ISP

receives a packet of data for IP address 203.16.1.101, it must find the computer currently

assigned that address and determine its physical address in order to move the packet into the

computer.

ARP is part of the Internet protocol suite. There are other protocol suites for other

network families. For instance for AppleTalk, the equivalent protocol is AppleTalk Address

Resolution Protocol (“AARP”).

5.5.1 ARP Request Packet Structure

The ARP request and ARP response packets have a standard format4. The packet is

structured as a packet header that is separate from the packet “payload.” The “payload”

represents data being delivered to various network nodes based on the node addresses in the

packet header.

An ARP request packet header includes the sender’s MAC address in the Ethernet

header, as well as the LAN broadcast address (all 1s) for the Ethernet destination address. The

ARP request packet data includes the sender’s MAC address, sender’s IP address, and target IP

address.

4 See Stevens, TCP Illustrated Volume 1, page 56 and RFC 826 “Packet Format” section.



16

See Stevens Figure 4.3 at page 56.

For the ARP request packet, the “target Ethernet addr” field is empty or meaningless. A

node responding to the ARP request replies with its own MAC address in the payload (and in the

in the Ethernet header), i.e., the payload of an ARP packet includes modified data. For a

response from a Proxy ARP node, the response packet includes the MAC address of the

responding ARP node as the “source MAC” address. In this situation, data in the original ARP

request packet is modified.

5.5.2 ARP Response Packet Structure

The packet structure reproduced from Stevens Figure 4.3 shown above is the same for

both ARP Requests and ARP Responses. The “broadcast host” sets the destination MAC

address to all 1s as a broadcast. Stevens shows the details of a typical ARP Request/Response

exchange.

See Stevens at page 58.



17

When the ARP Request packet is processed by a “responding host,” the following

transformations take place in the various fields indicated:

Packet Header:

Ethernet destination addr-> replaced by the “broadcast host” Ethernet addr.

Ethernet source addr-> replaced by the “responding host” Ethernet addr.

Packet Body:

target Ethernet destination addr-> replaced by the “broadcast host” Ethernet addr.

sender Ethernet destination addr-> replaced by the “responding host” Ethernet addr.

target IP addr-> replaced by the “broadcast host” IP addr.

sender IP addr-> replaced by the “responding host” IP addr.

Therefore, when a node responds to an ARP request with a response packet, the source

MAC field contains the MAC address of the responding ARP node itself, not that of the

requesting device. Similarly, the response packet “target MAC address” contains the MAC

address of the requesting device.

5.6 Domain Name Services (“DNS”)

Just as is the case for telephone numbers, a directory assistance service is provided on the

Internet to let a computer ask for the IP address corresponding to the name of a computer server,

such as “www.yahoo.com.” This service is called Domain Name Service (“DNS”). If a user

located in a hotel room needs to access the Yahoo web site, his computer must first find the IP

address of the name www.yahoo.com.

The DNS protocol is yet another application-level protocol used on the Internet. It uses

lower level protocols such as TCP and IP to send a packet to a particular server that offers the

directory lookup service. See RCF 1034 and RFC 1035. The response packet from the DNSserver contains an IP address as the answer to the question regarding the “www.yahoo.com”

address. In this situation, when the packet arrives back at the requesting computer it contains

three types of address: two Data Link Layer addresses corresponding to source and destination



18

LAN addresses; two Network Layer addresses corresponding to source and destination IP

addresses; and the DNS lookup address.

5.7 Dynamic Host Control Protocol (“DHCP”)

When a user arrives at a new physical location and connects to a network, there must be a

way for the computer to get assigned a new IP address from the local service provider. For many

years this was a manual step – a person at the ISP would be asked to assign a particular IP

address and the user would type that address into the portable computer. The burden of manual

entry was eliminated with the advent of the Dynamic Host Configuration Protocol (“DHCP”) in

19935.

DHCP solves the fundamental problem of automatically giving a mobile computer an IP

address that is valid on the ISPs network. A special DHCP server is set up on a network, usually

on the same LAN as a computer that needs to be given an IP address. The DHCP involves

special “bootstrap” protocols that allow the portable computer to locate an available DHCP

server and ask it to provide an IP address. Having a valid IP address allows the portable

computer to participate in communications across the Internet because the rest of the Internet

computers know how to reach the ISP.

DHCP severs usually have possession of an assigned block of IP addresses that is fewer

in number than the number of client computers they service. In the simplest scenario, the DHCP

server “leases” an IP address to any client computer that needs one. However, the lease expires

after a day or two so the previously allocated IP address can be re-used by other active client

computers.

5 RFC 1541 outline the DHCP protocol in 1993 and RFC 2123.



19

5.8 Network Address Translation (“NAT”)

The total number of available IP addresses6 is surprisingly small, being fewer than the

number of people on the planet. To compound the difficulties, IP addresses are assigned in

blocks and are not used efficiently. Some corporations may not be using all of their assigned

addresses.

The Internet development community has reserved three blocks7 of restricted `IP

addresses– meaning they are not published as addresses that can normally be reached by

computers on the Internet. These blocks are used by organizations such as ISPs and corporations

for their internal use. The mechanism for transmitting packets between external networks and

internal networks is referred to generally as ‘Network Address Translation” (“NAT”).

The NAT methodology was introduced in the early 1990s. See RFC 1631. It would be

well known to one of ordinary skill in the art that NAT provides a means for automatically

modifying packets transmitted from a computer trying to communicate beyond a NAT router.

The concept of NAT was introduced to expand the total number of available IP addresses on the

Internet by re-using these blocks of “restricted” addresses over and over again. Since they are

not visible on the Internet that re-use is feasible.

NAT operates by presenting a single or small range of addresses to the Internet (the

router “external” address). Behind the NAT router will be a much larger group of computers that

use one of the reserved IP address blocks. These addresses are not recognized by the rest of the

Internet. A computer behind the NAT router is assigned an “inside” IP address by the NAT

router. When that computer makes a request that must be sent out on the Internet, the NAT

router takes the computer’s “inside” address and replaces it with its own “outside” address8

.

6 For simplicity this discussion is limited to IPv4. IPv6 offers a vastly increased address space but is not universallyused.

7 10.0.0.0 through 10.255.255.255, 172.16.0.0 through 172.31.0.0 and 192.168.0.0 through 192.168.255.0

8 One common practice predating the patents-in-suit is to use a different TCP port number for each computermaking a request, thus allowing the NAT router’s outside IP address to be used for many requesting computers.



20

When data for the requesting computer is returned to the NAT router, it can identify the

“inside” computer from a table it maintains. Therefore, in a manner similar to that disclosed in

the patents-in-suit, the NAT router works by replacing a computer’s source IP address with its

own router IP address and replacing the destination IP address of a response packet with the

network IP address of the requesting computer.

6 SUMMARY OF OPINIONS

6.1 The Asserted Claims of the ‘892 Patent are Invalid

With regard to the ‘892 patent, Normadix has asserted infringement by Second Rule of

claim 1; claims 5 and 6 (dependent from claim 1); claim 7 (dependent from claim 5); and claim 8

(dependent from claim 5).

6.1.1 The Asserted Claims of the ‘892 Patent are not Enabled

See section 7.3

6.1.2 Weiman (U.S. Patent No. 6,141,690) Anticipates the Claims of the’892

Patent

See Claim Chart Exhibit A. Weiman anticipates claims claim 1, 5, 6, 7 and 8 of the ‘892

patent.

The application for U.S. Patent No. 6,141,690 entitled “Computer network address

mapping” was filed on July 31, 1997 (“Weiman”). Weiman discloses a system and methods for

connection of mobile laptop PCs to a network without the need to re-configure its network

configuration parameters every time.

Weiman discloses the use of a “portable device” (user device) attached initially to a

“local network” (home network), and then subsequently attached to a “remote network” (foreign

Response packets can be distinguished by the TCP destination port number. Such port mapping techniques are alsodisclosed in Figure 9A of the ‘892 patent.



21

network) while maintaining the same link layer address MAC as it used on the local network.

Moreover, Weiman discloses a system that does not require manual configuration:

In my opinion, Weiman (U.S. Patent No. 6,141,690) anticipates the asserted claims of

the’892 Patent. ‘Kostick96 Using Linux IP Forwarding Anticipates the Claims of the ‘892 Patent

See Claim Chart Exhibit B.

The following reference discloses the subject matter of the asserted ‘892 claims.

IP Masquerading with Linux, Chris Kostick, Linux Journal Issue 27, July 1996(“Kostick96”)

See portal.acm.org/citation.cfm?id=328288.328289

In addition, the following references provide background relevant to the subject matter of

the ‘892 patent.

RFC 1597, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D.Karrenberg, G. de Groot, March 1994 (“RFC1597”)

RFC1631 - The IP Network Address Translator (NAT), K. Egevang, P. Francis, May1994 (“RFC1631”)

IP Masquerading Code Follow-up, Chris Kostick, Linux Journal Issue 43, November1997 (“Kostick97”)

Building a Linux Firewall, Chris Kostick, Linux Journal 24, April 1st, 1996.

In my opinion, Kostck96 anticipates the asserted claims of the’892 Patent.



claim 11; claim 12 (dependent from claim 11); claim 13 (dependent from claim 12); claim 15;

claim 17 (dependent from claim 15); claim 19; and claim 20 (dependent from claim 19).

The ‘727 patent is entitled “System and method for establishing network connection with

unknown network and/or user device” and has a filing date of October 6, 2000. The inventors

claim priority from the continuation of U.S. application Ser. No. 09/041,534, filed on Mar. 12,

1998, now U.S. Pat. No. 6,130,892.



22


See section 8.3.

6.2.2 Stevens Anticipates the Claims of the ‘727 Patent

See Claim Chart Exhibit C.

In my opinion, the asserted claims of the ‘727 Patent are invalid because of the prior art

known or in used in the United States as well as prior art in the form of printed publications. The

claims at issue are either anticipated by or rendered obvious in light of the following:

TCP/IP Illustrated, Volume 1, W. Richard Stevens, pp.60-62, 1994. (“Stevens”)RFC 1009 Braden et al “Requirements for Internet Gateways,” June 1987

RFC 1027 “Using ARP to Implement Transparent Subnet Gateways,” Carl-Mitchell et al,October 1987

RFC 1919, M. Chatel, “Classical Versus Transparent IP Proxies, March 1996.

In my opinion, Stevens anticipates the asserted claims of the’727 Patent.‘

6.2.3 Kostick96 Using Linux IP Masquerading Renders the Claims of the

‘727 Patent Obvious

See Claim Chart Exhibit D.





the ‘727 patent.





23



In my opinion, Kostick96 anticipates claims 19 and 20 of the ‘727 patent, and renders

claims 11-13, 15 and 17 of the’727 patent obvious.

6.2.4 Weiman Renders the Claims of the ‘727 Patent Obvious

See Claim Chart Exhibit E.



claim 1; claim 5 (dependent from claim 1); claim 6; claims 7, 8 and 9 (all dependent from claim

6); and claim 10 (dependent from claim 7).

The ‘894 patent is entitled “Systems and methods for redirecting users having transparent

computer access to a network using a gateway device having redirection capability” and has a

filing date of Dec. 8, 1999. A Provisional Patent Application Ser. No. 60/111,497 was filed on

Dec. 8, 1998. Claims 1 and 6 are independent claims. Claim 6 is an apparatus claim that mirrors

the method claim of claim 1.

6.3.1 The Assetrted Claims of the ‘894 Patent are not Enabled

See section 9.3.

6.3.2 Slemmer (US Patent 6,226,677) in Combination with Heddaya (US

Patent 6,205,481) Renders the Claims of the ‘894 Patent Obvious

See Claim Chart Exhibit F.

In my opinion, the asserted claims of the ‘894 patent are invalid because of prior art

known or in used in the United States as well as prior art in the form of printed publications. The

claims at issue are either anticipated by or rendered obvious in light of one or more of the

following:



24

Slemmer (US Patent 6,226,677) in Combination with Heddaya (US Patent 6,205,481)

Renders the Claims of the ‘894 Patent Obvious

US Patent 6,226,677, entitled “Controlled communications over a global computer

network,” was awarded to Michael Slemmer on May 1, 2001 (“Slemmer”). Application No.

09/232,386 for the patent was filed on January 15, 1999.

Slemmer discloses the handling of browser request packets from a user computer. These

user originated TCP packets are sent via an intranet to a “forced proxy server.” When a TCP

packet is received by the forced proxy server it is analyzed. If the destination IP address

(referred to in the patent as the “first destination IP address”) is not from a “sandboxed” domain,

the destination IP address is changed to a predetermined second destination IP address. This

reroutes the TCP packet to another IP address on the Internet. The rerouted TCP packet results

in webpage request at a web server. The web page is returned to the user’s computer.

In my opinion, Slemmer in combination with Heddaya renders the asserted claims of

the’894 patent obvious.‘

6.3.3 IPORT in Combination with Heddaya (US Patent 6,205,481) Renders

the Claims of the ‘894 Patent Obvious

See Claim Chart Exhibit G.

In my opinion, the IPORT system in combination with Heddaya renders all of the claims

of the ‘894 patent obvious.

The IPORT system disclosures are contained in the following documents:

Hospitality Net Article, “New room-service fare/High –speed Internet access

(Atcom/Info Installed in Hyatt in San Jose, and the Four Seasons in Beverly Hills,” Dec.8, 1998. [SEC0002799-SEC0002800]

User’s Guide to Installing IPORT Internet Access System Server (v2.0), dated Sept. 21,1998 (ATCOM Confidential) [SEC00520-SEC00721]

Network World Article “New room-service fare/High –speed Internet access,” dated Dec.7, 1998, [SEC0002805-SEC0002807.]



25

IPORT Internet Access System Site Installation Guide (Version 2), October 13, 1998[SEC00883-SEC00838.]

White Paper, “Connection Methods and Concepts for IPORT v2.x, dated November1998. [SEC00808-SEC00824.]

White Paper “IPORT Central Office Solution,” dated November 1998. [SEC00732-SEC00752]

In my opinion, IPORT in combination with Heddaya renders the asserted claims of

the’894 patent obvious.‘

6.3.4 Kostick97 in Combination with Ikudome99 Renders the Claims of the

‘894 Patent Invalid

See Claim Chart Exhibit H.

The following references disclose the subject matter of the asserted ‘894 patent claims:


See http://portal.acm.org/citation.cfm?id=328288.328289

“System Administration: IP Masquerading Code Follow-Up,” Linux Journal archive,Volume 1997, Issue 43es (November 1997) ISSN:1075-3583, Chris Kostick (“Kostick97”)


Ikudome US patent 6,779,118 entitled “User specific automatic data redirection system”issued August 17, 2004 (Application date April 21, 1999.)

In addition, the following reference describes HTTP proxy services.

US Patent 5,696,898 entitled “System and method for database access control” issued onDecember 9, 1997 to Baker, et al. Application date June 6, 1995. (“Baker95.”)

In my opinion, Kostick97 in combination with Ikudome99 renders the asserted claims of

the’894 patent obvious.


The ‘399 patent is entitled “Systems and methods for integrating a network gateway

device with management systems” and has a filing date of October 20, 2000. The inventors

claim priority from several U.S. Provisional Applications filed on Oct. 22, 1999.



26

Nomadix contends that Second Rule infringes claims 1, 3-4, 6, 8, 13, 15-16, 18 and 20-

21. Claims 1, 6, 13, and 18 are independent claims. Claims 1 and 13 are apparatus claims while

claims 6 and 18 are method claims.

‘‘


See section 10.3.

6.4.2 VanHorne98 (US Patent 6,128,601) in Combination with IPORT


See Claim Chart Exhibit I.

U.S. Patent 6,128,601 (“VanHorne98”), entitled “Active client to communications

network connection apparatus and method,” when combined with the IPORT product

disclosures, renders the ‘399 patent obvious.

The U.S Patent Office rejected the claims of the ‘399 patent application as being

anticipated by Van Horne (US Patent 5,987,430). The ‘399 patent was allowed only as a result

of amendments that are fully disclosed by the IPORT product.

The following references disclose the functionality of the IPORT system:

Hospitality Net Article, “New room-service fare/High –speed Internet access(Atcom/Info Installed in Hyatt in San Jose, and the Four Seasons in Beverly Hills,” Dec.8, 1998. [SEC0002799-SEC0002800]


Network World Article “New room-service fare/High –speed Internet access,” dated Dec.

7, 1998, [SEC0002805-SEC0002807.]





27


In my opinion, VanHorne98 (U.S. Patent No. 6,128,601) in combination with the IPORT

disclosures renders the asserted claims of the’399 patent invalid.‘


U.S. Patent 6,857,009, entitled “System and method for network access without

reconfiguration,” was awarded to Ferreria, et al. on February 15, 2005. The application was filed

on October 23, 2000, but the applicants claim priority to U.S. Provisional Patent Application Ser.

No. 60/161,138 filed Oct. 22, 1999. The latter provisional application is incorporated in the ‘009

specification by reference in its entirety. The ‘009 patent includes the application for the ‘892

patent by reference.

Nomadix contends that Second Rule infringes claims 1, 2, 4-6, 8-11, 23-24, 26-28, and

30- 35. Claims 1, 23, and 34 are independent claims. Claims 12 and 23 are apparatus claims

while claims 1 and 34 are method claims.

6.5.1 Kostick96 (Linux IP Forwarding) in Combination with Elton97

Renders the Claims of the ‘009 Patent Obvious.

See Claim Chart Exhibit J.


IP Masquerading with Linux, Chris Kostick, Linux Journal Issue 27, July 1996(“Kostick96”)See http://portal.acm.org/citation.cfm?id=328288.328289

Linux as a Proxy Server, Linux Journal archive, Volume 1997, Issue 44 (December1997) Article No. 3, ISSN:1075-3583, Peter Elton. (“Elton97”)


In my opinion, Kostick96 in combination with Elton97 renders the asserted claims of

the’009 patent obvious.



28

6.5.2 Millet in Combination with Bhagwat99 Renders the Claims of the ‘009

Patent Obvious

See Claim Chart Exhibit K.

U.S. Patent No. 6,434,627 (“Millet”), entitled “IP network for accommodating mobile

users with incompatible network addressing,” was awarded to Millet, et al. on August 13, 2002.

Application No.: 09/268,559 was filed on March 15, 1999.

Millet discloses an address translation method that allows a computer network to

automatically learn that a visiting node has attached to the network. The patent also discloses a

method wherein there is automatic establishment of a virtual gateway, thereby allowing the

visiting node to communicate with local nodes, other visiting nodes, and/or Internet sites.

US Patent No. 7,139,268, entitled “Performance of intermediate nodes with flow

splicing,” was issued to Pravin Bhagwat and John Tracey on November 21, 2006

(“Bhagwat99”). It was issued from Application No.: 09/240,374 filed on January 29, 1999.

Bhagwat99 discloses a method and system with an intermediate node separating two end

point computers. The patent describes a system for “splicing” a data flow inbound to the

intermediate node, and a second data flow outbound from the intermediate node. The composite

“spliced” flow transforms the first data flow and the second data flow into a single composite

data flow originating at the source of the first data flow and terminating at the destination of the

second data flow.

In my opinion, Millet in Combination with Bhagwat99 Renders the Claims of the ‘009

Patent Obvious.‘

6.5.3 Stevens (Proxy ARP) in Combination with Bhagwat97 Render the

Claims of the ‘009 Patent Obvious

See Claim Chart Exhibit L.



29

Proxy ARP is a technique for intercepting ARP requests from a computer that is

configured with the wrong Network ID. The Proxy ARP concept is fully disclosed in the

following documents:

RFC 1027, S. Carl-Mitchell & J. Quarterman, October 1987.

RFC 1919, “Classic v Transparent IP Proxies,” M. Chatel, March 1996.

Stevens TCP Illustrated at pages 60-62. (“Stevens”)

US Patent No. 5,941,988, entitled “Session and transport layer proxies via TCP glue,”

was awarded to Pravin Bhagwat and David Maltz on August 24, 1999 (“Bhagwat97”). The

application for this patent was filed on January 27, 1997.

This reference describes a method of merging two separate TCP connections terminating

at a common host and “gluing” them into a single connection between a client computer and a

target server, such as a web server. An intermediate proxy called the “TCP proxy” is used to

“splice” the two separate connections. The “spliced” connection preserves the TCP end-to-end

semantics of packet byte sequence numbers, byte acknowledgement numbers, and flow control.

In my opinion, Stevens (Proxy ARP) in combination withBhagwat97 renders the claims

of the ‘009 patent obvious.‘

7 ‘892 PATENT INVALIDITY ANALYSIS

7.1 The ‘892 Patent

The ‘892 patent application No. 09/041,534 was filed on March 12, 1998 and is a

continuation-in-part of U.S. patent application Ser. No. 08/816,174, entitled “NOMADIC

ROUTER,” filed Mar. 12, 1997, now abandoned. The ‘892 patent discloses a “Nomadic

translator or router.”

Nomadix asserts that claims 1 and 5-8 are infringed by Second Rule.



30

7.1.1 Overview

According to the ‘892 patent, a nomadic router enables a “portable computer” configured

for a “home” network to be connected to any location on a different network 9. The specification

discloses a router, referred to as a nomadic router that automatically and transparently re-

configures itself to its new location (foreign network) and processes outgoing and incoming data.

A nomadic router enables a portable computer, which is configured to be connected to a

home network to be connected to any location on the Internet. From the context of the ‘892

specification, it is understood that a nomadic router is not a classical layer 3 networking device;

rather, the term “nomadic router” has the connotation of a translation device. The nomadic

router automatically and transparently re-configures the portable computer to its new location by

processing outgoing and incoming data. The nomadic router appears as the home network to the

portable computer, and appears as the portable computer to the communication system. The

portable computer has a permanent address, the nomadic router has a router address, and the

portable computer transmits outgoing data to the system including its permanent address as a

source address. The router translates the outgoing data by replacing the permanent address with

the nomadic router address as the source address. The portable computer receives incoming data

from the system including the nomadic router address as a destination address; the nomadic

router translates the incoming data by replacing the nomadic router address with the permanent

address as the destination address.

The nomadic router has the ability to establish communication with a portable computer

that is affirmatively configured in an incompatible way. It is assumed that the portable computer

knows nothing about the nomadic router. The nomadic router is capable of intercepting packets

transmitted from the portable computer that would otherwise be dropped by devices on the

foreign network. The nomadic router is claimed to be capable of dealing with “incompatible or

9 Although the ‘892 patent specification refers to the “internet” there is no limitation expressed in the claims thatwould narrow them to the Internet alone.



31

improperly configured” devices. It does so automatically, thereby eliminating any form of

manual configuration, without requiring prior knowledge of network settings of the portable

computer.

The nomadic router performs the necessary translation or modification to the packets sent

to/from the portable computer to make them “compatible with the currently attached network” –

without actually changing the configuration of the portable computer.

7.1.2 ‘892 Priority Date

It is my opinion that the claims of the ‘892 patent are not supported by the original parent

application U.S. patent application Ser. No. 08/816,174. I have therefore used March 12, 1998

as the priority date for the ‘892 patent.

The portions of the ‘892 patent that are not present in the March 1997 application include

Figures 7 through 15, and portions of the written specification from col. 10 ll. 21 through col. 14

ll.39. These missing segments are essential in providing one of ordinary skill in the art the scope

of the invention.

For example, during the patent prosecution the applicants overcame the Examiners

objections by identifying different means by which the nomadic router is able to learn about the

host computer and network so it is aware of what translation is necessary. For example, the

section referred to as “Host Learning” describes the redirection of all outbound packets from the

host computer to the nomadic router. During the patent prosecution it was stated that this

redirection can be accomplished in several ways, including: 1. Proxy ARP Packet Interception

and Host Reconfiguration; 2. Promiscuous Mode Packet Interception; 3. Dynamic Host

Configuration Protocol (DHCP) Service.

Similarly, the ‘892 patent specification disclosures regarding “Network Learning” are

essential to an understanding of the ‘892 patent. The specification states that the nomadic router

is able to learn about the network environment it is currently attached to by using methods such



32

as: 1. Dynamic Host Configuration Protocol (DHCP); 2. Router Information Packets; 3. Passive

Listening, involving placing the nomadic router’s network connection in promiscuous mode,

where it receives all packets not just ones destined for it. The description of these aspects of the

‘892 invention are missing from the abandoned March 12, 1997 application.

The subject of “Packet Translation” was also introduced by the applicant for the first time

in the March 12, 1998 specification. The nomadic router packet translation function provides a

mapping between location and service dependent configurations used by the host computer 12

and that used by the network 14 to which it is currently attached. This is a feature of each and

every claim of the ‘892 patent.

The inbound traffic arriving at the nomadic router destined for the host computer 12, is

passed through the translation function so the host computer thinks that the replies were sent

directly to it. The host computer is completely unaware of all the translation being performed by

the nomadic route. Figures 9a and 9b illustrate the translation function. They are missing in the

March 12, 1997 application specification. These figures describe the operations performed at the

application, transport, network, link and physical layers.

The host computer 12 will generate network packets using the current configurationstored in the host computer 12 using the standard protocol stack as shown in step 1. Thisconfiguration information is either manually configured in the host computer 12 orobtained using DHCP.

As shown in step 2, when the host computer 12 addresses the link level

destination address, the address automatically obtained using the Proxy ARP packetinterception routine described earlier, this will cause the host computer 12 to send thepacket to the network address of its standard router or home gateway device, but usingthe link level address of the nomadic router 10.

In step 3, the packet is transmitted across the standard physical connection between thehost computer 12 and nomadic router 10. As shown in step 4, the nomadic router 10 willreceive the packet at the link level either due to the Proxy ARP function whichreconfigured the host computer’s MAC address, or the nomadic router 10 will have thelink level in promiscuous mode which will cause it to receive the packet even if destinedto a different MAC address.



33

Once the packet is passed to the network layer, shown in step 5, the nomadic routertranslation function will modify the content of the packet to change the source address tothat of the nomadic router’s address instead of the host computer’s address. It will alsotranslate other location dependent information such as the name of the local DomainName Service (DNS) server. When translating the DNS packet, it will change the source

address to that of the nomadic router’s address and the destination address to that of alocal DNS server.

Once the network layer translation is complete, the packet can be translated at theapplication and transport layers. The application layer is translated next, as shown in step6, since the transport layer requires a pseudo network layer header which includes thesource and destination addresses and the content from the application layer.

At the application layer translation, any addresses which describe the source address of the host computer, such as with FTP, are translated to be that of the nomadic router’saddress. Any application layer destination addresses, such as a local proxy server, are

translated to match that of the server running on the current network.

Once this application translation is complete, the transport layer, as shown in step 7, cancomplete the checksum and any port number manipulation. The port number ismanipulated if more than one host computer 12 is attached to the nomadic router 10.Each host computer 12 when it sends out a request using a specific port is translated tomatch an available inbound port on the nomadic router 10.

The port number assigned for use with each host computer 12 is stored in a table in thenomadic router 10 and is utilized with the reply packet described later. Finally the packetis sent out over the network 14 in step 8.

When a reply packet comes in from the network 14, as shown in step 9, the nomadicrouter 10 will receive the packet. In step 10, the nomadic router 10 will perform thereverse network layer translation to set the destination address to that of the hostcomputer 12 rather than the nomadic router’s address, and any source address to thatreplaced by the nomadic router 10 in step 5.

Once this network translation is complete, the packet is translated at the application layer,as shown in step 11, to change the destination address to that of the host computer 12 andthe source address to the original destination address stored from step 6. In step 12, anyport manipulation performed in step 7 is changed to the original setting and a newchecksum is computed. Finally, as shown in step 13, the packet is sent to the hostcomputer 12 which then processes the packet normally.

See ‘892 patent at 13:43-14:38.

The detail provided in these passages is essential to understanding the claim language of

the ‘892 patent. Without it, the claims are not supported by the specification. Because it is



34

missing from the March 12, 1997 application, there is no support for the translation elements

recited by the ‘892 patents.

For these reasons it is my opinion that the correct priority date for the ‘892 patent is

March 12, 1998.

7.1.3 ‘892 Claims

1. A method for allowing network communications over a foreign network for a userdevice configured to communicate with a home network, the method comprising:

connecting the user device to the foreign network;

intercepting packets transmitted from the user device which would otherwise be droppedby devices on the foreign network to determine without requiring prior knowledge of

network settings of the user device;using the determined network settings of the user device to determine whether tointercept subsequently transmitted packets; and

automatically modifying packets transmitted from the user device based on the network settings of the user device and network settings of the foreign network.

5. The method of claim 1 wherein modifying packets transmitted from the user devicecomprises:

replacing a source address with a router address where the router address is automaticallydetermined based on the network settings of the foreign network.

6. The method of claim 5 wherein replacing the source address comprises replacing asource address within a packet header.

7. The method of claim 5 wherein replacing the source address comprises replacing asource address within a packet header and a source address within packet contents.

8. The method of claim 5 further comprising:

receiving data from the foreign network with the router address as a destination address;and replacing the destination address with a network address of the user device

See ‘892 patent at 17:15-18:34.

The portable computer has what the patent describes as a “permanent address,” and thenomadic router has a “router address.” However, the reference to “address’ is ambiguous, as will

be discussed later. The nomadic router translates the outgoing data by replacing the permanent

address with the router address as the source address.



35

7.1.4 ‘892 Claim Terms

The Court has construed following claim term:

Term at Issue Court’s ConstructionsClaim 1:intercepting

“receiving and processing [e.g., data, packets]targeted for another device”

7.2 Prosecution History

The PTO Examiner originally rejected claims many claims of the ‘892 patent application

under 35 U.S.C. § 102{e) as being anticipated by Li et al, (U.S. Patent No. 6,012,088) and

Egevang (RFC 1631, retrieved 4/27/99). The remaining claims were rejected under 35 U.S.C.§

103(a) based on combinations of Li, Egevang and Perkins (U.S. Patent No. 5,412,654), Norris

(U.S. Patent No. 5,557,748), Mayes (U.S. Patent No. 5,793,763), and Compliment (U.S. Patent

No. 5,909,549).

From the amendment filed 2/29/2000 (p560), and following the Examiner’s Interview

conducted on April 19, 2000, the ‘892 patent claims 55- 62 of the application were allowed.

Claim 55, now claim 1 of the issued patent, was amended as follows:1. A method for allowing network communications over a foreign network for a userdevice configured to communicate with a home network, the method comprising:

connecting the user device to the foreign network;

intercepting packets transmitted from the user device which would otherwise be droppedby devices on the foreign network to determine without requiring prior knowledge of network settings of the user device;

using the determined network settings of the user device to determine whether tointercept subsequently transmitted packets; and

automatically modifying packets transmitted from the user device based on the network settings of the user device and network settings of the foreign network.

See ‘892 patent claim 1 [Feb 29, 2000 amendments highlighted.]



36

On March 30, 2000, the Applicants filed a “Proposed Response” and offered further

remarks attempting to distinguish the then-cited prior art:10 Applicants’ solution to establishing

communication with an incompatible or improperly configured device was to intercept packets

transmitted from the device.

It was stated that the invention intercepts packets, i.e. receives and processes packets, not

intended for the nomadic router/translator. As further clarification the Applicants stated that the

prior art relied upon by the Examiner “fails to disclose or suggest the concept of intercepting

packets to establish communication with an incompatible device and translate or modify

subsequent packets to “appear” compatible to the network.”

The significance of this is clarified in the following file history cite:

In general, all of the references relied upon by the Examiner assume and/or require aproper configuration (or compatibility) to establish communication with the device.

Because Applicant’s invention does not require or assume a proper, compatibleconfiguration, Applicants had to devise a strategy to establish communication with animproperly configured (incompatible) device. Once communication with the device isestablished, Applicant’s invention performs the necessary translation or modification tothe packets sent to/from the device to make them “compatible with the current ly attachednetwork – without actually changing the configuration of the device.

See March 30, 2000 response [page 589-590]

Applicants’ provide three examples (of the many possible) of how packets can beintercepted: Proxy ARP Interception, Promiscuous Mode Packet Interception, and DHCPRequest Interception. (see pp. 19-20 of specification.) In each case, the present inventionintercepts packets, i.e. receives and processes packets, which are not intended for thenomadic router/translator and are in fact are likely intended for a device or host (such as arouter or gateway) which is not on the foreign network (thus, are incompatible).

[See ‘892 at 11:57 for proxy ARP discussion]

See prosecution History page 590.

With regard to the prior art reference of Egevang, the Applicants stated that the router

disclosed by Egevang does not perform intercepting as claimed by the patent. This apparent

10 See page FH pages 560-578 for Feb 29, 2000 amendments. See FH pages 589-592 for March 30, 2000

amendment.



37

deficiency arises because Egevang’s router must be addressed correctly at the link layer in order

for it to perform its NAT function. i.e., any network devices that do not know the Egevang

router’s link layer address will send packets that will be dropped by it and therefore not satisfy

the claim language of “intercepting packets transmitted from the user device which would

otherwise be dropped.” Devices satisfying the ‘892 claim language must be capable of

interception even if their link layer address is not known to the network devices requiring NAT

router services:

Egevang is directed to solving the problem of IP address reuse and describes a strategyfor Network Address Translation (NAT) which maps private IP addresses to public,routable IP addresses.

For the router disclosed by Egevang to perform NAT, the packets must be explicitlyaddressed to it at the link layer. Otherwise, the packets will not” know” of that particularrouter’s existence and therefore can not establish communication with the router in thefirst instance. The router does not intercept packets as described and claimed byApplicants.

The March 30, 2000 response also conveys the same message for prior art of Johnson

cited by the PTO Examiner. In essence, an interface communications processor such as that

disclosed by Johnson does not satisfy the ‘892 claim language because it is not capable of

dealing with packets that do not know its link layer address.

Packets sent by devices that do not know the interface communications processor’s link

layer address will be “dropped” and not intercepted as required by the invention. As stated in the

response, “if the packets are not compatible at the link layer, i.e. addressed to the interface

processor, no translation can be performed.”

Johnson is similar in some respects to both Norris and Egevang, and is alsodistinguishable. Johnson discloses an interface (communications) processor which

performs protocol translation to accommodate communication over dissimilar network architectures or protocols. Johnson indicates that the interface processor, “which initiallydoes not know the specific format being used by the data, examines the data to identifyits format.” (Col. 2, ll.40- 42.) Johnson also states that “... the CP 312 determines in whatformat the data is received. This determination is made based only on the received data,that is to say, without advance knowledge,” (Col. 4. ll. 53-55) Like Egevang, Johnsonassumes that the device is compatible with the network at the link layer in that the devicemust send packets to the interface processor. If the device is incompatible with the



38

network, the interface processor would never receive the packets and process them in thefirst place. Similar to the router in Egevang, if the device is unaware of the existence of the router/processor, the packers will be dropped. There is no teaching or suggestion inJohnson to intercept packets as disclosed and claimed by Applicants.

The applicants also represented the following (in distinguishing the Norris reference,

which was applied to claim 56). These responses give additional insight into the nature of the

invention.

With respect to claim 71, the proposed combination of Li, Egevang, and Norris does notdisclose replying to the ARP message by associating a media access control address of adevice on the network with a destination address of the device on the home network asdisclosed and claimed by Applicants. Furthermore, the proposed combination does notdisclose automatically determining network settings of the network based on addressescontained in the messages translated over the network and modifying these messages

transmitted by a user device based on the network settings of the network. The Examinercites col. 10, lines 6-10 of Norris which states:

The ARP and SAP commands are used to locate a variety of hardware mechanisms onthe network. This permits the mobile computer to connect to a quiet network or acompletely foreign network and still utilize resources on that network.

Contrary to the Examiner’s position, the claimed method of claims 6,8, 50, and 52 doesnot simply use ARP to resolve the network address. Rather, the present invention asdisclosed and claimed “pretends” to be the device which the user device is looking forwhen it transmits an ARP packet. The present invention then “transmits a reply to theuser device which includes a MAC address of the translator.” As described in thespecification, this feature of the present invention “tricks” the user device into sendingfuture packets to the translator although the user device “thinks” it is sending the packetsto a device on its home network. This is not simply the prior an ARP request as describedin Norris, but a unique modification of the ARP reply which allows the present inventionto function without prior information of the foreign network. The Examiner has notidentified any teaching or suggestion in the art of record which would motivate one of ordinary skill in the art to reply to an ARP request which is not directed to the devicewhich is generating the reply as disclosed and claimed by Applicants.

However, on March 3, 2000, the Examiner issued an Advisory action indicating that the

arguments were not persuasive and that no claims were in condition for allowance. Following an

Interview on April 19, 2000, the Patent Office issued a Notice of Allowability for claims 55-62

of the application.



39

7.3 The ‘892 Patent is not Enabled

According to the ‘892 patent, a nomadic router enables a “portable computer” configured

for a “home” network to be connected to any location on a different network. The specification

discloses a router that automatically and transparently re-configures itself to its new location and

processes outgoing and incoming data. The ‘892 patent uses various terms such “terminal,”

“user device,” “host computer,” “host device,” “mobile computer,” and “network device (host)”

when referring to the portable computer.

The portable computer has what the patent describes as a “permanent address,” and the

nomadic router has a “router address.” The nomadic router translates the outgoing data by

replacing the permanent address with the router address as the source address. The portable

computer receives data through the router because the router processor translates the incoming

data by replacing the router’s address with the “permanent address” as the destination address.

However, the reference to “address” is ambiguous and not enabled by the specification.

7.4 Weiman (U.S. Patent No. 6,141,690) Anticipates the Claims of

the’892 Patent

7.4.1 Background on Weiman





Weiman discloses the use of a “portable device” (user device) attached initially to a

“local network” (home network), and then subsequently attached to a “remote network” (foreign

network) while maintaining the same link layer address MAC as it used on the local network.

Moreover Weiman discloses a system that does not require manual configuration:

An apparatus and method of the present invention provide for computer network configuration and address mapping, so as to provide convenient, secure, and flexible highspeed communication between devices on the computer network. In a preferred



40

embodiment, the invention provides for connecting mobile laptop PCs to a network,without the need to re-configure its network configuration parameters every time.See Weiman at 2:47-55 (Emphasis added.)

The link layer MAC address of the portable device is referred to as the “first tap point,”

referring to a MAC address used to connect to the local network, and a “second tap point” that

represents the MAC address of a local device on the local network that the portable device

wishes to communicate with. IP or Internet Protocol addresses are referred to in Weiman as

“computer network addresses” and relationships between computer network addresses and “tap

points” are maintained. See Weiman at 1:53-57.

The Weiman invention discloses the use of a “remote controller” that provides for the

capture of packets from the portable device when it is connected to the remote network and

sending packets containing networking parameters it used when connected to the local network.

The portable device is not modified for use on the remote network; the remote controller learns

the portable devices network parameters from the contents of the packets received.

As shown in FIG. 1, the portable device 103 includes a generator 123 of an initial datapacket, which, as discussed in greater detail subsequently herein, has a source addressheader that includes the network level protocol address 105 that identifies the first tappoint 107 of the local network 101, and a destination address header that includes the

network level protocol address 105 that identifies the local device coupled to the secondtap point 110 of the local network 101. The portable device 103 includes a transmitter fortransmitting the initial data packet 213 from the portable device 103 to the remotecontroller 115, when the portable device is connected to the remote network, as shown onthe left side of FIG. 1.

See Weiman at 4:30-42. (Emphasis added.)

7.4.2 Analysis of ‘892 Patent Claim 1

7.4.2.1 network communications over a foreign network for a user device

configured to communicate with a home network

The ‘892 patent makes no technical distinction between “home,” “office,” “airport,”

“hotel,” and “foreign” networks. For example, it does not identify any distinguishing features

that would make a “home” network different from say an “office” network, other than

geographical location:



41

There is a vast array of communication device alternatives such as Ethernet, WirelessLAN, and dialup modem among which the users switches when in the office, movingaround the office, or on the road (such as at a hotel, airport, or home).

See ‘892 patent at 2:52-56.

Similarly, The Weiman reference also does not distinguish between a home network and

any other kind of network. It is evident that Weiman applies equally to any form of local or

remote network that might be classified as a “home,” “office,” “airport” or “hotel” network.

In the case of the Weiman reference the disclosed “local network” corresponds to the

‘892 patent “home network” and the “remote network” disclosed by Weiman corresponds to the

‘892 patent “foreign network.” Therefore Weiman satisfies the claim 1 preamble.

7.4.2.2 intercepting packets transmitted from the user device which wouldotherwise be dropped by devices on the foreign network

The Court has construed “intercepting” to mean “receiving and processing [e.g., data,

packets] targeted for another device.” The disclosures of Weiman satisfy this claim step.

Interception of IP Packets Targeting Other Hosts

The ‘892 patent provides one example of “intercepting” that is based on ARP proxy using

promiscuous mode packet interception by the Nomadix router. Promiscuous mode ARP packet

capture involves receiving and processing an ARP request packet that has MAC destination

address of all 1’s, denoting a LAN broadcast, and a target IP address for a network host.

In this instance, intercepting can be understood as receiving and processing a packet

targeted for a different IP address, regardless of the MAC destination address. The only means

of determining the target for the packet is the IP destination address.

The only other address elements in an ARP request packet are the source MAC address

and host IP address of the sending host. Thus, an ARP request packet contains no information

about the host computer it is targeting other than the IP address. Therefore, any gateway device

that receives and processes a packet having a destination IP address different from its own

qualifies as an intercepting device under the Court’s construction. This follows from the fact that



42

ARP request packets processed by a proxy ARP gateway are “targeted for another device”

exclusively by virtue of the embedded target destination IP address, and that IP address is not the

same as the proxy ARP gateway device.

Clearly, if a host sends any packet on a LAN where the destination IP address is different

from the IP network ID, the packet will be dropped unless it is intercepted by a gateway device.

The Weiman Reference Satisfies Intercepting Under the Court’s Construction

The Weiman reference states that the packets generated by the portable device contain

the IP address identifying the host computer itself (at the first tap point) on the “local network”

(equivalent to the ‘892 patent “home network”) and an IP address of a gateway “tap point” 110on the local network 101 (‘892 patent “home network”):

As shown in FIG. 1, the portable device 103 includes a generator 123 of an initial datapacket, which, as discussed in greater detail subsequently herein, has a source addressheader that includes the network level protocol address 105 that identifies the first tappoint 107 of the local network 101, and a destination address header that includes thenetwork level protocol address 105 that identifies the local device coupled to the secondtap point 110 of the local network 101.


The first tap point 107 corresponds to the LAN connection point for the host computer’s

“home” network 101 in the upper right hand corner of figure 1. When the host computer 103 is

connected to a “foreign network” such as 113, packets generated by the portable device would

otherwise be dropped by devices on the remote network, since they would be configured with an

IP host source address that was not recognizable on the remote network.

The Weiman disclosure clearly indicates that the remote controller “intercepts” the

packet transmitted from the portable device.

When the portable device 103 is connected to the remote network, the portable devicetransmits the initial data packet to the remote controller 115 as shown in FIG. 2 anddiscussed previously herein.

See Weiman at 5:34-37.



43

Any gateway device that receives and processes a packet having a destination IP address

different from its own qualifies as an intercepting device under the Court’s construction.

7.4.2.3 determine without requiring prior knowledge of network settings of the

user device

The Weiman patent discloses ways of determining the network settings of the user

device. Many of the same ‘892 patent preferred embodiment techniques for “host learning” are

disclosed by Weiman. For example, Weiman uses promiscuous packet capture (see discussion in

section 7.1.3):

The code scans for all of the packet drivers that might be included as configuration items.There might be one, or there might be up to five. So it is scanned to see how many of

them are installed and finding the means for calling them, called handles; passing theaddresses for packet-receivers and set each interface into Promiscuous Mode.


As noted in section 7.1.2 above, the ‘892 patent “host learning” includes setting the

nomadic router in “promiscuous mode.”

Similarly, the ‘892 patent discloses the “Proxy ARP Packet Interception and Host

Reconfiguration” method of intercepting and processing ARP packets on a foreign network. The

identification and processing of ARP packets is also disclosed by Weiman:

If there were no configuration errors, the execution of the software moves from Block 319 to Block 321, it’s going to initiate an ARP (Address Resolution Protocol) used tofind the Physical Address for the default network gateway. Execution of the softwarethen enters the main loop at Block 323 for scanning through all of the receiver bufferslooking for a buffer that has a packet that has been received. So now moving over toBlock 331, the procedure handleReceivedPacket is going to check to see if this packet isan ARP Packet. If it is, then it calls the procedure handleARPPacket in Block 333 and isdescribed in FIG. 5A


The software first tests for arrival of an ARP packet of any kind:

Block 509 determines if this is an ARP Request. If it is not, then execution of thesoftware checks to see if it is an ARP reply. If it’s not that, there are other ARP or RARPcombinations that it could be. In Block 513 execution of the software returns withoutprocessing the packet.See Weiman at 8:59-63.



44

The software then tests for a portable device broadcasting an ARP with its own IP

address.

At Block 515, the packet is an ARP Request. Execution of the software checks to see did

it come from one of the network interfaces of the portable devices. If it did, thenexecution of the software checks to see if the portable device is ARP’ing for itself.See Weiman at 8:59-9:1.

The ARP reply processing mirrors the description of ARP processing given in the ‘892

patent, i.e., the Weiman system does not just use standard ARP packets, but builds a reply that

allows the remote controller to “pretend” to be a local network gateway. See Weiman at 9:28-35.

7.4.2.4 using the determined network settings of the user device to determine

whether to intercept subsequently transmitted packets

The software system of Weiman determines if a packet is an ARP Request or an ARP

Reply. If it is an ARP Request, the software searches the portable device table for an entry

whose Protocol Address matches the sender’s (source IP address). (See Weiman Figure 5, Block

521.) If an entry does not exist, the software creates a new entry in the table.

Then, an ARP response is created:

Execution of the software copies the sender’s Protocol Address and Physical Address into

the table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529.See Weiman at 9:28-35.

Here the term “address” has the meaning of both the Protocol Address and the Physical

Address as a pair. Thus, “destination Address” means the combination of destination Protocol

Address and destination Physical Address. See Weiman at 9:32. The above cite describes the

assignment of the controller’s (Protocol, Physical) addresses to the sending address fields of the

new packet, and assignment of the portable device’s (Protocol, Physical) addresses to the

destination address fields of the packet. See also Weiman discussion on ARP processing:

Both of these source Addresses, meaning the Physical MAC Address and the network level Protocol Address, are that of the Controller. Both destination Addresses, againProtocol and physical, are the sender’s.



45


See Weiman Figure 5C.

A packet from the portable device (user device) that is not an ARP packet is processed

and forwarded from the remote controller depending on the source IP address in the packet. See

Weiman at 12:17-14:51.



46

The network settings for the remote device stored in the lookup table are subsequently

used to determine whether to intercept other packets from the remote device. Weiman Figures

6E and 6J disclose a system that processes subsequent packets arriving at the remote controller

from the portable device and intercepts the packet if it does not have an entry in a table:

In Block 661 subsequent to Block 629, execution of the software determines that thepacket is from one of the portable device interfaces. In 661 execution of the softwaresearches the portable device table for a match based on the source Address of the packet.In Block 663 execution of the software checks to see if an entry was found.


The portable device table is searched for the “source Address” of the incoming packet.

As noted above, “source Address” should be interpreted as both Protocol and Physical addresses.

Moreover, the continuing discussion describes subnet comparisons, so it can be concluded that

the “source Address” and “Destination Address” include at least the Protocol (IP) addresses.

If the “source Address” is found in the table, the test is made for “Is the Destination

Address on the same subnet as the Remote Network?” See Weiman Figure 6E, item 673. Again,

this refers to the Protocol Destination (IP) address. If the “Destination Address” (IP) is on the

same subnet, the ARP table is searched for the corresponding destination physical address. Then

either the ARP supplied physical address or a gateway physical address is put into the packet’s

destination physical address.

In summary, a packet received from the portable device is intercepted and processed if

the portable device does not already have an entry in the portable device lookup table. Whether

a packet is intercepted is based on the acquired portable device’s “network settings” not being in

the table.

7.4.2.5 automatically modifying packets transmitted from the user device based

on the network settings of the user device and network settings of the

foreign network.

The processing disclosed by Weiman applies not just to packets that are ARP requests

from the portable device, but to more general IP packets. (See Weiman at 11:16-18, e.g.,



47

“Starting on FIG. 6A at Block 601, is the handle IP Protocol packet procedure. This is the code

that handles any packet that’s an IP Packet.”)

Figure 6E of Weiman describes the modification of a portable device (remote device)

packet based on a search of the “table of Portable Devices” for a match, which in turn is based on

the Source Address of the packet.” See Figure 6E. Thus, the stored “network settings”

corresponding to the “remote device” are used in the processing that results in the packet

modifications described in Figure 6J below.



48

See Weiman Figure 6E.

Figure 6J, describes the modifications to the packet:

If at least the gateway is known, then in 6125 execution of the software copies the defaultgateway’s Physical Address to the destination Address of the packet and sends thepacket, and returns in 6127.



49

If the ARP entry is known for where execution of the software is trying to send this, thenin 6129 execution of the software copies the ARP table entry’s Physical Address to thedestination at the Address of the packet and transmits the packet, and then execution of the software returns in 6131.


See Weiman Figure 6J.

In both cases there is an assignment of a physical address to the transmitted packet based

on the “network settings” of the portable (remote) device. For either of the two proposed sets of

constructions this claim step is satisfied by the Weiman disclosures.

Additionally, Weiman discloses “automatically modifying packets transmitted from the

user device based on the network settings of the user device and network settings of the foreign

network” in discussing the processing of packets that represent ARP responses to the user

device:

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol and



50

Physical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529.


Also, Weiman discusses the “automatic modification” of packets “based on the network

settings of the user device and network settings of the foreign network” when processing a

packet from the portable device:

Both of those blocks converge in Block 691 where execution of the software determinesthe Local Controller for this portable device. If the answer is no, then execution of thesoftware returns in 693. Otherwise, if yes, then in Block 695 execution of the softwaresets the destination Protocol Address to the Local Controller’s Protocol Address.


If the ARP entry is known for where execution of the software is trying to send this, then

in 6129 execution of the software copies the ARP table entry’s Physical Address to thedestination at the Address of the packet and transmits the packet, and then execution of the software returns in 6131.



7.4.3.1 replacing a source address with a router address where the router address

is automatically determined based on the network settings of the foreign

network. [‘892 patent claim 5]

automatic determination of router address

Weiman discloses the “router address is automatically determined based on the network

settings of the foreign network.” When the remote controller of Weiman boots up, it performs a

BOOTP transaction to obtain an IP address:

Execution of the software sends BOOTP broadcasts, but this is only done if the siteProtocol Address is not yet determined. There’s a feature in the software that provides forconfiguration without the Protocol Address using BOOTP, as in Block 355, thenexecution of the software returns back to the main loop.


Starting on FIG. 6A at Block 601, is the handle IP Protocol packet procedure. This is thecode that handles any packet that’s an IP Packet. In Block 603 we want to check to see if we know our remote network Protocol Address. Again, if the answer is no, then we callreceive BOOTP to check if this is a BOOTP reply. If it is, did we learn our site ProtocolAddress? If the answer is no, then we simply return without doing anything with the



51

packet. If the answer is yes, then execution of the software determines whether thedefault gateway and subnet mask are also ascertained. These are optional fields in theBOOTP reply (shown in Block 611).


This is also disclosed in Weiman Figure 3C:


Clearly, this step of determining the controller’s IP address is an automated step.

replacing a source address with a router address

Weiman discloses “replacing a source address with a router address” in discussing the

processing of packets that

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is the

controller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529.


In the processing of an ARP response packet, the original source address can be the MAC

address corresponding to the all 1’s broadcast address. This MAC source address is replaced by



52

the MAC address of the controller (the “router” of the ‘892 patent) in the source MAC address

field of the ARP Response packet. See section 5.5 for discussion of ARP Request/Response

packet structure. See section 5.5 regarding ARP packet structure.

Similarly, in the processing of an ARP response packet, the original source address can

be the IP address of the portable device. This IP protocol source address is replaced by the IP

protocol address of the controller (the “router” of the ‘892 patent) in the source IP address field

of the ARP Response packet. See section 5.5 for discussion of ARP Request/Response packet

structure.

Similarly, as disclosed by Weiman Figure 5C, a packet from a portable (remote) device is

processed according to “network settings” contained in the portable device table. See Figure 5C

element 521.



53


Based on the processing of network settings, the source physical address of the packet is

replaced with the physical address of the remote controller (router).

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address).



54


Therefore Weiman fully discloses the additional steps of Claim 5. The remote controller

(router) address is automatically determined based on the network settings of the foreign

(remote) network, and processing steps replace a source address with a remote controller (router)

address.


7.4.4.1 replacing the source address comprises replacing a source address within a

packet header





packet structure.





structure.

See Weiman at 8:64-9:8 and 9:25-35.


7.4.5.1 replacing the source address comprises replacing a source address within a

packet header and a source address within packet contents







55

packet structure. Also, the ARP response packet payload contains a target IP address, a target

MAC address, a source IP address and a source MAC address. When the ARP response packet

is formed from the ARP request packet, the source MAC address field contents are replaced by

the MAC address of the controller. See section 5.5 for discussion of ARP Request/Response

packet structure.





structure. Also, the ARP response packet payload contains a target IP address, a target MAC

address, a source IP address and a source MAC address. When the ARP response packet is

formed from the ARP request packet, the source IP address field contents are replaced by the IP

address of the controller. See section 5.5 for discussion of ARP Request/Response packet

structure.

See Weiman at 8:64-9:8 and 9:25-35.


7.4.6.1 receiving data from the foreign network with the router address as a

destination address; and replacing the destination address with a network

address of the user device [‘892 patent claim 8]

When describing the processing of packets from the remote network, Weiman discloses

this claim step:

If the answer is no, then in Block 641 execution of the software searches the portabledevice table for a portable device with this Protocol Address. In Block 643 execution of

the software checks to see whether one was found. If not, in 645, execution of thesoftware returns. Otherwise, if one is found, then in Block 647 execution of the softwarecopies the portable device’s Physical Address into the packet destination Address field,copies the Physical Address of the Network interface to the Source Physical Address,updates the portable device table entry time-of-last-use field, and sends the packet to theportable device. Execution of the software returns in Block 649.




56

Clearly, this is processing being performed by the remote controller; hence the packet

was addressed to the remote controller (router). The excerpt indicates that the remote controller

received data from the remote (foreign) network with the remote controller (router) address as

the destination address, and the subsequent processing replaced the destination address with a

network address of the portable (user) device. Therefore this disclosure in Weiman satisfies the

step of claim 8 of the ‘892 patent.

7.5 Kostick96 Using Linux IP Forwarding Anticipates the Claims of

the ‘892 Patent





the ‘892 patent.


RFC1631 - The IP Network Address Translator (NAT), K. Egevang, P. Francis, May

1994 (“RFC1631”)



7.5.1 Background on Kostick96

Kostick96 figure 1 illustrates the basic operation of IP packet masquerading. The

behavior of this network configuration is described by Kostick96:

Let’s decode this stuff. First, the earliest packet is at the bottom. It is a DNS request(therefore UDP) from 192.168.1.2 to 20.2.51.2. mccoy is warbird’s DNS server in thiscase. The Masq column shows us the port on deathstar that is used for the masquerading.For the first DNS request, it is port 60000 (EA60). After the DNS resolution, the TCPconnection is established on the next available port over 60000, 60001. Figure 2illustrates the protocol time-line for the sequence of events up to the TCP open.

See Kostick96 at page 3.



57

Similarly, RFC1631 discloses the processing of a network packet by replacing its source

address with a different source IP address before forwarding the packet to a different network.

See Kostick96 Figure 1.

Kostick96 therefore discloses the steps of the ‘892 patent. The “warbird” computer,

representing the patent “user device,” is configured with a host IP address of 192.168.1.2 that is

incompatible with the 20.2.51.0/24 network. When “warbird” sends a DNS request to the DNS

server “mccoy” it does so with a source IP address in the packet that is incompatible with

network addresses in the range 20.2.51.0/24.

Kostick96 describes a Linux computer called “deathstar” that has two network interfaces,

one to the incompatible network 192.168.1.0/24 and one to the network 20.2.51.0/24. The



58

computer “deathstar” corresponds to the ‘892 patent nomadic router. Without the specially

configured “deathstar” computer, the DNS request packet from “warbird” would not be sent to

the “mccoy” DNS server.

The packet sent from “warbird” is targeting a DNS server with an IP address of

20.2.51.2. According to the ‘892 patent and the Court’s construction for “intercepting,” namely

“receiving and processing [e.g., data, packets] targeted for another device,” the capture of the

“warbird” packet by “deathstar” satisfies the intercepting requirement of the ‘892 patent claims.

I note that the ‘892 patent provides various interpretations of “intercepting” including

interception of ARP packets:

1. Proxy ARP Packet Interception and Host Reconfiguration

Whenever a host computer 12 has an IP packet which it needs to send to a router 26 orother network device, it uses the Address Resolution Protocol (ARP) to obtain the link layer Media Access Control address (MAC address). As illustrated in FIG. 8, when thehost computer 12 broadcasts an ARP request for the MAC address of a destination node,the nomadic router 10 receives this ARP request broadcast and responds with its MACaddress (not that of the destination node).

See ‘892 patent at 11:57-67.

That is, in this instance, intercepting can be understood as receiving and processing a

packet targeted for a different IP address, regardless of the MAC destination address. The

“deathstar” computer has an IP address of 192.168.1.1 on the 192.168.1.0/24 network, and it

receives and processes a packet with destination IP address of 20.2.51.2.

After intercepting the packet from “warbird” the “deathstar” computer performs the

masquerade address translation. This results in the packet source address 192.168.1.2 being

replaced by a source address 20.2.51.119 that is compatible with the 20.2.51.0/24 network. That

satisfies the modifying requirement of the claims.

7.5.2 Discussion of Anticipation

The’892 patent “Abstract” provides insight into the ‘892 invention.



59

A nomadic router or translator enables a laptop computer or other portable terminalwhich is configured to be connected to a home network to be connected to any locationon the internet or other digital data communication system. The router automatically andtransparently re-configures the terminal to its new location and processes outgoing andincoming data. The router includes a processor which appears as the home network to the

terminal, and appears as the terminal to the communication system. The terminal has apermanent address, the router has a router or translator address, and the terminaltransmits outgoing data to the system including the permanent address as a sourceaddress. The processor translates the outgoing data by replacing the permanent addresswith the router address as the source address. The terminal receives incoming data fromthe system including the router address as a destination address, and the processortranslates the incoming data by replacing the router address with the permanent addressas the destination address. Alternatively, the terminal can be directly connected to a pointon a local network, and the router connected to another point on the network. The routercan be employed to implement numerous applications including nomadic e-mail, network file synchronizer, database synchronizer, instant network, nomadic internet and trade

show router and can also be utilized as a fixed nomadic router.See ‘892 patent Abstract. (Emphasis added.)

There is no doubt from this passage that the intended scope of the ‘892 invention

encompasses a router device that connects to a terminal (host computer) on one side and a

separate LAN on the other side, i.e., according to the abridged figure 12B shown below:

See ‘892 patent Figure 12B (partial)

In fact, this configuration is distinguished from the alternative configuration where both

the router and the host computer are connected directly to the same LAN segment:

Alternatively, the terminal can be directly connected to a point on a local network, andthe router connected to another point on the network.

See ‘892 patent Abstract.

The’892 patent “Disclosure of Invention” also provides similar information regarding the

scope of ‘892

The nomadic router includes a processor which appears as the home network to theterminal, and appears as the terminal to the communication system. The terminal has a



60

permanent address, the nomadic router has a router address, and the terminal transmitsoutgoing data to the system including the permanent address as a source address. Theprocessor translates the outgoing data by replacing the permanent address with the routeraddress as the source address. The terminal receives incoming data from the systemincluding the router address as a destination address, and the processor translates the

incoming data by replacing the router address with the permanent address as thedestination address.

See ‘892 patent at 2:7-19. (Emphasis added.)

As described in the Abstract and Disclosure of Invention, the terminal has a “permanent

address,” which it includes as the source address in any data packets it sends to the Nomadic

router. The Court did not construe the term “permanent address.” From the above specification

disclosures, one of ordinary skill in the art would conclude that “permanent address” is any form

of address that can be used as a source address in a data packet.

The router replaces the source address in the packet with its own “router” address.”

processor translates the outgoing data by replacing the permanent address with the routeraddress as the source address


Kostick96 discloses a permanent address for a “terminal” that is used as the source

address for packets sent by the terminal to the router. The router disclosed in Kostick96 is the

computer “deathstar” having an IP address of 20.2.51.249. The “terminal” disclosed by

Kostick96 is the computer “warbird” at IP address 192.168.1.2. The router processor “ translates

the outgoing data by replacing the permanent address with the router address as the source

address” when it is set up for network masquerading, and it converts the “permanent” source IP

address of “warbird” to the “router” IP address of “deathstar.”

Similarly, the “router” disclosed by Kostick96, i.e., the computer “deathstar” at IP

address 20.2.521.119 receives packets for the “terminal” “warbird” at IP and the router processor

“translates the incoming data by replacing the router address with the permanent address as the

destination address.” This is accomplished by “deathstar” when it translates packets with the



61

destination address 20.2.51.119 to the new destination address of “wardbird” at permanent

address 192.168.1.1.

The claim terms “home network” and “foreign network” were not construed by the Court.

I have adopted the position that the “home network” is the network for which the terminal was

configured when its “permanent address” was established. Conversely, I have adopted the

position that a “foreign network” is any network that has a network ID different from the “home

network” ID. In the disclosures of Kostick96, the “home network” ID is therefore

192.168.1.0/24, while the “foreign network” ID is 20.2.51.0/24.

With this understanding, the disclosures of Kostick96 anticipate the claims of the ‘892

patent.

7.5.3 Claim 1 Analysis

7.5.3.1 allowing network communications over a foreign network for a user device

configured to communicate with a home network

Kostick96 discloses a computer “warbird” configured to communicate on a home

network with the permanent address 192.168.1.2. The capabilities of the “deathstar” gateway

computer are such that they allow “warbird” to communicate over the “foreign network”

20.2.51.0/24. These disclosures mirror the ‘892 patent Abstract:

A nomadic router or translator enables a laptop computer or other portable terminalwhich is configured to be connected to a home network to be connected to any locationon the internet or other digital data communication system.


As seen in Kostick96, a packet is sent from “warbird” targeting a DNS server with an IP

address of 20.2.51.2. The “warbird” computer can access any other host computer on the

“foreign network” 20.1.51.0/24.

7.5.3.2 connecting the user device to the foreign network

Kostick96 discloses a computer “warbird” that connects as the “user device” to the

“foreign network” 20.2.51.0/24. These disclosures mirror the ‘892 patent Abstract:



62

A nomadic router or translator enables a laptop computer or other portable terminalwhich is configured to be connected to a home network to be connected to any locationon the internet or other digital data communication system.


As noted earlier, the ‘892 patent specification, is quite specific in encompassing the

embodiments of figure 12:


7.5.3.3 intercepting packets transmitted from the user device which would

otherwise be dropped by devices on the foreign network





Packets sent from “warbird” with host IP address 192.168.1.2 would be dropped by host

computers on the 20.1.51.0/24 LAN if “warbird” packets were communicated directly on that

LAN. The interception of packets by gateway device “deathstar” is necessary to avoid dropping

the packets when they are communicated on the 20.2.51.0/24 LAN.

I note that the ‘892 patent provides various interpretations of “intercepting” including

interception of ARP packets:

1. Proxy ARP Packet Interception and Host Reconfiguration

Whenever a host computer 12 has an IP packet which it needs to send to a router 26 orother network device, it uses the Address Resolution Protocol (ARP) to obtain the link layer Media Access Control address (MAC address). As illustrated in FIG. 8, when thehost computer 12 broadcasts an ARP request for the MAC address of a destination node,the nomadic router 10 receives this ARP request broadcast and responds with its MACaddress (not that of the destination node).



63

See ‘892 patent at 11:57-67.

That is, in this instance, intercepting can be understood as receiving and processing a

packet targeted for a different IP address, regardless of the MAC destination address. The only

means of determining the target for the packet is the IP destination address.

It can be seen that the example of proxy ARP interception corresponds to “receiving and

processing” packets targeted for another device – namely, a computer with an IP address

different from the proxy ARP gateway. According to the ‘892 patent, a proxy ARP gateway

“intercepts” packets destined for a computer with a different IP address.

The “deathstar” computer has an IP address of 192.168.1.1 on the 192.168.1.0/24

network, and it receives and processes a packet with destination IP address of 20.2.51.2 being

sent to the computer “mccoy.” Therefore the “deathstar” gateway computer is receiving and

processing a packet targeted for another computer, and is clearly performing the act of

“intercepting.”

7.5.3.4 determine without requiring prior knowledge of network settings of the

user device

As seen in Kostick96, the “home network” settings of the computer “warbird” do nothave to be known a-priori. The “network settings of the user device” configured for the

“warbird” home network of 192.168.1.0/24 include the computer’s host IP address of

192.168.1.2, which does not need to be known for the ‘892 patent claims to be practiced.

7.5.3.5 using the determined network settings of the user device to determine

whether to intercept subsequently transmitted packets

Kostick96 describes a Telnet session between the “warbird” computer and the Telnet

server “enterprise.”

For our example, I’ve started a telnet session from warbird to enterprise. Also, on mccoy,I’m using the tcpdump program to monitor the traffic on 20.2.51.0 and sparcbook tomonitor the traffic on 192.168.1.0. receives and processes packets targeted for “mccoy,”“enterprise,” or “relay.”

See Kostock96 at page 3.



64

A Telnet session requires a TCP connection to be established with “enterprise.” The TCP

connection handshake requires “deathstar” to listen for additional packets from “warbird” having

the same “permanent address” as the initial TCP “SYN” request packet. In particular “deathstar”

must listen for the third step of the three way handshake from “warbird” corresponding to the

TCP “ACK” packet. See Stevens at pages 231-235.

It would be obvious to one of ordinary skill in the art that ipfwadm could deny access to

specific IP addresses using setup commands such as that illustrated by Kostick96:

If I had only wanted deathstar to masquerade for enterprise, then I would have typed in:

# ipfw a m all from 192.168.1.2/32 to 0.0.0.0/0


One of ordinary skill in the art could have set a rule to permit only traffic from host

192.168.1.2 to network 20.2.51.0/24, thereby denying access to networks such as 203.20.259.0.

The processing and forwarding of packets from 192.168.1.2 would have been based on the

source IP address and the rule in the forwarding table. This would satisfy the claim step of

“using the determined network settings of the user device to determine whether to intercept

subsequently transmitted packets.” The determined network settings would be the source IP

address.

The gateway “deathstar” must extract the source IP address and TCP port of any arriving

packet from the 192.168.1.0/24 network and compare such addresses/ports to the addresses/ports

in the Linux forwarding tables.

In addition, the program ipfwadm was disclosed in the Kostick96 reference. The

program ipfwadm was available at the time of the Kostick96 disclosures:

Those who use Linux as a filtering firewall and also use ipfwadm should note thatsoftware does not yet support IP masquerading, so ipfw is necessary. [New: ipfwadm2.0beta2, now available for Linux 1.3.66 and newer fromftp://ftp.xos.nl/pub/linux/ipfwadm/, does support masquerading.




65

The program ipfwadm permits policies to be set up to “accept,” “deny,” “reject” or

“masquerade.” See ipfwadm-2.3.0, source code module ipfwadm.c with last modified date of

July 30, 1996 available from http://www.xos.nl/linux/ipfwadm/ . ipfwadm can also be set up to

filter traffic on protocols such as TCP, UDP and ICMP. See ipfwadm-2.3.0, source code module

ipfwadm.c.

The example given Kostick 97 illustrates this behavior:

There are really just two statements given. The first one:

ipfwadm -F -p deny

defines the forwarding policy (-F) of this machine--deathstar from Figure 1. It sets thepolicy to deny all packets to be forwarded by deathstar. Forwarding is the situation wherea packet has a source address and destination address different from any of deathstar’sinterfaces and is to be routed through.


Clearly, it would be obvious to one of ordinary skill in the art to set a “deny” policy on

other hosts on the 192.168.1.0/24 LAN and to block the forwarding of 192.168.1.2 sourced

packets except to specific LANs.

7.5.3.6 automatically modifying packets transmitted from the user device based

on the network settings of the user device and network settings of the

foreign network

The “deathstar” gateway receives packets from the computer “warbird” and translates the

“permanent address” of 192.168.1.2 used as the source address to a new source address of

20.2.51.119.

Kostick96 describes a Telnet session between the “warbird” computer and the Telnet

server “enterprise.” The Telnet request from “warbird” to 20.2.51.33 is intercepted by

“deathstar.”




66


Kostick96 discloses a TCP connection between the “deathstar”(configuration adapter)

and a Telnet server, enterprise at 20.2.51.33.

See Kostick96 Listing 3.


Clearly the packets sent by “warbird” are modified as they pass through the “deathstar”

gateway. The Kostick96 reference satisfies “modifying packets transmitted from the user device

based on the network settings of the user device and network settings of the foreign network.”



The ‘727 patent is entitled “System and method for establishing network connection with

unknown network and/or user device” and has a filing date of October 6, 2000. The inventors

claim priority from the continuation of U.S. application Ser. No. 09/041,534, filed on Mar. 12,

1998, now U.S. Pat. No. 6,130,892.

Nomadix contends that Second Rule infringes claims 11-13, 15, 17, 19 and 20. Claims

11 and 19 are independent claims. Claims 12, 13, 15 and 17 are dependent from claim 11, while

claim 20 is dependent from claim 19.



67

8.1.1 Overview

The ‘727 patent describes a system and method for connecting a mobile computer to a

“foreign” network that is configured with “private IP addresses.” This connection requires a

network “device” that automatically determines network number of the foreign network by

monitoring IP addresses contained in traffic on the foreign network LAN. The network device

may be carried with the mobile computer, or attached as a node on the network.

The network device intercepts mobile computer packets transmitted over the foreign

network. These are packets that contain a source IP address that is incompatible with the foreign

network number. The network device intercepts the packets from the mobile computer, which

contain the mobile computer’s own permanent IP address as a source IP address, without regard

to the packet IP destination addresses.

Packets transmitted by the mobile computer are intercepted and modified to be

compatible with the network. When connected to the foreign network, the mobile computer is

already configured with an IP address that is incompatible with the network.

The device automatically determines the network settings of the user device and/or the

network and modifies packets appropriately so that the user device can communicate over the

network without having to reconfigure the user device with appropriate settings for each network

it may encounter. Communication settings such as network address, gateway, proxy address, etc.

are automatically determined using various techniques.

8.1.2 Priority Date

The ‘727 patent application is a continuation of U.S. application Ser. No. 09/041,534,

filed on Mar. 12, 1998, now U.S. Pat. No. 6,130,892. Both applications disclose a “nomadic

router” that is configured for a home network, which can be operated on a “foreign network”

because of the capabilities of the nomadic router.



68

The ‘892 patent was based on an application that was a continuation-in-part of U.S.

patent application Ser. No. 08/816,174, entitled “NOMADIC ROUTER,” filed on Mar. 12, 1997,

now abandoned. I have reviewed U.S. patent application Ser. No. 08/816,174 and, in my

opinion, the claims of the ‘727 patent are not supported by the original parent application Ser.

No. 08/816,174. I have therefore concluded that the proper priority date for the ‘727 patent is

March 12, 1998. See section 7.1.2 for detailed analysis.

8.1.3 ‘727 Claims

The asserted claims of the’727 patent read as follows:

11. A method for providing access to a network utilizing private IP addresses for a user

device having an incompatible private IP address, the method comprising: interceptingdata transmitted by the user device containing the incompatible private IP address;modifying the data using a private IP address compatible with the network private IPaddresses; and transmitting the modified data on the network.

12. The method of claim 11 further comprising connecting a translator to the network toperform the steps of intercepting the data transmitted by the user device, modifying thedata, and transmitting the data.

13. The method of claim 12 wherein the step of connecting comprises connecting thetranslator between the user device and the network.

15. The method of claim 11 wherein the step of intercepting packets comprises receiving

and processing packets which would otherwise be dropped by devices on the second localarea network due to incompatible network settings.

17. The method of claim 11 wherein the step of intercepting packets comprises:intercepting an Address Resolution Protocol (ARP) message transmitted by the userdevice; and replying to the ARP message with a hardware address of a device on thenetwork so future messages transmitted by the user device are directed to the device onthe network.

19. A method for providing connectivity to a first network for a user device, the userdevice having a permanent address, the method comprising:

automatically determining network settings of the first network based on addressescontained in messages transmitted over the first network;

intercepting user device messages transmitted over the first network without regard tomessage destination addresses, the user device messages having the permanent address of the user device as a source address;

and modifying incorrectly configured messages transmitted by the user device based onthe network settings of the foreign network,



69

wherein modifying incorrectly configured messages transmitted by the user deviceincludes substituting the permanent address of these messages with a router address asthe source address,

wherein the router address is an address recognized by the foreign network.

20. The method of claim 19 wherein the user device is configured to communicate over ahome network having network settings incompatible with the foreign network, themethod further comprising:

automatically determining network settings of the user device by intercepting an AddressResolution Protocol (ARP) message transmitted by the user device having a destinationaddress of a device on the home network

and replying to the ARP message by associating a Media Access Control (MAC) addressof a device on the first network with the destination address of the device on the homenetwork.

See ‘727 patent claims 11-20.


Term at Issue Court’s Constructions

Claim 17 :intercepting


Claim 11:data

information contained in one or more packets


During the prosecution of the’727 patent, the applicants responded to an Office Action

mailed October 5, 2005, in which the Examiner rejected claims 1, 11, and 18-20 because of

failure to comply with the enablement requirement. The applicants pointed out that the term

“foreign device” was used in order to distinguish it from the “user device.”

Regarding independent claim 1, the Examiner posited that the terms “foreign network”,“network setting”, and “intercepting packets transmitted from the user [device] and thenetwork” lack support in the written description. The Applicant notes that claim 1 recites“foreign device” as opposed to “foreign network”; and recites “intercepting packetstransmitted by the foreign device” as opposed to “intercepting packets transmitted by theforeign network”. The Applicant respectfully submits that the written descriptionprovides support for all of the limitations set forth in claim 1 for the following reasonsbelow.

See ‘727 File History at N003903.



70

Also, “network settings of the user device” and “network settings of the second local area

network” were defined in terms of computer configurations:

settings which may require “reconfiguration (e. g., IP address configuration, gateway or

next hop router address, netmask, link level parameters, and security permissions)”See ‘727 File History at N003904.

With regard to the terms “intercepting packets transmitted by the user device” and

“intercepting packets transmitted by the foreign device,” the applicants described the role of the

nomadic router in the following manner:

“intercepts the message [i. e., packets]” transmitted by a user device (page 2, lines 20-25); “intercepts packets from the host [i.e., the user device)” (page 4, lines 27-29);pretends to be the router for which the host is configured and pretends to be the host with

which the router expects to communicate (page 5, lines 1-3)


For independent claim 11, the applicants responded to the Examiner’s statements that

“intercepting data,” “modifying the data,” and “transmitting the modified data,” “private IP” and

“incompatible private IP” lacked support in the written description. Intercepting, modifying and

transmitting data were described in the following way:

The specification describes, for example, that the Nomadic Router of the present

invention “automatically and transparently reconfigures packets sent to/from the terminal[i.e., the user device] for its new location by processing outgoing and incoming data”(page 2, lines 17-19); “intercepts the message [i. e., packets]” transmitted by a userdevice (page 2, lines 20-25); “intercepts packets from the host [i.e., the user device]”(page 4, lines 27-29); pretends to be the router for which the host is configured andpretends to be the host with which the router expects to communicate (page 5, lines 1-3);“translates the data allowing the host [i.e., user device] to think that it is communicatingwith its home router” (page 5, lines 9-10); “will automatically intercept and translatepackets” communicated between a host computer (i.e., a user device) and a network (page 11, lines 8-21); “translates[s) packets transmitted/received by the host computer [i.e., the user device]” such that “for outbound traffic from host computer 12 to network 14,

the translation function changes the content of the packet . . . causing all packets sent outto network 14 to be directed back to nomadic router 10 rather than to host computer 12”and such that “inbound traffic from network 14 arriving at nomadic router 10 (which isreally for host

See ‘727 File History at N003906-7.



71

Applicants portrayed the term “private IP address” as an IP address supplied by the

nomadic router:

the Nomadic Router provides “a permanent IP address” to the user device (page 4, lines

1-2); the Nomadic Router includes a first module for storing a digital communicationaddress of a user of a user device, a second module for detecting a data communicationnetwork location to which the user device is connected, and a fourth module forestablishing data communication between the user device and the network such that thecommunication address of the data communication network location is automaticallyconverted to the communication address of the user (page 4, lines 1322);


In addition, they portrayed the “incompatible private IP” address as an IP address

specified according to a “home internet or IP address” that does not need to be changed when the

user computer is moved to a new network:

the user device has a “permanent internet address which conveniently need not bechanged in accordance with the present invention” (page 9, lines 16-17)~ the user devicehas a “home internet or IP address” (page 9, lines 25-26); the Nomadic Router “providesthe mapping between the location based IP address used in the internet today and thepermanent user based address housed in the CPU in the [user] device 12” (page 12, lines10-14;


As disclosed by the applicants in the File History, the nomadic router maintains a table of mappings between the permanent (incompatible private IP) addresses and the temporary (private

IP) addresses:

the “IP Mapping” element); the Nomadic Router has a protocol for specifying the“mapping between permanent and temporary IP addresses” (page 12, lines 15-21); theNomadic Router translates the content of a packet transmitted by the user device to“change the source address to match that of the nomadic router’s address instead of thehost computer’s [i.e., the user device’s] address” (page 22, line 28 through page 23, line1; see also FIGS. 9A and 9B and related description on page 22, line 7 through page 23,line 24).




72


I have previously offered the opinion that the ‘727 patent is invalid because of lack of

enablement. See Alexander Declaration in Support of Second Rule’s Motion for Partial

Summary Judgment, September 4, 2008 at 109-120.

Claims 11-13, 15, 17, 19 and 20 of the ‘727 patent are not enabled. In my opinion the

‘727 patent does not provide enablement of the terms “private IP addresses” and “incompatible

private IP address.” (Claim 11.) The term “private IP address” appears in claim 11 five times.

However, neither “private IP address “nor “incompatible private IP address” are mentioned

elsewhere in the patent. Specifically, those terms are not present in the written description and

are not enabled. Nor does the ‘727 patent enable the term “modifying the data using a private IP

address compatible with the network private IP addresses.” (Claim 11.) Finally, the method of

“providing access” is not enabled. (Claim 11.)

In my opinion, the claim term “incorrectly configured messages” cannot be

comprehended and is not enabled. (Claim 19.) The term “permanent address” is ambiguous.

(Claim 19.) In addition, the language of claim 19 includes the term “permanent address,” which

is not enabled. Finally, the ‘727 patent claim 19 does not enable a method that is different from

well-known and pre-existing IP Mobility Standards.

8.4 Stevens Anticipates the Claims of the ‘727 Patent

One or more of the following references discloses the subject matter of the asserted ‘727

claims.

TCP/IP Illustrated, Volume 1, W. Richard Stevens, pp.60-62, 1994. (“Stevens”)

RFC 1009 Braden et al “Requirements for Internet Gateways,” June 1987RFC 1027 “Using ARP to Implement Transparent Subnet Gateways,” Carl-Mitchell et al,October 1987


As noted above, the ‘727 patent is invalid because of lack of enablement. If one of

ordinary skill in the art were to use the disclosures of the File History as a guide, the patent



73

claims could be read in a very simple way that would be anticipated by prior art. The File

History disclosures and claims 11-13, 15, 17, 19 and 20 read on the following LAN network:

See ‘727 patent Figure 12E (partial)

That is, in one potential interpretation of the claim language, a user device (e.g. Host

Computer 12a) is attempting to communicate with another device (e.g., Host Computer 12n) via

a local area network.

8.4.1 ARP Packet Structure

See section 5.5.

8.4.2 Proxy ARP

Proxy ARP nodes have been used for many years on network segments in order to

accommodate ARP requests from hosts that are configured with an “incompatible” IP address,

i.e., the subnet that the host is connected to is configured with an IP address that has a Network

ID different from the Network ID assigned to LAN segment itself. There are numerous

examples of these configurations pre-dating the priority date of the ‘727 patent, including one

from Stevens shown below:



74

See Stevens Figure 4.6, page 61


Claim 11 recites:

11. A method for providing access to a network utilizing private IP addresses for a userdevice having an incompatible private IP address, the method comprising: interceptingdata transmitted by the user device containing the incompatible private IP address;modifying the data using a private IP address compatible with the network private IPaddresses; and transmitting the modified data on the network.

See ‘727 patent claim 11.

Claim 11 therefore recites LAN access for a user computer (12a) wherein the other LAN

devices (12b-12n) are “utilizing private IP addresses” appropriate for the Network ID of the

LAN shown in Figure 12E of the ‘727 patent. The user device (12a) is configured with an IP

address that uses a different Network ID than the devices 12b-12n.

Claim 11 recites “intercepting data transmitted by the user device” (i.e. 12a), modifying

the packet from the user device (12a) to change the IP address to one that has the same Network



75

ID as all other devices (12b-12n) on the LAN, and compatible with the network private IP

addresses; and transmitting the modified packet on the LAN network.

One of ordinary skill in the art would understand “intercepting data transmitted” to be

satisfied by data that is in an ARP request captured at a Proxy ARP node. Under the Court’s

construction of “intercepting,” namely “receiving and processing [e.g., data, packets] targeted for

another device,” the receiving and processing of payload data of an ARP request would satisfy

the claim step. In a Proxy ARP scenario, the user device packet would have the wrong source

and destination Network ID for the LAN.

Similarly, the step involving “modifying the data” is satisfied by ARP payload data that

is captured and modified by a Proxy ARP node. Under the Court’s construction of “data,”

namely “information contained in one or more packets,” modifying the payload data of an ARP

request would satisfy this claim step. Also, modifying the data using a private IP address is

satisfied because the Proxy ARP node has an IP address that is compatible with the LAN

Network ID. That is, the device at the “private IP address” is used to modify the physical

address embedded in the payload data11.

Finally, “transmitting the modified data” is satisfied by the ARP response generated by a

Proxy ARP node on the LAN. The modified data includes modifications to the sender/target

physical address fields, as follows:

User node MAC address moved from request “source MAC address” field to response“target MAC address” field

Proxy ARP node MAC address moved to response “source MAC address field.”

Thus, the claim limitation of the “modifying the data using a private IP address

compatible with the network private IP addresses; and transmitting the modified data on the

network “ is satisfied by the Proxy ARP node. The functionality recited by the claim is identical

11 In the ARP response packet, Proxy ARP nodes return the proxy’s own MAC address as the “source MAC

address” and the requested target IP address (from the ARP request) in the response source IP address.



76

to that provided by the “Proxy ARP” interception technique. See Stevens, pages 60-62 and RFC-

1009, RFC 1027, and RFC 1919.12



See ‘727 patent at claim 12.

In claim 12 a translator is used on the same LAN (“utilizing private IP addresses”). This

translator corresponds to the Nomadic Router of Figure 12E, element 10.

See ‘727 patent Figure 12E (partial)

This functionality is identical to that provided by the “Proxy ARP” interception

technique. See Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC 1919.




12 See Stevens TCP/IP Illustrated Volume 1, pp.60-62, RFC 1009 Braden et al “Requirements for Internet

Gateways,” June 1987, RFC 1027 “Using ARP to Implement Transparent Subnet Gateways,” Carl-Mitchell et al,

October 1987, and RFC 1919, M. Chatel, “Classical Versus Transparent IP Proxies, March 1996.



77

Claim 13 merely inserts the translator between the user’s computer and the LAN

(network “utilizing private IP addresses”). Figure 12B of the ‘727 patent illustrates this

configuration, where the recited “translator” is element 10.



technique. See Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC 1919. Stevens illustrates

a proxy ARP device separating two LANs that have the same Network IDs, which would apply

equally to Figure 12B above, where one of ordinary skill in the art would understand that both

network interfaces of the Nomadic Router could be using the same Network ID.

Alternatively, if 10a and 10b correspond to two different network IDs, then this

configuration is disclosed by Stevens. See Stevens, pages 60-62, RFC-1009, RFC 1027, and

RFC 1919. Although the ‘727 specification is vague on this point, it alludes to the possibility

that the Nomadic Router interfaces 10a and 10b shown in Figure 12B are for one Network ID

and not two different IDs:

Router 10 includes a terminal interface 10a which normally is used to connect router 10to host device 12, and a system interface 10b which connects router 10 tocommunications device 14. Router 10 generally includes a processor consisting of hardware and/or software which implements the required functionality. Router 10 isfurther configured to operate in an alternate mode in which host device 12 is connecteddirectly to a network, and router 10 is also connected to a point in the network via system

interface 10b. In this case, terminal interface 10a is unused.Although device 10 is described herein as being a router, it will be understood that router10 is not a conventional router in that it includes the capability for providinginterconnectability between networks. Instead, router 10 is essentially a translator whichenables host device 12 to be automatically and transparently connected to anycommunications device 14, and process incoming and outgoing data for device 12.

See ‘727 patent at 5:56-6:6.



78


Claim 15 recites the interception of packets that would otherwise be dropped by devices

on the LAN due to incompatible network settings.

15. The method of claim 11 wherein the step of intercepting packets comprises receivingand processing packets which would otherwise be dropped by devices on the second localarea network due to incompatible network settings.



technique. See Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC 1919. In the absence of a

Proxy ARP node on the LAN, a user device broadcasting ARP requests for IP addresses related

to its “incompatible private IP” Network ID would not receive an ARP reply because there

would be no devices on the LAN with network addresses using that Network ID, and the ARP

broadcast would not be extended beyond the LAN itself.


Claim 17 mirrors claim 15, but is more explicit in its recitation of ARP requests.



Here claim 17 simply recites the use of the standard “proxy ARP” techniques. This

functionality is identical to that the “Proxy ARP” interception technique disclosed publicly for

several decades. See Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC 1919.

It is also notable that this claim, which is dependent from claim 11, sheds light on the

claim 11 language of “intercepting data transmitted by the user device containing the

incompatible private IP address.” Claim 17 illustrates without ambiguity that data in an ARP

request packet is data transmitted by the user device. Claim 17 is specific to the “intercepting”



79

step, which in claim 11 involves “intercepting data transmitted by the user device “ while in

claim 17 it involves “intercepting an Address Resolution Protocol (ARP) message transmitted by

the user device.” Because Claim 17 depends from Claim 11, Claim 11 must also include in its

scope the interception of an ARP message transmitted by the user device.


Claim 19 provides most of the limitations in the claims already discussed, but it does not

require private IP addresses, and further introduces a connection to a “router.” As noted above,

the Nomadic Router is understood to not perform as a conventional router that interconnects two

Network IDs. Instead it performs as a translator. See section 8.4.3 above and the ‘727 patent at

5:56-6:6. One of ordinary skill in the art would understand the “router” recited in claim 19 to be

a classical layer-3 interconnection between two different IP Network IDs.

Claim 19 reads as follows:



intercepting user device messages transmitted over the first network without regard tomessage destination addresses, the user device messages having the permanent address of the user device as a source address;




See ‘727 patent at claim 19. (Emphasis added.)

However, I note that this method claim does not recite the use of any particular

“translating” or “intercepting” device. In fact the claim reads on the following network

configuration where the router itself performs the Proxy ARP functions:



80

See ‘727 patent Figure 12A (partial).

Thus, the router itself can perform the interception and translation, as well as the ARP

response steps of “modifying incorrectly configured messages transmitted by the user device”

based on the LAN Network ID, and “substituting the permanent address of these messages with a

router address as the source address.” This is none other than the functionality of the Proxy ARP

interception technique disclosed publicly for several decades. See Stevens, pages 60-62, RFC-

1009, RFC 1027, and RFC 1919.

Other references explicitly disclose a router configured as a Proxy ARP gateway.

SeeTanenbaum96 at page 421-423

13

.

13 Computer Networks, Third Edition, Andrew Tanenbaum, 1996.



81

Also noteworthy is that the claim language of “user device messages transmitted over the

first network without regard to message destination addresses” applies to ARP messages that are

broadcast on the LAN. They are certainly without regard to destination address.


Claim 20 is dependent from claim 19 and further limits the scope of the claim to

explicitly require interception of an ARP request. The ARP request is intercepted despite the

fact that the user computer is configured with an IP address that does not match the LAN

Network ID. This is a recitation of the standard Proxy ARP technique.

20. The method of claim 19 wherein the user device is configured to communicate over a

home network having network settings incompatible with the foreign network, themethod further comprising:



First I note that, according to the claim, the “network settings” of the user device are

discerned entirely from the contents of an ARP request packet. The ARP request and ARP

response packets have a standard format14. An ARP request packet contains the senders MAC

address in the Ethernet header, as well as the LAN broadcast address (all 1s) for the Ethernet

destination address. The ARP request packet payload includes the sender’s MAC address,

sender’s IP address, and target IP address. A node responding to the ARP request replies with its

own MAC address in the Ethernet header and in the payload.

Hence, one of ordinary skill in the art knows that for this claim the recited automatically

determined “network settings” of the user device include only the user device’s MAC address

and IP address.

14 See Stevens, TCP Illustrated Volume 1, page 56 and RFC 826 “Packet Format” section.



82

The claim language reads on the following system configuration:

See ‘727 patent Figure 12A (partial).

A router or gateway set up as a Proxy ARP node satisfies this claim language. Replying

to the ARP message by “associating a Media Access Control (MAC) address of a device on the

first network with the destination address of the device on the home network” would be

understood by one of ordinary skill in the art to mean responding with an ARP response packet

that contains physical MAC address and a LAN IP address that has the same Network ID as the

LAN configuration, so that the user device will cache the ARP response address pair for use in

addressing future

This is none other than the functionality of the Proxy ARP interception technique

disclosed publicly for several decades. See Stevens, pages 53-62, RFC-1009, RFC 1027, and

RFC 1919.

8.5 Kostick96 Using Linux IP Masquerading Renders the Claims of the






the ‘727 patent.





83




Kostick96 figure 1 illustrates the basic operation of IP packet masquerading. The

behavior of this network configuration is described by Kostick96:

Let’s decode this stuff. First, the earliest packet is at the bottom. It is a DNS request(therefore UDP) from 192.168.1.2 to 20.2.51.2. mccoy is warbird’s DNS server in thiscase. The Masq column shows us the port on deathstar that is used for the masquerading.For the first DNS request, it is port 60000 (EA60). After the DNS resolution, the TCPconnection is established on the next available port over 60000, 60001. Figure 2illustrates the protocol time-line for the sequence of events up to the TCP open.


Similarly, RFC1631 discloses the processing of a network packet by replacing its source

address with a different source IP address before forwarding the packet to a different network.



84






See section 7.5.1 for additional discussion.

8.5.2 Discussion of Obviousness

The claim term “private IP address” is not defined in the specification of the ‘727 patent,

nor was that term construed by the Court. The term “private IP address” appears in claim 11 five



85

times. However, neither “private IP address “nor “incompatible private IP address” are

mentioned elsewhere in the patent. Specifically, those terms are not present in the written

description and are not enabled. Nor does the ‘727 patent enable the term “modifying the data

using a private IP address compatible with the network private IP addresses” in claim 11.

If the term “private IP address” is interpreted very narrowly to be an IP address from one

of the one of the reserved address blocks that is not published on the Internet15, then it would still

have been obvious to apply the teachings of Kostick96 to a scenario where the network

20.2.51.0/24 was replaced with a private network block in the reserved range of 10.0.0.0 -

10.255.255.255, such as 10.71.1.0/24. It would have been obvious to one of ordinary skill in the

art to use the Kostick96 masquerading configured computer to satisfy the claim steps of the ‘727

patent. This analysis is not necessary for claims 19 and 20, which do not require private IP

addresses.

Moreover, one of ordinary skill in the art would have been motivated to do so because of

the desire to create a solution that did not require a reconfiguration of the user’s computer when

attached to a private network in a hotel, when traveling away from the user’s own private office

network, without changing the host IP address.

For example if a user normally attaches the user computer to an office network that is

configured for a “private IP” block, it is possible that the computer will be configured with a

static IP address on the office network. This would occur if the user has servers on the network,

including the user’s own computer, that require static IP address assignments. This might be the

case when the user’s office network has its own DNS server for mapping machine names to IP

addresses.

15 See RFC 1597, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot,

March 1994 (“RFC1597”)



86

That scenario might result in the user’s computer being configured with a static host IP

address of 192.168.1.2, which the user does not want to be modified when on travel so that the

computer will operate correctly when it is once again re-connected to the office network.

When the user travels and connects the computer to a hotel network (e.g., 10.71.1.0/24)

the user’s computer will be incompatible with the hotel’s network and will not function. The

user would then be motivated to insert a device such as the Kostick96 masquerading router to

translate from the 192.168.1.2 static “incompatible private IP address” to one of the hotel’s

10.71.1.0/24 “compatible private IP” addresses (most likely assigned to the outside port of the

NAT router via DHCP on the hotel network.

Expressed in terms of the ‘727 patent Figure 12B illustrated below, the IP address of the

user’s computer will be 192.168.1.2, element 10 would be the Kostick96 masquerading router,

the outside address of the router at element 10b would be 10.71.1.101, and the hotel network,

represented by element 14 of the figure, would be a network ID such as 10.71.1.0/24.


In this scenario the user benefits from the fact that the computer 12 statically configured

IP address is not modified while the user is on travel.


Claim 11 recites:





87

Claim 11 therefore recites five important component steps: (1) a user device having an

incompatible private IP address; (2) providing access to a network utilizing private IP addresses;

(3) intercepting data transmitted by the user device containing the incompatible private IP

address; (4) modifying the data using a private IP address compatible with the network private IP

addresses; (5) transmitting the modified data on the network.

8.5.3.1 a user device having an incompatible private IP address

In this scenario, it is posited that the Network ID is 192.168.1.0 representing the user’s

home network. The network containing compatible IP addresses is Network ID 20.2.51.0.

Kostick96 discloses the “warbird” computer, representing the patent “user device,”

configured with a host IP address of 192.168.1.2 that is incompatible with the 20.2.51.0/24

network. See section 8.5.1. When “warbird” sends a DNS request to the DNS server “mccoy” it

does so with a source IP address in the packet that is incompatible with network addresses in the

range 20.2.51.0/24.

8.5.3.2 providing access to a network utilizing private IP addresses

Kostick96 discloses the providing of access to the network 20.2.51.0/24 via a computer

referred to as “deathstar.” The Kostick96 Linux computer called “deathstar” has two network

interfaces, one to the incompatible network 192.168.1.0/24 and one to the network 20.2.51.0/24.

The computer “deathstar” corresponds to the ‘727 patent nomadic router. Without the specially

configured “deathstar” computer, the DNS request packet from “warbird” would not be sent to

the “mccoy” DNS server.

8.5.3.3 intercepting data transmitted by the user device containing the

incompatible private IP address

Thus, the user device has an incompatible IP address of 192.168.1.2 (“warbird”). The

user device has an IP address that is incompatible with the outside Network ID 20.2.51.0.

When the user device performs a DNS lookup on 20.2.51.2 (“mccoy”) the masquerading

router intercepts the request. The packet contains an incompatible IP address.



88

As noted in section 8.5.1, intercepting can be understood as receiving and processing a

packet targeted for a different IP address, regardless of the MAC destination address. The

“deathstar” computer has an IP address of 192.168.1.1 on the 192.168.1.0/24 network, and it

receives and processes a packet with destination IP address of 20.2.51.2. Therefore it satisfies

the Court’s construction for “intercepting.”

8.5.3.4 modifying the data using a private IP address compatible with the network

private IP addresses

Then the masquerading router (“deathstar”) disclosed by Kostick96 performs an address

translation by assigning its outside IP address 20.2.51.119 and an ephemeral TCP port number.

This means that the incompatible IP address in the packet is replaced by a compatible IP address.

That satisfies the modifying requirement of the claims, wherein the “deathstar” computer

replaces the “incompatible private IP address” of 192.168.1.2 with a “compatible IP address” of

20.2.51.119.

8.5.3.5 transmitting the modified data on the network

The disclosure of Kostick96 includes a DNS request to the DNS server “mccoy.” The

“deathstar” computer forwards the DNS request to “mccoy” after modifying packet contents.

Therefore Kostick96 satisfies this claim step.




In claim 12 a translator is used on the same LAN (“utilizing private IP addresses”) The

Linux computer “deathstar” performing masquerading router address translation corresponds to

the translator of the ‘727 patent, claim 12.



89




Kostick96 figure 1 discloses the use of the Linux masquerading translator between the

user’s device (“warbird”) and the network 20.2.51.0/24.






Without the Kosick96 Linux masquerading router, packets from the user device

(“warbird”) would be ignored on the network 20.2.51.0/24. Therefore Kosick96 satisfies this

claim.


Claim 17 mirrors claim 15, but is more explicit in its recitation of ARP requests.



Here claim 17 simply recites the use of the standard “proxy ARP” techniques. This

functionality is identical to that the “Proxy ARP” interception technique disclosed publicly for

several decades. See Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC 1919.



90

It would be obvious to one of ordinary skill in the art to combine Kosick96 with any one

of the Proxy ARP disclosures such as Stevens, pages 60-62, RFC-1009, RFC 1027, and RFC

1919.


Claim 19 reads as follows:



intercepting user device messages transmitted over the first network without regard to

message destination addresses, the user device messages having the permanent address of the user device as a source address;




See ‘727 patent at claim 19. (Emphasis added.)

Kostick96 determines the network settings of the 192.168.1.0/24 network by monitoring

the incoming packets from the 192.168.1.1 interface of “deathstar.” As noted in section 8.5.3.3,

“deathstar” intercepts messages from the computer “warbird” without regard to the message

destination address in the received packets. The messages from “warbird” contain 192.168.1.2

as the source IP address.

The computer “deathstar” modifies the incoming packets from “warbird” to satisfy the

“foreign network” 20.2.51.0/24, as discussed in section 8.5.3.4. These packets received by

“deathstar” are incorrectly configured for the foreign network 20.2.51.0/24. The modifying of

the packet includes substituting the router’s “compatible address” 20.2.51.119 as the source

address, in place of the “incompatible source address”192.168.1.2.address. The router address

20.2.51.119 is an address recognized by the foreign network 20.2.51.0/24.



91



explicitly require interception of an ARP request. The ARP request is intercepted despite the

fact that the user computer is configured with an IP address that does not match the LAN

Network ID.




The computer “warbird” will have a gateway IP address that is on compatible with the

foreign network 20.2.51.0/24. In the examples given by Kostick96 it is configured with a

gateway IP address of 192.168.1.1, which is the address of a device on the home network

192.168.1.0/24. To locate the gateway at 192.168.1.1, “warbird” sends ARP request messages

with a destination address on the home network, namely 192.168.1.1.

The “deathstar” machine associates its own MAC address on the network interface

20.2.51.119 with the gateway IP address 192.168.1.1, and uses that association to forward

packets from “warbird” to devices on the 20.2.51.0/24 network.

8.6 Weiman Renders the Claims of the ‘727 Patent Obvious





See section 7.4.1



92

8.6.1 Discussion of Obviousness

The claim term “private IP address” is not defined in the specification of the ‘727 patent,

nor was that term construed by the Court. The term “private IP address” appears in claim 11 five

times. However, neither “private IP address “nor “incompatible private IP address” are

mentioned elsewhere in the patent. Specifically, those terms are not present in the written

description and are not enabled. Nor does the ‘727 patent enable the term “modifying the data

using a private IP address compatible with the network private IP addresses” in claim 11.

If the term “private IP address” is interpreted very narrowly to be an IP address from one

of the one of the reserved address blocks that is not published on the Internet16, then it would still

have been obvious to apply the teachings of Weiman to a scenario where the local and foreign

networks were specified to be in one of the reserved address blocks. It would have been obvious

to one of ordinary skill in the art to use the Weiman configured remote controller to satisfy the

claim steps of the ‘727 patent.

See section 8.5.2 for additional discussion of motivation.


Claim 11 recites:



Claim 11 therefore recites five important component steps: (1) a user device having an

incompatible private IP address; (2) providing access to a network utilizing private IP addresses;

16 See RFC 1597, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot,

March 1994 (“RFC1597”)



93

(3) intercepting data transmitted by the user device containing the incompatible private IP

address; (4) modifying the data using a private IP address compatible with the network private IP

addresses; (5) transmitting the modified data on the network.

8.6.2.1 a user device having an incompatible private IP address

The Weiman reference discloses a user device, referred to as a “portable device 103”

connected to a “remote network 113.” The network settings for the portable device are

compatible with the “local network 101.” That is, the portable device has an “incompatible IP

address. It would be obvious to one of ordinary skill in the art that the local network ID could be

one of the reserved Internet address blocks.

See also section 7.4.2.1 regarding Weiman.

8.6.2.2 providing access to a network utilizing private IP addresses


connected to a “remote network 113.” The network settings for the portable device are

compatible with the “local network 101.” The portable device accesses the “remote network.” It

would be obvious to one of ordinary skill in the art that the remote network ID could be one of

the reserved Internet address blocks.

See also section 7.4.2.1 regarding Weiman.

8.6.2.3 intercepting data transmitted by the user device containing the

incompatible private IP address


connected to a “remote network 113.” Packets received from the portable device are intercepted

by the remote controller. See section 7.4.2.2. The network settings for the portable device are

compatible with the “local network 101” and are incompatible with the “local network 101.” It

would be obvious to one of ordinary skill in the art that the local network ID and the remote

network ID could be selected from the reserved Internet address blocks.



94

See section 7.4.2 regarding Weiman.

8.6.2.4 modifying the data using a private IP address compatible with the network

private IP addresses


connected to a “remote network 113.” Packets received from the portable device are intercepted

by the remote controller. See section 7.4.2.2. The network settings for the portable device are

compatible with the “local network 101” and are incompatible with the “local network 101.”

The data transmitted from the portable device is modified using a private IP address

compatible with the “remote network 113.” See section 7.4.2.5 regarding data modifications

disclosed by Weiman.

8.6.2.5 transmitting the modified data on the network

Weiman satisfies this claim step:

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529.


See also Weiman at 9:9-10:7 generally.




The remote controller in Weiman is connected to the network (“remote network 113”)

and performs the recited steps of intercepting data transmitted by the portable device. See

section7.4.2.2.



95




Weiman Figure 1 clearly discloses the “remote controller 115” between the “portable

device 103” and the “remote network 113.”






Without the Weiman remote controller, packets from the user portable device would be

ignored on the remote network. Therefore Weiman satisfies this claim step.


Claim 17 recites the interception of ARP requests:



Weiman discloses the interception of ARP packets transmitted by the user “portable

device.”Block 509 determines if this is an ARP Request. If it is not, then execution of thesoftware checks to see if it is an ARP reply. If it’s not that, there are other ARP or RARPcombinations that it could be. In Block 513 execution of the software returns withoutprocessing the packet.

At Block 515, the packet is an ARP Request. Execution of the software checks to see didit come from one of the network interfaces of the portable devices. If it did, then



96

execution of the software checks to see if the portable device is ARP’ing for itself. Onboot up they do that. If that’s the case, then in Block 519 execution of the softwarereturns without processing the packet. If execution of the software answers that ARP,then the portable device would operate as if some other machine on the network had itsProtocol Address and it would stop talking on the Network and provide an error message

saying some other device its Protocol Address.

Moving on to Block 521, execution of the software searches for the portable device tablefor an entry whose Protocol Address matches the sender’s. In Block 523 execution of thesoftware checks to see if this was found. If not, in Block 525 execution of the softwarecreates a new entry in the table. The Entry’s time-first-used is timeNow, which is usedfor some of the management protocol messages.

See Weiman at 8:59-9:15.

Therefore Weiman satisfies the claim step of “intercepting packets comprises:

intercepting an Address Resolution Protocol (ARP) message transmitted by the user device.”

The ARP response sent by the remote controller contains the controller’s hardware

address:

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529.

SeeWeiman at 9:28-35.


Claim 19 provides most of the limitations in the claims already discussed other than

private IP addresses, but further introduces a connection to a “router.” Weiman discloses a

router.

Weiman also discloses modifying portable device messages transmitted over the remote

network including substituting the sour IP address of these messages with the remote controller

address as the source address. See Expert Report section 7.4.2 and Weiman 9:9-12:45.

The characteristics of the remote network are determined automatically. The remote

controller determines the characteristics of the remote network using the BOOTP protocol. The



97

BOOTP messages transmitted over the remote network contain IP addresses that indicate the

network ID of the remote network:

Execution of the software sends BOOTP broadcasts, but this is only done if the site

Protocol Address is not yet determined.See Weiman at 7:15-17.

In Block 503 execution of the software performs a test for the Protocol Address of thesite Network. That would come in from either BOOTP responses from the broadcast orfrom the parsing of the ASCII text file.


See also Weiman Figure 5.



explicitly require interception of an ARP request.


automatically determining network settings of the user device by intercepting an AddressResolution Protocol (ARP) message transmitted by the user device having a destination

address of a device on the home network and replying to the ARP message by associating a Media Access Control (MAC) addressof a device on the first network with the destination address of the device on the homenetwork.

Weiman discloses the interception of ARP request packets from the user portable device

and the determination of network settings of the portable device. See Weiman at 8:64-9:8.

Weiman also discloses associating a MAC address from the remote network with the destination

address on the local network.

Execution of the software copies the sender’s Protocol Address and Physical Address intothe table entry, and builds an ARP-response packet. The sender address is thecontroller’s, destination Address is the portable devices (meaning both Protocol andPhysical Address). So now the ARP Request from the portable device is then as aresponse back to the portable device and the procedure returns in Block 529




98

See also analysis of sections 7.4.2 for additional details of Weiman processing.


The ‘894 patent is entitled “Systems and methods for redirecting users having transparent

computer access to a network using a gateway device having redirection capability” and has a

filing date of Dec. 8, 1999. A Provisional Patent Application Ser. No. 60/111,497 was filed on

Dec. 8, 1998. Claims 1 and 6 are independent claims. Claim 6 is an apparatus claim that mirrors

the method claim of claim 1.

Nomadix asserts that claims 1 and 5-10 are infringed by Second Rule.


9.1.1 Overview

The ‘894 patent claims systems and methods that redirect browser requests from users

using a gateway device is in communication with an Authentication, Authorization and

Accounting (AAA) server. The AAA server determines if a user is entitled to access the

destination network based upon the access information stored in a user profile database. The

AAA server redirects the user to a different destination address.

The gateway receives an access request that is formulated in terms of an “original

destination address” for the request. The gateway determines, based on some unique

characteristic of the user, if the request requires redirection. If redirection is necessary, the

gateway first stores the original destination address, and then modifies the request so as to

forward the request to a redirection server if redirection is required.

The redirection server responds to the modified request with a browser redirect message

that specifies reassignment of the request to an administrator-specified, redirect destination

address. As the browser redirection response packet is passed back through the gateway, it is

intercepted by the gateway and modified so that it contains the original destination address. The



99

modified browser redirect message is then sent to the user’s computer where the web browser

automatically redirects the computer to the redirected destination address.

In one of the claims the redirection server provides a redirection message that reassigns

the modified request to a redirected destination address that returns a login page to the user’s

browser. Other claims recite storing user-access information in a user profile database and the

determination of whether a computer user is entitled to access the original destination address

based upon the user-access information stored within the user profile database.

9.1.2 ‘894 Priority Date

The ‘894 patent identifies a provisional application No. 60/111,497, filed on December 8,

1998. I have reviewed this application and it is my opinion that the provisional application does

not provide support for the claims of the ‘894 patent. I am therefore of the opinion that the

correct priority date for the ‘894 patent is the filing date of December 8, 1999.

Provisional application No. 60/111,497, filed on December 8, 1998, contains a six page

specification, seven drawings, and eight different attachments identified as Attachments A-G.

9.1.2.1 Claim Elements not Supported by the Provisional Application

In my opinion, the provisional application does not support the following claim elements:

storing the original destination address if redirection is required

modifying, at the gateway device, the original destination address access request andcommunicating the modified request to a redirection server if redirection is required

responding, at the redirection server, to the modified request with a browser redirectmessage that reassigns the modified request to an administrator-specified, redirecteddestination address

intercepting, at the gateway device, the browser redirect message and modifying it withthe stored original destination address

sending the modified browser redirect message to the computer, which automaticallyredirects the computer to the redirected destination address

The analysis below highlights the absence of support for these claim elements.



100

9.1.2.2 Application No. 60/111,497 Specification and Drawings

The Provisional Application makes the following disclosures relating to the subject

matter of the application:

Cross Reference to Related ApplicationsThis application is related to US App. Serial No. 08/816,174, a copy of the disclosure of which is attached hereto as attachment H.

H. BACKGROUND OF THE INVENTION

1. Field of the Invention:

The present invention is related to network communications and, in particular, toimprovements In DHCP providing for automatic user tracking and security.

2. Description of the Prior Art:

Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) was developed as a means of allowingnetwork administrators to assign TCP/IP configuration parameters automatically to theclient computers in their networks. Because DHCP relieves network administrators of thetime consuming tusk of manually configuring each computer on the network, it has beenwell received and is currently used in 40 to 60 percent of enterprise networks today.DHCP was designed to assign IP settings to any user joining a network, without any userauthentication, from a predefined range of IP addresses. Since DHCP assigns IPaddresses indiscriminately (without, for example, manually entering a MAC address for alease reservation), it does not allow for the tracking of individual end-users. This canmake tracing and diagnosing network problems very difficult for the NSP

See provisional application No. 60/111,497 at N001588.

The specification focuses on the deficiencies of DHCP. As noted in the specification,

DHCP was designed to assign IP settings to user joining a network, without the requirement for

user authentication. It does not allow for the tracking of individual end-users. See N001588-89.

The Provisional Application purports to overcome the limitations of DHCP. However, that

subject matter is not directly related to the ‘894 patent specification.

For example, the “Summary of the Present Invention” contains disclosures concerning

the detection of MAC addresses, and the redirection of a user to a browser sign in page.

The Nomadix databases have been built to easily integrate with these subscriber accesssystems. Like a router, the Nomadix technology continues to track the IP and MACsettings for each user on the network, eliminating the need for further sign-ins. Thisallows the NSP to trace network problems and track usage. In addition, the underlying



101

dynamic NAT approach used to translate static IP addresses can create an additional layerof security for subscribers, since their private IP information never gets transmitted overthe public Internet.

See Provisional Application No. 60/111,497 at N001589-90.

I note that the reference to NAT used for static IP address translation in the above

passage is not relevant to the ‘894 patent claim steps that involve “modifying, at the gateway

device, the original destination address access request.” The former operates on source IP

addresses, whereas the NAT scheme discussed in the Provisional Application logically applies to

destination IP addresses. In my opinion the “Summary of the Present Invention” provides no

support for the’894 claim elements listed in section 9.1.2.1.

9.1.2.3 Detailed Description of a Preferred Embodiment(s)

The one page “detailed description” is dedicated entirely to the central issues of (1)

identifying users who are not yet registered by means of the packet MAC address; (2) Processing

of user DHCP requests. The detailed description section refers to Figure 1 of the specification

and figures in Attachment H. A fleeting reference is made to packet translation and redirection:

If no DHCP request is made, the packet is translated or redirected as required beforenormal processing.

If the received packet is does not include a valid MAC address, temporary newconfiguration information is provided to the User who is then directed to a Subscriptionlogin page to create a new account.

See Provisional Application at N001592.

In my opinion this fragmentary statement does not provide support for the’894 claim

elements listed in section 9.1.2.1.

9.1.2.4 Attachment A. Subscriber Configuration Issues in Residential Broadband

Deployments (December 5, 1998).

Under the section entitled “Brief Description of the Drawings and Attachments” there is a

reference to the preferred embodiment of the invention claimed in the Provisional Application

No. 60/111,497.

Attachment A is a confidential Nomadix document entitled “Subscriber ConfigurationIssues in Residential Broadband Deployments”, dated December 5, 1998, including 17



102

pages of combined text and drawings, which provides additional description of thebackground of the present invention as well as additional disclosure of preferredembodiment of the present invention as shown, for example, on page 10 and followingthereof.

See provisional application No. 60/111,497 at N001589-90.

Attachment A provides a lengthy dissertation on the difficulties users have in re-

configuring TCP/IP stack parameters when moving a computer from on network to another.

Attachment A simply shows “Automatic User Tracking and Security” using MAC address

tracking techniques. This is consistent with the “Background of the Invention” section

referenced above reciting the lack of such features in DHCP.

This material is not relevant to the ‘894 patent since its claims do not recite methods or

systems that involve improperly configured network address configuration. See section 9.2.1.

Attachment A has as its focus the Nomadix handling of incorrectly configured IP

addresses:

Automatic Support for all Network Configurations

Nomadix’ adaptive configuration approach was designed to accommodate all possiblenetwork configurations, including dynamic and static IP address assignments. If thesubscriber’s network settings are not properly configured to access the residentialnetwork (i.e., using a static IP address from work), the adaptive configuration technologywill automatically intercede and provide dynamic translation of all network parameters.



103

This will allow the subscriber to fully utilize the network services he has purchased,without altering his network settings.

See Provisional Application at N001610-11.

See Page 10, Attachment A, “Subscriber Configuration Issues in Residential BroadbandDeployments”, dated December 5, 1998. N001611.

As shown above, there is a passing reference to “the ability to redirect that user to a sign-

in page on his browser” and the “underlying dynamic NAT approach used to translate static IP

addresses.” These minimal statements provide no useful disclosures concerning the claim steps

listed in section 9.1.2.1. I note that the reference to NAT used for IP address and TCP port



104

translation in the above passage is not relevant to the patent claim steps that involve “modifying,

at the gateway device, the original destination address access request.” The former operates on

source IP addresses and source TCP ports, whereas the latter logically applies to destination IP

addresses and ports.

Attachment A provides only fleeting references to redirection issues:

The first time a subscriber accesses his residential network, the Nomadix solution has theability to redirect that user to a sign-in page on his browser.


Before allowing network access, the USG can also redirect the subscriber’s browser to asign-in web page to authenticate that user.


Nomadix also provides a strong security and tracking solution to NSPs by allowing themthe option to redirect the subscriber’s browser to a sign-in web page for authenticationand billing.


In my opinion, the subject matter of Attachment A is irrelevant to the ‘894 patent. (See

section 9.2.1.)

9.1.2.5 Attachments B - G

These attachments provide no discussion or disclosures concerning the claim steps listed

in section 9.1.2.1. They are all documents that describe the MAC-IP address mapping issues,

and more generally the capabilities of the Nomadix Universal Subscriber Gateway and the

provision of network services without modifying a client computer’s network configuration

settings.

9.1.2.6 Attachment H - NOMADIC TRANSLATOR OR ROUTER BY Joel E.

Short, Leonard Kleinrock

Attachment H is Application No. 09/041,534 that resulted in the issue of Patent No.

6,130, 892. Application No. 09/041,534 is a continuation of Application No. 08/816,174.



105

I can find no disclosures in the 60/111,497 provisional application that provide any

support for the claim steps listed in section 9.1.2.1. The 09/041,534 application makes various

references to terms such as “redirect,” but as seen in the excerpt below, they are not pertinent to

the ‘894 patent claims:

Rather than the host computer 12 sending packets directly to the router 26 or othernetwork device, which is what it is initially configured to do, the nomadic router 10 isable redirect all outbound packets from the host computer 12 to itself. This redirectioncan be 15 accomplished in several ways as described below.


As seen in the continuing passages, this type of redirection is completely unrelated to the

redirection taught by the ‘894 patent.

9.1.2.7 Summary

None of the material supplied as part of Provisional Application at N001580-1686

supports the ‘894 claim steps involving “redirection,” “redirection server,” or “browser

redirection message,” in the sense of determining “which of the original destination address

requests require redirection,” “storing the original destination address if redirection is required”

“communicating the modified request to a redirection server if redirection is required”

“responding, at the redirection server, to the modified request with a browser redirect message

that reassigns the modified request to an administrator-specified, redirected destination address”

“intercepting, at the gateway device, the browser redirect message and modifying it with the

stored original destination address.”

I am therefore of the opinion that the correct priority date for the ‘894 patent is the filing

date of December 8, 1999.

9.1.3 ‘894 Claims

1. A method for redirecting an original destination address access request to a redirecteddestination address, the method comprising the steps of:

receiving, at a gateway device, all original destination address access requests originatingfrom a computer;



106

determining, at the gateway device, which of the original destination address requestsrequire redirection;

storing the original destination address if redirection is required;

modifying, at the gateway device, the original destination address access request andcommunicating the modified request to a redirection server if redirection is required;

responding, at the redirection server, to the modified request with a browser redirectmessage that reassigns the modified request to an administrator-specified, redirecteddestination address;

intercepting, at the gateway device, the browser redirect message and modifying it withthe stored original destination address;

and sending the modified browser redirect message to the computer, which automaticallyredirects the computer to the redirected destination address.

5. The method of claim 1, wherein the step of responding, at the redirection server, to themodified request with a browser redirect message that reassigns the modified request to

an administrator-specified, redirected destination address further comprises

responding, at the redirection server, to the modified request with a browser redirectmessage that reassigns the modified request to a redirected destination address associatedwith a login page.

6. A system for redirecting an original destination address access request to a redirecteddestination address, the system comprising:

a computer that initiates original destination address requests; a gateway device incommunication with the computer,

that receives the original destination address requests from the computer,

determines if redirection of any of the original destination address requests is required,stores the original destination address request if redirection is required and modifies theoriginal destination address request if redirection is required,

and a redirection server in communication with the gateway device that receives themodified request from the gateway device and responds with a browser redirect messagethat reassigns the request to an administrator-specified, redirect destination address,

wherein the gateway device intercepts the browser redirect message and modifies theresponse with the stored original destination address before forwarding the browserredirect message to the computer

and wherein the computer receives the modified browser redirect message and thecomputer is automatically redirected to the redirect destination address.

7. The system of claim 6, further comprising a user profile database in communicationwith the gateway device that includes stored user-access information.

8. The system of claim 6, further comprising an Authentication, Authorization andAccounting (AAA) server in communication with the gateway device and user profiledatabase, the AAA server determines if a user of the computer is entitled to access the



107

original destination address requests based upon the user-access information storedwithin the user profile database.

9. The system of claim 6, wherein the redirection server is located within the gatewaydevice.

10. The system of claim 7, wherein the user-profile database is located within thegateway device.



Claim 1:intercepting


Claim 1:“all original destination address

access requests originatingfrom a computer”

“all access requests for an original destinationaddress originating from a computer”

Claim 6:“the original destinationaddress requests from thecomputer”

“all access requests for an original destinationaddress from the computer”

destination address a specific network location, such as an internetaddress, email account, FTP address, or otheraddress accessible via an online service

Claim 1:storing

recording data into a data storage device

Claim 6:stores

records data into a data storage device

Claims 1 & 7:stored

recorded data on a data storage device

Claims 1 and 6:“a browser redirect message”

a message instructing a computer receiving themessage to redirect its browser



108


The PTO rejected claims 1-16 in an Office Action – in response to communication dated

October 22, 2002. (See N001199.) The reasons for rejection were based on Bowker.

9.2.1 Transparent Home Network Settings

In response to the PTO Office Action dated December 30, 2002, the applicants cancelled

claims 1-16 and added claims 24-34.

Claims 1-16 have been cancelled from the present application. Newly added claim 24 is amethod claim directed toward a process for redirecting original destination address accessrequests to a redirected destination address. While claim 24 embodies the spirit of previous method claim 1, the applicant believes that the changes were significant so as towarrant a new claim as opposed to an amendment to claim 1. In addition, while claim 29

embodies the spirit of previous system claim 10, the applicant believes that the changeswere significant so as to warrant a new claim as opposed to an amendment to Claim 10.

(See ‘894 File History at N001389.)



109


This new claim can be compared with the original claims 1 and 17: (N00802)




110


It is evident that with the new added claims 1 and 6, the applicants abandoned the

limitations relating to a user’s computer configured for a home network:

wherein the users otherwise have access to a home network through home settingsresident on the user’s computer, and wherein the users can access the destination network without altering the home network settings

wherein the user’s computer remains configured for accessing the home network, andwherein no additional configuration software need be installed on the user’s computer to

access the destination network.


Neither of these limitations is found in the current claim language for the ‘894 patent.

9.2.2 The Patented System Requires (User) Computer Spoofing

In the last amendment and response to the PTO Examiner, the patent applicant identified

that in addition to selectively redirecting HTTP requests to a redirection server, the gateway

“spoofs” the user’s browser by returning an HTTP response packet containing the original IP

destination address as the new source IP address. In this manner, the web browser (computer

user) is “spoofed” into believing that the web server at the originally targeted URL was

responsible for returning the browser redirect command.



111

Claims 24 and 29 require that the gateway device intercept the browser redirect messageprior to forwarding such to the computer host. The claims require that the interceptiontake place for the purpose of modifying the source address (i.e., the redirect serveraddress) with the stored original destination address. By intercepting the redirect messageand modifying it with the stored original address the computer host is “spoofed” into

believing that the redirect page that it sent to is the requested original destination address.This “spoofing” operation, also referred to as “browser hijacking”, may be instrumentalin insuring that the redirection process occurs because as long as the computer believesthat the redirected address is the original address it will be difficult for the computer tocircumvent the redirection with any type of blocking mechanism being implemented onthe computer host.

See ‘894 Prosecution History at N001389. (Emphasis added.)

The Bowker’ 790 patent provides no teaching that the user is “spoofed” into believing .that the unrequested information that it receives is the information that it had requested.No teaching is provided that the source address connected with the unrequestedinformation is replaced with the requested information address prior to submission to theuser. As such, the user’s computer is knowledgeable regarding the redirection and mayattempt to block the redirection by implementing a suitable blocking mechanism.Therefore, the Bowker ‘079 patent does not teach or suggest the required elements of Claims 24 and 29, specifically, an interception process that occurs prior to thecomputer/host receiving the browser redirect message and serves the purpose of replacingthe source address (ie., the redirect server address) with the original destination address.This novel process is highly advantageous in that it “spoofs” the computer into believingthat the redirect address is the destination address that the computer had originallyrequested.

See ‘894 Prosecution History at N001390. (Emphasis added.)

This conclusion is further confirmed by the ‘894 patent specification itself:

The protocol stack can pretend to be the user-entered destination location long enough tocomplete a connection or `handshake`. Thereafter, this protocol stack directs the user tothe portal server, which can be local to the gateway device to facilitate higher speedcommunication.


I further note that the applicant’s remarks and the ‘894 patent claim language only make

sense in the context of manipulation of source IP address and destination IP address, i.e.,

network protocol addresses.

One of ordinary skill in the art would understand from the claim language and the

applicant’s response above, that a browser makes an “original destination address access



112

request” that is intercepted at a gateway and forwarded to a redirection server as a “modified

request.”





In my opinion Claims 1 and 5-10 of the ‘894 patent are not enabled. The ‘894 patent

does not provide enablement of the claim terms “original destination address,” “receiving…of all

original destination address access requests,” “redirection,” or “modifying the original

destination address at the gateway device.”

9.3.1 “original destination address”

Dr. Cole explains what he understands an original destination address to be:

This can occur where a user initially opens a web browser resident on the user’scomputer and attempts to access a destination address, such as an Internet site

See Cole Decl. at 104. (Emphasis from original.)

Dr. Cole opines that the term “original destination address” can refer to any address at

any level because there is a discernable relationship between domain names, layer 2 network

addresses, and MAC layer 2 addresses.

Once the IP address is determined from the domain name, the IP address is associatedwith a MAC address via ARP. DNS and ARP are common/standard networking termsthat one of skill would clearly understand.

See Cole Decl. at 114.

The principal weakness with this argument is that the claim language is explicit regarding

the origin of the “original destination address” – it comes from a computer that is running a

browser application:

receiving, at a gateway device, all original destination address access requests originatingfrom a computer

See ‘894 patent at 13:50-51. (Claim 1)



113

a computer that initiates original destination address requests; a gateway device incommunication with the computer, that receives the original destination address requestsfrom the computer

See ‘894 patent at 14:26-31. (Claim 1)

9.3.1.1 Domain Lookups

From the specification, it is evident that at least one embodiment applies to a web

browser requesting a web page from a web server using the HTTP protocol. Assume that the

desired web page is www.google.com (including the default web page at the server directory

root)17. Despite Dr. Cole’s assertions, there is no combination of ARP and DNS that uniquely

relates the URL www.google.com to one IP address, nor is there a unique way of relating the

URL www.google.com to the MAC address of any particular Google physical server.

As seen in the packet trace below, the DNS resolution for www.google.com yields four

different IP addresses:

This it is seen that an “original destination” URL or domain name is not uniquely identified by

an IP address.

17 Contemporary web broseres also provide graphical support for the FTP protocol, so a browser user could also

enter a URL for an FTP site such as ftp://ftp.mysite.com. This browser command would use the FTP protocol rather

than the HTTP protocol.



114

9.3.1.2 Determination of “original destination address” MAC address

Furthermore, the 894 patent’s gateway cannot know the MAC address of a Google server

because ARP address requests at the inventions gateway are not broadcast across router

boundaries. An ARP for the MAC address of a Google server can only take place on a LAN

segment at the Google facilities.

As a secondary matter there is a difference between a complete URL, which could

constitute one form of “destination address,” and a domain name as discussed above, which is

associated with one or more IP addresses.

Therefore, even with the restriction to Internet application protocols and IP network

protocols, one of ordinary skill in the art would be drawn to a variety of different conclusions

including: (1) the “original destination address” can never be the MAC address of a desired

destination computer because neither the browser computer nor the gateway have any way of

determining MAC addresses on remote LANs; (2) the “original destination address” could be the

MAC address of the gateway itself; (3) the “original destination address” could be the destination

IP address in a Internet packet; (4) the “original destination address” could be domain name of a

server as specified in a browser HTTP request; (5) or, the “original destination address” could be

the complete URL specified in a browser HTTP request.

9.3.1.3 Opinion on Scope of “original destination address”

It is my opinion that if the “original destination address” can be any one of a requested

URL, a requested domain name, a layer 3 network destination address, or a MAC layer 2

destination addresses, then the patent is invalid through lack of enablement. The step of

“receiving, at a gateway device, all original destination address access requests originating from

a computer” could not be implemented by one of ordinary skill in the art for an “original

destination address” corresponding to the MAC address of a web server being called upon to

return a web page.



115

For the purposes of this report I limited the scope of the term “destination address” to that

provided by the Court:

a specific network location, such as an internet address, email account, FTP address, or

other address accessible via an online serviceSee Markman at page 27.

Within the realm of feasible implementations, a specific network location can therefore

only mean a particular IP address, a particular domain name, or a particular URL. The

destination MAC address is not available to the browser computer or the gateway. However,

when either URL or domain name is adopted as “destination address” I am unable to determine

the logic of the patent claims. In particular, it would be illogical for a gateway to store the URL

or domain name (“original destination address”) if redirection is required and perform

“intercepting, at the gateway device, the browser redirect message and modifying it with the

URL or domain name (“original destination address”). No enablement is provided for a “stored”

URL or domain name (“original destination address”) to modify a response packet in this

manner.

The only logical enablement is the storing of the outbound destination IP address. This is

confirmed by the statements made during prosecution of the ‘894 patent. See discussion in

section 9.2.2.

Therefore, I have limited the scope of my analysis to the understanding that “destination

address” is a network layer destination address, specifically the destination IP address of an

Internet packet.

This interpretation appears to comport with Dr. Cole’s IP enablement example:

RFC 2004 – Minimal Encapsulation within IP published in 1996, references the “originaldestination address” and how it can be changed during encapsulation of an IP packet.



116

9.3.1.4 The Preferred Embodiment Requires “original destination address” to be

a Destination IP Address

As analyzed in section 9.3.2, the preferred embodiment discloses a system that must use

the destination IP address as the only possible form of “original destination address.” The

“original destination address” must be known prior to a TCP connection being in the

“Established” state, i.e., before any HTTP payload information is available. See section 9.3.2.3.

9.3.2 Stack Address Translation is not a Term of Art and does not Enable the

‘894 Patent

Dr. Cole cites the specification’s Stack Address Translation as evidence of enablement.

(See Cole Decl. 115) Unfortunately the meaning of the paragraphs cited (‘894 patent 9:5-51)

cannot be deciphered and could not conceivably be understood by one of ordinary skill in the art.

The redirection is accomplished by a Home Page Redirect (HPR) performed by thegateway device, a AAA server, or by a portal page redirect unit located internal to orexternal to the gateway device. To accomplish the redirection of a user to a portal page,HPR utilizes a Stack Address Translation (SAT) operation to direct the user to the portalpage, which is preferably local to the gateway device so that the redirection will beefficient and fast. This is accomplished by redirecting the user to a protocol stack usingnetwork and port address translation to the portal server that can be internal to thecomputer network or gateway device. More specifically, the gateway device, AAA serveror portal page redirect unit receives the user’s HTTP request for a web page and sends

back the HTTP response reversing the network and port address translation the portalserver, essentially acting as a transparent `go-between` to the user and portal server. Itwill be appreciated, however, that to receive the HTTP request the gateway device, AAAserver or portal page redirect unit must initially open a Transmission Control Protocol(TCP) connection to a server in line with the user-requested internet address.

According to one aspect of the present invention, when a user initially attempts to accessa destination location, the gateway device, AAA server or portal page redirect unitreceives this request and routes the traffic to a protocol stack on a temporary server,which can be local to the gateway device. This can occur where a user initially opens aweb browser resident on the user’s computer and attempts to access a destination address,such as an Internet site. The destination address can also include any address accessiblevia the network or an online service, and can include the portal page. The protocol stack can pretend to be the user-entered destination location long enough to complete aconnection or `handshake`. Thereafter, this protocol stack directs the user to the portalserver, which can be local to the gateway device to facilitate higher speedcommunication. The redirection to the portal server can be accomplished by redirectingweb pages only, rather than all traffic, including E-mails, FTPs, or any other traffic.Therefore, once authorized, if a user does not attempt to access a webpage through the



117

user’s internet browser, the gateway device can forward the communication transparentlyto the user’s requested destination without requiring the user to access the portal page.Furthermore, according to one aspect of the invention specific user-input destinationaddresses may be authorized to pass through the gateway device without beingredirected.


In the material that follows I will refer to the “the gateway device, AAA server or portal

page redirect unit” as the “gateway server.”

9.3.2.1 Network and Port Translation are not Defined for the Stack Address

Translation Operation

The specification refers to “redirecting the user to a protocol stack using network and port

address translation to the portal server.” On its face, this description is ambiguous at best. Doesit mean “redirecting the user to a protocol stack using network and port address translation” or

does it mean “redirecting the user using network and port address translation to the portal

server?”

The concept of “network and port address translation” was well known at the time of the

patent application. It has the customary meaning of “Network Address Translation” router (see

section 5.8), wherein a source IP address and TCP port number are replaced with a different

source IP address and TCP port number. The specification does not clearly identify functional

similarities or differences that distinguish Stack Address Translation from Network Address

Translation.

9.3.2.2 The Gateway Server must Include the “Protocol Stack”

According to the specification, the gateway server terminates a TCP session. This is

necessary before the client computer will begin sending application level data such as HTTP

packets.

to receive the HTTP request the gateway device, AAA server or portal page redirect unitmust initially open a Transmission Control Protocol (TCP) connection to a server in linewith the user-requested internet address.




118

What the specification does not make clear is how the gateway server also communicates

with a protocol stack:

Home Page Redirect (HPR) performed by the gateway device, a AAA server, or by a

portal page redirect unit…HPR utilizes a Stack Address Translation (SAT) operation to direct the user to the portalpage….

This is accomplished by redirecting the user to a protocol stack using network and portaddress translation to the portal server…


This logic indicates that the gateway server terminates the browser TCP session and also

communicates with a protocol stack. The only logical conclusion is that the protocol stack is

part of the gateway server and performs the TCP endpoint duties. The specification does not

make this conclusion clear. If that conclusion is wrong, the relationship between the gateway

server and the named “protocol stack” is indeterminate.

9.3.2.3 The Protocol Stack Pretends to be the Requested Origin Server

The specification indicates that the protocol stack “pretends” to be the destination

location just long enough to complete a connection handshake.

The protocol stack can pretend to be the user-entered destination location long enough tocomplete a connection or `handshake`.


One of ordinary skill in the art would understand that completion of a TCP connection

handshake covers the period until the connection enters the “ESTABLISHED” state. That

implies the gateway server is terminating the TCP connection request as a transparent proxy to

the user’s “destination location” IP address. Clearly the user would not believe in the pretence if

he/she received packets that had a source IP address different from the requested destination

server.

The specification does not enable that “IP spoofing” function. For example, it does not

explain the implementation of a TCP/IP stack that is capable acting as a multi-homed host (with



119

a multiplicity of arbitrary and a priori unknown IP addresses) nor does it explain the mechanics

of maintaining a multiplicity of backlog and retransmit queues.

Also it does not disclose what the protocol stack “pretends” to after the connection is

established. If the protocol stack responds to the HTTP request, does the transmitted packet also

reflect the IP address of the origin server.

9.3.2.4 Stack Address Translation does not Provide Enablement for HTTP Proxy

Requests from a Browser

Because the HTTP protocol uses TCP as its transport protocol, a TCP connection must

first be established between the user’s browser and the gateway server. A TCP connection is

necessary before any application layer data can be sent via the connection, and until the

application layer data is available from the first HTTP packet, there is no way to know if the

user’s browser is making a proxy request or a direct request to an HTTP server.

Therefore during the period prior to establishing a TCP connection, how does the

gateway server protocol stack “pretend to be the user-entered destination location?” Up until the

connection completion the only known information about the request is the destination IP

address: That IP address is either the proxy server address or the origin server itself. The

specification does not enable an understanding of how the gateway server distinguishes between

the proxy server IP address, which is not a “user-entered destination location,” and the origin

server IP address.

9.3.3 Redirection

The ‘894 patent specification and prosecution history use the term “redirection” in

different ways. For example, the term “browser redirect message” appears to signify a browser

implemented redirection, whereas redirection is used in other contexts to mean server-side

redirection of the flow of packets. These are two entirely different forms of redirection.



120

The Court construed the term “browser redirect message” to be “a message instructing a

computer receiving the message to redirect its browser.” I understand the word “message” to be

some form of command or indicator instructing a browser to perform the act of redirection. The

‘894 patent provides no enablement for anything other than conventional HTTP redirect

commands.

9.3.3.1 Stack Address Translation Applies only to the HTTP Protocol

In certain sections of the specification references are made to the HTTP application level

protocol:

More specifically, the gateway device, AAA server or portal page redirect unit receivesthe user’s HTTP request for a web page and sends back the HTTP response reversing thenetwork and port address translation the portal server, essentially acting as a transparent`go-between` to the user and portal server. It will be appreciated, however, that to receivethe HTTP request the gateway device, AAA server or portal page redirect unit mustinitially open a Transmission Control Protocol (TCP) connection to a server in line withthe user-requested internet address.


The specification provides no enablement for application protocols such as FTP, SMTP,

POP and Telnet. The redirection performed by the gateway server to the portal server can be

accomplished by redirecting web pages only. The specification states clearly that redirection of

other protocol traffic, “including E-mails, FTPs, or any other traffic,” cannot be accomplished:

The redirection to the portal server can be accomplished by redirecting web pages only,rather than all traffic, including E-mails, FTPs, or any other traffic.


Here the specification appears to be informing us that while other traffic such as email

and FTP can be intercepted, authorized and conditionally modified by the invention, such

packets cannot be modified for browser redirection. The ‘894 patent is not enabled for such

protocols.



121

9.3.3.2 Browser Redirect Messages

In my opinion, the ‘894 patent claims are limited to computers that access Internet web

server sites using HTTP protocols, i.e., it is limited to redirection of browser HTTP page requests

that utilize the HTTP request/response protocol and the HTTP redirect commands18.

One of ordinary skill in the art would infer that the patent’s “browser redirect messages”

are HTTP response packets that contain the HTTP redirect command to redirect the browser

running on a user’s computer to a different web server.

The redirection server returns a “browser redirect message,” i.e., an HTTP response

message containing an HTTP redirection command.19 One of ordinary skill in the art would

understand that a ‘browser redirect message” is one of the HTTP command messages dictated by

the HTTP specifications, and that the redirection message is to be acted on by the browser (user

agent).10.3 Redirection 3xx

This class of status code indicates that further action needs to be

taken by the user agent in order to fulfill the request. The action

required MAY be carried out by the user agent without interaction

with the user if and only if the method used in the second request is

GET or HEAD.

See RFC 2616 at page 61.

There are five types of redirects available in the HTTP protocol that would satisfy the

‘894 patent’s claim language:

301 Moved Permanently

The requested resource has been assigned a new permanent URI and any

future references to this resource SHOULD use one of the returned

URIs.

302 Found

The requested resource resides temporarily under a different URI.

Since the redirection might be altered on occasion, the client SHOULD

18 Some systems conceived in the late 1990s used HTTP to view emails located on a server. They did not employ

email protocols. FTP proxies also existed in the 1990s to act as a firewall to FTP servers. They used the FTP

protocol, not the HTTP protocol. Finally, contemporary web browsers offer built in FTP clients. These web

browser FTP clients use the FTP protocol not HTTP.

19 See for example, RFC 2616 at http://www.ietf.org/rfc/rfc2616.txt.



122

continue to use the Request-URI for future requests.

303 See Other

The response to the request can be found under a different URI and

SHOULD be retrieved using a GET method on that resource. This method

exists primarily to allow the output of a POST-activated script to

redirect the user agent to a selected resource.

305 Use Proxy

The requested resource MUST be accessed through the proxy given by

the Location field. The Location field gives the URI of the proxy.

The recipient is expected to repeat this single request via the

proxy. 305 responses MUST only be generated by origin servers.

Note: RFC 2068 was not clear that 305 was intended to redirect a

single request, and to be generated by origin servers only. Not

observing these limitations has significant security consequences.

307 Temporary Redirect

The requested resource resides temporarily under a different URI.

Since the redirection MAY be altered on occasion, the client SHOULDcontinue to use the Request-URI for future requests. This response

is only cacheable if indicated by a Cache-Control or Expires header

field.

See RFC 2616 at pages 61-65.

The ‘894 claim language can only be understood as the generation of an HTTP redirect

command to a browser. There are no equivalent redirect commands for other protocols such as

FTP, POP and SMTP, and those protocols do not use the HTTP redirect commands.

9.4 Slemmer (US Patent 6,226,677) in Combination with Heddaya (USPatent 6,205,481) Renders the Claims of the ‘894 Patent Obvious

9.4.1 Background on Slemmer

US Patent 6,226,677, entitled “Controlled communications over a global computer

network,” was awarded to Michael Slemmer on May 1, 2001 (“Slemmer”). Application No.

09/232,386 for the patent was filed on January 15, 1999.

Slemmer discloses the handling of browser request packets from a user computer. These

user originated TCP packets are sent via an intranet to a “forced proxy server.” When a TCP

packet is received by the forced proxy server it is analyzed. If the destination IP address

(referred to in the patent as the “first destination IP address”) is not from a “sandboxed” domain,

the destination IP address is changed to a predetermined second destination IP address. This



123

reroutes the TCP packet to another IP address on the Internet. The rerouted TCP packet results

in webpage request at a web server. The web page is returned to the user’s computer.

The Slemmer patent clearly re-directs the original web page request to a server different

from the intended server identified by the original URL. In certain circumstances the web server

response returned to the user includes a login page.

The Slemmer invention uses two different software servers to process packets from a

user’s computer (12). Web page requests are intercepted by the first server referred to as a

“proxying software module,” based at least in part on the TCP destination port number:

Requests to the world wide web from the user machines 120 are unique in that their

destination TCP port is set to 80. When a packet is transmitted from a user machine 120,a transparent proxying software module in the server 130 makes a determinationregarding whether or not the transmitted information relates to a web request.

See Slemmer at 4:31-36.

The proxying software module, corresponding to the “gateway device” of the ‘894 patent,

is a server running on 130 that analyzes incoming packets. If redirection is required, the

“proxying software module” forwards the packet by changing the port number of the packet to a

new port “address” where a “redirection server” is listening:In that regard, the server 130 analyzes at least portions of each packet. If a packet TCPport is identified as 80, that packet is intercepted by the transparent proxying softwaremodule and redirected to a different TCP port on the server 130.


The “redirection server” of the ‘894 patent is the “software control program “ listening on

the second forwarding TCP port:

A software control program running on the server 130 is in communication with that

software port to which the packet is redirected. This software port responds to requests asif they were the web server on the Internet 140.


Thus Slemmer contains the ‘894 claim elements of “receiving at a gateway device,”

“determining, at the gateway device, which of the original destination address requests require



124

redirection,” “modifying, at the gateway device, the original destination address access request,”

and “communicating the modified request to a redirection server if redirection is required.”

9.4.1.1 determining, at the gateway device, which of the original destination

address requests require redirection

As disclosed by the Slemmer reference, the server 130 acts as a “gateway device,” and

determines if this is a request that must be forwarded to the control program.

During a browser request from the user machine, the TCP packet is sent via the intranetto a forced proxy server. The TCP packet has a number of fields including a first fieldrelated to a first destination IP address. The TCP packet and its first destination IPaddress are received by the forced proxy server and analyzed. If the first destination IPaddress is not from a “sandboxed” domain, the first destination IP address is changed to apredetermined second destination IP address to effectively reroute the TCP packet to

another IP address on the Internet.

See Slemmer at 2:29-39. (Emphasis added.)

Thus, the destination IP address specified by the user’s browser is examined to see if it

corresponds to a packet that must be redirected, and if is does satisfy such a test, the destination

IP address of the packet is changed in order to re-route the packet. This disclosure satisfies the

‘894 patent’s claim steps of:

receiving, at a gateway device, all original destination address access requests originating

from a computer;

determining, at the gateway device, which of the original destination address requestsrequire redirection;

modifying, at the gateway device, the original destination address access request andcommunicating the modified request to a redirection server if redirection is required;

See ‘894 patent at 13:50-59.

9.4.1.2 modifying, at the gateway device, the original destination address access

request and communicating the modified request to a redirection server if

redirection is required

Figure 3 of the Slemmer reference clearly discloses the redirection of a web page request.

Element 304 identifies a URL requested by a user connecting to the Internet. In element 308, the

“forced proxy” redirects the request to a second URL.



125

See Slemmer Figure 3.

With reference to FIG. 3, a user plugs in a laptop and runs the browser in step 300. Theuser’s default web page is a first URL home.browserid.com/Index.htm. The user’s laptop(user machine 120) attempts to connect to port 80 of home.browserid.com in step 304.The server 130 redirects this request to the forced proxying or control program.




126

Once the server 130 has determined that a particular request is to be redirected, it acts as

a “redirection server,” and returns the response to the user’s browser with a redirect command.

The control program returns a HTTP redirect message sending the user machine 120 to a

second URL at www.login.com in step 308.See Slemmer at 6:65-67.

The Slemmer “forced proxy” server 130 therefore satisfies the ‘894 patent’s claim steps

of:

responding, at the redirection server, to the modified request with a browser redirectmessage that reassigns the modified request to an administrator-specified, redirecteddestination address;

See ‘894 patent at 13:61-64.

sending the modified browser redirect message to the computer, which automaticallyredirects the computer to the redirected destination address.

See ‘894 patent at 14:1-14:3.

9.4.1.3 The Login Page

Both claim 10 and claim 25 of the Slemmer patent disclose the redirection of a requested

URL to a server that provides a login page response:

10. A method, as claimed in claim 1, wherein:

said at least one web page from said source includes at least one of the following: loggingin information and advertising information.


Claim 25:

providing a second destination address associated with a second web site accessible usingthe Internet while said user machine is connected to said second intranet network, saidsecond web site having second information different from said first information, saidsecond information including at least one of: logging in information and advertising

information, said providing step being conducted using a proxy server responsive to saiduser machine;




127

The Slemmer “forced proxy” server 130 therefore satisfies the ‘894 patent’s claim steps

of:

responding, at the redirection server, to the modified request with a browser redirect

message that reassigns the modified request to a redirected destination address associatedwith a login page.

See ‘894 patent at 14:19-22. (Claim 5.)

9.4.2 Background on Heddaya

US Patent No. 6,205,481, entitled “Protocol for distributing fresh content among

networked cache servers,” was awarded to Heddaya, et al, on March 20, 2001 (“Heddaya”).

Application No. 09/040,520 for this patent was filed on March 17, 1998.

Heddaya discloses client computer HTTP request messages sent to a “home server” that

are intercepted by intermediate caches servers located along the route between the client and the

content server. The cache servers are implemented with packet filters inserted into routers. A

cache server acts as a proxy for the home server from the perspective of the client.

The Heddaya specification teaches a system that not only intercepts client computer

HTTP requests, but also “spoofs” the client into believing that the HTTP response packets are

from the home server. As discussed in Heddaya , conventional HTTP requests conventional

networking applications that use HTTP follow this a direct connection paradigm: (1) establish a

TCP connection between the client and the home server; (2) Make the HTTP document request

from the client in the form of a GET message; (3) receive the HTTP response from the home

server; and, (4)terminate the TCP connection.

The cache servers disclosed by Heddaya identify the document requested by a client.

Because the URL information in the HTTP request is typically advertised by an HTTP client

only after a TCP/IP connection has already been established, it is generally necessary to establish

end-to-end TCP connections between the client and the home server before any HTTP requests

can be intercepted. Heddaya overcomes this limitation with the patented invention.



128



In the preferred embodiment of Heddaya, intermediate routers are able to detect TCP

connection requests to all HTTP home servers, and have the ability to act as a proxy for, or

“spoof” the home server. The “snooper” component located in the intermediate router inspects

packets that arrive at the router, identifies any packets that are TCP SYN requests, and

establishes a connection between the router cache server and the client computer. After

establishing the connection the snooper inspects all packets to capture any that contain a

corresponding HTTP GET request:

To overcome this hurdle, in the preferred embodiment, intermediate routers 14 have someawareness of the TCP protocol. TCP aware routers 14 are able to detect TCP connectionrequests to all HTTP servers (i.e., a {SYN} packet directed to the HTTP port), and havethe ability to act as a proxy for, or “spoof” the home server 20.

This functionality is implemented by the snooper 28. In particular, snoopers 28 located inrouters 14 on the path to a home server 20 inspect packets that fly-by, identify suchpackets, and intercept any {SYN} packets directed to HTTP home servers 20. As {SYN}packets do not contain any information identifying which document the client 12 intendsto request, the snooper 28 acts as a proxy for, or “spoofs” the home server 20, byestablishing a connection between the client 12 and the local transport layer in the cacheserver 16, and noting the initial sequence numbers used by both the client 12 and thelocal transport layer.

After the connection is established the snooper 28 inspects all packets that fly-by, andwaits for the corresponding {GET} request. Once the {GET} request arrives the snooper28 queries the local filter 26 and the resource manager 24 to determine if the requesteddocument is cached. If the document is cached the snooper 28 forwards the HTTP {GET}message to the local resource manager 24, waits for the resource manager 24 to servicethe request, and then terminates the connection. Otherwise, the requested document is notcached (i.e., the filter 26 or resource manager 24 missed). Several different approachesmay be taken to servicing the document request at this point.

See Hedday at 9:55-10:16.

9.4.2.2 storing the original destination address if redirection is required

Figure 4 of Heddaya illustrates some of these steps, and specifically discloses that the

“home server” IP address is maintained (“stored”) at the cache server.



129

See Heddaya Figure 4. (Flow chart of the operations performed by a leaf server locatedon the routing path.)




As noted in Figure 4 from Heddaya reproduced above, the cache servers perform the

function of “spoofing” by acting as a proxy, and by replacing the network address of the cache

server with the network address of the home server.

The above hand-off process is illustrated in the flow chart of FIG. 4. This process iscarried out by a particular class of cache servers 16 referred to as leaf node servers 38,which are the cache servers 16 that are on the extreme lower level nodes of the tree T,i.e., the first servers to intercept a {SYN} packet from a client 12. The leaf node servers28 in the tree T depicted in FIG. 1 are cache servers 16-1, 16-6, and 16-8.



130

As shown in step 41 of FIG. 4, when a leaf node server 38 receives a {SYN} packet, thehome server 20 is proxied for, or “spoofed”, by establishing a TCP connection directlybetween the leaf node server 38 and the client 12. The leaf node server 38 then waits tointercept the corresponding {GET} request from the client 12.

Note that spoofing thus occurs in the sense that packets exchanged between the client 12

and a cache server 16 are modified by the snooper 28 in the above scenario. In particular,the network address of a cache server 16 which is servicing a request is replaced with thenetwork address of the home server 20 and in a connection handoff, the sequencenumbers of bytes issued by the cache server 16 have to follow the sequence number asdetermined by the leaf server 38.

See Heddaya at 10:32-53. (Emphasis added.)

This mirrors the claim language of “intercepting, at the gateway device, the browser

redirect message and modifying it with the stored original destination address” since all packets

sent from the cache server to the client computer will now reflect the IP address of the home

server.

The Heddaya disclosure therefore satisfies the ‘894 patent claim step of intercepting the

TCP packet from the redirection server in order to replace incoming source IP address of the

redirection server with the destination IP address received as part of the original page request

from the user:

intercepting, at the gateway device, the browser redirect message and modifying it withthe stored original destination address;

See ‘894 patent at 13:65-67.

9.4.2.4 Communicating the Modified Request to Another Server.

Heddaya discloses the ‘894 claim steps of “communicating the modified request to

another server:”

Returning to step 41, if the requested document passes the cache query test by the filter28, and in step 42, and if the resource manager 22 detects that the document is present in

the local cache and will permit access to it, then the document request is serviced locally,in step 45. In step 45, the {GET} command is forwarded to the resource manager, whichthen replies with the requested document. Finally, the TCP connection between the leaf server 38 and the client 12 is closed, by spoofing the home server 20 once again andissuing the closing {FIN} and {ACK} messages to the client.

See Heddaya at 10:54-64.



131

Thus, Heddaya discloses the servicing of an HTTP request from a “resource manager”

using a separate TCP connection (“the {GET} command is forwarded to the resource manager,

which then replies with the requested document”).

This mirrors the claim language of “modifying, at the gateway device, the original

destination address access request and communicating the modified request to a redirection

server if redirection is required” since all packets sent from the cache server to the client

computer will now reflect the IP address of the home server.

9.4.2.5 Sending the modified browser redirect message to the computer, which

automatically redirects the computer to the redirected destination address

Heddaya discloses the step of returning the HTTP response as a “spoofed” packet. The

connection to the client is closed using the home server address to “spoof” the client the TCP

connection between the leaf server 38 and the client 12 is closed, by spoofing the home server

20:

Finally, the TCP connection between the leaf server 38 and the client 12 is closed, byspoofing the home server 20 once again and issuing the closing {FIN} and {ACK}messages to the client.

See Heddaya at 10:60-64.

This mirrors the claim language of “intercepting, at the gateway device, the browser

redirect message and modifying it with the stored original destination address” since all packets

sent from the cache server to the client computer will now reflect the IP address of the home

server.

9.5 IPORT in Combination with Heddaya (US Patent 6,205,481)


The IPORT system in combination with Heddaya (section 9.4.2) renders all of the claims

of the ‘894 patent obvious.

See section 9.4.2 for an overview of Heddaya and sections 9.4.2.1-9.4.2.5 for claim

analysis. The remaining material addresses the IPORT system



132








9.5.1 Background on IPORT

The company ATCOM/INFO began marketing the IPORT product in 1998. In January

1998, they conducted joint trials with Microsoft and CGX Communications. In fact there were

several sites Beta testing the IPORT product set as of March 4, 1998:

See SEC0002794 dated March 4, 1998.



133

The IPORT system was based on Microsoft Windows technology, including Microsoft

Windows NT Operating System, SQLServer database, Microsoft IIS Server, Microsoft DHCP

Server, and NT Routing and Remote Access Server.

IPORT runs as a Proxy Server that intercepts HTTP an initial HTTP request from a

browser, redirects the user to a login page, and establishes an Internet connection that can be

used for web browsing, email and FTP transfers. The Microsoft Proxy Server 2.0 is the central

element in the implementation of proxy functionality.

See Installation Guide at page 4-45. (SEC01055)

This is achieved transparently, and without adding any software to the user’s computer:

See IPORT Site Installation Guide (SEC00843)

The IPORT software, in addition to standard system components supplied by Microsoft,

includes the ATCOM IPORT Server, a collection of SQLServer database components such as

tables and scripts, HTML and ASP pages that run on the IIS server,



134

The IPORT system “Spoofs the user’s corporate network, i.e., the IPORT NT Server acts

as a proxy for the user’s corporate network DNS server etc.

See Hospitality,Net article SEC0002799 (Dated December 8, 1998.)

As seen in the documentation and screenshot below, the IPORT Server answers the user’s

HTTP request with an HTTP response packet containing the re-direct command for an IPORT

administrator-specified destination address, in this case the welcome page:

See IPORT White Paper- Connection Methods and Concepts (SEC 00815)

9.5.2 Background on Heddaya

See section 9.4.2.



135

9.5.3 Invalidity Analysis

9.5.3.1 receiving, at a gateway device, all original destination address access

requests originating from a computer

IPORT documentation discloses methodologies whereby the IPORT Server interceptsuser’s web page requests:


Claim 1 recites

1. A method for redirecting an original destination address access request to a redirecteddestination address, the method comprising the steps of:



The IPORT server receives the user’s page request by transparently intercepting the

packet from the user’s computer.

First, the user connects to IPORT using one of several choices of physical connection

method, such as Ethernet:



136


Once the user starts the computer and launches the browser, the web page request is

redirected to an IPORT administration page.



The IPORT server examines the contents of a packet received from a user’s computer and

determines the “network settings” of the user’s computer.


A user is required to initially view an IPORT administration page:



137

See White Paper Central Office Solution page 10. (SEC00743)

Once the user has logged in to the IPORT system, the user can take advantage of normal

Internet connectivity:

See IPORT White Paper- Connection Methods and Concepts page 5. (SEC 00815)

This means that a determination is made for each page request as to the need for re-

direction. Clearly, once the user has logged into the system redirection is no longer necessary,thereby satisfying this claim step requirement for “determining, at the gateway device, which of

the original destination address requests require redirection.”

9.5.3.3 storing the original destination address if redirection is required

See discussion of Heddaya, section 9.4.2.2.




The IPORT Server communicates a user’s web page request to redirection server

components that respond with a re-direct command.



138

See White Paper Central Office Solution at page 12. (SEC00745)

See also section 9.5.2.1 above.

9.5.3.5 responding, at the redirection server, to the modified request with a

browser redirect message that reassigns the modified request to an

administrator-specified, redirected destination address







139

9.5.3.6 Intercepting, at the gateway device, the browser redirect message and

modifying it with the stored original destination address

See analysis for Heddaya in section 9.4.2.5.

The IPORT system also “Spoofs the user’s corporate network, i.e., the IPORT NT Server

acts as a proxy for the user’s corporate network DNS server etc.


9.5.3.7 Sending the modified browser redirect message to the computer, which

automatically redirects the computer to the redirected destination address






140


9.6 Kostick97 in Combination with Ikudome99 Renders the Claims of

the ‘894 Patent Invalid

The following references disclose the subject matter of the asserted ‘894 patent claims:



“System Administration: IP Masquerading Code Follow-Up,” Linux Journal archive,Volume 1997, Issue 43es (November 1997) ISSN:1075-3583, Chris Kostick (“Kostick97”)


Ikudome US patent 6,779,118 entitled “User specific automatic data redirection system”issued August 17, 2004 (Application date April 21, 1999.)

In addition, the following reference describes HTTP proxy services.

US Patent 5,696,898 entitled “System and method for database access control” issued onDecember 9, 1997 to Baker, et al. Application date June 6, 1995. (“Baker95.”)

9.6.1 Background on Ikudome99

Ikudome99, US patent 6,779,118 entitled “User specific automatic data redirection

system” issued August 17, 2004 (Application date April 21, 1999) discloses a system that

redirects user requests based on information contained in an authentication and accounting

server.

The authentication and accounting server retrieves the proper rule set for the user, andcommunicates the rule set and the user’s address to the redirection server. The redirectionserver then implements the redirection rule set for the user’s address. Rule sets areremoved from the redirection server either when the user disconnects, or based on somepredetermined event. New rule sets are added to the redirection server either when a userconnects, or based on some predetermined event.

See Ikudome99 Abstract.

Ikudome99 discloses a system for creating and implementing dynamically changing rules

that control the redirection of specific user data traffic. The redirection is determined based on

database entries reflecting the user’s past activities. When the user connects to the local



141

network, as in the prior art system, the user’s ID and password are sent to the authentication

accounting server and checked against information in an authentication database.

The authentication accounting server assigns a temporary IP address. The user’s filter

and redirection information to a redirection server to control the redirection process for

individual users. The redirection server uses the filter and redirection information supplied by

the authentication accounting server to allow packets to pass directly through the redirection

server unchanged, or to block the user’s request. The redirection server can also modify the

request according to the redirection information obtained from the authentication and accounting

database.

The “redirection server” of the ‘894 patent corresponds to the “redirection server”

disclosed by Ikudome99.

Each time a locked user attempts to access another location, the redirection server 208redirects the user to a default location. In such a case, the redirection server 208 actseither as proxy for the destination address, or in the case of WWW traffic the redirectionserver 208 replies to the user’s request with a page containing a redirection command.

See Ikudome99 at 5:24-30.

The redirection server 208 monitors all the IP packets, checking each against the rule set.

In this situation, if IP address 10.0.0.1 (the address assigned to user ID UserID-2)attempts to send a packet containing HTTP data (i.e., attempts to connect to port 80 onany machine within the xyz.com domain) the traffic is redirected by the redirection server208 to www.us.com. Similarly, if the user attempts to connect to any service other thenHTTP at www.us.com or Telnet anywhere, the packet will simply be blocked by theredirection server 208.



Kostick97 includes the following figure that describes the relationship between a

“gateway device” referred to as “deathstar” and other networked computers. Kostick97

describes the IP forwarding capabilities on Linux available in November 1997, including

“redirecting,” “modifying” an “original destination address,” and “intercepting.”



142

The functional components of the Linux computer described by Kostick97 include

“ipfwadm” to set up filtering and masquerading, and the programs “redir” and “ipautofw” to

redirect Internet traffic from its original destination:

If you have a requirement for an internal web server, a couple of programs are availableto forward or redirect traffic bound from the external host to an internal host. Thesimplest is the redir program updated by Nigel Metheringham and available fromsunsite.unc.edu:/pub/Linux/system/Network/daemons/redir-0.7.tar.gz. redir is a TCP portredirector that resides on your masquerading host waiting for connections on a port andredirected to an internal server. A simple example to redirect HTTP and log allconnections is:

# redir --syslog 192.168.1.5 80 80 &

See Kostick97 at pages 5-6.

Probably the most popular though is ipautofw, which is generic enough to handle bothTCP and UDP traffic. It is implemented in the Linux kernel as a part of the 2.0.30 kernel,and it is also a command interface to set up auto-forwarding rules. It’s available fromftp://ftp.netis.com/pub/members/rlynch/ipautofw.tar.gz. The ipautofw command setsrules in the /proc/net/ip_autofw file to automatically forward packets for masqueradedhosts. For example, in order to handle Real Audio traffic before the kernel module wasimplemented, you could use ipautofw to give the command:

ipautofw -A -r udp 6970 7170 -c tcp 7070


Now, suppose we had that web server behind our masquerading host. We could add anauto-forwarding entry such as

# ipautofw -A -r tcp 80 80 -h 195.168.1.5

This command forwards HTTP requests to yoda (195.168.1.5).




143


9.6.3 Invalidity of the ‘894 Patent Based on Kostick97

9.6.3.1 A method for redirecting an original destination address access request to

a redirected destination address, the method comprising the steps of:

Kostick97 discloses a Linux computer called “deathstar” running redirection software.

The redirection software can selectively redirect Internet packets based at least on the port to

which they are addressed. The two networks 192.168.1.0/24 and 204.192.48.0/24 are connected

via the gateway “deathstar.” All traffic sent from the network 192.168.1.0/24 to network

204.192.48.0/24 must pass thorough the gateway, which can be configured as the default

gateway on LAN 192.168.1.0/24.



144

Kostick97 discloses the subject matter of the ‘894 patent in that packets sent from

“falcon” at IP address 192.168.1.2 to “original destination addresses” on LAN 204.192.48.0/24

pass through the gateway “deathstar” at address 192.168.1.1. The computer “deathstar” can be

configured to redirect packets targeting a particular TCP port so that they are sent to a different

IP address.

Hence packets targeting a server with an “original destination address” of 204.192.48.81

can be redirected to a different IP address such as 204.192.48.121 as they pass through the

“deathstar” gateway device. See section 9.6.2 for discussion of the Linux redirection software

modules “ipautofw.”

9.6.3.2 receiving, at a gateway device, all original destination address access

requests originating from a computer;

As seen in Kostick97, all packets from the computer “falcon” at IP address 192.168.1.2

that are addressed to a web server listening on port 80 at 204.192.48.81 will be “received at a

gateway device” deathstar” at IP address 192.168.1.1. The computer “deathstar” acts as the ‘894

patent’s “gateway device.” The “original destination address” is the destination IP address

contained in the Internet packets sent by “falcon” and received by the “deathstar” gateway.


address requests require redirection;

Kostick97 describes the way in which different types of Internet protocols can be

redirected. This is achieved by specifying the destination IP port (at the gateway) for which

traffic must be redirected to a different host.

For example, the command to forward traffic to a web server running on the server at

204.192.48.121 (shown as “Linux PPP Server”) on the 204.192.48.0/24 side of the gateway

device “deathstar,” takes the form:

# ipautofw -A -r tcp 80 80 -h 204.192.48.121

This command forwards HTTP requests to address 204.192.48.121. See Kostick97 at page 6.



145

Clearly the “ipautofw” commands satisfy the claim step requirement of “determining, at

the gateway device, which of the original destination address requests require redirection” since

packets for other ports are not affected by the forwarding command. The “deathstar” gateway

device must process the packets to determine which of them are to be forwarded to the server

204.192.48.121.

9.6.3.4 storing the original destination address if redirection is required;

While Kostick97 does not explicitly show the “storing of the original address” it would

have been obvious for one of ordinary skill in the art to do so based on the masquerading features

described by Kostick99.

One of ordinary skill in the art would understand that the implementation of a “deathstar”

as a masquerade computer for the 192.168.1.0/24 network hosts would require the storage of

source and destination IP addresses as part of the masquerade relay processing. It would be

obvious that the “original destination address” could also be stored and associated with the TCP

connection opened to the redirection server.



redirection is required;

Kostick97 discloses the concept of redirection. See section 9.6.2. The destination

address of the packet is changed from 204.192.48.81 to 204.192.48.121 as a result of the

redirection. In this scenario 204.192.48.81 is the original destination address for the requested

web page. Kostick97 discloses the use of redirection for web page requests. See Kostick97 at

page 6.

9.6.3.6 responding, at the redirection server, to the modified request with a

browser redirect message that reassigns the modified request to an

administrator-specified, redirected destination address;

Kostick97 discloses the use of web servers but does not explicitly disclose the use of a

web server programmed to return a browser redirect message. However, it would be obvious for



146

one of ordinary skill in the art to install a web server on the server at IP address 204.192.48.121,

and obvious to set up a web page that provides a browser redirection as a response to an HTTP

request.

The concept of HTTP redirection was well understood at the time of the ‘894 patent

application as seen in the Ikudome99 reference:

Each time a locked user attempts to access another location, the redirection server 208redirects the user to a default location. In such a case, the redirection server 208 actseither as proxy for the destination address, or in the case of WWW traffic the redirectionserver 208 replies to the user’s request with a page containing a redirection command.


9.6.3.7 intercepting, at the gateway device, the browser redirect message and

modifying it with the stored original destination address;

The Court construed the term “intercepting” to mean “receiving and processing [e.g.,

data, packets] targeted for another device.” Intercepting includes any configuration where a

gateway device receives an Internet packet containing an HTTP response message that was

generated in response to an HTTP request. The target of the HTTP response message is the

“falcon” computer at IP address 192.168.1.2. The “deathstar” computer is not involved with the

HTTP request-response exchange, i.e., it is not an end point in the HTTP message exchange.

Kostick97 discloses the concept of masquerading. In this scenario, the “deathstar”

computer can be set up to masquerade for all computers on the 192.168.1.0/24 LAN. See

Kostick97 Listing 1/Listing 4. As explained in section 8.5.1, this results in a TCP connection

between the 208.192.48.102 interface of “deathstar” and the redirect server at IP address

208.192.48.121. In this situation “deathstar” intercepts the HTTP message targeted for “falcon”

at IP address 192.168.1.2.

Alternatively, if “deathstar” acts as a router, the incoming IP packet will be addressed

directly to 192.168.1.2 , which is not the address 204.192.48.102 of “deathstar.” Hence, in this

scenario “deathstar” also “intercepts” as a router because it processes a packet that is targeting a

different IP address.



147

It would also be obvious to one of ordinary skill in the art that the implementation of a

“deathstar” as a masquerade computer for the 192.168.1.0/24 network hosts could include

storage of the “original destination” IP addresses as part of the masquerade relay processing. It

would be obvious that the “original destination address” could also be stored and associated with

the TCP connection opened to the redirection server. The original destination IP address could

then be used as a replacement source IP address in the received packets.

9.6.3.8 and sending the modified browser redirect message to the computer, which

automatically redirects the computer to the redirected destination address.

Acting either as a router or a masquerade packet relay, “deathstar” sends the packet from

the redirect server at IP address 208.192.48.121 to the target destination address 192.168.1.2.



The ‘399 patent is entitled “Systems and methods for integrating a network gateway

device with management systems” and has a filing date of October 20, 2000. The inventors

claim priority from several U.S. Provisional Applications filed on Oct. 22, 1999.

Nomadix contends that Second Rule infringes claims 1, 3-4, 6, 8, 13, 15-16, 18 and 20-

21. Claims 1, 6, 13, and 18 are independent claims. Claims 1 and 13 are apparatus claims while

claims 6 and 18 are method claims.

10.1.1 Overview

The two system claims differ in that claim 1 recites a network gateway device that

“maintains data representative of the user’s access to the computer network” whereas claim 13

recites claims a management system connected to a network gateway device for” automatically

billing the user based upon the physical location of the user and the usage of the computer

network.”



148

Similarly, the independent method claims differ primarily in that claim 6 recites

collecting data corresponding to a user’s access to the computer network and reconfiguring that

data into “call accounting record format,” while claim 18 recites collecting data concerning a

user’s access to the computer network, including physical location of the user and the network

usage, and reconfiguring that data into “one of the predetermined data formats.”

The claims recite a management system communicating with a network gateway device

that automatically manages user access to a computer network. A user computer communicates

with a network gateway device without the need for any “agent” software installed on the user’s

computer. The gateway device also maintains data representative of the user’s accesses to the

network. A management system connected to the network gateway device for automatically

billing the user based upon usage of the computer network.

The management system communicates with the gateway using a compatible

communications protocol supported by the management system, and the gateway device

reformats data to meet the requirements of the protocol.

The management system receives data from the network gateway device and uses the

data for automatic billing purposes.

10.1.2 ‘399 Claims

1. A system for integrating a gateway device with a management system to automaticallybill a user for access to a computer network, comprising:

a computer; a network gateway device in communication with said computer forconnecting the computer to the computer network,

wherein the network gateway device communicates with the computer absent additionalagents implemented by the computer and wherein

the network gateway device maintains data representative of the user’s access to thecomputer network;

and a management system connected to said network gateway device

for automatically billing the user based upon usage of the computer network,

wherein said management system is configured to communicate according to at least onepredetermined protocol,



149

wherein the network gateway device formats the data into call accounting record format,

and wherein said management system receives the data formatted by the network gateway device

and utilizes the data formatted by the network gateway device for billing purposes.

3. The system of claim 1, wherein the data representative of the user’s access to thecomputer network comprises data representative of the user’s location.

4. The system of claim 1, wherein said management system is a hotel propertymanagement system.

6. A method for integrating a gateway device with a management system to automaticallybill a customer for access to a computer network, comprising:

enabling a user to access, via a network gateway device, a computer network absentadditional agents implemented by a user’s computer;

collecting data corresponding to the user’s access to said computer network in saidnetwork gateway device; reconfiguring said data into call accounting record format;

and transmitting the reconfigured data to the management system.

8. The method of claim 6, wherein transmitting the reconfigured data to the managementsystem includes transmitting the reconfigured data to a hotel property managementsystem.

13. A system for integrating a gateway device with a management system toautomatically bill a user for access to a computer network, comprising:

a computer; a network gateway device in communication with said computer for

connecting the computer to the computer network,wherein the network gateway device communicates with the computer absent additionalagents implemented by the computer and wherein the network gateway device maintainsdata representative of the user’s physical location and usage of the computer network;

and a management system connected to said network gateway device for automaticallybilling the user based upon the physical location of the user and the usage of thecomputer network,

wherein said management system is configured to communicate according to at least onepredetermined protocol,

wherein the network gateway device formats the data to meet one of the predeterminedprotocols supported by said management system, and

wherein said management system receives the data formatted by the network gatewaydevice

and utilizes the data formatted by the network gateway device, including the physicallocation of the user and the user’s network usage, for billing purposes.



150

15. The system of claim 13, wherein the at least one predetermined protocol is selectedfrom the group consisting of a low level protocol, a call accounting record, and a privatebranch telephone system protocol.

16. The system of claim 13, wherein said management system is a hotel propertymanagement system.

18. A method for integrating a gateway device with a management system toautomatically bill a customer for access to a computer network, comprising:

enabling a user to access, via a network gateway device, a computer network, absentadditional agents implemented by a user’s computer;

collecting data corresponding to the user’s access to said computer network, including aphysical location of the user and the user’s network usage, in said network gatewaydevice;

reconfiguring said data to one of the predetermined data formats which may be receivedby a management system;

and transmitting the reconfigured data to the management system.

20. The method of claim 18, wherein reconfiguring said data comprises reconfiguringsaid data to one of said predetermined formats selected from the group consisting of alow level protocol, a call accounting record, and a private branch telephone systemprotocol.

21. The method of claim 18, wherein transmitting the reconfigured data to themanagement system includes transmitting the reconfigured data to a hotel propertymanagement system.



Claims 1, 6, 13, and 18:agent

“special client software for managing thecommunication between the client and thegateway device”

Claims 1 and 13:“absent additional agentsimplemented by a user’scomputer”

absent additional special client softwareimplemented by the computer for managing thecommunication between the computer and thegateway device

Claim 1:“for automatically billing theuser based on usage of thecomputer network”

“for automatically billing the user based onusage of the computer network”

Claim 13:“for automatically billing the

“for automatically billing the user based upon thephysical location of the user and the usage of the



151

user based upon the physicallocation of the user and theusage of the computer network”

computer network”

Claim 13:

“for billing purposes”

“for billing purposes”

Claims 1 & 6:“call accounting record format”

“a format that can be used to organize datarelated to telephone calls”

Claims 1 & 6:“a call accounting record”

“a protocol that can be used to organize datarelated to telephone calls”

Claim 6:“collecting data correspondingto the user’s access to said

computer network”

“collecting data corresponding to the user’saccess to said computer network”

Claim 18:“the user’s network usage”

“the user’s use of the computer network”

Claim 1:“data,” in the phrase: “whereinsaid management systemreceives the data formatted bythe network gateway device andutilizes the data formatted by

the network gateway device forbilling

The meaning of “data” when read in the contextof the patent is “the call accounting recordformat data”

Court’s analysis of Call Accounting Record:

1. Call Accounting Record Independent Claims 1 and 6 include limitations related to CallAccounting Record (“CAR”) format.4 CAR format is one way that the gateway devicecan format the data. ‘399 Patent at col.7 ll.53-55. The specification discusses the meaningof CAR beginning at Col. 7, l. 53, with reference to Figure 3. The example of the CARprovided at Figure 3 includes a measurement of duration. The specification explains thatthe Figure 3 CAR “include data representative of month/day 310, extension/room 315,time 320, duration 325 (e.g., in minutes), charge 330, phone number 335, routing code340, and the like, as well as additional data 300 that may be necessary for accurate



152

ordering, transmittal, and/or reception of the call accounting record.” Id. at col.7 ll. 58-64.The specification makes clear that these data measurements are exemplary only. Indeed,the specification repeatedly discloses that the data included can be modified “as neededto conform to the format requested by the management system.” Id. at col.7 ll. 57-58; seealso id. at col.8 ll.41-65. Figure 3 expressly includes a Case 2:07-cv-01946-DDP-VBK

Document 127 Filed 10/03/2008 Page 17 of 43 category for “additional data that may benecessary for” the CAR.

Id. at col.7 l.62. But these modifications need not be additions to the data illustrated inFigure 3. Rather, the specification recognizes that there may be deletions or replacementsof particular types of data, depending on the particulars of the management system. Id. atcol.8, ll.49-65. The specification uses the example of telephone numbers, which areincluded in Figure 3, to illustrate this point, explaining:

[W]hen a user/subscriber is obtaining access to the hotel network via the gateway device,no telephone number is dialed or called. Therefore, when possible, data within the CARformat (i.e., telephone record), such as telephone numbers, may be replaced with adescriptive record that indicates some other data that the property management systemswishes to track ro record. Id. at col.8 ll.55-61. Moreover, this interpretation is consistentwith the remainder of the written description, which refers to billing for usage and accessto networks, but couches its disclosures in permissive, not mandatory, language andrepeatedly discloses that the information should be adjusted for the particulars of thesituation. See, e.g., id. col.3 ll. 14-17 (“data representative of he user’s access to thecomputer network can include...”) (emphasis added); col.6 ll.36-41 (the gateway device“can” monitor and record information “such as” identity, time, etc.); col.7 ll.43-47.Accordingly, the proper construction of CAR does not include a durational limitation.Aside from this durational argument, the parties’ proposed constructions of the term “callaccounting record” differ. While Nomadix proposes that the term be construed as “aformat that can be used to organize data related to telephone calls,” Second Rule’sconstruction (without the durational limit) reads: “a data record format corresponding toan individual user/subscriber’s use of the computer system.” Read in the context of theclaims, the Court does not find a meaningful difference between these two constructions.The Court adopts Nomadix’s construction, however, because it is less cumbersome.


The amendment in response to the Office Action dated June 4 resulted in a disavowal of

methods and systems that use additional agents to communicate with the network gateway

device:

The ‘430 Van Horne Patent Does Not Teach a Gateway Interface that Manages theCommunication on Behalf of the Client (i.e., Computer) Independent of CommunicationManaging Client Software Being Implemented on the Client.

See ‘399 Prosecution History at N002487.

The following amendments were made to the claim language:



153

(Revised as claim 1.)

(Revised as claim 6)


(Revised as claim 13.)




154

10.2.1 Summary of Prior Art Issues

In responding to the rejection of claims by the PTO in connection with the US Patent No.

5,987,430 (Van Horne), the applicants provided the following rationale to overcome the

rejection:

The teachings of the ‘430 Van Horne patent are distinguishable from the claimedinvention in that the Van Horne patent requires special client software for managing thecommunication between the client and the gateway device. As amended, independentclaims 1, 7, 12, 15 and 20 explicitly require that the network gateway devicecommunicate with the computer absent additional agents implemented by the computer.

The present invention, and specifically the novel gateway device of the present inventionteach and claim a method for automatic billing based on service usage that can be

implement without the client implementing special client software (i.e., an agent) tomanage the communication between the client and the gateway device. Thus, theautomatic billing method can be accomplished independent of client software or the needto reconfigure the client. As such, the present invention is highly beneficial in thoseinstances in which the computer is portable and the network connection is in a transitoryenvironment, such as a hotel room, airport lobby, etc. In this situation, the user benefitsfrom being able to access networks without having to implement (and store) special clientsoftware or reconfigure the computer in any other manner. Discussion related to thisaspect of the gateway device can be found throughout United States Patents Nos.6,130,892 and 6,636,894. Those patents, which were pending applications at the time of filing this application, were incorporated by reference as if set forth fully in the disclosureof the present application. (See page 6, lines 12-14).

The ‘430 Van Home provides no teaching of a gateway device that can managecommunication with a client absent special client software. In fact, the ‘430 Van Homepatent explicitly teaches (and requires in all of the independent claims) a client systemrunning client software for the purpose of managing the communication between theclient and the gateway.

See ‘399 Prosecution History at N002487.

As seen above, the applicants incorporate U.S. Patents 6,130,892 and 6,636,894 by

reference in the ‘399 patent.

The ‘399 patent specification also includes by reference the U.S. Patent Application

entitled “Systems And Methods For Providing Dynamic Network Authorization, Authentication

And Accounting,” filed by inventors Joel Short and Florence Pagan. This application further

explains the reference to “agents” in the ‘399 patent.



155

Additionally, in conventional network access systems, in order for a user to connect toon-line services (e.g., the Internet), the user must install client side software the user’scomputer. Client side software is typically provided by a network administrator ornetwork access provider, such as an ISP with whom the user has subscribed for Internetaccess, and enables the client to configure his or her computer to communicate with that

network access provider. Continuing with the illustrative example of a user accessing theInternet via an ISP, the user must install ISP software on client computer, and thereafterestablish an account with the ISP for Internet access. Typically, a user subscribes to anISP, such as America Online™, Earthlink TM, Compuserve ™ or the like, by contractingdirectly with the ISP for Internet access. Usually, the user pays for such Internet accesson a monthly fixed fee basis. Regardless user’s location, the user may dial up an accessnumber provided by the ISP and Internet access. The connection is often achieved via aconventional telephone modem, cable modem, DSL connection, or the like.

See US patent Application 09/693 060 at N01078.

From this passage one of ordinary skill in the art would understand the term “agent” to

include at least client-installed software applications provided by an ISP. In contrast, the ‘399

patent purports to use no client software specific to the gateway.





Claims 1, 3-4, 6, 8, 13, 15-16, 18 and 20-21 of the ‘399 patent are not enabled. In my

opinion the ‘399 patent does not provide enablement of the claim term “agent.” In addition the

entire phrase “absent additional agents” is indefinite. The ‘399 patent specification does not

even use the term “agent” or define what scope it should have, nor does the specification provide

any direct or indirect hint whatsoever as to the meaning of the phrase “absent additional agents,”

or enable any person having skill in the art to make and use the invention without additional

agents on the client machine.

In addition, the ‘399 patent includes by reference U.S. Patents 6,130,892 and 6,636,894.

As discussed in sections 7.3 and 8.3 respectively.



156

10.4 VanHorne98 (US Patent 6,128,601) in Combination with IPORT




of amendments that are fully disclosed by the IPORT product.


network connection apparatus and method,” when combined with the IPORT product

disclosures, renders the ‘399 patent obvious.








Nomadix contends that Second Rule infringes claims 1, 2, 4-6, 8-13, 15-17, 19-20, 22-24,

26-28, 30-35. Claims 1, 6, 13, and 18 are independent claims. Claims 1 and 13 are apparatus

claims while claims 6 and 18 are method claims.

10.4.1 Background on Van Horne


network connection apparatus and method” was awarded to Peter Van Horne, Keith Olson and



157

Kevin Miller on October 3, 2000. It is a continuation of an earlier application that resulted in

U.S. Patent 5,987,430 that was reviewed by the US Patent Office during prosecution of the ‘399

patent. The application for the Van Horne patent was filed on March 2, 1998.

VanHorne98 discloses systems and methods for connecting remote client computers to

the Internet by way of a server system. The server system provides for separately billing client

computer usage time, and for tracking usage.

The VanHorne98 invention provides communications system access for travelers in

public places, hotel rooms, ships or otherwise away from their normal point of network access.

10.4.2 Background on IPORT

See section 9.5.1.

10.4.3 Other Relevant Prior Art



of amendments that are fully disclosed by the YesWare product.

10.4.3.1 Background on YesWare

The YesWare system was disclosed in the following articles (collectively “YesWare”):

Elastic Networks Unveils YesWare; Mobility Software Solution Targets Visitor-BasedNetworking,” April 12, 1999, PRNewswire article covering the DemoMobile 99 tradeshow. SEC0002703-2704.

Hotel OnLine Special Report entitled “Darwin Networks Will Carry the Full Suite of Elastic Network Products,” June 2, 1999. See http:/www.hotel-online/News/PressReleases1999_2nd /June99_ElasticDarwin.html, SEC0002705-2707.

Electric Networks YesWare Applications User’s Guide, Document Revisions 2.20(November 1999) and 2.00 (April 1999), SEC 0002715-2784



158

The YesWare system was disclosed during sever trade events during 1999. It is a

“Visitor-Based Network” that allows user’s computers to be connected to a foreign network without reconfiguration.

YesWare is described as “billing system:’

See SEC 0002703

The system description discloses connection to a gateway that does not require use of a

client agent:



159

See SEC 0002704

In the above reference, the YesWare provides InterProxy that enables “plug and play

access. It allows mobile computers to operate in a foreign LAN regardless of the original IP

address or computer configuration. Thus, the network gateway device “communicates with the

computer absent additional agents implemented by the computer” as recited by the independent

‘399 claims.

Mobile users with Ethernet support are given high-speed access to their private LANwithout having to reconfigure computer settings.

See SEC 0002704

Similarly, the article entitled “Darwin Networks Will Carry the Full Suite of Elastic

Network Products,” discloses the YesWare system that makes it easy for a user to connect to the

Internet for web browsing:

See SEC 0002706

As noted in the above article, there is no need for laptop reconfiguration or loading of

special software for the user. Therefore these two disclosures satisfy the claim elements or steps

of claims 1, 6, 10, 13 and 18 that mandate the use of computer–gateway communications that do

not require agent software on the client computer: “the network gateway device communicates



160

with the computer absent additional agents implemented by the computer” claim 1, “a computer

network absent additional agents implemented by a user’s computer” claim 6, “the network

gateway device communicates with the computer absent additional agents implemented by the

computer” claim 10, “the network gateway device communicates with the computer absent

additional agents implemented by the computer” claim 13, and “via a network gateway device, a

computer network, absent additional agents implemented by a user’s computer” claim 18.

10.4.4 Invalidity of the ‘399 Patent Based on VanHorne98 and IPORT

10.4.4.1 integrating a gateway device with a management system to automatically

bill a user for access to a computer network

VanHorne98 discloses a gateway device that connects client computers to a

communication network via a server system. The server has the capability of separately billing

usage time and tracking usage by the network connected computers..

See VanHorne98 at Abstract.

In a preferred embodiment a client system having a personal computer and client connectsoftware connects to the Internet by way of a server running server software. Billingcharges are tracked and recorded for each of the client systems by the server software.The server optionally communicates with network management software via an

electronic communication network.See VanHorne98 at 4:17-24.

The server software tracks and controls access through each of the access ports linkedwith the server. The server software includes billing features that provide billing optionsto respective client systems linked with the server, record billing preferences, transmitbilling data to approval systems and receive approvals or rejections from the approvalsystems, transmit approval or rejection signals to the client systems, track system usageby the client systems

See VanHorne98 at 4:25-32. (Emphasis added.)

IPORT documentation discloses methodologies whereby the IPORT Server intercepts

user’s web page requests:



161


Claim 1 recites1. A method for redirecting an original destination address access request to a redirecteddestination address, the method comprising the steps of:



The IPORT server receives the user’s page request by transparently intercepting the

packet from the user’s computer.

First, the user connects to IPORT using one of several choices of physical connection

method, such as Ethernet:



162


Once the user starts the computer and launches the browser, the web page request is

redirected to an IPORT administration page.

10.4.4.2 a network gateway device in communication with said computer for

connecting the computer to the computer network

The network gateway device is referred to as a “server” in VanHorne98. The

characteristics of the server are disclosed in several figures:

FIG. 2 is a block diagram of a server system in accordance with the present invention;FIG. 3A is a block diagram of a server and access ports in accordance with anembodiment of the present invention;FIG. 3B is a block diagram of an alternative embodiment of the present invention;FIG. 4A is a block diagram of a lodging server and access port embodiment of thepresent invention;FIG. 4B is a block diagram of a building server and access port embodiment of thepresent invention;FIG. 5 is a block diagram of a server and access ports in accordance with an embodiment

of the present invention;

See VanHorne98 at 5:25-37.

The IPORT server examines the contents of a packet received from a user’s computer and

determines the “network settings” of the user’s computer.



163


A user is required to initially view an IPORT administration page:

See White Paper Central Office Solution page 10. (SEC00743)

Once the user has logged in to the IPORT system, the user can take advantage of normal

Internet connectivity:

See IPORT White Paper- Connection Methods and Concepts page 5. (SEC 00815)

This means that a determination is made for each page request as to the need for re-

direction. Clearly, once the user has logged into the system redirection is no longer necessary,

thereby satisfying this claim step requirement for “determining, at the gateway device, which of

the original destination address requests require redirection.”



164

10.4.4.3 the network gateway device communicates with the computer absent

additional agents implemented by the computer

The IPORT Server communicates a user’s web page request to redirection server

components that respond with a re-direct command.


The IPORT documentation clearly indicates that there was no need to install special

“agents” on a user’s computer. The user connected to the IPORT system simply by plugging

into an IPORT jack and launching a web browser.


Therefore, the IPORT system satisfies the claim limitation of “the network gateway

device communicates with the computer absent additional agents implemented by the computer.”

The disclosures of the IPORT system are further supported by evidence that the

hospitality industry was generally moving towards solutions that did not require an “agent” to be

installed on the user’s computer. For example, the YesWare system was disclosed during several

trade events during 1999. It is a “Visitor-Based Network” that allows user’s computers to be

connected to a foreign network without reconfiguration.



165

The YesWare system was disclosed in the following articles (collectively “YesWare”):

Elastic Networks Unveils YesWare; Mobility Software Solution Targets Visitor-BasedNetworking,” April 12, 1999, PRNewswire article covering the DemoMobile 99 tradeshow. SEC0002703-2704.

Hotel OnLine Special Report entitled “Darwin Networks Will Carry the Full Suite of Elastic Network Products,” June 2, 1999. See http:/www.hotel-online/News/PressReleases1999_2nd /June99_ElasticDarwin.html, SEC0002705-2707.

PRNewswire article - Elastic Networks Unveils YesWare

YesWare is described as “billing system:’

See SEC 0002703

The YesWare “InterProxy” system description discloses connection to a gateway that

does not require use of a client agent:

See SEC 0002704

In the above reference, the YesWare provides InterProxy that enables mobile computers

to operate in a foreign LAN regardless of the original IP address or computer configuration.

Thus, the network gateway device “communicates with the computer absent additional agents

implemented by the computer” as recited by the independent ‘399 claims.



166

Mobile users with Ethernet support are given high-speed access to their private LANwithout having to reconfigure computer settings.

See SEC 0002704

HotelOnline News Report - Darwin Networks Will Carry the Full Suite of Elastic Network

Products

Similarly, the article entitled “Darwin Networks Will Carry the Full Suite of Elastic

Network Products,” discloses the YesWare system that makes it easy for a user to connect to the

Internet for web browsing:

See SEC 0002706

As noted in the above article, there is no requirement for laptop reconfiguration or

loading of special software for the user. Therefore these two disclosures satisfy the claim

elements or steps of claims 1, 6, 10, 13 and 18 that mandate the use of computer–gateway

communications that do not require agent software on the client computer: “the network gateway

device communicates with the computer absent additional agents implemented by the computer”

claim 1, “a computer network absent additional agents implemented by a user’s computer” claim

6, “the network gateway device communicates with the computer absent additional agents

implemented by the computer” claim 10, “the network gateway device communicates with the

computer absent additional agents implemented by the computer” claim 13, and “via a network

gateway device, a computer network, absent additional agents implemented by a user’s

computer” claim 18.

10.4.4.4 the network gateway device maintains data representative of the user’s

access to the computer network

VanHorne98 discloses the storage of billing-related dat at the server:

In the preferred embodiment, the user of the client system 10 is billed for access to theECN 310, although it should be understood that unmetered or unbilled access also maybe granted.



167


The server of VanHorne98 uses a “billing software” module that is preferably part of the

server (gateway device) itself. The client transmits billing information to the billing software

module running on the server. Billing information is stored on the server for later access and

reporting.

In a preferred embodiment, the server 110 runs a form of billing software, which providesthis information to the client software 90 via the connections described in thisspecification. These billing options may include, for example, credit cards, prepaid accesscards, smart cards or direct charges to a hotel room bill. In the illustrated embodiment,after the billing options are received, step 651, a billing options menu or series of menusmay be displayed 653. In one embodiment, a credit card information template isdisplayed and filled out by the user of the client system 10. Once billing information hasbeen satisfactorily entered, processing continues. For example, as illustrated, processingmay return to step 648. Once sufficient billing information is received, stored or entered,the billing information is transmitted to the server 110, preferably to the billing softwarerunning on the server 110. Such billing software optionally is a separate software modulefrom the server software 130, but preferably is part of the server software 130. This stepis illustrated by box number 659. Preferably this billing information is stored on theserver 110 for later access and bill processing reporting.


The disconnect signal is received in the billing processing portion of the server software130, which is discussed in more detail below. The server software 130 reports the billinginformation to the client system software 90, as indicated in process step 735, where the

billing information is received. In the next step 737, the client software displays billinginformation, based on the data received from the server software 130 in step 735.


Any other data may be displayed as well. For example data indicating services accessed,premium charges, hotel room charges or incidental charges may optionally be displayed.


Clearly the billing software module of VanHorne98 satisfies the claim step of a network

gateway device maintaining data representative of the user’s access to the computer.

10.4.4.5 a management system connected to said network gateway device

The server of Van Horn98 connects with a “remote network management system 410.”

The server software 130 performs various functions, in communicating with variousclient systems 10 through the access ports 160, controlling billing functions, maintaininga client usage database, monitoring access ports 160, transmitting messages to the ECN



168

310, interacting with remote billing systems or a remote network management system410.


Preferably, the server system 110 communicates with a network management server 410,which runs network management software. The network management system canperform remote management of a plurality of server systems 110, in its preferredembodiment.

See VanHorne98 at 20:61-20:65. (Emphasis added.).

Clearly the network management server of VanHorne98 satisfies this claim step.

10.4.4.6 automatically billing the user based upon usage of the computer network

The network management server of VanHorne98 provides automatic billing services,

such as billings through credit cards. The billings are based on the usage of the computer

network by the client computers:

In the preferred embodiment, the server system 110 communicates via the ECN 310 (or aprivate network) with the plurality of server systems 110. This preferred embodiment isillustrated in FIG. 19. Optionally, the one or more communications stations 420 may alsobe in communication with the network management server 410. These communicationsstations 420. Such communications stations are described in more detail earlier in thisdescription. In addition, the network management server may be in communication withbilling clearing servers 430, such as credit card clearing institutions. Preferably thenetwork management server uses a private or dedicated connections with such clearing

servers 430, but alternatively, communications with the clearing servers may occur via anECN, including for example the Internet. The network management 410 also generatesusage reports 440 for mailing to customers. Such usage reports can list billing charges orusage statistics.

See VanHorne98 at 20:65-21-14. (Emphasis added.).

10.4.4.7 management system is configured to communicate according to at least one

predetermined protocol

The network management server is connected to the VanHorne98 server system via a

network. One of the preferred embodiments specifies the Internet as the network. Therefore at

least one predetermined protocol would be the TCP protocol for communicating billing

information:

The network management server 410 preferably runs network management software 450for performing billing transaction processing, remote network management and usagestatistical reporting. In addition the network management software 450 preferably



169

monitors the servers 110 and communications stations 420 to determine their usage rates,monitor error conditions, detect failures and remotely order reboots if necessary.


As seen in figure 19 of VanHorne98, the network management server 410 communicates

with the server 110 via the ECN, or “Electronic Communication Network” that can take the form

of an Internet network:

See VanHorne98 at Figure 19.

As illustrated in FIGS. 1-5, the system and method of the present invention provides a

client device 10 with direct high speed access to an electronic communications network 310 (“ECN”), such as the Internet, using specialized access ports 160 placed in publicplaces, which are linked to a server 110, which in turn provides transmission access to theECN 310.




170

As noted elsewhere in the VanHorne98 patent, the Internet uses TCP as a standard

communications protocol.

The Internet generally includes numerous computers that communicate with each other

using common communication protocols, commonly known as packet transfer protocols,such as the TCP/IP protocol. The ISP system, in turn is connected to the Internet,typically via a high speed communications line to an Internet center such as the nearestsuper computer center forming part of the “backbone” of the Internet.


10.4.4.8 the network gateway device formats the data into call accounting record

format

Providing a call accounting record format would have been a necessary and obvious

requirement for both the VanHorne98 and IPORT systems. The IPORT reference explicitlydiscloses “call accounting records” that use “a protocol that can be used to organize data related

to telephone calls” as that term was construed by the Court.

The IPORT documentation explicitly identifies a telephone PBX switch as the emulated

interface to “Property Management System.” The IPORT system emulates a PBX and sends “call

detail records” to the PM system. To one of ordinary skill in the art, the IPORT PBX interface

would have provided a clear indication that the records were organized with data relating to

telephone calls.

The IPORT system emulates a PBX and sends call details records to the PM system:



171

See IPORT Site Installation Guide at page 1-3 (SEC00844)

VanHorne98 discloses the transmission of credit card transaction data to a credit card

clearing house for approval:

In the billing approval process, the server software 130 transmits the billing informationvia the ECN 310, to a billing approval server. This transmission is indicated in step 771.If credit card approval is required, typically the billing approval server is a credit bureauor credit card service server. Alternatively, the billing approval request may be sent viathe ECN 310 to any billing approval server. For example, if a pre-paid access card isbeing used, the approval request may be sent to the issuer of the pre-paid access card.

The billing approval server can approve the transaction, approve with credit limit orreject. For example, if the funds in a pre-paid access account have been expendedcompletely, the transaction will be rejected. Alternatively, if a credit card is valid the an

approval will be received.See VanHorne98 at 19:39-51.

At the time of the invention one of ordinary skill in the art would have known that

standard e-Commerce formats such as SWIFT, EDI and EDIFACT were commonly used for

credit card transactions.

In addition to the Van Horne disclosures, the IPORT documentation discloses the claim

step of a “network gateway device formats the data into call accounting record format.”Connectivity from the IPORT system to a Property Management System (“PM System”) was

provided as part of the IPORT implementation. Call detail records could be sent to the PM

System.



172

See IPORT Site Installation Guide at page 1-3 (SEC00844)

The reference to the HITIS initiative is to a Microsoft led effort to provide a standard

record format for accounting and billing in the hospitality industry. The IPORT system

subsequently supported the HITIS initiative for standardized call accounting record formats.

During 1998 and 1999 a considerable effort was being expended to create record

standards for the hotel management industry, as described in the following articles:

“AH&MA Sanctions Mapping the HITIS Interface Protocol to XML,” July 1999. See http://xml.coverpages.org/hitisxmlmapping.html

Hospitality NET Article, “HITIS, Standards Project Initiates Public AwarenessCampaign,” May 4, 1998. See http://www.hospitalitynet.org/news//4000595.html.

Hotel Online Special Report “Damn Interfaces! How Will Standards Affect TheHospitality Industry Today?”, Mark Hamilton, March 1999. See http://www.hotel-online.com/News/PressReleases1999_1st/Mar99_DamnInterfaces.html

The IPORT system explicitly discloses the use of call accounting records and associated

billing systems. Based on these disclosures it would have been obvious for one of ordinary skill

in the art to adopt an emerging standard such as those formulated by the HITIS organization:

In July, 1999, the HITIS Advisory Committee unanimously endorsed therecommendation to designate the eXtensible Markup Language (XML), as the primaryplatform mapping for the HITIS standards.



173

The HITIS standards, designed in concept to be platform neutral, were recognized asinitially requiring two platform mappings; one to the Windows operating system and oneto the Java language platform.

Two organizations contributed to this effort:

WHIS: The Windows Hospitality Interface Specification group (WHIS), sponsored byMicrosoft, which provided the base documents to AH&MA and built a reference platformfor the WHIS/HITIS compliant interfaces based on Microsoft technology (COM/DCOM).Samples of these early implementations of the HITIS specifications in the Windowsenvironment can be found athttp://www.microsoft.com/industry/hospitality/developers/initiatives/whis

See http://xml.coverpages.org/hitisxmlmapping.html

See http://www.hospitalitynet.org/news//4000595.html



174

Note that the article makes the following reference to “Payment Processing and

Accounting Systems:

Six technical committees have been formed to develop 22 technical standards affecting

interfaces with property management systems and other hospitality systems in 1998:Payment Processing and Accounting Systems (first meeting: June 16, beta testing:August 7-September 3, completion: October 21)

See http://www.hospitalitynet.org/news//4000595.html

The IPORT documentation provides detailed information concerning the type of

accounting and usage information that was tracked by IPORT:





175

See IPORT Installation Guide at page 4-78. (SEC01088)



176



177




178


The IPORT system explicitly discloses the use of call accounting records and associated

billing systems. Based on these disclosures it would have been obvious for one of ordinary skill

in the art to adopt an emerging standard such as those formulated by the HITIS organization.

The IPORT system, in combination with the knowledge one of ordinary skill in the art would

have had of industry standardization trends at the time of the ‘399 patent application filing,

therefore satisfies the claim step of “the network gateway device formats the data into call

accounting record format.”



179

10.4.4.9 management system receives the data formatted by the network gateway

device and utilizes the data formatted by the network gateway device for

billing purposes.

In addition to the VanHorne98 disclosures, the IPORT documentation discloses the claim

step of “management system receives the data formatted by the network gateway device and

utilizes the data formatted by the network gateway device for billing purposes.”

See IPORT Installation Guide

In this disclosure, the Property Management System receives records from the IPORT

system.



U.S. Patent 6,857,009, entitled “System and method for network access without

reconfiguration,” was awarded to Ferreria, et al. on February 15, 2005. The application was filed

on October 23, 2000, but the applicants claim priority to U.S. Provisional Patent Application Ser.

No. 60/161,138 filed Oct. 22, 1999. The provisional application is incorporated in the ‘009

specification by reference in its entirety. The ‘009 Provisional Application includes application

Serial No. 60/111,497 for the ‘892 patent by reference. (See ‘099 Provisional Application at

N007126:18.)



180

Nomadix contends that Second Rule infringes claims 1, 2, 4-6, 8-11, 23-24, 26-28, and

30- 35. Claims 1, 23, and 34 are independent claims. Claims 12 and 23 are apparatus claims

while claims 1 and 34 are method claims.

11.1.1 Overview

The ‘009 patent recites a system and method for providing connectivity to a foreign

network for a user device configured for communication over a home network. This is achieved

without reconfiguring the user device.

Packets transmitted by the user device, which are incompatible with the foreign network,

are intercepted and selectively modified by a proxy server (“configuration adapter”). The

modifications ensure that the intercepted packets are compatible with network settings of the

foreign network.

Network services are provided by the proxy server (“configuration adapter”), which is

connected to the user device through the TCP protocol. The proxy server (“configuration

adapter”) is also connected through TCP to the target server whose access is desired by the user.

The two TCP sessions are “spliced” using TCP session splicing techniques. TCP splicing results

in session flow control functions occurring at the endpoints. Thus, packet acknowledgement and

flow control is between the user device and the target server. This prior art technique avoids the

copying of TCP data between connections at the proxy server (“configuration adapter”).

The network services provided correspond to network services normally available on the

user device’s home network or other network services that are normally inaccessible from the

foreign network. For example, the proxy server (“configuration adapter”) provides transparent

HTTP proxy services to users having a browser configured to use a proxy, it handles domain

name server requests, and it processes outgoing email service requests. The claims recite

specifically the “interception” of DNS requests from the user device, the resolution of the

requested domain name to an IP address, and the establishment of a TCP connection between



181

proxy server (“configuration adapter”) and the server at the address corresponding to the

resolved domain name.

The ‘009 patent purports to provide transparent network access for mobile users without

reconfiguration of the user’s computing device. Because the user device is configured for a

network different from the foreign network, these proxy requests would not otherwise be

satisfied.

11.1.2 ‘009 Claims

1. A method for providing connectivity to a foreign network for a device having network settings configured for communication over a home network without reconfiguring thenetwork settings of the device, the method comprising:

intercepting packets transmitted by the device;

selectively modifying intercepted packets which are incompatible with network settingsconfigured for communication over the foreign network to be compatible with thenetwork settings configured for communication over the foreign network,

wherein the network settings configured for communication over the home and foreignnetworks include respective IP addresses, gateway addresses, subnet masks, DNSaddresses, and protocol proxies;

and selectively providing network services for the device corresponding to network services available on the home network to reduce delay associated with accessing the

network services from the foreign network,or to provide network services otherwise inaccessible from the foreign networks whereinselectively providing network services comprises providing a proxy service whichincludes resolving a domain name to an address;

wherein resolving a domain name to an address includes; establishing a connectionbetween the device and a configuration adapter in order for the configuration adapter tointercept packets transmitted by the device;

examining contents of the intercepted packets to identify a domain name; resolving thedomain name to an address;

establishing a connection between the configuration adapter and a computer at theaddress corresponding to the domain name;

and splicing the connections between the device and the configuration adapter, andbetween the configuration adapter and the computer, to form a single connection betweenthe device and the computer such that the device and the computer communicate packetswith each other over the single connection without the network settings of the devicebeing reconfigured.



182

2. The method of claim 1 wherein the proxy service comprises a hypertext transferprotocol proxy service.

4. The method of claim 1 wherein resolving a domain name to an address comprises:attempting to resolve the domain name to an address using a domain name server

accessible from the foreign network; and resolving the domain name to an addresscorresponding to a configuration adapter after a predetermined timeout period expires, orif domain name servers accessible from the foreign network can not resolve the domainname.

5. The method of claim 1 wherein splicing the connections comprises directly modifyingsubsequently intercepted packets without copying the packet payload.

6. The method of claim 1 wherein resolving the domain name to an address comprisesusing a domain name server accessible from the foreign network.

8. The method of claim 1 wherein selectively providing network services comprisesproviding an outgoing email service.

9. The method of claim 8 wherein providing an outgoing email service comprisesmodifying intercepted simple mail transport protocol (SMTP) packets to redirect theintercepted SMTP packets to an SMTP server on the foreign network.

10. The method of claim 8 wherein providing an outgoing email service comprisesmodifying intercepted simple mail transport protocol (SMTP) packets to redirect theintercepted SMTP packets to an SMTP server on the foreign network without modifyingthe source address of the SMTP packet packets.

11. The method of claim 1 wherein selectively providing network services comprisesredirecting domain name service requests to a local domain name server for the foreignnetwork.

23. A configuration adapter for providing connectivity to a foreign network for a devicehaving network settings configured for communication over a home network withoutreconfiguring the network settings of the device, the configuration adapter comprising:

at least one network interface for connecting to the foreign network; and a processor incommunication with the network interface,

the processor intercepting packets transmitted by the device, selectively modifying

intercepted packets which are incompatible with network settings configured forcommunication over the foreign network to be compatible with the network settings of configured for communication over the foreign network,

and selectively providing network services for the device corresponding to network services available on the home network to reduce delay associated with accessing thenetwork services from the foreign network, or to provide network services otherwiseinaccessible from the foreign network;



183


wherein the processor selectively provides a proxy service for the device which includesresolving a domain name to an address;

wherein the processor resolves a domain name to an address by establishing a connectionbetween the device and the configuration adapter,

examining contents of the intercepted packets to identify a domain name, resolving thedomain name to an address,

establishing a connection between the configuration adapter and a computer at theaddress corresponding to the domain name,

and splicing the connections between the device and the configuration adapter, andbetween the configuration adapter and the computer, to form a single connection betweenthe device and the computer such that the device and the computer communicate packets

with each other over the single connection without the network settings of the devicebeing reconfigured.

24. The configuration adapter of claim 23 wherein the proxy service comprises ahypertext transfer protocol proxy service.

26. The configuration adapter of claim 23 wherein the processor attempts to resolve thedomain name to an address using a domain name server accessible from the foreignnetwork, and resolves the domain name to an address corresponding to the configurationadapter after a predetermined timeout period expires, or if the domain name serversaccessible from the foreign network can not resolve the domain name.

27. The configuration adapter of claim 23 wherein the processor splices the connectionsby directly modifying subsequently intercepted packets without copying the packetpayload.

28. The configuration adapter of claim 23 wherein the processor resolves the domainname to an address using a domain name server accessible from the foreign network.

30. The configuration adapter of claim 23 wherein the processor selectively provides anoutgoing email service.

31. The configuration adapter of claim 30 wherein the processor provides an outgoingemail service by redirecting intercepted simple mail transport protocol (SMTP) packets toan SMTP server configured to process mail from addresses on the foreign network.

32. The configuration adapter of claim 30 wherein the processor redirects interceptedsimple mail transport protocol (SMTP) packets without modifying the source address of the SMTP packets.



184

33. The configuration adapter of claim 30 wherein the processor redirects domain nameservice requests to a local domain name server for the foreign network.

34. A method for providing access to a second local area network for a device configuredto communicate over a first local area network having incompatible network settings with

network settings of the second local area network, the method comprising: determiningwhether an application running on the device is requesting a proxy service; wherein thestep of determining comprises: establishing a transmission control protocol (TCP)connection between a configuration adapter and the device to examine contents of apacket transmitted by the device; establishing a TCP connection between theconfiguration adapter and the proxy server requested by the application; and splicing theconnection such that end-to-end semantics are maintained by the application and therequested proxy server, and modifying packets containing proxy requests to directrequests if the requested proxy service is inaccessible from the foreign network withoutmodifying the network settings of the device.

35. The method of claim 34 wherein the step of splicing comprises: implementing asubset of network protocol functionality to intercept each packet from the applicationwithout passing the packet through an RFC-compliant protocol stack.



Claims 1 and 23intercepting


Claims 1 & 23:selectively modifyingintercepted packets

choosing whether to modify intercepted packetsand accordingly modifying intercepted packets

Claims 1 & 23:selectively providing network services

choosing whether to provide network servicesand accordingly providing network services

selectively provides a proxyservice

chooses whether to provide a proxy service andaccordingly provides a proxy service

11.1.4 Description of Preferred Embodiment

One preferred embodiment is summarized by figures 13 and 14 of the ‘099 patent

specification.

In the disclosed embodiment, the “configuration manager/adapter” is responsible for

intercepting HTTP requests that are configured as HTTP proxy requests. When a web browser is



185

configured to communicate via an HTTP proxy server, the proxy server’s (DNS) name or IP

address is available to the browser as a configuration parameter. One aspect of the ‘009 parent

describes a “configuration manager/adapter” that can intercept the traffic destined for the proxy

server and “pretend” to be the user’s proxy server. When a user requests a web page the browser

normally opens a direct connection with its configured proxy server and identifies the requested

web page in an HTTP command such as “GET http://www.yahoo.com HTTP/1.0.” That is,

using an absolute URL rather than a relative URL.

Because the HTTP protocol uses TCP as its transport protocol, a TCP connection must

first be established between the user’s browser and the “configuration manager/adapter.” A TCP

connection is necessary before any application layer data can be sent via the connection, and

until the application layer data is available from the first HTTP packet, there is no way to know

if the user is making a proxy request or a direct request to an HTTP server.

The “configuration manager/adapter” first listens for DNS requests from a browser,

because if the browser is configured to use an HTTP proxy using a named proxy, it will first

attempt to resolve the proxy domain name to the corresponding IP address.

Block 550 in FIG. 13 determines whether the subscriber is proxied, i.e. whether the clientbrowser or other application is configured to use a proxy server. Block 550 accesses thesubscriber database to determine whether the proxy status of a particular subscriber waspreviously determined and stored. If the proxy status is unknown, block 552 examines thepacket to determine whether it is a DNS request. This is necessary to automaticallyaccommodate browsers which are preconfigured with a proxy host name rather than an IPaddress. If the browser is configured to connect to a proxy server by name, the firstrequest from the browser when trying to connect to an HTTP server will be a DNSrequest for the proxy server name to determine the associated IP address.

See ‘009 patent at 14:46-59.

Once the IP address of the proxy server is resolved, the “configuration manager/adapter”

can process normal HTTP requests:

If the DNS request is resolvable to the actual pre-configured proxy server, then the actualDNS result may be relayed back to the browser as represented by block 557. Once the IPaddress has been resolved, a connection is established between the subscriber and theconfiguration manager as represented by block 558.



186

See ‘009 patent at 15:27-32.

For subsequent HTTP requests from the browser, the “configuration manager/adapter”

can determine if the received HTTP request is a proxy request. One method is to examine the

HTTP packet payload to see if the requested URL is absolute or relative.

Otherwise, the packet contents or payload must be examined to determine if the HTTPrequest is a proxy request as indicated by blocks 564 and 566.

See ‘009 patent at 15:36-38.

After establishing a connection between the subscriber and the configuration manager,the configuration manager must examine the contents or payload of the packet todetermine whether an HTTP proxy request (or other proxy request) is contained therein.Block 580 examines the first line of data to determine whether it contains a method,request, and HTTP version information. If not, nothing is returned as represented by

block 584. Otherwise, block 582 examines the request URI to determine whether it is anabsolute URI.

See ‘009 patent at 16:19-28.

For proxy HTTP requests, the “configuration manager/adapter” makes a standard or

direct request to the “origin server,” which represents the user’s desired target web server

location. See ‘099 patent at 15:41-44.


11.2.1 Claim Amendments

The Notice of Allowance was issued on October 4, 2004 in response to amendments filed

by the applicants on August 7, 2004.



187

In the May 6, 2004 Office Action, the Examiner rejected all of the claims as being

unpatentable over Redlich, U.S. Patent No. 6,591,306 in view of Rai et al US Patent No.

6,675,208.

The applicants responded with an amendment the claims and arguments against the

Examiner’s rejections (dated July 6, 2004). Numerous amendments were added to the claims in

the July 2004 Amendment by the applicants. For example, claim 1 was modified in the

following manner:



188

Similar amendments were made to claims 15 (now independent claim 12), 29 (now

independent claim 23), and 43 (now independent claim 34).

The amendments focus on the following two claim elements:


See ‘009 patent at 21:53-57.

wherein resolving a domain name to an address includes;

establishing a connection between the device and a configuration adapter in order for theconfiguration adapter to intercept packets transmitted by the device;



189

examining contents of the intercepted packets to identify a domain name;

resolving the domain name to an address;

establishing a connection between the configuration adapter and a computer at theaddress corresponding to the domain name; and

splicing the connections between the device and the configuration adapter, and betweenthe configuration adapter and the computer, to form a single connection between thedevice and the computer such that the device and the computer communicate packetswith each other over the single connection without the network settings of the devicebeing reconfigured.

See ‘009 patent at 21:67-22:17.

That is, the applicants introduced and defined the term “network settings” for both the

foreign and home networks to include “IP addresses, gateway addresses, subnet masks, DNS

addresses, and protocol proxies.” Then they elaborated on well known TCP splicing techniques

to use the “configuration adapter” as a proxy server.

11.3 Kostick96 (Linux IP Forwarding) in Combination with Elton97

Renders the Claims of the ‘009 Patent Invalid.


IP Masquerading with Linux, Chris Kostick, Linux Journal Issue 27, July 1996(“Kostick96”)See http://portal.acm.org/citation.cfm?id=328288.328289

Linux as a Proxy Server, Linux Journal archive, Volume 1997, Issue 44 (December1997) Article No. 3, ISSN:1075-3583, Peter Elton. (“Elton97”)


11.3.1 Kostick96 (Linux IP Forwarding)

See sections 7.5.1 and 8.5.1.

11.3.2 Background on Elton97

Elton97 discloses a Linux computer configured to perform proxy HTTP services.



190

See Elton97 at page 1.

The system described by Elton97 uses a Linux server with dual network interfaces. On one side

it is configured with addresses associated with a user’s home network.

To further ensure protection and anonymity, use one of the ``bogus’’ class addresses (seeTable 1) as per RFC1918. These IP addresses are set aside by the INTERNIC for usebehind a firewall. Any packet with one of these IP addresses is dropped by the Internetbackbone routers. See Figure 1 for an example of a network topology with a dual-homed

host firewall. The example configuration files in this article are based on this basictopology. Our protected network is assigned the ``bogus’’ Class C address 192.168.50,and we assume that the valid IP address of the Internet side of the firewall is111.222.333.1.


The network ID of 192.168.50/24 corresponds to the “home network” address block used by the

user device, illustrate below as “client workstation.”

See Elton97 figure 1.

The Elton97 system utilizes the open source component “Socks5,” which allows proxies

to be set up for many commonly used services, including HTTP, FTP, TELNET, finger, archie,

whois, ping and traceroute. See Elton97 at page 2. Alternatively, the Elton97 article discloses



191

the use of Trusted Information Systems Firewall Toolkit (TIS fwtk) as a proxy server. The TIS

toolkit provides proxy servers for HTTP, email

The TIS firewall toolkit provides very specific proxies for each service, giving you the

ability to set up just an HTTP proxy server, for example, if you wish to limit your users to just that service. When the package builds, the proxies that are built include an HTTP(http-gw), FTP (ftp-gw), TELNET (tn-gw), rlogin (rlogin-gw), X (x-gw) and genericproxy (plug-gw). Also included is a secure replacement for sendmail (smap) as well as anauthentication module (authsrv). The generic proxy gives you the ability to configureproxies for specific machines and ports. Possible uses for this proxy could be proxyingUsenet news as well as accessing e-mail through the POP3 protocol. (Socks5 does notinclude support for either News or POP3.)


While Elton97 does not explicitly disclose the SMTP proxy, it was well known at the

time of the invention that the TIS firewall kit included an SMTP proxy.

For example, the article “Creating a Linux Firewall Using the TIS Toolkit,” Linux

Journal archive, Volume 1996, Issue 25es (May 1996), ISSN:1075-3583, Benjamin Ewy.

(“Ewy96”) lists SMTP as one of the “fwtk” proxies.

The fwtk comes with proxies for telnet, rlogin, SMTP mail, ftp, http, X window, and ageneric TCP plug-board server that works as a transparent pass-through proxy for many

other services.

See Ewy96 at page 1.

11.3.3 Claim Analysis

11.3.3.1 a device having network settings configured for communication over a

home network without reconfiguring the network settings of the device

Kostick96 discloses a user device referred to as “warbird” that is configured for

communication over the “home network” 192.168.1.0/24. For example its host IP address is

192.168.1.2 and it communicates through a gateway IP address 192.168.1.1 that is also on the

home network. No reconfiguration is necessary for “warbird” to communicate with servers

located on the foreign network 20.2.51.0/24, such as “mccoy,” “enterprise,” and “relay.”



192


The network 20.2.51.0/24 represents a “foreign network” as far as hosts “warbird” and

“sparcbook” are concerned. Computers on network 20.2.51.0/24 would have access to a

gateway server appropriate for that network, typically with an address such as 20.2.51.253. Host

computers on network 20.2.51.0/24 would be configured to use the gateway to route packets to

other LAN networks that make up the Internet, as shown above in Figure 1 from Kostick96.

11.3.3.2 intercepting packets transmitted by the device

Packets addressed to hosts on network 20.2.51.0/24 are intercepted. The Court’s

construction for “intercepting” is “receiving and processing [e.g., data, packets] targeted for

another device.” See Markman Ruling at page 23. The ‘009 patent application included U.S.

Prov. Pat. Appl. No. 60-111,497 by reference, and that disclosure includes “intercepting”



193

techniques that involve receiving and processing ARP packets that are identified only by their

target IP address, i.e., the IP address of computer that is different from the computer that

intercepts and processes the packet.

In this instance, intercepting occurs in the “deathstar” computer, which performs

receiving and processing of packets targeted for IP addresses on the LAN segment 20.2.51.0/24

that differ from “deathstar’s” IP address. The “deathstar” computer has an IP address of

192.168.1.1 on the 192.168.1.0/24 network where “warbird” is sending packets. The “deathstar”

computer at IP address of 192.168.1.1 intercepts packets sent by “warbird” to the Telnet server

“enterprise.”

The Telnet request from “warbird” to 20.2.51.33 is intercepted by “deathstar.”



In fact any packets not addressed to the 192.168.1.0/24 LAN will be intercepted by the

“deathstar” gateway.

11.3.3.3 selectively modifying intercepted packets which are incompatible with

network settings configured for communication over the foreign

network to be compatible with the network settings configured for

communication over the foreign network

Selectively modifying intercepted packets

The Court construed the term “selectively modifying intercepted packets” to be

“choosing whether to modify intercepted packets and accordingly modifying intercepted

packets.” Kostick discloses that the Linux IP forwarding functionality can be configured to

selectively forward certain hosts and certain protocols on the 192.168.1.0/24 network, as well as

selectively forward to different destination networks:



194


Along these same lines, it is evident that the destination network specified in the

forwarding rule is configurable:

Therefore Kostick satisfies the Court’s construction for “selectively modifying

intercepted packets.”

modifying intercepted packets which are incompatible

The masquerade computer “deathstar” selectively modifies the intercepted packets by

replacing the source IP address specified for the “home” network, namely 192.168.1.2 for

“warbird” with an IP address and TCP port compatible with the “foreign network,” 20.2.51.0/24.

In the example of Kostick96 it replaces the “home” source address 192.168.1.2 with a foreign

address 20.2.51.119. This is indicated by the tcpdump packet trace captured on the 20.2.51.0/24

LAN:

20 Clearly the reference to “enterprise” is misplaced. The IP address specified in the filter is for the host “warbird.”



195

See Kostick96 page 3.

The masquerade computer “deathstar” selectively modifies the intercepted packets by

replacing the source TCP port number with a TCP port compatible with the “foreign network,”

20.2.51.0/24. Each computer on the 192.168.1.0/24 LAN is assigned a different TCP source port

number. Also, as seen in Kostick, separate port numbers were assigned to DNS lookup and

Telnet session connections.

As seen in Listing 1, showing masquerade log file packets passing through “deathstar,”

the port assigned for the DNS request was 6000 (EA60 hexadecimal) and 6001 (EA61

hexadecimal) for the Telnet session.


Let’s decode this stuff. First, the earliest packet is at the bottom. It is a DNS request(therefore UDP) from 192.168.1.2 to 20.2.51.2. mccoy is warbird’s DNS server in thiscase. The Masq column shows us the port on deathstar that is used for the masquerading.For the first DNS request, it is port 60000 (EA60). After the DNS resolution, the TCPconnection is established on the next available port over 60000, 60001.

See Kostick96 page 3.

This port mapping is also seen in Listing 3 shown above.

11.3.3.4 including IP addresses, gateway addresses, subnet masks, DNS

addresses, and protocol proxies;

The network settings for the home and foreign network, corresponding to the

192.168.1.0/24 and 20.2.51.0/24 networks include the “warbird” host IP address of 192.168.1.2

and the home gateway IP address of 192.168.1.1.



196

11.3.3.5 providing network services for the device corresponding to network

services available on the home network

The “user device” “warbird” is configured with a home host IP address of 192.168.1.2

and a home gateway IP address of 192.168.1.1. When used in the home network, the gateway IP

address allows “warbird” to access the Internet at large via conventional gateway services.

When connected to the foreign network via “deathstar” it can access services provided by

the servers “mccoy,” “enterprise,” or “relay” located on the 20.2.51.0/24 foreign network. If it

were connected directly to the foreign network it would not be capable of accessing these

resources because its network IP address and gateway IP address would be incorrect for the

20.2.51.0/24 foreign network.

As an example, Kostick discloses a Telnet session between “warbird” and “enterprise.”

11.3.3.6 provide network services otherwise inaccessible from the foreign

networks

Because the “user device” “warbird” is configured with a home host IP address of

192.168.1.2 and a home gateway IP address of 192.168.1.1, it would not be able to access

services provided by the servers “mccoy,” “enterprise,” or “relay located on the 20.2.51.0/24

foreign network if it were connected directly to the foreign network. To provide otherwise

inaccessible services available on the foreign network, the “deathstar” masquerading router is

necessary.

As an example, Kostick discloses a Telnet session between “warbird” and “enterprise”

that would not have been possible.

11.3.3.7 comprises providing a proxy service which includes resolving a domain

name to an address;

Kostick96 discloses a host computer “warbird” that uses the DNS serve “mccoy” to

resolve DNS domain name lookups. However, “warbird” does not communicate directly with

“mccoy.” Rather, “warbird” connects to “mccoy” through the proxy server “deathstar.”



197

The computer “deathstar” disclosed by Kostick96 provides a proxy service because

“deathstar” is required to open a TCP connection with “mccoy” to fulfill the request for a DNS

lookup, and the requesting computer “warbird” does not communicate directly with the DNS

server.

11.3.3.8 includes resolving a domain name to an address;

When “warbird” sends a DNS request to the DNS server “mccoy” it does so with a

source IP address in the packet that is incompatible with network addresses in the range

20.2.51.0/24. To provide the service of resolving a domain name, using a DNS server on the

foreign network, the “deathstar” masquerading router is necessary.

Kostick96 discloses a host computer with “home network” settings resolving a DNS

address request.


11.3.3.9 establishing a connection between the device and a configurationadapter in order for the configuration adapter to intercept packets

In Kostick96, the “configuration adapter” is the combination of the computers referred to

as “deathstar” and “mccoy.” A TCP connection is opened between “warbird” and “mccoy.”

11.3.3.10 examining contents of the intercepted packets to identify a domain

name; resolving the domain name to an address;

When a DNS request is made by “warbird” the request is received by “mccoy” and the

contents of the DNS packet are examined. If “mccoy” receives a packet that is not a DNS

request, it will not process it as a DNS request. If a DNS request packet is received by “mccoy”

that contains a domain name, the “mccoy” computer resolves the domain name to an IP address

either directly or by reference to a secondary DNS server.



198

11.3.3.11 establishing a connection between the configuration adapter and a

computer at the address corresponding to the domain name;

Kostick96 discloses a TCP connection between the “deathstar”(configuration adapter)

and a Telnet server, enterprise at 20.2.51.33.



Clearly a TCP connection is established between the Telnet serve and the configuration

adapter “deathstar.”

11.3.3.12 splicing the connections between the device and the configuration

adapter, and between the configuration adapter and the computer, to

form a single connection between the device and the computer

Kostick96 also discloses the splicing of two TCP sessions:




199

See Kostick96 Listing 2

The tcpdump trace shown above clearly indicates that the user’s device at 192.168.1.2 is

“spoofed” into thinking that it is the TCP endpoint to a connection with the “enterprise”

computer. Further evidence of TCP splicing is indicated by the way Kostick96 handles TCP

sequence numbers:

See Kostick at page 3.

11.3.3.13 without the network settings of the device being reconfigured.

As seen in Kostick96 there is no need to modify the network settings of the host

computers on the “home network” 192.168.1.0/24.

11.4 Millet in Combination with Bhagwat99 Renders the Claims of the


11.4.1 Background on Millet

U.S. Patent No. 6,434,627 (“Millet”), entitled “IP network for accommodating mobile

users with incompatible network addressing,” was awarded to Millet, et al. on August 13, 2002.

Application No.: 09/268,559 was filed on March 15, 1999.

Millet discloses an address translation method that allows a computer network toautomatically learn that a visiting node has attached to the network. The patent also discloses a

method wherein there is automatic establishment of a virtual gateway, thereby allowing the

visiting node to communicate with local nodes, other visiting nodes, and/or Internet sites.



200

The network performs an address translation to enable the connectivity of the visiting

node. The network maintains one or more globally unique outside addresses that are reachable

by Internet routers. When a visiting node communicates through the network, the network

translates the source address of packets to a particular one of its outside addresses.

The network also replaces destination addresses in packets received by the network that

are addressed to the particular outside address. Specifically, the network replaces the globally

unique outside address with the “home” address of the visiting node. Packets are then forwarded

to the visiting node.

11.4.2 Background on Bhagwat99

US Patent No. 7,139,268, entitled “Performance of intermediate nodes with flow

splicing,” was issued to Pravin Bhagwat and John Tracey on November 21, 2006

(“Bhagwat99”). It was issued from Application No.: 09/240,374 filed on January 29, 1999.

Bhagwat99 discloses a method and system with an intermediate node separating two end

point computers. The patent describes a system for “splicing” a data flow inbound to the

intermediate node, and a second data flow outbound from the intermediate node. The composite

“spliced” flow transforms the first data flow and the second data flow into a single composite

data flow originating at the source of the first data flow and terminating at the destination of the

second data flow.

In Figure 17, Bhagwat99 discloses the modification of packets passing through the proxy

server:

FIG. 17 is a flow diagram that depicts the steps of an example of splice source

processing. The majority of processing is performed in block 1702 and includesmodifying information in the TCP and IP packet headers. Step 1702 includes:

1. Modify source and destination address in IP header

2. Modify source and destination port in TCP header

3. Map sequence number from source to destination flow

4. Set acknowledgment field from rcv_nxt field of destination TCB



201

5. Set window field from rcv_wnd field of destination TCB

6. Set length field in IP pseudo header

7. Calculate and fill in TCP checksum

8. Fill in IP total length, type of service and time to live fields

The source and destination IP addresses and port numbers are modified by copying theappropriate values from the destination TCB. The sequence number is mapped from thesource flow to the destination flow. The acknowledgment number and receive windowfields are set by copying the values from the rcv_nxt and rcv_wnd fields of thedestination TCB respectively. The length field in the IP pseudo header is set. The TCPchecksum is calculated and filled in. The total length, type of service, and time to livefields of the IP header are filled in.

See Bhagwat99 at 13:44-14:3.

In addition, certain of the claims explicitly recite modifications to the packets:

14. A method recited in claim 10, wherein each of the first protocol, the second protocol,the third protocol and the fourth protocol are Transmission Control Protocol (TCP) inconjunction with either version 4 or version 6 of Internet Protocol (IP) and wherein step(c) of claim 1, includes the following steps (a), (b), (c), (d), and (e): (a) setting the sourceIP address in the IP header to the local IP address associated with the third source flowend point; (b) setting the destination IP address in the IP header to the remote IP addressassociated with the third source flow end point; (c) setting the source port number in theTCP header to the local port number associated with the third source flow end point; (d)setting the destination port number in the TCP header to the remote port numberassociated with the third source flow end point, and (e) modifying the sequence (SEQ)number in the TCP header; and wherein step (b) of claim 10, includes the following steps

(f), (g), (h), and (i): (f) replacing the acknowledgment (ACK) number in the TCP header;(g) replacing the window value in the TCP header; (h) modifying or recalculating theTCP checksum in the TCP header, and (i) modifying or recalculating the IP checksum inthe IP header; and wherein step (e) of claim 1, includes the following steps (j), (k), (l),(m), (n), (o), (p) and (q): (j) setting the source IP address in the IP header to the local IPaddress associated with the first destination flow end point; (k) setting the destination IPaddress in the IP header to the remote IP address associated with the first destination flowend point; (l) setting the source port number in the TCP header to the local port numberassociated with the first destination flow end point; (m) setting the destination portnumber in the TCP header to the remote port number associated with the first destinationflow end point; (n) replacing the sequence (SEQ) number in the TCP header; (o)modifying the acknowledgment (ACK) number in the TCP header; (p) modifying theTCP checksum in the TCP header, and (q) modifying the IP checksum in the IP header.

See Bhagwat99 claim 14 at 19:10-63.



202

The technique of TCP splicing can be applied to any application that utilizes the TCP

transport protocol to carry the application-level payloads. Bhagwat99 provides a detailed

description of the splicing of HTTP web page requests that are carried in TCP packets:

As an example we consider an intermediate node that allows World Wide Web content tobe partitioned across a set of servers. The web intermediate node starts by accepting aTCP connection from a client. It then reads one or more requests from the flow inboundfrom the client. Next the intermediate node determines an appropriate server to servicethe client request(s). It then establishes a connection, including of two flows one in eitherdirection, with the selected server assuming an appropriate connection is not alreadyavailable. The intermediate node then selects the inbound flow from the chosen serverand the outbound flow to the client and splices the selected flows. Finally, theintermediate node writes the request that it had received from the client to the server.

See Bhagwat99 at 7:27-40. (Emphasis added.) (See also Bhagwat99 at 7:41-50.)

In addition, Bhagwat99 explicitly refers to the transparent handling of DNS requests and

responses that are sent to and from DNS servers through a spliced TCP connection:

It will be understood by those skilled in the art that the process just described can beapplied to a wide variety of intermediate node functions and communication protocols.For example, the steps listed above for the web intermediate node can be used to provideload balancing and content partitioning for a list of protocols including HTTP, SOCKS,telnet, FTP, AFS, DFS, NFS, RFS, SMTP, POP, DNS, Sun RPC, and NNTP.

See Bhagwat99 at 7:51-58.

11.5 Stevens (Proxy ARP) in Combination withBhagwat97 Render the

Claims of the ‘099 Patent Obvious

11.5.1 Proxy ARP

Proxy ARP is a technique for intercepting ARP requests from a computer that is

configured with the wrong Network ID. The Proxy ARP concept is fully disclosed in the

following documents:

RFC 1027, S. Carl-Mitchell & J. Quarterman, October 1987.RFC 1919, “Classic v Transparent IP Proxies,” M. Chatel, March 1996.

Stevens TCP Illustrated at pages 60-62. (“Stevens”)

See sections 5.5 and 8.4.2 for detailed discussion of the Stevens reference.



203

11.5.2 Background on US Patent 5,941,988 (“Bhagwat97”)

US Patent No. 5,941,988, entitled “Session and transport layer proxies via TCP glue,”

was awarded to Pravin Bhagwat and David Maltz on August 24, 1999 (“Bhagwat97”). The

application for this patent was filed on January 27, 1997.

This reference describes a method of merging two separate TCP connections terminating

at a common host and “gluing” them into a single connection between a client computer and a

target server, such as a web server. An intermediate proxy called the “TCP proxy” is used to

“splice” the two separate connections. The “spliced” connection preserves the TCP end-to-end

semantics of packet byte sequence numbers, byte acknowledgement numbers, and flow control.

The approach described retains the session setup functions of the transport layer proxy,

but provides a method to push the data copying into kernel space to improve performance of the

relay operation of the common host. The byte stream arriving on one end of the split connection

is mapped directly into the sequence number space of the other split connection. This process of

mapping, or TCP gluing, involves updating a subset of TCP and IP header fields; that is, source

and destination addresses, port numbers, sequence numbers and checksum. These changes to the

TCP/IP packet headers are made on-the-fly as packets are relayed over the “spliced” connection

between the original separate TCP connections. The figures of the Bhagwat97 patent illustrate

this “splicing.”



204

See Figure 3 Bhhagwat97.

The above figure describes the same splicing disclosed in the ‘009 patent:

See ‘009 patent Figure 17.



205

For example element 716 of Figure 17 of the ‘009 patent illustrates the TCP connection

setup SYN packet for the client-to-gateway server connection. Then element 722 contains the

remote computer’s HTTP request to the proxy server, which results in a TCP connection setup to

the web server 712 by means of the SYN packet at element 724. This is followed by the HTTP

request to the web server at element 730 and the response from the web server at elements 732

and 736. Finally, the HTTP response is relayed to the remote computer at elements 734 and 738.

As indicated, the “splicing” technique maintains client-to-web server request and

acknowledgment sequence numbers.

Bhagwat97 discloses modifying packet TCP and IP packet header information at the

“TCP proxy” server.

Modifying Packet HeadersAs each segment is received at a glued socket, the segment’s headers are altered toaddress the segment to the socket at the other end of the glued connection. The segment’sTCP headers are altered so the segment will be intelligible to the end system when itarrives; that is, the segment will look like a continuation of the normal TCP connectionthe end system first started with the proxy. Processing a segment requires three steps;changing the IP and TCP headers and making special sanity checks.

Alter IP Header

C Change source and destination address to that of outgoing connection.C Remove IP options from incoming packet.C Update IP header checksum.

Alter TCP HeaderC Change source and destination port numbers to match outgoing connection.C Map sequence number from incoming sequence space to outgoing space. seq.sub.--num=(seq.sub.-- num-in6glue.sub.-- irs) +out6glue.sub.-- issC Map ACK number from incoming sequence space to outgoing space. ack.sub.--num=(ack.sub.-- num-in6glue.sub.-- iss) +out6glue.sub.-- irsC Update TCP header checksum.

See Bhagwat97 at 7:58-8:15.

This process of mapping, or TCP gluing, involves updating a subset of TCP and IPheader fields; that is, source and destination addresses, port numbers, sequence numbersand checksum. The changes to the TCP/IP packet headers are on-the-fly as packets arerelayed over the glued connection between the original separate TCP connections.



206

See Bhagwat97 Abstract.

Other documents authored by Bhagwat and/or Maltz include:

Improving HTTP Caching Proxy Performance with TCP Tap, David A. Maltz and PravinBhagwat, IBM Technical Report RC 21147, IBM, March 1998.

TCP splicing for application layer proxy performance, David A. Maltz and PravinBhagwat. IBM Technical Report RC 21139, IBM, March 1998.

The Bhagwat97 prior art is distinguished from earlier TCP proxy server solutions such as

the SOCKS architecture that used “split” TCP sessions:

The currently used techniques of constructing a TCP proxy (e.g., a SOCKS server)involves splitting a TCP connection into two halves (client-to-proxy and proxy-to-server)and then using an application layer server to exchange data between the two ends. Allknown current transport layer proxies perform the data copying function in user space;i.e., a user process waits in a tight loop reading data from one socket and writing it to

another one. Compared to the client or the server, the proxy spends twice as many CPUcycles on protocol processing, data copying, and context switching. What is needed is away to effectively push data movement operation into kernel space to make the relayoperation more efficient.See Bhagwat97 at 2:7-19.

11.5.3 HTTP Proxy Services

FIG. 3 shows such a synchronization scheme in use for an HTTP caching proxy.The message exchange illustrated in FIG. 3 is between a web browser (the client) 21, acaching proxy 22, and a web server 23. The web browser 21 opens a connection and

sends a URL addressed as “http:X” to the HTTP caching proxy 22. The caching proxy 22turns the ACKs off, opens the connection with the web server 23, and fetches the URL“http:X”. datal is retrieved from the web server 23 by the caching proxy 22 which thensets up the TCP glue 24. Once the TCP glue has been set up, the ACKs are turned back on and data flows from the caching proxy 22 to the web browser 21.


11.5.4 Spliced Connections to DNS Servers

Prior to the ‘009 patent application the use of DNS servers was well understood. See

RFC 1034 and RFC 103521. DNS is an application level protocol that can run on either TCP or

UDP transport layer protocols. See RFC 1034 at 15-16. DNS queries and responses are carried

21 RFC 1034 Domain Names – Concepts and Facilities, P. Mockapetris, November 1987. RFC 1035, Domain

Names – Implementation and Specification, P. Mockapetris, November 1987.



207

in a standard message format. The message format has a header containing a number of fixed

fields that carry query parameters.

It would have been obvious to one of ordinary skill in the art to use the TCP splicing

technique of Bhagwat97 to make DNS requests and receive DNS answer packers. Bhagwat97

discloses splicing of TCP connections and the use of a TCP proxy server to relay application

traffic such as HTTP requests and responses. There is no technical distinction between an

application layer DNS request packet and an HTTP request packet when the application packets

are passed through a spliced TCP relay connection.

Bhagwat97 confirms that the disclosures could be applied to other application protocols:

In general, the technique of TCP gluing can be applied to improve performance of anytransport layer proxy, including the HTTP caching proxy.


12 MISCELLANEOUS

I am being compensated at a rate of $275/hour. My compensation is not contingent in

any way on the outcome of this case. I have not published any articles or papers during the last

10 years. A list of materials I considered in writing this report is contained in Attachment A. A

list of cases in which I have testified as an expert at trial or at deposition is contained in my CV,

included herein by reference as Attachment B.

I expressly reserve the right to supplement this report in view of any additional

documents, interrogatory responses, contentions, or deposition testimony that may be produced

in discovery. If called upon I will revise my opinion to account for new information contained in

any new discovery provided.

My work on this matter continues and will continue through trial. My opinions,

therefore, may be supplemented at a later date. At trial, I may use enlargements of text,

drawings, figures, photographs, video-recordings, screen short or charts related to the subject

matter of this report, along with any of the materials provided to me as a basis for my opinions

and/or other material allowing me to explain my opinions.



Dated:Oct.31,2008

PeterAlexander.Ph.D.

208



Attachment A

Documents Referred To

Alexander Declaration in Support of Second Rule’s Motion for Partial Summary Judgment,

September 4, 2008.

U.S. Patents Nos. 6,130,892 (“’892 patent”), 6,636,894 (“’894 patent”), 6,868,399 (“’399

patent”), 7,088,727 (“’727 patent”) and 6,857,009 (“’009 patent”) (collectively “patents-in-suit”)

Prosecution Histories for US Patents 6,130,892, 6,636,894, 6,868,399, 7,088,727 and 6,857,009.

U.S. Patent No. 6,141,690 entitled “Computer network address mapping” awarded to Weiman.

US Patent 6,226,677, entitled “Controlled communications over a global computer network,”

awarded to Michael Slemmer

US Patent No. 6,205,481, entitled “Protocol for distributing fresh content among networked

cache servers,” awarded to Heddaya, et al.

U.S. Patent 6,128,601 (“VanHorne98”), entitled “Active client to communications network connection apparatus and method.”

Hospitality Net Article, “New room-service fare/High –speed Internet access (Atcom/InfoInstalled in Hyatt in San Jose, and the Four Seasons in Beverly Hills,” Dec. 8, 1998.

[SEC0002799-SEC0002800]

User’s Guide to Installing IPORT Internet Access System Server (v2.0), dated Sept. 21, 1998

(ATCOM Confidential) [SEC00520-SEC00721]

Network World Article “New room-service fare/High –speed Internet access,” dated Dec. 7,

1998, [SEC0002805-SEC0002807.]

IPORT Internet Access System Site Installation Guide (Version 2), October 13, 1998

[SEC00883-SEC00838.]

White Paper, “Connection Methods and Concepts for IPORT v2.x, dated November 1998.

[SEC00808-SEC00824.]


TCP/IP Illustrated, Volume 1, W. Richard Stevens, pp.60-62, 1994. (“Stevens”)

US Patent No. 5,941,988, entitled “Session and transport layer proxies via TCP glue,” was

awarded to Pravin Bhagwat and David Maltz on August 24, 1999 (“Bhagwat97”). Theapplication for this patent was filed on January 27, 1997.



2

US Patent No. 7,139,268, entitled “Performance of intermediate nodes with flow splicing,” was

issued to Pravin Bhagwat and John Tracey on November 21, 2006 (“Bhagwat99”). It was issued

from Application No.: 09/240,374 filed on January 29, 1999.

Request For Comments:RFC 1631. Network Working Group, The IP Network Address Translator (NAT) (May 1994)www.ftp.isi.edu/in-notes/rfc1631.txt. [http://www.ietf.org/rfc/rfc1631.txt]

RFC793 Transmission Control Protocol, Jon Postel, Information Sciences Institute, University of

Southern California, Sept. 1981. [http://www.ietf.org/rfc/rfc0793.txt]

RFC826 - Ethernet Address Resolution Protocol, David C. Plummer

Request For Comments: 826, November 1982. [http://www.ietf.org/rfc/rfc826.txt]

RFC 1541 outline of the DHCP protocol in 1993

RFC 1009 Braden et al “Requirements for Internet Gateways,” June 1987

RFC 1027 “Using ARP to Implement Transparent Subnet Gateways,” Carl-Mitchell et al,

October 1987


RFC 1027, S. Carl-Mitchell & J. Quarterman, October 1987.

RFC 1919, “Classic v Transparent IP Proxies,” M. Chatel, March 1996.

RFC 1034 Domain Names Network Working Group, P. MockapetrisRequest for Comments: 1034, Nov. 1987.

RFC 1035 Domain Names Implementation, Network Working Group P. MockapetrisRequest for Comments: 1035, Nov. 1987.

RFC 1541 Dynamic Host Configuration Protocol, Network Working Group R. Droms

Request for Comments: 1541 Bucknell University, Oct. 1993.

RFC 2123 Network Working Group R. Droms, Request for Comments: 2131 Bucknell

University, March 1997.

IP Masquerading with Linux, Chris Kostick, Linux Journal Issue 27, July 1996 (“Kostick96”)


RFC 1597, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg,

G. de Groot, March 1994 (“RFC1597”)



3

IP Masquerading Code Follow-up, Chris Kostick, Linux Journal Issue 43, November 1997(“Kostick97”)


ipfwadm-2.3.0, source code module ipfwadm.c with last modified date of July 30, 1996 availablefrom http://www.xos.nl/linux/ipfwadm/

Stevens p231-235, TCP Connection Handshake



Attachment B

Curriculum VitaePeter Alexander, Ph.D.



Peter Alexander, Ph.D.

Resume Page 2.

PETER ALEXANDER, Ph.D.

501 ½ Larkspur AvenueCorona del Mar, CA 92625

Office (949) 760 9990 Cell (949) 689 8692email: [email protected]

EDUCATION

Ph. D., Electrical Engineering, Massachusetts Institute of Technology, 1971MS, Electrical Engineering, University of Illinois, 1967BS, Electrical Engineering, University of Canterbury, New Zealand, 1965

PROFESSIONAL AFFILIATIONS & AWARDS

Fulbright Scholar, 1965National Science Foundation – Small Business Innovation Research, 1988Dept. of Energy – Small Business Innovation Research, 1988Member Association of Computing Machinery (ACM)Member IEEE Computer Society

PROFESSIONAL EXPERIENCE - SUMMARY

Technical Expertise - Computer software design, development & deployment

• Forensic data acquisition and analysis

• Microsoft Visual Studio component and application design

• Web integration of authentication services, streaming media services, ad displays,content feeds

• Implementation of real-time and media streaming systems

• Architecture and design of complex business systems involving database back ends

• Oracle 8i, 9i, SQL Server 2000, and DB2 database technology.

• Java, C, C++, Visual Basic, assembly language programming

• Embedded microprocessor designs

• Network equipment design and manufacture (LAN cards, routers, bridges)

• Security, authentication, networking, firewalls, hacking countermeasures, backups,archives and service level agreements for customer-outsourced data.

Domain Expertise - Client-server and web-based software applications

• ERP systems – financial, distribution, manufacturing, SF automation applications(Platinum Software)

• eCommerce - Secure web transactions, authentication (InfrastructureWorld.com,Syntricity, Inc.)




Resume Page 3.

• Semiconductor manufacturing – yield analysis, semiconductor defect analysis(Syntricity, Inc.)

LITIGATION RELATED EXPERIENCE

• Patent Litigation. Contributions made to fifteen different patent infringement cases,three of which required participation in claim construction for Markman hearings,including courtroom assistance to attorneys during claim construction. Authored threeinfringement and three validity rebuttal reports in support of plaintiffs, as well asnumerous non-infringement and invalidity reports on behalf of defendants. Testifiedin deposition as an expert on eighteen occasions in patent cases regarding claimconstruction, infringement and invalidity.

• Software contract disputes. Analysis of desktop, Internet, and client-server software

projects to determine adherence to industry-standard software developmentprocesses, and to evaluate architectural design decisions. Contributions made tonumerous cases, including court testimony in two, and deposition testimony in fourothers.

• Forensic analysis. Provided forensic analysis of Internet and computer hard drivetechnology to recover deleted computer data and determine algorithms. Performedanalysis of peer-to-peer file sharing servers for government agencies.

Jury Tes t imony

epicRealm Licensing, LLC (Parallel Networks) v. Autoflex Leasing, Franklin

Covey, Clark Consulting, Herbalife of America, Various Inc.

U.S. District Court, Eastern District of Texas, Marshall DivisionCivil Action Nos. 5:07-CV-125, 5:07-CV-126, 5:07-CV-135 (Hon. David Folsom)Matter: Web technology patent litigation.Technical Issues: Web site implementationResponsibilities: Retained by Franklin Covey, Co., Clark Consulting, Inc., Herbalife of

America, Various, Inc. Researched specific non-infringement issues;wrote declaration on support of motion to dismiss, and testified indeposition Dec., 2007 regarding that declaration. Testified indeposition regarding non-infringement by Herbalife (June 2008) andVarious Inc., (July 2008).Testified in jury trial for Parallel Networks v. Various, FriendFinder

August 20, 2008 regarding non-infringement and non-infringingalternatives.

Disposition: CurrentLaw Firms: Vedder Price, Chicago, IL; Jones Day, New York, NY; Pepper

Hamilton, Boston, MA, Fenwick & West, San Francisco, fordefendants.

Opposing counsel: Baker Botts.




Resume Page 4.

Dell USA, LP v. Lucent Technologies, Inc

US District Court, Eastern District of Texas, Sherman Division Civil Action No. C.A. 4:03-cv-347. (Hon. Richard A. Schell.)

Matter: Patent infringement - configurator applications for manufacturing.Technical Issues: Analysis of configurator algorithms, software automation.Responsibilities: Invalidity and non-infringement report on behalf of defendant Lucent

Technologies. Testified in deposition regarding non-infringement andinvalidity, Sept. 2007. Testified in jury trial on Jan. 29-30, 2008regarding non-infringement and invalidity.

Disposition: Jury returned a verdict in favor of Lucent Technologies for non-infringement.

Law Firm: Kirkland & Ellis, LLP, New York, NY, for defendant.Opposing counsel: Haynes & Boone, Dallas, TX.Orion IP LLC v. Mercedes-Benz USA et al

US District Court, Eastern District of Texas, Tyler Division.Civil Action No. 6:05-cv-322 (Hon. Leonard Davis)Matter: Patent Infringement – automated proposal generation.Technical Issues: Technology and analysis for web sites.Responsibilities: Wrote non-infringement report regarding Hyundai Motor America

web sites. Testified in deposition regarding non-infringement report.Testified in jury trial, May 24, 2007 regarding non-infringement,primarily for the ‘342 patent.

Disposition: For the contested ‘342 patent the jury found in favor of HyundaiMotor Corporation for non-infringement.

Law Firm: Jackson Walker L.L.P., Dallas, TX for defendant

Opposing counsel: Williams, Morgan & Amerson, P.C., and Wong, Cabello, Lutsch,Rutherford & Brucculeri, LLP, Houston, TX.

Amer Jneid et al v. Novell Inc., Tripole Corporation

Superior Court of State of California, County of Orange

Civil Action No. 02CC00182 (Hon. David C. Velasquez)Matter: Breach of contract.Technical Issues: Networking technology code analysisResponsibilities: Analysis of source code for Novell product implementations.

Testified at deposition on behalf of defendant Tripole Corp.Testified in Jury trial, November 2006.

Disposition: Completed work November, 2006. Jury awarded $13.5M damages to

client Tripole Corporation. The jury ruled against licensee NovellCorp. As the IP licensor, Tripole Corporation was awardedapproximately $13.5M damages.

Law Firm: Waldron & Olson, Newport Beach, CA, for Tripole Corp.Opposing counsel: Workman Nydegger, UT.CyberNET Engineering v. Con-Way Transportation

Circuit Court of the State of Oregon, for the County of Multnomah

Case No. 0107-07220, April 7-8, 2003Matter: Contract dispute.Technical issues: Local area network design and implementation for 300 service centers.




Resume Page 5.

Responsibilities: Researched relevant networking issues and testified at jury trial onbehalf of plaintiff.

Law Firm: Martin Bischoff Templeton Langslet, Portland, OR, for plaintiff

Disposition: Jury verdict in favor of plaintiff. 2003. The jury ruled in favor of CyberNET Engineering and awarded in excess of $600K.

Markman Hear ing tes t imony :

Finisar Corporation v. XM Satellite Radio, Inc. & Sirius Satellite Radio, Inc.

US District Court, Eastern District of Texas, Lufkin Division.

Civil Action No. No. 9:07-CV-99 (Clark) (Hon. Ron Clark)Matter: Patent litigation concerning satellite content distribution.Technical Issues: Indexing of data, scheduled data delivery via satelliteResponsibilities: Research claim construction issues. Testified briefly in claim

construction hearing, February, 2008.Disposition: Current.

Law Firm: Kilpatrick Stockton for plaintiff.Opposing counsel: Fish & Richardson, Washington, DC, and Kramer Levin Naftalis

& Frankel, New York.Auction Management Solutions Inc. v. Manheim Auctions Inc. et al

U.S. District Court, Northern District of Georgia, Atlanta Division

Civil Action No. 05-CV-0639 (RWS) (Hon. Richard W. Story)Matter: Online auction technology patent litigation.Technical Issues: Communications protocols and streaming mediaResponsibilities: Research claim construction issues. Testified in deposition regarding

claim construction in May, 2006. Provided a declaration to the Court.regarding construction terms for the asserted patent claims. Testified

in court during claim construction hearing, August, 2006.Wrote infringement report, validity report and testified in depositionMay 2008 on behalf of AMS as plaintiff.

Disposition: Current. Markman Order issued Oct. 2007. Defendant stipulated tonon-infringement in cross suit.

Law Firm: Finnegan Henderson Farabow Garrett & Dunner for plaintiff.Opposing counsel: Ropes & Gray LLP, Morris Manning & Martin, Covington &

Burling, Dow Lohnes & AlbertsonMcKesson Information Solutions v. Epic Systems Corp.

U.S. District Court, Northern District, Georgia, Atlanta Division

Civil Action No. 1:06-cv-2965 (Hon. Jack T. Camp)

Matter: Patent infringement - web-based services.Technical Issues: Analysis of web technology.Responsibilities: Assist in claim construction. Testified in deposition regarding

contributions to claim construction, Sept. 2007. Provided assistancewith technology tutorial entered into evidence at Markman Hearing,July 2, 2008.

Disposition: Current.Law Firm: Kilpatrick Stockton LLP, Atlanta, GA, for defendant Epic.




Resume Page 6.

Deposi t ion Test im ony

MicroStrategy Incorporated v. Business Objects Americas, Crystal Decisions

United States District Court, for the District of Delaware.

Civil Action No. 03-1124-KAJMatter: Web server report automation patent litigation.Technical Issues: Web server interaction with client browsers.Responsibilities: Analysis of source code to determine infringement issues. Wrote

Infringement expert report and Validity rebuttal report. Contributed toclaim construction. Testified in deposition regarding infringement andinvalidity rebuttal.

Disposition: Completed work in October 2005.Law Firm: Howrey Simon Arnold & White, Washington D.C. for plaintiff.Opposing counsel: Townsend Townsend & Crew

Young Conaway Stargatt & Taylor LLP

Sky Technologies LLC v. IBM Corp. and i2 Inc.U.S. District Court, Eastern District of Texas, Marshall Division

Civil Action No. 2:03CV454-DF Judge David Folsom.Matter: Supply-chain negotiation patent litigation.Technical Issues: Analysis of Java J2EE applications/ Enterprise Java Bean technology.Responsibilities: Conducted research concerning infringement position and claim

construction. Testified in deposition regarding infringement.Law Firm: Townsend Townsend and Crew, San Francisco, and Susman Godfrey

LLP, Houston, TX for plaintiff.Opposing counsel: Fitzpatrick, Cella, Harper & ScintoDisposition: Settled. Completed work in Jan. 2006.

Trilogy Software, Inc. v Selectica, Inc. U.S. District Court, Eastern District of Texas, Marshall Division

Civil Action No. 2-04-CV-160 (TJW). Judge T. John WardMatter: Internet eCommerce patent litigation.Technical Issues: Web server interaction with client browsers.Responsibilities: Research non-infringement issues in cross complaint. Testified at

deposition regarding Trilogy’s proposed claim construction. Wroteexpert declaration in support of claim construction, expert reportsregarding invalidity and non-infringement.

Law Firm: McKool Smith, Dallas, TX for defendant in cross complaint.Opposing counsel: Howrey Simon Arnold & White; Ireland Carroll and Kelley, PC.,

Jones & Jones; Brown McCarroll LLP.Disposition: Settled. Completed work in Jan. 2006.Datamize Inc. v. Charles Schwab & Co., CyberTrader, Inc.

U.S. District Court, Eastern District of Texas, Marshall Division

Civil Action No. 2:03-CV-321 Judge David Folsom.Matter: User interface patent infringement.Technical Issues: Interpretation of software design and implementation for applications

involving graphical user interfaces (GUI) allowing various degrees of built-in flexibility.




Resume Page 7.

Responsibilities: Assisted lawyers with interpretation of patent specification, andcontributed to claim construction terms as a computer expert. Testifiedin deposition as an expert witness regarding indefinite terms. Wrote

tutorial and declaration in support of defendant’s claim constructionbrief. Attended Markman Hearing and assisted attorneys withpreparation.

Law Firm: Orrick Herrington & Sutcliffe, New York, NY for defendant.Opposing counsel: McKool SmithDisposition: Settled. Completed work in Dec. 2004.Network Appliance v. BlueArc Corp.

U.S. District Court, Northern District of CA, San Francisco Division

Case No. C 03-05665 MHP Judge Marilyn Hall PatelMatter: Network file sharing patent infringement.Technical Issues: Interpretation of multiprocessor hardware/software architecture and

implementation for a Network File System data storage patent. Thetechnology involves multiprocessor operating systems, microprocessorhardware, Internet protocols, and inter-processor messaging.

Responsibilities: Advised lawyers on the interpretation of patent specifications,contributed to claim construction for “means plus function” structuredefinition, testified in claim construction deposition as an expertwitness. Wrote declaration in support of defendant’s claimconstruction brief; wrote rebuttal declaration in response to opposingexpert report.

Disposition: Completed work in Dec. 2004.Law Firm: Keker & Van Nest, San Francisco, CA and

Bromberg & Sunstein, Boston for defendant.Opposing counsel: Howrey Simon Arnold & WhiteE-Centives v. Coupons, Inc.

U.S. District Court, District of Maryland, Northern Division

Civil Action No. RDB-02-CV3701Matter: Web software patent infringement.Technical Issues: Microsoft ASP web servers, user tracking and consumer web services.Responsibilities: Conducted technical research on software implementation, wrote

expert opinion regarding invalidity, wrote rebuttal opinion re non-infringement, and testified at deposition on behalf of defendant.

Disposition: Settled April 2005.

Law Firm: Foley & Lardner, Washington, DC for defendantRader, Fishman & Grauer, Washington, DCOpposing counsel: Mintz, Levin, Cohn, Ferris, Glovsky and PopeoAcacia Media Technologies Corp. v. New Destiny Internet Group

U.S. District Court, Central District of California, Southern Division

Case No. SA CV 02-1040 JW (MLGx)Matter: Streaming multimedia systems patent litigation.Technical Issues: Implementation of web-based multimedia encoding.




Resume Page 8.

Responsibilities: Conducted research, created technology tutorial for Markmanhearings; wrote an expert declaration on video compressiontechnology. Testified in deposition.

Disposition: Completed work in Sept 2005.Law Firm: Hennigan Bennett & Dorman, Los Angeles, CA for plaintiff.Opposing counsel: Foley & Lardner, Fish & RichardsonPeninsular Technologies, LLC v. WinCan America

United States District Court, Western District of Michigan, Southern Division

Civil Action No. 1:04-CV-0305Matter: Multimedia patent litigation.Technical Issues: Characteristics of MPEG video for visual inspection systems.Responsibilities: Wrote non-infringement expert report and contributed to claim

construction. Testified in deposition regarding claim construction andnon-infringement.

Disposition: Completed work October 2005.Law Firm: Rader, Fishman & Grauer, Michigan for defendant.Opposing counsel: Piuce, Heneveld, Cooper, DeWitt &Litton, LLP

Inxight Software, Inc. v. Verity, Inc.

United States District Court, Northern District of California, San Francisco.

Civil Action No. C 05-01660 CRB Judge Charles R. BreyerMatter: Contract dispute regarding licensed software products.Technical Issues: Software architecture.Responsibilities: Research C++ and Java software architecture.

Wrote expert opinion on technical software implementation issues forlarge server-based linguistic analysis systems. Testified in deposition.

Disposition: Settled Feb. 2006.Law Firm: Manatt, Phelps & Phillips, LLP, Palo Alto, for defendant.Opposing counsel: Orrick, Herrington & Sutcliffe

Neoris de Mexico v. Ariba, Inc.

U.S. District Court, Northern District of CA, San Francisco Division.

Case No. C 02 1670 JSWMatter: Breach of warranty and contract.Technical Issues: B2B marketplaces and exchange design and developmentResponsibilities: Wrote expert opinion and testified at deposition on behalf of

defendant.

Disposition: Settled Jan. 2006. Completed work April 2004.Law Firm: Howard, Rice, Nemerovski, Canady, Falk & Rabkin, San Francisco,CA for defendant.

Opposing counsel: Legal Strategies GroupBusiness-To-Business Markets Inc. v. Kshema Tech. Ltd.

Superior Court of the State of California County of LA, Central District

Case No. BC280932, January 21, 2004Matter: Breach of contract.Technical Issues The software development contract involved a complex, Java-based

exchange web site. Apache web server, Weblogic application server,




Resume Page 9.

Tomcat application web server, Oracle 8.1 database server, Java JSPpages, Java EJB deployment, Linux operating system.

Responsibilities: Wrote expert declaration and testified at deposition on behalf of

defendant, Feb. 2004. Testified in second deposition, April 2007.Disposition: Motion for summary judgment in favor of defendant.Law Firm: Law Offices of Timothy Cronin, San Francisco, CA for defendant.Carma Consulting v. FileNet Corp and Farmers Insurance

United States District Court, Central District of California

Case No. SACV02-115DOC (MLGX), July 16, 2003Matter: Theft of trade secret case involving the alleged unauthorized release of

source code.Technical issues: Two Windows Active-X server components, written in Visual Basic

were supplied to Farmers Insurance as a run time OCX and a DLLrespectively. Evaluated the reproduction cost and the potential

economic damages for disclosure of source code.Responsibilities: Wrote expert opinion and testified at deposition on behalf of

defendant.Disposition: Motion for summary judgment in favor of defendant. 2003Law Firm: Cummins & White, Newport Beach, CA for defendant.Dongjin Semichem v. EmailFund

American Arbitration Association

AAA Case No. 50 T 168 0013403Matter: Software development contract dispute.Technical Issues: Elliptic Curve Cryptography for wireless handheld devices.

Encompasses Wireless Public Key Infrastructure, ECC algorithms,

RSA algorithms, equivalence of Public Key and Symmetric Keyencryption strengths, and WTLS.

Responsibilities: Wrote expert declaration. Conducted research on technical issues forplaintiff.

Disposition: Testified at deposition and at arbitration hearing on behalf of plaintiff.Law Firm: Lee, Kim & Song Professional Law Corporation, Los Angeles, CA for

plaintiff.Coupons Inc. v. Indian Harbor Insurance Company

American Arbitration Association

AAA Case No. 74 133 Y 91922 94 /DEARMatter: Patent insurance contract dispute.

Technical Issues: Web server software implementation and patent infringement issues.Responsibilities: Testify on technical issues analyzed during E-Centives v. CouponsInc. patent litigation while representing Coupons. Testified atdeposition on behalf of plaintiff, May 2006.

Disposition: Case settled, Aug. 2006.Law Firm: Farella Braun & Martel LLP, San Francisco, CA for plaintiff.Opposing counsel: Sonnenschein Nath & Rosenthal LLP, San Francisco, CALending Tree LLC v. LowerMyBills, Inc.

United States District Court, Western District of North Carolina

Charlotte Division




Resume Page 10.

Civil Action No. 3:05CV153-CMatter: Patent Infringement – credit analysis.Technical Issues: Technology and code analysis for web sites

Responsibilities: Wrote infringement and invalidity rebuttal reports. Testified indeposition regarding infringement, September 2006. Testified indeposition regarding Invalidity rebuttal report, November, 2006

Disposition: Settled 2006.Law Firm: King & Spalding LLP, Atlanta, GA for plaintiff.Opposing counsel: Sonnenschein Nath & Rosenthal LLP, Chicago, ILNetRatings, Inc. v. WebSideStory, Inc

US District Court, Southern District of New York Civil Action No. 06 Civ. 878 (LTS)(AJP)Matter: Patent infringement - web user tracking.Technical Issues: Analysis of web sites, client application software, and browser

characteristics.Responsibilities: Wrote invalidity report on behalf of defendant WebSideStory.

Testified in deposition regarding invalidity report, May 2007.Disposition: Settled Aug., 2007.Law Firm: Latham Watkins, LLP, New York, NY, for defendant.Opposing counsel: Dreier, LLP, New York, NY.WhitServe LLC, v. Computer Packages, Inc.

US District Court, Southern District of Connecticut.

Civil Action No. 3:06CV01935 (AVC)Matter: Patent infringement - web document services.Technical Issues: Analysis of MS Access VBA code and web technology.

Responsibilities: Prepare non-infringement and invalidity reports on behalf of defendantComputer Packages, Inc. Testified in deposition regarding invalidityand non-infringement reports, Sept. 2007

Disposition: Completed work Sept. 2007.Law Firm: Fitzpatrick, Cella, Harper & Scinto, New York, for defendant CPI.Opposing counsel: St. Onge Steward Johnson & Reens, CTOpposing counsel: Womble Carlyle Sandridge & Rice PLLC, Wilmington, DE.Taurus IP, LLC v. DaimlerChrysler and Mercedes Benz USA, Inc.

United States District Court, Western District of Wisconsin

Civil Action No. 07-C-0158-CMatter: Patent infringement - computer based management of data models

used for managing sales information.Technical Issues: Analysis of source code used to implement DaimlerChrysler andMercedes Benz web sites.

Responsibilities: Wrote non-infringement report. Testified in deposition regarding non-infringement, Dec. 2007.

Disposition: Court awarded summary judgment of non-infringement and invalidityon 2 claims.

Law Firm: Kilpatrick Stockton LLP, Atlanta, GA, for defendantsDaimlerChrysler & Mercedes Benz.

Opposing counsel: DeWitt, Ross and Stevens S.C., Madison, WI




Resume Page 11.

Telematics Corporation v. UPS, Inc., et al

U.S. District Court, Northern District of Georgia, Atlanta Division

Civil Action Nos. 1:07-cv-0105-ODE

Matter: Vehicle telematics technology patent litigation.Technical Issues: Computer implementation of GPS tracking systemResponsibilities: Retained by Motorola, Ryder, and Verizon to address infringement

allegations. Assist attorneys with claim construction issues; testified indeposition Jan., 2008 regarding claim construction.

Disposition: CurrentLaw Firms: Kilpatrick Stockton, Atlanta, GA, for defendant Motorola Inc., and

Roylance, Abrams, Berdo & Goodman, LLP, Washington, DC fordefendants Ryder Truck Rental, Teletrac, Inc.

Opposing counsel: Thomas, Kayden, Horstemeyer & Risley, LLPConstellation IP, LLC v. Avis Budget Group, FedEx Corporation.

United States District Court, Eastern District of Texas, Texarkana Division.Civil Action No. 5:07-cv-00038-DF-CMCMatter: Patent infringement - computer based customized presentations.Technical Issues: Analysis of FedEx web sites. Delivery of web pages to web browsers.Responsibilities: Wrote non-infringement report. Testified in deposition regarding non-

infringement, June, 2008.Disposition: Current.Law Firm: Finnegan Henderson Farabow Garrett & Dunner, Reston, VA, for

defendant FedEx.Opposing counsel:Sedona Corporation v. Open Solutions, Inc..

United States District Court, District of Connecticut.Index No. 3:07CV171 (TPS)Matter: Contract dispute regarding porting of source code from Java platform

to Microsoft .NET platform.Technical Issues: Java and C# source code analysis and comparisons for a large

application concerned with data warehouses/data marts for the bankingindustry.

Responsibilities: Wrote expert report regarding similarities of code. Testified indeposition, September, 2008.

Disposition: Current.Law Firm: Schiff Hardin LLP, San Francisco, CA for plaintiff Sedona

Corporation.Opposing counsel: Pullman & Comley, LLC, Bridgeport, CT.

Has a lso served as an exper t dur ing the last four years:

FlashFind Corp. v. Continental Graphics Corp., Boeing Company.

American Arbitration Association Case No. 75-18040048606 BRSHMatter: Fraud, Breach of Contract.Technical Issues: Analysis of Java and Microsoft .NET technology platforms for

document management in the Energy and Aerospace verticals.




Resume Page 12.

Responsibilities: Research on behalf of respondents Continental Graphics, and BoeingDisposition: Completed work August, 2007.Law Firm: Andrews Kurth LLP, Houston for respondent.

Opposing counsel: Bowen Lawyers, Houston.Valencia Systems, Inc. v. Packeteer, Inc.

American Arbitration Association Case No. NO. 74 117 Y 00661 06 DEARMatter: Misappropriation of Trade Secrets.Technical Issues: Analysis of network monitoring technology..Responsibilities: Prepare declaration regarding technology disclosures for claimant

Valencia Systems, Inc.Disposition: CurrentLaw Firm: Akin Gump Strauss Hauer & Feld LLP for claimant Valencia.Opposing counsel: DLA Piper US LLP.

WebSideStory, Inc v. NetRatings, Inc.US District Court, Southern District of California, San Diego Div. Civil Action No. 06cv408 WQH (AJB)Matter: Patent infringement - web user tracking.Technical Issues: Analysis of web sites and browser characteristics.Responsibilities: Wrote infringement report on behalf of plaintiff WebSideStoryDisposition: Settled Aug., 2007.Law Firm: Latham Watkins, LLP, San Diego, CA, for plaintiff.Opposing counsel: Brown, Raysman, Millstein, Felder & Steiner, New York, NY.Fortinet, Inc. v. Anchiva Systems, Inc

Superior Court of State of California, County of Santa Clara

Civil Action No. 106-CV-065174Matter: Misappropriation of Trade Secrets.Technical Issues: Technology and code analysis for virus detection.Responsibilities: Analysis of source code.Disposition: Completed work in Feb. 2007.Law Firm: Orrick, Herrington & Sutcliffe LLP, Menlo Park, CA for defendant.Opposing counsel: Farella Braun & Martel LLP, San Francisco, CA.Cogent Systems, Inc. v. Northrop Grumman Corporation

Superior Court of State of California

Los Angeles Superior Court, Central District

Civil Action No. BC332199

Matter: Breach of Contract, Misappropriation of Trade SecretsTechnical Issues: Technology and code analysis for automated fingerprint recognition.Responsibilities: Analysis of source code and system architecture.Disposition: Completed work April, 2007. Case settled September 2007.Law Firm: Parker Milliken Clark O’Hara Samuelian and Hennigan Bennett &

Dorman for plaintiff.Opposing counsel: Sheppard, Mullin, Richter & Hampton LLPAutomated Business Companies v. ENC Technology Corp. et al.

United States District Court, Southern District of Texas, Houston Division

Civil Action No. H-06-1032




Resume Page 13.

Matter: Patent Infringement – remote login and access.Technical Issues: Technology and code analysis for web sitesResponsibilities: Initial system analysis.

Disposition: Inactive.Law Firm: Fulbright and Jaworski for defendant LogMeIn, Inc. (formerly 3AM

Labs Inc. for defendant.Opposing counsel: Smyser Kaplan Veselka, LLP, and Dunlap Codding & Rogers, P.C.Rasterix Holdings LLC v. Research In Motion, Ltd., Arizan Corp.

Superior Court of Fulton County, State of Georgia

Civil Action No. 2003-CV-76785Matter: Breach of Agreement, Misappropriation of Trade Secrets.Technical Issues: Technology and code for document filters for hand-held devices.Responsibilities: Source code analysis.Disposition: Inactive.

Law Firm: Howrey, Chicago, IL, for defendant.Opposing counsel: Kilpatrick Stockton LLP, Atlanta, GA.Beilstein Institut Zu Forderung der Chemischen Wissenschaften v. MDL

Information Systems, Inc. U.S. District Court, Northern District of CA, San Francisco.

Civil Action No. C 04-05368 SIMatter: Breach of contract.Technical Issues: Database design and implementationResponsibilities: Analysis of organic chemistry database system.Disposition: Settled December 2006.Law Firm: Carroll, Burdick & McDonough LLP, San Francisco, CA, for plaintiff

Opposing counsel: Andrew Gold, Bogatin, Corman & Gold, Oakland, CAAmerican Calcar Inc. v. BMW North America, LLC

United States District Court, Southern District of California.

Civil Action No. 04CV00614 DMS (LSP) Judge Dana M. SabrawMatter: User interface patent litigation.Technical Issues: User interface characteristics, broadcast FM radio systems, GPS

navigation.Responsibilities: Research non-infringement issues. Wrote invalidity and non-

infringement expert opinions for two patents.Disposition: Defendant won non-infringement Motion for Summary Judgment

Work completed Oct. 2005. Case settled.

Law Firm: Howrey Simon Arnold & White, Irvine, CA, for defendant.Opposing counsel: Knobbe Martens Olson & Bear LLPOrion IP, LLC. v. Home Depot USA Inc., Harley Davidson, Inc., Toyota Motor

Sales, USA, Inc. U.S. District Court, Eastern District of Texas, Marshall Division

Civil Action No. 2:04-CV-297 LED. Judge Leonard Davis

Matter: eCommerce patent litigation.Technical Issues: Implementation of Internet browser technology.Responsibilities: Research non-infringement issuesDisposition: Settled January 2006.




Resume Page 14.

Law Firm: Vinson & Elkins, LLP, Houston, TX for defendant Harley Davidson.Opposing counsel: Williams, Morgan & Amerson, Ireland Carroll and Kelley, PCepicRealm Licensing, LLC v. Autoflex, Macerich Co.

U.S. District Court, Eastern District of Texas, Marshall DivisionCivil Action No. 2-05CV-356 DFMatter: Web technology patent litigation.Technical Issues: Web site implementationResponsibilities: Research non-infringement issues.Disposition: Work completed June 2007.Law Firm: Sidley Austin Brown, Dallas, TX, for defendant.Opposing counsel: Baker Botts; Ireland Carroll; Brown McCarroll; Jones & JonesAtHome Bondholders v. AT&T Corporation

Superior Court of State of California, County of Santa Clara

Civil Action No. CV 812506

Matter: Theft of trade secrets.Technical Issues: Implementation AT&T ISP network for Internet and mail services.Responsibilities: Analysis of e-mail and Internet traffic capacity planning; analysis of

migration technology used to transfer 850,000 Internet accounts fromAtHome network to AT&T Broadband network.

Disposition: Completed work in April 2005.Law Firm: Sidley Austin Brown, Washington D.C. for defendant.




Resume Page 15.

PROFESSIONAL EXPERIENCE

2003 to Present Independent Computer Consultant

Independent computer technology consultant since February 2003, offering advisoryservices for information technology organizations, venture capital groups and the legalprofession. Services have been provided for projects in the following areas:

• Computer software development contracts for Internet and client-server softwareimplementation.

• Disaster recovery for large scale IT operations.

• Definition of product design and market positioning for a “distance learning” productdesigned to enable training of employees via a web server application.

• Forensic analysis of computer data and electronic discovery from computer disks.

• Definition of a web-based eCommerce system to provide secure businesstransactions. Developed architectural plans and database schema for Oracle databaseimplementation.

• Provided technical consulting services regarding the behavior of certain scripts usedfor a mIRC chat server (Jedi 2.1). Analyzed the internal architecture of the Jedi relaychat system. At issue was the behavior of a Jedi server when a remote user (client)uploaded a file for distribution to other clients. Analyzed the upload scripts andformed a preliminary opinion regarding the functional behavior of the code.

• Provided research on spyware products that are downloaded to a user’s clientcomputer while browsing the web. Determined the behavior and installationmechanisms for this class of spyware products, and provided consulting on ways of

removing them.• Provide consulting services to eBusiness clients for the creation of SOAP integration

of database services. Provided planning assistance for a large, ASP (Active ServerPages) web site to implement live business information feeds.

• Analyzed web application server prototypes from Apache Software Foundationreference implementations such as the Apache HTTP server project, Jakarta TomcatProject (J2EE Servlet and JSP Web container), Turbine a servlet based applicationframework, and the Velocity Template Engine reference designs

2001 to 2003 Syntricity, Inc., San Diego, CA

Vice President Technical Operations

Syntricity is a supplier of application software to the semiconductor industry. Itscustomers include Intel, Sun Microsystems, Broadcom, Qualcomm and Conexant.Products are installed on Unix and NT 4.0 web servers at the customer site as Intranetsolutions (Enterprise), or on Unix servers at the Syntricity data center, which offers anASP style subscription services.




Resume Page 16.

Developed a large capacity warehouse architecture and deployable warehouse solution tosupport defect, FBM, lot history, non-lot equipment, and other data storage requirementsto support analysis of yield and production forecasts from test data acquired in the

semiconductor manufacturing environment. This system was built on Oracle 8i and 9icommercial RDBMS products. Implemented a comprehensive set of statistical analysistools including multivariate regression and confidence level testing to facilitate yieldtrend and production scheduling for semiconductor manufacturers. Developed amessaging transaction system - "Integration Server" for WIP/MES back-end businessprocesses. Various technologies were incorporated including: RMI, from a JMS inputqueue and JNDI for naming services.

The design was implemented with Oracle 9.2 loader and schema validation technology,and required user ETL data to be formatted as XML documents. Java 2 SE was theimplementation platform language. The web server, based on the Tomcat open source

code from the Apache Consortium, was enhanced to provide comprehensive accesscontrol according to user class, and included integrated end-user script-basedcustomization (using the open source Python interpreter). XML objects were usedextensively to represent web server data structures in the core implementation. Highvolume datalog insertion (ETL) back-end functionality was implemented for user uploadsvia FTP. An earlier generation C-coded CGI version was also supported. All productsdeveloped were web server solutions, with access via a standard browser. Responsible forcreating and managing design teams as well as quality assurance, configurationmanagement, technical hosting operations, and technical documentation groups.Responsible for product functional specifications, source code control, defect tracking,configuration/build management, and application validation.

Responsible for a team of 40 people across four groups that included softwareengineering, database design, quality assurance and technical operations. Java 2 was theimplementation platform language, and Oracle 8.1.6 was used for the warehousedatabase. All products were designed as web server solutions, with access via a standardbrowser. Responsible for creating and managing design teams as well as qualityassurance, configuration management, technical hosting operations and technicaldocumentation groups. Detailed understanding of source code control, defect tracking,configuration management and build tracking.

Customers using the hosting subscription center run under contractual Service Level

Agreements (SLA). The ASP hosted service is currently implemented on an E4800 Sunapplication server running Solaris 8, connected to an Oracle database server (Oracle8.1.6). Storage totaling approximately 1 Terabyte is provided through a combination of the EMC Clarion System 1 storage arrays (Raid-5) accessed via fiber channel, andnetwork attached storage using the Network Appliances NetApp devices. VeritasSANPoint Foundation Suite HA for Solaris is used as the storage management tool.




Resume Page 17.

2000 to 2001 InfrastructureWorld, San Francisco, CA

Chief Technology Officer

Infrastructureworld, a spin off from Bechtel Enterprises, offered services through acollaborative web site for large-scale construction projects. Managed development staff of 10, and operational staff of 3 to create, enhance and maintain the live web site.Responsible for a new web server implementation based on NT4.0 and Windows 2000technologies, to support authentication through certificates, user access control viaauthenticated account login, SSL extranet connections and document encryption.Investigated Public Key/Private Key encryption authentication mechanisms beforeselecting Windows NT integrated challenge/response authentication as the preferredauthentication technique.

Each business client was hosted as a separate virtual web site with secure access to

content that described the client’s projects offered for bid. Functionality includedinsurance and financing RFP’s, document management, and project collaboration. Inaddition, each web site offered integration of multimedia content for promotion of clientprojects, including steaming video and audio content. Implemented a secure data accesssystem using native NT operating system authentication services. All documents andfiles were transmitted via 128-BIT SS using server side certificates for serverauthentication to the client browser. Automatic virus scanning and cleaning wasimplemented for all documents and files uploaded by users to the web server. Theoperational web server site was implemented with a two-tier server configuration usingRaid (redundant) storage.

1999 to 2000 CareerPath.com, Los Angeles, CA

Senior Vice President, Technology

Management of Operations and Development teams. Lead the company’s Web site re-architecture project, providing higher levels of Web server and Oracle databaseperformance. Implementation of methodologies for project management, code review,quality assurance, and defect tracking. Managed the operations group (40) supporting theproduction Web site, encompassing wide area networking, Unix administration, OracleDBA support, HTML authoring and quality assurance teams. Managed the softwaredevelopment staff (25) which created new technology infrastructure and dynamic page

content using Java middle tier servlets, Java Beans, JSP presentation components, andOracle technology. Object oriented programming techniques were applied through usecase analysis.

Created a feed management system, written using server-side Java parsing technology, toprocesses Web job postings harvested from Web spider technology. Later enhancementsincluded development of a Content Management system (using XML pagerepresentation), vertical affiliate co-branding system, transparent registration and loginacross a federation of partnership Web sites, and a comprehensive on-line reports server.




Resume Page 18.

1999 Charles Schwab Online Trading, Phoenix, AZ

Independent Consultant

This project involved disaster recovery cold site planning for the Charles Schwab OnlineWeb Trading facility. The web capability was capable of handling 200,000+ concurrentusers, and was implemented with 300 load-sharing IBM gateway servers working behindeight Cisco Catalyst 7500 routers. The traffic was distributed across the front line serversand routed to an ensemble of 200 middle tier servers, which manage the business objectsand execute the trades. In the third tier, customer financial and demographic data wasmaintained on a group of seven IBM mainframes running DB2. A design was formulatedthat gives the Schwab organization a contingency backup system in the event of catastrophic failure of the main site.

1997 to 1999 Platinum Software Corp., Irvine, CA(Re-named as Epicor Software Corp)

Vice President, Development

Reported to the President until 7/1/98, then reporting to the Executive VP of Product/Marketing. Member of the Executive Committee (top 8 executives in Platinum).

Managed a team of about 100 contributors working on Windows NT-based Client-Serversystems. The Department was organized into five functional groups each headed by aDirector-level manager, and includes ERP application development, technology/toolsdevelopment, Windows/DOS legacy systems, QA and documentation teams.

This scope of the development effort encompassed the Platinum ERP client-serverproduct suites, which include financial and distribution applications. These applications,based on Microsoft SQL Server technology, are implemented within a two-tier tool set,and involved 500 tables and more than 2000 stored procedures. Responsibilities alsoincluded all ERP integration tools and application content. The ERP integration suiteallows remote transaction integration of customer relationship management, sales forceautomation, distribution, manufacturing, and financial applications, as well as OLAPbusiness intelligence reporting via client-side components and Microsoft DSS.

Direct management of teams deploying MS Message Queue, MS Transaction Server, MS

SQL Server 6.5 and 7.0, NT 4.0, XML, and business object technology. Successfullylaunched a high volume test group to establish performance of the client-server productsunder stress, and to determine their scalability. Built an architectural team to design andimplement 3 tier, thin-client framework, using Java business objects running on anapplication server. Established effective methodologies for fostering cooperation indevelopment projects requiring the participation of geographically remote design anddevelopment teams.

Developed a pure Java client-server system to support an end user form builderapplication. The objective of this project was to demonstrate an application server-centric




Resume Page 19.

3-tier architecture. Application servers are dispensers of services, and a Java compilationservice was the central technology being demonstrated. The pilot development showedbuilding block to support a broad variety business object models, forms architectures, and

rules engines. (JDK 1.1)

A full-functionality GUI in Java was also developed, along with a Java-basedCustomization Workbench, built, using the form class metaphor, which is familiar tousers of Visual Café, JBuilder, or J++ 6.0. The Java Swing classes were used in theimplementation.

Created a prototype OLAP decision support analysis system. The Platinum Info Reportpack contained OLAP cubes specific to the Platinum ERA financial, distribution andmanufacturing data. OLAP cubes were implemented on top of core Platinum applicationsto enable multi-dimensional analysis on key business drivers such as sales activity.

Reports contained in the Info Report Pack were designed to leverage graphical,WYSIWYG reporting and analysis capabilities of Crystal Info, a third party reportingpackage, including: presentation-quality formatting, charts, graphs, drill-down, top “N”analysis, search, sort and criteria selection.

1994 to 1996 Quixote Corp., Chicago, IL

Vice President, Technology (Reporting to the President of Legal

Technologies, Inc.)

Legal Technologies, a subsidiary of the Quixote Corp., was formed as a consortium of

four companies operating in the legal vertical market to address law office automation,and related legal services.

Formulated opinions and strategies for technology-related products being considered foracquisition or development by the company. Assisted the corporate legal counsel in theinterpretation of patent claims for the purpose of defending or initiating lawsuits.Participated in negotiations with plaintiffs to bring about resolution of legal conflicts.

Managed teams developing Windows client-server database applications for thelegal/judicial markets. These products involved MFC C++ and Visual Basic 4.0,NT/SQL Server and Btrieve technology.

Development of video deposition applications. Encoding of VHS tapes from videodepositions into MPEG using Real Magic encoders. Annotation of video to allow rapidsearch of content and synchronization of video to the written transcript. The user wasprovided with the ability to jump to a specific page and line in the written transcript withautomated tracking to the correct location in the displayed video. Similarly, the rollingvideo stream would automatically scroll the text display.




Resume Page 20.

1989 to 1992 Fibronics International, Lowell, MA

General Manager, Spartacus subsidiary

Successfully developed software products for TCP/IP and Unix-related networkingapplications. These products performed routing and bridging functions for Internetpackets, at data rates of up to 100Mbps across FDDI fiber networks. Technologyinvolved embedded C-coded Intel RISC CPU’s and Motorola 68K seriesmicroprocessors. In addition, a suite of Internet-protocol software packages wasdeveloped for integration of mainframes with other Fibronics TCP/IP LAN and WANproducts. Networking software developed for mainframe computers included: TCP/IPprotocol stack; Network File System (server) package; File Transfer Protocol (FTP)server module; Simple Mail Transfer Protocol (SMTP); 3270 terminal emulators; X-windows client functionality.

The NFS application was the result of a nine month development effort involving a teamof six software developers. The complete design, including all architectural components,was formulated from Sun Microsystems documentation, and the resulting concept wasimplemented from scratch in C++. A parallel research study of the competing AndrewFile System was also carried out. The NFS product was deployed by several largeFibronics customers.

1982 to 1988 Numerix Corporation, Newton, MA

President/CEO

Founder and CEO of a high-technology computer company with 130 employees. Led thecompany from its startup in May 1982 through rapid growth. Revenues grew from $0 to$10M in three years.

Supervised a software and hardware development team of 50 people, and a totalemployee headcount of 130. Lead contract negotiations with vendors, partners andinvestors. Intimately involved with product engineering, quality assurance and fieldreliability problems.

1975 to 1981 CNR, Inc., Newton, MA

Vice President

Managed software and hardware design teams for defense-related projects. Theseincluded: real-time data acquisition using microprocessor systems, real-timecommunications channel simulators, embedded Intel and Motorola microprocessorsystems, designs for the application of the Global Positioning System to air trafficcontrol, synchronization of the DOD world-wide communication system using atomicclocks to facilitate the distribution of a high-precision time reference.




Resume Page 21.

1972 to 1975 Univ. of Auckland - New Zealand

Asst. Prof., EE

Performed teaching and graduate research responsibilities for electrical engineering andcomputer science. Taught graduate level courses on control systems, communicationsystems, microprocessors and integrated circuit design. Taught undergraduate coursesinvolving electromagnetic theory, electronic circuit design and mathematics