NO: 426476US IN THE UNITED STATES PATENT AND … · PO Box 1450 Alexandria, Virginia 22313-1450 . U.S. Patent 6,128,298 Petition for Inter Partes Review i TABLE OF CONTENTS Page

NO: 426476US

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE __________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD

__________________

GOOGLE INC., Petitioner,

v.

ROCKSTAR CONSORTIUM US LP, Patent Owner.

__________________

Case IPR2015-_____ Patent U.S. 6,128,298 __________________

PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,128,298

UNDER 35 U.S.C. § 312 AND 37 C.F.R. § 42.104

Mail Stop PATENT BOARD Patent Trial and Appeal Board US Patent and Trademark Office PO Box 1450 Alexandria, Virginia 22313-1450

U.S. Patent 6,128,298 Petition for Inter Partes Review

i

TABLE OF CONTENTS

Page

I. MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8 ..................... 1

II. CERTIFICATION OF GROUNDS FOR STANDING .................................. 2

III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED .................... 2

A. Prior Art Patents and Printed Publications ............................................ 2

B. Grounds for Challenge .......................................................................... 4

IV. BACKGROUND OF THE ’298 PATENT ..................................................... 5

A. Overview of the ’298 Patent .................................................................. 5

B. Prosecution History of the ’298 Patent ................................................. 6

V. CLAIM CONSTRUCTION ............................................................................ 7

A. “waiting for the return packet” .............................................................. 9

VI. IDENTIFICATION OF HOW CHALLENGED CLAIMS 11–13 AND 24–26 ARE UNPATENTABLE ..................................................... 10

A. Claims 11 and 24 are anticipated by Kim ........................................... 10

B. Claims 12 and 25 are rendered obvious by Kim in view of Comer .............................................................................................. 18

C. Claims 13 and 26 are rendered obvious by Kim in view of Comer and RFC 792 ....................................................................... 23

D. Claims 11 and 24 are anticipated by Yeom ........................................ 27

E. Claims 12 and 25 are rendered obvious by Yeom in view of Comer .............................................................................................. 36

F. Claims 13 and 26 are rendered obvious by Yeom in view of Comer and RFC 792 ....................................................................... 40

G. Claims 11 and 24 are anticipated by Attanasio ................................... 43


ii

H. Claims 12 and 25 are rendered obvious by Attanasio in view of Comer ..................................................................................... 53

I. Claims 13 and 26 are rendered obvious by Attanasio in view of Comer and RFC 792 ............................................................... 57

VII. CONCLUSION .............................................................................................. 60


iii

TABLE OF AUTHORITIES Page Cases In re Trans Texas Holdings Corp., 498 F.3d 1290 (Fed. Cir. 2007) ....................................................................... 8 Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) ...................................................................8, 9 Statutes 35 U.S.C. § 102(a) ............................................................................................... 3 35 U.S.C. § 102(b) ........................................................................................... 3, 4 35 U.S.C. § 314(a) ............................................................................................... 5 35 U.S.C. § 315(a) ............................................................................................... 1 Rules 37 C.F.R. § 42.8 ................................................................................................... 1 37 C.F.R. § 42.22 ................................................................................................. 2 37 C.F.R. § 42.100 ............................................................................................... 7 37 C.F.R. § 42.104 ........................................................................................ 2, 10


1

I. MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8

Real Party-in-Interest: Google Inc. (“Petitioner”).

Related Matters: U.S. Patent No. 6,128,298 (the “’298 patent”) is asserted in

the following cases: (1) consolidated case Rockstar Consortium US LP et al v.

ASUSTeK Computer, Inc. et al., Consolidated Case No. 2:13-cv-00894 (E.D. Tex.),

which consolidated six different cases filed by Rockstar Consortium US LP; (2)

Arris Group, Inc. et al. v. Constellation Techs. LLC et al., Case No. 14-CV-114 (D.

Del.); (3) Bockstar Techs. LLC v. Cisco Sys. Inc., Case No. 13-CV-2020 (D. Del.).

The ’298 patent is also asserted in Google Inc. v. Rockstar Consortium US LP et

al., Case No. 4:13-cv-05933-CW (N.D. Cal.). In that case, Google requested a

declaration of non-infringement on the ’298 patent; Rockstar counterclaimed for

infringement of the ’298 patent; and Google then pled the affirmative defense of

invalidity with respect to the ’298 Patent. Google’s affirmative defense does not

trigger the statutory bar against filing an inter partes review petition. 35 U.S.C.

§ 315(a)(3). There are no patents or applications that claim the benefit of the filing

date of the ’298 patent.

Petitioner is also filing petitions for inter partes review challenging claims

14–19, 22–23, and 27–32 of the ’298 patent. Petitioner recommends assigning all

proceedings to the same panel.

Counsel: Lead Counsel: Scott A. McKeown (Reg. No. 42,866)


2

Backup Counsel: Greg Gardella (Reg. No. 46,045)

Service Information : Email : [email protected]

[email protected]

Post: Oblon Spivak, 1940 Duke St., Alexandria, VA 22314

Telephone: 703-412-6297 Facsimile: 703-413-2220

II. CERTIFICATION OF GROUNDS FOR STANDING

Petitioner certifies pursuant to Rule 42.104(a) that the patent for which

review is sought is available for inter partes review and that Petitioner is not

barred or estopped from requesting an inter partes review challenging the patent

claims on the grounds identified in this Petition.

III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)–(2), Petitioner challenges

claims 11–13 and 24–26 of the ’298 patent. The ’298 patent claims priority to

Provisional U.S. Patent Application No. 60/015,945, which was filed on Apr. 24,

1996. (Ex. 1001, the ’298 patent.)

A. Prior Art Patents and Printed Publications

Petitioner relies upon the following patents and printed publications:

Exhibit 1003 – “IP Address Reuse Through Transparent Port-Address

Translator,” by Il Hwan Kim et al. (“Kim”) was published by The Journal of Korea

Information and Communications Society in December 1995, which is prior to the


3

earliest filing date claimed by the ’298 patent (April 24, 1996). Kim is therefore

available as prior art under at least pre-AIA 35 U.S.C. § 102(a). Kim was not

considered during the original prosecution of the ’298 patent and is not cumulative

of any prior art considered by the examiner(s).

Exhibit 1006 – “A Transparent TCP/IP Gateway to Connect Private

Networks to the Internet,” by Heon Yeom et al. (“Yeom”). As shown by the

Declaration of Bob Kummerfeld (Ex. 1028), Yeom was publicly posted to the

Internet on January 30, 1995 and, therefore, was publicly available prior to the

earliest filing date claimed by the ’298 patent (April 24, 1996). See MPEP 2128

II.B (“Prior art disclosures on the Internet or on an on-line database are considered

to be publicly available as of the date the item was publicly posted.”) Yeom is

therefore available as prior art under at least pre-AIA 35 U.S.C. § 102(b). Yeom

was not considered during the original prosecution of the ’298 patent and is not

cumulative of any prior art considered by the examiner(s).

Exhibit 1007 – “Internetworking with TCP/IP: Design, Implementation, and

Internals,” Volume II, by Douglas E. Comer et al. (“Comer”) was publicly

available by at least December 31, 1991, which is prior to the earliest filing date

claimed by the ’298 patent (April 24, 1996). Comer is therefore available as prior

art under pre-AIA 35 U.S.C. § 102(b). Comer was not considered during the

original prosecution of the ’298 patent and is not cumulative of any prior art


4

considered by the examiner(s).

Exhibit 1008 – Request for Comments 792, “Internet Control Message

Protocol,” by J. Postel (“RFC 792”) was publicly available by at least September

1981, which is at least one year prior to the earliest filing date claimed by the ’298

patent (April 24, 1996). RFC 792 is therefore available as prior art under at least

pre-AIA 35 U.S.C. § 102(b). RFC 792 was not considered during the original

prosecution of the ’298 patent and is not cumulative of any prior art considered by

the examiner(s).

Exhibit 1023 – U.S. Patent No. 5,371,852 to Attanasio et al. (“Attanasio”)

issued on December 6, 1994, which is at least one year prior to the earliest filing

date claimed by the ’298 patent (April 24, 1996). Attanasio is therefore available

as prior art under at least pre-AIA 35 U.S.C. § 102(b). Attanasio was not

considered during the original prosecution of the ’298 patent and is not cumulative

of any prior art considered by the examiner(s).

B. Grounds for Challenge

Petitioner requests cancellation of challenged claims 11–13 and 24–26 under

the following statutory grounds:

i. Claims 11 and 24 are anticipated by Kim;

ii. Claims 12 and 25 are rendered obvious by Kim in view of Comer;

iii. Claims 13 and 26 are rendered obvious by Kim in view of Comer and RFC 792;


5

iv. Claims 11 and 24 are anticipated by Yeom;

v. Claims 12 and 25 are rendered obvious by Yeom in view of Comer;

vi. Claims 13 and 26 are rendered obvious by Yeom in view of Comer and RFC

792;

vii. Claims 11 and 24 are anticipated by Attanasio;

viii. Claims 12 and 25 are rendered obvious by Attanasio in view of Comer; and

ix. Claims 13 and 26 are rendered obvious by Attanasio in view of Comer and RFC

792.

Section VI below demonstrates, for each of the statutory grounds, that there

is a reasonable likelihood that Petitioner will prevail. See 35 U.S.C. § 314(a).

Additional explanation and support for each ground of rejection is set forth in the

Expert Declaration of Professor Vijay K. Madisetti, PhD (Exhibit 1009).

IV. BACKGROUND OF THE ’298 PATENT

A. Overview of the ’298 Patent

The ’298 patent is directed to the basic and well-known concept of network

address translation using an IP filter. (Ex. 1001, Abstract.) A source node in the

first network with a private IP address and port (pIP, pPort) sends an outgoing data

packet to an IP address and Port (iIP, iPort) corresponding to a destination node in

a second network. (Id. at 5:55–60.) An IP filter intercepts the outgoing data

packet and replaces the source node’s IP address/port number combination with an


6

IP address and port number of the IP filter (frIP, frPort) before sending the

outgoing data packet to the destination node in the second network. (Id. at 5:65–

6:4.) The IP filter also maintains a translation table, which stores, inter alia, the

source and destination node IP address and port numbers. (Id. at 5:40–50.) The IP

filter uses its own port number (frPort) plus an offset value to establish an index

into the translation table. (Id. at 6:2–4.) When the IP filter receives an incoming

data packet from the second network, the IP filter uses its port number with the

known offset as an index into the translation table. The IP filter replaces the IP

filter’s IP address/port number (frIP, frPort) in the incoming packet with the first

network’s IP address/port number (pIP, pPort), and then routes the packet to the

correct node in the first network. (Id. at 6:5–14.)

B. Prosecution History of the ’298 Patent

The application that matured into the ’298 patent, U.S. Patent Application

No. 08/842,328 (“the ’328 application”), was filed on April 24, 1997. The ’328

application claims priority to Provisional U.S. Application No. 60/015,945, which

was filed on April 24, 1996.

In a non-final office action mailed on April 27, 1999, the examiner rejected

claims 1-5, 9, 11, 14–18, 22, 24, and 27–31 of the ’328 application over U.S.

Patent No. 5,781,550 (“Templin”). (Ex. 1002, pp. 57–64.)

In a response dated July 27, 1999, the applicants submitted a declaration


7

under Rule 131 “including facts showing a completion of the invention claimed in

the present application before the filing date of the Templin reference (February 2,

1996).” (Ex. 1002, pp. 67–93.)

In a non-final office action dated October 12, 1999, the examiner rejected

claims 1–5, 9, 11–18, and 22–32 of the ’328 application as being obvious in view

of U.S. Patent No. 5,793,763 (“Mayes”). (Ex. 1002, pp. 96–101.)

In a response dated February 25, 2000, the applicants amended claims 6,

10, 19, and 23 to rewrite them in independent form. Furthermore, applicants

argued that “Mayes does not disclose such a lookup table for stored source

information, indexed by the filter node port number.” (Ex. 1002, pp. 106–15.)

The examiner allowed the application and the ’298 patent issued on October

3, 2000.

V. CLAIM CONSTRUCTION

In an inter partes review, claim terms in an unexpired patent are interpreted

according to their broadest reasonable interpretation (“BRI”) in view of the

specification in which they appear. 37 C.F.R. § 42.100(b); Office Patent Trial

Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). The USPTO uses BRI

because, among other reasons, the patentee has the opportunity to amend its claims in

this proceeding. See, e.g., Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756,

48,764 (Aug. 14, 2012) (“Since patent owners have the opportunity to amend their


8

claims during IPR, PGR, and CBM trials, unlike in district court proceedings, they

are able to resolve ambiguities and overbreadth through this interpretive approach,

producing clear and defensible patents at the lowest cost point in the system.”).

Thus, as required by the applicable rules, this Petition uses the BRI standard. The

BRI of claim terms here may be different from the construction that those same terms

may receive following claim construction proceedings in district court. See, e.g., In

re Trans Texas Holdings Corp., 498 F.3d 1290, 1297 (Fed. Cir. 2007). Thus the

claim constructions presented in this Petition, including where Petitioner does not

propose an express construction, do not necessarily reflect the claim constructions

that Petitioner believes should be adopted by a district court under Phillips v. AWH

Corp., 415 F.3d 1303 (Fed. Cir. 2005). In presenting this Petition, unless otherwise

stated, the grounds set forth herein are based on (1) the proposed claim

construction offered by the Patent Owner in Google Inc. v. Rockstar Consortium

US LP, et al., Case No. 13-5933 (N.D. Cal.) (Ex. 1026), or (2) for terms where

Patent Owner has not explicitly offered a claim construction, on petitioner’s

understanding of Patent Owner’s infringement contentions in Google Inc. v.

Rockstar Consortium US LP, et al., Case No. 13-5933 (N.D. Cal.). (Ex. 1027.) In

presenting the grounds set forth in this Petition, petitioner does not concede that

any claim constructions impliedly or expressly proposed by Patent Owner are

appropriate for the district court litigation, where a different legal standard applies


9

to the construction of the asserted claim terms. Petitioner does not believe that

many of the Patent Owner’s implied or express proposed constructions are

appropriate under Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005). Instead,

petitioner presents these proposed constructions to the Board for consideration in

determining the BRI because Patent Owner considers these constructions correct

under Phillips, and therefore necessarily also considers them within the appropriate

scope of the BRI. Petitioner further submits these constructions under 35 U.S.C. §

301(a)(2), which encourages submission of claim construction materials to prevent

patentees from arguing broad constructions under Phillips while simultaneously

arguing narrow constructions as the BRI.

A. “waiting for the return packet”

Claims 11, 12, and 25 recite the “waiting” term. The specification only uses

the “waiting for the return packet” term when reciting claim elements. (Ex. 1001,

1:60–61, 12:10, 12:20, 15:21, 16:49.) The specification uses the term “waits for a

response”: “The packet is transmitted to the Internet, and the IP filter waits for the

response.” (Ex. 1001, 3:57–58.) Accordingly, a person of ordinary skill in the art

would consider the broadest reasonable interpretation in light of the specification

and prosecution history of “waiting for the return packet” to mean able to receive

the return packet. (Ex. 1009, ¶ 55.) See also Ex. 1027 (Patent Owner’s

infringement contentions in Google Inc. v. Rockstar Consortium US LP et al., Case


10

No. 4:13-cv-05933-CW (N.D. Cal.), p. 20 (alleging “waiting” limitation is satisfied

because “As shown in exemplary citation 11.6(1), the [accused product] receives a

data packet from a server in response to a request packet with the replaced source

address.”); 35 U.S.C. § 301(a)(2) (under AIA, patentee statements on claim scope are

admissible to and should be considered by PTAB, to prevent inconsistent statements

on claim scope).

VI. IDENTIFICATION OF HOW CHALLENGED CLAIMS 11–13 AND 24–26 ARE UNPATENTABLE

Pursuant to Rule 42.104(b)(4)–(5), this section demonstrates that the

challenged claims are unpatentable.

A. Claims 11 and 24 are anticipated by Kim

Claim 11. Kim (Ex. 1004) [11A] A method of interfacing private and public data communications networks, through a filter node in communication with both networks, comprising the steps of:

“By focusing on the fact that there are significantly more actual UDP and TCP ports compared to the number of sockets simultaneously required by one node, the connections to external networks by multiple local nodes by using one global address can be provided by translating many local sockets to one global address and unused port number.” (Ex. 1004, p. 39.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 57.)

[11B] (a) receiving at the filter node, from the private network, a data packet having a destination address corresponding to a node in the public network and a source

“From this point on, the sockets in each node will be marked as (IP address, TCP port number), and all TCP packets will be expressed as (srcIP, srcPORT, dstIP, dstPORT).” (Ex. 1004, p. 39.) A packet is received with a source address of the inner network and a destination address in the outer network :


11

Claim 11. Kim (Ex. 1004) address corresponding to a node in the private network;

(Ex. 1004, p. 44.) “[Y]ou’ll see that the packet going from (S, 1000) to (D, 23) is relayed by G, changed to (G, 3000), and then sent to (D, 23) and that the packet sent from (D, 23) to (G, 3000) is relayed to (S, 1000) by G so that a one-to-one connection can be made between S and D.” (Ex. 1004, p. 40.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 60.)

[11C] (b) maintaining, by the filter node, the source address taken from the data packet;

“Take a look at Table 1. This table shows the sockets (IPaddr, PORT) created from the Node 1 (inner nodes) of the stub B class network with the address of 172.16.0.0 being corresponded with the port number of G (Gateway node) with a global address.” (Ex. 1004, p. 40.)

(Ex. 1004, p. 40.) A table entry with source address and port is allocated for a packet establishing a new connection:

(Ex. 1004, p. 44.) A port table maintains the IP address and port of


12

Claim 11. Kim (Ex. 1004) inner network nodes:

(Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 59.)

[11D] (c) replacing, in the data packet, the source address with an address of the filter node, wherein the source address includes a port number of the node in the private network and the address of the filter node includes a port number of the filter node;

“The transmitter header of an outbound packet is revised from (I. Addr. I. PORT) to (G. Addr. G. PORT) in accordance with the port-address translation table and then relayed to an external global network. In addition, the receiver header of a packet, received by G from outside, is revised from (G. Addr. G. PORT) to (I. Addr. I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) A packet’s source IP address and port are replaced with a source IP address and port of the gateway node:


[11E] (d) routing from the filter node, in the public network, the data packet having the replaced source

“The transmitter header of an outbound packet is revised from (I. Addr. I. PORT) to (G. Addr. G. PORT) in accordance with the port-address translation table and then relayed to an external global network. In addition, the receiver header of a packet, received by G from outside, is


13

Claim 11. Kim (Ex. 1004) address, according to the destination address, to the corresponding public node network;

revised from (G. Addr. G. PORT) to (I. Addr. I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 60.)

[11F] (e) waiting for a return packet from the public network, responsive to the data packet having the replaced source information;

“Each time a packet, requiring translation of the address, is discovered, G refers to this table to revise the header information before relaying the packet. This relay process occurs by monitoring inbound and outbound packets.” (Ex. 1004, p. 40.)

(Ex. 1004, p. 42.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 61, 63.)

[11G] (f) replacing, in the return packet, the destination address with the maintained source address; and


(Ex. 1004, p. 40.) “The receiver header of a packet, received by G, is revised from (G. Addr, G. PORT) to (I. Addr, I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.)


14

Claim 11. Kim (Ex. 1004) The return packet’s destination IP address and port are changed to the destination IP address and port of the inner node:


[11H] (g) routing from the filter node, in the private network, the return packet having the replaced destination address to the corresponding private network node.

“The receiver header of a packet, received by G, is revised from (G. Addr, G. PORT) to (I. Addr, I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 61.)

Claim 24. Kim (Ex. 1004)

[24A] A method of operating a filter node for interfacing first and second data communications networks, comprising the steps of:

“By focusing on the fact that there are significantly more actual UDP and TCP ports compared to the number of sockets simultaneously required by one node, the connections to external networks by multiple local nodes by using one global address can be provided by translating many local sockets to one global address and unused port number.” (Ex. 1004, p. 39.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 57.)

[24B] (a) receiving from the first network, a data packet having a

“From this point on, the sockets in each node will be marked as (IP address, TCP port number), and all TCP packets will be expressed as (srcIP, srcPORT, dstIP,


15

Claim 24. Kim (Ex. 1004) destination address corresponding to a node in the second network and a source address corresponding to a node in the first network;

dstPORT).” (Ex. 1004, p. 39.) A packet is received with a source address of the inner network and a destination address in the outer network :


[24C] (b) maintaining the source address taken from the data packet;


(Ex. 1004, p. 40.) A table entry with source address and port is allocated for a packet establishing a new connection:

(Ex. 1004, p. 44.) A port table maintains the IP address and port of inner network nodes:


16



[24D] (c) replacing, in the data packet, the source address with an address of the filter node, wherein the source address includes a source port number and the address of the filter node includes a port number of the filter node;

“The transmitter header of an outbound packet is revised from (I. Addr. I. PORT) to (G. Addr. G. PORT) in accordance with the port-address translation table and then relayed to an external global network. In addition, the receiver header of a packet, received by G from outside, is revised from (G. Addr. G. PORT) to (I. Addr. I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) The packet’s source IP address and port are replaced with a source IP address and port of the gateway node:


[24E] (d) sending to the second network the data packet having the replaced source address, whereby that packet is routed to the corresponding second network node;

“The transmitter header of an outbound packet is revised from (I. Addr. I. PORT) to (G. Addr. G. PORT) in accordance with the port-address translation table and then relayed to an external global network. In addition, the receiver header of a packet, received by G from outside, is revised from (G. Addr. G. PORT) to (I. Addr. I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.)


17

Claim 24. Kim (Ex. 1004) See also Madisetti Expert Declaration (Ex. 1009, ¶ 60.)

[24F] (e) receiving a return packet from the second network, responsive to the data packet having the replaced source information;

“Each time a packet, requiring translation of the address, is discovered, G refers to this table to revise the header information before relaying the packet. This relay process occurs by monitoring inbound and outbound packets.” (Ex. 1004, p. 40.) “The receiver header of a packet, received by G, is revised from (G. Addr, G. PORT) to (I. Addr, I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 61.)



(Ex. 1004, p. 40.) “The receiver header of a packet, received by G, is revised from (G. Addr, G. PORT) to (I. Addr, I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) The return packet’s destination IP address and port are changed to the destination IP address and port of the inner node:


18



[24H] (g) sending to the first network the return packet having the replaced destination address, whereby that packet is routed to the corresponding first network node.

“The receiver header of a packet, received by G, is revised from (G. Addr, G. PORT) to (I. Addr, I. PORT) and delivered to an internal local area network.” (Ex. 1004, p. 40.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 61.)

B. Claims 12 and 25 are rendered obvious by Kim in view of Comer

1. Obviousness Arguments

Claims 12 and 25 depend from claims 11 and 24. Claims 12 and 25 recite

“buffering, at the filter node, further data packets received from the private

network while waiting for the return packet, and repeating steps (b) through (g) on

an individual basis for the further packets, if any, that were buffered.” The ability

to buffer data packets was well known prior to April 1995, the alleged conception

date. (Ex. 1009, ¶¶ 37–38, 46.)

One example of buffering is disclosed in Comer, which describes the basic


19

principles, operations, and packet structures used in TCP/IP communications. (Ex.

1007, p. xv.) One of the operations used in TCP/IP communications is “Window-

Based Flow Control.” (Ex. 1007, p. 265.) TCP/IP communications use

acknowledgement packets with window advertisements, which inform the sending

node of the receiving node’s available buffer. (Ex. 1007, p. 265.) If the window

advertisement is zero, the sending node stops transmitting packets to that receiving

node and maintains outgoing data packets in a buffer. (Ex. 1007, p. 265.) Until

the sending node receives a non-zero window, the sending node uses a probing

procedure to verify the receiving node’s buffer is still full. (Ex. 1007, p. 267.) The

probing procedure consists of sending packets from the sending node and receiving

acknowledges with window advertisements from the receiving node on an

individual basis, until such time that a non-zero window advertisement is received

at the sending node. (Ex. 1007, p. 267.)

It would have been obvious to a person of ordinary skill in the art at the time

of invention of the ’298 patent to combine Kim with the teaching of Comer. (Ex.

1009, ¶¶ 70–73.) Both Kim and Comer are from the same field of endeavor,

communications using TCP/IP protocols. Compare Kim (Ex. 1004, p. 37) (“This

translation occurs by searching the TCP/IP header information of all packets that

pass through the border to the external network and revising the header by

referencing the mapping table between the global address and the local address.”)


20

with Comer (Ex. 1007, p. xv) (“Since the publication of Internetworking With

TCP/IP in 1988, many readers have asked for a second volume that provides more

information on how the TCP/IP protocols operate. This text attempts to satisfy the

need for additional information”); Ex. 1009, ¶ 70.)

Specifically, Comer is a textbook that discusses the standard procedures and

operations of TCP/IP packet communications as used by those of ordinary skill in

the art at the alleged time of invention of the ’298 patent. Because Kim is a

translation system for a TCP/IP communications network it uses the TCP/IP

communication protocols discussed in Comer. Indeed, Kim itself teaches that its

port-address translator utilizes other standard TCP/IP data packet protocols such as

SYN, FIN, ACK etc. (Ex. 1003, pp. 41, 43.) Therefore, the TCP/IP packet

buffering and window advertisement schemes described in Comer would have

been present in the TCP/IP packets processed by Kim’s port-address translator.

(Ex. 1009, ¶ 70.)

A skilled artisan as of April 1995 would have recognized a number of

benefits to buffering data packets in Kim’s port-address translator. Comer itself

describes advantages to the TCP/IP window advertisement protocol. First, use of

window advertisements allows communicating nodes to “control the flow of data

across a connection.” (Ex. 1007, p. 265.) This allows a receiving node to

advertise “small window sizes to limit the data a sender can generate.” (Ex. 1007,


21

p. 265.) Kim also notes the benefits of controlling inbound packets: “By

fundamentally controlling inbound requests, a security effect that is provided by

the firewall system can be obtained.” (Ex. 1003, p. 43.) A skilled artisan would

understand that controlling the flow of in and outbound data based on available

buffer space is a critical feature that avoids disruption of communications. (Ex.

1009, ¶ 71.) If a receiving node’s buffer becomes full additional received packets

can be dropped due to lack of buffer space to store the packets. (Ex. 1009, ¶ 71.)

One of skill would further understand that packet loss could easily be avoided by

implementing standard TCP/IP window advertisement protocols as described in

Comer. (Ex. 1009, ¶ 71.)

Adding Comer’s buffering scheme to Kim’s port-address translator would be

well within the technical skill of one of ordinary skill in the art. (Ex. 1009, ¶ 72.)

Kim is a software-based solution that already has the capability to handle TCP/IP

communication protocols. (Ex. 1009, ¶ 72.) Adding buffering through window-

based flow control would present no great technical challenges, and would not

negatively impact the function of Kim’s port-address translator. (Ex. 1009, ¶ 72.)

2. Claim Charts

Claim 12. Kim (Ex. 1004) in view of Comer (Ex. 1007) [12A] A method as claimed in claim 11,

See Section VI. A., claim 11.

[12B] comprising buffering, at the

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the


22

Claim 12. Kim (Ex. 1004) in view of Comer (Ex. 1007) filter node, further data packets received from the private network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 67–69.)

Claim 25. Kim (Ex. 1004) in view of Comer (Ex. 1007)

[25A] A method as claimed in claim 24,

See Section VI. A., claim 24.

[25B] comprising buffering further data packets received from the first network while waiting for the return packet, and

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a


23

Claim 25. Kim (Ex. 1004) in view of Comer (Ex. 1007) repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 67–69.)

C. Claims 13 and 26 are rendered obvious by Kim in view of Comer

and RFC 792


Claims 13 and 26 depend from claims 12 and 25. Claims 13 and 26 recites

translation of data packets “in accordance with an internet control message

protocol (ICMP).” ICMP data packets do not include a field for source or

destination port number. (Ex. 1009, ¶ 75.) The ’298 patent teaches that translation

of ICMP packets is accomplished by storing the “sequence field of the [ICMP]

packet in pPort in the table.” (Ex. 1001, 7:14–16.)


24

It would have been obvious to translate ICMP packets based on the

disclosures of RFC 792. RFC 792 is the official Internet Protocol standard for the

Internet Control Message Protocol (ICMP). (Ex. 1008, p. 1.) Just as in the ‘298

patent, RFC 792 teaches that the “sequence number may be used by the echo

sender to aid in matching the replies with the echo requests,” more specifically by

using it “like a port in TCP or UDP to identify a session.” (Ex. 1008, p. 15,

emphasis added.) Thus, just as in the ‘298 patent, the ICMP protocol describes

using a unique sequence number to identify a communications session. A person

of ordinary skill in the art would thus have understood that using the identifier or

sequence fields in an ICMP packet in place of a port number would allow a port-

address translation system to translate ICMP messages. (Ex. 1009, ¶ 75.)

Accordingly, the Kim system as modified by the teaching of RFC 792 could send

and receive ICMP messages.

Kim, Comer, and RFC 792 are from the same field of endeavor, Internet

Protocol communications. Compare Kim (Ex. 1004, Abstract) (“IP address reuse

through automatic translation between local and global addresses is considered as

an appropriate solution prior to adopting a new protocol.”) with Comer (Ex. 1007,

p. xv) (“Since the publication of Internetworking With TCP/IP in 1988, many

readers have asked for a second volume that provides more information on how

the TCP/IP protocols operate. This text attempts to satisfy the need for additional


25

information”) and RFC 792 (Ex. 1008, p. 1) (“ICMP, uses the basic support of IP

as if it were a higher level protocol, however, ICMP is actually an integral part of

IP, and must be implemented by every IP module.”); (Ex. 1009, ¶ 76.) Thus, one

of ordinary skill in the art would have been aware that the teachings of RFC 792

were directly applicable to the TCP/IP communications system of Kim and Comer.

A person of ordinary skill in the art would have had several motivations to

modify Kim and Comer to handle translation of ICMP packets. RFC 792 teaches

that processing of ICMP packets provides a number of benefits to a TCP/IP

communications system. For example, ICMP packets can be used to “report an

error in datagram processing,” such as “when a datagram cannot reach its

destination, datagram cannot reach its destination, when the gateway does not have

the buffering capacity to forward a datagram, and when the gateway can direct the

host to send traffic on a shorter route.” (Ex. 1008, p. 1.) RFC 792 thus describes

beneficial control messages that “provide feedback about problems in the

communications environment.” (Ex. 1008, p. 1.) A person of ordinary skill would

have further understood that ICMP packets were common in TCP/IP

communications at the alleged time of invention. (Ex. 1009, ¶ 77.) Were Kim’s

port-address translator system unable to process ICMP packets it would be unable

to fully and effectively communicate with other nodes in a TCP/IP network. (Ex.

1009, ¶ 77.) Finally, Kim itself explicitly invites modification of its port-address


26

translator system to handle ICMP messages: “Considerations are needed for a

variety of protocols including ICMP, SNMP, and RIP.” (Ex. 1003, p. 43.)

Adding translation of ICMP packets to Kim’s port-address translator would

be well within the technical skill of one of ordinary skill in the art. (Ex. 1009,

¶ 78.) Kim is a software-based solution that already has the capability to handle

TCP/IP communication protocols. (Ex. 1009, ¶ 78.) Translation of ICMP packets

would present no great technical challenges, and would not negatively impact the

function of Kim’s port-address translator. (Ex. 1009, ¶ 78.)

2. Claim Charts

Claim 13. Kim (Ex. 1004) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008)


See Section VI. C., claim 12.

[13B] wherein the data packets include packets in accordance with an internet control message protocol (ICMP).

“The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these same values in the echo reply.” (Ex. 1008, pp. 15, 17, 19.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 75.)

Claim 26. Kim (Ex. 1004) in view of Comer (Ex. 1007) and RFC 792

(Ex. 1008) [26A] A method as claimed in claim 25,

See Section VI. C., claim 25.

[26B] wherein the data packets include packets

“The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP


27

Claim 26. Kim (Ex. 1004) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008)

in accordance with an internet control message protocol (ICMP).

to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these same values in the echo reply.” (Ex. 1008, pp. 15, 17, 19.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 75.)

D. Claims 11 and 24 are anticipated by Yeom

1. Statement of Non-Redundancy

The rejections based on Yeom are necessary because Petitioner expects that

Patent Owner will attempt to antedate the Kim reference. Patent Owner swore

behind the Templin reference during prosecution, asserting that their Rule 131

declaration and the accompanying documents “show[ed] a completion of the

invention claimed in the present application before the filing date of the Templin

reference (February 2, 1996).” (Ex. 1002, p. 72.) Additionally, in the pending

litigation Patent Owner asserted that U.S. Patent No. 6,128,298 “is entitled to a

priority date of “April 28, 1995.” (Ex. 1025, p. 2.) Petitioner does not agree with

the Patent Owner’s claims of priority; however, if Patent Owner is successful in

showing its alleged early conception date, and is further successful in

demonstrating the requisite diligence for its alleged priority date, the ground raised

below with respect to Yeom would not be redundant of the grounds raised in

Sections VI.A through VI.C with respect to Kim. Accordingly, all grounds should

be included for trial.


28

2. Claim Charts

Claim 11. Yeom (Ex. 1006) [11A] A method of interfacing private and public data communications networks, through a filter node in communication with both networks, comprising the steps of:

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network. Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 80.)

[11B] (a) receiving at the filter node, from the private network, a data packet having a destination address corresponding to a node in the public network and a source address corresponding to a node in the private network;

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) A packet is received with a source address of the inner network and a destination address in the outer network :

(Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 81–82.)

[11C] (b) maintaining, by the filter node, the source address

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the


29

Claim 11. Yeom (Ex. 1006) taken from the data packet;

((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) A table entry with source address and port is allocated for a packet establishing a new connection:

(Ex. 1006, p. 3.) The table with maintained source information is searched for a matching entry:


[11D] (c) replacing, in the data packet, the source address

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the


30

Claim 11. Yeom (Ex. 1006) with an address of the filter node, wherein the source address includes a port number of the node in the private network and the address of the filter node includes a port number of the filter node;

((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) The packet’s source IP address and port are replaced with a source IP address and port of the gateway node:


[11E] (d) routing from the filter node, in the public network, the data packet having the replaced source address, according to the destination address, to the corresponding public node network;

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) A packet is sent from the gateway to its destination in the outer network:

(Ex. 1006, p. 3.)


31

Claim 11. Yeom (Ex. 1006) See also Madisetti Expert Declaration (Ex. 1009, ¶ 82.)

[11F] (e) waiting for a return packet from the public network, responsive to the data packet having the replaced source information;

“From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network. Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 84.)


“Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) The return packet’s destination IP address and port are changed to the destination IP address and port of the inner node:


[11H] (g) routing from the filter node, in the private network, the return packet having the replaced destination address to the

“Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) A packet is routed from the gateway to its destination in the inner network:


32

Claim 11. Yeom (Ex. 1006) corresponding private network node.


Claim 24. Yeom (Ex. 1006)

[24A] A method of operating a filter node for interfacing first and second data communications networks, comprising the steps of:

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network. Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 80.)

[24B] (a) receiving from the first network, a data packet having a destination address corresponding to a node in the second network and a source address corresponding to a node in the first network;

“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) A packet is received with a source address of the inner network and a destination address in the outer network :


33

Claim 24. Yeom (Ex. 1006) (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 81–82.)


“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) A table entry with source address and port is allocated for a packet establishing a new connection:

(Ex. 1006, p. 3.) The table with maintained source information is searched for a matching entry:

(Ex. 1006, p. 3.)


34

Claim 24. Yeom (Ex. 1006) See also Madisetti Expert Declaration (Ex. 1009, ¶ 83.)


“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) The packet’s source IP address and port are replaced with a source IP address and port of the gateway node:



“Whenever an inner site I1 wants to make a TCP connection with outside host O2, it would send a request as if it is on a real IP network. The gateway G which has a real IP address G, when receiving the packet, would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3). From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet with originator (G,p3) and sent to the outside network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 82.)

[24F] (e) receiving a return packet

“From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet


35

Claim 24. Yeom (Ex. 1006) from the second network, responsive to the data packet having the replaced source information;

with originator (G,p3) and sent to the outside network. Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 84.)


“Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) The return packet’s destination IP address and port are changed to the destination IP address and port of the inner node:



“Likewise, all the packets from the outside network with originator (O2,p2) and destination (G,p3) would be transformed with destination (I1,p1) and feed into the inner network.” (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 84.)


36

E. Claims 12 and 25 are rendered obvious by Yeom in view of

Comer







date. (Ex. 1009, ¶¶ 37–38, 46.) As explained in more detail above, Comer teaches

one example of buffering. (Supra, pp. 18–19.)

It would have been obvious to a person of ordinary skill in the art the time of

invention of the ’298 patent to combine Yeom with the teaching of Comer. (Ex.

1009, ¶¶ 92–94.) Both Yeom and Comer are from the same field of endeavor,

communications using TCP/IP protocols. Compare Yeom (Ex. 1006, Title) (“A

transparent TCP/IP gateway to connect private networks to the internet”) with

Comer (Ex. 1007, p. xv) (“Since the publication of Internetworking With TCP/IP

in 1988, many readers have asked for a second volume that provides more


need for additional information”); Ex. 1009, ¶ 92.)



37


the art at the alleged time of invention of the ’298 patent. Because Yeom is a


communication protocols discussed in Comer. Indeed, Yeom itself teaches that its

port-address translator utilizes TCP/IP data packet protocols such as RST, FIN,

ACK etc. (Ex. 1006, p. 3.) Therefore, the TCP/IP packet buffering and window

advertisement schemes described in Comer would have been present in the TCP/IP

packets processed by Yeom’s port-address translator. (Ex. 1009, ¶ 92.)


benefits to buffering data packets in Yeom’s port-address translator. Comer itself

describes advantages to the TCP/IP window advertisement protocol. First, use of

window advertisements allows communicating nodes to “control the flow of data

across a connection.” (Ex. 1007, p. 265.) This allows a receiving node to


p. 265.) A skilled artisan would understand that controlling the flow of inbound

data based on available buffer space is an important feature that avoids disruption

of communications. (Ex. 1009, ¶ 93.) If a receiving node’s buffer becomes full

additional received packets can be dropped due to lack of buffer space to store the

packets. (Ex. 1009, ¶ 93.) One of skill would further understand that packet loss

could easily be avoided by implementing standard TCP/IP window advertisement


38

protocols as described in Comer. (Ex. 1009, ¶ 93.)

Adding Comer’s buffering scheme to Yeom’s port-address translator would

be well within the technical skill of one of ordinary skill in the art. (Ex. 1009,

¶ 94.) Yeom is a software-based solution that already has the capability to handle

TCP/IP communication protocols. (Ex. 1009, ¶ 94.) Adding buffering through

window-based flow control would present no great technical challenges, and would

not negatively impact the function of Yeom’s port-address translator. (Ex. 1009,

¶ 94.)

2. Claim Charts

Claim 12. Yeom (Ex. 1006) in view of Comer (Ex. 1007) [12A] A method as claimed in claim 11,

See Section VI. E., claim 11.

[12B] comprising buffering, at the filter node, further data packets received from the private network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.)


39

Claim 12. Yeom (Ex. 1006) in view of Comer (Ex. 1007) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 89–91.)

Claim 25. Yeom (Ex. 1006) in view of Comer (Ex. 1007)


See Section VI. E., claim 24.

[25B] comprising buffering further data packets received from the first network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the


40

Claim 25. Yeom (Ex. 1006) in view of Comer (Ex. 1007) TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 89–91.)

F. Claims 13 and 26 are rendered obvious by Yeom in view of

Comer and RFC 792





destination port number. (Ex. 1009, ¶ 97.) The ’298 patent teaches that translation

of ICMP packets is accomplished by storing the “sequence field of the [ICMP]

packet in pPort in the table.” (Ex. 1001, 7:14–16.) As explained in more detail

above, it would have been obvious to translate ICMP packets based on the

disclosures of RFC 792. (Supra, p. 24.) Accordingly, the Yeom system as

modified by the teaching of RFC 792 could send and receive ICMP messages.

Yeom, Comer, and RFC 792 are from the same field of endeavor, Internet

Protocol communications. Compare Yeom (Ex. 1004, Title) (“A transparent

TCP/IP gateway to connect private networks to the internet”) with Comer (Ex.

1007, p. xv) (“Since the publication of Internetworking With TCP/IP in 1988,

many readers have asked for a second volume that provides more information on

how the TCP/IP protocols operate. This text attempts to satisfy the need for


41

additional information”) and RFC 792 (Ex. 1008, p. 1) (“ICMP, uses the basic

support of IP as if it were a higher level protocol, however, ICMP is actually an

integral part of IP, and must be implemented by every IP module.”); (Ex. 1009,

¶ 98.) Thus, one of ordinary skill in the art would have been aware that the

teachings of RFC 792 were directly applicable to the TCP/IP communications

system of Yeom and Comer.


modify Yeom and Comer to handle translation of ICMP packets. RFC 792 teaches

that processing of ICMP packets provides a number of benefits to a TCP/IP









communications at the alleged time of invention. (Ex. 1009, ¶ 99.) Were Yeom’s

port-address translator system unable to process ICMP packets it would be unable

to fully and effectively communicate with other nodes in a TCP/IP network. (Ex.


42

1009, ¶ 99.)

Adding translation of ICMP packets to Yeom’s port-address translator

would be well within the technical skill of one of ordinary skill in the art. (Ex.

1009, ¶ 100.) Yeom is a software-based solution that already has the capability to

handle TCP/IP communication protocols. (Ex. 1009, ¶ 100.) Translation of ICMP

packets would present no great technical challenges, and would not negatively

impact the function of Yeom’s port-address translator. (Ex. 1009, ¶ 100.)

2. Claim Charts

Claim 13. Yeom (Ex. 1006) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008)


See Section VI. G., claim 12.



Claim 26. Yeom (Ex. 1006) in view of Comer (Ex. 1007) and

RFC 792 (Ex. 1008) [26A] A method as claimed in claim 25,


[26B] wherein the data packets include packets in accordance with an internet

“The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these


43

Claim 26. Yeom (Ex. 1006) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008)

control message protocol (ICMP).

same values in the echo reply.” (Ex. 1008, pp. 15, 17, 19.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 97.)

G. Claims 11 and 24 are anticipated by Attanasio

1. Statement of Non-Redundancy

The ground raised in the following section is meaningfully distinct from

those above and relies upon a fundamentally different prior art reference. The

ground detailed in Sections VI.A–F rely upon Kim and Yeom as the primary

references. The grounds detailed in Sections VI.G–I rely upon Attanasio as the

primary reference. Whereas Kim and Yeom describe a port-address translator that

uses a port-address translation table to effect translation (Ex. 1004, p. 40; Ex. 1006,

p. 3), Attanasio describes a port-address translator that uses a message switch table

and routing functions to effect translation. (Ex. 1023, Abstract.) As Patent Owner

may attempt to distinguish elements of the challenged claims based upon

purportedly unique claim features, which are clearly described by Attanasio, all

grounds should be included for trial.

2. Claim Charts

Claim 11. Attanasio (Ex. 1023) [11A] A method of interfacing private and public data

“The present invention provides a method and apparatus for enabling a cluster of computers to appear as a single computer to host computers outside the cluster. A host computer communicates only with a gateway to access destination nodes and processes within the cluster. The gateway has at least one message switch which


44

Claim 11. Attanasio (Ex. 1023) communications networks, through a filter node in communication with both networks, comprising the steps of:

processes incoming and outgoing port type messages crossing the cluster boundary.” (Ex. 1023, Abstract.)

(Ex. 1023, Figure 2.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 102.)

[11B] (a) receiving at the filter node, from the private network, a data packet having a destination address corresponding to a node in the public network and a source address corresponding to a node in the private network;

“In a similar manner, an outgoing message 220, is shown originating at a source node 105 within the cluster 200; passing through the interconnect 110, gateway message switch 240, gateway port 230, cluster boundary 125, and ultimately to the destination host 130.” (Ex. 1023, 6:37–42.) “While different PP protocols will use headers containing different information, they will always contain the source port number and destination port number.” (Ex. 1023, 8:50–53.) “While the MM headers used by different MM protocols may vary, they will all contain three fields: The MM address of the sending machine (source address), the MM address of the destination machine (destination address), and the protocol identifier for the kind of PP protocol being used.” (Ex. 1023, 8:61–67.) “Box 625 determines if the message is an outgoing message. An outgoing message must have originated at a node within the cluster (SADDR is the address of a cluster node) and be destined for a host outside the cluster (DADDR is the address of a host outside the cluster). If either of these conditions is not satisfied, i.e., the message is not an outgoing message, the message is processed at the frame level in box 640.” (Ex. 1023, 14:50–57.)

Filter Node

Private Data Communications

Network Public Data Communications

Network


45

Claim 11. Attanasio (Ex. 1023) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 103–05.)

[11C] (b) maintaining, by the filter node, the source address taken from the data packet;

“The message switch 400 comprises a message switch table 410 and the necessary software needed to route messages having a plurality of protocols and port numbers. Once the values of the destination port and protocol of the message are determined, the pair of values is looked up in the message switch table 410. (Column 412 represents values of destination ports and column 414 represents values of message protocols in the message switch table 410). For each pair of destination port and protocol values on an incoming message, there exists only one function on an incoming message, there exists only one function designated f_1, f_2, . . . f_N in column 418 of the message switch table 410. This selected function, which is typically a software program, is run to determine to which node, and to which communication port on that node, the incoming message will be sent.” (Ex. 1023, 11:21–37.)

(Ex. 1023, Figure 4.)

See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 106–07.)

[11D] (c) replacing, in the data packet, the source address with an address of the filter

“For outgoing messages,…[t]he message switch then alters the message so that the source address is the gateway address rather than the address of the source node.” (Ex. 1023, 5:47–52.) “However, if the message is an outgoing message type, it is processed in box 630 before going on the network. In box 630, the source address in the message header (SADDR) is changed to that of the address of the cluster. The cluster address for this purpose is the (or an) address of the gateway where the message will be placed on


46

Claim 11. Attanasio (Ex. 1023) node, wherein the source address includes a port number of the node in the private network and the address of the filter node includes a port number of the filter node;

the network.” (Ex. 1023, 14:58–64.) “[T]he message switch must change this source port number to one of the port numbers on the gateway when the message leaves the cluster. This insures that the cluster appears as a single image computer to hosts on the network.” (Ex. 1023, 15:6–10.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 106–07.)

[11E] (d) routing from the filter node, in the public network, the data packet having the replaced source address, according to the destination address, to the corresponding public node network;

“In box 630, the source address in the message header (SADDR) is changed to that of the address of the cluster. The cluster address for this purpose is the (or an) address of the gateway where the message will be placed on the network. By changing the source address in this way, hosts on the network external to the cluster will view the message as coming from the gateway and not the source node within the cluster. As a result, the source node will be invisible to the external host and the entire cluster will have the image of a single computer, whose address is the gateway connection address. At this point, the outgoing message is ready for frame level processing in box 640.” (Ex. 1023, 14:60–15:4.)



47

Claim 11. Attanasio (Ex. 1023) [11F] (e) waiting for a return packet from the public network, responsive to the data packet having the replaced source information;

“FIG. 5 is a flowchart description of how an incoming message is processed by the present invention. “Box 505 shows the cluster gateway waiting for a message. There are many well known ways for doing this.” (Ex. 1023, 11:42–46.)

(Ex. 1023, Figure 5A.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 108.)


“The destination IP address is changed to the internal address of the specified node, and if necessary, the destination port is changed to the specified port number. The modified IP message is then sent to the specified node via the Network Interface for the cluster interconnect.” (Ex. 1023, 11:37–42.) “Once the new NODE__PORT and NODE__ADDR values are calculated as described above, they are used to replace values in fields of the incoming message. In box 570, the destination port field (see FIG. 3D and 3E) in the PP header are changed (if necessary) to equal the value DPORT. In some protocols, other fields may have to be changed (e.g. header checksum) to maintain coherency in the header. In box 575, the destination address in the MM header is changed to equal the value of NODE__ADDR. At this point, shown in box 580, the appropriate network protocols/headers are added to the incoming message for it to be transmitted on the interconnect.” (Ex. 1023, 13:65–14:9.)


48

Claim 11. Attanasio (Ex. 1023)

(Ex. 1023, Figure 5A, Figure 5B.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 109.)

[11H] (g) routing from the filter node, in the private network, the return packet having the replaced destination address to the corresponding private network node.

“The destination IP address is changed to the internal address of the specified node, and if necessary, the destination port is changed to the specified port number. The modified IP message is then sent to the specified node via the Network Interface for the cluster interconnect.” (Ex. 1023, 11:37–42.) “At this point, shown in box 580, the appropriate network protocols/headers are added to the incoming message for it to be transmitted on the interconnect…. [T]he inbound message, with modified headers, is passed to the Network Interface for the cluster interconnect (110 in FIG. 1) to be sent to the selected destination node in the cluster.” (Ex. 1023, 14:7–19.)

(Ex. 1023, Figure 5B.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 109.)

Claim 24. Attanasio (Ex. 1023)


49

Claim 24. Attanasio (Ex. 1023) [24A] A method of operating a filter node for interfacing first and second data communications networks, comprising the steps of:

“The present invention provides a method and apparatus for enabling a cluster of computers to appear as a single computer to host computers outside the cluster. A host computer communicates only with a gateway to access destination nodes and processes within the cluster. The gateway has at least one message switch which processes incoming and outgoing port type messages crossing the cluster boundary.” (Ex. 1023, Abstract.)


[24B] (a) receiving from the first network, a data packet having a destination address corresponding to a node in the second network and a source address corresponding to a node in the first network;

“In a similar manner, an outgoing message 220, is shown originating at a source node 105 within the cluster 200; passing through the interconnect 110, gateway message switch 240, gateway port 230, cluster boundary 125, and ultimately to the destination host 130.” (Ex. 1023, 6:37–42.) “While different PP protocols will use headers containing different information, they will always contain the source port number and destination port number.” (Ex. 1023, 8:50–53.) “While the MM headers used by different MM protocols may vary, they will all contain three fields: The MM address of the sending machine (source address), the MM address of the destination machine (destination address), and the protocol identifier for the kind of PP protocol being used.” (Ex. 1023, 8:61–67.)

Filter Node

Private Data Communications

Network Public Data Communications

Network


50

Claim 24. Attanasio (Ex. 1023) “Box 625 determines if the message is an outgoing message. An outgoing message must have originated at a node within the cluster (SADDR is the address of a cluster node) and be destined for a host outside the cluster (DADDR is the address of a host outside the cluster). If either of these conditions is not satisfied, i.e., the message is not an outgoing message, the message is processed at the frame level in box 640.” (Ex. 1023, 14:50–57.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 103–05.)


“The message switch 400 comprises a message switch table 410 and the necessary software needed to route messages having a plurality of protocols and port numbers. Once the values of the destination port and protocol of the message are determined, the pair of values is looked up in the message switch table 410. (Column 412 represents values of destination ports and column 414 represents values of message protocols in the message switch table 410). For each pair of destination port and protocol values on an incoming message, there exists only one function on an incoming message, there exists only one function designated f_1, f_2, . . . f_N in column 418 of the message switch table 410. This selected function, which is typically a software program, is run to determine to which node, and to which communication port on that node, the incoming message will be sent.” (Ex. 1023, 11:21–37.)

(Ex. 1023, Figure 4.)


51

Claim 24. Attanasio (Ex. 1023) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 106–07.)


“For outgoing messages,…[t]he message switch then alters the message so that the source address is the gateway address rather than the address of the source node.” (Ex. 1023, 5:47–52.) “However, if the message is an outgoing message type, it is processed in box 630 before going on the network. In box 630, the source address in the message header (SADDR) is changed to that of the address of the cluster. The cluster address for this purpose is the (or an) address of the gateway where the message will be placed on the network.” (Ex. 1023, 14:58–64.) “[T]he message switch must change this source port number to one of the port numbers on the gateway when the message leaves the cluster. This insures that the cluster appears as a single image computer to hosts on the network.” (Ex. 1023, 15:6–10.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 106–07.)


“At this point, the outgoing message is ready for frame level processing in box 640.” (Ex. 1023, 15:4–9.) “Box 640 performs the frame level processing... and places the newly created frame message on the network.” (Ex. 1023, 15:11–16.)


[24F] (e) receiving a return packet from the second

“All messages arriving at the cluster 200, from the external network 120, arrive with the cluster gateway 109 external address as their destination IP address in their IP header.” (Ex.


52

Claim 24. Attanasio (Ex. 1023) network, responsive to the data packet having the replaced source information;

1023, 11:1–5.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 109.)


“The destination IP address is changed to the internal address of the specified node, and if necessary, the destination port is changed to the specified port number. The modified IP message is then sent to the specified node via the Network Interface for the cluster interconnect.” (Ex. 1023, 11:37–42.) “Once the new NODE__PORT and NODE__ADDR values are calculated as described above, they are used to replace values in fields of the incoming message. In box 570, the destination port field (see FIG. 3D and 3E) in the PP header are changed (if necessary) to equal the value DPORT. In some protocols, other fields may have to be changed (e.g. header checksum) to maintain coherency in the header. In box 575, the destination address in the MM header is changed to equal the value of NODE__ADDR. At this point, shown in box 580, the appropriate network protocols/headers are added to the incoming message for it to be transmitted on the interconnect.” (Ex. 1023, 13:65-14:9.)

(Ex. 1023, Figure 5A, Figure 5B.)


53

Claim 24. Attanasio (Ex. 1023) See also Madisetti Expert Declaration (Ex. 1009, ¶ 109.)


“The destination IP address is changed to the internal address of the specified node, and if necessary, the destination port is changed to the specified port number. The modified IP message is then sent to the specified node via the Network Interface for the cluster interconnect.” (Ex. 1023, 11:37–42.) “At this point, shown in box 580, the appropriate network protocols/headers are added to the incoming message for it to be transmitted on the interconnect…. [T]he inbound message, with modified headers, is passed to the Network Interface for the cluster interconnect (110 in FIG. 1) to be sent to the selected destination node in the cluster.” (Ex. 1023, 14:7–19.)

(Ex. 1023, Figure 5B.) See also Madisetti Expert Declaration (Ex. 1009, ¶ 109.)

H. Claims 12 and 25 are rendered obvious by Attanasio in view of

Comer







date. (Ex. 1009, ¶¶ 37–38, 46.) As explained in more detail above, Comer teaches


54

one example of buffering. (Supra, pp. 18–19.)

It would have been obvious to a person of ordinary skill in the art at the time

of invention of the ’298 patent to combine Attanasio with the teaching of Comer.

(Ex. 1009, ¶¶ 115–17.) Both Attanasio and Comer are from the same field of

endeavor, communications using TCP/IP protocols. Compare Attanasio (Ex. 1023,

9:34–37) (“This configuration 340 shows organization of a MM header and MM

data area using Internet Protocol (IP), the MM protocol used by the preferred

embodiment”) with Comer (Ex. 1007, p. xv) (“Since the publication of

Internetworking With TCP/IP in 1988, many readers have asked for a second

volume that provides more information on how the TCP/IP protocols operate. This

text attempts to satisfy the need for additional information”); Ex. 1009, ¶ 115.)



the art at the alleged time of invention of the ’298 patent. Because Attanasio is a


communication protocols discussed in Comer. Indeed, Attanasio incorporates by

reference an earlier version of Comer in order to provide “[m]uch more detail”

about the subject of “networking communication protocols.” (Ex. 1023, 7:57–63.)

Therefore, the TCP/IP packet buffering and window advertisement schemes

described in Comer would have been present in the TCP/IP packets processed by


55

Attanasio’s port-address translator. (Ex. 1009, ¶ 115.)


benefits to buffering data packets in Attanasio’s port-address translator. Comer

itself describes advantages to the TCP/IP window advertisement protocol. First,

use of window advertisements allows communicating nodes to “control the flow of

data across a connection.” (Ex. 1007, p. 265.) This allows a receiving node to


p. 265.) A skilled artisan would understand that controlling the flow of inbound

data based on available buffer space is an important feature that avoids disruption

of communications. (Ex. 1009, ¶ 116.) If a receiving node’s buffer becomes full

additional received packets can be dropped due to lack of buffer space to store the

packets. (Ex. 1009, ¶116.) One of skill would further understand that packet loss

could easily be avoided by implementing standard TCP/IP window advertisement

protocols as described in Comer. (Ex. 1009, ¶ 116.)

Adding Comer’s buffering scheme to Attanasio’s port-address translator


1009, ¶ 117.) Attanasio is a software-based solution that already has the capability

to handle TCP/IP communication protocols. (Ex. 1009, ¶ 117.) Adding buffering

through window-based flow control would present no great technical challenges,

and would not negatively impact the function of Attanasio’s port-address


56

translator. (Ex. 1009, ¶ 117.)

2. Claim Charts

Claim 12. Attanasio (Ex. 1023) in view of Comer (Ex. 1007) [12A] A method as claimed in claim 11,

See Section VI. J., claim 11.

[12B] comprising buffering, at the filter node, further data packets received from the private network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 112–14.)

Claim 25. Attanasio (Ex. 1023) in view of Comer (Ex. 1007)

[25A] A method as claimed in

See Section VI. J., claim 24.


57

Claim 25. Attanasio (Ex. 1023) in view of Comer (Ex. 1007) claim 24, [25B] comprising buffering further data packets received from the first network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered.

“When TCP on the receiving machine sends an acknowledgement, it includes a window advertisement in the segment to tell the sender how much buffer space the receiver has available for additional data…. TCP uses window advertisements to control the flow of data across a connection. A receiver advertises small window sizes to limit the data a sender can generate. In the extreme case, advertising a window size of zero halts transmission altogether.” (Ex. 1007, p. 265.) “Once a receiver advertises a zero window. the sender enters the PERSIST output state and begins to probe the receiver. The receiver responds to each probe by sending an acknowledgement. As long as the window remains closed, the probes continue, and the acknowledgements contain a window advertisement of zero. Eventually, when sufficient space becomes available, the acknowledgements will carry a nonzero window, and the sender will start to transmit new data.” (Ex. 1007, p. 267.) “[W]henever an application program extracts data from a TCP input buffer, it checks to see if the additional space causes the window to open, and sends a gratuitous acknowledgement if it does. As the sender processes the acknowledgement, it finds the nonzero window advertisement, moves back to the TRANSMIT state, and resumes transmission of data.” (Ex. 1007, p. 267.) See also Madisetti Expert Declaration (Ex. 1009, ¶¶ 112–14.)

I. Claims 13 and 26 are rendered obvious by Attanasio in view of

Comer and RFC 792





58


destination port number. (Ex. 1009, ¶ 120.) The ’298 patent teaches that

translation of ICMP packets is accomplished by storing the “sequence field of the

[ICMP] packet in pPort in the table.” (Ex. 1001, 7:14–16.) As explained in more

detail above, it would have been obvious to translate ICMP packets based on the

disclosures of RFC 792. (Supra, p. 24.) Accordingly, the Attanasio system as

modified by the teaching of RFC 792 could send and receive ICMP messages.

Attanasio, Comer, and RFC 792 are from the same field of endeavor,

Internet Protocol communications. Compare Attanasio (Ex. 1006, Title) (“This

configuration 340 shows organization of a MM header and MM data area using

Internet Protocol (IP), the MM protocol used by the preferred embodiment.”) with

Comer (Ex. 1007, p. xv) (“Since the publication of Internetworking With TCP/IP

in 1988, many readers have asked for a second volume that provides more


need for additional information”) and RFC 792 (Ex. 1008, p. 1) (“ICMP, uses the

basic support of IP as if it were a higher level protocol, however, ICMP is actually

an integral part of IP, and must be implemented by every IP module.”); (Ex. 1009,

¶ 121.) Thus, one of ordinary skill in the art would have been aware that the

teachings of RFC 792 were directly applicable to the TCP/IP communications

system of Attanasio and Comer.


59


modify Attanasio and Comer to handle translation of ICMP packets. RFC 792

teaches that processing of ICMP packets provides a number of benefits to a TCP/IP









communications at the alleged time of invention. (Ex. 1009, ¶ 122.) Were

Attanasio’s port-address translator system unable to process ICMP packets it

would be unable to fully and effectively communicate with other nodes in a

TCP/IP network. (Ex. 1009, ¶ 122.)

Adding translation of ICMP packets to Attanasio’s port-address translator


1009, ¶ 123.) Attanasio is a software-based solution that already has the capability

to handle TCP/IP communication protocols. (Ex. 1009, ¶ 123.) Translation of

ICMP packets would present no great technical challenges, and would not


60

negatively impact the function of Attanasio’s port-address translator. (Ex. 1009,

¶ 123.)

2. Claim Charts

Claim 13. Attanasio (Ex. 1023) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008)





Claim 26. Attanasio (Ex. 1023) in view of Comer (Ex. 1007) and

RFC 792 (Ex. 1008) [26A] A method as claimed in claim 25,




VII. CONCLUSION

For the foregoing reasons, Petitioner asks that inter partes review of the ’298

patent be instituted and that claims 11–13 and 24–26 be canceled.


61

Respectfully submitted, Google Inc., Petitioner

By: /Scott A. McKeown/ Scott A. McKeown Registration No. 42,866 OBLON, SPIVAK, McCLELLAND, MAIER &, NEUSTADT, L.L.P.

Customer Number

22850 Tel: (703) 413-3000 Fax: (703) 413 -2220 (OSMMN 07/09)


EXHIBIT APPENDIX

Exhibit Description 1001 U.S. Patent No. 6,128,298 (for inter partes review) 1002 Prosecution history of U.S. Patent No. 6,128,298 1003 Il Hwan Kim, “IP Address Reuse Through Transparent Port-Address

Translator,” The Journal of Korea Information and Communications Society vol. 20 No. 12 (Dec. 1995)

1004 Certified translation of Exhibit 1003 1005 INTENTIONALLY BLANK 1006 Heon Yeom et al., “A transparent TCP/IP Gateway to Connect

Private Networks to the Internet,” Education and Research Center, Seoul National University (Jan. 30, 1995)

1007 Douglas E. Comer et al., “Internetworking with TCP/IP: Design, Implementation, and Internals,” Volume II (1991)

1008 J. Postel, “Internet Control Message Protocol,” Request for Comments (RFC): 792 (September 1981)

1009 Declaration of Professor Vijay K. Madisetti, PhD 1010 INTENTIONALLY BLANK 1011 INTENTIONALLY BLANK 1012 D. Brent Chapman & Elizabeth D. Zwicky, “Building Internet

Firewalls,” Chapter 4 (September 1995) 1013 D. Clark, “The Design Philosophy of the DARPA Internet

Protocols,” Proc. SIGCOMM ‘88, Computer Communication Review Vol. 18, No. 4, pp. 106–14 (August 1988)

1014 S. Cooper, “Firewall Products Today,” Lawrence Livermore National Laboratory Preprint UCRL-JC-119743 (February 1995)

1015 IETF, “Address Lifetime Expectations (ale) Charter,” (November 1993)

1016 INTENTIONALLY BLANK 1017 Gary Kessler, “Firewall Routers and Packet Filtering” (February

1995) 1018 INTENTIONALLY BLANK 1019 D. Clark, “Window and Acknowledgement Strategy in TCP,”

Request for Comments (RFC): 813 (July 1982) 1020 K. Egevang, P. Francis, “The IP Network Address Translator

(NAT),” Request for Comments (RFC): 1631 (May 1994)


Exhibit Description 1021 Paul Tsuchiya, Tony Eng, “Extending the IP Internet Through

Address Reuse,” ACM SIGCOMM Computer Communications Review, 23(1):16–33 (January 1993)

1022 INTENTIONALLY BLANK 1023 U.S. Patent No. 5,371,852 to Attanasio et al. 1024 INTENTIONALLY BLANK 1025 Letter from Patent Owner in Google Inc. v. Rockstar Consortium US

LP et al., Case No. 4:13-cv-05933-CW (N.D. Cal.) (July 24, 2014) 1026 Patent Owner’s proposed claim constructions in Google Inc. v.

Rockstar Consortium US LP, et al., Case No. 13-5933 (N.D. Cal.) 1027 Patent Owner’s Infringement Contentions for U.S. Patent No

6,128,298, Google Inc. v. Rockstar Consortium US LP et al., Case No. 4:13-cv-05933-CW (N.D. Cal.)

1028 Declaration of Bob Kummerfeld, Ph.D.


CERTIFICATE OF SERVICE

I hereby certify that, on November 4, 2014, I caused a true and correct copy

of the foregoing Petition for Inter Partes Review of U.S. Patent No. 6,128,298 and

supporting materials to be served via Express Mail at the correspondence address

of record for the ’298 patent:

Foley & Lardner Washington Harbour 3000 K Street NW Suite 500 P.O. Box 25696 Washington D.C. 20007-8696

/Scott A. McKeown/ Scott A. McKeown Registration No. 42,866

Documents

NO: 426476US IN THE UNITED STATES PATENT AND … · PO Box 1450 Alexandria, Virginia 22313-1450 . U.S. Patent 6,128,298 Petition for Inter Partes Review i TABLE OF CONTENTS Page