WO2001075556A2 - Apparatus, system, and method for communicating to a network through a virtual domain - Google Patents

Apparatus, system, and method for communicating to a network through a virtual domain Download PDF

Info

Publication number
WO2001075556A2
WO2001075556A2 PCT/US2001/008637 US0108637W WO0175556A2 WO 2001075556 A2 WO2001075556 A2 WO 2001075556A2 US 0108637 W US0108637 W US 0108637W WO 0175556 A2 WO0175556 A2 WO 0175556A2
Authority
WO
WIPO (PCT)
Prior art keywords
client
controller
forwarder
destination
deceiver
Prior art date
Application number
PCT/US2001/008637
Other languages
French (fr)
Other versions
WO2001075556A3 (en
Inventor
Douglas A. Campbell
Alan B. Hamor
Mike D. Helton
Original Assignee
Wk Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=24165576&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2001075556(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Wk Networks, Inc. filed Critical Wk Networks, Inc.
Priority to AU2001250867A priority Critical patent/AU2001250867A1/en
Publication of WO2001075556A2 publication Critical patent/WO2001075556A2/en
Publication of WO2001075556A3 publication Critical patent/WO2001075556A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5053Lease time; Renewal aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats

Definitions

  • This invention relates generally to networks and network systems, and more specifically to a system and method for enabling anonymous network activity, while establishing virtual namespaces for clients.
  • the current Internet infrastructure involves millions of computers linked together on a computer network. This network allows all of the computers to communicate with one another. Clients are typically linked to the Internet via Internet Service Providers (ISP's), which in turn connect to larger ISP's. This allows numerous clients to communicate to each other through their various connections.
  • ISP's Internet Service Providers
  • all the machines on the Internet can be categorized into two types: servers and clients. Typically, machines that provide services (like Web servers, FTP servers, Email servers, etc.) are servers. Servers are loaded with the appropriate software in order to allow them to perform their intended services.
  • IP addresses are a thirty-two bit number that is normally expressed as 4 octets in a dotted decimal number (e.g., 192.168.1.101). Each of the octets can have values between 0 and 255 (2 8 possibilities per octet).
  • ISP Internet Service Provider
  • DNS domain name system
  • HTTP-protocol hypertext transport protocol
  • information such as a client's e-mail address, web sites that were visited, and information on the client's software and host computer, to be recorded and traced by the server.
  • This opens up the user to a range of privacy threats including unwanted e-mails, solicitations, and "cookies" (data that is stored on the client's machine by a server and subsequently used for identification).
  • One of the solutions available is to route the client through a proxy server in order to substitute IP information being sent by the client.
  • the packets sent from client's computer are routed through a proxy server.
  • the server executes algorithms to extract information that would identify the client, and replaces the information with predetermined substitutes.
  • the proxy server routes the packet out to the web server.
  • the web server receives the packet, all of the information points back to the proxy server, and not to the client. This in effect "hides" the client from the web server.
  • a drawback to such systems is that, as mentioned before, the client is obtaining protection merely through the use of an alternate identity that is ultimately assigned back to the same client.
  • the present invention involves the use of three algorithms, known collectively as DNS Misdirection and individually as the deceiver, the controller, and the forwarder.
  • the deceiver communicates with clients and with the controller.
  • the deceiver provides name resolution for clients.
  • the routine works the same as a standard name server, except when a query is received from a client, the deceiver allows the controller to supply the information.
  • the controller communicates with the deceiver and the forwarder.
  • the controller determines the address, "time to live” (TTL), and other DNS result fields and returns them to the deceiver.
  • TTL time to live
  • the controller is queried by the forwarder for the site address that the client intended to reach.
  • One advantage of the invention deals with isolating client activity on the Internet.
  • Another important feature of the invention is that the DNS Misdirection system allows for the creation of virtual namespaces. Through these namespaces, the isolated clients can anonymously browse the Internet while being part of a virtual community. By utilizing virtual namespaces and generated root domain names (e.g., "carlover”, “winetaster”, “stockpicker”), the community activities would be inaccessible to all but intended clients. Furthermore, since virtual namespaces would create a domain through which clients could identify themselves and communicate through, network administrators could establish ad hoc software applications as well as domain-specific identifiers that could be assigned to a user or groups of users.
  • FIG. 1 schematically shows the system architecture of an exemplary network on which one embodiment of the invention may be implemented.
  • FIG. 2 illustrates the packet contents as they are routed through the network.
  • FIG. 3 generally provides a flowchart representation of a client sending a packet to be resolved, and the subsequent misdirection of the client to a destination website via the present invention.
  • FIG. 4 generally provides a flowchart representation when the website server responds back to the client through the invention.
  • FIG. 1 illustrates an embodiment of the system architecture that contains at least one client (101).
  • This client consists of a personal computer, which contains an interface to a computer network, such as a modem, network interface card, etc.
  • the client (101) may also be generalized as any client application. Loaded in the client computer (101) are an Internet browser and a resolver (not shown).
  • the client (101) will typically enter a destination site domain name into the computer's Internet browser (e.g., "www.whoknowz.com").
  • the destination site is a web server (108).
  • the Internet browser will typically be connected through an ISP (not shown).
  • the domain name can be embedded in a URL (via hyperlink), or can be explicitly entered by the client.
  • IPv4 IP address
  • IPv6 IP address
  • the ISP will furnish the clients with a DNS (105), which is accessed through the client's resolver.
  • DNS DNS
  • the resolver is typically predisposed with two IP addresses, which represent the primary and secondary name servers that may be accessed.
  • the name of the server may be entered manually, or may be provided by using Dynamic Host Configuration Protocol (DHCP).
  • DHCP Dynamic Host Configuration Protocol
  • the deceiver (104) Upon receipt of the packet, the deceiver (104) will recognize the source of the packet (1) through the IP source address, shown in FIG. 2. The fields in which the IP source and destination addresses function are described in greater detail in RFC 791 ("DARPA Internet Program Protocol Specification"). By parsing the data field through the controller (106), the deceiver will determine the intended domain name that the client (101) wants to reach.
  • RFC 791 DRPA Internet Program Protocol Specification
  • the deceiver (104) queries the controller (106) to initiate a name resolution.
  • the controller (106) then sends the packet (2) where the IP destination address of the DNS (105) is now placed in the packet (2), and is transmitted onward, hi the meantime, the controller (106) stores the client's (101) IP location, and determines a name-to-IP address time-to-live (TTL).
  • TTL is the time period in which the client (101) may assume a valid name-to-IP address.
  • the TTL of the name-to-IP address may be established through the use of cache, or any other suitable memory available.
  • the TTL field is a 32 bit integer that represents units of seconds, and is primarily used by resolvers when they cache network resource records.
  • the TTL describes how long a resource record can be cached before it should be discarded.
  • the TTL may be assigned by the administrator for the zone where the data originates.
  • the client must perform another query in order to establish a connection with an IP address.
  • the controller (106) Upon receipt of the packet (2), the controller (106) determines the source of the packet, and subsequently proceeds to process the domain name resolution request, and queries the DNS name server (105) in packet (3) to obtain the website server (108) IP address. When the destination website IP address is resolved in the DNS (105), it is transmitted back to the controller (106) in packet (4). When the controller (106) obtains the IP address of the destination website server (108), the controller (106) then proceeds to establish connection with a forwarder (107) through which to communicate through. Once connected, the controller (106) then records the address of the forwarder (107). The forwarder's (107) address is then used by the controller (106) to create a valid session for the client (101), by correlating the forwarder address with the TTL of the client (101) and the destination website server (108).
  • the controller (107) will associate the established forwarder (107) with the session. After connecting with a forwarder (107), the controller (106) then proceeds to store the client (101) IP address, the destination website (108) IP address, the IP address of the forwarder (107), and the determined TTL.
  • the stored elements (200) are disclosed in FIG. 1.
  • the controller (106) After storing the pertinent information, the controller (106) then returns the forwarder (107) IP address back to the deceiver (104) via packet (5).
  • the contents of packet (5) are shown in FIG. 2.
  • the packet (6) is then transmitted to the client (101), along with the TTL.
  • the client Upon receipt of the packet (6), the client will be "deceived” into thinking that the forwarder (107) IP address is actually the destination website server (108).
  • any communication between the client (101) and the website server (108) will be taking place in a virtual domain, since both the client (101) and the website server (108) do not technically exist to each other - the client is isolated from the destination sites of his or her data packets, and the destination sites are isolated from the clients that are accessing the site.
  • a virtual namespace may be set up as ".bank”, thus identifying a bank classification. If a client wishes to visit a server that is known to be related to banks, the client could type “wellsfargo.bank” and be routed to "wellsfargo.com” via the system described in FIG. 1. Alternately, a client could enter "*.bank” and receive an HTML page with all registered entries. Furthermore, the client could customize the identification used on the Internet (e.g., "wellsfargo.doug”). Names could be created ad hoc or could be associated with groupware (e.g., "mother.birthday.card”; "smith. family. reunion.newyork”). The variations are virtually endless.
  • Some of the implementations of the virtual namespaces and underlying domains include, but are not limited to:
  • the packet (7) is now routed to the forwarder (107).
  • the client (101) will typically connect to the forwarder (107) through a well-known port.
  • the forwarder (107) proceeds to query the controller (106) (shown as packet (8)) to determine: (1) whether the client (101) is valid; (2) if the TTL has not expired; and (3) if the IP address of the website server (108) that the client wishes to connect to is valid. If everything is confirmed, the controller (106) then sends back the relevant information via packet (9).
  • the forwarder (107) extracts the needed information including the website server (108) IP address, and forwards the packet on to it's intended destination.
  • the deceiver (104), the controller (106), and the forwarder (107) are applications.
  • the website server (108) maybe generalized as any server application.
  • the deceiver (104), the controller (106), and the forwarder (107) can all be on a single computer, or separate computers.
  • the deceiver (104) and the controller (105) can be on the client's computer.
  • FIG. 3-4 represent a flowchart representation of the invention as previously disclosed in FIG. 1-2.
  • the client configures software/hardware on the client computer, and establishes a session by signing on or logging into a network for a predetermined time (402).
  • the client wishes to transmit data onto the network, or otherwise communicate with other computers or servers, one option available for the client is to query the resolver in order to retrieve an intended destination site (403).
  • the resolver query is routed to the deceiver. After receiving the contents of the resolver, the deceiver then forwards the query to the controller in (404).
  • the controller When the controller receives the query packet, the controller next records the location of the client, determines the TTL for the client session, and further queries a
  • the controller then establishes contact with an available forwarder through which the client session may be transmitted through, and subsequently records the IP address. While it is not displayed in the flowchart, if the controller determines that: (1) a TTL has expired; (2) an invalid client is sending the query; (3) a valid forwarder is unavailable; or (4) a desired website destination is invalid, or any combination thereof, the controller aborts the remainder of the process and transmits the appropriate message or subroutine to the client. If everything is determined to be valid, then the controller proceeds to store into memory the client's IP address, the destination website IP address, the forwarder IP address, and the TTL (407).
  • step (408) the controller sends back to the deceiver the forwarder IP address, that is masquerading as the destination website IP address.
  • the deceiver in turn sends the data back to the client (409), where the client then connects with the forwarder through a known port.
  • the forwarder next queries the controller to determine the validity of the client, the status of the TTL, and the IP address of the website which the client is trying to reach (410). Just like the controller, if the forwarder determines at this point that: (1) a TTL has expired; (2) an invalid client is sending the query; or (3) a desired website destination is invalid, or any combination thereof, the forwarder aborts the remainder of the process, and transmits the appropriate message or subroutine back to the client (411).
  • the forwarder will proceed to transmit the client's data to the destination website server (412). Once the destination website receives the data from the client, the server will only recognize the forwarder as the source, and thus would only communicate back to the client via the forwarder. Accordingly, if the website server requires to communicate back to the client, the data is routed through the forwarder (413).
  • the forwarder in principle, reverses the process disclosed in (410) to determine the source client which is intended to receive the website server's data (414).
  • the data may be of any kind including, but not limited to, text, programs, applets, video, audio, etc.

Abstract

The present invention is an apparatus, system and method for communicating to a network through an ad hoc virtual domain. The present invention contains a deceiver (104), a controller (106), and a forwarder (107) through which a client (101) communicates through. The deceiver (104), controller (106), and forwarder (107) collectively establish the domain in which the ad hoc virtual namespace will exist. This invention allows clients (101) to interact over a network in a fashion that is anonymous and unique to the session which the client (101) is engaging in.

Description

APPARATUS, SYSTEM, AND METHOD FOR COMMUNICATING TO A NETWORK THROUGH A VIRTUAL DOMAIN
SCOPE OF THE INVENTION
This invention relates generally to networks and network systems, and more specifically to a system and method for enabling anonymous network activity, while establishing virtual namespaces for clients.
BACKGROUND
The proliferation and expansion of computer systems, networks, databases, the Internet, and particularly the World Wide Web (WWW), has resulted in a vast and diverse collection of information and means of communication. The current Internet infrastructure involves millions of computers linked together on a computer network. This network allows all of the computers to communicate with one another. Clients are typically linked to the Internet via Internet Service Providers (ISP's), which in turn connect to larger ISP's. This allows numerous clients to communicate to each other through their various connections. In general, all the machines on the Internet can be categorized into two types: servers and clients. Typically, machines that provide services (like Web servers, FTP servers, Email servers, etc.) are servers. Servers are loaded with the appropriate software in order to allow them to perform their intended services. Machines that request information from servers are typically called clients. In order to differentiate between machines on the network, each machine is given a unique address called an IP address. The IP address is a thirty-two bit number that is normally expressed as 4 octets in a dotted decimal number (e.g., 192.168.1.101). Each of the octets can have values between 0 and 255 (28 possibilities per octet). When a client connects to the Internet, the client is assigned an IP address through their Internet Service Provider (ISP) for the duration of the connection. Conversely, the IP addresses of servers are relatively static, and do not change very often. Because it is difficult for clients to remember IP addresses, and because IP addresses need to change, most servers on the Internet possess domain names (e.g., "www.whoknowz.com") to help users reach their intended servers without remembering strings of numbers. Name servers, used in the domain name system (DNS), map the human-readable names into IP addresses to help clients reach their destinations. When a client enters a domain name, the browser (via a resolver) extracts the domain name and passes it to a name server, which will return the correct IP address to the associated site. The Domain Name System is comprised of a distributed database and name servers that access that database. One of the main problems with the current utilization of IP addresses and domain names on the World Wide Web (WWW) is that the WWW is based largely on the hypertext transport protocol ("HTTP-protocol"). The nature of HTTP -protocol allows information, such as a client's e-mail address, web sites that were visited, and information on the client's software and host computer, to be recorded and traced by the server. This opens up the user to a range of privacy threats including unwanted e-mails, solicitations, and "cookies" (data that is stored on the client's machine by a server and subsequently used for identification). Furthermore, clients that wish to cloak themselves from such intrusions are forced into systems that simply provide alternate account identities for the client; while the client is protected, the alternate account identity becomes the object of the unwanted e-mails, "cookies", etc. instead. The effect of this is similar to the client manually creating a new user account in which to browse the WWW.
One of the solutions available is to route the client through a proxy server in order to substitute IP information being sent by the client. When a client desires to visit a web server, the packets sent from client's computer are routed through a proxy server. At the proxy server, the server executes algorithms to extract information that would identify the client, and replaces the information with predetermined substitutes. Afterwards, the proxy server routes the packet out to the web server. Once the web server receives the packet, all of the information points back to the proxy server, and not to the client. This in effect "hides" the client from the web server. However, a drawback to such systems is that, as mentioned before, the client is obtaining protection merely through the use of an alternate identity that is ultimately assigned back to the same client. Furthermore, current systems do not have any added flexibility designed in the system to take advantage of anonymous client group browsing or multiple group association, hi order to fully take advantage of ad hoc identity browsing, additional features need to be added in order to create a "community-like" environment among numerous anonymous clients.
SUMMARY OF THE INVENTION
To address the above-discussed deficiencies in existing systems, the present invention involves the use of three algorithms, known collectively as DNS Misdirection and individually as the deceiver, the controller, and the forwarder. The deceiver communicates with clients and with the controller. The deceiver provides name resolution for clients. The routine works the same as a standard name server, except when a query is received from a client, the deceiver allows the controller to supply the information. The controller communicates with the deceiver and the forwarder. The controller determines the address, "time to live" (TTL), and other DNS result fields and returns them to the deceiver. The controller is queried by the forwarder for the site address that the client intended to reach.
One advantage of the invention deals with isolating client activity on the Internet. Another important feature of the invention is that the DNS Misdirection system allows for the creation of virtual namespaces. Through these namespaces, the isolated clients can anonymously browse the Internet while being part of a virtual community. By utilizing virtual namespaces and generated root domain names (e.g., "carlover", "winetaster", "stockpicker"), the community activities would be inaccessible to all but intended clients. Furthermore, since virtual namespaces would create a domain through which clients could identify themselves and communicate through, network administrators could establish ad hoc software applications as well as domain-specific identifiers that could be assigned to a user or groups of users.
BRIEF DESCRIPTION OF THE DRAWINGS :
The following drawings illustrate certain embodiments of the present invention. FIG. 1 schematically shows the system architecture of an exemplary network on which one embodiment of the invention may be implemented.
FIG. 2 illustrates the packet contents as they are routed through the network.
FIG. 3 generally provides a flowchart representation of a client sending a packet to be resolved, and the subsequent misdirection of the client to a destination website via the present invention.
FIG. 4 generally provides a flowchart representation when the website server responds back to the client through the invention.
DETAILED DESCRIPTION
FIG. 1 illustrates an embodiment of the system architecture that contains at least one client (101). This client consists of a personal computer, which contains an interface to a computer network, such as a modem, network interface card, etc. The client (101) may also be generalized as any client application. Loaded in the client computer (101) are an Internet browser and a resolver (not shown). When the client (101) wishes to connect to a site on the Internet, the client (101) will typically enter a destination site domain name into the computer's Internet browser (e.g., "www.whoknowz.com"). In FIG. 1, the destination site is a web server (108). The Internet browser will typically be connected through an ISP (not shown). The domain name can be embedded in a URL (via hyperlink), or can be explicitly entered by the client. If the client (101) is to reach the web server (108), the client needs to obtain the web server's (108) IP address, shown in FIG. 1 (all of the hypothetically disclosed IP addresses in the invention are shown in the figure). With the architecture used in existing systems, the IP address must be resolved into a 32 bit (IPv4) / 128 bit (IPv6) IP address. Normally, the ISP will furnish the clients with a DNS (105), which is accessed through the client's resolver. The resolver is typically predisposed with two IP addresses, which represent the primary and secondary name servers that may be accessed. The name of the server may be entered manually, or may be provided by using Dynamic Host Configuration Protocol (DHCP). The process of resolving domain names, and the operation of DNS servers is addressed further in detail in RFC 1034 ("Domain Names - Concepts and Facilities" - last update: November 17, 1999), and RFC 1035 ("Domain Names - Implementation and Specification" - last update: November 17, 1999). Under the current invention, when an unresolved packet is sent from client (101), the packet is processed through the deceiver (104). A more detailed representation of the packet, as well as exemplary port connections, is shown in FIG. 2. It should be pointed out that the term "packet" may mean an IP packet, an UDP datagram, or other transmitted data. When the packet (1) is transmitted, the packet will be transparently addressed to the deceiver (104). Upon receipt of the packet, the deceiver (104) will recognize the source of the packet (1) through the IP source address, shown in FIG. 2. The fields in which the IP source and destination addresses function are described in greater detail in RFC 791 ("DARPA Internet Program Protocol Specification"). By parsing the data field through the controller (106), the deceiver will determine the intended domain name that the client (101) wants to reach.
From this point, the deceiver (104) queries the controller (106) to initiate a name resolution. The controller (106) then sends the packet (2) where the IP destination address of the DNS (105) is now placed in the packet (2), and is transmitted onward, hi the meantime, the controller (106) stores the client's (101) IP location, and determines a name-to-IP address time-to-live (TTL). The TTL is the time period in which the client (101) may assume a valid name-to-IP address. The TTL of the name-to-IP address may be established through the use of cache, or any other suitable memory available. Typically, the TTL field is a 32 bit integer that represents units of seconds, and is primarily used by resolvers when they cache network resource records. The TTL describes how long a resource record can be cached before it should be discarded. The TTL may be assigned by the administrator for the zone where the data originates. Under the present invention, once the TTL expires, the client must perform another query in order to establish a connection with an IP address.
Upon receipt of the packet (2), the controller (106) determines the source of the packet, and subsequently proceeds to process the domain name resolution request, and queries the DNS name server (105) in packet (3) to obtain the website server (108) IP address. When the destination website IP address is resolved in the DNS (105), it is transmitted back to the controller (106) in packet (4). When the controller (106) obtains the IP address of the destination website server (108), the controller (106) then proceeds to establish connection with a forwarder (107) through which to communicate through. Once connected, the controller (106) then records the address of the forwarder (107). The forwarder's (107) address is then used by the controller (106) to create a valid session for the client (101), by correlating the forwarder address with the TTL of the client (101) and the destination website server (108). As long as the client's name-to-IP- address has not expired (i.e., the TTL has not run out), the controller (107) will associate the established forwarder (107) with the session. After connecting with a forwarder (107), the controller (106) then proceeds to store the client (101) IP address, the destination website (108) IP address, the IP address of the forwarder (107), and the determined TTL. The stored elements (200) are disclosed in FIG. 1.
After storing the pertinent information, the controller (106) then returns the forwarder (107) IP address back to the deceiver (104) via packet (5). The contents of packet (5) are shown in FIG. 2. After the packet (5) is routed through the deceiver (104), the packet (6) is then transmitted to the client (101), along with the TTL. Upon receipt of the packet (6), the client will be "deceived" into thinking that the forwarder (107) IP address is actually the destination website server (108). At this point, any communication between the client (101) and the website server (108) will be taking place in a virtual domain, since both the client (101) and the website server (108) do not technically exist to each other - the client is isolated from the destination sites of his or her data packets, and the destination sites are isolated from the clients that are accessing the site.
One advantage of this configuration is that the virtual namespaces allow system administrators and clients to create a virtually endless string of identities for clients and their target website server(s). For example, a virtual namespace may be set up as ".bank", thus identifying a bank classification. If a client wishes to visit a server that is known to be related to banks, the client could type "wellsfargo.bank" and be routed to "wellsfargo.com" via the system described in FIG. 1. Alternately, a client could enter "*.bank" and receive an HTML page with all registered entries. Furthermore, the client could customize the identification used on the Internet (e.g., "wellsfargo.doug"). Names could be created ad hoc or could be associated with groupware (e.g., "mother.birthday.card"; "smith. family. reunion.newyork"). The variations are virtually endless.
Some of the implementations of the virtual namespaces and underlying domains include, but are not limited to:
(1) creating unique environments for marketing, branding, advertising and promotion purposes;
(2) allowing for personalized Web identities for individuals, corporations, organizations, etc.; (3) providing anonymous browsing, searching and e-mailing;
(4) creating environments for users to establish groups for collaborative communication or application purposes;
(5) cataloguing domain names under intuitive categories or functions (e.g.
"bestbuy.shop, "amazon.shop", etc.) (6) creating a search index which allows the user(s) to locate all members of a specific category and identifying distinct products, goods, services, content, or information provided by any ember of any category and/or identification. (7) creating directories that contain telephone, Internet, fax, wireless, page, cellular, e-mail, instant messaging and/or similar data under one or more human readable formats addressable by a communication device.
When the client makes a transmission to the website server (108), the packet (7) is now routed to the forwarder (107). The client (101) will typically connect to the forwarder (107) through a well-known port. After receiving the packet from the client (101), the forwarder (107) proceeds to query the controller (106) (shown as packet (8)) to determine: (1) whether the client (101) is valid; (2) if the TTL has not expired; and (3) if the IP address of the website server (108) that the client wishes to connect to is valid. If everything is confirmed, the controller (106) then sends back the relevant information via packet (9). The forwarder (107) then extracts the needed information including the website server (108) IP address, and forwards the packet on to it's intended destination. It should be understood that the deceiver (104), the controller (106), and the forwarder (107) are applications. The website server (108) maybe generalized as any server application. Furthermore, the deceiver (104), the controller (106), and the forwarder (107) can all be on a single computer, or separate computers. Also, the deceiver (104) and the controller (105) can be on the client's computer.
FIG. 3-4 represent a flowchart representation of the invention as previously disclosed in FIG. 1-2. hi step (401), the client configures software/hardware on the client computer, and establishes a session by signing on or logging into a network for a predetermined time (402). When the client wishes to transmit data onto the network, or otherwise communicate with other computers or servers, one option available for the client is to query the resolver in order to retrieve an intended destination site (403). In (403), the resolver query is routed to the deceiver. After receiving the contents of the resolver, the deceiver then forwards the query to the controller in (404).
When the controller receives the query packet, the controller next records the location of the client, determines the TTL for the client session, and further queries a
DNS name server, and receives back the IP address of the website which the client wishes to contact (405). hi (406), the controller then establishes contact with an available forwarder through which the client session may be transmitted through, and subsequently records the IP address. While it is not displayed in the flowchart, if the controller determines that: (1) a TTL has expired; (2) an invalid client is sending the query; (3) a valid forwarder is unavailable; or (4) a desired website destination is invalid, or any combination thereof, the controller aborts the remainder of the process and transmits the appropriate message or subroutine to the client. If everything is determined to be valid, then the controller proceeds to store into memory the client's IP address, the destination website IP address, the forwarder IP address, and the TTL (407).
In step (408), the controller sends back to the deceiver the forwarder IP address, that is masquerading as the destination website IP address. The deceiver in turn sends the data back to the client (409), where the client then connects with the forwarder through a known port. The forwarder next queries the controller to determine the validity of the client, the status of the TTL, and the IP address of the website which the client is trying to reach (410). Just like the controller, if the forwarder determines at this point that: (1) a TTL has expired; (2) an invalid client is sending the query; or (3) a desired website destination is invalid, or any combination thereof, the forwarder aborts the remainder of the process, and transmits the appropriate message or subroutine back to the client (411). If everything is determined to be valid, the forwarder will proceed to transmit the client's data to the destination website server (412). Once the destination website receives the data from the client, the server will only recognize the forwarder as the source, and thus would only communicate back to the client via the forwarder. Accordingly, if the website server requires to communicate back to the client, the data is routed through the forwarder (413). When data is received by the forwarder, the forwarder, in principle, reverses the process disclosed in (410) to determine the source client which is intended to receive the website server's data (414). The data may be of any kind including, but not limited to, text, programs, applets, video, audio, etc. Once the forwarder determines the client's proper IP address, the forwarder then transmits the reply data back to the client (415).
Although the present invention has been described in detail, it is to be understood that various changes, alterations, and substitutions can be made without departing from the spirit and scope of the invention. More particularly, it should be apparent to those skilled in the pertinent art that the above described invention is algorithmic and is executable by a suitable conventional computer system or network. Alternate embodiments of the present invention may also be suitably implemented, at least in part, in firmware or hardware, or some suitable combination.

Claims

CLAIMSWe claim:
1. A method, comprising:
(a) transmitting a packet from at least one client to a deceiver;
(b) transmitting the packet from the deceiver to a controller;
(c) routing the packet from the controller to a first server to resolve the packet;
(d) receiving the resolved packet from the first server back to the controller; (e) establishing a connection between the controller and a forwarder;
(f) processing the resolved packet and storing data from the packet in the controller;
(g) routing the packet back through the client to the forwarder;
(h) further processing the packet in the forwarder, where the packet is then transmitted to a second server.
2. The method according to claim 1, wherein the packet sent from the client contains a request for a domain name resolution.
3. The method according to claim 2, wherein the packet sent from the client is forwarded through the deceiver to the controller, where said controller subsequently queries a domain name server.
4. The method according to claim 3, wherein the domain name server resolves the client request, and returns the resolved packet back to the controller.
5. The method according to claim 1, wherein the packet from the client computer includes a request to resolve an IP address of a website server that the client is intending to reach.
The method according to claim 5, wherein the controller stores an IP address that represents the origin of a client.
7. The method according to claim 5, wherein the controller stores an IP address of the website server that the client is intending to reach.
8. The method according to claim 5, wherein the controller stores an IP address that represents the location of the forwarder.
9. The method according to claim 5, wherein the controller stores a time-to-live function for a session.
10. The method according to claim 5, wherein the processing of the resolved packet includes interchanging the IP address of the website server with the IP address of the forwarder.
11. The method according to claim 5, wherein the processing of the resolved packet in the forwarder includes said forwarder querying the controller to determine the destination IP.
12. The method according to claim 5, wherein the processing of the resolved packet in the forwarder includes said forwarder querying the controller to determine the client IP, the deceiver IP and a time-to-live to establish validity of client request.
13. A computer system comprising:
(a) a deceiver connected to at least one client to receive/send data, whereby the deceiver misdirects data received from the client back to said client; (b) a forwarder connected to the client and a destination website;
(c) a controller in communication with the deceiver, the forwarder, and a server.
14. A computer system according to claim 13, wherein the controller receives data from the deceiver containing destination instruction.
15. A computer system according to claim 14, wherein the destination instruction is an IP address of a website that the client is intending to communicate with.
16. A computer system according to claim 13, wherein the deceiver forwards a destination instruction to the controller, and the controller transmits the instruction to the server.
17. A computer system according to claim 16, wherein the server returns the destination instruction back to the controller.
18. A computer system according to claim 17, wherein the controller extracts and replaces the destination instruction with a misdirected destination instruction.
19. A computer system according to claim 18, wherein the controller stores the destination instruction.
20. A computer system according to claim 19, wherein the controller transmits the misdirected destination instruction to the deceiver.
21. A computer system according to claim 20, wherein the misdirected destination instruction identifies the forwarder as a destination.
22. A computer system according to claim 21 wherein the deceiver forwards the misdirected destination instruction through the client to the forwarder.
23. A computer system according to claim 22 wherein the forwarder validates the misdirected destination instruction via the controller.
24. A computer system according to claim 23 wherein the forwarder executes the validated misdirected destination instruction to the destination website.
25. A method for communicating through virtual namespaces comprising: (a) assigning an ad hoc domain to at least one client with a controller via a deceiver; (b) misdirecting client destination instructions through the controller and deceiver;
(c) validating the misdirected IP queries through a forwarder, wherein the forwarder, controller and deceiver function as the client's domain for the virtual namespace.'
26. The method according to claim 25 wherein the ad hoc domain exists for a predetermined period of time.
27. The method according to claim 25 wherein the controller and deceiver misdirect client destination instruction back to the client.
28. The method according to claim 27 wherein data in the client destination instruction is recorded and stored in the controller.
29. The method according to claim 27 wherein the controller establishes communication with a forwarder through which said misdirected client destination instruction is to be routed through.
30. The method according to claim 29 wherein the deceiver communicates the output of the controller to the client.
31. The method according to claim 29 wherein the forwarder validates the misdirected client destination instruction through the controller
32. A computer program article of manufacture comprising:
(a) a computer readable medium;
(b) program means in said computer readable medium for communicating with at least one client; (c) program means in said computer readable medium for misdirecting client IP queries; (d) program means in said computer readable medium for validating the misdirected client IP queries and communicating data contained in said IP queries to a destination website;
(e) program means in said computer readable medium for re- validating data sent from said destination website that is intended for the client.
33. A method for misdirecting destination instructions, comprising:
(a) receiving a destination instruction from at least one client;
(b) processing and storing the destination instruction; (c) establishing a misdirection destination for said destination instruction;
(d) transparently transmitting the misdirection destination back to the client.
34. The method according to claim 33, wherein the destination instruction is received by a deceiver;
35. The method according to claim 34, wherein the destination instruction is forwarded to a controller;
36. The method according to claim 35, wherem the destination instruction is resolved and processed in the controller.
37. The method according to claim 36, wherein the controller establishes a misdirection destination by communicating to a forwarder.
38. The method according to claim 37, wherein the misdirection destination is the forwarder.
39. The method according to claim 33, wherein the client further transmits data relating to the destination instruction using the misdirected destination instruction.
40. A computer system comprising:
(a) a processing system connected to at least one client; (b) a deceiver communicating with the processing system;
(c) a forwarder communicating with the processing system;
(d) a controller communicating with the deceiver and the forwarder, wherein said controller, deceiver and forwarder define a domain through which the client communicates to a network.
41. A computer system according to claim 40, wherein the deceiver and controller define a first part of the domain by directing client activity to a predetermined destination established by the deceiver.
42. A computer system according to claim 41 wherein the predetermined destination is transparently substituted for a client's intended destination.
43. A computer system according to claim 41, wherein the forwarder defines a second part of the domain by validating the predetermined destination established by the deceiver and controller.
44. A computer system according to claim 40 wherein said at least one client and a network transmit data to each other through the domain.
PCT/US2001/008637 2000-04-04 2001-04-04 Apparatus, system, and method for communicating to a network through a virtual domain WO2001075556A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001250867A AU2001250867A1 (en) 2000-04-04 2001-04-04 Apparatus, system, and method for communicating to a network through a virtual domain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/542,858 US7209959B1 (en) 2000-04-04 2000-04-04 Apparatus, system, and method for communicating to a network through a virtual domain providing anonymity to a client communicating on the network
US09/542,858 2000-04-04

Publications (2)

Publication Number Publication Date
WO2001075556A2 true WO2001075556A2 (en) 2001-10-11
WO2001075556A3 WO2001075556A3 (en) 2002-01-03

Family

ID=24165576

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/008637 WO2001075556A2 (en) 2000-04-04 2001-04-04 Apparatus, system, and method for communicating to a network through a virtual domain

Country Status (3)

Country Link
US (3) US7209959B1 (en)
AU (1) AU2001250867A1 (en)
WO (1) WO2001075556A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1323528C (en) * 2004-10-22 2007-06-27 中国科学院计算技术研究所 Automatic configuration method for internet domain server in self-organizing net
US7711853B2 (en) 2006-07-14 2010-05-04 Microsoft Corporation Resolving names to network endpoints

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7209959B1 (en) * 2000-04-04 2007-04-24 Wk Networks, Inc. Apparatus, system, and method for communicating to a network through a virtual domain providing anonymity to a client communicating on the network
US7051070B2 (en) * 2000-12-18 2006-05-23 Timothy Tuttle Asynchronous messaging using a node specialization architecture in the dynamic routing network
US8505024B2 (en) 2000-12-18 2013-08-06 Shaw Parsing Llc Storing state in a dynamic content routing network
US20030079027A1 (en) * 2001-10-18 2003-04-24 Michael Slocombe Content request routing and load balancing for content distribution networks
EP1784963B1 (en) * 2004-08-17 2016-05-11 Zarbaña Digital Fund LLC Techniques for delivering personalized content with a real-time routing network
JP4668271B2 (en) * 2004-08-17 2011-04-13 ショー パーシング リミティド ライアビリティ カンパニー Upstream failure detection and recovery methods
DE102004055331A1 (en) * 2004-11-16 2006-08-17 Jochen Schumacher Method for providing an address in a data network
US9165301B2 (en) * 2007-06-06 2015-10-20 Core Audience, Inc. Network devices for replacing an advertisement with another advertisement
US9298834B2 (en) * 2009-05-26 2016-03-29 Adobe Systems Incorporated User presence data for web-based document collaboration
US8612380B2 (en) 2009-05-26 2013-12-17 Adobe Systems Incorporated Web-based collaboration for editing electronic documents
US20140181203A1 (en) * 2011-06-15 2014-06-26 Telefonaktiebolaget L M Ericsson (Publ) Methods and arrangement for dispatching requests
JP6084023B2 (en) * 2012-11-14 2017-02-22 キヤノン株式会社 Information processing apparatus, program, and control method
US20150207780A1 (en) * 2014-01-21 2015-07-23 Jonathan Grier Anonymous Network Operation
US20170195426A1 (en) * 2015-12-31 2017-07-06 Ricoh Company, Ltd. Maintaining session across plural providing devices
US11552930B2 (en) * 2020-08-31 2023-01-10 Equinix, Inc. Virtual domains within a shared device

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014698A (en) * 1997-05-19 2000-01-11 Matchlogic, Inc. System using first banner request that can not be blocked from reaching a server for accurately counting displays of banners on network terminals
US6119171A (en) * 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing
US6182148B1 (en) * 1999-03-18 2001-01-30 Walid, Inc. Method and system for internationalizing domain names
US6262976B1 (en) * 1998-09-17 2001-07-17 Ordered Networks, Inc. System and method for network flow optimization using traffic classes

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
SE504523C2 (en) 1995-06-19 1997-02-24 Ericsson Telefon Ab L M Device and method for linking customers to servers during runtime in a distributed telecommunications network
US6317775B1 (en) * 1995-11-03 2001-11-13 Cisco Technology, Inc. System for distributing load over multiple servers at an internet site
US6161126A (en) 1995-12-13 2000-12-12 Immersion Corporation Implementing force feedback over the World Wide Web and other computer networks
FR2744818B1 (en) * 1996-02-12 1998-03-27 Bull Sa PROCESS FOR VERIFYING THE CONSERVATION OF THE INTEGRITY OF A QUERY ISSUED WITHOUT PROTECTION BY A CUSTOMER TO A SERVER BY MEANS OF INTEGRITY OF THE RESPONSE
US6189030B1 (en) 1996-02-21 2001-02-13 Infoseek Corporation Method and apparatus for redirection of server external hyper-link references
CA2199108C (en) * 1996-03-05 2002-04-23 Hirotoshi Maegawa Parallel distributed processing system and method of same
US5805820A (en) * 1996-07-15 1998-09-08 At&T Corp. Method and apparatus for restricting access to private information in domain name systems by redirecting query requests
US5931912A (en) * 1996-08-09 1999-08-03 International Business Machines Corporation Traversal path-based approach to understanding user-oriented hypertext object usage
US6594254B1 (en) * 1996-08-16 2003-07-15 Netspeak Corporation Domain name server architecture for translating telephone number domain names into network protocol addresses
US6195691B1 (en) * 1996-09-17 2001-02-27 National Systems Corporation Method and apparatus for creating and using dynamic universal resource locators
US5708654A (en) * 1996-11-27 1998-01-13 Arndt; Manfred R. Method for detecting proxy ARP replies from devices in a local area network
US6014660A (en) * 1996-12-09 2000-01-11 Sun Microsystems, Inc. Method and apparatus for client-sensitive name resolution using DNS
US5961593A (en) * 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6052736A (en) * 1997-03-31 2000-04-18 International Business Machines Corp. Adaptive message routing in a multiple network environment with a master router
US6205489B1 (en) 1999-01-05 2001-03-20 Whowhere, Inc. Method for providing an internet protocol address with a domain name server
US6091951A (en) * 1997-05-14 2000-07-18 Telxon Corporation Seamless roaming among multiple networks
US6201962B1 (en) * 1997-05-14 2001-03-13 Telxon Corporation Seamless roaming among multiple networks including seamless transitioning between multiple devices
US6256739B1 (en) * 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US6026445A (en) 1997-11-17 2000-02-15 International Business Machines Corporation System and method for saving and reusing recently acquired name to address mappings
US6092100A (en) * 1997-11-21 2000-07-18 International Business Machines Corporation Method for intelligently resolving entry of an incorrect uniform resource locator (URL)
US6370584B1 (en) * 1998-01-13 2002-04-09 Trustees Of Boston University Distributed routing
US6003083A (en) * 1998-02-19 1999-12-14 International Business Machines Corporation Workload management amongst server objects in a client/server network with distributed objects
US6061743A (en) * 1998-02-19 2000-05-09 Novell, Inc. Method and apparatus for aggregating disparate namespaces
US6507585B1 (en) * 1998-05-27 2003-01-14 3Com Corporation Multi-carrier LAN adapter device using frequency domain equalizer
US6704317B1 (en) * 1998-05-27 2004-03-09 3Com Corporation Multi-carrier LAN modem server
US6891887B1 (en) * 1998-05-27 2005-05-10 3Com Corporation Multi-carrier LAN adapter device using interpolative equalizer
US6256031B1 (en) * 1998-06-26 2001-07-03 Microsoft Corporation Integration of physical and virtual namespace
US6249801B1 (en) * 1998-07-15 2001-06-19 Radware Ltd. Load balancing
US6256664B1 (en) * 1998-09-01 2001-07-03 Bigfix, Inc. Method and apparatus for computed relevance messaging
US6502135B1 (en) * 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US6496931B1 (en) * 1998-12-31 2002-12-17 Lucent Technologies Inc. Anonymous web site user information communication method
US6272540B1 (en) * 1998-12-31 2001-08-07 Intel Corporation Arrangement and method for providing flexible management of a network
US6338082B1 (en) 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
US6493765B1 (en) * 1999-03-23 2002-12-10 Nortel Networks Limited Domain name resolution in a network having multiple overlapping address domains
US6910180B1 (en) * 1999-05-10 2005-06-21 Yahoo! Inc. Removing cookies from web page response headers and storing the cookies in a repository for later use
US6628654B1 (en) * 1999-07-01 2003-09-30 Cisco Technology, Inc. Dispatching packets from a forwarding agent using tag switching
US6633560B1 (en) * 1999-07-02 2003-10-14 Cisco Technology, Inc. Distribution of network services among multiple service managers without client involvement
US6606315B1 (en) * 1999-07-02 2003-08-12 Cisco Technology, Inc. Synchronizing service instructions among forwarding agents using a service manager
US6549516B1 (en) * 1999-07-02 2003-04-15 Cisco Technology, Inc. Sending instructions from a service manager to forwarding agents on a need to know basis
US6449657B2 (en) * 1999-08-06 2002-09-10 Namezero.Com, Inc. Internet hosting system
US6629149B1 (en) * 1999-08-17 2003-09-30 At&T Corp. Network system and method
US6751677B1 (en) * 1999-08-24 2004-06-15 Hewlett-Packard Development Company, L.P. Method and apparatus for allowing a secure and transparent communication between a user device and servers of a data access network system via a firewall and a gateway
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
US6442687B1 (en) * 1999-12-02 2002-08-27 Ponoi Corp. System and method for secure and anonymous communications
US6510464B1 (en) * 1999-12-14 2003-01-21 Verizon Corporate Services Group Inc. Secure gateway having routing feature
US6674743B1 (en) * 1999-12-30 2004-01-06 3Com Corporation Method and apparatus for providing policy-based services for internal applications
US6785705B1 (en) * 2000-02-08 2004-08-31 Lucent Technologies Inc. Method and apparatus for proxy chaining
US6880089B1 (en) * 2000-03-31 2005-04-12 Avaya Technology Corp. Firewall clustering for multiple network servers
US6779039B1 (en) * 2000-03-31 2004-08-17 Avaya Technology Corp. System and method for routing message traffic using a cluster of routers sharing a single logical IP address distinct from unique IP addresses of the routers
US7209959B1 (en) * 2000-04-04 2007-04-24 Wk Networks, Inc. Apparatus, system, and method for communicating to a network through a virtual domain providing anonymity to a client communicating on the network
US7472200B1 (en) * 2003-12-03 2008-12-30 Cisco Technology, Inc. Arrangement in a multi-homed transport endpoint for selecting a source address based on source-destination address pair metrics
KR100737360B1 (en) * 2006-10-20 2007-07-09 한국전자통신연구원 Root mobile router and operation method thereof in dynamically composed moving network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014698A (en) * 1997-05-19 2000-01-11 Matchlogic, Inc. System using first banner request that can not be blocked from reaching a server for accurately counting displays of banners on network terminals
US6119171A (en) * 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing
US6262976B1 (en) * 1998-09-17 2001-07-17 Ordered Networks, Inc. System and method for network flow optimization using traffic classes
US6182148B1 (en) * 1999-03-18 2001-01-30 Walid, Inc. Method and system for internationalizing domain names

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1323528C (en) * 2004-10-22 2007-06-27 中国科学院计算技术研究所 Automatic configuration method for internet domain server in self-organizing net
US7711853B2 (en) 2006-07-14 2010-05-04 Microsoft Corporation Resolving names to network endpoints

Also Published As

Publication number Publication date
US20130159464A1 (en) 2013-06-20
US7209959B1 (en) 2007-04-24
US8762498B2 (en) 2014-06-24
US20070162590A1 (en) 2007-07-12
AU2001250867A1 (en) 2001-10-15
WO2001075556A3 (en) 2002-01-03
US8370457B2 (en) 2013-02-05

Similar Documents

Publication Publication Date Title
US8370457B2 (en) Network communication through a virtual domain
EP1175767B1 (en) Methods for determining, collecting, and using geographic locations of internet users
JP7045104B2 (en) How to process data, devices and computer programs, and zone files for hierarchical Domain Name System
EP1699189B1 (en) Geo-intelligent router
US20060224752A1 (en) Determining geographic locations of private network Internet users
US20020073233A1 (en) Systems and methods of accessing network resources
US7443825B2 (en) Method and apparatus for providing a stand-alone wireless web service
US20060218289A1 (en) Systems and methods of registering and utilizing domain names
JP2001103092A (en) Dns inquiry device, dns inquiry method and recording medium
US7844729B1 (en) Geo-intelligent traffic manager
Blanchet Finding the Authoritative Registration Data (RDAP) Service
Yan et al. Is DNS ready for ubiquitous Internet of Things?
WO2002013459A2 (en) Determining geographic locations of private network internet users
KR20020007977A (en) Web On Demand System
Afanasyev et al. Map-and-encap for scaling ndn routing
US20020065936A1 (en) Multi-platform application
US20030225910A1 (en) Host resolution for IP networks with NAT
WO2004049637A1 (en) Geo-intelligent traffic manager
CN103297444A (en) Identity analysis method and device
Abegaz DNS Services, alternative ways of using DNS infrastructures
Kosonen A New layered naming architecture

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP