Request for Reexamination of U.S. Patent No. 7,490,151
`
`Primary Domain Name
`Server
`
`IP address of BinGO!'s first Domain Name
`Server (DNS).
`
`Secondary Domain Name
`Server
`
`Primary WINS
`
`IP address of another Domain Name Server.
`
`IP address of BinGO!'s first WINS (Windows
`Internet Name Server) or NBNS (NetBIOS
`Name Server).
`
`Secondary WINS
`
`IP address of another WINS or NBNS.
`
`Table 7-15:
`
`IP .STATIC SETTINGS
`
`Dynamic Name Server
`Negotiation
`
`Defines whether BinGO! receives IP
`addresses for Primary Domain Name Server,
`Secondary Domain Name Server, Primary
`WINS and Secondary WINS from the WAN
`partner or sends them to the WAN partner.
`
`Table 7-16: WAN PARTNER • EDIT •
`
`/P • ADVANCED SETTINGS
`
`Then, on page 201, BinGO UG shows that a WAN partner (e.g., a secure corporate network) can
`be sent DNS requests received by the BinGO! router for resolution and handling:
`
`The Dynamic Name Server Negotiation field contains the following selection
`options:
`
`off
`
`yes
`
`client (receive)
`
`server (send)
`
`BinGO! does not send or answer requests for
`WINS or DNS IP addresses.
`
`The response is linked to the mode for issuing I
`receiving an IP address (setting under IP Tran(cid:173)
`sit Network in WAN PARTNER • EDIT •
`/P):
`
`•
`
`•
`
`•
`
`:smuU! senos requests ror WIN::; ana uNt
`P addresses to the WAN partner, if dynam
`'c client is selected.
`
`:smuU! answers requests ror WIN::; anc
`)NS IP addresses from the WAN partner, i
`:Jvnamic server is selected.
`
`:smuU! aoes not sena or answer request~
`or WINS and DNS IP addresses, if yes 01
`10 is selected.
`
`BinGO! sends requests for WINS and DNS IP
`addresses to the WAN partner.
`
`BinGO! answers requests for WINS and DNS
`IP addresses from the WAN partner.
`
`Table 7-17: Dynamic Name Server Negotiation
`
`Thus, in this second configuration (i.e., where the BinGO! router was configured to connect to a
`router for the corporate network as a WAN Partner, and the BinGO! router has the Dynamic
`Name Server Negotiation variable set to be active), all DNS and WINS requests would be sent to
`the WAN Partner for resolution. See also BinGO at 202 ("Proceed as follows if you want
`
`93
`
`Page 93 of 184
`
`VIRNETX EXHIBIT 2007-Part 2
`Apple v. Virnetx
`Case IPR2013-00354
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`BinGO! to report the DNS or WINS entered to the WAN partner (Server Mode) or if
`DNS/WINS addresses other than those in the LAN are to be used for connections to the WAN
`partner (Client Mode, e.g. for dialing into an Internet Service Provider).").
`
`BinGO thus shows two configurations in which a determination is made by a data
`processing device that intercepts DNS requests sent by a client in which it is determined whether
`the intercepted DNS request corresponds to a secure server.
`
`Step (ii) of claim 1 specifies: "when the intercepted DNS request does not correspond to
`a secure server, forwarding the DNS request to a DNS function that returns an IP address of a
`nonsecure computer."
`
`As described above, BinGO shows two different configurations in which DNS requests
`from a client computer are sent to a router and evaluated. In each configuration, a determination
`is made whether the DNS request specifies a secure destination, or a non-secure destination (e.g.,
`a non-secure website on the Internet).
`
`In the first configuration (i.e., where the BinGO! router sends the request to a DNS server
`on the LAN on which the router is located), a determination is made whether the hostname in the
`DNS request matches a hostname in the local secure DNS server. If it does not, then the BinGO!
`router will send the request to a secondary DNS server as designated in its configuration. BinGO
`shows that ordinarily a BinGO! router will be configured to have an internet service provider
`(ISP) as a default WAN partner. See, e.g., BinGO UG at 90 ("Generally, the route to the Internet
`provider is used as the default route, because most unknown packets are bound for the Internet
`anyway (e.g. www. bintec.de ). "). In this configuration, if a DNS request specifying a non-secure
`destination (i.e., one that does not match a name on the local DNS server storing IP addresses of
`secure computers), then that DNS request would be sent to the ISP designated as a WAN partner,
`and the DNS server of this ISP would resolve the non-secure destination and return the IP
`address. See, e.g., BinGO UG at 88 ("If you have configured Internet access with the Wizard
`and you do not have your own DNS server, you can obtain the IP address of your provider's
`DNS server. The router is known as the DNS proxy by the PCs in the LAN. When a request is
`made for a name resolution (e. g. for www.bintec.de), the PC asks the router, and the router in
`turn refers to the provider's DNS server. Translation of the address can then take place there.").
`
`In the second configuration (i.e., where DNS requests are forwarded to a router at the
`secure corporate network), a determination is made whether the DNS specifies a secure or non(cid:173)
`secure destination. In the latter case, the router at the corporate network will take steps to
`resolve the DNS request and return the IP address of the non-secure destination. See, e.g., BinGO
`UG at 90 ("If you have not configured Internet access, but your head office has an Internet
`Service Provider, you can access the Internet via the provider of your WAN partner. ... Due to
`the fact that your default route leads all unknown packets to your head office, and there another
`default route in turn sends all unknown packets to its Internet provider, you can access the
`Internet via your partner's network.")
`
`BinGO thus shows that when an intercepted DNS request does not correspond to a secure
`server, a DNS function returns the IP address of the non-secure computer.
`
`94
`
`Page 94 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`Step (iii) of claim 1 specifies: "(3) in response to determining that the DNS request in
`step (2) is requesting access to a secure target web site, automatically initiating the VPN between
`the client computer and the target computer."
`
`As explained above, BinGO shows processes whereby a BinGO! router automatically
`establishes an encrypted ISDN connection after authentication between client computers on a
`LAN with the BinGO! router and destination computers inside a secure corporate network. Also
`as explained above, this occurs after a DNS request generated on a client computer is evaluated
`and determined to be identifying as the destination a secure computer on the corporate network.
`BinGO further shows that it could also be configured to establish these connection using a
`variety of types ofVPNs. See, e.g., BinGO EFR at 73-98. In particular, BinGO EFR shows
`configurations in which the BinGO! router would establish encrypted tunnels between the client
`computer and the secure destination computer. See, e.g., BinGO EFR at 82-84.
`
`BinGO thus shows that in response to determining that a DNS request is requesting
`access to a secure target web site, automatically initiating an encrypted channel between the
`client computer and the target computer.
`
`Accordingly, BinGO anticipates claim I ofthe '151 under 35 U.S.C. § 102(a).
`
`2.
`
`Claim 2
`
`Claim 2 of the '151 patent depends from claim 1, and specifies that "step (iii) comprises
`the steps of: (a) determining whether the client is authorized to access the secure server; and (b)
`when the client is authorized to access the secure server, sending a request to the secure server to
`establish an encrypted channel between the secure server and the client. "
`
`BinGO explains that a BinGO! router could be configured to require authentication from
`client computers attempting to use the BinGO! router to gain access to a secure destination. For
`example, BinGO UG explains that all users must have authentication credentials (i.e., user
`account and password) and that this is checked each time a user attempts to use the BinGO!
`router. For example, BinGO UG at 243 explains:
`
`You can log in to BinGO! in several different ways as described in chapter 5,
`page 97, but logging in is always protected by a password. Every failed
`attempt is logged by a syslog message indicating the source and creates a
`relevant SNMP trap. Pauses are introduced after several failed attempts in
`order to make automatic attempts to log in more difficult.
`
`BinGO further explains that it uses conventional authentication techniques. See, e.g., BinGO UG
`at 242 ("PAP, CHAP and MS-CHAP are the common procedures used for authentication of PPP
`connections. These use a standard procedure to exchange a user ID and a password for checking
`the identity of the far end.") BinGO also explains that it provides additional mechanisms to
`authenticate users, such as call-back functionality in which a remote user accessing a BinGO!
`router is called back to establish the connection. See, e.g., BinGO UG at 242 (§ 8.2.4). See also
`BinGO UG at 40 ("Before every connection, BinGO! and the router at HQ check the incoming
`data to see if they should take the call. In order to protect the network against unauthorized
`
`95
`
`Page 95 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`access, acceptance of the call only takes place after correct authentication. This authentication is
`based on a common password and two codes that you and your partner use for the connection.");
`ld. at 175-176 (authentication required for access to corporate network); BinGO EFR at 84-85
`("Both the ISP and the VPN Server will typically want to verify the initiating partner during
`connection establishment. Authentication is performed in band using PAP, CHAP, or MS(cid:173)
`CHAP.").
`
`BinGO also discloses that a remote computer (e.g., in a WAN partner such as a corporate
`headquarters network) may access a BinGO! router to perform remote configuration and
`administration functions. See BinGO UG at 130 ("The "isdnlogin service allows incoming data
`calls access to the SNMP shell of your BinGO!. This is how BinGO! can, for example, be
`remotely configured and administrated.") The BinGO! router inherently is a secure computer
`destination, requiring authentication to access and employing encryption for communications.
`See BinGO UG at 101-103 (describing process where BinGO! router receives ISDN call from
`remote computer and requires authentication to gain access to server administration functions);
`BinGO UG at 265 ("BinGO! supports the encryption ofPPP connections to WAN partners.
`Encryption is based on the MPPE (Microsoft Point to Point Encryption) procedure with code
`lengths of 40 bits and 128 bits."). The BinGO! router also will host web pages that are
`accessible for administration purposes to authenticated users. See, e.g., BinGO UG at 236
`("Every BinTec router has a homepage, the so-called HTTP status page. You can use this with
`the aid of an Internet browser (e.g. Netscape Navigator, Internet Explorer) to display the status of
`BinGO!. All users of the BinGO! LAN can then view the router status, provided they know the
`password for the user name ht-tp."); see also generally, ld. at 236-239. Thus, if a remote user
`fails to authenticate to the BinGO! router, that user will not be able to access any of the remote
`administration or status web page functions of the BinGO! router, and instead will be returned an
`error.
`
`Accordingly, BinGO anticipates claim 2 ofthe '151 patent under§ 102(a).
`
`3.
`
`Claim 3
`
`Claim 3 depends from claim 2, and specifies that "step (iii) further comprises the step of:
`(c) when the client is not authorized to access the secure server, returning a host unknown error
`message to the client.
`
`As described above in connection with claims 1 and 2, BinGO shows systems and
`processes in which a BinGO! router serves as a DNS proxy server, and will establish encrypted
`channels with a secure server. BinGO! also explains that it employs conventional DNS
`procedures. See, e.g., BinGO UG at page 358 (definition of domain name service/domain name
`server). BinGO further explains that it employs various conventional authentication techniques,
`including CHAP. See, e.g., BinGO UG at 156; BinGO EFR at 82 (explaining that one VPN
`tunneling technique is PPTP according to RFC 1171). BinGO thus shows that BinGO! routers
`follow well-known and standardized industry protocols governing communications (e.g., PPTP
`(RFC 1171), DNS handling and resolution (RFC1034, 1035).
`
`A client computer that fails to authenticate in any of the configurations specified in
`BinGO which employ standardized authentication procedures (e.g., CHAP pursuant to
`
`96
`
`Page 96 of 184
`
`

`
`Request for Reexamination ofU.S. Patent No. 7,490,151
`
`RFC1171) will return an error that terminates the connection. For example, it was known in the
`art under the CHAP authentication protocol, a failure of authentication returns an error and
`should prompts termination of the connection. See, e.g, RFC 1994 at 9 ("Ifthe Value received in
`a Response is not equal to the expected value, then the implementation MUST transmit a CHAP
`packet with the Code field set to 4 (Failure), and SHOULD take action to terminate the link.").
`Once terminated, the TCP/IP response will return an error as well, which commonly is the host
`unknown error message.
`
`Accordingly, BinGO anticipates claim 3 ofthe '151 patent under 35 U.S.C. § 102(a).
`
`4.
`
`Claim 4
`
`Claim 4 depends from claim 3, and specifies that "the client comprises a web browser
`into which a user enters a URL resulting in the DNS request."
`
`BinGO shows that web browsers on client computers were the typical type of application
`that would generate DNS requests. See, e.g., BinGO UG at 15 ("Thus, via your router, as shown
`above, you can connect with the network of your Internet provider and thus avail of the usual
`services of the Internet, such as the World Wide Web (WWW) or e-mail."); Id at 87 ("What
`about if you want to communicate or access data by simply using the name and not the number
`(IP address), for example, if you want to talk with the PC BossPC or you want to see the
`Internet pages www.bintec.de? BossPC and www.bin- tec.de are clearly not IP addresses, but
`names. As computers only understand IP addresses and not names, it is necessary for the names
`to be translated (resolved) into their corresponding IP addresses.")
`
`Accordingly, BinGO anticipates claim 4 of the' 151 patent under 35 U.S. C. § 102(a).
`
`5.
`
`<:Iaim 5
`
`Claim 5 of the '151 patent depends from claim I, and specifies "automatically initiating
`the encrypted channel between the client and the secure sewer comprises establishing an IF
`address hopping scheme between the client and the secure server."
`
`Solely for the purposes of this request, Requestor observes that "secure sewer" and "IF
`address'' may be determined by the Office to be typographical errors, such that the Office may
`consider a "secure sewer" to be referring to a "secure server" and an "IF address" to be referring
`to an "IP address."
`
`BinGO shows several processes in which a VPN is established by creating an IP hopping
`scheme between the client and destination computers. For example, on pages 244-246, BinGO
`UG shows a protocol called Network Address Translation (NAT) which is used to route IP
`packets between client and destination computers. As explained on pages 244-246:
`
`8.2. 7 NAT (Network Address Translation)
`
`NAT is a simple-to-operate procedure that can be used for four purposes in
`the BinTec implementation:
`
`97
`
`Page 97 of 184
`
`

`
`Request for Reexamination ofU.S. Patent No. 7,490,151
`
`Hiding the internal host addresses of a LAN by remapping to one or
`more external addresses. The external addresses remain unchanged.
`
`Controlling the external to internal access. Externally the router
`forwards all data packets, internally it only forwards what has been
`explicitly enabled (Forward NAT).
`
`Reverse NAT ensures that a connection partner uses only a single IP
`address. Only incoming connections are allowed from the partner, e.g.
`as a service from Internet Service Providers (ISP).
`
`Permanent monitoring of the connections into and out of a network via
`the router with indication of the source and destination addresses and
`ports.
`
`NAT always refers to an interface. The LAN to which BinGO! is connected is
`always referred to as "inside", the WAN partner as "outside".
`
`See also BinGO UG at 167-168.
`
`BINGO EFR also shows that the BinGO! router could be configured to use an IP hopping
`scheme called "Open Shortest Path First" ("OSPF"). BinGO EFR explains in the overview of
`OSPF that in this protocol there are "No hop-count limitations" for forwarding packets to a
`particular station. See BinGO EFR at 17. BinGO EFR thus explains that this IP hopping
`protocol can used by the BinGO! router (e.g., to route traffic in a VPN it establishes between a
`client computer and a destination computer).
`
`Accordingly, BinGO anticipates claim 5 of the '151 patent under 35 U.S.C. § 1 02(a).
`
`6.
`
`<:Iaiun 6
`
`Claim 6 depends from claim 1, and specifies that the step of "automatically initiating the
`encrypted channel between the client and the secure server avoids sending a true IP address of
`the secure server to the client."
`
`BinGO discloses several configurations in which DNS requests are used to automatically
`establish encrypted channels between a client computer and a secure destination computer. In
`particular, BinGO shows establishment of a VPN through which client computers can send
`secure, encrypted communications to a secure destination computer, such as a server on a remote
`corporate network. For example, on page 94, BinGO EFR describes an example of aLAN-to(cid:173)
`LAN configuration established using BinGO! routers:
`
`98
`
`Page 98 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`Example LAN-to-LAN Configuration
`
`Two distant networks, a corporate central site LAN and a supplier or
`partner's network can be connected over the Internet via a Virtual Private
`Network using two BRICKs as follows.
`
`10.6.6.2
`
`192.168.99.9
`I
`Gil 5
`
`10.6.6.1
`
`10.5.5.2
`
`192.168.12.1
`
`I •I F
`
`10.5.5.1
`
`SupplierNet.com
`
`CentraiSite.com
`
`Once both BRICKs are configured for Virtual Private Networking
`hosts on either LAN can connect to hosts on the remote LAN. All traffic
`that is routed between the two networks is encrypted (user-data encryp(cid:173)
`tion). Individual hosts are not required to support PPP or PPTP, the VPN
`remains transnarent.
`
`In this configuration, the two BinGO! routers send encrypted communications to each other via
`the Internet. The encryption and decryption of traffic in this configuration is handled by the
`BinGO! routers. !d. As indicated in this example, individual hosts are not required to support
`PPP or PPTP, the VPN remains transparent. Thus, the client computers on each LAN (the
`"hosts") communicate only with the BinGO! router, and do not receive the IP address of the
`remote host. See also BinGO UG at 265; BinGO EFR at 83-85 ("data encryption/decryption is
`performed at each end ofthe tunnel").
`
`Accordingly, BinGO anticipates claim 6 ofthe '151 patent under 35 U.S.C. § 102(a).
`
`7.
`
`<:Iaiun 7
`
`Independent claim 7 is directed to subject matter similar to that recited in claim 1, except
`it is presented as "computer readable medium" form. For example, claim 7 includes limitations
`concerning determining whether a DNS request corresponds to a secure server automatically
`creating an encrypted channel between the client and secure server which are analogous to claim
`1. In particular, claim 7 recites:
`
`7.
`
`A computer readable medium storing a domain name server (DNS)
`proxy module comprised of computer readable instructions that, when
`executed, cause a data processing device to perform the steps of:
`
`(i)
`
`(ii)
`
`intercepting a DNS request sent by a client;
`
`determining whether the intercepted DNS request corresponds
`to a secure server; and
`
`99
`
`Page 99 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`(iii) when the intercepted DNS request does not correspond to a
`secure server, forwarding the DNS request to a DNS function
`that returns an IP address of a nonsecure computer; and
`
`(iv) when the intercepted DNS request corresponds to a secure
`server, automatically initiating an encrypted channel between
`the client and the secure server.
`
`The preamble of claim 7 specifies a "[a] computer readable medium storing a domain
`name server (DNS) proxy module comprised of computer readable instructions .... "
`
`BinGO discloses that a BinGO! router includes a DNS proxy server functionality. See,
`e.g., BinGO UG at 87. The BinGO! router possesses this functionality by running executable
`code stored in a flash memory component ofthe server. See, e.g., BinGO UG at 294 (explaining
`product features of BinGO! router include I MB/8 bit flash-ROM); 279-281 (describing how to
`update code stored in flash-ROM). BinGO thus discloses a computer readable medium storing a
`DNS proxy module comprised of computer readable instructions that, when executed, cause the
`BinGO! router to perform specified steps.
`
`Step (i) of Claim 7 specifies: "intercepting a DNS request sent by a client."
`
`BinGO discloses that a BinGO! router would ordinarily be configured to receive DNS
`requests made on client computers on a LAN on which the BinGO! router is resident. See, e.g.,
`BinGO UG at 60-61 (describing configuration of client computers to send DNS requests to
`BinGO! router); !d. at 91 ("All packets whose destinations are not within the local network are
`sent by your PC to this gateway. BinGO! serves as this gateway."). BinGO thus shows that
`DNS requests that are generated on client computers are intercepted by the BinGO! router for
`handling, rather than being resolved by the client computer itself.
`
`Step (ii) of Claim 7 specifies: "determining whether the intercepted DNS request
`corresponds to a secure server."
`
`As explained above in connection with claim 1, BinGO discloses two configurations in
`which a BinGO! router is will determine if an intercepted DNS requests corresponds to a secure
`server.
`
`In a first configuration, BinGO shows a BinGO! router being configured to access a DNS
`server on the LAN which stores information correlating hostnames with IP addresses of secure
`servers (e.g., computers on a corporate network). Specifically, on pages 88-89, BinGO UG
`explains:
`
`If, in addition to an Internet connection, you have configured a corporate net(cid:173)
`work connection, entered BinGO! as a DNS proxy server, and the DNS
`settings of your router lead to the Internet provider (a standard setting of the
`Wizard), all requests for name translation would be sent to your provider. If
`you want to reach a PC in your partner's network (BossPC), BinGO!
`establishes a connection to the provider and asks for the IP address of BossPC.
`
`100
`
`Page 100 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`Unlike "names" such as www.bintec.de, computer names are not known on
`the Internet. They are only used within a corporate network (domain, working
`group). The DNS server of the provider is thus usually unable to translate the
`name. This connection to your provider has been a waste of time, not to
`mention money. And you still have not reached BossPC.
`
`In order that such unintentional and useless connections are not established,
`you must prevent such requests about computers in your partner's network
`taking place in the first place. This task is carried out by the NetBIOS filter
`you configured with the Wizard. (see chapter 4.7, page 93). This, however,
`has not solved your problem. You still want to have the name BossPC
`translated into its IP address.
`
`One possibility would be to set up your own Domain Name Server in
`which all the names of the PCs in your partner's network and their
`corresponding IP addresses that you want to reach are listed . ...
`
`BinGO UG explains that this configuration is implemented by configuring the BinGO! router to
`specify this secure server DNS server on the LAN. See BinGO UG at 201 (explaining
`configuration ofDNS server location in BinGO! router: "DNS in the LAN ... If you have set up
`a DNS in your LAN, enter its IP address."). BinGO further explains that the BinGO! router
`could function as a DNS proxy server, that it could be configured to use a primary and secondary
`DNS server, and that the process of DNS resolution was hierarchical (meaning that the first DNS
`server would be consulted, and if no IP address was returned, the DNS request would be sent to
`the secondary DNS server for resolution, etc.). See, e.g., BinGO UG at 87 ("DNS servers are
`structured hierarchically. As soon as the primary DNS receives a request, it tries to translate the
`name. If it is not able to translate the name, it refers the request to the next higher DNS."); !d. at
`200 (showing configuration options for primary and secondary DNS servers ofthe BinGO!
`router).
`
`Thus, in this configuration, after receiving a DNS request from a client computer, the
`BinGO! router would use the local DNS server containing the entries of secure destinations to
`determine if the DNS request specified a secure server, and would return the IP address of that
`server if it did. If that DNS query returned an IP address of a secure server on, e.g., a corporate
`network, the BinGO! router would automatically establish a connection with the secure
`destination in the corporate network using the WAN Partner configuration settings for that WAN
`Partner. If this DNS server did not resolve the address (i.e., because the request did not specify a
`secure destination), the BinGO! router would send the request to a secondary DNS server (e.g.,
`one associated with an ISP designated to be the "default route" in the BinGO! router
`configuration settings).
`
`BinGO also describes a second configuration where the BinGO! router has not been
`configured to have an ISP as a WAN partner. In that configuration, a corporate network is the
`"default" route for the BinGO! router. On page 90, BinGO UG explains:
`
`101
`
`Page 101 of 184
`
`

`
`Request for Reexamination ofU.S. Patent No. 7,490,151
`
`If you have not configured Internet access, but your head office has an
`Internet Service Provider, you can access the Internet via the provider of your
`WAN partner.
`
`Due to the fact that your default route leads all unknown packets to your head
`office, and there another default route in turn sends all unknown packets to its
`Internet provider, you can access the Internet via your partner's network.
`
`In other words, in this configuration, all DNS requests that could not be resolved locally (i.e.,
`computers outside of the LAN) would be routed to a DNS server on a corporate network, where
`the determination would be made if the request was specifying a secure destination (i.e., a
`computer on the corporate network) or a non-secure destination (e.g., a public web site on the
`Internet). In this configuration, a router in the corporate network would receive the DNS
`requests from the BinGO! router. See, e.g., BinGO UG at 91 (Figure 4-3); !d. ("Not only does
`BinGO! avail of a default route, your PC also has one: the gateway. All packets whose
`destinations are not within the local network are sent by your PC to this gateway. BinGO! serves
`as this gateway. As soon as your router receives such a packet, it forwards it in turn to one of its
`known routers (e.g. to the provider or to another partner's network).") BinGO UG further
`explains that settings on the BinGO! router would dictate the handling procedures followed by
`the router and the remote router. For example, on page 199, BinGO UG explains:
`
`7.2.5 Transfer of DNS and WINS Server IP Addresses to WAN Partner
`
`A Domain Name Server (J J DNS) or Windows Internet Name Server
`(WINS) is needed for translating host names and 0 0 NetBIOS names into
`IP addresses (name resolution). Domain Name Servers form a hierarchical
`tree structure. As soon as a request is sent to your primary DNS, it tries to
`execute name resolution using its internal tables. If it cannot find the name, it
`asks a higher-level DNS that it knows.
`
`When you enter a WAN partner in BinGO! you can define whether BinGO!
`sends or answers requests for WINS or DNS IP addresses.
`
`On page 200, BinGO UG shows this configuration being implemented through a service on the
`BinGO! router called "Dynamic Name Server Negotiation":
`
`102
`
`Page 102 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`Primary Domain Name
`Server
`
`IP address of BinGO!'s first Domain Name
`Server (DNS).
`
`Secondary Domain Name
`Server
`
`Primary WINS
`
`IP address of another Domain Name Server.
`
`IP address of BinGO!'s first WINS (Windows
`Internet Name Server) or NBNS (NetBIOS
`Name Server).
`
`Secondary WINS
`
`IP address of another WINS or NBNS.
`
`Table 7-15:
`
`IP .STATIC SETTINGS
`
`Dynamic Name Server
`Negotiation
`
`Defines whether BinGO! receives IP
`addresses for Primary Domain Name Server,
`Secondary Domain Name Server, Primary
`WINS and Secondary WINS from the WAN
`partner or sends them to the WAN partner.
`
`Table 7-16: WAN PARTNER • EDIT •
`
`IP • ADVANCED SETTINGS
`
`Then, on page 201, BinGO UG shows that a WAN partner (e.g., a secure corporate network) can
`be sent DNS requests received by the BinGO! router for resolution and handling:
`
`The Dynamic Name Server Negotiation field contains the following selection
`options:
`
`oft
`
`yes
`
`client (receive)
`
`server (send)
`
`BinGO! does not send or answer requests for
`WINS or DNS IP addresses.
`
`The response is linked to the mode for issuing I
`receiving an IP address (setting under IP Tran(cid:173)
`sit Network in WAN PARTNER • EDIT •
`/P):
`
`•
`
`•
`
`•
`
`::llnl.:iV! senas requests Tor VVIN::i ana LIN::
`P addresses to the WAN partner, if dynam
`'c client is selected.
`
`::llnl.:iVI answers requests Tor VVIN::i anc
`)NS IP addresses from the WAN partner, i
`:Jvnamic server is selected.
`
`::llnl.:iVI aoes not sena or answer request~
`or WINS and DNS IP addresses, if yes 01
`10 is selected.
`
`BinGO! sends requests for WINS and DNS IP
`addresses to the WAN partner.
`
`BinGO! answers requests for WINS and DNS
`IP addresses from the WAN partner.
`
`Table 7-17: Dynamic Name Server Negotiation
`
`Thus, in this second configuration (i.e., where the BinGO! router was configured to connect to a
`router for the corporate network as a WAN Partner, and the BinGO! router has the Dynamic
`Name Server Negotiation variable set to be active), all DNS and WINS requests would be sent to
`theW AN Partner for resolution. See also BinGO UG at 202 ("Proceed as follows if you want
`
`103
`
`Page 103 of 184
`
`

`
`Request for Reexamination of U.S. Patent No. 7,490,151
`
`BinGO! to report the DNS or WINS entered to the WAN partner (Server Mode) or if
`DNS/WINS addresses other than those in the LAN are to be used for connections to the WAN
`partner (Client Mode, e.g. for dialing into an Internet Service Provider).").
`
`BinGO thus shows two configurations in which a data processing device that intercepts
`DNS requests sent by a client determines if the intercepted DNS request corresponds to a secure
`server.
`
`Step (iii) of Claim 7 specifies: "when the intercepted DNS request does not correspond
`to a secure server, forwarding the DNS request to a DNS function that returns an IP address of a
`nonsecure computer; and"
`
`As described above in connection with step (ii), BinGO shows two different
`configurations in which DNS requests from a client computer are sent to a BinGO! router and
`evaluated. In each configuration, a determination is made whether the DNS request specifies a
`secure destination, or a non-secure destination (e.g., a non-secure website on the Internet).
`
`In the first configuration (i.e., where the BinGO! router sends the request to a DNS server
`on the LAN on which the router is located), a determination is made whether the hostname in the
`DNS request matches a hostname in the local secure DNS server. If it does not, then the BinGO!
`router will send the request to a secondary DNS server as designated in its configuration. BinGO
`shows that ordinarily a BinGO! router will be configured to have an internet service provider
`(ISP) as a default WAN partner. See, e.g., BinGO UG at 90 ("Generally, the route to the Internet
`provider is used as the default route, because most unknown packets are bound for the Internet
`anyway (e.g. www.bintec.de)."). In this configuration, then, if a DNS request specifying a non(cid:173)
`secure destination (i.e., one that does n