`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`PATENT TRIAL & APPEAL BOARD
`
`
`Bruce A. Wootton et al.
`In re Patent of:
`U.S. Patent No.: 6,128,298
`Issue Date:
`October 3, 2000
`Appl. No.:
`
`08/842,328
`Filing Date:
`April 24, 1997
`Title:
`Internet Protocol Filter
`
`
`DECLARATION OF PROFESSOR VIJAY K. MADISETTI, Ph.D.
`
`I am Professor Vijay K. Madisetti. I support this report on behalf of
`
`(1.)
`
`Google in connection with its request for inter partes review of U.S. Patent No.
`
`6,128,298 (“the ’298 patent”).
`
`I.
`
`INTRODUCTION
`
`A. Qualifications
`
`(2.) My name is Vijay K. Madisetti. I am currently a tenured full
`
`Professor of Electrical and Computer Engineering at the Georgia Institute of
`
`Technology (“Georgia Tech”) in Atlanta, GA, and I have been on the faculty of
`
`Georgia Tech since 1989.
`
`(3.)
`
`I received a Bachelor of Technology in Electronics and Electrical
`
`Communications Engineering from the Indian Institute of Technology (IIT) in
`
`1984. I received my Ph.D. in Electrical Engineering and Computer Sciences
`
`(EECS) from the University of California, Berkeley in 1989.
`
`
`
`
`
`1
`
`Google Ex. 1509, pg. 1
`
`
`
`
`
`(4.)
`
`I have authored or co-authored over 100 reference articles in the area
`
`of electrical engineering in the areas of communications, signal processing,
`
`communications, and computer engineering. I also teach courses at the
`
`undergraduate and graduate levels in these areas at Georgia Tech.
`
`(5.)
`
`I have authored, co-authored, or edited several books in the past
`
`twenty years, including: VLSI Digital Signal Processors, Madisetti, V.K.; Quick-
`
`Turnaround ASIC Design in VHDL, Romdhane, M., Madisetti, V.K., Hines, J; The
`
`Digital Signal Processing Handbook (First Edition), Madisetti, V. K., Williams, D.
`
`(Editors); VHDL: Electronics Systems Design Methodologies, Madisetti, V. K.
`
`(Editor); Platform-Centric Approach to System-on-Chip (SoC) Design, Madisetti,
`
`V. K., Arpnikanondt, A; The Digital Signal Processing Handbook – Second
`
`Edition, Madisetti, V. K. (2009/2010); Cloud Computing: A Hands-On Approach,
`
`A. Bahga, V. Madisetti (2013); Internet of Things: A Hands-On Approach, A.
`
`Bahga, V. Madisetti (2014).
`
`(6.)
`
`In the past decade I have authored several peer-reviewed papers in the
`
`area of computer and telecom systems design, and these include: V. Madisetti, et
`
`al: “The Georgia tech Digital Signal Multiprocessor, IEEE Transactions on Signal
`
`Processing, Vol 41, No. 7, July 1993; V. Madisetti et al, “Rapid Prototyping on the
`
`Georgia Tech Digital Signal Multiprocessor”, IEEE Transactions on Signal
`
`Processing, Vol 42, March 1994; V. Madisetti, “Reengineering legacy embedded
`
`
`
`
`
`2
`
`Google Ex. 1509, pg. 2
`
`
`
`
`
`systems”, IEEE Design & Test of Computers, Vol 16, Vol 2, 1999; V. Madisetti et
`
`al, “Virtual Prototyping of Embedded Microcontroller-based DSP Systems”, IEEE
`
`Micro, Vol 15, Issue 5, 1995; V. Madisetti, et al, “Incorporating Cost Modeling in
`
`Embedded-System Design”, IEEE Design & Test of Computers, Vol 14, Issue 3,
`
`1997; V. Madisetti, et al, “Conceptual Prototyping of Scalable Embedded DSP
`
`Systems”, IEEE Design & Test of Computers, Vol 13, Issue 3, 1996; V. Madisetti,
`
`Electronic System, Platform & Package Codesign,” IEEE Design & Test of
`
`Computers, Vol 23, Issue 3, June 2006; V. Madisetti, et al, “A Dynamic Resource
`
`Management and Scheduling Environment for Embedded Multimedia and
`
`Communications Platforms,” IEEE Embedded Systems Letters, Vol 3, Issue 1,
`
`2011.
`
`(7.)
`
`I have also been active in research in the area of wireless and mobile
`
`communications, and computer engineering, including digital content (video/voice)
`
`delivery, and some of my representative peer-reviewed publications in this area
`
`include: (i) J. Kim and Vijay Madisetti, Adaptive Mobility Management in
`
`Wireless Networks, in Electronics Letters, July 1998, pp. 1453-1455; (ii) Mustafa
`
`Turkboylari & Vijay K. Madisetti, Effect of Handoff Delay on the System
`
`Performance of TDMA Cellular Systems, Proceedings of the Fourth IEEE
`
`Conference on Mobile and Wireless Communications Network 411-15 (Sept. 9-11,
`
`2002); (iii) Loran A. Jatunov & Vijay K. Madisetti, Computationally-Efficient
`
`
`
`
`
`3
`
`Google Ex. 1509, pg. 3
`
`
`
`
`
`SNR Estimation for Bandlimited Wideband CDMA Systems, 5 IEEE Transactions
`
`on Wireless Communications, no. 12 (2006) at 3480-91; and (iv) Nimish Radia,
`
`Ying Zhang, Mallik Tatipamula & Vijay K. Madisetti, Next Generation
`
`Applications on Cellular Networks: Trends, Challenges, and Solutions, 100
`
`Proceedings of the IEEE, no. 4 (April 2012) at 841-54.
`
`(8.)
`
`I served as a consultant for wireless technologies for Johns Hopkins’
`
`Applied Physics Laboratory between 2004 and 2005.
`
`(9.)
`
`I designed floating point chipsets, based on the MIL-STD-1750A
`
`family of microprocessors for secure weapons guidance, navigational, and GPS
`
`applications, used in several Department of Defense programs in the mid-1990s.
`
`(10.) I designed software applications for several commercial cellular and
`
`VOIP mobile phones in the early-2000 time frame for companies such as Ericsson
`
`and Cisco, which rank amongst the world’s leading wireless and networking
`
`infrastructure manufacturers. I am also familiar with various data messaging
`
`networks, such as Internet Protocol, SS7, USSD, GPRS, synchronous and
`
`asynchronous data, and UMTS.
`
`(11.) I have developed software for encryption for certain commercially
`
`available mobile phones in the early 2000 timeframe, specifically for the GSM A5
`
`encryption standards, in collaboration with a leading international mobile phone
`
`and base station manufacturer.
`
`
`
`
`
`4
`
`Google Ex. 1509, pg. 4
`
`
`
`
`
`(12.) In conjunction with BPL Telecom (India), through a joint venture
`
`called Soft Networks (SN), LLC in Atlanta, in the late 1990s and early 2000s, I
`
`collaborated with BPL Telecom’s engineers to support BPL Telecom’s mobile,
`
`VOIP/Soft Switch and wireless services offerings in India, through design and
`
`development of micropayment services for mobile phones, design of smartphones,
`
`and telecom customer billing and fraud detection algorithms, which included
`
`establishment of secure sessions and privileged access to customer account and
`
`billing data.
`
`(13.) In the past few years, I have provided services to content providers in
`
`the defense market in the area of security certification and accreditation of federal
`
`information systems, evaluating and designing security certification programs for
`
`defense contractors.
`
`(14.) I was awarded the 2006 Frederick Emmons Terman Medal for my
`
`contributions to electrical engineering by the American Society of Engineering
`
`Education, and I also received Georgia Tech’s Outstanding Doctoral Advisor
`
`Award in 2001.
`
`(15.) I also have significant experience in designing and implementing
`
`chips and software systems using various source code languages, including C,
`
`assembly, and VHDL. In 2000, I published a book entitled Vijay K. Madisetti,
`
`VHDL: Electronics Systems Design Methodologies and Interactive Tutorial
`
`
`
`
`
`5
`
`Google Ex. 1509, pg. 5
`
`
`
`
`
`(2000), and I was also awarded the VHDL International Best Ph.D. Dissertation
`
`Advisor Award in 1997.
`
`(16.) I am a Fellow of the Institute of Electrical and Electronics
`
`Engineering (“IEEE”), which signifies the highest professional standing in my
`
`research and educational community.
`
`(17.) In sum, I have over 25 years of experience in research and
`
`development in the areas of computer engineering and electrical engineering as a
`
`professor, researcher, entrepreneur, and consultant. I consider myself to be at least
`
`a person of ordinary skill in the art.
`
`(18.) I make this declaration based on personal knowledge and I am
`
`competent to testify about the matters set forth herein.
`
`(19.) A copy of my latest curriculum vitae (CV) is attached to this
`
`declaration as Appendix A.
`
`B. Basis of My Opinion and Materials Considered
`
`(20.) I have reviewed the ’298 patent and its file history. I have reviewed
`
`the prior art and other documents and materials cited herein. My opinions are also
`
`based in part upon my education, training, research, knowledge, and experience.
`
`For ease of reference, the full list of information that I have considered is included
`
`in Appendix B.
`
`
`
`
`
`6
`
`Google Ex. 1509, pg. 6
`
`
`
`
`
`C. Understanding of Legal Standards
`
`1. Anticipation
`
`(21.) A patent claim is “anticipated” if each and every limitation of the
`
`claim is disclosed in a single prior art reference. Section 102 of the Patent Statute
`
`was amended on March 16, 2013. The earlier version of Section 102 applies to the
`
`patent at issue given its filing date.
`
`(22.) Each element of a patent claim may be disclosed by a prior art
`
`reference either expressly or inherently. Further, my understanding is that even an
`
`“express” disclosure does not necessarily need to use the same words as the claim.
`
`An element of a patent claim is inherent in a prior art reference if the element must
`
`necessarily be present and such would be recognized by a person of ordinary skill
`
`in the art. However, I understand that inherency cannot be established by mere
`
`probabilities or possibilities.
`
`2. Obviousness
`
`(23.) A patent claim is invalid if the differences between the patented
`
`subject matter and the prior art are such that the subject matter as a whole would
`
`have been obvious at the time the invention was made to a person of ordinary skill
`
`in the art. I am informed that this standard is set forth in 35 U.S.C. § 103(a).
`
`(24.) I understand that a patent claim is unpatentable as obvious if the
`
`subject matter of the claim as a whole would have been obvious to a person of
`
`
`
`
`
`7
`
`Google Ex. 1509, pg. 7
`
`
`
`
`
`ordinary skill in the art as of the time of the invention at issue. I understand that
`
`the following factors must be evaluated to determine whether the claimed subject
`
`matter is obvious: (1) the scope and content of the prior art; (2) the difference or
`
`differences, if any, between the scope of the claim of the patent under
`
`consideration and the scope of the prior art; and (3) the level of ordinary skill in the
`
`art at the time the patent was filed.
`
`(25.) I understand that prior art references can be combined to reject a claim
`
`under 35 U.S.C. § 103 when there was an apparent reason for one of ordinary skill
`
`in the art, at the time of the invention, to combine the references, which includes,
`
`but is not limited to (A) identifying a teaching, suggestion, or motivation to
`
`combine prior art references; (B) combining prior art methods according to known
`
`methods to yield predictable results; (C) substituting one known element for
`
`another to obtain predictable results; (D) using a known technique to improve a
`
`similar device in the same way; (E) applying a known technique to a known device
`
`ready for improvement to yield predictable results; (F) trying a finite number of
`
`identified, predictable potential solutions, with a reasonable expectation of success;
`
`or (G) identifying that known work in one field of endeavor may prompt variations
`
`of it for use in either the same field or a different one based on design incentives or
`
`other market forces if the variations are predictable to one of ordinary skill in the
`
`art.
`
`
`
`
`
`8
`
`Google Ex. 1509, pg. 8
`
`
`
`
`
`(26.) Moreover, I have been informed and I understand that so-called
`
`objective indicia of non-obviousness, also known as “secondary considerations,”
`
`like the following are also to be considered when assessing obviousness: (1)
`
`commercial success; (2) long-felt but unresolved needs; (3) copying of the
`
`invention by others in the field; (4) initial expressions of disbelief by experts in the
`
`field; (5) failure of others to solve the problem that the inventor solved; and (6)
`
`unexpected results. I also understand that evidence of objective indicia of non-
`
`obviousness must be commensurate in scope with the claimed subject matter. I am
`
`not aware of any objective indicia of non-obviousness for the ’298 patent.
`
`II. Description of the Relevant Field and the Relevant Timeframe
`
`(27.) I have carefully reviewed the ’298 patent and its file history.
`
`(28.) Based on my review of this material, I believe that the relevant field
`
`for the purposes of the ’298 patent is computer networking and communications. I
`
`have been informed that the relevant timeframe is on or before April 24, 1996.
`
`(29.) As described in Section I above and as shown in my CV, I have
`
`extensive experience in the relevant field. Based on my experience, I have a good
`
`understanding of the relevant field in the relevant timeframe.
`
`III. The Person of Ordinary Skill in the Relevant Field in the Relevant
`Timeframe
`
`(30.) I have been informed that “a person of ordinary skill in the relevant
`
`field” is a hypothetical person to whom an expert in the relevant field could assign
`
`
`
`
`
`9
`
`Google Ex. 1509, pg. 9
`
`
`
`
`
`a routine task with reasonable confidence that the task would be successfully
`
`carried out. I have been informed that the level of skill in the art is evidenced by
`
`prior art references. The prior art discussed herein demonstrates that a person of
`
`ordinary skill in the field, at the time the ’298 patent was effectively filed, would
`
`have been aware of and have experience with computer networking, packet
`
`communications, Internet protocol, transport protocols, gateway devices, and
`
`address translation.
`
`(31.) Based on my experience, I have an understanding of the capabilities
`
`of a person of ordinary skill in the relevant field. I have supervised and directed
`
`many such persons over the course of my career. Further, I had those capabilities
`
`myself at the time the patent was effectively filed.
`
`IV. Engineering Principles Underlying the ’298 Patent
`
`A.
`
`Introduction
`
`(32.) In the early 1990’s, the computer network that was to become today’s
`
`Internet experienced a historic shift from a limited-access, research-related
`
`network with significant US government oversight to an open, widely accessible
`
`public network carrying commercial traffic. At the same time, the number of
`
`computers connected to the Internet grew nearly one-hundred-fold from
`
`approximately 100,000 attached computers in 1990 to nearly 10,000,000 attached
`
`computers in 1996.
`
`
`
`
`
`10
`
`Google Ex. 1509, pg. 10
`
`
`
`
`
`(33.) Both of these trends had an impact on the technology involved in the
`
`’298 patent. First, with a vastly increased number of Internet users, network
`
`administrators became increasingly concerned about network security, and began
`
`using “firewalls” to limit the sites and services that their own internal network
`
`users could access in the larger Internet, as well as the sites and services that
`
`external users could access in the administered network. Second, with an
`
`increasing number of Internet hosts, the number of available Internet network
`
`addresses became scarcer, prompting the need to more carefully allocate and use
`
`network addresses.
`
`B. The Internet: packets, Internet addresses, the Internet Protocol
`(IP)
`
`(34.) Internet “hosts” are computers attached to the Internet that
`
`communicate with each other by sending small “packets” of information to each
`
`other. Each host has a 32-bit Internet address (often referred to as an “IP
`
`address”), typically written in the form a.b.c.d, where each letter is a number
`
`between 0 and 255. Each packet traversing the Internet carries the IP address of
`
`the host that first sent the packet into the network and the IP address of the host to
`
`which the packet is ultimately destined. A network of routers forwards a packet
`
`from a source (sending) host to a destination (receiving) host, using the destination
`
`host’s IP address to determine the packet’s path through the network of routers.
`
`
`
`
`
`11
`
`Google Ex. 1509, pg. 11
`
`
`
`
`
`The standard that defines the format of packets and their source and destination
`
`addresses is known as the Internet Protocol (IP).
`
`(35.) The Internet consists of a very large number of hosts and routers, as
`
`well as the communication links connecting hosts and routers. Although the
`
`Internet is perceived as one (very!) large network, it is more accurately
`
`characterized as a “network of networks.’’ Each individual network, itself
`
`consisting of interconnected hosts and routers, is owned and administered by an
`
`organization, e.g., a company, a university, or an Internet Service Provider (ISP)
`
`such as AT&T or Comcast. Although each individual network connected into the
`
`Internet must use standardized Internet protocols (such as IP), each organization
`
`has considerable freedom in how it manages its own network, including the
`
`assignment of addresses to hosts in its network, and the policies used to determine
`
`which packets can enter and leave its network. The router at which a packet leaves
`
`an organization’s network and enters into another organization’s network is
`
`referred to as a “gateway” router. When a gateway router enforces a policy that
`
`determines which packets can enter or leave its network, that gateway router is
`
`often referred to as a “firewall” router, as discussed below.
`
`C.
`
`Internet Hosts: TCP, UDP, port numbers
`
`(36.) Since the IP protocol standardizes the format of packets exchanged
`
`between Internet-connected devices, the IP protocol must be implemented at each
`
`
`
`
`
`12
`
`Google Ex. 1509, pg. 12
`
`
`
`
`
`and every host and router in the Internet. Two other protocol standards that are
`
`widely used in the Internet are TCP (the Transmission Control Protocol) and UDP
`
`(the User Datagram Protocol). TCP and UDP are used primarily by hosts at the
`
`“edge” of the Internet. The TCP and UDP protocols define the format of the
`
`“payload’’ of an IP packet, as well as actions taken when an IP packet containing a
`
`TCP or UDP payload is received or sent at a host. The TCP or UDP payload in an
`
`IP packet are often referred to a “segment.”
`
`(37.) A TCP or UDP segment includes the actual application-specific data
`
`being sent from one host application (e.g., web page content, an email message, or
`
`a video file) to another host application, as well as additional information
`
`contained in “fields” in the TCP or UDP segment header. One such field indicates
`
`the amount of data being sent. Two other fields indicate the sending and receiving
`
`“port numbers” associated with that data. These ports typically serve to identify
`
`the applications on the sending and receiving hosts that send and receive,
`
`respectively, the TCP or UDP segment within an IP packet.
`
`(38.) A TCP segment also contains several fields not found in a UDP
`
`segment. Because TCP provides reliable delivery between sender and receiver,
`
`TCP segments contain a “sequence number” and an “acknowledgment” field used
`
`to implement a reliable delivery service. A TCP segment also contains a receiver-
`
`advertised “window” that tells the sender-side TCP how many bytes of data the
`
`
`
`
`
`13
`
`Google Ex. 1509, pg. 13
`
`
`
`
`
`receiver-side TCP is able to receive. TCP’s “flow-control” mechanism regulates
`
`how the sender sends TCP segments to the receiver, based on the value of the
`
`receiver-advertised window. Clark describes TCP’s flow-control mechanism as
`
`follows:
`
`The window mechanism is a flow control tool. … This number of
`bytes, called the window, is the maximum which the sender is
`permitted to transmit until the receiver returns some additional
`window. Sometimes, the receiver will have no buffer space available,
`and will return a window value of zero. Under these circumstances,
`the protocol requires the sender to send a small segment to the
`receiver now and then, to see if more data is accepted.
`(Ex. 1519, p. 2.) Comer described TCP’s flow control mechanism:
`
`
`When TCP on the receiving side 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.
`… 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 become available, the
`acknowledgements will carry a nonzero window, and the sender will
`start to transmit new data.
`(Ex. 1507, pp. 265–67.)
`
`
`
`
`
`
`14
`
`Google Ex. 1509, pg. 14
`
`
`
`
`
`D. Firewalls, application-layer gateways
`
`(39.) The ’298 patent deals with the manipulation of an incoming or
`
`outgoing packet’s IP addresses and port numbers, and the sending, buffering, and
`
`receiving of packets, at an “IP filter device.”
`
`(40.) Chapman defines a firewall as, “A component or set of components
`
`that restricts access between a protected network and the Internet, or between other
`
`sets of networks.” (Ex. 1512, pp. 1–2.) Figure 1 (adapted from Cooper (Ex. 1514,
`
`p. 4), where I have added the labels A, B, and C, and the computer icons above
`
`labels A and C), illustrates a firewall sitting between a trusted network (typically
`
`also administered by the firewall owner/operator) and an untrusted network
`
`(typically the larger Internet).
`
`(41.) Several different types of firewalls existed in 1995. The simplest was
`
`the packet-filtering firewall – a network component (e.g., a gateway router) that
`
`performed simple packet filtering - deciding which packets could pass through the
`
`
`
`
`
`
`
`15
`
`Google Ex. 1509, pg. 15
`
`
`
`
`
`firewall from the protected network to the Internet (and vice versa) and which
`
`would be blocked at the firewall.
`
`(42.) A second type of firewall was the application-level gateway, also
`
`known as a proxy server. An application-level gateway provides more complex
`
`services than simple packet filtering.
`
`Proxy services are specialized application or server programs that run
`on a firewall … These programs take users' requests for Internet
`services (such as FTP and Telnet) and forward them, as appropriate
`according to the site's security policy, to the actual services. The
`proxies provide replacement connections and act as gateways to the
`services. For this reason, proxies are sometimes known as application-
`level gateways.
`(Ex. 1512, p. 5.)
`
`
`(43.) Key to this definition is the phrase “replacement connections.” This
`
`means that there are two separate TCP connections – a first connection between
`
`the internal host and the application-level gateway firewall, and a second
`
`connection between the gateway and the external host. In Figure 1, for example,
`
`there is a first TCP connection between host A and firewall B, and a second TCP
`
`connection between firewall B and external host C. IP packets (with source IP
`
`address A and destination IP address B) containing TCP segments (with TCP
`
`source port number a, and TCP destination port number b) are sent from A to B.
`
`The application gateway then extracts the application-level information from the
`
`
`
`
`
`16
`
`Google Ex. 1509, pg. 16
`
`
`
`
`
`TCP segment, puts this information into a new TCP segment (with TCP source
`
`port number x, and TCP destination port number y, where x may not equal a and y
`
`may not equal b), puts this new TCP segment into a new IP packet (with source IP
`
`address B and destination IP address C) and then sends this new IP packet to host
`
`C.
`
`(44.) Kessler notes: “Circuit gateways act as a TCP relay; an external
`
`remote host connects to a TCP port at the gateway and the gateway, in turn,
`
`establishes a TCP connection to the intended destination on the internal local
`
`network.” (Ex. 1517, pp. 1–2.)
`
`(45.) Thus, an application-level gateway relays TCP connections by
`
`allowing a user to connect to a TCP port on the gateway, which then connects to
`
`some destination on the other side of the gateway.
`
`(46.) Note that with two separate, independent connections between distinct
`
`pairs of Internet devices, IP packets on the two different connections will have
`
`different source and destination addresses as noted in the example above. Thus,
`
`the gateway serves to transform the IP addresses of an incoming packet (and
`
`possibly the port numbers and other TCP information) to different addresses in the
`
`corresponding output packet, as the incoming packet passes from the gateway’s
`
`input to the gateway’s output.
`
`
`
`
`
`17
`
`Google Ex. 1509, pg. 17
`
`
`
`
`
`(47.) Since there are two connections, these connections may have different
`
`TCP receiver-advertised window values. Consequently, the gateway may receive
`
`TCP segments on the A-to-B connection but not be able to send those segments
`
`onto the B-to-C connection. In this case, gateway B buffers segments until a
`
`received packet from C indicates that the receiver-advertised window allows B to
`
`send one or more buffered TCP segments.
`
`E. NAT
`
`(48.) Recall that as discussed above, each Internet-connected host must
`
`have a 32-bit IP address. With a rapidly increasing number of Internet hosts in the
`
`early 1990’s, the Internet Engineering Task Force – the body that sets the technical
`
`standards for the Internet – began worrying that the set of available (unallocated)
`
`IP addresses could become exhausted. How then would new host be able to
`
`connect to the Internet? Indeed, in November of 1993, the IETF chartered a
`
`working group to “to develop an estimate for the remaining lifetime of the IPv4
`
`address space based on currently known and available technologies.” (Ex. 1515, p.
`
`1.)
`
`(49.) In May of 1994, an IETF Request for Comments 1631 was published
`
`that could help solve the address exhaustion problem. (Ex. 1520, p. 1.) Based on
`
`earlier work by the second author (Ex. 1521, p. 1), RFC 1631 proposed a technique
`
`known as Network Address Translation (NAT). The abstract for RFC 1631
`
`
`
`
`
`18
`
`Google Ex. 1509, pg. 18
`
`
`
`
`
`provided both motivation for NAT, as well as an outline of its operation (which
`
`was detailed in the RFC):
`
`The two most compelling problems facing the IP Internet are IP
`address depletion and scaling in routing. … This memo proposes
`another short-term solution, address reuse, … The address reuse
`solution is to place Network Address Translators (NAT) at the borders
`of stub domains. Each NAT box has a table consisting of pairs of local
`IP addresses and globally unique addresses. The IP addresses inside
`the stub domain are not globally unique. They are reused in other
`domains, thus solving the address depletion problem.
`(Ex. 1520, p. 1.)
`
`
`(50.) Figure 2 (adapted from Figure 2 in RFC 1631) shows a configuration
`
`where network address translation is performed at the two routers (A, B) between a
`
`“stub” network (i.e., a network at the “edge” of the Internet, as in the case of the
`
`“trusted network” in Figure 1 above) and the larger Internet. (Id. at p. 3.) In the
`
`example from RFC 1631, Router A has a pool of 256 globally-unique IP addresses
`
`in the range 198.76.29.0 through 198.76.29.255; any packet in the Internet that has
`
`a destination address in this range will be forwarded to router A for delivery to a
`
`host in the network below A. (Id. at pp. 2–4.) In the example from RFC 1631,
`
`there may be up to 16,777,216 hosts in A’s network, with addresses in the range of
`
`10.0.0.0 through 10.255.255.255, but as far as the network outside of A’s network
`
`is concerned, there are only up to 256 IP address associated with A’s network. (Id.
`
`
`
`
`
`19
`
`Google Ex. 1509, pg. 19
`
`
`
`
`
`at p. 3.) Similarly, Router B has a pool of 256 globally-unique IP addresses in the
`
`range 198.76.28.0 through 198.76.28.255, and there may be up to 16,777,216 hosts
`
`in B’s network, with addresses in the range of 10.0.0.0 through 10.255.255.255.
`
`Note that the network addresses in use within A and B’s network are not unique.
`
`Assuming that fewer than 256 computers in A’s network (similarly for B) will
`
`never be communicating outside of A’s network, NAT provides for significant
`
`address reuse – the up to 16 million hosts with A use only 256 globally unique IP
`
`addresses.
`
`
`Figure 2: Network Address Translation, performed at routers A and B,
`connecting “stub” networks to the larger Internet (adapted from Figure 2
`in RFC 1631). (Id. at p. 3.)
`
`(51.) In the example from RFC 1631, each NAT router maintains a “table
`
`consisting of pairs of local IP addresses and globally unique addresses,” i.e., for
`
`each local host that is communicating outside of the local network, the NAT router
`
`(e.g., NAT router B, for example, in Figure 2) maintains a pairing between the
`
`
`
`
`
`20
`
`Google Ex. 1509, pg. 20
`
`
`
`
`
`local address (e.g., in the range of 10.0.0.0 through 10.255.255.255) and the global
`
`IP address (e.g., in the range 198.76.28.0 through 198.76.28.255) associated with
`
`that local host. (Id. at pp. 1–4.) Suppose for example that B has a NAT table entry
`
`pairing global address 198.76.28.4 with local address 10.81.13.22. In this case, in
`
`the example in Figure 2 (taken from RFC 1631 (Id. at p. 3)), the packet arriving at
`
`router B has a destination address of 198.76.28.4, but when that packet leaves
`
`router B heading towards its eventual destination (the host at the bottom right of
`
`Figure 2), the destination address of the packet has been changed to 10.81.13.22.
`
`(52.) In the example above, the packet ultimately arriving at the host in B’s
`
`network was sent by the host shown in A’s network. The host in A’s network has
`
`local address 10.33.96.5 (and thus the packets original source address is 10.33.96.5
`
`and its destination address is 198.76.28.4). Note that when that packet leaves NAT
`
`router A, the packet’s source address has been changed to 198.76.29.7, so that any
`
`external host wanting to reply to this packet will address the reply packet to
`
`198.76.29.7. Router A would use its own NAT table, which pairs global address
`
`198.76.29.7 with local address 198.76.29.7 to forward that reply to the correct
`
`local host in A’s network.
`
`(53.) The RFC-standardized version of NAT in 1994 manipulated the IP
`
`address field in incoming/outgoing packets and assigned a pool of addresses to a
`
`NAT router. (Id. at p. 7.)
`
`
`
`
`
`21
`
`Google Ex. 1509, pg. 21
`
`
`
`
`
`(54.) Note that NAT gateways maintain translation tables, pairing original
`
`IP addresses with the new IP addresses. Since the maximum number of translation
`
`table entries is fixed – limited to the number of global IP addresses in the pool (in
`
`the case of original NAT) – Tsuchiya proposed that a global address associated
`
`with a connection be de-assigned and reused after a connection had remained idle
`
`for some period of time. (Ex. 1521, p. 1.) This notion of reclaiming a resource if it
`
`has remained idle for some period of time has been referred to as “soft state.” (Ex.
`
`1513, p. 9.)
`
`V. The ’298 Patent
`
`(55.) The ’298 patent is directed to the basic and well-known concept of
`
`network address translation using an IP filter. (Ex. 1501, 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 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.)
`
`(56.) 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.)
`
`
`
`
`
`22
`
`Google Ex. 1509, pg. 22
`
`
`
`
`
`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.)
`
`VI. Claim Interpretation
`
`(57.) In proceedings before the USPTO, I understand that the claims of an
`
`unexpired patent are to be gi
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
