IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. GOOGLE INC., Petitioner,

Transcription

1 NO: US 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 Mail Stop PATENT BOARD Patent Trial and Appeal Board US Patent and Trademark Office PO Box 1450 Alexandria, Virginia

2 TABLE OF CONTENTS Page I. MANDATORY NOTICES PURSUANT TO 37 C.F.R 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 AND ARE UNPATENTABLE A. Claims 11 and 24 are anticipated by Kim B. Claims 12 and 25 are rendered obvious by Kim in view of Comer C. Claims 13 and 26 are rendered obvious by Kim in view of Comer and RFC D. Claims 11 and 24 are anticipated by Yeom E. Claims 12 and 25 are rendered obvious by Yeom in view of Comer F. Claims 13 and 26 are rendered obvious by Yeom in view of Comer and RFC G. Claims 11 and 24 are anticipated by Attanasio i

3 H. Claims 12 and 25 are rendered obvious by Attanasio in view of Comer I. Claims 13 and 26 are rendered obvious by Attanasio in view of Comer and RFC VII. CONCLUSION ii

4 Cases TABLE OF AUTHORITIES Page 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) U.S.C. 102(b)... 3, 4 35 U.S.C. 314(a) U.S.C. 315(a)... 1 Rules 37 C.F.R C.F.R C.F.R C.F.R , 10 iii

5 I. MANDATORY NOTICES PURSUANT TO 37 C.F.R 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 (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 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 of the 298 patent. Petitioner recommends assigning all proceedings to the same panel. Counsel: Lead Counsel: Scott A. McKeown (Reg. No. 42,866) 1

6 Backup Counsel: Greg Gardella (Reg. No. 46,045) Service Information : CPDocketMcKeown@oblon.com CPDocketGardella@oblon.com Post: Oblon Spivak, 1940 Duke St., Alexandria, VA Telephone: Facsimile: II. CERTIFICATION OF GROUNDS FOR STANDING Petitioner certifies pursuant to Rule (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 (b)(1) (2), Petitioner challenges claims and 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, (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 2

7 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 3

8 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 and 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; 4

9 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 5

10 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, The 328 application claims priority to Provisional U.S. Application No. 60/015,945, which was filed on April 24, In a non-final office action mailed on April 27, 1999, the examiner rejected claims 1-5, 9, 11, 14 18, 22, 24, and of the 328 application over U.S. Patent No. 5,781,550 ( Templin ). (Ex. 1002, pp ) In a response dated July 27, 1999, the applicants submitted a declaration 6

11 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 ) In a non-final office action dated October 12, 1999, the examiner rejected claims 1 5, 9, 11 18, and of the 328 application as being obvious in view of U.S. Patent No. 5,793,763 ( Mayes ). (Ex. 1002, pp ) 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 ) 3, The examiner allowed the application and the 298 patent issued on October 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 (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 7

12 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 (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 (N.D. Cal.). (Ex ) 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 8

13 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 (Patent Owner s infringement contentions in Google Inc. v. Rockstar Consortium US LP et al., Case 9

14 No. 4:13-cv 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 AND ARE UNPATENTABLE Pursuant to Rule (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: [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 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.) 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 : 10

15 Claim 11. Kim (Ex. 1004) address corresponding to a node in the private network; (Ex. 1004, p. 44.) [11C] (b) maintaining, by the filter node, the source address taken from the data packet; [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.) 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 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 11

16 Claim 11. Kim (Ex. 1004) inner network nodes: [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; (Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, 59.) 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 (Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, 60.) 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 12

17 Claim 11. Kim (Ex. 1004) address, according to the destination address, to the corresponding public node network; [11F] (e) waiting for a return packet from the public network, responsive to the data packet having the replaced source information; 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.) 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.) [11G] (f) replacing, in the return packet, the destination address with the maintained source address; and See also Madisetti Expert Declaration (Ex. 1009, 61, 63.) 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 being corresponded with the port number of G (Gateway node) with a global address. (Ex. 1004, p. 40.) (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.) 13

18 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. (Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, 61.) 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: [24B] (a) receiving from the first network, a data packet having a 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.) 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, 14

19 Claim 24. Kim (Ex. 1004) dstport). (Ex. 1004, p. 39.) destination address corresponding to a node in the second network and a source address corresponding to a node in the first network; A packet is received with a source address of the inner network and a destination address in the outer network : (Ex. 1004, p. 44.) [24C] (b) maintaining the source address taken from the data packet; See also Madisetti Expert Declaration (Ex. 1009, 60.) 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 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 inner network nodes: 15

20 Claim 24. Kim (Ex. 1004) [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; (Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, 59.) 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; (Ex. 1004, p. 44.) See also Madisetti Expert Declaration (Ex. 1009, 60.) 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.) 16

21 Claim 24. Kim (Ex. 1004) [24F] (e) receiving a return packet from the second network, responsive to the data packet having the replaced source information; [24G] (f) replacing, in the return packet, the destination address with the maintained source address; and See also Madisetti Expert Declaration (Ex. 1009, 60.) 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.) 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 being corresponded with the port number of G (Gateway node) with a global address. (Ex. 1004, p. 40.) (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: 17

22 Claim 24. Kim (Ex. 1004) (Ex. 1004, p. 44.) [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. See also Madisetti Expert Declaration (Ex. 1009, 61.) 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 18

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

24 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, 20

25 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 windowbased 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 See Section VI. A., claim 11. as claimed in claim 11, [12B] comprising When TCP on the receiving machine sends an buffering, at the acknowledgement, it includes a window advertisement in the 21

26 Claim 12. Kim (Ex. 1004) in view of Comer (Ex. 1007) 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.) 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. 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, ) Claim 25. Kim (Ex. 1004) in view of Comer (Ex. 1007) [25A] A method See Section VI. A., claim 24. as claimed in claim 24, [25B] comprising When TCP on the receiving machine sends an buffering further acknowledgement, it includes a window advertisement in the data packets segment to tell the sender how much buffer space the receiver received from the has available for additional data. TCP uses window first network while advertisements to control the flow of data across a connection. waiting for the A receiver advertises small window sizes to limit the data a return packet, and sender can generate. In the extreme case, advertising a 22

27 Claim 25. Kim (Ex. 1004) in view of Comer (Ex. 1007) window size of zero halts transmission altogether. (Ex. 1007, p. 265.) repeating steps (b) through (g) on an individual basis for the further packets, if any, that were buffered. 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, ) C. Claims 13 and 26 are rendered obvious by Kim in view of Comer and RFC Obviousness Arguments 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.) 23

28 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 portaddress 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 24

29 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 25

30 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) [13A] A method See Section VI. C., claim 12. as claimed in claim 12, [13B] wherein The identifier and sequence number may be used by the echo the data packets sender to aid in matching the replies with the echo requests. For include packets example, the identifier might be used like a port in TCP or UDP in accordance to identify a session, and the sequence number might be with an internet incremented on each echo request sent. The echoer returns these control message same values in the echo reply. (Ex. 1008, pp. 15, 17, 19.) protocol (ICMP). 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 See Section VI. C., claim 25. as claimed in claim 25, [26B] wherein The identifier and sequence number may be used by the echo the data packets sender to aid in matching the replies with the echo requests. For include packets example, the identifier might be used like a port in TCP or UDP 26

31 Claim 26. Kim (Ex. 1004) in view of Comer (Ex. 1007) and RFC 792 (Ex. 1008) in accordance to identify a session, and the sequence number might be with an internet incremented on each echo request sent. The echoer returns these control message same values in the echo reply. (Ex. 1008, pp. 15, 17, 19.) protocol (ICMP). 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, (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. 27

32 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: [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. 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.) 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 : [11C] (b) maintaining, by the filter node, the source address (Ex. 1006, p. 2.) See also Madisetti Expert Declaration (Ex. 1009, ) 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 28

33 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: (Ex. 1006, p. 3.) [11D] (c) replacing, in the data packet, the source address 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 29

34 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: (Ex. 1006, p. 3.) [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; See also Madisetti Expert Declaration (Ex. 1009, 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 packet is sent from the gateway to its destination in the outer network: (Ex. 1006, p. 3.) 30

35 Claim 11. Yeom (Ex. 1006) See also Madisetti Expert Declaration (Ex. 1009, 82.) [11F] (e) waiting From that point on, all the packets with originator (I1,p1) for a return packet and destination (O2,p2) would be transformed into a packet from the public with originator (G,p3) and sent to the outside network. network, Likewise, all the packets from the outside network with responsive to the originator (O2,p2) and destination (G,p3) would be data packet having transformed with destination (I1,p1) and feed into the inner the replaced source network. (Ex. 1006, p. 2.) information; [11G] (f) replacing, in the return packet, the destination address with the maintained source address; and 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 (Ex. 1006, p. 3.) 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.) A packet is routed from the gateway to its destination in the inner network: 31

36 Claim 11. Yeom (Ex. 1006) corresponding private network node. (Ex. 1006, p. 3.) See also Madisetti Expert Declaration (Ex. 1009, 84.) 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.) [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; See also Madisetti Expert Declaration (Ex. 1009, 80.) 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 : 32

37 Claim 24. Yeom (Ex. 1006) (Ex. 1006, p. 2.) [24C] (b) maintaining the source address taken from the data packet; See also Madisetti Expert Declaration (Ex. 1009, ) 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.) 33

38 Claim 24. Yeom (Ex. 1006) [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; 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: (Ex. 1006, p. 3.) [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; [24F] (e) receiving a return packet See also Madisetti Expert Declaration (Ex. 1009, 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.) See also Madisetti Expert Declaration (Ex. 1009, 82.) From that point on, all the packets with originator (I1,p1) and destination (O2,p2) would be transformed into a packet 34