McDermott
`Will &Emery
`
`Boston Brussels Chicago Diisseldon‘ Houston London Los Angeles Miami Milan
`Munich New York Orange County Paris Rome Silicon Valley Washington, D.C.
`
`Strategic alliance with MWE China Law Offices (Shanghai)
`
`TObY H- KUSme|’l P-C-
`Allomel’ at Law
`tkusmer@mwe.com
`+1 617 535 4065
`
`December 23, 2011
`
`CERTIFICATE OF ELECTRONIC TRANSMISSION
`
`I hereby certify that this correspondence is being
`electronically transmitted to the United States Patent and
`Trademark Office on December 23, 201 1
`/Jessica Brown/
`Jessica Brown
`
`Commissioner for Patents
`
`Mail Stop PATENT APPLICATION
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`Re:
`
`U.S. Continuation Patent Application
`Attorney Docket No. 77580-151(VRNK-1CP3CN-FT1)
`SYSTEM AND METHOD EMPLOYING AN AGILE NETWORK PROTOCOL
`
`FOR SECURE COMMUNICATIONS USING SECURE DOMAIN NAMES
`
`Subject:
`
`Transmitting Patent Application for Track I Prioritized Examination
`
`Dear Sir/Madam:
`
`We enclose for filing the patent application for Track I Prioritized Examination of:
`
`Inventors:
`
`Victor Larson (Fairfax, VA); Robert Dunham Short III (Leesburg, VA);
`Edmond Colby Munger (Crownsville, MD); Michael Williamson (South
`Riding, VA)
`
`Assignee:
`
`VIRNETX, INC.
`
`For:
`
`SYSTEM AND METHOD EMPLOYING AN AGILE NETWORK
`
`PROTOCOL FOR SECURE COMMUNICATIONS USING SECURE
`
`DOMAIN NAMES
`
`This patent application is a continuation of U.S. Application No. 13/049,552, filed March
`16, 2011, which is a continuation ofU.S. Application No. 11/840,560, filed August 17, 2007,
`now U.S. Patent No. 7,921,211, issued April 5, 2011, which is a continuation of U.S. Application
`No. 10/714,849, filed November 18, 2003, now U.S. Patent No. 7,418,504, issued August 26,
`2008, which is a continuation of U.S. Application No. 09/558,210, filed April 26, 2000, now
`abandoned, which is a continuation-in-part of U.S. Application No. 09/504,783, filed on
`February 15, 2000, now U.S. Patent No. 6,502,135, issued December 31, 2002, which is a
`continuation-in-part of U.S. Application No. 09/429,643, filed October 29, 1999, now U.S.
`Patent No. 7,010,604, issued March 07, 2006, which derives from U.S. Provisional Application
`Nos. 60/106,261, filed October 30, 1998, and 60/137,704, filed June 7, 1999, and includes:
`
`U.S. practice conducted through McDermott Will & Emery LLP.
`
`28 State Street Boston Massachusetts 02109-1775 Telephone: +1 617 535 4000 Facsimile: +1 617 535 3800 www.mwe.com
`
`DM_US 31 l49502—l.077580.0l5l
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1
`
`

`
`Commissioner for Patents
`
`December 23, 2011
`
`Page 2
`
`Certification and Request for Prioritized Examination (Track I)
`
`Ninety-three (93) pages of specification, claims, and abstract;
`
`Forty (40) sheets of drawings (Figs. l-37);
`
`Application Data Sheet (6 pages);
`
`Declaration and Petition from parent application no. l0/7l4,849, signed by the
`inventor (6 pages)
`
`0
`
`Power of Attorney and Statement under 37 CFR 3.73(b) from parent application
`no. 1 1/840,560, signed by the assignee
`
`The filing fee has been calculated as shown below:
`
` NO. OF
`
`CLAIMS
`
`28
`
`Total Claims
`
`Independent Claims
`
`2
`
`-3
`
`EXTRA
`CLAIMS
`
`Large Entity
`RATE
`
`AMOUNT
`
`8
`
`0
`
`$60
`
`$250
`
`Multiple Dependent Claim(s)
`
`Basic Filing Fee
`
`Search Fee
`
`Examination Fee
`
`$480.00
`
`$0.00
`
`$0.00
`
`$380.00
`
`$620.00
`
`$250.00
`
`$310.00
`
`$300.00
`
`$4800.00
`
`$130.00
`
`$7270.00
`
`Utility Application Size Fee for 50 additional sheets that exceed 100 sheets
`
`Publication Fee
`
`Prioritized Examination Fee (Track I) under 37 C.F.R. 1.17(c)
`
`Processing Fee 37 C.F.R. 1.17(i)
`
`Total of Above Calculations
`
`
`
`IX]
`
`IXI
`
`IXI
`
`Please charge my Deposit Account No. 501 133 in the amount of $7270.00. Please
`reference attorney docket no. 775 80- l 5 l(VRNK- l CP3CN-FT l).
`The Commissioner is hereby authorized to charge payment of the following fees
`associated with this communication or credit any overpayment to Deposit Account
`No. 501 l33.
`
`IX] Any additional filing fees required under 37 CFR l.l6.
`The Commissioner is hereby authorized to charge payment of the following fees during
`the pendency of this application or credit any overpayment to Deposit Account
`No. 501 l33.
`
`IX] Any patent application processing fees under 37 CFR l.l7.
`IXI Any filing fees under 37 CFR l.l6 for presentation of extra claims.
`
`DM_US 3 l l49502—l.077580.0l5l
`
`Petitioner Apple Inc. — Exhibit 1002, p. 2
`
`Petitioner Apple Inc. - Exhibit 1002, p. 2
`
`

`
`Commissioner for Patents
`
`December 23, 2011
`
`Page 3
`
`Please return the Official Filing Receipt to the undersigned.
`
`Respectfully submitted,
`MCDERMOTT WILL & EMERY LLP
`
`CUSTOMER NUMBER 23630
`
`/Toby H. Kusmer/
`Toby H. Kusmer, P.C., Reg. No. 26,418
`
`600 13th Street, N.W.
`
`Washington, DC 20005-3096
`Telephone: (617) 535-4000
`Facsimile: (617)535-3800
`Date: December 23, 2011
`
`DM_US 31149502—1.077580.0151
`
`Petitioner Apple Inc. — Exhibit 1002, p. 3
`
`Petitioner Apple Inc. - Exhibit 1002, p. 3
`
`

`
`Doc Code: TRACK1.REQ
`
`Document Description: TrackOne Request
`
`PTO/SB/424 (O9-11)
`
`CERTIFICATION AND REQUEST
`
`FOR PRIORITIZED EXAMINATION (TRACK I) (Page 1 of 1)
`
`First Named
`
`IIQE/I:n(E(0n_
`
`Nonprovisional Application
`-
`Number (if known):
`LARSON, VICIOV
`SYSTEM AND METHOD EMPLOYING AN AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS USING SECURE DOMAIN NAMES
`
`APPLICANT HEREBY CERTIFIES THE FOLLOWING AND REQUESTS PRIORITIZED EXAMINATION
`
`(TRACK I) FOR THE ABOVE-IDENTIFIED APPLICATION.
`
`1.
`
`(a) The application is an original nonprovisional utility application filed under 35 U.S.C. 111(a).
`This certification and request is being filed with the utility application via EFS-Web.
`
`OR
`
`(b) The application is an original nonprovisional plant application filed under 35 U.S.C. 111(a).
`This certification and request is being filed with the plant application in paper. (Note: Plant
`applications cannot be filed via EFS-Web.)
`
`Note: The following are excluded from the Track I program: design applications, provisional
`applications, national stage applications, PCT international applications, reissue applications, and
`reexamination proceedings.
`
`The following fees (in amounts consistent with the current fee schedule available at
`(1) basic
`httg://w\wv'.uspto.govlabout/officeslcfo/flnance/fees.isg) are filed with the application:
`filing fee; (2) search fee; (3) examination fee; (4) any required excess claims fees; (5) any required
`application size fee; (6) publication fee; (7) processing fee (Track I) set forth in 37 CFR 1.17(i); and
`(8) prioritized examination fee (Track I) set forth in 37 CFR 1.17(c).
`
`An executed oath or declaration under 37 CFR 1.63 is filed with the application.
`
`The application contains or is amended to contain no more than four independent claims and no
`more than thirty total claims, and no multiple dependent claims.
`
`mature /Toby H. Kusmer/
`
`Name
`Print/T e
`
`dToby H. Kusmer, P.C.
`
`Date 2011-12-23
`
`Practitioner
`Re istration Number
`
`26,418
`
`Note: Signatures of all the inventors or assignees of record of the entire interest or their representative(s) are required in accordance with
`37 CFR 1.33 and 11.18. Please see 37 CFR 1.4(d) for the form of the signature. If necessary, submit multiple forms for more than one
`signature, see below*.
`
`Fl
`
`*Total of
`
`1
`
`forms are submitted.
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4
`
`

`
`Privacy Act Statement
`
`The Privacy Act of 1974 (P.L. 93-579) requires that you be given certain information in connection with your
`submission of the attached form related to a patent application or patent. Accordingly, pursuant to the requirements of
`the Act, please be advised that: (1) the general authority for the collection of this information is 35 U.S.C. 2(b)(2); (2)
`furnishing of the information solicited is voluntary; and (3) the principal purpose for which the information is used by the
`U.S. Patent and Trademark Office is to process and/or examine your submission related to a patent application or
`patent.
`If you do not furnish the requested information, the U.S. Patent and Trademark Office may not be able to
`process and/or examine your submission, which may result in termination of proceedings or abandonment of the
`application or expiration of the patent.
`
`The information provided by you in this form will be subject to the following routine uses:
`
`1. The information on this form will be treated confidentially to the extent allowed under the Freedom of
`Information Act (5 U.S.C. 552) and the Privacy Act (5 U.S.C 552a). Records from this system of records may
`be disclosed to the Department of Justice to determine whether disclosure of these records is required by the
`Freedom of Information Act.
`
`2. A record from this system of records may be disclosed, as a routine use, in the course of presenting evidence
`to a court, magistrate, or administrative tribunal, including disclosures to opposing counsel in the course of
`settlement negotiations.
`3. A record in this system of records may be disclosed, as a routine use, to a Member of Congress submitting a
`request involving an individual, to whom the record pertains, when the individual has requested assistance from
`the Member with respect to the subject matter of the record.
`4. A record in this system of records may be disclosed, as a routine use, to a contractor of the Agency having
`need for the information in order to perform a contract. Recipients of information shall be required to comply
`with the requirements of the Privacy Act of 1974, as amended, pursuant to 5 U.S.C. 552a(m).
`5. A record related to an International Application filed under the Patent Cooperation Treaty in this system of
`records may be disclosed, as a routine use, to the International Bureau of the World Intellectual Property
`Organization, pursuant to the Patent Cooperation Treaty.
`6. A record in this system of records may be disclosed, as a routine use, to another federal agency for purposes
`of National Security review (35 U.S.C. 181) and for review pursuant to the Atomic Energy Act (42 U.S.C.
`218(c)).
`7. A record from this system of records may be disclosed, as a routine use, to the Administrator, General
`Services, or his/her designee, during an inspection of records conducted by GSA as part of that agency’s
`responsibility to recommend improvements in records management practices and programs, under authority of
`44 U.S.C. 2904 and 2906. Such disclosure shall be made in accordance with the GSA regulations governing
`inspection of records for this purpose, and any other relevant (i.e., GSA or Commerce) directive. Such
`disclosure shall not be used to make determinations about individuals.
`
`8. A record from this system of records may be disclosed, as a routine use, to the public after either publication of
`the application pursuant to 35 U.S.C. 122(b) or issuance of a patent pursuant to 35 U.S.C. 151. Further, a
`record may be disclosed, subject to the limitations of 37 CFR 1.14, as a routine use, to the public if the record
`was filed in an application which became abandoned or in which the proceedings were terminated and which
`application is referenced by either a published application, an application open to public inspection or an issued
`patent.
`9. A record from this system of records may be disclosed, as a routine use, to a Federal, State, or local law
`enforcement agency, if the USPTO becomes aware of a violation or potential violation of law or regulation.
`
`Page 2
`
`Petitioner Apple Inc. — Exhibit 1002, p. 5
`
`Petitioner Apple Inc. - Exhibit 1002, p. 5
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`SYSTEM AND METHOD EMPLOYING AN AGILE NETWORK PROTOCOL FOR
`
`SECURE COMMUNICATIONS USING SECURE DOMAIN NAMES
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001]
`
`This application claims priority from and is a continuation of a co-pending
`
`U.S. Application No. 13/049,552,
`
`filed March 16, 2011, which is a continuation of U.S.
`
`Application No. 11/840,560, filed August 17, 2007, now U.S. Patent No. 7,921,211, which is a
`
`continuation of U.S. Application No. 10/714,849, filed November 18, 2003, now U.S. Patent No.
`
`7,418,504, which is a continuation of U.S. Application No. 09/558,210, filed April 26, 2000,
`
`now abandoned, which is a continuation-in-part of U.S. Application No. 09/504,783, filed on
`
`February 15, 2000, now U.S. Patent 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
`
`No. 09/429,643, filed on October 29, 1999, now U.S. Patent No. 7,010,604, issued March 07,
`
`2006. The subject matter of U.S. application serial number 09/429,643, which is bodily
`
`incorporated herein, derives from provisional U.S. Application Nos. 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,209, filed April 26, 2000, now abandoned, and which is
`
`incorporated by reference herein. Each of the above-mentioned applications is incorporated
`
`herein by reference in its entirety as though fi1lly set forth herein.
`
`BACKGROUND OF THE INVENTION
`
`[0002]
`
`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 110. 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
`
`Petitioner Apple Inc. — Exhibit 1002, p. 6
`
`Petitioner Apple Inc. - Exhibit 1002, p. 6
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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 websites or other Internet resources they are “visiting.” These two security
`
`issues may be called data security and anonymity, respectively.
`
`[0003]
`
`Data security is usually tackled using some form of data encryption. An
`
`encryption key 48 is known at both the originating and terminating terminals l00 and ll0. The
`
`keys may be private and public at the originating and destination terminals 100 and ll0,
`
`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.
`
`[0004]
`
`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).
`
`[0005]
`
`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 messages confuse 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.
`
`-2-
`
`Petitioner Apple Inc. — Exhibit 1002, p. 7
`
`Petitioner Apple Inc. - Exhibit 1002, p. 7
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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
`
`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.
`
`[0006]
`
`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.
`
`[0007]
`
`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 layer of encryption to add another, then sends the traffic to the
`
`next server, which strips off yet another layer of encryption and adds a 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.
`
`[0008]
`
`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
`
`-3-
`
`Petitioner Apple Inc. — Exhibit 1002, p. 8
`
`Petitioner Apple Inc. - Exhibit 1002, p. 8
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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
`
`[0009]
`
`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 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 final destination.
`
`[0010]
`
`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.
`
`[0011]
`
`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
`
`Petitioner Apple Inc. — Exhibit 1002, p. 9
`
`Petitioner Apple Inc. - Exhibit 1002, p. 9
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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.
`
`[0012]
`
`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 by a TARP router or a TARP 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.
`
`[0013]
`
`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.
`
`[0014]
`
`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.
`
`[0015]
`
`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
`99 C6
`
`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
`
`Petitioner Apple Inc. — Exhibit 1002, p. 10
`
`Petitioner Apple Inc. - Exhibit 1002, p. 10
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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 Whether the 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.
`
`[0016]
`
`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.
`
`[0017]
`
`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.
`
`[0018]
`
`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 a portion,
`
`or entirety, of a message, and that portion or entirety then interleaved into a number of separate
`
`Petitioner Apple Inc. — Exhibit 1002, p. ll
`
`Petitioner Apple Inc. - Exhibit 1002, p. 11
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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.
`
`[0019]
`
`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.
`
`[0020]
`
`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 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.
`
`[0021]
`
`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.
`
`[0022]
`
`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
`
`Petitioner Apple Inc. — Exhibit 1002, p. 12
`
`Petitioner Apple Inc. - Exhibit 1002, p. 12
`
`

`
`Attorney Docket No. 77580-151 (VRNK-1CP3CN-FT1)
`
`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.
`
`[0023]
`
`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.
`
`[0024]
`
`Further
`
`improvements described in this continuation-in-part application
`
`include: (1) a load balancer that distributes packets across different transmission paths according
`
`to transmission 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 filnction