UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`
`Juniper Networks, Inc.,
`
`Petitioner
`
`v.
`
`Implicit, LLC,
`
`Patent Owner
`___________
`
`U.S. Patent Nos. 8,694,683; 9,270,790; 9,591,104;
`10,033,839; 10,027,780; 10,225,378
`
`
`Named Inventor:
`Edward Balassanian
`
`Title: Method and System for Data Demultiplexing
`___________
`
`DECLARATION OF SETH NIELSON IN SUPPORT OF PETITIONS
`FOR INTER PARTES REVIEW
`
`
`
`
`Mail Stop: PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`10786038
`
`Juniper Ex. 1011-p. 1
`Juniper v Implicit
`
`

`

`TABLE OF CONTENTS
`
`
`
`
`Page
`INTRODUCTION ........................................................................................ 1
`I.
`BACKGROUND AND QUALIFICATIONS .............................................. 2
`II.
`III. MATERIALS CONSIDERED ..................................................................... 3
`IV. LEGAL STANDARDS ................................................................................ 4
`V.
`TECHNICAL BACKGROUND .................................................................. 6
`VI. THE CHALLENGED PATENTS .............................................................. 19
` Overview .......................................................................................... 19
`
`The ’163 patent ................................................................................. 24
`
`The ’683 Patent ................................................................................ 26
`
`The ’790 Patent ................................................................................ 28
`
`The ’104 Patent ................................................................................ 29
`
`The ’780 Patent ................................................................................ 29
`
`The ’839 Patent ................................................................................ 31
`
`The ’378 Patent ................................................................................ 31
`VII. CLAIM CONSTRUCTION ....................................................................... 32
`
`“message” ......................................................................................... 32
`
`“sequence of [two or more] routines”/“one or more routines” /“routines
`in the sequence of routines” /“list of conversion routines” .............. 32
`“state information” ........................................................................... 33
`“convert one or more packets having a TCP format into a different
`format” / “convert at least one or more of the packets of the message
`into a different format” / “convert packets having a TCP format into a
`different format” / “convert one or more packets in a transport layer
`format into a different format” / “convert packets of the different format
`into another format” ......................................................................... 34
`“execute a Transmission Control Protocol (TCP)” /“a transport layer
`protocol is executed” ........................................................................ 35
`“key [value]” .................................................................................... 36
`
`
`
`
`
`
`
`i
`
`Juniper Ex. 1011-p. 2
`Juniper v Implicit
`
`

`

`
`
`
`
`
`
`
`
`
`
`Page
`VIII. GROUND 1: SMITH IN VIEW OF DECASPER ..................................... 36
` Overview .......................................................................................... 36
`
`Smith – “AltaVista Firewall” ........................................................... 37
` Decasper ........................................................................................... 42
` Motivation to Combine Smith and Decasper ................................... 48
`
`The Combined Smith-Decasper System .......................................... 52
`
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’683 Patent Obvious .................................................. 58
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’790 Patent Obvious .................................................. 88
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’104 Patent Obvious .................................................. 99
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’780 Patent Obvious ................................................ 112
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’839 Patent Obvious ................................................ 124
`The Combination of Smith and Decasper Renders the Challenged
`Claims of the ’378 Patent Obvious ................................................ 125
`IX. GROUND 2: CHECKPOINT IN VIEW OF DECASPER ...................... 132
` Overview ........................................................................................ 132
`
`CheckPoint – FireWall-1 ................................................................ 133
` Decasper ......................................................................................... 145
` Motivation To Combine ................................................................. 145
`
`The Combined CheckPoint-Decasper System ............................... 150
`
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’683 Patent Obvious ................................................ 156
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’790 Patent Obvious ................................................ 181
`
`
`
`
`
`
`- ii -
`
`
`
`Juniper Ex. 1011-p. 3
`Juniper v Implicit
`
`

`

`
`
`
`
`Page
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’104 Patent Obvious ................................................ 190
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’780 Patent Obvious ................................................ 201
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’839 Patent Obvious ................................................ 210
`The Combination of CheckPoint and Decasper Renders the Challenged
`Claims of the ’378 Patent Obvious ................................................ 212
`The Cited Prior Art and Arguments Present Substantially Different Issues
`Than Those Previously Considered by the USPTO ................................. 219
`
`Smith............................................................................................... 219
`
`CheckPoint ..................................................................................... 219
` Decasper ......................................................................................... 221
`
`
`
`
`
`X.
`
`
`
`
`
`
`- iii -
`
`
`
`Juniper Ex. 1011-p. 4
`Juniper v Implicit
`
`

`

`
`
`1.
`
`I, Seth Nielson, submit the following declaration (the “Declaration”) in
`
`connection with the proceeding identified above.
`
`I.
`
`INTRODUCTION
`2.
`I have been retained by counsel for Juniper Networks, Inc. (“Juniper”
`
`or “Petitioner”) as a technical expert in connection with the proceeding identified
`
`above. I submit this Declaration in support of Petitioner Juniper’s Petitions for Inter
`
`Partes Review (each a “Petition,” and collectively the “Petitions”) of United States
`
`Patent Nos. U.S. Patent Nos. 8,694,683 (“the ’683 patent); 9,270,790 (“the ’790
`
`patent); 9,591,104 (“the ’104 patent”); 10,033,839 (“the ’839 patent”); 10,027,780
`
`(“the ’780 patent); and 10,225,378 (“the ’378 patent”) (collectively, the “Challenged
`
`Patents”) against Patent Owner Implicit, LLC (“Patent Owner”). All “Ex. 10XX”
`
`cites herein are to the Exhibits to the Petitions. All “Ex. _” cites followed by a letter
`
`are to exhibits to this Declaration. All citations to “Section XX” are internal citations
`
`to the sections of this declaration.
`
`3.
`
`I understand that Patent Owner has filed a patent infringement lawsuit
`
`in the U.S. District Court for the Eastern District of Texas alleging infringement by
`
`Juniper of certain claims of the Challenged Patents. Implicit, LLC v. Juniper
`
`Networks, Inc., Case No. 2:19-cv-00037-JRG-RSP (E.D. Tex.).
`
`1
`
`Juniper Ex. 1011-p. 5
`Juniper v Implicit
`
`

`

`
`
`4.
`
`I have been asked to consider whether certain claims of the Challenged
`
`patents are obvious in light of the prior art discussed below. As such, my opinions
`
`are limited to the following claims of the Challenged Patents:
`
`• ’683 patent: Claims 1, 2, 4-6, and 8-14
`
`• ’790 patent: Claims 1, 3-5, 7-10, and 12-19
`
`• ’104 patent: Claims 1-7, 10-13, 16, 19, and 20
`
`• ’780 patent: Claims 1-6, 11, 13, 14, 16, 18, and 20
`
`• ’839 patent: Claim 1
`
`• ’378 patent: Claims 1-6, 11, 14, 16-20
`
`II. BACKGROUND AND QUALIFICATIONS
`5.
`I am the Founder and Chief Scientist of Crimson Vista Inc., a boutique
`
`cybersecurity consulting company. I am also an Adjunct Assistant Professor at the
`
`University of Texas at Austin. My subject-matter expertise is cybersecurity, having
`
`offered advice and guidance to government bodies, academic institutions, and
`
`commercial clients. My expertise includes the subfield of network security including
`
`firewalls, network security protocols, cryptographic protocols, and related
`
`technologies.
`
`6.
`
`I began working in the computing industry in the year 2000, after
`
`graduating with a BS of Computer Science from Brigham Young University. I
`
`worked in industry for three years developing networking applications. In personal
`
`2
`
`Juniper Ex. 1011-p. 6
`Juniper v Implicit
`
`

`

`
`
`projects, I also developed a custom firewall and VPN, and experimented with
`
`proxies. In 2009, I completed my PhD in Computer Science from Rice University
`
`with my research emphasis in cybersecurity.
`
`7.
`
`I have taught Network Security and Advanced Network Security at
`
`Johns Hopkins University from 2014-2019. I am now teaching Network Security
`
`and Privacy at the University of Texas at Austin. In addition to these university-level
`
`courses, I teach data security lectures at conferences, consult with clients on network
`
`security architectures, and have offered expert testimony in various litigation matters
`
`on similar topics.
`
`8.
`
`Additional details of my education and employment history, recent
`
`professional service, patents, publications, and other testimony are set forth in my
`
`current curriculum vitae, attached to this declaration as Exhibit A (See Nielson CV).
`
`III. MATERIALS CONSIDERED
`9.
`I have considered information from various sources in forming my
`
`opinions. Besides drawing from approximately two decades of experience in the
`
`computer industry, I also have reviewed the following documents: (a) the
`
`Challenged Patents (Exs. 1003 and 1005-1009); (b) U.S. Patent No. 6,629,163 (“the
`
`’163 patent”) (Ex. 1001), (c) the prosecution file histories of the Challenged Patents
`
`3
`
`Juniper Ex. 1011-p. 7
`Juniper v Implicit
`
`

`

`
`
`and of the ’163 patent (Exs. 1002, 1004 and 1010); and the other documents and
`
`references as cited herein.1
`
`IV. LEGAL STANDARDS
`10.
`I have relied on instructions from counsel as to the applicable legal
`
`standards to use in arriving at my opinions in this Declaration.
`
`11.
`
`I have been informed and understand that patent claims are construed
`
`from the perspective of one of ordinary skill in the art at the time the claimed
`
`invention was made and that, during this proceeding, claims are to be given their
`
`broadest reasonable construction consistent with the specification.
`
`12.
`
`I have been informed and understand that the subject matter of a patent
`
`claim is obvious if the differences between the subject matter of the claim 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 having ordinary skill in the art to which the
`
`subject matter pertains. I have also been informed that the framework for
`
`determining obviousness involves considering the following factors: (i) the scope
`
`and content of the prior art; (ii) the differences between the prior art and the claimed
`
`subject matter; (iii) the level of ordinary skill in the art; and (iv) any objective
`
`evidence of non-obviousness.
`
`
`1 I understand that the file histories for the Challenged Patents will be filed, in each
`case, as Exhibit 1010 only in the corresponding IPR proceeding for efficiency
`purposes.
`
`4
`
`Juniper Ex. 1011-p. 8
`Juniper v Implicit
`
`

`

`
`
`13.
`
`I further understand that the claimed subject matter would have been
`
`obvious to one of ordinary skill in the art if, for example, it results from the
`
`combination of known elements according to known methods to yield predictable
`
`results, the simple substitution of one known element for another to obtain
`
`predictable results, the use of a known technique to improve similar devices in the
`
`same way, or the application of a known technique to a known device ready for
`
`improvement to yield predictable results. I have also been informed that the analysis
`
`of obviousness may include recourse to logic, judgment, and common sense
`
`available to the person of ordinary skill in the art that does not necessarily require
`
`explication in any reference. I understand that so-called “secondary considerations
`
`of non-obviousness,” must be considered in an obviousness analysis. I understand
`
`that an analysis including these secondary considerations helps to prevent the
`
`forbidden use of hindsight in determining whether a patent claim is obvious. I
`
`understand that secondary considerations of non-obviousness include: (a) a long-felt
`
`but unresolved need for the invention; (b) commercial success of the invention; (c)
`
`copying of the invention; (d) praise and recognition of the invention by others; (e)
`
`licensing of the rights to the invention; and (f) unexpected results. In rendering my
`
`opinions, I followed these guidelines.
`
`14.
`
`In my opinion, a person of ordinary skill in the art pertaining to the
`
`Challenged Patent at the relevant date would have a bachelor’s degree in computer
`
`5
`
`Juniper Ex. 1011-p. 9
`Juniper v Implicit
`
`

`

`
`
`science or related field and four years of industry experience in computer
`
`networking, or a master’s degree in computer science and two years of industry
`
`experience. A person of ordinary skill in the art would have experience with
`
`implementation of network protocols, including commonly-used protocols such as
`
`IP and TCP, and related subsystems, and would be aware of data structures,
`
`including hash tables and tries, and data processing technologies such as packet
`
`filters. I base this level of skill on my two decades of experience in the field of
`
`computer science, my understanding of the basic qualifications that would be
`
`relevant to an engineer or scientist tasked with investigating methods and systems
`
`applicable to computer networking, and my familiarity with the backgrounds of
`
`colleagues and co-workers, both past and present. That said, due to the nature of the
`
`subject matter described in the Challenged Patents my opinions would not be
`
`materially affected if a slightly different level of skill in the art were applied.
`
`V. TECHNICAL BACKGROUND
`15. At the time of the ’683 patent, many computer networks (including the
`
`global Internet) were packet-based networks, which means that messages would be
`
`broken up into discrete blocks, or “packets,” that are reassembled into the original
`
`messages after being received by the recipient. The network infrastructure, which
`
`in addition to links (or channels) includes control components such as switches and
`
`6
`
`Juniper Ex. 1011-p. 10
`Juniper v Implicit
`
`

`

`
`
`routers, which move packets from one link to the next, potentially across multiple
`
`switches and/or routers, until the packets reach their destination.
`
`16. The development of many of these core networking technologies were
`
`developed in the 1970’s. These technologies include certain network “protocols”
`
`named TCP (Transmission Control Protocol) and IP (Internet Protocol).
`
`17. Although they may not have heard of TCP/IP, Internet users might be
`
`a little more familiar with the acronym “HTTP,” even if they don’t know what the
`
`letters stand for. Some users will have noticed these letters in their web browser
`
`while others will have noted companies advertising their website with the “http://”
`
`prefix. HTTP stands for the “Hyper-Text Transfer Protocol.” First proposed in
`
`1991, HTTP is a protocol used by web browsers to access data on websites.
`
`Although browsers sometimes hide the “http” in the browser bar these days (or
`
`“https as shown below, which is HTTP over secure transport such as SSL, it still
`
`shows up when typing in addresses:
`
`
`
`18. A networking “protocol,” such as HTTP, is simply the rules of
`
`communication between two machines connected on a network. The protocol tells
`
`7
`
`Juniper Ex. 1011-p. 11
`Juniper v Implicit
`
`

`

`
`
`each machine how to form, transmit, process, and respond to messages. In every-
`
`day life, humans use “protocols” all the time in communicating with other humans.
`
`For example, when a person picks up the phone, he or she typically says “Hello?”
`
`While most of us wouldn’t think of this as a “rule”, the communications could break
`
`down pretty quickly if someone picked up a ringing phone and said, “Goodbye!”
`
`We use these rules to help manage the complexities of social interactions.
`
`19. Computers are not that different. If one computer wants to “talk” to
`
`another computer, it must know how to say “hello,” what kind of messages to send,
`
`and when to say “goodbye.”
`
`20. For example, I mentioned that a typical web browser uses the
`
`HyperText Transfer Protocol (HTTP) for most communications. HTTP has rules
`
`for how messages are exchanged between two computers. These rules define two
`
`basic roles: “client” and “server.” The server is a computer that listens for requests
`
`and the client sends requests to a listening server.
`
`21. When a client wants to make an HTTP request of a server, it creates an
`
`HTTP “request” message. HTTP (versions 1.0 and 1.1) use human-readable
`
`messages so I will reproduce a few examples here. Imagine that a user goes to their
`
`browser and types in “cnn.com”. The browser would create an HTTP request that
`
`looks something like this:
`
`GET / HTTP/1.1
`Host: www.cnn.com
`
`8
`
`Juniper Ex. 1011-p. 12
`Juniper v Implicit
`
`

`

`
`
`
`22. When the server receives the GET request, it examines the requested
`
`resource (e.g., the top-level resource “/” or the resource “/us”) and determines if it
`
`can respond. If the server knows how to serve that resource, it sends back an HTTP
`
`response that might look something like this:
`
`HTTP/1.1 200 OK
`Content-Length: 1024
`Content-Type: text/html
`
`<content>
`
`23. Like the HTTP request, the HTTP response follows rules. The first line
`
`is called the “status line” and the first chunk of the status line text is the HTTP
`
`version number of the response. The next two chunks are details about the status
`
`including a numeric code. The 200 code indicates that the requested resource was
`
`found and is being served. If the requested resource was not found, the web server
`
`would most likely return a “404” error code, which some websites still display
`
`visually when a request can’t be served. For example, here is how the GitHub
`
`website displays information when a webpage is not found.
`
`9
`
`Juniper Ex. 1011-p. 13
`Juniper v Implicit
`
`

`

`
`
`
`
`24. The headers shown in my example include information about the
`
`“body” of the response. Unlike the GET request, this response has data in addition
`
`to the headers. The “Content-Type” header indicates that the body is a text file with
`
`HTML content (the standard way to define a webpage), and the “Content-Length”
`
`indicates how long the body is. “Content-Length” must typically be included or the
`
`browser won’t know how much data to read from the network. Once again, all of
`
`these rules allow the computers to know what to expect and how to process it when
`
`received.
`
`25. All of the examples I’ve included are exceptionally simplified.
`
`Moreover, when a browser requests a webpage, the response will generally include
`
`many other “pointers” to additional web resources that the browser will
`
`automatically download. In the case of CNN, when the user enters “cnn.com” into
`
`their browser, this initiates a single HTTP request. But the response includes
`
`hundreds of additional HTTP URLs that the browser will automatically request (i.e.,
`
`10
`
`Juniper Ex. 1011-p. 14
`Juniper v Implicit
`
`

`

`
`
`additional GET requests) in order to download all of the images, videos, and even
`
`ads that make up the visual representation of the website.
`
`26. But for all of its power HTTP is relatively limited in the wider view of
`
`all the requirements for computer communications. For example, I mentioned that
`
`the HTTP request is sent to the HTTP server that, in turn, sends back an HTTP
`
`response. But HTTP does not have any mechanisms for actually finding the server,
`
`routing the messages to it, or knowing how to send a response back! All of those
`
`operations (and many, many more) are performed by other protocols that work
`
`together with HTTP.
`
`27. Because there are so many necessary steps to global network
`
`communications, no one protocol should handle them all. Network architects create
`
`network protocols that chain together, with each element in the chain handling a
`
`different part of the communication processing. The chain of protocols is sometimes
`
`called a “network stack.” See Ex. 1044 (Computer Networks) at 4-14 (describing
`
`layering of protocols, encapsulation of messages, and other network architecture
`
`approaches).
`
`28.
`
`In the case of HTTP, for example, the GET message sent is first passed
`
`to another protocol, such as TCP, the Transmission Control Protocol. TCP performs
`
`several important functions. TCP first creates a “session” that enables all of the data
`
`to be grouped together so that one session’s data can be distinguished from another’s.
`
`11
`
`Juniper Ex. 1011-p. 15
`Juniper v Implicit
`
`

`

`
`
`Also, if TCP receives data out-of-order, it uses this session information to correctly
`
`reorder the data. TCP also computes error-detection codes in order to determine if
`
`data has become corrupted. Both sides of TCP communicate about the data being
`
`received; lost or corrupted data is resent to ensure that all data eventually arrives.
`
`29. TCP also performs an operation called “multiplexing.” The browser
`
`isn’t the only program using the network, after all. There has to be a way to identify
`
`data meant for the browser, an email program, a chat program, video games, Internet
`
`music programs, and so forth. Also, a server, such as a web server, has to be able to
`
`distinguish between traffic from multiple clients! TCP solves this problem with port
`
`numbers.
`
`30. When an outbound connection, such as the request from a browser for
`
`a webpage, is sent, an unused TCP port number is assigned as the “source port”.
`
`This port number enables the information sent back from the server to be sent to the
`
`correct program. For example, many users have multiple webpages open at once
`
`and the randomly assigned outbound port ensures that the responses go to the correct
`
`places. It will also include a “destination port” indicating which application should
`
`process the data at the server. See Ex. 1044 (Computer Networks) at 15-18
`
`(describing the concept of ports for transport protocols).
`
`31.
`
`In order to receive data, a server such as a web server, will register or
`
`reserve an unused port to receiving incoming requests. For commonly used
`
`12
`
`Juniper Ex. 1011-p. 16
`Juniper v Implicit
`
`

`

`
`
`applications, the server will typically use a “well-known” port. Web servers, for
`
`example, usually use port 80 for regular traffic (http) and port 443 for encrypted
`
`traffic (https). When the client data comes in, the destination port is checked. The
`
`server that reserved, or claimed, that port, will create a unique session for this
`
`specific client. The server uses these unique sessions to differentiate the
`
`communications from different clients. Id. at 17-18 (“[The source port and
`
`destination port], plus the source and destination IP addresses, combine to uniquely
`
`identify each TCP connection.”).
`
`32. These unique sessions can be identified (de-multiplexed) based on the
`
`following pieces of data: source IP address, protocol, source TCP port, destination
`
`IP address, destination TCP port (I will discuss IP addresses and the protocol field
`
`shortly). Using these characteristics, the network can keep the traffic between two
`
`endpoints separate from each other. The data is both delivered to the correct
`
`application and, if the application is a server, kept separate from the data of other
`
`clients. See id at 221, 290-291 (discussing the protocol field’s use for de-
`
`multiplexing to the higher protocol, and TCP’s 4-tuple demux key).
`
`33. TCP is very powerful; but it is also not enough! TCP can demultiplex
`
`data when it arrives, but it has no addressing mechanism for the computer’s address.
`
`The IP (Internet Protocol) layer does that.
`
`13
`
`Juniper Ex. 1011-p. 17
`Juniper v Implicit
`
`

`

`
`
`34. The IP protocol is designed to bridge together all of the various local
`
`networks around the world. Specifically, IP provides IP addresses, which are global
`
`addresses used for routing messages. Although we typically use domain names on
`
`the Internet (e.g., “cnn.com”), these domain names are converted into IP addresses
`
`for actually getting packets to the right places.
`
`35.
`
`IP has to do its own form of multiplexing and de-multiplexing. Just
`
`like TCP has to send data “up the stack” to the correct application (e.g., HTTP, FTP,
`
`etc.), IP has to send data “up the stack” to the correct transport layer. So far, all of
`
`the examples have been with TCP, but there are other transport protocols as well,
`
`such as UDP. When data is sent “down the stack” to the IP protocol, the identity of
`
`the transport protocol that sent the data is stored in the IP header in the “protocol”
`
`field. When the data is received, the protocol field is used to know whether data
`
`should be sent “up the stack” to TCP processing, UDP processing, or some other
`
`transport-layer handler. See id. at 221 (“The Protocol field is simply a
`
`demultiplexing key that identifies the higher-level protocol to which this IP packet
`
`should be passed. There are values defined for TCP (6), UDP (17), and many other
`
`protocols that may sit above IP in the protocol graph.”)
`
`36.
`
`In addition to TCP and IP, there are lower protocols, such as Ethernet,
`
`that are used to transmit data over specific types of networks.
`
`14
`
`Juniper Ex. 1011-p. 18
`Juniper v Implicit
`
`

`

`
`
`37. There are many reasons these protocols are split up. First of all, trying
`
`to create HTTP to do all of these steps together would be a nightmare. The
`
`complexity of the implementation would be significantly higher which is typically
`
`associated with more bugs and security vulnerabilities. See id. at 29-39 (describing
`
`layering of protocols, encapsulation of messages, and other network architecture
`
`approaches).
`
`38. Second, without modularity, the system is too fragile. Although all of
`
`my examples so far have used TCP, there are other session protocols such as UDP.
`
`Unlike TCP, UDP does not tie the packets together, do any reordering, do any
`
`resending, or any error checking. By keeping the protocols modular, it is possible
`
`to exchange TCP with UDP without having to re-write application protocols like
`
`HTTP. Or, in another example, there are two versions of the Internet Protocol (IPv4
`
`and IPv6). See id. (describing modular design).
`
`39. The use of multiple, modular protocols (e.g., HTTP, TCP, and IP)
`
`means that even a single transfer of data across the Internet (e.g., serving a webpage
`
`in response to a user request) involves a multitude of conversions of data from one
`
`format into another. See id. (describing data passing from one protocol to another,
`
`encapsulation, decapsulation, and multiplexing).
`
`40. A conceptual reference model for network stacks was created in the
`
`80’s called the Open Systems Interconnection model (OSI model). This model did
`
`15
`
`Juniper Ex. 1011-p. 19
`Juniper v Implicit
`
`

`

`
`
`not identify specific protocols such as TCP or IP, but rather defined what a protocol
`
`at a specific numbered layer should do. The OSI model defined 7 layers as shown
`
`below, illustrating also how one layer is encapsulated inside another by showing the
`
`data and the various headers present at each layer:
`
`OSI Model
`
`
`
`41. The OSI model is somewhat idealistic. In practice, most networking
`
`applications and devices deal with only layer 2 (such as Ethernet), layer 3 (IP), layer
`
`4 (TCP and UDP), and layer 7 (application layer).
`
`42. Almost all networks use a gateway router. The gateway router serves
`
`a primary purpose of knowing how to route packets out of the network from interior
`
`nodes, or how to route packets into the network from exterior nodes. It is called a
`
`16
`
`Juniper Ex. 1011-p. 20
`Juniper v Implicit
`
`

`

`
`
`“gateway” router because all the devices on the local network must send their data
`
`through the gateway to reach other networks.
`
`43. Gateways have also taken on defensive capabilities. Although
`
`somewhat overly simplistic, networks are typically thought of as divided between
`
`local and remote networks. Typically, a local network can only connect to the
`
`Internet through a gateway that may be as simple as a home device provided to the
`
`user by the local telecommunications company, or a powerful and expensive system
`
`engineered to provide vast amounts of data with speed and resiliency. But no matter
`
`whatever other features it has, the gateway is the “choke point” for data going out
`
`and coming in.
`
`44. For this reason, gateways are a natural defensive position in the world
`
`of cyber security. Not only are they choke points, but they also represent a natural
`
`boundary in trust and security policy. The gateway separates “us” and “them,” and
`
`traffic that might be entirely acceptable for “us” may not be the least bit appropriate
`
`for “them.” A gateway that enforces security policies is typically called a firewall.
`
`The most basic kinds of firewall, commonly referred to as a packet-filtering firewall,
`
`simply checks
`
`the source and destination of
`
`the
`
`traffic, blocking most
`
`communication beyond certain standard channels. Ex. 1032 (Hunt) at 5-6. However,
`
`more advanced firewalls can scan the content of the traffic itself (such as antivirus),
`
`enabling far more advanced policies and security features. Id. at 2, fn1, 7-8.
`
`17
`
`Juniper Ex. 1011-p. 21
`Juniper v Implicit
`
`

`

`
`
`45. Some firewalls will even reassemble the application data within the
`
`firewall itself first in order to scan the data for malware, viruses, and other potential
`
`threats. Ex. 1032 (Hunt) at 7-8. For routing purposes, the firewall still only needs
`
`the IP header. But for security purposes, it can examine any data and perform any
`
`processing necessary to enforce the security policy.
`
`46. Another type of common network device is the proxy. A proxy is so
`
`named because it makes requests on behalf of other computers. For example, a web
`
`proxy would handle all of the web requests for its clients. One reason for using a
`
`proxy is caching. Each time a URL is requested through the proxy, the proxy can
`
`keep a cached copy of the data on its local storage. If at a later point there is another
`
`request for the same URL from within the network, the proxy can serve its own copy
`
`much faster, speeding up access to popular data. See Ex. 1053 (World-Wide Web
`
`Proxies by Luotonen) at 5-6 (“Caching of documents has been introduced, giving
`
`notice able speed-ups in retrieve times… The basic idea in caching is simple: store
`
`the retrieved document into a local file for further use so it won’t be necessary to
`
`connect to the remote server the next time that document is requested…”).
`
`47. Proxies can also be used for security purposes, serving a very similar
`
`purpose to firewalls. See e.g., Ex. 1050 (RFC 1919) at 1-2. If all of the outbound
`
`traffic is funneled through one or more proxies, the p