`
`T
`
`—
`
`Tme of lnventlom
`
`Method for Establishing Secure Communication Link Between
`Computers of Virtual Private Network
`
`——
`
`Payment information:
`
`
`
`Submitted with Payment
`
`Pevmem weeeeueeeeefuliv received in RAM
`Reieeenfirmetien Number
`Deposit Account
`
`190733
`
`Petitioner Apple Inc. — Exhibit 1026, p. 1
`
`
`The Director of the USPTO is hereby authorized to charge indicated fees and credit any overpayment as follows:
`
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.16 and 1.17
`
`File Listing:
`____:+____
`
`
`
`
`
`
`
`Petitioner Apple Inc. - Exhibit 1026, p. 1
`
`
`
`Number
`
` Document
`Document Description % <a'?2%:T>
`
` fl
` 007170cont1.pdf
`
`Multipart Description/PDF files in .zip description
`
`-
`0 79
`
`1
`
`78
`
`79
`
`
`
`
`
` 2 OathorDeclarationfiled
`
`007170dec.pdf
`
`101669 I
`
`Information:
`
`Information:
`
`Information:
`
`
`
`
`
`
`
`
`
`4
`ApplicationDataSheet
`ADS.pdf
`1121183 I
`
` Information:
`
`
`
`Fee Worksheet (PTO-06)
`
`
`Total Files Size (in bytes )2
`
`2200860
`
`
`
`Petitioner Apple Inc. — Exhibit 1026, p. 2
`
`Petitioner Apple Inc. - Exhibit 1026, p. 2
`
`
`
`This Acknowledgement Receipt evidences receipt on the noted date by the USPTO of the indicated documents,
`characterized by the applicant, and including page counts, where applicable.
`It serves as evidence of receipt
`similar to a Post Card, as described in MPEP 503.
`
`4
`New Applications Under 35 U.S.C. 111
`If a new application is being filed and the application includes the necessary components for a filing date (see
`37 CFR 1.53(b)-(d) and MPEP 506), a Filing Receipt (37 CFR 1.54) will be issued in due course and the date
`shown on this Acknowledgement Receipt will establish the filing date of the application.
`
`National Stage of an International Application under 35 U.S.C. 371
`If a timely submission to enter the national stage of an international application is compliant with the conditions
`of 35 U.S.C. 371 and other applicable requirements a Form PCTIDOIEOIQO3 indicating acceptance of the
`application as a national stage submission under 35 U.S.C. 371 will be issued in addition to the Filing Receipt,
`in due course.
`
`New International Application Filed with the USPTO as a Receiving Office
`If a new international application is being filed and the international application includes the necessary
`components for an international filing date (see PCT Article 11 and MPEP 1810), a Notification of the
`International Application Number and of the International Filing Date (Form PCTlROl105) will be issued in due
`course, subject to prescriptions concerning national security, and the date shown on this Acknowledgement
`Receipt will establish the international filing date of the application.
`
`Petitioner Apple Inc. — Exhibit 1026, p. 3
`
`Petitioner Apple Inc. - Exhibit 1026, p. 3
`
`
`
`Electronic Acknowledgement Receipt
`
`T
`
`—
`
`Tme of lnventlom
`
`Method for Establishing Secure Communication Link Between
`Computers of Virtual Private Network
`
`——
`
`Payment information:
`
`
`
`Submitted with Payment
`
`Pevmem weeeeueeeeefuliv received in RAM
`Reieeenfirmetien Number
`Deposit Account
`
`190733
`
`Petitioner Apple Inc. — Exhibit 1026, p. 4
`
`
`The Director of the USPTO is hereby authorized to charge indicated fees and credit any overpayment as follows:
`
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.16 and 1.17
`
`File Listing:
`____:+____
`
`
`
`
`
`
`
`Petitioner Apple Inc. - Exhibit 1026, p. 4
`
`
`
`Number
`
` Document
`Document Description % <a'?2%:T>
`
` fl
` 007170cont1.pdf
`
`Multipart Description/PDF files in .zip description
`
`-
`0 79
`
`1
`
`78
`
`79
`
`
`
`
`
` 2 OathorDeclarationfiled
`
`007170dec.pdf
`
`101669 I
`
`Information:
`
`Information:
`
`Information:
`
`
`
`
`
`
`
`
`
`4
`ApplicationDataSheet
`ADS.pdf
`1121183 I
`
` Information:
`
`
`
`Fee Worksheet (PTO-06)
`
`
`Total Files Size (in bytes )2
`
`2200860
`
`
`
`Petitioner Apple Inc. — Exhibit 1026, p. 5
`
`Petitioner Apple Inc. - Exhibit 1026, p. 5
`
`
`
`This Acknowledgement Receipt evidences receipt on the noted date by the USPTO of the indicated documents,
`characterized by the applicant, and including page counts, where applicable.
`It serves as evidence of receipt
`similar to a Post Card, as described in MPEP 503.
`
`4
`New Applications Under 35 U.S.C. 111
`If a new application is being filed and the application includes the necessary components for a filing date (see
`37 CFR 1.53(b)-(d) and MPEP 506), a Filing Receipt (37 CFR 1.54) will be issued in due course and the date
`shown on this Acknowledgement Receipt will establish the filing date of the application.
`
`National Stage of an International Application under 35 U.S.C. 371
`If a timely submission to enter the national stage of an international application is compliant with the conditions
`of 35 U.S.C. 371 and other applicable requirements a Form PCTIDOIEOIQO3 indicating acceptance of the
`application as a national stage submission under 35 U.S.C. 371 will be issued in addition to the Filing Receipt,
`in due course.
`
`New International Application Filed with the USPTO as a Receiving Office
`If a new international application is being filed and the international application includes the necessary
`components for an international filing date (see PCT Article 11 and MPEP 1810), a Notification of the
`International Application Number and of the International Filing Date (Form PCTlROl105) will be issued in due
`course, subject to prescriptions concerning national security, and the date shown on this Acknowledgement
`Receipt will establish the international filing date of the application.
`
`Petitioner Apple Inc. — Exhibit 1026, p. 6
`
`Petitioner Apple Inc. - Exhibit 1026, p. 6
`
`
`
`Cont. of Appln. No. 10/702,486
`
`METHOD FOR ESTABLISHING SECURE COMMUNICATION LINK BETWEEN
`
`COMPUTERS OF VIRTUAL PRIVATE NETWORK
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`This application claims priority from and is a divisional patent application of co-pending
`U.S. application serial number 09/558,209, filed April 26, 2000, which is a continuation-in-part
`
`patent application of previously-filed U.S. application serial number 09/504,783,
`
`filed on
`
`February 15, 2000, now U.S. Pat. No._6,502,135, issued December 31, 2002, which claims
`
`priority from and is a continuation-in-part patent application of previously-filed, U.S. application
`
`serial number 09/429,643, filed on October 29, 1999. The ‘subject matter of U.S. application
`
`serial number 09/429,643, which is bodily incorporated herein, derives from provisional U.S.
`
`application numbers 60/106,261 (filed October 30, 1998) and 60/137,704 (filed June 7, 1999).
`
`The present application is also related to U.S. application serial number 09/558,210, filed April
`
`26, 2000, and which is incorporated by referenceherein.
`
`BACKGROUND OF THE INVENTION
`
`A tremendous variety of methods have been proposed and implemented to provide
`
`security and anonymity for communications over the Internet. The variety stems, in part, from‘
`
`the different needs of different Internet users. A basic heuristic framework to aid in discussing
`
`these different security techniques is illustrated in FIG. 1. Two terminals, an originating terminal
`100 and a destination terminal 110 are in communication over the Internet. It is desired for the
`
`communications to be secure, that is, immune to eavesdropping. For example, terminal 100 may
`transmit secret information to terminal 110 over the Internet 107. Also, it may be desired to
`
`prevent an eavesdropper from discovering that terminal 100 is in communication with terminal
`
`11’0. For example, if terminal 100 is a user and terminal 110 hosts a web site, terminal 100’s user
`
`may not want anyone in the intervening networks to know what web sites he is "visiting."
`Anonymity would thus be an issue, for example, for companies that want to keep their market
`research interests private and thus would prefer to prevent outsiders from knowing which web-
`
`sites or other Internet resources they are “visiting.” These two security issues may be called data
`
`. security and anonymity, respectively.
`
`Data security is usually tackled using some form of data encryption. An encryption key
`
`48 is known at both the originating and terminating terminals 100 and 110. The keys may be
`
`Petitioner Apple Inc. — Exhibit 1026, p. 7
`
`Petitioner Apple Inc. - Exhibit 1026, p. 7
`
`
`
`Cont. of Appln. No. 10/702,486
`
`private and public at the originating and destination terminals 100 and 110, respectively or they
`
`may be symmetrical keys (the same key is used by both parties to encrypt and decrypt). Many
`
`encryption methods are known and usable in this context.
`
`To hide traffic from a local administrator or ISP, a user can employ a local proxy server
`
`in communicating over an encrypted channel with an outside proxy such that
`
`the local
`
`administrator or ISP only sees the encrypted traffic. Proxy servers prevent destination servers
`
`from determining the identities of the originating clients. This system employs an intermediate
`
`server interposed between client and destination server. The destination server sees only the
`
`Internet Protocol (IP) address of the proxy server and not the originating client. The target server
`
`only sees the address of the outside proxy. This scheme relies on a trusted outside proxy server.
`Also, proxy schemes are vulnerable to traffic analysis methods, of determining identities of
`
`transmitters and receivers. Another important limitation of proxy servers is that the server knows
`
`the identities of both calling and called parties. In many instances, an originating terminal, such
`
`as terminal A, would prefer to keep its identity concealed from the proxy, for example, if the
`
`proxy server is provided by an Internet service provider (ISP).
`
`To defeat traffic analysis, a scheme called Chaum’s mixes employs a proxy server that
`
`transmits and receives fixed length messages, including dummy messages. Multiple originating
`
`terminals are connected through a mix (a server) to multiple target servers. It is difficult to tell
`
`which of the originating terminals are communicating to which of the connected target servers,
`
`and the dummy messagesconfuse eavesdroppers’ efforts to detect communicating pairs by
`
`analyzing traffic. A drawback is that there is a risk that the mix server could be compromised.
`
`One way to deal with this risk is to spread the trust among multiple mixes. If one mix is
`
`compromised, the identities of the originating and target terminals may remain concealed. This
`
`strategy requires a number of alternative mixes so that
`
`the intermediate servers interposed
`
`between the originating and target terminals are not determinable except by compromising more
`
`than one mix. The strategy wraps the message with multiple layers of encrypted addresses. The
`
`first mix in a sequence can decrypt only the outer layer of the message to reveal the next
`
`destination mix in sequence. The second mix can decrypt the message to reveal the next mix and
`
`so on_. The target server receives the message and, optionally, a multi-layer encrypted payload
`
`containing return information to send data back in the same fashion. The only way to defeat such
`
`Petitioner Apple Inc. — Exhibit 1026, p. 8
`
`Petitioner Apple Inc. - Exhibit 1026, p. 8
`
`
`
`Cont. of Appln. No. 10/702,486
`
`a mix scheme is to collude among mixes. If the packets are all fixed-length and intermixed with
`
`dummy packets, there is no way to do any kind of traffic analysis.
`
`Still another anonymity technique, called ‘crowds,’ protects the identity of the originating
`
`terminal from the intermediate proxies by providing that originating terminals belong to groups
`
`of proxies called crowds. The crowd proxies are interposed between originating and target
`
`terminals. Each proxy through which the message is sent is randomly chosen by an upstream
`
`proxy. Each intermediate proxy can send the message either to another randomly chosen proxy
`
`in the “crowd” or to the destination‘. Thus, even crowd members cannot determine if a preceding
`proxy is the originator of the message or if it was simply passed from another proxy.
`
`ZKS (Zero-Knowledge Systems) Anonymous IP Protocol allows users to select up to any
`
`of five different pseudonyms, while desktop software encrypts outgoing traffic and wraps it in
`
`User Datagram Protocol (UDP) packets. The first server in a 2+-hop system gets the UDP
`
`packets, strips off one 1
`
`ayer of encryption to add another, then sends the traffic to the next
`
`server, which strips off yet another layer of encryption and addsa new one. The user is permitted
`
`to control the number of hops. At the final server, traffic is decrypted with an untraceable IP
`
`address. The technique is called onion-routing. This method can be defeated using traffic
`
`analysis. For a simple example, bursts of packets from a user during low-duty periods can reveal
`
`the identities of sender and receiver.
`
`Firewalls attempt to protect LANs from unauthorized access and hostile exploitation or
`
`damage to computers connected to the LAN. Firewalls provide a server through which all access
`
`to the LAN must pass. Firewalls are centralized systems that require administrative overhead to
`
`maintain. They can be compromised by virtual-machine applications (“applets”). They‘ instill a
`
`false sense of security that leads to security breaches for example by users sending sensitive
`
`information to servers outside the firewall or encouraging use of modems to sidestep the firewall
`
`security. Firewalls are not useful for distributed systems such as business travelers, extranets,
`
`small teams, etc.
`
`SUMMARY OF THE INVENTION
`
`A secure mechanism for communicating over the intemet, including a protocol referred
`
`to as the Tunneled Agile Routing Protocol (TARP), uses a unique two-layer encryption format
`
`and special TARP routers. TARP routers are similar in function to regular IP routers. Each
`
`TARP router has one or more IP addresses and uses normal IP protocol to send IP packet
`
`Petitioner Apple Inc. — Exhibit 1026, p. 9
`
`Petitioner Apple Inc. - Exhibit 1026, p. 9
`
`
`
`Cont. of Appln. No. 10/702,486
`
`messages (“packets” or “datagrams”). The IP packets exchanged between TARP terminals via
`
`TARP routers are actually encrypted packets whose true destination address is concealed except
`
`to TARP routers and servers. The normal or “clear” or “outside” IP header attached to TARP IP
`
`packets contains only the address of a next hop router or destination server. That is, instead of
`
`indicating a final destination in the destination field of the IP header, the TARP packet’s IP
`
`header always points to a next-hop in a series of TARP router hops, or to the final destination.
`
`This means there is no overt indication from an intercepted TARP packet of the true destination
`
`of the TARP packet since the destination could always be next-hop TARP router as well as the
`
`V final destination.
`
`Each TARP packet’s true destination is concealed behind a layer of encryption generated
`
`using a link key. The link key is the encryption key used for encrypted communication between
`
`the hops intervening between an originating TARP terminal.and a destination TARP terminal".
`Each TARP router can remove the outer layer of encryption to reveal the destination router for
`
`each TARP packet. To identify the link key needed to decrypt the outer layer of encryption of a
`
`TARP packet, a receiving TARP or routing terminal may identify the transmitting terminal by
`
`the sender/receiver IP numbers in the cleartext IP header.
`
`Once the outer layer of encryption is removed, the TARP router determines the final
`
`_ destination. Each TARP packet 140 undergoes a minimum number of hops to help foil traffic
`
`analysis. The hops may be chosen at random or by a fixed value. As a result, each TARP packet
`
`may make random trips among a number of geographically disparate routers before reaching its
`
`destination. Each trip is highly likely to be different for each packet composing a given message
`
`because each trip is independently randomly determined. This feature is called agile routing. The
`
`fact that different packets take different routes provides distinct advantages by making it difficult
`
`for an interloper to obtain all the packets forming an entire multi—packet message. The associated
`
`advantages have to do with the inner layer of encryption discussed below. Agile routing is
`
`combined with another feature that furthers this purpose; a feature that ensures that any message
`
`is broken into multiple packets.
`
`The IP address of a TARP router can be changed, a feature called IP agility. Each TARP
`
`router, independently or under direction from another TARP terminal or router, can change its IP
`
`address. A separate, unchangeable identifier or address is also defined. This address, called the
`
`TARP address, is known only to TARP routers and terminals and may be correlated at any time
`
`Petitioner Apple Inc. — Exhibit 1026, p. 10
`
`Petitioner Apple Inc. - Exhibit 1026, p. 10
`
`
`
`Cont. ofAppln. No. 10/702,486
`
`by a TARP router or a 'l§rARP terminal using a Lookup Table (LUT). When a TARP router or
`
`terminal changes its IP address, it updates the other TARP routers and terminals which in turn
`
`update their respective LUTs.
`
`The message payload is hidden behind an inner layer of encryption in the TARP packet
`
`that can only be unlocked using a session key. The session key is not available to any of the
`
`intervening TARP routers. The session key is used to decrypt the payloads of the TARP packets
`
`permitting the data stream to be reconstructed.
`
`Communication may be made private using link and session keys, which in turn may be
`
`shared and used according to any desired method. For example, public/private keys or symmetric
`
`keys may be used.
`
`To transmit a data stream, a TARP originating terminal constructs a series of TARP
`
`packets from a series of IP packets generated by a network (IP) layer process. (Note that the
`terms “network layer,” “data link layer,” “application layer,” etc. used in this specification
`
`correspond to the Open Systems Interconnection (OSI) network terminology.) The payloads of
`
`these packets are assembled into a block and chain-block encrypted using the session key. This
`
`assumes, of course, that all the IP packets are destined for the same TARP terminal. The block is
`
`then interleaved and the interleaved encrypted block is broken into a series of payloads, one for
`
`each TARP packet to be generated. Special TARP headers IPT are then added to each payload
`using the IP headers from the data stream packets. The TARP headers can be identical to normal
`
`IP headers or customized in some way. They should contain a formula or data for deinterleaving
`
`the data at the destination TARP terminal, a time-to-live (TTL) parameter to indicate the number
`
`of hops still to be executed, a data type identifier which indicates whether the payload contains,
`
`for example, TCP or UDP data, the sender’s TARP address, the destination TARP address, and
`
`an indicator as to whetherithe packet contains real or decoy data or a formula for filtering out
`
`decoy data if decoy data is spread in some way through the TARP payload data.
`Note that although chain-block encryption is discussed here with reference to the session
`
`key, any encryption method may be used. Preferably, as in chain block encryption, a method
`
`should be used that makes unauthorized decryption difficult without an entire result of the
`
`encryption process. ‘Thus, by separating the encrypted block among multiple packets and making
`
`it difficult for an interloper to obtain access to all of such packets,
`
`the contents of the
`
`communications are provided an extra layer of security.
`
`Petitioner Apple Inc. — Exhibit 1026, p. 11
`
`Petitioner Apple Inc. - Exhibit 1026, p. 11
`
`
`
`Cont. of Appln. No. 10/702,486
`
`Decoy or dummy data can be added to a stream to help foil traffic analysis by reducing
`
`the peak-to-average network load. It may be desirable to provide the TARP process with an
`
`ability to respond to the time of day or other criteria to generate more decoy data during low
`
`traffic periods so that communication bursts at one point
`in the Internet cannot be tied to
`communication bursts at another point to reveal the communicating endpoints. l
`
`Dummy data also helps to break" the data into a larger ‘number of inconspicuously-sized
`
`packets permitting the interleave window size to be increased while maintaining a reasonable
`
`size for each packet. (The packet size can be a single standard size or selected from a fixed range
`
`of sizes.) One primary reason for desiring for each message to be broken into multiple packets is
`
`apparent if a chain block encryption scheme is used to form the first encryption layer prior to
`
`interleaving. A single block encryption may be applied to portion, or entirety, of a message, and
`
`that portion or entirety then interleaved into a number of separate packets. Considering the agile -
`
`IP routing of the packets, and the attendant difficulty of reconstructing an entire sequence of
`
`packets to form a single block-encrypted message element, decoy packets can significantly
`
`increase the difficulty of reconstructing an entire data stream.
`
`The above scheme may be implemented entirely by processes operating between the data
`
`link layer and the network layer of each server or terminal participating in the TARP system.
`
`Because the encryption system described above is insertable between the data link and network"
`
`layers, the processes involved in supporting the encrypted communication may be completely
`transparent to processes at the IP (network) layer and above. The TARP processes may also be
`
`completely transparent to the data link layer processes as well. Thus, no operations at or above
`
`the Network layer, or at or below the data link layer, are affected by the insertion of the TARP
`
`stack. This provides additional security to all processes at or above the network layer, since the
`
`difficulty of unauthorized penetration of the network layer (by, for example, a hacker) is
`
`increased substantially. Even newly developed servers running at the session layer leave all
`
`‘processes below the session layer vulnerable to attack. Note that in this architecture, security is
`
`distributed. That is, notebook computers used by executives on the road, for example, can
`
`communicate over the Internet without any compromise in security.
`
`IP address changes made by TARP terminals and routers can be done at regular intervals,
`
`at random intervals, or upon detection of “attacks.” The variation of IP addresses hinders traffic
`
`analysis that might reveal which computers are communicating, and also provides a degree of
`
`Petitioner Apple Inc. — Exhibit 1026, p. 12
`
`Petitioner Apple Inc. - Exhibit 1026, p. 12
`
`
`
`Cont. of Appln. No. 10/702,486
`
`immunity from attack. The level of immunity from attack is roughly proportional to the rate at
`
`which the IP address of the host is changing.
`
`As mentioned, IP addresses may be changed in response to attacks. An attack may be
`
`revealed, for example, by a regular series of messages indicating that a router is being probed in
`
`some way. Upon detection of an attack, the TARP layer process may respond to this event by
`
`changing its IP address. In addition, it may create a subprocess that maintains the original IP
`
`address and continues interacting with the attacker in some manner.
`
`Decoy packets may be generated by each TARP terminal on some basis determined by an
`algorithm. For example, the algorithm may be a random one which calls for the generation of a
`
`packet on a random basis when the terminal
`
`is idle. Alternatively,
`
`the algorithm may be
`
`responsive to time of day or detection of low traffic to generate more decoy packets during low
`
`traffic times. Note that packets are preferably generated in groups, rather than one by one, the
`
`groups being sized to simulate real messages. In addition, so that decoy packets may be inserted
`
`in normal TARP message streams, the background loop may have a latch that makes it more
`
`likely to insert decoy packets when a message stream is being received. Alternatively, if a large
`
`number of decoy packets is received along with regular TARP packets,
`the algorithm may
`increase the rate of dropping of decoy packets rather than forwarding them. The result of
`
`dropping and generating decoy packets in this way is to make the apparent incoming message
`
`size different from the apparent outgoing message size to help foil traffic analysis.
`
`In various other embodiments of the invention, a scalable version of the system may be
`
`constructed in which a plurality of IP addresses are preassigned to each pair of communicating
`
`. nodes in the network. Each pair of nodes agrees upon an algorithm for “hopping” between IP
`
`addresses (both sending and receiving), such that an eavesdropper sees apparently continuously
`
`random IP address pairs (source and destination) for packets transmitted between the pair.
`
`Overlapping or “reusable” IP addresses may be allocated to different users on the same subnet,
`
`since each node merely verifies that a particular packet includes a valid source/destination pair
`
`from the agreed-upon algorithm. Source/destination pairs are preferably not reused between any
`
`two nodes during any given end-to-end session, though limited IP block sizes or lengthy sessions
`
`might require it.
`
`Further improvements described in this continuation-in-part application include: (1) a
`
`load balancer
`
`that distributes packets across different
`
`transmission paths according to
`
`Petitioner Apple Inc. — Exhibit 1026, p. 13
`
`Petitioner Apple Inc. - Exhibit 1026, p. 13
`
`
`
`Cont. of Appln. No. 10/702,486
`
`trans1nission- path quality; (2) a DNS proxy server that transparently creates a virtual private
`network in response to a domain name inquiry; (3) a large-to-small link bandwidth management
`
`feature that prevents denial—of-service attacks at system chokepoints; (4) a traffic limiter that
`
`regulates incoming packets by limiting the rate at which a transmitter can be synchronized with a
`receiver; and (5) a signaling synchronizer that allows a large number of nodes to communicate
`
`with a central node by partitioning the communication function between two separate entities
`
`The present
`
`invention provides key technologies for implementing a secure virtual
`
`Internet by using a new agile network protocol that is built on top of the existing Internet
`
`protocol (IP). The secure virtual Internet works over the existing Internet infrastructure, and
`
`interfaces with client applications the same way as the existing Internet. The key technologies
`
`provided by the present invention that support the secure virtual Internet include a “one-click”
`
`and “no-click” technique to become part of the secure virtual Internet, a secure domain name
`
`service (SDNS) for the secure virtual Internet, and a new approach for interfacing specific client
`
`applications onto the secure virtual Internet. According to the invention, the secure domain
`name service interfaces with existing applications, in addition to providing a way to register and
`serve domain names and addresses.
`
`According to one aspect of the present invention, a user can conveniently establish a
`VPN using a “one-click” or a “no—click” technique without being required to enter user
`
`identification information, a password and/or an encryption key for establishing a VPN. The
`
`advantages of the present
`
`invention are provided by a method for establishing a secure
`
`communication link between a first computer and a second computer over a computer network,
`
`such as the Internet.
`
`In one embodiment, a secure communication mode is enabled at a first
`
`computer without a user entering any cryptographic information for establishing the secure
`
`communication mode of communication, preferably by merely selecting an icon displayed on the
`
`first computer. Alternatively, the secure communication mode of communication can be enabled
`
`by entering a command into the first computer.
`
`Then, a secure communication link is
`
`established between the first computer and a second computer over a computer network based on
`
`the enabled secure communication mode of communication. According to the invention, it is
`
`determined whether a secure communication software module is stored on the first computer in
`
`response to the step of enabling the secure communication mode of communication. A
`
`predetermined computer network address is then accessed for loading the secure communication
`
`Petitioner Apple Inc. — Exhibit 1026, p. 14
`
`Petitioner Apple Inc. - Exhibit 1026, p. 14
`
`
`
`Cont. of Appln. No. 10/702,486
`
`software module when the software module is not stored on the first computer. Subsequently,
`
`the proxy software module is stored in the first computer. The secure communication link is a
`
`virtual private network communication link over the computer network. Preferably, the virtual
`
`private network can be based on inserting into each data packet one or more data values that vary
`
`according to a pseudo-random sequence. Alternatively, the virtual private network can be based
`
`on a computer network address hopping regime that is used to pseudorandomly change computer
`
`network addresses or other data values in packets transmitted between the first computer and the
`
`second computer, such that the second computer compares the data values in each data packet
`
`transmitted between the first computer and the second computer to a moving window of valid
`
`values. Yet another alternative provides that the virtual private network can be based on a
`
`comparison between a discriminator field in each data packet to a table of valid discriminator
`
`fields maintained for the first computer.
`
`According to another aspect of the invention, a command is entered to define a setup
`
`parameter
`
`associated with the
`
`secure
`
`communication link mode of communication.
`
`Consequently,
`
`the
`
`secure
`
`communication mode
`
`is
`
`automatically established when a
`
`communication link is established over the computer network.
`
`The present invention also provides a computer system having a communication link to a
`
`computer network, and a display showing a hyperlink for establishing a virtual private network
`
`through the computer network. When the hyperlink for establishing the virtual private network
`
`is selected, a virtual private network is established over the computer network. A non-standard
`
`top-level domain name is then sent over the virtual private network communication to a
`
`predetermined computer network address, such as a computer network address for a secure
`
`domain name service (SDNS).
`
`The present invention provides a domain name service that provides secure computer
`
`network addresses for secure, non-standard top-level domain names. The advantages of the
`
`present invention are provided by a secure domain name service for a computer network that
`
`includes a portal connected to a computer network, such as the Internet, and a domain name
`
`database connected to the computer network through the portal. According to the invention, the
`
`portal authenticates a query for a secure computer network address, and the domain name
`
`database stores secure computer network addresses for the computer network. Each secure
`
`Petitioner Apple Inc. — Exhibit 1026, p. 15
`
`Petitioner Apple Inc. - Exhibit 1026, p. 15
`
`
`
`Cont. of Appln. No. 10/702,486
`
`computer network address is based on a non-standard top-level domain name, such as .scom,
`
`.sorg, .snet, .snet, .sedu, .smil and .sint.
`
`The present invention provides a way to encapsulate existing application network traffic
`
`at
`
`the application layer of . a client computer so that
`
`the ‘client application can securely
`
`communicate with a server protected by an agile network protocol. The advantages of the
`
`present invention are provided by a method for communicating using a private communication
`
`link between a client computer and a server computer over a computer network, such as the
`
`Internet. According to the invention, an information packet is sent from the client computer to
`the server computer over the computernetwork. The information packet contains data that is
`inserted into the payload portion of the packet at the application layer of the client computer and
`
`is used for forming a virtual private connection between the client computer and the server
`
`computer. The modified information packet can be sent through a firewall before being sent
`
`over the computer network to the server computer and by working on-top of existing protocols
`
`(i.e., UDP, ICMP and TCP), the present invention more easily penetrates the firewall. The
`information packet is received at a kernel, layer of an operating system on the server side.
`It is
`then determined at the kernel layer of the operating system on the host computer whether the
`
`information packet contains the data that