US20040078490A1 - Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents - Google Patents

Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents Download PDF

Info

Publication number
US20040078490A1
US20040078490A1 US10/686,135 US68613503A US2004078490A1 US 20040078490 A1 US20040078490 A1 US 20040078490A1 US 68613503 A US68613503 A US 68613503A US 2004078490 A1 US2004078490 A1 US 2004078490A1
Authority
US
United States
Prior art keywords
data collection
geographic location
location
confidence
location information
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
US10/686,135
Other versions
US7809857B2 (en
Inventor
Mark Anderson
Ajay Bansal
Brad Doctor
George Hadjiyiannis
Christopher Herringshaw
Eli Karplus
Derald Muniz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Bank AG New York Branch
Original Assignee
Individual
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
Application filed by Individual filed Critical Individual
Priority to US10/686,135 priority Critical patent/US7809857B2/en
Publication of US20040078490A1 publication Critical patent/US20040078490A1/en
Application granted granted Critical
Publication of US7809857B2 publication Critical patent/US7809857B2/en
Assigned to MORGAN STANLEY SENIOR FUNDING, INC. reassignment MORGAN STANLEY SENIOR FUNDING, INC. SECURITY AGREEMENT Assignors: NEUSTAR DATA SERVICES, INC., NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC., ULTRADNS CORPORATION
Assigned to NEUSTAR IP INTELLIGENCE, INC. reassignment NEUSTAR IP INTELLIGENCE, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: QUOVA, INC.
Assigned to NEUSTAR, INC., AGGREGATE KNOWLEDGE, INC., ULTRADNS CORPORATION, NEUSTAR DATA SERVICES, INC., NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., MARKETSHARE ACQUISITION CORPORATION, MARKETSHARE HOLDINGS, INC., MARKETSHARE PARTNERS, LLC reassignment NEUSTAR, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: MORGAN STANLEY SENIOR FUNDING, INC.
Assigned to BANK OF AMERICA, N.A. reassignment BANK OF AMERICA, N.A. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AGGREGATE KNOWLEDGE, INC., MARKETSHARE PARTNERS LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC.
Assigned to UBS AG, STAMFORD BRANCH reassignment UBS AG, STAMFORD BRANCH SECOND LIEN PATENT SECURITY AGREEMENT Assignors: AGGREGATE KNOWLEDGE, INC., MARKETSHARE PARTNERS LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC.
Assigned to JPMORGAN CHASE BANK, N.A reassignment JPMORGAN CHASE BANK, N.A GRANT OF SECURITY INTEREST IN UNITED STATES PATENTS Assignors: AGGREGATE KNOWLEDGE, LLC, EBUREAU, LLC, IOVATION, INC., MARKETSHARE PARTNERS, LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC., SIGNAL DIGITAL, INC., SONTIQ, INC., TRANS UNION LLC, TRANSUNION HEALTHCARE, INC., TRANSUNION INTERACTIVE, INC., TRANSUNION RENTAL SCREENING SOLUTIONS, INC., TRANSUNION TELEDATA LLC, TRU OPTIK DATA CORP., TrustID, Inc.
Assigned to DEUTSCHE BANK AG NEW YORK BRANCH reassignment DEUTSCHE BANK AG NEW YORK BRANCH GRANT OF SECURITY INTEREST IN PATENT RIGHTS Assignors: MARKETSHARE PARTNERS, LLC, NEUSTAR DATA SERVICES, INC., NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC., SONTIQ, INC., TRU OPTIK DATA CORP., TrustID, Inc.
Assigned to NEUSTAR, INC., AGGREGATE KNOWLEDGE, INC., MARKETSHARE PARTNERS LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC. reassignment NEUSTAR, INC. SECOND LIEN PATENT SECURITY AGREEMENT RELEASE Assignors: UBS AG, STAMFORD BRANCH
Assigned to NEUSTAR, INC., AGGREGATE KNOWLEDGE, INC., MARKETSHARE PARTNERS LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC. reassignment NEUSTAR, INC. FIRST LIEN PATENT SECURITY AGREEMENT RELEASE Assignors: BANK OF AMERICA, N.A.
Assigned to TRANSUNION INTERACTIVE, INC., TRANS UNION LLC, NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., TRANSUNION TELEDATA LLC, TRU OPTIK DATA CORP., IOVATION, INC., NEUSTAR, INC., MARKETSHARE PARTNERS, LLC, SIGNAL DIGITAL, INC., AGGREGATE KNOWLEDGE, LLC, SONTIQ, INC., EBUREAU, LLC, TrustID, Inc., TRANSUNION RENTAL SCREENING SOLUTIONS, INC. reassignment TRANSUNION INTERACTIVE, INC. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161 Assignors: JPMORGAN CHASE BANK, N.A.
Assigned to DEUTSCHE BANK AG NEW YORK BRANCH reassignment DEUTSCHE BANK AG NEW YORK BRANCH CORRECTIVE ASSIGNMENT TO CORRECT THE APPLICATION NO. 16/990,698 PREVIOUSLY RECORDED ON REEL 058294 FRAME 0010. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: MARKETSHARE PARTNERS, LLC, NEUSTAR DATA SERVICES, INC., NEUSTAR INFORMATION SERVICES, INC., NEUSTAR IP INTELLIGENCE, INC., NEUSTAR, INC., SONTIQ, INC., TRU OPTIK DATA CORP., TrustID, Inc.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • H04L61/3015Name registration, generation or assignment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29Geographical information databases
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/35Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • 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/52Network services specially adapted for the location of the user terminal
    • 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
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/30Types of network names
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface

Definitions

  • the present invention relates generally to the field of geographic location determination and, more specifically, to a method and apparatus for estimating the geographic location of a network entity, such as a node coupled to the Internet.
  • Geography plays a fundamental role in everyday life and effects, for example, of the products that consumers purchase, shows displayed on TV, and languages spoken.
  • Information concerning the geographic location of a networked entity, such as a network node, may be useful for any number of reasons.
  • Geographic location may be utilized to infer demographic characteristics of a network user. Accordingly, geographic information may be utilized to direct advertisements or offer other information via a network that has a higher likelihood of being the relevant to a network user at a specific geographic location.
  • Geographic information may also be utilized by network-based content distribution systems as part of a Digital Rights Management (DRM) program or an authorization process to determine whether particular content may validly be distributed to a certain network location. For example, in terms of a broadcast or distribution agreement, certain content may be blocked from distribution to certain geographic areas or locations.
  • DRM Digital Rights Management
  • Content delivered to a specific network entity, at a known geographic location may also be customized according to the known geographic location. For example, localized news, weather, and events listings may be targeted at a network entity where the geographic location of the networked entity is known. Furthermore content may be presented in a local language and format.
  • Knowing the location of network entity can also be useful in combating fraud. For example, where a credit card transaction is initiated at a network entity, the location of which is known and far removed from a geographic location associated with a owner of credit card, a credit card fraud check may be initiated to establish the validity of the credit card transaction.
  • a method to collect geographic location information is provided. Geographic location information, associated with at least one network address, is collected utilizing a plurality of geographically dispersed data collection agents. The geographic location information is utilizing to associate a geographic location with the network address.
  • FIG. 1A is a diagrammatic representation of a deployment of a geolocation system, according to an exemplary embodiment of the present invention, within a network environment.
  • FIG. 1B is a block diagram providing architectural details regarding a geolocation system, according to an exemplary embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating software architecture for a geolocation system, according to an exemplary embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of collecting data utilizing a number of data collection agents.
  • FIG. 4A is a state diagram illustrating general dataflow within the geolocation system, according to an exemplary embodiment of the present invention.
  • FIG. 4B is a state diagram illustrating dataflow, according to an exemplary embodiment of the present invention, during a geolocation data collection and analysis process.
  • FIG. 5 is a diagrammatic overview of dataflow pertaining to a data warehouse, according to an exemplary embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating operation of a data collection agent, according to an exemplary embodiment of the present invention, upon receipt of a request from an associated data collection broker.
  • FIG. 7 is a flowchart illustrating operation of a data collection broker, according to an exemplary embodiment of the present invention, upon receipt of a job request from a user via an interface.
  • FIG. 8 is a diagrammatic representation of operation of an analysis module, according to an exemplary embodiment of the present invention.
  • FIGS. 9A and 9B show a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of tiered estimation of a geolocation associated with a network address.
  • FIG. 11 is a block diagram illustrating a process flow for a unified mapping process, according to an exemplary embodiment of the present invention.
  • FIGS. 12A and 12B illustrate respective one-dimensional and two-dimensional confidence maps, according to exemplary embodiments of present invention.
  • FIG. 13 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a RegEx LDM to identify one or more geographic locations associated with network address and associated at least one confidence factor with each of the identified geographic locations.
  • FIGS. 14 A- 14 Q illustrate an exemplary collection of confidence maps that may be utilized by the RegEx LDM to attach confidence factors to location determinants.
  • FIG. 15 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by the Net LDN to identify one or more geographic locations for a network address, or a block of network addresses, and to associated at least one confidence factor with each of the geographic locations.
  • FIGS. 16 A- 16 E illustrate an exemplary collection of confidence maps that may be utilized by the Net LDM to attach confidence factors to location determinants.
  • FIG. 17 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by the DNS LDM identify one or more geographic locations for network address, and to associated at least one confidence factor with each of the geographic locations.
  • FIGS. 18 A- 18 E illustrate an exemplary collection of confidence maps that may be utilized by the DNS LDM to attach confidence factors to location determinants.
  • FIGS. 19 A- 19 E illustrate an exemplary collection of confidence maps that may be utilized by the ASN LDM to attach confidence factors to location determinants.
  • FIGS. 20 A- 20 C illustrate an exemplary collection of confidence maps that may be utilized by the LKH LDM to attach confidence factors to location determinants.
  • FIGS. 21 A- 21 C illustrate an exemplary collection of confidence maps that may be utilized by the NKH LDM to attach confidence factors to location determinants.
  • FIG. 22 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a sandwich LDM to identify one or more geographic locations for a network address, and to associate at least one confidence factor with each of the geographic locations.
  • FIG. 23 illustrate an exemplary confidence that may be utilized by the sandwich LDM to attach confidence factors to location determinants.
  • FIG. 24 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of filtering location determinants received from a collection of LDMs utilizing a filter location determinants.
  • FIG. 25 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a location synthesis process to deliver a single location determinant that the unified mapping process has identified as a best estimate of a geographic location.
  • FIG. 26 is a graph illustrating correctness of location determinants, as a function of a post-location synthesis process confidence factor.
  • FIG. 27 is a graph illustrating correctness of location determinants as a function of post-location synthesis process confidence factor, and a smoothed probability of correctness given a confidence factor range.
  • FIG. 28 is a graph illustrating correctness of location determinants as a function of a post-location synthesis process confidence factor, and a smoothed probability of correctness given a confidence factor range.
  • FIG. 29 is a graph illustrating correctness of location determinants as a function of a post-confidence accuracy translation confidence factor, and a smoothed probability of correctness.
  • FIG. 30 shows a diagrammatic representation of a machine in exemplary form of a computer system within which a set of instructions, for causing the machine to perform any of the methodologies discussed above, may be executed.
  • the term “geographic location” shall be taken to refer to any geographic location or area that is identifiable utilizing any descriptor, metric or characteristic.
  • the term “geographic location” shall accordingly be taken to include a continent, a country, a state, a province, a county, a city, a town, village, an address, a Designated Marketing Area (DMA), a Metropolitan Statistical Area (MSA), a Primary Metropolitan Statistical Area (PMSA), location (latitude and longitude), zip or postal code areas, and legislative districts.
  • DMA Designated Marketing Area
  • MSA Metropolitan Statistical Area
  • PMSA Primary Metropolitan Statistical Area
  • location latitude and longitude
  • zip or postal code areas and legislative districts.
  • the term “location determinant” shall be taken to include any indication or identification of a geographic location.
  • network address for purposes of the present specification, shall be taken to include any address that identifies a networked entity, and shall include Internet Protocol (IP) addresses.
  • IP Internet Protocol
  • IP addresses are associated with a particular geographic location. This is because routers that receive packets for a particular set of machines are fixed in location and have a fixed set of network addresses for which they receive packets. The machines that routers receive packets for tend to be geographically proximal to the routers. Roaming Internet-Ready devices are rare exceptions. For certain contexts, it is important to know the location of a particular network address. Mapping a particular network address to a geographic location may be termed “geolocation”. An exemplary system and methodology by which geographic locations can be derived for a specific network addresses, and for address blocks, are described below. Various methods of obtaining geographic information, combining such geographic information, and inferring a “block” to which a network address corresponds and which shares the same geographic information are described.
  • the exemplary system and method described below include (1) a data collection stage, (2) a data analyses stage, and (3) a delivery stage.
  • FIG. 1A is a diagrammatic representation of a deployment of a geolocation system 10 , according to an exemplary embodiment of the present invention, within a networked environment 8 .
  • the geolocation system 10 is shown to include: (1) a data collection and analysis system 12 that is responsible for the collection and analysis of information useful in geolocating a network address; (2) a delivery engine system 16 , including a number of delivery engine servers 64 , which operate to provide geolocation information to a customer; and (3) a data warehouse 30 that stores collected information useful for geolocation purposes and determining geolocations for specific network addresses (or blocks of network addresses).
  • Geolocation data is distributed from the data warehouse 30 to the delivery engine system 16 for delivery to a customer in response to a query.
  • the data collection and analysis system 12 operates continuously to identify blocks of network addresses (e.g., Class B or Class C subnets) as will be described in further detail below, and to associate a geographic location (geolocation) with the identified blocks of network addresses.
  • a record is then written to the data warehouse 30 for each identified block of network addresses, and associated geolocation.
  • a record within the data warehouse 30 identifies a block of network addresses utilizing a subnet identifier.
  • a record within the data warehouse identifies a start and end network address for a relevant block of network addresses.
  • a record identifies only a single network address and associated geolocation.
  • the data collection and analysis system 12 operates to continually updated and expand the collection of records contained within the data warehouse 30 .
  • An administrator of the data collection and analysis system 12 may furthermore optionally directed the system 12 to focus geolocation activities on a specific range of network addresses, or to prioritize geolocation activities with respect to specific range of network addresses.
  • the data collection and analysis system 12 furthermore maintains a log of network addresses received that did not map to a block of network addresses for which a record exists within the data warehouse 30 .
  • the data collection and analysis system may operate to prioritize geolocation activities to determine geolocation information for network addresses in the log.
  • an Internet user may, utilizing a user machine that hosts a browser 1 , access a web site operated by the customer.
  • the custom website is supported by the application server 6 , which upon receiving an IP address associated with the user machine 2 , communicates this IP address to the geolocation Application Program Interface (API) 7 hosted that the customer site. Responsive to receiving the IP address, the API 7 communicates the IP address to a delivery engine server 64 of the delivery engine system 16 .
  • API Application Program Interface
  • the data collection and analysis system 12 generates a location determinant, indicating at least one geographic location, and an associated location probability table, that is communicated back to the customer. More specifically, the delivery engine server 64 attempts to identify a record for a block of network addresses to which the received IP address belongs. If the delivery engine server 64 is successful in locating such a record, geolocation information (e.g., a location determinant) stored within that record is retrieved and communicated back to the customer.
  • geolocation information e.g., a location determinant
  • the delivery engine server 64 is unsuccessful in locating a record within the data warehouse 30 , the relevant IP address is logged, and a “not found” message is communicated to the customer indicating the absence of any geolocation information for the relevant IP address.
  • the customer is then able to utilize the location determinant for any one of multiple purposes (e.g., targeted advertising, content customization, digital rights management, fraud detection etc.)
  • purposes e.g., targeted advertising, content customization, digital rights management, fraud detection etc.
  • FIG. 1B is a block diagram providing further details regarding a physical architecture for the geolocation system 10 , according to an exemplary embodiment of the present invention.
  • the geolocation system 10 comprises the data collection and analysis system 12 , a data warehouse system 14 , and the delivery engine system 16 .
  • FIG. 2 is a block diagram illustrating software architecture for the geolocation system 10 , according to an exemplary embodiment of the present invention.
  • the data collection and analysis system 12 is shown to collect data from geographically dispersed, strategically placed remote data collection agents 18 , hosted on data collection machines 20 .
  • a group of data collection agents 18 is controlled by a data collection broker 22 , which may be hosted on a data analysis server 24 .
  • the data collected by a data collection broker 22 is delivered to a data collection database 26 , and is analyzed utilizing an analysis module 28 .
  • the analysis module 28 implements a number of analysis techniques to attach a known or estimated geographic location to certain network information (e.g., the source or destination address of a network request).
  • a resulting location record, along with all supporting information, is then written into a data warehouse 30 of the data warehouse system 14 .
  • the geolocation system 10 in one embodiment, supports the following features:
  • FIG. 2 illustrates a number of a data collection agents 18 hosted at geographically disperse locations. For example, these disperse locations may be with separate service providers. The location of the data collection agents 18 at disperse locations assists the geolocation system 10 by providing different “points of view” on the network target.
  • Each data collection agent 18 is responsible for actual execution of a data collection process, or search, to locate and extract data that is the useful for the determination of a geolocation. Further details regarding exemplary searches are provided below.
  • a traceroute search is conducted by a data collection agent 18 responsive to a search request received at a data collection agent 18 from a data collection broker 22 .
  • Each data collection agent 18 responsive to a request, will perform a search (e.g., a traceroute) to collect specified data, and determine the validity of the raw data utilizing built-in metrics. If successful, this data is provided to the data collection database 26 , via a data collection broker 22 , for analysis by the analysis module 28 .
  • Each data collection agent 18 further advises a controlling data collection broker 22 of the success or failure of a particular search.
  • Each data collection broker 22 controls a group of data collection agents 18 . For example, given a network address, or a range of network addresses, a data collection broker 22 determines which data collection agents 18 are most appropriate for the specific search. Once the request has been sent to a group of data collection agents 18 from a data collection broker 22 , a response is expected containing a summary of the search. If the search was successful, this information will be placed directly into the data collection database 26 , at which time the analysis module 28 will determine an estimated geolocation of the searched addresses.
  • the data collection broker 22 takes the appropriate action, and the data is not entered into the data collection database 26 . At this time, the data collection broker 22 hands the search request to another data collection broker 22 , which performs the same process.
  • the data collection database 26 contains current state information, as well as historical state information.
  • the state information includes statistics generated during the data acquisition by the data collection agents 18 , as well as failure statistics. This allows an operator of the geolocation system 10 to visualize the actual activity of a data collection process.
  • FIG. 3 is a flowchart illustrating a method 38 , according to an exemplary embodiment of the present invention, of collecting data utilizing a number of data collection agents 18 .
  • a user enters a job request to the data collection broker 22 via, for example, a web interface. Job scheduling is also an option for the user.
  • the relevant data collection broker 22 accepts a request, and determines what data collection agents 18 will service the request.
  • the data collection broker 22 also sets a unique session identifier (USID).
  • USID unique session identifier
  • one or more data collection agents 18 accept a job, and report to the data collection broker 22 that submission was successful.
  • the data collection broker 22 writes (1) a start mark, indicating that the job is underway, and (2) the unique session identifier to the data collection database 26 .
  • the data collection agents 18 perform various searches (e.g., traceroutes) to collect raw data, and stores results locally for later batch update.
  • each of the data collection agents 18 informs the data collection broker 22 that the search has finished, with or without success. After the last data collection agent 18 reports its status, the data collection broker 22 instructs the data collection agents 18 to upload their information to the data collection database 26 .
  • the data collection broker 22 instructs the data collection agents 18 to flush their local storage, and remain idle until the next search job.
  • the analysis module 28 processes the newly entered data within the data collection database 26 , and writes this data to the data warehouse 30 .
  • the delivery engine system 16 is responsible for delivering geolocation information generated by the geolocation system 10 .
  • the delivery engine system 16 may be viewed as comprising a delivery staging server 60 , a statistics processing engine 62 , one or more delivery engine servers 64 and a delivery engine plant daemon (not shown)
  • the delivery staging server 60 provides a reliable and scaleable location distribution mechanism for geolocation data and does not modify any data.
  • the delivery staging server 60 provides a read-only copy of the geolocation information to the delivery engine servers 64 , and is responsible for preparing geolocation information that should be distributed to the delivery engine servers 64 .
  • Each delivery staging server 60 prepares dedicated information for one product offering.
  • the delivery staging server 60 will retrieve the geolocation information from the data warehouse 30 based on the product offering.
  • the delivery staging server 60 configuration includes a customer list and a delivery engine servers list for deployment. At fixed intervals, geolocation information is refreshed from the data warehouse 30 and distributed to the delivery engine service 64 .
  • the refresh from the data warehouse 30 may be based on a number of factors such as a new product offering or refining the existing location data.
  • the delivery staging server 60 retrieves a current copy of customers and the delivery engine servers 64 associated with the relevant delivery staging server 60 .
  • the administration of the delivery staging servers 60 is performed by a separate server that is also responsible for load balancing and backup configuration for the delivery staging servers 60 .
  • the statistics processing engine 62 is responsible for retrieving customer access logs (hits and misses) and usage data from the delivery engine services 64 on a regular basis. This information is used, for example, as input for the load balancing criteria, and getting update information for the location misses. The usage statistics may also provide the required information to the billing subsystem.
  • All information sent to delivery engine service 64 is encrypted to prevent unauthorized use.
  • the delivery engine servers 64 are responsible for serving the clients of the geolocation system 10 .
  • the delivery engine servers 64 may be hosted at a client site or at a central data center.
  • the delivery engine servers 64 are able to accept update information from the delivery staging server 60 and to serve current requests.
  • Each delivery engine servers 64 saves all customer access information and provide this information to the statistics processing engine 62 .
  • each delivery engine server 64 provides an eXtensible Markup Language (XML)-based Application Program Interface (API) interface to the customers of the geolocation system 10 .
  • XML eXtensible Markup Language
  • API Application Program Interface
  • a geolocation API 7 interfaces with a delivery engine server 64 from a customer application server.
  • the geolocation API 7 may support a local cache to speed up the access, this cache being flushed whenever the delivery engine server 64 is reloaded.
  • the geolocation API 7 may be configured to access an alternate server in case of a failure or high load on a single delivery engine server 64 .
  • Each delivery engine server 64 and delivery staging server 60 includes a Simple Network Management Protocol (SNMP) agent for network management.
  • SNMP Simple Network Management Protocol
  • FIG. 4A is a state diagram illustrating general data flow, as described above and according to an exemplary embodiment of the present invention, within the geolocation system 10 .
  • FIG. 4B is a state diagram illustrating data flow, according to an exemplary embodiment of the present invention, during the geolocation data collection and analysis processes described above.
  • the analysis module 28 retrieves geolocation information from the data collection database 26 to which all data collection agents 18 write such information, in the manner described above. Specifically, the analysis module 28 operates a daemon, polling in a timed interval for new data within the data collection database 26 . When new data is found, the analysis techniques embodied within sub-modules (Location Determination Modules LDMs) of the analysis module 28 are initiated, with the results of these analysis techniques being written to the primary data warehouse 30 .
  • LDMs Location Determination Modules
  • FIG. 5 provides an overview of data flow pertaining to the data warehouse 30 , according to an exemplary embodiment of the present invention.
  • data collection is performed by the data collection and analysis system 12 .
  • the results of the collection process are aggregated in the data collection database 26 , which is an intermediary datastore for collection data.
  • data is taken from the database 26 by the analysis module 28 , and the final analysis, along with all the supporting data, is placed into the data warehouse 30 .
  • the delivery staging servers 16 then pull a subset of data from the data warehouse 30 (this defines a product offering), and place this information into a staging database (not shown) associated with the delivery staging server 60 .
  • a staging database then pushes a copy of the geolocation information out to all delivery engine servers 64 , which run a particular product offering.
  • the delivery staging servers 60 may provide the following customer information to the data warehouse 30 :
  • the delivery staging servers 60 process requests from a client application by:
  • the delivery staging servers 60 process database updates by storing a new database with a version number on disk and building a new in-memory database for updates. Each update is a complete replacement of the existing in-memory database
  • the statistics processing engine 62 activates after a given period of time, checks the data warehouse 30 for a list of active client machines, and retrieves the statistics files from all of the deployed delivery engine servers 64 . Once such files have been retrieved, the statistics processing engine 62 pushes the statistics into the data warehouse 30 .
  • the geolocation system 10 utilizes eXtensible Markup Language (XML) as a data transfer format, both within the above-mentioned subsystems, and as the delivery agent to customer systems.
  • XML eXtensible Markup Language
  • XML offers flexibility of format when delivering geolocation information, and extensibility when the geolocation system 10 offers extended data in relation to geographic location, without having to reprogram any part of the client interfaces.
  • a standard XML parser technology may be deployed throughout the geolocation system 10 , the parser technology comprising either the Xerces product, a validating parser offered by the Apache group, or XML for C++, written by the team at IBM's AlphaWorks research facility, which is based on the Xerces parser from Apache, and includes Unicode support and other extensions.
  • the geolocation system 10 utilizes numerous Document Type Definitions (DTDs) to support the XML messaging. DTDs serve as templates for valid XML messages.
  • DTDs Document Type Definitions
  • a location probability table may be an XML formatted message, containing a table of information representing location granularity (or resolution), location description, and a confidence percentage.
  • the location probability table indicates multiple levels of geographic location granularity or resolution, and provides a location probability (or confidence factor) for each of these levels of geographic resolution. For example, at a “country” level of geographic resolution, a relatively high probability level may be indicated. However, at a “city” level of geographic resolution, a relatively low probability level may be indicated in view of a lower confidence in the geolocation of the network entity at an indicated city.
  • the above location probability table constitutes a XML response to a geolocation request for the IP address 128.52.46.11.
  • the city where the address is located is Cambridge, Mass., USA, identified with granularity (or geographic resolution) down the zip code level, at a 91% confidence.
  • the location probability table may be formatted according to a proprietary bar delimited format specification.
  • a data collection agent 18 operates to receive commands from an associated data collection broker 22 , and includes logic to execute a number of data collection operations specific to a number of analysis processes implemented by the analysis module 28 . Each data collection agent 18 reports results back to an associated data collection broker 22 that performs various administrative functions (e.g., start, stop, restart, load, process status).
  • FIG. 6 is a flowchart illustrating functioning of a data collection agent 18 , according to an exemplary embodiment of the present invention, upon receipt of a request from an associated data collection broker 22 .
  • a data collection broker 22 determines what actions are required responsive to a request from a customer (e.g., check new addresses, recheck older addresses, etc.), and provides instructions to one or more data collection agents 18 regarding what function(s) to perform with respect to certain network information (e.g., a network address).
  • Each data collection broker 22 further stores raw data (geolocation information) into the data collection database 26 , performs load balancing of requests across multiple data collection agents 18 , performs administrative functions with respect to data collection agents 18 (e.g., requests stops, starts, status etc.) and performs various internal administrative functions (e.g. start, stop, restart, load).
  • FIG. 7 is a flowchart illustrating functioning of a data collection broker 22 , according to an exemplary embodiment of the present invention, upon receipt of a job request from a user via a Web interface or any other interface.
  • the analysis module 28 operates to extract raw data from the data collection database 26 , process the data according to one or more analysis algorithms (or modules) to generate a location probability table, and to store results and the raw data into the data warehouse 30 .
  • FIG. 8 is a diagrammatic representation of operation of the analysis module 28 , according to an exemplary embodiment of the present invention.
  • the delivery engine servers 64 except queries (e.g., in XML format), return responses, lookup query information in a main memory database, report statistics to flat files for the data processing, respond to administrative functions, and except push updates to create second run-time databases and perform switchover.
  • queries e.g., in XML format
  • return responses e.g., in XML format
  • lookup query information in a main memory database e.g., in XML format
  • report statistics to flat files for the data processing e.g., respond to administrative functions, and except push updates to create second run-time databases and perform switchover.
  • the delivery servers 64 operate to scan content within the data warehouse 30 , creating specific service offerings (e.g., North America, by continent, by country), and push content out to the delivery engine servers 64 .
  • specific service offerings e.g., North America, by continent, by country
  • each of the data collection agents 18 may implement one of multiple data collection processes to obtain raw geolocation information. These data collection processes may, in one exemplary embodiment of the present invention, access any one or more of the following data sources:
  • Net Whois Record is an entry in a registry that tracks ownership of blocks of Internet Protocol (IP) addresses and address space. Such records are maintained by RIPE (Reseaux IP Europeens), APNIC (Asia Pacific Network Information Centre), ARIN (American Registry of Internet Numbers), and some smaller regional Internet registries. For instance, the IP network address 192.101.138.0 is registered to Western State College in Gunnison, Colo.
  • IP Internet Protocol
  • DNS Whois Record The DNS Whois record is an entry in a registry that tracks ownership of domain names. This is maintained by Network Solutions, Inc. For instance, quova.com is registered to Quova, Inc. in Mountain View, Calif.
  • ASN Whois Record is an entry in a registry that tracks autonomous systems.
  • An autonomous system is a collection of routers under a single administrative authority using a common Border Gateway Protocol for routing packets.
  • ASN databases are maintained by a number of organizations.
  • DNS Loc Record Occasionally, a DNS Location (Loc for short) record is stored, which indicates the precise latitude, longitude, and elevation of a host.
  • Traceroute shows the route of a data packet from a data collection machine to a target host. Much information can be derived from the analysis of a traceroute. For instance, if hop #10 is in California, and hop #13 is in California, then with increased certainty, it can be inferred that hops #11 and #12 are also in California.
  • the analysis module 28 may also utilize the following information sources in performing an analysis to estimate a geographic location for network address:
  • Hostname An IP network address is often tied to a hostname. The hostname may have information indicative of location. Carriers typically implement this to more easily locate their own hardware. For instance, bbr-g2-0.sntc04.exodus.net is in Santa Clara, Calif.; ‘sntc’ is Exodus' abbreviation for Santa Clara.
  • the analysis module 28 utilizes a demographic/geographic database 31 , shown in FIGS. 1B and 2 to be part of the data warehouse 30 , storing a city record for every city in the U.S.A. and all foreign cities with populations of greater than 100,000 people. Tied to each city are its state, country, continent, DMA (Designated Marketing Area), MSA (Metropolitan Statistical Area), PMSA (Primary Metropolitan Statistical Area), location (latitude & longitude), sets of zip/postal codes, legislative districts, and area codes. Each city record also has population and a connectivity index, which is based on the number of major carriers that have presence in that city.
  • the analysis module 28 includes a collection of blocking algorithms 63 , a unified mapping process 61 , and a consolidated domains algorithm 65 .
  • FIGS. 9A and 9B show a flowchart illustrating a method 70 , according to an exemplary embodiment of the present invention, of tiered estimation of the geolocation associated with a network address. Specifically the tiered estimation of a geolocation employs a number of exact processes and, if the exact processes fail, a number of inexact processes. In an alternative embodiment of the present invention, no distinction is made between exact and inexact processes (as shown in FIG. 11), and all processes are regarded as being located on a common tier.
  • the method 70 is performed by the analysis module 28 , and employs each of the algorithms 61 , 63 and 65 .
  • the method 70 commences at block 72 with the obtaining of a network address (e.g., an IP address) to be mapped.
  • a network address e.g., an IP address
  • This network address may be received from an internal process performing an automated mapping operation (e.g., updating the geolocation information associated with a specific IP address), or from an external source (e.g., a customer that requires geolocation information concerning an IP address).
  • the obtained network address is then queued within a main queue.
  • the consolidated domain algorithm 65 is run. Specifically, a network address is removed from the main queue, and tested to determine whether it is likely to fall within a consolidated domain. If the tests of satisfied, as determined at decision block 76 , the relevant network address and the geolocation information determined by the consolidated domains algorithm 65 are written to a record within the data warehouse 30 at block 78 .
  • the consolidated domain algorithm 65 utilizes the fact that some domains have all of their IP network addresses concentrated in a single geographic location. The domain suitability is judged by the algorithm 65 on the basis of other domain properties other than size. Such domains typically include colleges and universities (except those that have multiple campuses), small businesses that are known to be located in a single location, government labs, etc.
  • Examples of domains that may be utilized by the algorithm 65 include:
  • the “.edu” domain Because of the nature of educational institutions, “.edu” domains are typically consolidated domains. An extensive list of “.edu” domains can be obtained from web resources (by looking up the appropriate categories under the main search engines). IP lists (from web-server access logs, etc.) can also be translated to names and checked for an ending “.edu”. Then they can be sorted into unique names.
  • ISPs Local Internet Service Providers
  • the above described method may encounter domain names that contain extraneous information (e.g., “glen.lcs.mit.edu”), when in fact the domain name required is “mit.edu”.
  • domain names that contain extraneous information
  • glen.lcs.mit.edu In general, the name behind the “.edu.” entry is part of the domain but everything before it is extraneous (note that this will include .edu domains in other countries). This also holds for government labs (“x.gov”), and commercial (“x.com”). Names derived from the above methods are pre-processed to truncate them to the appropriate domain name according to the above rules.
  • blocking algorithms 63 are executed to determine a network address block size around the relevant network address. Further details regarding exemplary blocking algorithms 63 are provided below.
  • a blocking algorithm 63 performs a check of neighboring network addresses to find the expanse of a “block” of network addresses that share common information (e.g., a common subnet segment). The identification of a block of network addresses is useful in that information regarding a particular network address may often be inferred from known information regarding neighboring network addresses within a common block.
  • one or more “exact” geographic location processes are run to determine whether geolocation information can be determined for the subject network address, and optionally for other network addresses of the block of network addresses.
  • the “exact” processes are labeled as such as they render geolocation information with a relatively high confidence factor. Further, the exact processes may render geolocation information for neighboring network addresses within a block to increase the confidence factor of geolocation information rendered for a subject network addresses.
  • the method 70 progresses to block 92 , where a series of “inexact” geographic location operations (or algorithms) are executed on the subject network address, and optionally on one or more network addresses within an associated block.
  • the “inexact” processes are labeled as such in view of the relatively lower confidence factor with which these inexact processes render geolocation information associated with a network address.
  • a number of inexact processes are executed on a number of network addresses surrounding a subject network address, and the outputs of these inexact processes are consolidated by the unified mapping process 61 , which considers the output from each of the number of inexact processes (e.g., the below discussed Location Determination Modules (LDMs)). Further details are provided below.
  • LDMs Location Determination Modules
  • Queuing interfaces exist for both processes (e.g., scripts or algorithms) scripts that enter items into the main queue discussed above, as well as for processes that remove items form the main queue.
  • one or more blocking algorithms 63 are executed at block 82 shown in FIG. 9A to identify a “block” of network addresses surrounding a subject network address that may share common information or characteristics with the subject network address.
  • Three exemplary blocking algorithms 63 to perform a blocking operation around a subject network address are discussed below, namely: (1) a divide-and-conquer blocking algorithm; (2) a netmask blocking algorithm; and (3) a blocking algorithm that utilizes RTP tables, BGP tables, and ISP topology maps.
  • the entire network segment can be processed by the exact and inexact processes, and return one complete record for each network that he stored within the data warehouse 30 . This is advantageous in that the number of hosts that are required to be processed is reduced, and the amount of data that is required to be collected is also reduced.
  • the divide-and-conquer blocking algorithm receives a subject network address, and possibly the associated information (e.g. location), and checks neighboring network addresses to find the extent of the block of network addresses that share the common information.
  • the algorithm starts with a first test network address halfway to the end of a block and test with a predicate to determine whether the first test network address has same information as the subject network address.
  • the “distance” between the subject network address and the first network address is then halved and the result added to the current distance if the answer was positive, or subtracted from the current distance if the answer was negative. This process is repeated until the distance offset is one.
  • the divide-and-conquer blocking algorithm then returns to the top end Qf the block and, after competing an iteration, returns to the bottom end of the block.
  • test_pred( ) This takes an IP network address and returns true if this IP network address shares the same information (i.e., is part of the same block) as the subject IP network address.
  • test predicate The function of the test predicate is to discover if the new network addresses explored by the divide-and-conquer algorithm belong to the same block as the subject network address.
  • this test predicate can be implemented. For example:
  • the unified mapping process 61 can be run on the test network address to derive a location and this location can be matched against the location of the subject network address. This imposes a relatively large-overhead per iteration of the divide-and-conquer algorithm.
  • Traceroute information If the subject network address and the test network address follow the same route (modulo the last hop) then the network addresses are part of the same block.
  • DNS service This test renders a positive result if the test network address and the subject network address use the same DNS server.
  • test predicates may be devised to implement blocking.
  • the netmask blocking algorithm relies on the assumption that a subnet will generally not be spread over multiple locations. If parts of a block of network addresses are in differing locations, such network addresses typically require a long-distance line and a switch or router to handle the traffic between locations. In such situations, it is generally more convenient to divide the network into a number of subnets, one for each location. Subnets in effect form a lower bound on the block-size. Therefore, blocking can be performed by obtaining the netmask (and therefore the subnet bounds) for a given network address (e.g., an IP address). Netmask's may be obtained from a number of sources, for example:
  • ICMP Internal Control Message Protocol
  • DHCP Dynamic Host Configuration Protocol
  • a machine On dialing up to an ISP, a machine usually sends a DHCP request to obtain its network configuration information. Included in this information is a netmask. Monitoring the DHCP response (or in the case of Linux, an “ifconfig” call) will reveal this netmask. An automated script that does either is included in the dialup scripts to derive blocking information as mapping by the ISP dialup method occurs. Because the subnets may be subsets of the actual block, multiple dialup sessions may have to occur before the complete block is revealed.
  • DHCP Dynamic Host Configuration Protocol
  • the netmask blocking algorithm can avoid “hitting” the lowest address (i.e., the Network Address) and the highest address (i.e., the Broadcast Address) of a subnet by stepping through the address space. This technique allows the netmask blocking algorithm to avoid automatic security auditing software that may incorrectly assumed a SMURF attack is being launched.
  • the below described algorithm provides at least two benefits, namely (1) that the data collection process becomes less intrusive and (2) a performance benefit is achieved, in that by limiting the number of hosts that are processed on each network, it is possible to “process” a large network (e.g., the Internet) utilizing a relatively small data set.
  • FIG. 10B is a diagrammatic representation of a Class C network 104 that has been subnetted.
  • traceroute data for the network addresses 2.2.2.1 and 2.2.2.254 has been collected and is known. By looking one hop back, it can be determined that the network has been subnetted. Since the network is identified as being subnetted, additional host will be required. For example in a Class C network, 256 hosts may be divided over multiple locations. For example, IP addresses 1-64 may be in Mountain View, 65-128 may be in New York, 129-and 92 may be in Boston, and 123-256 are in Chicago.
  • a further consideration is a situation in which a traceroute is obtained to a router that has an interface on an internal network. In this case, the traceroute will stop at the routers external interface. This may result in the blocking of a network multiple times.
  • a determination is made by the subnet blocking algorithm as to whether the end node of a traceroute is the same as the next-to-last hop of other traceroutes on the network. If so, the above described situation is detected.
  • DSL Digital Subscriber Line
  • cable modems do not appear to routers when they have multiple interfaces. This can result in the creation of false results.
  • the subnet blocking algorithm looks for patterns in the last three hops. By looking at this information, the algorithm is able to determine appropriate blocking for the high-speed modem network.
  • Some routers also allow for networks to be subnetted to different sizes within a predefined network block.
  • a Class C network may be subnetted into two networks, one of which is then further divided into number of smaller networks.
  • the subnet blocking algorithm verifies every block within two traceroutes. This enables the location of at least one node per network.
  • a further exemplary algorithm may also perform blocking utilizing RIP tables, BGP tables and ISP topology maps.
  • the division into blocks that are routed to a common location stems from the way routing is performed.
  • Availability of the internal routing tables for an Autonomous System, or a topology map for an ISP, may be utilized to obtain the block information as such tables and maps explicitly named the blocks that are routed through particular routes.
  • Routing tables have a standard format. Each route consists of a network prefix and possibly a netblock size, along with the route that IP addresses belonging to that netblock should follow and some metrics. The values of interest for blocking are the netblock and the netblock size.
  • a script extracts the netblock and netblock size for each route in the table, and then either obtains an existing location or geolocates one IP network address in the block by any of the existing methods and enter the result into the data warehouse 30 .
  • BGP routing tables have the same structure as internal routing tables with minor exceptions. All routes in the BGP table have a netblock size associated with them, and the route is given in terms of AS paths. Most routes within a BGP table are of little use in determining a block because they do not take into account the routing performed within an Autonomous System. However, BGP tables contain a large number of exception routes. Very often, the blocks corresponding to these routes represent geographically compact domains, and the netblock and netblock size can be used as extracted from the BGP table. Exception routes can be recognized easily since they are subsets of other routes in the table. For example:
  • the second route in the above example is a subset of the first route and is by definition an exception route.
  • ISP topology maps usually contain the netblocks that each router handles. These can be used as above. The format is non-standard and requires decoding. A dedicated scripts created each topology map operates to parse these topology maps.
  • the unified mapping process 61 operates to combine the results of a number of mapping methodologies that do not yielded exact results (e.g., combines the results of the inexact algorithms).
  • the unified mapping process 61 takes into account all information available from such methodologies, and a probability (or confidence factor) associated with each, and establishes a unique location. The associated probability that serves as a confidence factor for the unique location.
  • the unified mapping process 61 is implemented as a Bayesian network that takes into account information regarding possible city and the state locations, results conflicts (e.g., there may be contradictory city/city indications or inconsistent cities/state combinations, and calculates) a final unique location and the associated probability.
  • a probability for each of a number of possible locations that are inputted to the unified mapping process 61 is calculated utilizing the Bayesian network, in one exemplary embodiment of the present invention. For example, if there is one possible location with a very high probability and a number of other possible locations with smaller probabilities, the location with the highest probability may be picked, and its associated probability returned. On the other hand, if they are multiple possible locations with comparable probabilities, these may be forwarded for manual resolution, one embodiment of the present invention.
  • the unified mapping process 61 receives a target network address (e.g., an IP address), and then runs the number of non-exact mapping processes as sub-tasks. These non-exact mapping processes then provide input to the Bayesian network. If one of the non-exact algorithms fails, but a majority does not, the Bayesian network will attempt to resolve the network address anyway.
  • a target network address e.g., an IP address
  • FIG. 11 is a block diagram illustrating a process flow for the unified mapping process 61 , according to an exemplary embodiment of the present invention.
  • the unified mapping process 61 is an expert system suite of algorithms used to geolocate a network address (e.g., IP address).
  • the unified mapping process 61 combines a plethora of data from Internet registries (Domain Name Server, Network IP Space, Autonomous System Numbers), Internet network connections (inferred via traceroutes), and world geographical databases (place names, locations, populations).
  • the unified mapping process 61 further constructs a list of possible physical locations for a given network address, and from this list, through fuzzy logic and statistical methodologies, returns a location with a set of associated probabilities that provide an indication regarding the accuracy of that location. In this way, the unified mapping process 61 can tie the network address to a specific geographic location (e.g. a city, country, zip/postal code, etc.) and provide an indication regarding the probability of the specific geographic location being correct.
  • a specific geographic location e.g. a city, country, zip/postal code, etc.
  • the illustrated exemplary embodiment of the unified mapping process 61 has several components.
  • a collection 120 of the location determination modules Utilizing the data that have been gathered by external processes (e.g., the data collection agents 18 ), a collection 120 of the location determination modules (LDMs) generate (1) location determinants (LDs) for a target address in question, and (2) and associated confidence factor (CF) or likelihood that the location determinant is correct (e.g., indicates a “true” geographic location).
  • the location determinants generated by the collection 120 of location determination modules are then passed through a location filter 122 , which, based on certain criteria, removes nonsensical location determinants.
  • location determinants and their associated confidence factors are passed into the location synthesis process (LSP) 124 , where the multitude of different (and similar) location determinants, weighted by their confidence factors, compete against and cooperate with each other, ultimately yielding a unique and most likely location determinate including a “best estimate” geographic location (the location). Based on the degree of similarity between the “best estimate” geographic location and its competing locations, different confidence factors are assigned for the geographic resolution levels, which are transformed by a confidence-accuracy translator (CAT) 126 into a probability of accuracy for the winning location.
  • CAT confidence-accuracy translator
  • Confidence factors are used throughout the processing by the collection 120 of location determination modules and are discussed in detail below.
  • the confidence factors in one embodiment present invention, come in four varieties (post-CM, post-LDM, post-LSP, and post-CAT), and their meanings are very different. The reader can use the context to determine which confidence factor is being referenced.
  • a location determination module is a module that generates a location determinant (LD) or set of location determinants that are associated with the given network (e.g., IP) address.
  • the location determination modules utilize a variety of the available input data, and based on the data's completeness, integrity, unequivocalness and degree of assumption violation, assign a confidence factor for one or more geographic locations.
  • the location determination modules may conceptually be thought of as experts in geolocation, each with a unique special skills set.
  • the location determination modules further make decisions using “fuzzy logic”, and then present the output decisions (i.e., location determinants) and associated confidence factors (CFs) to the location filter 122 and location synthesis process 124 , where the location determinants are evaluated (or “argued”) democratically against the location determinants presented by other location determination modules.
  • fuzzy logic the output decisions (i.e., location determinants) and associated confidence factors (CFs) to the location filter 122 and location synthesis process 124 , where the location determinants are evaluated (or “argued”) democratically against the location determinants presented by other location determination modules.
  • All location determination modules operate it may somewhat similar manner in that they each examine input data, and attempt to generate location determinants with an associated confidence factor based on the input data. However, each location determination module is different in what input data it uses and how the respective confidence factors are derived. For instance, a specific location determination module may extract location information from a hostname, while another analyzes the context of the traceroute; a further location determination module may analyze autonomous system information, while yet another makes use of a DNS Location record. By combining these distinct data inputs, each individually weighted by the parameters that most directly affect the likelihood of the relevant data being correct, the location synthesis process 124 is equipped with a set of data to make a decision.
  • the location filter 122 operates through the location determinants, received from the collection 120 of location determination modules, which are in conflict with certain criteria. In particular, if a hostname ends with ‘.jp’, for example, the location filter 122 removes all location determinants that are not in Japan. Similarly, if a hostname ends with ‘.ca.us’, the location filter 122 omits location determinants that are not in California, USA.
  • the location synthesis process 124 is responsible for the unification and congregation of all location determinants that are generated by the collection 120 of location determination modules.
  • the location synthesis process 124 searches for similarities among the location determinants and builds a confirmation table (or matrix that indicates correspondence (or agreement) between various location determinants.
  • An intermediate result of this decision making process by the location synthesis process 124 is the location probability table (LPT), an example of which is discussed above. Since determinants may agree and disagree on multiple levels of geographic resolution (i.e. San Francisco, Calif. and Boulder, Colo. differ in city, state, and region, but are similar in country and continent), the location probability table develops different values at different levels of geographic resolution.
  • a combined confidence factor which is a linear combination of each of the constituent confidence factor fields, is computed and used to identify a most likely location (the winning location) and an associated probability of the winning location being correct.
  • a location probability table As returned from the location synthesis process 124 , are translated by the confidence-accuracy translator (CAT) 126 into a final form. A small subset of the data is run against verification data to compute the relationship between post-LSP confidence factors and accuracy. Given this relationship, the location probability table is translated to reflect the actual probability that the given network address was correctly located, thus completing the process of geolocation.
  • CAT confidence-accuracy translator
  • LDMs location determination modules
  • CMs confidence maps
  • a location determination module generates a location determinant (LD), or set of location determinants, and an associated confidence factor (CF), or set of confidence factors. These location determinants are provided, together with an associated confidence factor, to the location filter 122 and onto the location synthesis process 124 , where based on the magnitude of their confidence factors and agreement with other location determinants, are considered in the decision making of the unified mapping process 61 .
  • LD location determinant
  • CF confidence factor
  • the RegEx (Regular Expression) LDM 130 searches through a hostname and attempts to extract place names (cities, states, or countries) from within it.
  • the host name may be obtained by performing a traceroute, or by issuing a NSLOOKUP or HOST command against a network address.
  • LDM 130 identifies one or more place names, associated confidence factor values (based for example on parameters like city population, number of letters in the string from which the name was extracted, distance to the last known host in a traceroute, etc.) are generated for each of the place names.
  • the Net LDM 132 returns a geographic location for the network address (e.g., an IP address) as it is registered with the appropriate authority (e.g., ARIN/RIPE/APNIC).
  • the confidence factor assigned to the geographic location is based primarily on the size of the network block that is registered and within which the network address falls, under the assumption that a small network block (e.g., 256 or 512 hosts) can be located in common geographic location, whereas a large network block (e.g., 65,536) is less likely to all be located in a common geographic location.
  • CMs confidence maps
  • FIGS. 12A and 12B illustrate a one-dimensional confidence map 150 and a two-dimensional confidence map 160 respectively, according to exemplary embodiments of the present invention.
  • the one-dimensional confidence map 150 consider the exemplary scenario in which the Net LDM 132 returns a certain city. The question arises as to how the Net LDM 132 can attach a level of certainty (or probability) that the city is a correct geolocation associated with a network address. As stated above, in general, smaller network blocks are more likely to yield a correct geographic location than large ones.
  • a relationship between (1) the number of nodes within a network block and (2) a confidence level that a particular network address is located in a city associated with that network block can be determined and expressed in a confidence map, such as the confidence map 150 shown in FIG. 12A.
  • FIG. 12A it can be seen that confidence level for the geographic location is very high if the network block size is small. However, as the size of the network block increases, the confidence level decreases.
  • “crisp logic” may be utilized.
  • the “crisp logic” implementation differs from the “fuzzy logic” implementation in that the “crisp logic” may implements a pass/fail test. For example, rather crisp logic may specify that networks smaller than size x are correctly located and larger than x are incorrectly located.
  • the exemplary “fuzzy logic” implementation represented by the relationship shown in FIG. 12A present the continuum that represents a probabilistic relationship.
  • one-dimensional confidence maps 150 are good indicators of a likelihood of correct location
  • two-dimensional confidence map 160 is good indicators of a likelihood of correct location
  • this confidence map 160 attributes a higher confidence factor when the city is large and/or when the string from which unified mapping process 61 extracted the location is long. For example, as ‘sf’ is a short string and subsequently prone to ambiguity, it does not have the same level of confidence that a long string such as ‘santaclara’. However, if there is a large population associated with a specific geographic location, then the weighting of the string length is discounted.
  • the two-dimensional confidence map 160 when applied to the aforementioned examples, yields the following Table 2: TABLE 2 Example table of results from confidence map Location String Length Population Confidence San Francisco, CA 2 700,000 35 San Fernando, CA 2 20,000 10 Santa Fe, NM 2 70,000 15 South Fork, CO 2 ? ( ⁇ 5,000) 0 Santa Clara, CA 10 90,000 40
  • a location determination module e.g., the Net LDM 132
  • the Net LDM 132 can separate reasonable location determinants from unreasonable ones.
  • separation may depend on a large number of factors, and the unified mapping process 61 may utilize a large number of confidence maps.
  • Every candidate geographic location must pass through each relevant confidence map and has multiple confidence factors associated therewith combined. Once a location determinant has a combined confidence factor, it no longer uses the multiple individual factors. Specifically, the location determinant and the associated combined confidence factor are communicated to the location filter 122 and subsequently the location synthesis process 124 .
  • a confidence map may not assign a value higher than 50 for confidence factor. Since the combined confidence factor is an average of these, it is also less than 50. If a confidence factor is generated by the location synthesis process to have a value greater than 50, a confirming comparison may take place.
  • a specific location determination module may utilize a mix of one-dimensional and two-dimensional confidence maps, each of which has advantages and disadvantages.
  • a one-dimensional confidence maps may lack the ability to treat multidimensional nonlinear interaction, but only requires the one parameter to run.
  • a two-dimensional confidence map can consider higher dimensional interaction effects, but if one of the parameters is missing, the confidence map cannot be utilized to generate a confidence factor.
  • location determination modules are truly modular, and that none depend on any other, and they can easily be added, modified, or removed with respect to the unified mapping process 61 .
  • confidence maps 33 are stored within the data collection database 26 .
  • the confidence maps 33 are represented either as a matrix, or as a function where an input parameter constitutes a continuum, as opposed to discrete values.
  • FIG. 12C is an entity-relationship diagram illustrating further details regarding the storage of the confidence maps 33 within the data collection database 26 .
  • a reference table 35 which is accessed by an LDM, includes records that include pointers to a matrix table 37 and a function table 39 .
  • the matrix table 37 stores matrices for those confidence maps having input parameters that constitute discrete values.
  • the function table 39 stores functions for those confidence maps for which an input parameter (or parameters) constitute a continuum.
  • FIG. 13 is a flowchart illustrating a method 170 , according to an exemplary embodiment of the present invention, performed by the RegEx LDM 130 to identify one or more geographic locations for a network address and to associated at least one confidence factor with each of the geographic locations.
  • the RegEx LDM 130 performs a location determination based on searching for string patterns within the host name. Accordingly, the method 170 commences at block 172 with the receipt of input data (e.g., a traceroute or other data collected by the data collection agents 18 ).
  • input data e.g., a traceroute or other data collected by the data collection agents 18 .
  • decision block 174 a determination is made as to whether one or more hostnames are included within the input data. If there is no hostname included within the input data (e.g., a traceroute) provided to the unified mapping process 61 , the RegEx LDM 130 exits at block 176 .
  • the RegEx LDM 130 at block 178 parses the hostname by delimiter characters (e.g., hyphens, underscores, periods, and numeric characters) to identify words that are potentially indicative of a geographic location.
  • delimiter characters e.g., hyphens, underscores, periods, and numeric characters
  • the RegEx LDM 130 runs comparisons on these newly identified words individually, and in conjunction with neighbor words, to check for similarity to patterns that correspond to geographic locations (e.g., place names).
  • the RegEx LDM 130 accesses the demographic /geographic database 31 contained within the data warehouse 30 to obtain patterns to use in this comparison operation.
  • the LDM 130 checks individual words, and iteratively “chops” or removes letters from the beginning and end of the word in the event that extraneous characters are hiding valuable information. Strings that are more likely associated with networking and hardware than place names (such as ‘ppp’, ‘dsl’, ‘isdn’, ‘pop’, ‘host’, ‘tel’, etc.) are not included in any pattern matching routines.
  • Examples of valid patterns, as stored within the demographic/geographic database 31 , that may be sought include various combinations of:
  • the RegEx LDM 130 is capable of extracting fairly obfuscated geographic information from hostnames.
  • One of the shortcomings, however, of the history of place naming is ambiguity.
  • the RegEx LDM 130 at block 180 , therefore accordingly generally identifies not one but many geographic locations, and generates multiple location determinants.
  • the following table presents examples of the location determinants that the RegEx LDM 130 may generate from the exemplary host names: TABLE 3 Example RegEx LDM location determinant construction Actual Hostnames Location Determinants Rules/Reasons/Patterns dyn1-tnt4-1.chicago.
  • the RegEx LDM 130 Through the usage of common abbreviations and alternate spellings, the RegEx LDM 130 , for example, also knows to put ‘lsanca’ in Los Angeles, Calif., and ‘cologne’ in Dallas, Germany.
  • rules may restrict location determinant generation of trivially small (e.g., low population or low connectivity index) cities from fewer than 4 characters.
  • the RegEx LDM 130 is particularly suited to identify geographic locations associated with the Internet backbone/core routers. It is not uncommon for a company to make use of the hostname as a vehicle for communicating location. By using typical abbreviations and a geographical database of many tens of thousands of place names, the RegEx LDM 130 is suited to locating these hosts.
  • the RegEx LDM 130 has the ability to produce a multitude of location determinants for a particular network address. Because the RegEx LDM 130 is suited to identify geographic locations along the Internet backbone it may not, in one embodiment, be heavily deployed in the geolocation of end node targets. Instead, the immediate (router) locations delivered by the LDM 130 may be stored and used by other LDMs of the collection 120 , which make use of these results as Last Known Hosts (LKHs) and Next Known Hosts (NKHs).
  • LDHs Last Known Hosts
  • NSHs Next Known Hos
  • the RegEx LDM 130 outputs the multiple geographic location determinants, and the associated confidence factors, as a set to the location filter 122 , for further processing.
  • the method 170 then exits at block 176 .
  • the LDM 130 employs a relatively large number of confidence maps when compared to other LDMs of the collection 120 .
  • the confidence maps employed by the LDM 130 relate parameters such as word position, word length, city population, city connectivity, distance of city to neighboring hosts in the traceroute, etc.
  • each of the confidence maps discussed below includes a “confidence map weight”, which is a weighting assigned by the RegEx LDM 130 to a confidence factor generated by a respective confidence map. Different confidence maps are assigned different weightings based on, inter alia, the certainty attached to the confidence factor generated thereby. The number of terms or parameters of the confidence maps described below require clarification.
  • the term “hop ratio” is an indication of a hop position within a traceroute relative to an end host (e.g., how far back from the end hosts a given hop is).
  • connection index is a demographic representation of the magnitude or amount of network access to which a location has access within a network.
  • minimum connectivity is a representation of a lowest common denominator of connectivity between to network entities (e.g., a Last Known Host and an end host). Distances between geographic locations are calculated once a geographic location has been determined. The latitude and longitude co-ordinates of a geographic location may, in one exemplary embodiment, be utilized to performed distance calculations.
  • FIG. 14A An exemplary embodiment of the confidence map 190 is illustrated in FIG. 14A. This confidence map 190 is most assertive in the middle of a traceroute where it provides well-connected location determinants high confidence factors and less connected location determinants low confidence factors. At the beginning and the end of the traceroute, it has the opposite effect; well connected location determinants receive lower confidence factors and less connected get higher.
  • FIG. 14B An exemplary embodiment of the confidence map 192 is illustrated in FIG. 14B.
  • a longer string provides a high degree of certainty than a shorter string, and decreases ambiguity.
  • This confidence map 192 attributes higher confidence factors for longer strings and confidence factors of zero for two character strings.
  • the confidence map 194 couples the word length (an indirect measure of ambiguity) with the number of location determinants returned by the RegEx LDM 130 (a direct measure of ambiguity). Strings that are too short and yield too many location determinants are attributed a lower confidence factors than unique ones. It will be noted that the confidence map 194 is attributed a relatively higher weighting in view of the high degree of certainty delivered by this confidence map 194 .
  • FIG. 14D An exemplary embodiment of the confidence map 196 is illustrated in FIG. 14D.
  • short words are attributed relatively low confidence factors. Nonetheless, it is desirable to attributed a relatively higher confidence factor to geographic locations that are heavily populated, in spite of such geographic locations being indicated by a short word. For example, so that ‘sea’ and ‘sf’ (indicating Seattle and San Francisco, respectively) are attributed higher confidence factors, this confidence map 196 allows well-populated cities to be abbreviated shortly.
  • FIG. 14E An exemplary embodiment of the confidence map 198 is illustrated in FIG. 14E.
  • the confidence map 198 seeks to ensure that even short abbreviations are likely to be mapped correctly by attributing a higher confidence factor too short words (e.g., abbreviations) that exhibit a high degree of connectivity.
  • X-axis Distance in Miles to Last Known Host. This is determined from the demographic/geographic database 31 that stores intra-location distance values.
  • FIG. 14F An exemplary embodiment of the confidence map 200 is illustrated in FIG. 14F. Two hosts adjacent in a traceroute are expected to be physically near each other, unless they are traversed in the middle of the traceroute. This confidence map 200 is reflective of this expectation. Hosts that are distant and at the end of a traceroute are attributed lower confidence factors.
  • Y-axis Number of Hops Between this Host and LKH.
  • FIG. 14G An exemplary embodiment of the confidence map 202 is illustrated in FIG. 14G. Under the premise that a host should be located near the last known host in a traceroute, the confidence map 202 gives lower confidence factors when the LKH is close in the traceroute but far in physical space. The confidence map 202 is more forgiving of hosts slightly further in the traceroute.
  • Y-axis Minimum Population of this Host and LKH. This information is again retrieved from the demographic/geographic database 31 .
  • FIG. 14H An exemplary embodiment of the confidence map 204 is illustrated in FIG. 14H. It is generally found that hops in a traceroute jump great distances only when they travel from one major backbone city to another. A common characteristic of these cities is their large populations. So, in the confidence map 204 , larger, closer location determinants are rewarded, while distant, small ones are punished.
  • FIG. 141 An exemplary embodiment of the confidence map 206 is illustrated in FIG. 141. Similar to the preceding confidence map 204 based on population, this confidence map 206 rewards cities that are generally well-connected. For example, cities like New York and London can be connected to very distant cities.
  • FIG. 14J An exemplary embodiment of the confidence map 208 is illustrated in FIG. 14J. Two hosts adjacent in a traceroute are expected to be physically near each other, unless they are traversed in the middle of the traceroute. The confidence map 208 is reflective of this expectation. Hosts that are distant and at the end of a traceroute receive lower confidence factors.
  • Y-axis Number of Hops Between this Host and NKH
  • FIG. 14K An exemplary embodiment of the confidence map 210 is illustrated in FIG. 14K. Under the premise that a host should be located near the last known host in a traceroute, the confidence map 210 attributes lower confidence factors when the NKH is close in the traceroute, but far in physical space. The confidence map 210 is more forgiving of hosts slightly further in the traceroute.
  • Y-axis Minimum Population of this Host and NKH
  • FIG. 14L An exemplary embodiment of the confidence map 212 is illustrated in FIG. 14L. Hops in a traceroute tend to jump great distances only when they travel from one major backbone city to another. A common characteristic of these backbone cities is their large populations. Accordingly, the confidence map 212 generates a confidence factor such that larger, closer location determinants are rewarded, while distant, small location determinants are punished.
  • the confidence map 214 rewards cities that are generally well-connected. For example, cities like New York and London can be connected to very distant cities.
  • FIG. 14N An exemplary embodiment of the confidence map 216 is illustrated in FIG. 14N.
  • the population of a geographic location is an effective measure of likelihood. Intuitively, the Moscow of the Russian Federation is more likely than the Moscow of Iowa. Especially in the USA, population may be a powerful indicator of the likelihood of location determinant correctness.
  • FIG. 14O An exemplary embodiment of the confidence map 218 is illustrated in FIG. 14O.
  • a base premise of the confidence map 218 is that connectivity indices along a traceroute ought to be continuous. That is: host locales go from low connectivity to medium, to high. Any host's connectivity index along a traceroute ought theoretically not to deviate from the mean of its neighbors. This map penalizes such a deviation.
  • FIG. 14P An exemplary embodiment of the confidence map 220 is illustrated in FIG. 14P.
  • the connectivity index is utilized by the confidence map 220 to provide a direct measure of the probability that a host is in the particular geographic location. According to the confidence map 220 , the better connected a geographic location (e.g., city) is, the more likely the host is to be at a geographic location.
  • a geographic location e.g., city
  • FIG. 14Q An exemplary embodiment of the confidence map 222 is illustrated in FIG. 14Q. It will be noted that the confidence map 222 is assigned a relatively low confidence map weight, which is indicative of a relatively low effectiveness of the confidence map 222 . It has been found that information in a hostname is more likely to be found at the extreme ends than in the middle. Also if two city names appear together in a hostname, the names toward the ends of the word tend to have more relevance.
  • FIG. 15 is a flowchart illustrating a method 240 , according to an exemplary embodiment of the present invention, performed by the Net LDM 132 to identify one or more geographic locations for a network address (or block of network addresses) and associate at least one confidence factor with each of the geographic locations.
  • the Net LDM 132 initiates external data collection routines (e.g., data collection agents 18 ) to query multiple Internet Protocol (IP) registering authorities (e.g., RIPE/APNIC/ARIN) to a smallest possible network size
  • IP Internet Protocol
  • geographical information e.g., city, state, country, the zip/postal code, area code, telephone prefix
  • geographical information e.g., city, state, country, the zip/postal code, area code, telephone prefix
  • the Net LDM 132 utilizes multiple confidence maps to attach confidence factors to each of the geographic locations identified at block 244 , or to each of the geographic information items identified at block 244 .
  • the Net LDM 132 outputs the multiple geographic locations (or geographic information items) and the associated confidence factors to the location filter 122 .
  • the method 240 then terminates at block 252 .
  • the Net LDM 132 may be of limited effectiveness along the core routers, the use of the Net LDM 132 may,. in one exemplary embodiment, be restricted to the last three hops of a traceroute.
  • the Net LDM 132 may optionally also not be utilized if a network block size registered is larger than 65,536 hosts, for it is unlikely that so many machines would be located in the same place by the same organization.
  • the Net LDM 132 is a particularly effective at generating accurate confidence factors for geographic locations when the network blocks registered with the IP registering authority are relatively small (e.g., less than 1024 hosts). If the Net LDM 132 incorrectly attached is a high confidence level to a geographic location, it is most likely related to a large network block or an obsolete record in a registry.
  • the confidence factors generated by the Net LDM 132 come from distance to a Last Known Host (LKH) and a Next Known Host (NKH) (e.g., calculated utilized in the latitude and longitude co-ordinates of these hosts) the size of the network block, a position in a traceroute (e.g., relative location near the end of the traceroute), population and connectivity.
  • LH Last Known Host
  • NSH Next Known Host
  • a relative position within the traceroute will be dependent upon the number of hops, and the relevant hop's position within that number of hops. For example, if they are 7 hops within a given traceroute, then hop 6 is considered to be near the end host. However, if there are 20 hops within the traceroute, hop 6 to be considered to be very distant from the end host.
  • the confidence map 260 generates a relatively high confidence factor only at the ends of a traceroute and only when a geographic location (e.g., a city) corresponding to the network addresses within close proximity to the LKH.
  • a geographic location e.g., a city
  • FIG. 16B An exemplary embodiment of the confidence map 262 is illustrated in FIG. 16B.
  • the confidence map 262 works off of two premises. First, if an entity has gone through the trouble to register a small block of network space, it is probably accurate. Conversely, large networks that are registered to one organization probably have the hosts spread out across a large area. Thus, the confidence map 262 operates such that small network sizes yield large confidence factors.
  • the confidence map 264 generates a relatively high confidence factor for a geographic location only at the ends of a traceroute and only when a geographic location (e.g., a city) corresponding to network addresses within close proximity to the NKH.
  • a geographic location e.g., a city
  • FIG. 16D An exemplary embodiment of the confidence map 266 is shown in FIG. 16D. Contrary to the relationship in the RegEx LDM 130 , here less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that if a network is registered in a small town, hosts on that network are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • geographic locations e.g., cities
  • FIG. 16E An exemplary embodiment of the confidence map 268 is illustrated in FIG. 16E. Contrary to the relationship in the RegEx LDM 130 , here smaller geographic locations are rewarded with higher confidence factors. The premise is that if a network is registered, for example, in a small town, hosts on that network are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • DNS Domain Name Server
  • FIG. 17 is a flowchart illustrating a method 270 , according to an exemplary embodiment of the present invention, performed by the DNS LDM 134 to identify one or more geographic locations for a network address (or block of network addresses) and to associate at least one confidence factor with each of the geographic locations.
  • the DNS LDM 134 initiates external data collection routines (e.g., data collection agents 18 ) to query multiple Domain Name Server (DNS) registering authorities to collect DNS records. These records correspond to ownership of a particular domain name (e.g., www.harvard.com or www.amazon.com)
  • DNS Domain Name Server
  • geographical information e.g., city, state, country, the zip/postal code, area code, telephone prefix
  • geographical information e.g., city, state, country, the zip/postal code, area code, telephone prefix
  • the DNS LDM 134 utilizes multiple confidence maps to attach confidence factors to each of the geographic locations identified at block 274 .
  • the DNS LDM 134 outputs the multiple geographic locations (or geographic information items) and the associated confidence factors to the location filter 122 .
  • the method 270 then terminates at block 282 .
  • the DNS LDM 134 may not be most effective along the backbone core routers. For example, it is not helpful to know that att.net is in Fairfax or that exodus.net is in Santa Clara. To avoid potential problems related to this issue, the DNS LDM 134 may be deployed only on the last three hops of a traceroute, in one exemplary embodiment of the present invention.
  • a DNS record, retrieved at block 272 indicates the same geographic location as a network record, retrieved at block 242 , then it may be assumed, in one exemplary embodiment, that this geographic location is a corporate office and that the actual hosts may or may not be at that location. To prevent the location synthesis process 124 from being overwhelmed by redundant data that might not be useful, the DNS LDM 134 is prevented from duplicating the Net LDM 132 , because, in an exemplary embodiment, the LDM 134 is less skillful than the LDM 132 .
  • the DNS LDM 134 may be strongest at the end of a traceroute, but not along the backbone core routers. Accordingly, the DNS LDM 134 may work well to geolocate companies that have a domain name registered and do their own hosting locally. Small dial-up ISPs are also locatable in this way as well.
  • An exemplary collection of confidence maps that may be utilized by the DNS LDM 134 to attach confidence factors to location determinants, at block 278 , are discussed below with reference to FIGS. 18 A- 18 E.
  • the DNS LDM 134 relies on similar parameters as the Net LDM 132 for determining its confidence factors. Major differences include using distance to a network location, the rather than a network block size. It will also be noted that, in the exemplary embodiment, DNS confidence factors yielded by the confidence maps discussed below are significantly lower than in other LDMs.
  • FIG. 18A An exemplary embodiment of the confidence map 290 is illustrated in FIG. 18A. This confidence map 290 generates a relatively high confidence factor only at the ends of a traceroute and only when the geographic location (e.g., a city) corresponding to the DNS record is within close proximity to the LKH.
  • geographic location e.g., a city
  • FIG. 18B An exemplary embodiment of the confidence map 292 is illustrated in FIG. 18B. This confidence map 292 works under the assumption that if the Net and DNS records are identical, then they probably point to a corporate headquarters. If the distance between the two is zero, then the confidence factor is zero. If, however, the distance is not zero but is very small, then there is a greater chance that either one could be correct, or a larger confidence factor is given.
  • This confidence map 294 gives high confidence only at the ends of a traceroute and only when the geographic location (e.g., the city) corresponding to the DNS record is within close proximity to the NKH.
  • FIG. 18D An exemplary embodiment of this confidence map 296 is illustrated in FIG. 18D. Contrary to the relationship in the RegEx LDM 130 , the DNS LDM 134 operates such that less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that, for example, if a domain name is registered in a small town, hosts associated with it are more likely to be in that small town. Larger cities may just be corporate headquarters or collocations.
  • FIG. 18E An exemplary embodiment of the confidence map 298 is illustrated in FIG. 18E. Contrary to the relationship in the RegEx LDM 130 , here smaller geographic locations (e.g., small towns) are rewarded with higher confidence factors.
  • the premise is that, for example, if a domain name is registered in a small town, hosts associated with it are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • the method by which the Autonomous System Network (ASN) LDM 136 operates to identify one more geographic locations for network addresses, and to assign at least one confidence factor to each of the geographic locations is similar to the methods 240 and 270 of other two internet registry LDMs (i.e., the Net LDM 132 and the DNS LDM 134 ). Specifically, as opposed to the deploying external data collection routines to gather Net and DNS records, the ASN LDM 136 deploys the external data collection routines to gather the Autonomous System data, and parse it for meaningful geographic data. If ASN data is available, then the ASN LDM 136 can run.
  • the ASN LDM 136 is, in one embodiment, not used if the network block size registered by a blocking algorithm is larger than 65,536 hosts, as it is unlikely that so many machines would be located at a common location under the same Autonomous System (AS).
  • AS Autonomous System
  • the ASN LDM 136 does not run if its ASN record matches that of the Net LDM. Again, this is to avoid erroneous duplication.
  • the ASN LDM 136 is reliable because the ASN data is utilized in real network communication, and is accordingly generally current, correct, and of a reasonable high resolution.
  • ASN LDM 136 An exemplary collection of confidence maps that may be utilized by the ASN LDM 136 to attach confidence factors to location determinants are discussed below with reference to FIGS. 19 A- 19 E.
  • the confidence factors generated by the ASN LDM 136 come from distance to LKH and NKH, the size of the network, the position in the traceroute, population and connectivity. It will be noted that the following confidence maps, while utilizing distance and hop ratio in similar ways as in the RegEx LDM 130 , population and connectivity are used in contrary ways.
  • FIG. 19A An exemplary embodiment of the confidence map 300 is illustrated in FIG. 19A. This confidence map 300 gives high confidence only at the ends of a traceroute and only when the geographic location (e.g., a city) corresponding to the ASN record is within close proximity to the LKH.
  • geographic location e.g., a city
  • FIG. 19B An exemplary embodiment of the confidence map 302 is illustrated in FIG. 19B.
  • This confidence map 302 operates off of two premises. First, if an entity has gone through the trouble to register a small block of network space, it is probably accurate. Conversely, large networks that are registered to one organization probably have the hosts spread out across a large area. Thus, small net sizes yield large confidence factors.
  • X-axis Distance in Miles Between LKH and ASN
  • FIG. 19C An exemplary embodiment of the confidence map 304 is illustrated in FIG. 19C. This confidence map 304 generates relatively high confidence factors only at the ends of a traceroute and only when the geographic location (e.g., city) corresponding to the ASN record is within close proximity to the NKH.
  • geographic location e.g., city
  • FIG. 19D An exemplary embodiment of the confidence map 306 is illustrated in FIG. 19D. Contrary to the relationship in the RegEx LDM 130 , here less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that if a network is registered in a relatively smaller geographic location (e.g., small town), hosts on that network are most likely in that smaller geographic location. Larger cities may be corporate headquarters.
  • a relatively smaller geographic location e.g., small town
  • FIG. 19E An exemplary embodiment of the confidence map 308 is illustrated in FIG. 19E. Contrary to the relationship in the RegEx LDM 130 , here smaller geographic locations (e.g., smaller cities) are rewarded with higher confidence factors.
  • the premise is that if a network is registered in, for example, a small town, hosts on that network are most likely to be located in that small town. Larger cities may be corporate headquarters.
  • the method by which the Loc LDM 138 operates to identify one more geographic locations for network address, and to associate least one confidence level with each of the geographic locations is again similar to the methods 240 and 270 of the Net and DNS LDMs 132 and 134 in that external collection processes gather Location (Loc) records from appropriate registries, which are parsed to extract location determinants.
  • the Loc LDM 138 differs from the above described LDMs in that a collection of confidence maps is not utilized to attach confidence factors to each of these location determinants, as will be described in further detailed below.
  • the Loc LDM 138 differs from the previously described LDMs in that it exhibits a high degree of accuracy and precision.
  • a DNS Loc record as collected by external processes, may provide an indication of a hosts' latitude and longitude data, which may be utilized to tie a location determinant to a city (or even smaller).
  • the Loc LDM 138 is one of only two LDMs that do not make use of confidence maps. The rationale behind this is that there are no circumstances that would change the belief in the highly accurate DNS Loc record, used by the Loc LDM 138 . So as opposed to utilizing a number of confidence maps, if the Loc record is available, the Loc LDM 138 communicates a location determinant derived from the Loc record to the location filter 22 , accompanied by a precise confidence factor, for example, 85 .
  • the LKH LDM 140 makes use of traceroute contextual data, and asserts that the host in question is in precisely the same location as the one previously identified in the traceroute. Specifically, it is generally found that at the end of a traceroute, the physical distance from the one hop to the next is on the order of miles, not hundreds of miles. It is also not uncommon for a traceroute to spend several hops in the same area (i.e. network center).
  • the LKH LDM 140 may provide useful results, it has with it a dangerous side effect that requires careful attention; unless kept in check, the LKH LDM 140 has the power to “smear” a single location over the entire traceroute.
  • the confidence maps utilized by the LDM 140 are particularly strict to address this issue.
  • FIG. 20A An exemplary embodiment of the confidence map 320 is illustrated in FIG. 20A. As such above, it is desirable that the confidence maps utilized by the LDM 140 are “strict” to avoid erroneous location determinant smearing. This confidence map 320 only attributes relatively high confidence factors if the LKH is a small number of hops (e.g., less than 2 hops) away and the confidence factor of the LKH is very high.
  • FIG. 20B An exemplary embodiment of the confidence map 322 is illustrated in FIG. 20B. This confidence map 322 generates relatively high factors if and only if the hosts are close together (in the traceroute) and at the end of the traceroute. Other scenarios receive low or zero confidence factors.
  • FIG. 20C An exemplary embodiment of the confidence map 324 is illustrated in FIG. 20C.
  • the confidence map 324 gives slightly higher confidence factors if and only if the LKH is proximal to any of the Net, DNS, or Loc Records.
  • LDH Last Known Host
  • NHL Next Known Host
  • the NKH will usually not be directly instrumental in geolocating an end node, it can play an auxiliary role, and provide useful supplemental information. For example, if Router A is the last hop before a traceroute goes to an end node in, say, Denver, Colo., then it is not unlikely that Router A is also in Denver, Colo. By assigning Router A to Denver, Colo., the next time a traceroute runs through Router A, it can use the LKH to press on further.
  • the NKH LDM 142 in a slightly less robust way than the LKH LDM 140 and in a substantially way than the RegEx LDM 130 , is a mechanism for providing supplemental information in the router space of the Internet, which subsequently provides aid in the end node geolocation.
  • FIG. 21A An exemplary embodiment of the confidence map 330 is illustrated in FIG. 21A. Again it is desirable that the confidence maps utilized by the NKH LDM 142 are “strict” to avoid erroneous location determinant smearing. This confidence map 330 only gives high confidence factors if the NKH is a small number of hops (e.g., less than 2 hops) away from a current geographic location (e.g., host) and the confidence factor of the NKH is very high.
  • X-axis Number of Hops Between current Host and the NKH
  • FIG. 21B An exemplary embodiment of the confidence map 332 is illustrated in FIG. 21B. This confidence map 332 gives relatively high confidence factors if and only if the hosts are close together (in the traceroute) and at the end of the traceroute. Other scenarios receive low or zero confidence factors.
  • FIG. 21C An exemplary embodiment of the confidence map 334 is illustrated in FIG. 21C.
  • the confidence map 334 gives slightly higher confidence factors if and only if the NKH is proximal to any of the Net, DNS, or Loc Records.
  • FIG. 22 is a flowchart illustrating a method 340 , according to an exemplary embodiment of the present invention, performed by the sandwich LDM 144 to identify one more geographic locations for a network address, and associated at least one confidence factor with each of the geographic locations.
  • the method 340 commences at decision block 342 , where the sandwich LDM 144 determines whether both the LKH and the NKH LDMs 140 and 142 generated respective location determinants and associated confidence factors. If not, and only one or neither of these LDMs 140 and 142 generated a location determinant, the method 340 then ends at block 352 .
  • the sandwich LDM 144 retrieves the respective location determinants from the LKH and the NKH LDMs 140 and 142 .
  • the sandwich LDM 144 identifies the location determinant received at block 344 that has the highest confidence factor associated therewith.
  • the sandwich LDM 144 assigns a confidence factor to the location determinant identified at block 346 based on: (1) a combination of the confidence factors assigned to each of the location determinants by the LDMs 140 and 142 (e.g., by calculating the mean of the location determinants); and (2) the distance between the location determinants generated by the LDMs 140 and 142 .
  • the identified location determinant, and the new confidence factor calculated at block 348 are outputted from the sandwich LDM 144 to the location filter 122 .
  • the method 340 then ends at block 352 .
  • the sandwich LDM 144 is different from the other LDMs, because it is the only LDM that does not operate to produce a location determinant that is potentially distinct from the location determinants produced by the other LDMs.
  • the sandwich LDM 144 works as an extra enforcer to further empower the LKH and NKH LDMs 140 and 142 . For example, if an exemplary host has a LKH location determinant and a NKH location determinant, the sandwich LDM 144 will choose the more confident of the two location determinants and assign a confidence factor based on their joint confidence factors and their distance to one another.
  • the sandwich LDM 144 addresses a potential inability of LKH and NKH LDMs 140 and 142 to work together successfully in filling in so-called “sure thing” gaps. For example, if hop #10 of a traceroute is in New York City and hop #13 is in New York City, then it can be assumed with a high degree of certainty that hops #11 and #12 should also be in New York City. This scenario is then generalized to treat not just identical NKH and LKH location determinants, but also ones that are very close to one another.
  • the sandwich LDM 144 in an exemplary embodiment, utilizes a single confidence map 354 illustrated in FIG. 23 to assign a confidence factor to a location determinant.
  • Y-axis Mean confidence factor of LKH and NKH location determinants
  • the sandwich LDM 144 identifies which of the NKH or LKH location determinants as a higher confidence factor, it assigns a confidence factor to the identified location determinant that is only nontrivial if the LKH and NKH location determinants are very close and have a high mean confidence factor.
  • the suffix LDM 146 operates on hostnames. If a hostname is not available, the suffix LDM 146 does not run. Further, it requires that the hostname end in special words, specifically ISO country codes or state/province codes. Accordingly, the suffix LDM 146 does not employ artificial intelligence, and looks up the code (e.g., the ISO country code or a state/province code) and returns the corresponding geographic location information. The code lookup may be performed on the demographic/geographic database 31 . For example, a hostname that ends in ‘.jp’ is assigned to Japan; a hostname that ends in ‘.co.us’ is assigned to Colorado, USA.
  • the suffix LDM 146 can also identify dozens of large carriers that have presences in particular regions. For example, a hostname that ends in ‘.telstra.net’ is assigned to Australia; a hostname that ends in ‘.mich.net’ is assigned to Michigan, USA.
  • the suffix LDM 146 also has a special relationship with the location filter 122 . Because of its accuracy and generally large scale, the suffix LDM 146 is the only LDM that can insert location determinants into the location filter 122 , requiring that all other location determinants agree with the location determinant generated by the suffix LDM 146 , or they are not permitted to pass onto the location synthesis process 124 .
  • the suffix LDM 146 attributes a static confidence factor for all location determinants that it returns. This static confidence factor may, for example, be 91.
  • LDM “intelligence” is fairly large and, as will be appreciated from the above description, ranges from the thorough, hard-working RegEx LDM 130 , which may attempt to put a hostname with ‘telco’ in Telluride, Colo., to the precise Loc LDM 138 , which may generate precise location determinants. While the location synthesis process 124 , as will be described in further detail below, is intelligent enough to process a broader range of location determinants utilizing corresponding confidence factors, it is desirable to remove unreasonable location determinants from the location determinants that are forwarded to the location synthesis process 124 for consideration.
  • the suffix LDM 146 has a very high success rate in geolocation of a plethora of hosts, especially foreign ones. While the suffix LDM 146 lacks the high precision to be used by itself, the location determinant produced thereby may, in one exemplary embodiment, be deployed as a “filter location determinant”. Such a filter location determinant may, for example, be utilized by the location filter 122 to remove from the unified mapping process 61 location determinants that do not show a predetermined degree of correlation, agreement or consistency with the filter location determinant. A filter location determinant may, for example, be deployed to remove noise data, retaining a smaller, more manageable subset of location determinants that can be processed more quickly by the location synthesis process 124 .
  • the location filter 122 is tied directly to the suffix LDM 146 . Because of the reliability and accuracy of the suffix LDM 146 , the location determinant produced by this LDM 146 may be designated as the “filter location determinant”.
  • FIG. 24 is a flowchart illustrating a method 360 , according to an exemplary embodiment of the present invention, of filtering location determinants received from the collection of LDMs utilizing a filter location determinant.
  • the method 360 commences at block 362 with the running of a high accuracy LDM (e.g., the suffix LDM 146 ) to generate the “filter location determinant” and optionally an associated confidence factor.
  • a high accuracy LDM e.g., the suffix LDM 146
  • the filter location determinant and confidence factor generated thereby are communicated to the location filter 122 .
  • the location filter 122 determines whether the received filter location determinant is a state or country.
  • the location filter 122 intercepts multiple location determinants outputted by the collection of LDMs and bound for the location synthesis process 124 . The location filter 122 then checks to see if each of these location determinants adequately agrees with the filter location determinant. If they do, at block 372 , the location determinants proceed onward to the location synthesis process 124 by being retained in an input stack being for this process 124 . If they do not, at block 374 , then the location determinants are removed from the input stack for the location synthesis process 124 .
  • the agreement between the filter location determinant, and anyone of the multiple other location determinants received from the collection of LDMs, in one exemplary embodiment of the present invention, is a consistency between a larger geographic location (i.e., a location determinant of a relatively lower geographic location resolution) indicated by the filter location determinant and a more specific geographic location (i.e., a location determinant of a relatively higher geographic location resolution) that may be indicated by a subject location determinant.
  • location filter 122 may be effective in the debiasing of the United States data set.
  • the location synthesis process 124 may have a dozen or so ‘Londons’ to sort out. One is in the UK, and all the others are in the US.
  • the confidence factors generated by the RegEx LDM 130 will reflect likelihood of correctness and highlight London, UK, as the best, but if there is a ‘.uk’ at the end of the relevant hostname, then the location filter 122 can save the location synthesis process 124 from doing hundreds of thousands of extraneous operations.
  • the collection 120 of LDMs can conceptually be thought of as a collection of independent, artificially intelligent agents that continuously look at data and use their respective artificial intelligences to make decisions.
  • the collection 120 of different LDMs may disagree on any number of different levels. For example, two LDMs may return the same country and region, but different states and DMAs (Designated Marketing Areas). Alternatively, for example, one LDM may return a country only, while another LDM returns a city in a different country but on the same continent.
  • DMAs Designated Marketing Areas
  • the unified mapping process 61 includes the ability to analyze where the incoming location determinants agree, and where they disagree. From this analysis, the unified mapping process 61 operates to select the location determinant that has the highest likelihood of being correct. In order to perform this selection, the unified mapping process 61 includes the capability to assess the likelihood that it is correct.
  • the LDMs provide associated confidence factors along with the location determinants, as described above.
  • the confidence factors comprise quantitative values indicating levels of confidence that the LDMs have that the provided location determinants are in fact true. It should be noted that these confidence factors are not tied to any particular level of geographic granularity (or geographic resolution).
  • the location synthesis process 124 operates to produce a separate confidence factor for each level of geographic resolution or granularity (e.g., country, state, etc.).
  • FIG. 25 is a flowchart illustrating a method 380 , according to an exemplary embodiment of the present invention, performed by the location synthesis process 124 to deliver a single location determinant which the unified mapping process 61 has identified as being the best estimate of the “true” geographic location associated with any particular network address.
  • An initial discussion provides a high-level overview of the method 380 , with further details being provided below in the context of an illustrative example.
  • the method 380 commences at block 382 , where the location synthesis process 124 compares every location determinant received from the location filter 122 against every other location determinant (where appropriate). At block 384 , the location synthesis process 124 builds a confirmation confidence factor table. At block 386 , the location synthesis process 124 collapses separate confidence factors into one or more confirmation confidence factors, and at block 388 chooses a single location determinant as the best estimate based on one or more confirmation confidence factors. The choice of the “best estimate” location determinant at block 388 is performed by identifying the location determinant that exhibits a highest degree of confidence factor-weighted agreement with all the other location determinants. A final table of confidence factors generated for the “best estimate” location determinant is reflective of that agreement. The method 380 then ends at block 390 .
  • the location synthesis process 124 takes its input in the form of multiple sets of location determinants, as stated above. In one exemplary embodiment, a distinction is made between this method and a method of a flat set of all location determinants.
  • the location determinants are provided to the location synthesis process 124 as multiple sets.
  • the provision the location determinants in sets indicates to the location synthesis process 124 which location determinants should be compared against other. Specifically, efficiencies can be achieved by avoiding the comparison of location determinants within a common set, delivered from a common LDM.
  • the location synthesis process 124 iteratively compares each location determinant of each set with each location determinant of each other set.
  • the comparison in exemplary embodiment, because at a number of resolutions, for example:
  • the confirmation confidence factor table is a matrix of location determinants by geographic location resolution with their respective confirmation confidence factor.
  • the confirmation confidence factor calculation can be interpreted as a calculation of the probability that any of the agreeing location determinants are correct, given that the associated confidence factors are individual probabilities that each is independently correct.
  • the initial (empty) confirmation confidence factor matrix takes the form of the Table 5 illustrated below. TABLE 5 Initial confirmation confidence factor matrix. Country State City New York, NY, USA New York State, USA Elizabeth, NJ, USA London, UK Newark, NJ, USA
  • Each element of the matrix is computed by comparing all relevant (no intra-set mingling) matches. For example, evaluating the country confidence factor for New York, N.Y., USA yields the following Table 6: TABLE 6 Example Location Determinant Comparisons. Matches Country (always New York, NY, USA match self) Cannot Compare (same set) New York State, USA Matches Country Elizabeth, NJ, USA Does Not Match Country London, UK Matches Country Newark, NJ, USA
  • the location synthesis process 124 combines these three associated confidence factors (30, 25, and 50) to deliver the following confirmation confidence factor:
  • Confirmation confidence factors are, in this way, generated at a plurality of geographic resolutions (e.g., continent, country, state, city) by detecting correspondences between the location determinants at each of these geographic resolutions, and calculating the confirmation confidence factors for each of these geographic resolutions for each of the location determinants. Accordingly, utilizing the about calculation, the confirmation confidence factor table illustrated in Table 6 is populated as illustrated below in Table 7: TABLE 6 Completed confirmation confidence factor table. Country State City New York, NY, 73.75 30 30 USA New York State, 71.88 25 NA USA Elizabeth, NJ, 80.31 62.5 25 USA London, UK 20 20 20 Newark, NJ, USA 80.31 62.5 50
  • the location synthesis process 124 After the entire confirmation confidence factor table (or matrix) is generated at block 386 , the location synthesis process 124 then has the task of identifying the “best estimate” location determinant at block 388 . In the previous example, the correct answer is apparent from the combined confidence factor table. There is no better choice than Newark, N.J.; it is tied for first place on country and state levels, but it is first at the city level. However, consider the more complex examples in which one location determinant has the highest state confidence factor, but another has the highest DMA (Designated Marketing Area) confidence factor. To handle cases such as this, the location synthesis process 124 generates a combined confirmation confidence factor that is a linear combination of the constituent confirmation confidence factors.
  • DMA Designated Marketing Area
  • weights may, in an exemplary embodiment, be assigned to each of a plurality of levels of geographic resolution. Exemplary weights that may be utilized in the linear combination of the confirmation confidence factors are provided below:
  • These exemplary weights are indicative of the importance and significance of agreement at a given level of geographic resolution.
  • the PMSA and MSA geographic resolutions each have a zero weight because of their close ties with the DMA and City geographic resolutions. Agreement at the continental geographic resolution level is common and easy to achieve, and this resolution level is weighted very low in the combined confirmation confidence factor. Because the DMA geographic resolution level is considered to be the most significant level in the exemplary embodiment, it is allocated the highest weight.
  • the location synthesis process 124 selects the largest valued combined confidence factor and uses that location determinant as the final result (i.e., the “best estimate” location determinant). The location synthesis process 124 returns the single “best estimate” location determinant, along with an associated LPT (Location Probability Table) that constitutes the relevant location determinant's row of the confirmation confidence factor table.
  • LPT Location Probability Table
  • an LPT table (not shown) is maintained within the data warehouse 30 and stores the location probability tables generated for a block of network addresses (or for an individual network address).
  • An exemplary LPT table entry is provided below as Table 7: TABLE 7 LPT Column Description OCT1 1 st octet of the Network OCT2 2 nd octet of the Network OCT3 3 rd octet of the Network OCT4 4 th octet of the Network CONTINENT Continent code from the Continents Reference CODE Table where the Network is located. CONTINENT Confidence Factor Associated with the CONFIDENCE Identified Continent.
  • FACTOR COUNTRY Country code from the countries Reference CODE Table where the Network is located. COUNTRY Confidence Factor Associated with the CONFIDENCE Identified Country.
  • FACTOR REGION Region code from the Regions Reference Table CODE where the Network is located. This will be one of the Regions in the United States like Mid- West, West etc. REGION Confidence Factor Associated with the CONFIDENCE Identified Region.
  • ZIP Confidence Factor Associated with the CONFIDENCE Identified ZIP CODE FACTOR AREA CODE Telephone Area Code of the location where the network is located. Applicable to United States networks.
  • AREA CODE Confidence Factor Associated with the CONFIDENCE Identified AREA CODE FACTOR LATUTUDE Latitude of the location where the network is located. LONGITUDE Longitude of the location where the network is located. TIMEZONE Time Zone of location where the network is located.
  • the unified mapping process 61 outputs the “best estimate” location determinant together with a full Location Probability Table (LPT) (i.e., the end result 128 illustrated in FIG. 11).
  • LPT Location Probability Table
  • the values of the location probability table are the probabilities that the given location is correct at a number of geographic location resolution levels (or granularities).
  • the location synthesis process 124 does return an application probability table, and while the values in that are self-consistent and relatively meaningful, they are not location probabilities in the formal sense.
  • a translation is provided so that when a customer gets a result that is reported with a “90” confidence factor, the customer can know that if 100 records all with 90 confidence factor were pulled at random, roughly 90 of them would be correct.
  • This translation function is performed by the confidence accuracy translator 126
  • FIG. 26 is a graph 400 illustrating correctness of location determinants, as a function of post-location synthesis process confidence factor. It will be noted from the graph 400 that, in general, incorrect responses are generally given low confidence factors, and the higher confidence factors are generally associated with more correctness. To formalize this relationship, a moving average can be used to infer the rough relationship between confidence factors and accuracy.
  • FIG. 27 is a graph 402 illustrating correctness of location determinants as a function of post-LSP confidence factor, and the smoothed probability of correctness given a confidence factor range.
  • a curve 404 is a 41-point moving average, representing the probability that the given responses in that confidence factor neighborhood are right. Again, it has the desired shape. Low confidence factors are associated with low accuracy, and conversely, high confidence factors are associated with high accuracy.
  • carrying the confidence factors throughout the unified mapping process 61 is beneficial, because, in this way, not only can the unified mapping process 61 generally be skillful, but it can know when it is less skillful. What remains, however, it the final translation of post-location synthesis process confidence factors into probabilistically meaningful confidence factors.
  • the confidence accuracy translator 126 uses a piecewise linear approximation of the function by binning the data into equally sized, disjoint confidence factor bins.
  • FIG. 28 is a graph 406 illustrating correctness of location determinants as a function of post-LSP confidence factor, and the smoothed probability of correctness given a confidence factor range with picewise linear approximation.
  • a curve 408 is the approximation of the confidence factor-Accuracy relationship generated with each abscissa being the average confidence factor of the bin and each ordinate being the number of accuracy within the bin. Accordingly, the curve 408 can be and is used as an interpolation scheme for unified mapping process 61 to make the needed translation.
  • FIG. 29 shows a graph 411 plotting correctness of location determinants as a function of post-CAT confidence factor, and the smoothed probability of correctness.
  • Final results of the post-CAT confidence factors are compared against the actual accuracy in FIG. 29.
  • there is a strong correlation thus giving the final confidence factor the probabilistic meaning that is useful to end users to make meaningful decisions. While there is strong correlation, it should be noted that this is a general relationship and that, while pulling a random subset and verifying should yield comparable results, data may be noisy, and some populations may show disparities between confidence and real accuracy.
  • a latitude and longitude matching process may be utilized used to assist in the determination the geographic location of a given record. Only a network address (e.g., and IP address) is required for the longitude and latitude matching process to be successful. However, additional information, such as the owner's location, or proximal routers, may be utilized to achieve a higher probability of success.
  • a network address e.g., and IP address
  • additional information such as the owner's location, or proximal routers, may be utilized to achieve a higher probability of success.
  • the geographic locations identified by the longitude and latitude matching is utilized to compute distances, using this information to determine accuracy of a given record.
  • the information is compared with previous “hops” of the traceroute to the host. If the route forms a predictable pattern, a confidence factor maybe be increased.
  • the traced route geographically progresses toward the final hop 8 , leading to a decision that the destination is located within a certain range of accuracy.
  • the point of origin is Denver, Colo., and the destination is Salt Lake City, Utah.
  • the last four hops indicate a connection that is back-hauled through Denver, Colo., essentially geographically backtracking the route taken:
  • an approximate radius containing the target network address be generated.
  • the final destination will likely proceed through the same set of routers.
  • the final 3 hops leading up to the point of entry into the destination network are proximal, or at the very least, form a line toward the destination's point of entry, one may assume that the destination resides within the common latitude/longitude coordinates.
  • Using the attitude/latitude coordinates of other known landmarks allows a radius to be computed. Within this radius, metro areas and large cities will be known.
  • a traceroute is launched from the East Coast, the West Coast, and the North West. Route progression from the East Coast indicates a westward path, terminating in Texas. Route progression from the West Coast indicates an eastward path, terminating in Texas. Route progression from the North West indicates an eastward path, terminating in Texas.
  • Triangulation is the technique of using traceroutes originating from geographically widely separated locations and using the results to extrapolate a possible location for the target network address.
  • a general direction e.g. Northward, Eastward
  • Northward, Eastward may be extrapolate from the traceroutes using knowledge of the locations of the routers in the traceroute. This can then be used to place bounds on the possible location by creating an intersection of all traceroutes. For example, a traceroute going East from San Francisco, West from New Jersey is probably somewhere in the Central time zones. Directions for the traceroutes can be inferred by subtracting the geographical locations of the originating network address from those of the latest router in the trace that has a known location. Additionally, information about the number of hops in the traceroutes can be used to obtain estimates of distance.
  • a translation process may also generate a resolution indication. This will depend on:
  • FIG. 30 shows a diagrammatic representation of machine in the exemplary form of a computer system 500 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed.
  • the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.
  • PDA Personal Digital Assistant
  • the computer system 500 includes a processor 502 , a main memory 504 and a static memory 506 , which communicate with each other via a bus 508 .
  • the computer system 500 may further include a video display unit 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
  • the computer system 500 also includes an alpha-numeric input device 512 (e.g. a keyboard), a cursor control device 514 (e.g. a mouse), a disk drive unit 516 , a signal generation device 518 (e.g. a speaker) and a network interface device 520 .
  • the disk drive unit 516 includes a machine-readable medium 522 on which is stored a set of instructions (i.e., software) 524 embodying any one, or all, of the methodologies described above.
  • the software 524 is also shown to reside, completely or at least partially, within the main memory 504 and/or within the processor 502 .
  • the software 524 may further be transmitted or received via the network interface device 520 .
  • the term “machine-readable medium” shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention.
  • the term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.

Abstract

A method and a system perform geolocation activities relating to a network address. A database of network addresses, and associated geographic locations, is maintained. A query, including a network address, is received against the database for a geographic location associated with the network address. Information, concerning the query received against the database, is logged. Geolocation activities relating to at least the network address are modified based on the logged information.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • This application is a continuation of U.S. application Ser. No. 09/825,675 filed on Apr. 3, 2001, which in turn claims the priority benefit of U.S. Provisional Application No. 60/194,761, filed Apr. 3, 2000, and U.S. Provisional Application No. 60/241,776 filed Oct. 18, 2000. Each of the identified applications is hereby incorporated by reference.[0001]
  • FIELD OF THE INVENTION
  • The present invention relates generally to the field of geographic location determination and, more specifically, to a method and apparatus for estimating the geographic location of a network entity, such as a node coupled to the Internet. [0002]
  • BACKGROUND OF THE INVENTION
  • Geography plays a fundamental role in everyday life and effects, for example, of the products that consumers purchase, shows displayed on TV, and languages spoken. Information concerning the geographic location of a networked entity, such as a network node, may be useful for any number of reasons. [0003]
  • Geographic location may be utilized to infer demographic characteristics of a network user. Accordingly, geographic information may be utilized to direct advertisements or offer other information via a network that has a higher likelihood of being the relevant to a network user at a specific geographic location. [0004]
  • Geographic information may also be utilized by network-based content distribution systems as part of a Digital Rights Management (DRM) program or an authorization process to determine whether particular content may validly be distributed to a certain network location. For example, in terms of a broadcast or distribution agreement, certain content may be blocked from distribution to certain geographic areas or locations. [0005]
  • Content delivered to a specific network entity, at a known geographic location, may also be customized according to the known geographic location. For example, localized news, weather, and events listings may be targeted at a network entity where the geographic location of the networked entity is known. Furthermore content may be presented in a local language and format. [0006]
  • Knowing the location of network entity can also be useful in combating fraud. For example, where a credit card transaction is initiated at a network entity, the location of which is known and far removed from a geographic location associated with a owner of credit card, a credit card fraud check may be initiated to establish the validity of the credit card transaction. [0007]
  • SUMMARY OF THE INVENTION
  • According to first aspect of the present invention, there is provided a method to collect geographic location information. Geographic location information, associated with at least one network address, is collected utilizing a plurality of geographically dispersed data collection agents. The geographic location information is utilizing to associate a geographic location with the network address. [0008]
  • Other aspects of the present invention will be apparent from the accompanying drawings and from the detailed description that follows. [0009]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: [0010]
  • FIG. 1A is a diagrammatic representation of a deployment of a geolocation system, according to an exemplary embodiment of the present invention, within a network environment. [0011]
  • FIG. 1B is a block diagram providing architectural details regarding a geolocation system, according to an exemplary embodiment of the present invention. [0012]
  • FIG. 2 is a block diagram illustrating software architecture for a geolocation system, according to an exemplary embodiment of the present invention. [0013]
  • FIG. 3 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of collecting data utilizing a number of data collection agents. [0014]
  • FIG. 4A is a state diagram illustrating general dataflow within the geolocation system, according to an exemplary embodiment of the present invention. [0015]
  • FIG. 4B is a state diagram illustrating dataflow, according to an exemplary embodiment of the present invention, during a geolocation data collection and analysis process. [0016]
  • FIG. 5 is a diagrammatic overview of dataflow pertaining to a data warehouse, according to an exemplary embodiment of the present invention. [0017]
  • FIG. 6 is a flowchart illustrating operation of a data collection agent, according to an exemplary embodiment of the present invention, upon receipt of a request from an associated data collection broker. [0018]
  • FIG. 7 is a flowchart illustrating operation of a data collection broker, according to an exemplary embodiment of the present invention, upon receipt of a job request from a user via an interface. [0019]
  • FIG. 8 is a diagrammatic representation of operation of an analysis module, according to an exemplary embodiment of the present invention. [0020]
  • FIGS. 9A and 9B show a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of tiered estimation of a geolocation associated with a network address. [0021]
  • FIGS. 10A and 10B illustrate exemplary networks, a first of which has not been subnetted, and a second of which has been subnetted. FIG. 11 is a block diagram illustrating a process flow for a unified mapping process, according to an exemplary embodiment of the present invention. [0022]
  • FIGS. 12A and 12B illustrate respective one-dimensional and two-dimensional confidence maps, according to exemplary embodiments of present invention. [0023]
  • FIG. 13 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a RegEx LDM to identify one or more geographic locations associated with network address and associated at least one confidence factor with each of the identified geographic locations. [0024]
  • FIGS. [0025] 14A-14Q illustrate an exemplary collection of confidence maps that may be utilized by the RegEx LDM to attach confidence factors to location determinants.
  • FIG. 15 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by the Net LDN to identify one or more geographic locations for a network address, or a block of network addresses, and to associated at least one confidence factor with each of the geographic locations. [0026]
  • FIGS. [0027] 16A-16E illustrate an exemplary collection of confidence maps that may be utilized by the Net LDM to attach confidence factors to location determinants.
  • FIG. 17 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by the DNS LDM identify one or more geographic locations for network address, and to associated at least one confidence factor with each of the geographic locations. [0028]
  • FIGS. [0029] 18A-18E illustrate an exemplary collection of confidence maps that may be utilized by the DNS LDM to attach confidence factors to location determinants.
  • FIGS. [0030] 19A-19E illustrate an exemplary collection of confidence maps that may be utilized by the ASN LDM to attach confidence factors to location determinants.
  • FIGS. [0031] 20A-20C illustrate an exemplary collection of confidence maps that may be utilized by the LKH LDM to attach confidence factors to location determinants.
  • FIGS. [0032] 21A-21C illustrate an exemplary collection of confidence maps that may be utilized by the NKH LDM to attach confidence factors to location determinants.
  • FIG. 22 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a sandwich LDM to identify one or more geographic locations for a network address, and to associate at least one confidence factor with each of the geographic locations. [0033]
  • FIG. 23 illustrate an exemplary confidence that may be utilized by the sandwich LDM to attach confidence factors to location determinants. [0034]
  • FIG. 24 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, of filtering location determinants received from a collection of LDMs utilizing a filter location determinants. [0035]
  • FIG. 25 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, performed by a location synthesis process to deliver a single location determinant that the unified mapping process has identified as a best estimate of a geographic location. [0036]
  • FIG. 26 is a graph illustrating correctness of location determinants, as a function of a post-location synthesis process confidence factor. [0037]
  • FIG. 27 is a graph illustrating correctness of location determinants as a function of post-location synthesis process confidence factor, and a smoothed probability of correctness given a confidence factor range. [0038]
  • FIG. 28 is a graph illustrating correctness of location determinants as a function of a post-location synthesis process confidence factor, and a smoothed probability of correctness given a confidence factor range. [0039]
  • FIG. 29 is a graph illustrating correctness of location determinants as a function of a post-confidence accuracy translation confidence factor, and a smoothed probability of correctness. [0040]
  • FIG. 30 shows a diagrammatic representation of a machine in exemplary form of a computer system within which a set of instructions, for causing the machine to perform any of the methodologies discussed above, may be executed.[0041]
  • The file of this patent contains at least one drawing executed in color. Copies of this patent with color drawing(s) will be provided by the Patent and Trademark Office upon request and payment of the necessary fee. [0042]
  • DETAILED DESCRIPTION
  • A method and a system to collect geographic location information for a network address utilizing geographically dispersed data collection agents are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. [0043]
  • For the purposes of the present specification, the term “geographic location” shall be taken to refer to any geographic location or area that is identifiable utilizing any descriptor, metric or characteristic. The term “geographic location” shall accordingly be taken to include a continent, a country, a state, a province, a county, a city, a town, village, an address, a Designated Marketing Area (DMA), a Metropolitan Statistical Area (MSA), a Primary Metropolitan Statistical Area (PMSA), location (latitude and longitude), zip or postal code areas, and congressional districts. Furthermore, the term “location determinant” shall be taken to include any indication or identification of a geographic location. [0044]
  • The term “network address”, for purposes of the present specification, shall be taken to include any address that identifies a networked entity, and shall include Internet Protocol (IP) addresses. [0045]
  • Typically, most network addresses (e.g., IP addresses) are associated with a particular geographic location. This is because routers that receive packets for a particular set of machines are fixed in location and have a fixed set of network addresses for which they receive packets. The machines that routers receive packets for tend to be geographically proximal to the routers. Roaming Internet-Ready devices are rare exceptions. For certain contexts, it is important to know the location of a particular network address. Mapping a particular network address to a geographic location may be termed “geolocation”. An exemplary system and methodology by which geographic locations can be derived for a specific network addresses, and for address blocks, are described below. Various methods of obtaining geographic information, combining such geographic information, and inferring a “block” to which a network address corresponds and which shares the same geographic information are described. [0046]
  • The exemplary system and method described below include (1) a data collection stage, (2) a data analyses stage, and (3) a delivery stage. [0047]
  • System Architecture
  • FIG. 1A is a diagrammatic representation of a deployment of a [0048] geolocation system 10, according to an exemplary embodiment of the present invention, within a networked environment 8. Various components of the system 10 are shown in the attached Figures to be coupled by networks 4. The geolocation system 10 is shown to include: (1) a data collection and analysis system 12 that is responsible for the collection and analysis of information useful in geolocating a network address; (2) a delivery engine system 16, including a number of delivery engine servers 64, which operate to provide geolocation information to a customer; and (3) a data warehouse 30 that stores collected information useful for geolocation purposes and determining geolocations for specific network addresses (or blocks of network addresses).
  • Geolocation data is distributed from the [0049] data warehouse 30 to the delivery engine system 16 for delivery to a customer in response to a query.
  • More specifically, in one exemplary embodiment, the data collection and [0050] analysis system 12 operates continuously to identify blocks of network addresses (e.g., Class B or Class C subnets) as will be described in further detail below, and to associate a geographic location (geolocation) with the identified blocks of network addresses. A record is then written to the data warehouse 30 for each identified block of network addresses, and associated geolocation. In one exemplary embodiment, a record within the data warehouse 30 identifies a block of network addresses utilizing a subnet identifier. In a further exemplary embodiment, a record within the data warehouse identifies a start and end network address for a relevant block of network addresses. In an even further exemplary embodiment, a record identifies only a single network address and associated geolocation. The data collection and analysis system 12 operates to continually updated and expand the collection of records contained within the data warehouse 30. An administrator of the data collection and analysis system 12 may furthermore optionally directed the system 12 to focus geolocation activities on a specific range of network addresses, or to prioritize geolocation activities with respect to specific range of network addresses. The data collection and analysis system 12 furthermore maintains a log of network addresses received that did not map to a block of network addresses for which a record exists within the data warehouse 30. The data collection and analysis system may operate to prioritize geolocation activities to determine geolocation information for network addresses in the log.
  • In an exemplary use scenario, an Internet user may, utilizing a user machine that hosts a [0051] browser 1, access a web site operated by the customer. The custom website is supported by the application server 6, which upon receiving an IP address associated with the user machine 2, communicates this IP address to the geolocation Application Program Interface (API) 7 hosted that the customer site. Responsive to receiving the IP address, the API 7 communicates the IP address to a delivery engine server 64 of the delivery engine system 16.
  • In the manner described in further detail below, the data collection and [0052] analysis system 12 generates a location determinant, indicating at least one geographic location, and an associated location probability table, that is communicated back to the customer. More specifically, the delivery engine server 64 attempts to identify a record for a block of network addresses to which the received IP address belongs. If the delivery engine server 64 is successful in locating such a record, geolocation information (e.g., a location determinant) stored within that record is retrieved and communicated back to the customer. On the other hand, if the delivery engine server 64 is unsuccessful in locating a record within the data warehouse 30, the relevant IP address is logged, and a “not found” message is communicated to the customer indicating the absence of any geolocation information for the relevant IP address.
  • The customer is then able to utilize the location determinant for any one of multiple purposes (e.g., targeted advertising, content customization, digital rights management, fraud detection etc.) [0053]
  • FIG. 1B is a block diagram providing further details regarding a physical architecture for the [0054] geolocation system 10, according to an exemplary embodiment of the present invention. At a high level, the geolocation system 10 comprises the data collection and analysis system 12, a data warehouse system 14, and the delivery engine system 16. FIG. 2 is a block diagram illustrating software architecture for the geolocation system 10, according to an exemplary embodiment of the present invention.
  • The data collection and [0055] analysis system 12 is shown to collect data from geographically dispersed, strategically placed remote data collection agents 18, hosted on data collection machines 20. A group of data collection agents 18 is controlled by a data collection broker 22, which may be hosted on a data analysis server 24. The data collected by a data collection broker 22, as shown in FIG. 2, is delivered to a data collection database 26, and is analyzed utilizing an analysis module 28. The analysis module 28 implements a number of analysis techniques to attach a known or estimated geographic location to certain network information (e.g., the source or destination address of a network request). A resulting location record, along with all supporting information, is then written into a data warehouse 30 of the data warehouse system 14. The geolocation system 10, in one embodiment, supports the following features:
  • Implementation of a [0056] data collection agent 18 capable of individually performing a number of data collection operations in accordance with a number of analysis techniques utilized by the analysis module 28; and
  • Implementation of a [0057] data collection broker 22 capable of determining which of a number of analysis techniques, utilized by the analysis module 28, to utilize for a given network information (e.g., an IP address).
  • FIG. 2 illustrates a number of a [0058] data collection agents 18 hosted at geographically disperse locations. For example, these disperse locations may be with separate service providers. The location of the data collection agents 18 at disperse locations assists the geolocation system 10 by providing different “points of view” on the network target.
  • Each [0059] data collection agent 18 is responsible for actual execution of a data collection process, or search, to locate and extract data that is the useful for the determination of a geolocation. Further details regarding exemplary searches are provided below. For example, a traceroute search is conducted by a data collection agent 18 responsive to a search request received at a data collection agent 18 from a data collection broker 22. Each data collection agent 18, responsive to a request, will perform a search (e.g., a traceroute) to collect specified data, and determine the validity of the raw data utilizing built-in metrics. If successful, this data is provided to the data collection database 26, via a data collection broker 22, for analysis by the analysis module 28. Each data collection agent 18 further advises a controlling data collection broker 22 of the success or failure of a particular search.
  • Each [0060] data collection broker 22 controls a group of data collection agents 18. For example, given a network address, or a range of network addresses, a data collection broker 22 determines which data collection agents 18 are most appropriate for the specific search. Once the request has been sent to a group of data collection agents 18 from a data collection broker 22, a response is expected containing a summary of the search. If the search was successful, this information will be placed directly into the data collection database 26, at which time the analysis module 28 will determine an estimated geolocation of the searched addresses.
  • On the other hand, if a search is not successful, the [0061] data collection broker 22 takes the appropriate action, and the data is not entered into the data collection database 26. At this time, the data collection broker 22 hands the search request to another data collection broker 22, which performs the same process.
  • The [0062] data collection database 26 contains current state information, as well as historical state information. The state information includes statistics generated during the data acquisition by the data collection agents 18, as well as failure statistics. This allows an operator of the geolocation system 10 to visualize the actual activity of a data collection process.
  • Data Collection
  • FIG. 3 is a flowchart illustrating a method [0063] 38, according to an exemplary embodiment of the present invention, of collecting data utilizing a number of data collection agents 18.
  • At [0064] block 40, a user (or process) enters a job request to the data collection broker 22 via, for example, a web interface. Job scheduling is also an option for the user. At block 42, the relevant data collection broker 22 accepts a request, and determines what data collection agents 18 will service the request. The data collection broker 22 also sets a unique session identifier (USID).
  • At [0065] block 44, one or more data collection agents 18 accept a job, and report to the data collection broker 22 that submission was successful.
  • At [0066] block 46, the data collection broker 22 writes (1) a start mark, indicating that the job is underway, and (2) the unique session identifier to the data collection database 26.
  • At [0067] block 48, the data collection agents 18 perform various searches (e.g., traceroutes) to collect raw data, and stores results locally for later batch update.
  • At [0068] block 50, each of the data collection agents 18 informs the data collection broker 22 that the search has finished, with or without success. After the last data collection agent 18 reports its status, the data collection broker 22 instructs the data collection agents 18 to upload their information to the data collection database 26.
  • At [0069] block 52, after the last data collection agent 18 reports a finished database write, the data collection broker 22 instructs the data collection agents 18 to flush their local storage, and remain idle until the next search job.
  • At [0070] block 54, the analysis module 28 processes the newly entered data within the data collection database 26, and writes this data to the data warehouse 30.
  • The [0071] delivery engine system 16 is responsible for delivering geolocation information generated by the geolocation system 10. With reference to FIG. 1, the delivery engine system 16 may be viewed as comprising a delivery staging server 60, a statistics processing engine 62, one or more delivery engine servers 64 and a delivery engine plant daemon (not shown)
  • The [0072] delivery staging server 60 provides a reliable and scaleable location distribution mechanism for geolocation data and does not modify any data. The delivery staging server 60 provides a read-only copy of the geolocation information to the delivery engine servers 64, and is responsible for preparing geolocation information that should be distributed to the delivery engine servers 64. Each delivery staging server 60 prepares dedicated information for one product offering. The delivery staging server 60 will retrieve the geolocation information from the data warehouse 30 based on the product offering. The delivery staging server 60 configuration includes a customer list and a delivery engine servers list for deployment. At fixed intervals, geolocation information is refreshed from the data warehouse 30 and distributed to the delivery engine service 64. The refresh from the data warehouse 30 may be based on a number of factors such as a new product offering or refining the existing location data. Before each new load of the delivery engine servers 64, the delivery staging server 60 retrieves a current copy of customers and the delivery engine servers 64 associated with the relevant delivery staging server 60.
  • The administration of the [0073] delivery staging servers 60 is performed by a separate server that is also responsible for load balancing and backup configuration for the delivery staging servers 60.
  • The [0074] statistics processing engine 62 is responsible for retrieving customer access logs (hits and misses) and usage data from the delivery engine services 64 on a regular basis. This information is used, for example, as input for the load balancing criteria, and getting update information for the location misses. The usage statistics may also provide the required information to the billing subsystem.
  • All information sent to [0075] delivery engine service 64 is encrypted to prevent unauthorized use.
  • The [0076] delivery engine servers 64 are responsible for serving the clients of the geolocation system 10. The delivery engine servers 64 may be hosted at a client site or at a central data center. The delivery engine servers 64 are able to accept update information from the delivery staging server 60 and to serve current requests. Each delivery engine servers 64 saves all customer access information and provide this information to the statistics processing engine 62. In embodiment, each delivery engine server 64 provides an eXtensible Markup Language (XML)-based Application Program Interface (API) interface to the customers of the geolocation system 10.
  • A [0077] geolocation API 7, as described above with reference FIG. 1A, interfaces with a delivery engine server 64 from a customer application server. The geolocation API 7 may support a local cache to speed up the access, this cache being flushed whenever the delivery engine server 64 is reloaded. The geolocation API 7 may be configured to access an alternate server in case of a failure or high load on a single delivery engine server 64. Each delivery engine server 64 and delivery staging server 60 includes a Simple Network Management Protocol (SNMP) agent for network management.
  • Data Flow (Collection, Analysis and Delivery)
  • FIG. 4A is a state diagram illustrating general data flow, as described above and according to an exemplary embodiment of the present invention, within the [0078] geolocation system 10. FIG. 4B is a state diagram illustrating data flow, according to an exemplary embodiment of the present invention, during the geolocation data collection and analysis processes described above.
  • The [0079] analysis module 28 retrieves geolocation information from the data collection database 26 to which all data collection agents 18 write such information, in the manner described above. Specifically, the analysis module 28 operates a daemon, polling in a timed interval for new data within the data collection database 26. When new data is found, the analysis techniques embodied within sub-modules (Location Determination Modules LDMs) of the analysis module 28 are initiated, with the results of these analysis techniques being written to the primary data warehouse 30.
  • FIG. 5 provides an overview of data flow pertaining to the [0080] data warehouse 30, according to an exemplary embodiment of the present invention. As described above, data collection is performed by the data collection and analysis system 12. The results of the collection process are aggregated in the data collection database 26, which is an intermediary datastore for collection data. At some later point, data is taken from the database 26 by the analysis module 28, and the final analysis, along with all the supporting data, is placed into the data warehouse 30. The delivery staging servers 16 then pull a subset of data from the data warehouse 30 (this defines a product offering), and place this information into a staging database (not shown) associated with the delivery staging server 60. A staging database then pushes a copy of the geolocation information out to all delivery engine servers 64, which run a particular product offering.
  • The [0081] delivery staging servers 60 may provide the following customer information to the data warehouse 30:
  • Customer Registration [0082]
  • Customer Product License—level of support. [0083]
  • The following data is outputted from the data warehouse [0084] 30:
  • Product Description (US, whole Europe, UK etc) [0085]
  • Get customer list for the given product type [0086]
  • Get location information for the product. [0087]
  • Get list of [0088] delivery engine servers 64 that map to the product offering.
  • Store location data on the disk with version number [0089]
  • Build an in-memory database [0090]
  • Create customer specific information from the memory database. [0091]
  • Transfer data to Delivery Engine Production Systems. [0092]
  • The [0093] delivery staging servers 60 process requests from a client application by:
  • Parsing XML requests received from a client application. [0094]
  • Logging requests. [0095]
  • Looking up location information based on level of service. [0096]
  • Constructing a response and communicating the response back to the client application. [0097]
  • The [0098] delivery staging servers 60 process database updates by storing a new database with a version number on disk and building a new in-memory database for updates. Each update is a complete replacement of the existing in-memory database
  • The [0099] statistics processing engine 62 activates after a given period of time, checks the data warehouse 30 for a list of active client machines, and retrieves the statistics files from all of the deployed delivery engine servers 64. Once such files have been retrieved, the statistics processing engine 62 pushes the statistics into the data warehouse 30.
  • The [0100] geolocation system 10, according to the one embodiment, utilizes eXtensible Markup Language (XML) as a data transfer format, both within the above-mentioned subsystems, and as the delivery agent to customer systems. XML offers flexibility of format when delivering geolocation information, and extensibility when the geolocation system 10 offers extended data in relation to geographic location, without having to reprogram any part of the client interfaces.
  • A standard XML parser technology may be deployed throughout the [0101] geolocation system 10, the parser technology comprising either the Xerces product, a validating parser offered by the Apache group, or XML for C++, written by the team at IBM's AlphaWorks research facility, which is based on the Xerces parser from Apache, and includes Unicode support and other extensions.
  • The [0102] geolocation system 10 utilizes numerous Document Type Definitions (DTDs) to support the XML messaging. DTDs serve as templates for valid XML messages.
  • The standard response to a customer system that queries the [0103] geolocation system 10, in one exemplary embodiment of the present invention, is in the form of a location probability table (LPT), an example of which is provided below. A location probability table may be an XML formatted message, containing a table of information representing location granularity (or resolution), location description, and a confidence percentage.
    <?xml version=“1.0”?>
    <Service provider name>
      <geolocation type=“response”>
        <ipaddress>128.52.46.11</ipaddress>
        <lpt>
            <continent>
              <value type=“string”>North America</value>
              <confidence>100%</confidence>
          </continent>
            <country>
              <value type=“string”>United States</value>
              <confidence>99%</confidence>
          </country>
            <region>
              <value type=“string”>New England</value>
              <confidence>97%</confidence>
          </region>
            <state>
              <value type=“string”>Massachusetts</value>
              <confidence>96%</confidence>
          </state>
            <areacode>
              <value type=“integer”>617</value>
              <confidence>94%</confidence>
          </areacode>
            <msa>
              <value type=“string”>Boston MSA</value>
              <confidence>94%</confidence>
          </msa>
            <city>
              <value type=“string”>Cambridge</value>
              <confidence>93%</confidence>
          </city>
            <zipcode>
              <value type=“integer”>02142</value>
              <confidence>91%</confidence>
          </zipcode>
        </lpt>
      </geolocation>
    </quova>
  • As will be noted from the above example, the location probability table indicates multiple levels of geographic location granularity or resolution, and provides a location probability (or confidence factor) for each of these levels of geographic resolution. For example, at a “country” level of geographic resolution, a relatively high probability level may be indicated. However, at a “city” level of geographic resolution, a relatively low probability level may be indicated in view of a lower confidence in the geolocation of the network entity at an indicated city. [0104]
  • The above location probability table constitutes a XML response to a geolocation request for the IP address 128.52.46.11. The city where the address is located is Cambridge, Mass., USA, identified with granularity (or geographic resolution) down the zip code level, at a 91% confidence. [0105]
  • In an alternative embodiment, the location probability table may be formatted according to a proprietary bar delimited format specification. [0106]
  • A more detailed description of the various systems that constitute the [0107] geolocation system 10, and operation of the geolocation system 10, will now be provided.
  • A [0108] data collection agent 18 operates to receive commands from an associated data collection broker 22, and includes logic to execute a number of data collection operations specific to a number of analysis processes implemented by the analysis module 28. Each data collection agent 18 reports results back to an associated data collection broker 22 that performs various administrative functions (e.g., start, stop, restart, load, process status). FIG. 6 is a flowchart illustrating functioning of a data collection agent 18, according to an exemplary embodiment of the present invention, upon receipt of a request from an associated data collection broker 22.
  • A [0109] data collection broker 22 determines what actions are required responsive to a request from a customer (e.g., check new addresses, recheck older addresses, etc.), and provides instructions to one or more data collection agents 18 regarding what function(s) to perform with respect to certain network information (e.g., a network address).
  • Each [0110] data collection broker 22 further stores raw data (geolocation information) into the data collection database 26, performs load balancing of requests across multiple data collection agents 18, performs administrative functions with respect to data collection agents 18 (e.g., requests stops, starts, status etc.) and performs various internal administrative functions (e.g. start, stop, restart, load). FIG. 7 is a flowchart illustrating functioning of a data collection broker 22, according to an exemplary embodiment of the present invention, upon receipt of a job request from a user via a Web interface or any other interface.
  • The [0111] analysis module 28, according to one exemplary embodiment, operates to extract raw data from the data collection database 26, process the data according to one or more analysis algorithms (or modules) to generate a location probability table, and to store results and the raw data into the data warehouse 30. FIG. 8 is a diagrammatic representation of operation of the analysis module 28, according to an exemplary embodiment of the present invention.
  • The [0112] delivery engine servers 64 except queries (e.g., in XML format), return responses, lookup query information in a main memory database, report statistics to flat files for the data processing, respond to administrative functions, and except push updates to create second run-time databases and perform switchover.
  • The [0113] delivery servers 64 operate to scan content within the data warehouse 30, creating specific service offerings (e.g., North America, by continent, by country), and push content out to the delivery engine servers 64.
  • Data Collection
  • As described above, each of the [0114] data collection agents 18 may implement one of multiple data collection processes to obtain raw geolocation information. These data collection processes may, in one exemplary embodiment of the present invention, access any one or more of the following data sources:
  • Net Whois Record: The Net Whois record is an entry in a registry that tracks ownership of blocks of Internet Protocol (IP) addresses and address space. Such records are maintained by RIPE (Reseaux IP Europeens), APNIC (Asia Pacific Network Information Centre), ARIN (American Registry of Internet Numbers), and some smaller regional Internet registries. For instance, the IP network address 192.101.138.0 is registered to Western State College in Gunnison, Colo. [0115]
  • DNS Whois Record: The DNS Whois record is an entry in a registry that tracks ownership of domain names. This is maintained by Network Solutions, Inc. For instance, quova.com is registered to Quova, Inc. in Mountain View, Calif. [0116]
  • ASN Whois Record: An ASN Whois record is an entry in a registry that tracks autonomous systems. An autonomous system (AS) is a collection of routers under a single administrative authority using a common Border Gateway Protocol for routing packets. ASN databases are maintained by a number of organizations. [0117]
  • DNS Loc Record: Occasionally, a DNS Location (Loc for short) record is stored, which indicates the precise latitude, longitude, and elevation of a host. [0118]
  • Traceroute: A traceroute shows the route of a data packet from a data collection machine to a target host. Much information can be derived from the analysis of a traceroute. For instance, if [0119] hop #10 is in California, and hop #13 is in California, then with increased certainty, it can be inferred that hops #11 and #12 are also in California.
  • In addition to the above data that may be collected by the [0120] data collection agents 18, the analysis module 28 may also utilize the following information sources in performing an analysis to estimate a geographic location for network address:
  • Hostname: An IP network address is often tied to a hostname. The hostname may have information indicative of location. Carriers typically implement this to more easily locate their own hardware. For instance, bbr-g2-0.sntc04.exodus.net is in Santa Clara, Calif.; ‘sntc’ is Exodus' abbreviation for Santa Clara. [0121]
  • Demographic/Geographic Data: Implicit in much of the decision making processes is information about the different locations of the world. The [0122] analysis module 28, in one embodiment, utilizes a demographic/geographic database 31, shown in FIGS. 1B and 2 to be part of the data warehouse 30, storing a city record for every city in the U.S.A. and all foreign cities with populations of greater than 100,000 people. Tied to each city are its state, country, continent, DMA (Designated Marketing Area), MSA (Metropolitan Statistical Area), PMSA (Primary Metropolitan Statistical Area), location (latitude & longitude), sets of zip/postal codes, congressional districts, and area codes. Each city record also has population and a connectivity index, which is based on the number of major carriers that have presence in that city.
  • Analysis Module
  • As illustrated in FIG. 2, the [0123] analysis module 28 includes a collection of blocking algorithms 63, a unified mapping process 61, and a consolidated domains algorithm 65. FIGS. 9A and 9B show a flowchart illustrating a method 70, according to an exemplary embodiment of the present invention, of tiered estimation of the geolocation associated with a network address. Specifically the tiered estimation of a geolocation employs a number of exact processes and, if the exact processes fail, a number of inexact processes. In an alternative embodiment of the present invention, no distinction is made between exact and inexact processes (as shown in FIG. 11), and all processes are regarded as being located on a common tier. The method 70 is performed by the analysis module 28, and employs each of the algorithms 61, 63 and 65.
  • The [0124] method 70 commences at block 72 with the obtaining of a network address (e.g., an IP address) to be mapped. This network address may be received from an internal process performing an automated mapping operation (e.g., updating the geolocation information associated with a specific IP address), or from an external source (e.g., a customer that requires geolocation information concerning an IP address). The obtained network address is then queued within a main queue.
  • At [0125] block 74, the consolidated domain algorithm 65 is run. Specifically, a network address is removed from the main queue, and tested to determine whether it is likely to fall within a consolidated domain. If the tests of satisfied, as determined at decision block 76, the relevant network address and the geolocation information determined by the consolidated domains algorithm 65 are written to a record within the data warehouse 30 at block 78.
  • The [0126] consolidated domain algorithm 65 utilizes the fact that some domains have all of their IP network addresses concentrated in a single geographic location. The domain suitability is judged by the algorithm 65 on the basis of other domain properties other than size. Such domains typically include colleges and universities (except those that have multiple campuses), small businesses that are known to be located in a single location, government labs, etc.
  • Examples of domains that may be utilized by the [0127] algorithm 65 include:
  • The “.edu” domain: Because of the nature of educational institutions, “.edu” domains are typically consolidated domains. An extensive list of “.edu” domains can be obtained from web resources (by looking up the appropriate categories under the main search engines). IP lists (from web-server access logs, etc.) can also be translated to names and checked for an ending “.edu”. Then they can be sorted into unique names. [0128]
  • Local businesses: The major web search engines also list local businesses for each area. [0129]
  • Local Internet Service Providers (ISPs): Some Internet Service Providers are local to only one region. [0130]
  • Government laboratories: A number of government laboratories satisfy the consolidated domain criterion. [0131]
  • The above described method may encounter domain names that contain extraneous information (e.g., “glen.lcs.mit.edu”), when in fact the domain name required is “mit.edu”. In general, the name behind the “.edu.” entry is part of the domain but everything before it is extraneous (note that this will include .edu domains in other countries). This also holds for government labs (“x.gov”), and commercial (“x.com”). Names derived from the above methods are pre-processed to truncate them to the appropriate domain name according to the above rules. [0132]
  • Returning to FIG. 9A, if the conditions of the consolidated domain algorithm remain unsatisfied, at [0133] block 80, the relevant network address is reinserted into the main queue, and flagged as having failed to satisfy the conditions imposed by the consolidated domain algorithm 65.
  • At [0134] block 82, one or more of blocking algorithms 63 are executed to determine a network address block size around the relevant network address. Further details regarding exemplary blocking algorithms 63 are provided below. A blocking algorithm 63 performs a check of neighboring network addresses to find the expanse of a “block” of network addresses that share common information (e.g., a common subnet segment). The identification of a block of network addresses is useful in that information regarding a particular network address may often be inferred from known information regarding neighboring network addresses within a common block.
  • At [0135] block 84, if a block of network addresses associated with a subject network address is identified, this block of network addresses is then inserted into the main queue for further processing in association with the subject network address.
  • Moving on to FIG. 9B, at [0136] block 86, one or more “exact” geographic location processes (e.g., traceroutes, latency calculations, hostname matching and the DNS Loc LDM) are run to determine whether geolocation information can be determined for the subject network address, and optionally for other network addresses of the block of network addresses. The “exact” processes are labeled as such as they render geolocation information with a relatively high confidence factor. Further, the exact processes may render geolocation information for neighboring network addresses within a block to increase the confidence factor of geolocation information rendered for a subject network addresses.
  • At [0137] decision block 88, a determination is made as to whether the exact processes with successful in generating geolocation information with a predetermined confidence factor, and whether a blocking was verified. If so, at block 90, the network address and the determined geolocation information are written into a record within the data warehouse 30.
  • On the other hand, following a negative determination at [0138] decision block 88, the method 70 progresses to block 92, where a series of “inexact” geographic location operations (or algorithms) are executed on the subject network address, and optionally on one or more network addresses within an associated block. The “inexact” processes are labeled as such in view of the relatively lower confidence factor with which these inexact processes render geolocation information associated with a network address. In one exemplary embodiment, a number of inexact processes are executed on a number of network addresses surrounding a subject network address, and the outputs of these inexact processes are consolidated by the unified mapping process 61, which considers the output from each of the number of inexact processes (e.g., the below discussed Location Determination Modules (LDMs)). Further details are provided below.
  • At [0139] decision block 94, a determination is made as to whether the inexact processes generated a predetermined confidence factor for geolocation information for the subject network address. If so, the network address and associated geolocation information are again written into a record within the data warehouse 30 at block 96. On the other hand, following a negative determination at decision block 94, the network address may be forwarded for a manual resolution at block 98. The method 70 then exits at block 100.
  • Queuing
  • Queuing interfaces exist for both processes (e.g., scripts or algorithms) scripts that enter items into the main queue discussed above, as well as for processes that remove items form the main queue. [0140]
  • When a “block” of network addresses is successfully entered into the [0141] data warehouse 30 by an exact algorithm at block 90, the entire main queue is searched for entries that fall within that block of network addresses. These entries are then be removed because they are part of a block that is known to be accurate. If a block of network addresses is entered the data warehouse 30 with a high confidence factor, the main queues are searched for entries within that block. These entries can then be forwarded to a quality assurance queue (not shown).
  • Blocking
  • As stated above, one or [0142] more blocking algorithms 63 are executed at block 82 shown in FIG. 9A to identify a “block” of network addresses surrounding a subject network address that may share common information or characteristics with the subject network address. Three exemplary blocking algorithms 63 to perform a blocking operation around a subject network address are discussed below, namely: (1) a divide-and-conquer blocking algorithm; (2) a netmask blocking algorithm; and (3) a blocking algorithm that utilizes RTP tables, BGP tables, and ISP topology maps. As is described with reference to blocks 86 and 92, once an entire network segment has been blocked, the entire network segment can be processed by the exact and inexact processes, and return one complete record for each network that he stored within the data warehouse 30. This is advantageous in that the number of hosts that are required to be processed is reduced, and the amount of data that is required to be collected is also reduced.
  • The divide-and-conquer blocking algorithm receives a subject network address, and possibly the associated information (e.g. location), and checks neighboring network addresses to find the extent of the block of network addresses that share the common information. The algorithm starts with a first test network address halfway to the end of a block and test with a predicate to determine whether the first test network address has same information as the subject network address. The “distance” between the subject network address and the first network address is then halved and the result added to the current distance if the answer was positive, or subtracted from the current distance if the answer was negative. This process is repeated until the distance offset is one. The divide-and-conquer blocking algorithm then returns to the top end Qf the block and, after competing an iteration, returns to the bottom end of the block. [0143]
  • The following exemplary Perl code implements a divide-and-conquer algorithm on the IP network address space: [0144]
    #!/usr/local/bin/perl
    #
    # Script to figure out the blocks for us given an IP
    #
    #
    # Target IP is expected as the first parameter
    #
    # define a couple of simple helper procedures
    #
    sub int2ip {
      local ($i, $a, $b, $c, $d);
      $i = @_[0];
      $a = int($i / (256*256*256));
      $i = $i % (256*256*256);
      $b = int($i / (256*256));
      $i = $i % (256*256);
      $c = int($i / 256);
      $i = $i % 256;
      $d = $i;
      return (“$a.$b.$c.$d”);
    }
    sub ip2int {
      split /\./, @_[0];
      return (@_[0]*256*256*256 +
          @_[1]*256*256 +
          @_[2]*256 +
          @_[3]);
    }
    #
    # Let's start!
    #
    $ip = $ARGV[0];
    $ipn = ip2int($ip);
    # set the distance to the initial value and let's go
    $offset = 256*256*256*256 − $ipn;
    $offset = int ($offset / 2);
    $dist = $offset;
    # do successive approximation for the top end of the block
    while ($offset > 0) {
      $test_ip = int2ip($ipn + $dist);
      $offset = int($offset / 2);
      if (test_pred($test_ip, $ipn)) {
        $dist = $dist + $offset;
      } else {
        $dist = $dist − $offset;
      }
    }
    $top = int2ip($ipn + $dist);
    # set the distance to the initial value and let's go
    $offset = int ($ipn / 2);
    $dist = $offset;
    # do successive approximation for the bottom end of the block
    while ($offset > 0) {
      $test_ip = int2ip($ipn − $dist);
      $offset = int($offset / 2);
      if (test_pred($test_ip, $ipn)) {
        $dist = $dist + $offset;
      } else {
        $dist = $dist − $offset;
      }
    }
    $bottom = int2ip($ipn − $dist);
    # $bottom and $top now contain the lower and upper bounds
    # of the block respectively
  • Note should be taken of the call to test_pred( ). This takes an IP network address and returns true if this IP network address shares the same information (i.e., is part of the same block) as the subject IP network address. [0145]
  • The function of the test predicate is to discover if the new network addresses explored by the divide-and-conquer algorithm belong to the same block as the subject network address. There are a number of exemplary ways in which this test predicate can be implemented. For example: [0146]
  • Obtaining a location: The [0147] unified mapping process 61 can be run on the test network address to derive a location and this location can be matched against the location of the subject network address. This imposes a relatively large-overhead per iteration of the divide-and-conquer algorithm.
  • Traceroute information: If the subject network address and the test network address follow the same route (modulo the last hop) then the network addresses are part of the same block. [0148]
  • DNS service: This test renders a positive result if the test network address and the subject network address use the same DNS server. [0149]
  • It will be appreciated that a number of other test predicates may be devised to implement blocking. [0150]
  • The netmask blocking algorithm, according to an exemplary embodiment of the present invention, relies on the assumption that a subnet will generally not be spread over multiple locations. If parts of a block of network addresses are in differing locations, such network addresses typically require a long-distance line and a switch or router to handle the traffic between locations. In such situations, it is generally more convenient to divide the network into a number of subnets, one for each location. Subnets in effect form a lower bound on the block-size. Therefore, blocking can be performed by obtaining the netmask (and therefore the subnet bounds) for a given network address (e.g., an IP address). Netmask's may be obtained from a number of sources, for example: [0151]
  • Obtaining netmasks by Internal Control Message Protocol (ICMP): One of the ICMP control packets is a request for the netmask of a particular interface. Normally, the ICMP specification states that an interface should respond to such a packet only if the appropriate flag has been set. However, there are a number of implementations of ICMP that are broken so that the interface will respond promiscuously. [0152]
  • Obtaining netmasks by Dynamic Host Configuration Protocol (DHCP): On dialing up to an ISP, a machine usually sends a DHCP request to obtain its network configuration information. Included in this information is a netmask. Monitoring the DHCP response (or in the case of Linux, an “ifconfig” call) will reveal this netmask. An automated script that does either is included in the dialup scripts to derive blocking information as mapping by the ISP dialup method occurs. Because the subnets may be subsets of the actual block, multiple dialup sessions may have to occur before the complete block is revealed. [0153]
  • Turning now specifically to the Internet, the smallest subnet that is usable on the Internet has a 30-bit subnet mask. This allows two hosts (e.g., routers) to communicate between themselves. Below is an example of a Class C Network that has been subnetted with a 30-bit subnet mask:[0154]
  • (1) First network with a 30-bit subnet mask: [0155]
  • x.x.x.0 Network Address [0156]
  • x.x.x.1 Lowest Usable Host [0157]
  • x.x.x.2 Highest Usable Host [0158]
  • x.x.x.3 Broadcast Address[0159]
  • (2) Second network with a 30-bit subnet mask: [0160]
  • x.x.x.4 Network Address [0161]
  • x.x.x.5 Lowest Usable Host [0162]
  • x.x.x.6 Highest Usable Host [0163]
  • x.x.x.7 Broadcast Address[0164]
  • (3) Third network with a 30-bit subnet mask: [0165]
  • x.x.x.252 Network Address [0166]
  • x.x.x.253 Lowest Usable Host [0167]
  • x.x.x.254 Highest Usable Host [0168]
  • x.x.x.255 Broadcast Address[0169]
  • Knowing that the smallest subnet mask is a 30-bit subnet mask, the netmask blocking algorithm can avoid “hitting” the lowest address (i.e., the Network Address) and the highest address (i.e., the Broadcast Address) of a subnet by stepping through the address space. This technique allows the netmask blocking algorithm to avoid automatic security auditing software that may incorrectly assumed a SMURF attack is being launched. [0170]
  • Only two hosts per subnet/network are required by the netmask blocking algorithm to determine if it has been “subnetted” or not, provided that the IP network addresses are sufficiently far apart. [0171]
  • The below described algorithm provides at least two benefits, namely (1) that the data collection process becomes less intrusive and (2) a performance benefit is achieved, in that by limiting the number of hosts that are processed on each network, it is possible to “process” a large network (e.g., the Internet) utilizing a relatively small data set. [0172]
  • Consider the example of a Class C network that is not subnetted, such as that illustrated at [0173] 102, in FIG. 10A. This can be determined by collecting traceroute data from a low host (e.g., less than 128) and a high host (e.g., greater than 128) by examining the next-to-last hop in both traceroute's, it is observed that both trace hops go through the same next-to-last-hop router, and therefore utilizing the same subnet.
  • FIG. 10B is a diagrammatic representation of a [0174] Class C network 104 that has been subnetted. In this example, it is assumed that traceroute data for the network addresses 2.2.2.1 and 2.2.2.254 has been collected and is known. By looking one hop back, it can be determined that the network has been subnetted. Since the network is identified as being subnetted, additional host will be required. For example in a Class C network, 256 hosts may be divided over multiple locations. For example, IP addresses 1-64 may be in Mountain View, 65-128 may be in New York, 129-and 92 may be in Boston, and 123-256 are in Chicago. This example, even though a network block is registered as a Class C network to an entity, multiple records are required to accurately represent the data since there are multiple locations for the entity. In this case, 4 records are required. The netmask blocking algorithm accordingly starts looking for hosts at the high end of the lower network, and inversely for the low end of the high network. Assuming that responses are obtainable from the hosts in the network illustrated in FIG. 10A, it can be determined by the subnet blocking algorithm that the Class C network has been subnetted once. Another way of determining this outcome would be to view the relevant network as two 25-bit networks, rather than a single 24-bit network.
  • This technique of “divide and conquer”, combined with more selective pinging/tracerouting allows the subnet blocking algorithm to create a reduced impression in security logs of networks. [0175]
  • A further consideration is a situation in which a traceroute is obtained to a router that has an interface on an internal network. In this case, the traceroute will stop at the routers external interface. This may result in the blocking of a network multiple times. In order to address this problem, a determination is made by the subnet blocking algorithm as to whether the end node of a traceroute is the same as the next-to-last hop of other traceroutes on the network. If so, the above described situation is detected. [0176]
  • Digital Subscriber Line (DSL) and cable modems do not appear to routers when they have multiple interfaces. This can result in the creation of false results. To address the situation, the subnet blocking algorithm looks for patterns in the last three hops. By looking at this information, the algorithm is able to determine appropriate blocking for the high-speed modem network. [0177]
  • Some routers also allow for networks to be subnetted to different sizes within a predefined network block. In this situation, a Class C network may be subnetted into two networks, one of which is then further divided into number of smaller networks. To account for the situation, the subnet blocking algorithm verifies every block within two traceroutes. This enables the location of at least one node per network. [0178]
  • A further exemplary algorithm may also perform blocking utilizing RIP tables, BGP tables and ISP topology maps. The division into blocks that are routed to a common location stems from the way routing is performed. Availability of the internal routing tables for an Autonomous System, or a topology map for an ISP, may be utilized to obtain the block information as such tables and maps explicitly named the blocks that are routed through particular routes. [0179]
  • Using RIP and other internal routing tables: Routing tables have a standard format. Each route consists of a network prefix and possibly a netblock size, along with the route that IP addresses belonging to that netblock should follow and some metrics. The values of interest for blocking are the netblock and the netblock size. A script extracts the netblock and netblock size for each route in the table, and then either obtains an existing location or geolocates one IP network address in the block by any of the existing methods and enter the result into the [0180] data warehouse 30.
  • Using BGP routing tables: BGP routing tables have the same structure as internal routing tables with minor exceptions. All routes in the BGP table have a netblock size associated with them, and the route is given in terms of AS paths. Most routes within a BGP table are of little use in determining a block because they do not take into account the routing performed within an Autonomous System. However, BGP tables contain a large number of exception routes. Very often, the blocks corresponding to these routes represent geographically compact domains, and the netblock and netblock size can be used as extracted from the BGP table. Exception routes can be recognized easily since they are subsets of other routes in the table. For example:[0181]
  • 24.0.0.0/8 . . . [0182]
  • 24.32.0.0/24 . . . [0183]
  • The second route in the above example is a subset of the first route and is by definition an exception route. [0184]
  • (3) Using ISP topology maps: ISP topology maps usually contain the netblocks that each router handles. These can be used as above. The format is non-standard and requires decoding. A dedicated scripts created each topology map operates to parse these topology maps. [0185]
  • (4) Obtaining Internal Routing Tables: These tables can be obtained by strategic alliances with ISPs. It is also possible obtain these by dialing up to an ISP account and running the same routing protocols as the ISP network. This may convince the ISP routers that a dialog machine is also a router and the ISP routers may release internal routing tables. [0186]
  • (5) Obtaining BGP routing tables: Various sites on the web related to global routing release their copies of the global BGP routing table. [0187]
  • (6) Obtaining ISP topology maps: These can be obtained by alliances with an ISP. [0188]
  • The Unified Mapping Process (60)
  • The [0189] unified mapping process 61 operates to combine the results of a number of mapping methodologies that do not yielded exact results (e.g., combines the results of the inexact algorithms). In one embodiment, the unified mapping process 61 takes into account all information available from such methodologies, and a probability (or confidence factor) associated with each, and establishes a unique location. The associated probability that serves as a confidence factor for the unique location.
  • In one embodiment, the [0190] unified mapping process 61 is implemented as a Bayesian network that takes into account information regarding possible city and the state locations, results conflicts (e.g., there may be contradictory city/city indications or inconsistent cities/state combinations, and calculates) a final unique location and the associated probability.
  • A probability for each of a number of possible locations that are inputted to the [0191] unified mapping process 61 is calculated utilizing the Bayesian network, in one exemplary embodiment of the present invention. For example, if there is one possible location with a very high probability and a number of other possible locations with smaller probabilities, the location with the highest probability may be picked, and its associated probability returned. On the other hand, if they are multiple possible locations with comparable probabilities, these may be forwarded for manual resolution, one embodiment of the present invention.
  • At a high level, the [0192] unified mapping process 61 receives a target network address (e.g., an IP address), and then runs the number of non-exact mapping processes as sub-tasks. These non-exact mapping processes then provide input to the Bayesian network. If one of the non-exact algorithms fails, but a majority does not, the Bayesian network will attempt to resolve the network address anyway.
  • FIG. 11 is a block diagram illustrating a process flow for the [0193] unified mapping process 61, according to an exemplary embodiment of the present invention. The unified mapping process 61 is an expert system suite of algorithms used to geolocate a network address (e.g., IP address). The unified mapping process 61 combines a plethora of data from Internet registries (Domain Name Server, Network IP Space, Autonomous System Numbers), Internet network connections (inferred via traceroutes), and world geographical databases (place names, locations, populations). The unified mapping process 61 further constructs a list of possible physical locations for a given network address, and from this list, through fuzzy logic and statistical methodologies, returns a location with a set of associated probabilities that provide an indication regarding the accuracy of that location. In this way, the unified mapping process 61 can tie the network address to a specific geographic location (e.g. a city, country, zip/postal code, etc.) and provide an indication regarding the probability of the specific geographic location being correct.
  • As shown in FIG. 11, the illustrated exemplary embodiment of the [0194] unified mapping process 61 has several components. Utilizing the data that have been gathered by external processes (e.g., the data collection agents 18), a collection 120 of the location determination modules (LDMs) generate (1) location determinants (LDs) for a target address in question, and (2) and associated confidence factor (CF) or likelihood that the location determinant is correct (e.g., indicates a “true” geographic location). The location determinants generated by the collection 120 of location determination modules are then passed through a location filter 122, which, based on certain criteria, removes nonsensical location determinants. After the filtering process performed by the location filter 122, location determinants and their associated confidence factors are passed into the location synthesis process (LSP) 124, where the multitude of different (and similar) location determinants, weighted by their confidence factors, compete against and cooperate with each other, ultimately yielding a unique and most likely location determinate including a “best estimate” geographic location (the location). Based on the degree of similarity between the “best estimate” geographic location and its competing locations, different confidence factors are assigned for the geographic resolution levels, which are transformed by a confidence-accuracy translator (CAT) 126 into a probability of accuracy for the winning location.
  • Confidence factors are used throughout the processing by the [0195] collection 120 of location determination modules and are discussed in detail below. The confidence factors, in one embodiment present invention, come in four varieties (post-CM, post-LDM, post-LSP, and post-CAT), and their meanings are very different. The reader can use the context to determine which confidence factor is being referenced.
  • There are a number of data points that the [0196] unified mapping process 61 utilizes. The specifics of how these are used are discussed below. These are also discussed above with respect to the data collection agents 18.
  • A location determination module (LDM) is a module that generates a location determinant (LD) or set of location determinants that are associated with the given network (e.g., IP) address. The location determination modules utilize a variety of the available input data, and based on the data's completeness, integrity, unequivocalness and degree of assumption violation, assign a confidence factor for one or more geographic locations. The location determination modules may conceptually be thought of as experts in geolocation, each with a unique special skills set. The location determination modules further make decisions using “fuzzy logic”, and then present the output decisions (i.e., location determinants) and associated confidence factors (CFs) to the [0197] location filter 122 and location synthesis process 124, where the location determinants are evaluated (or “argued”) democratically against the location determinants presented by other location determination modules.
  • All location determination modules operate it may somewhat similar manner in that they each examine input data, and attempt to generate location determinants with an associated confidence factor based on the input data. However, each location determination module is different in what input data it uses and how the respective confidence factors are derived. For instance, a specific location determination module may extract location information from a hostname, while another analyzes the context of the traceroute; a further location determination module may analyze autonomous system information, while yet another makes use of a DNS Location record. By combining these distinct data inputs, each individually weighted by the parameters that most directly affect the likelihood of the relevant data being correct, the location synthesis process [0198] 124 is equipped with a set of data to make a decision.
  • The [0199] location filter 122 operates through the location determinants, received from the collection 120 of location determination modules, which are in conflict with certain criteria. In particular, if a hostname ends with ‘.jp’, for example, the location filter 122 removes all location determinants that are not in Japan. Similarly, if a hostname ends with ‘.ca.us’, the location filter 122 omits location determinants that are not in California, USA.
  • The location synthesis process [0200] 124, in one exemplary embodiment, is responsible for the unification and congregation of all location determinants that are generated by the collection 120 of location determination modules. The location synthesis process 124 searches for similarities among the location determinants and builds a confirmation table (or matrix that indicates correspondence (or agreement) between various location determinants. An intermediate result of this decision making process by the location synthesis process 124 is the location probability table (LPT), an example of which is discussed above. Since determinants may agree and disagree on multiple levels of geographic resolution (i.e. San Francisco, Calif. and Boulder, Colo. differ in city, state, and region, but are similar in country and continent), the location probability table develops different values at different levels of geographic resolution. A combined confidence factor, which is a linear combination of each of the constituent confidence factor fields, is computed and used to identify a most likely location (the winning location) and an associated probability of the winning location being correct.
  • The values contained in a location probability table, as returned from the location synthesis process [0201] 124, are translated by the confidence-accuracy translator (CAT) 126 into a final form. A small subset of the data is run against verification data to compute the relationship between post-LSP confidence factors and accuracy. Given this relationship, the location probability table is translated to reflect the actual probability that the given network address was correctly located, thus completing the process of geolocation.
  • A discussion will now be presented regarding location determination modules, and fuzzy confidence maps, according to an exemplary embodiment present invention. This discussion provides an understanding of the location determination modules (LDMs) and their dominant decision-facilitating mechanism, namely confidence maps (CMs). [0202]
  • A location determination module generates a location determinant (LD), or set of location determinants, and an associated confidence factor (CF), or set of confidence factors. These location determinants are provided, together with an associated confidence factor, to the [0203] location filter 122 and onto the location synthesis process 124, where based on the magnitude of their confidence factors and agreement with other location determinants, are considered in the decision making of the unified mapping process 61. Eight exemplary location determination modules are discussed below. These exemplary location determination modules (LDMs) are listed below in Table 1, together with the source of their resultant location determinant, and are shown to be included within the collection 120 of location determination modules shown in FIG. 11:
    TABLE 1
    List of exemplary LDMs
    LDM Name Source of LDM
    RegEx LDM
    130 String Pattern Matching in a
    Hostname.
    Net LDM 132 IP Registry
    DNS LDM
    134 Domain Name Server Registry
    ASN LDM
    136 Autonomous System Registry
    Loc LDM 138 DNS Loc Record
    LKH LDM 140 Last Known Host in a Traceroute
    NKH LDM 142 Next Known Host in a Traceroute
    Sandwich LDM
    144 Combination of LKH and NKH
    Suffix LDM
    146 Last One or Two Words of Hostname
  • Further details regarding each of the above listed location determination modules will be provided below, and an overview of two exemplary location determination modules will be discussed as an introduction. [0204]
  • The RegEx (Regular Expression) [0205] LDM 130, in an exemplary embodiment of the present invention, searches through a hostname and attempts to extract place names (cities, states, or countries) from within it. The host name may be obtained by performing a traceroute, or by issuing a NSLOOKUP or HOST command against a network address. Once the LDM 130 identifies one or more place names, associated confidence factor values (based for example on parameters like city population, number of letters in the string from which the name was extracted, distance to the last known host in a traceroute, etc.) are generated for each of the place names.
  • The [0206] Net LDM 132 returns a geographic location for the network address (e.g., an IP address) as it is registered with the appropriate authority (e.g., ARIN/RIPE/APNIC). The confidence factor assigned to the geographic location is based primarily on the size of the network block that is registered and within which the network address falls, under the assumption that a small network block (e.g., 256 or 512 hosts) can be located in common geographic location, whereas a large network block (e.g., 65,536) is less likely to all be located in a common geographic location.
  • There are a number of advantages to utilizing confidence factors throughout the inner workings of the [0207] unified mapping process 61. By “fuzzifying” the data (e.g., treating every possible geographic location as a viable answer with a confidence factor reflective of its dynamic accuracy), then processing the data, and then “defuzzifying” (e.g., collapsing onto one unique answer), the unified mapping process 61 is able to retain as much information as possible throughout the course of processing data.
  • The formal translation of input data/parameters into LDM confidence factors happens through relationships known as confidence maps (CMs). These relationships explicitly represent the correlation (or relationship) between input parameters and the likelihood (or probability) that an estimated geographic location for a network address is in fact correct. [0208]
  • FIGS. 12A and 12B illustrate a one-[0209] dimensional confidence map 150 and a two-dimensional confidence map 160 respectively, according to exemplary embodiments of the present invention. Turning first to the one-dimensional confidence map 150, consider the exemplary scenario in which the Net LDM 132 returns a certain city. The question arises as to how the Net LDM 132 can attach a level of certainty (or probability) that the city is a correct geolocation associated with a network address. As stated above, in general, smaller network blocks are more likely to yield a correct geographic location than large ones. Based on this premise, a relationship between (1) the number of nodes within a network block and (2) a confidence level that a particular network address is located in a city associated with that network block can be determined and expressed in a confidence map, such as the confidence map 150 shown in FIG. 12A.
  • Interpreting FIG. 12A, it can be seen that confidence level for the geographic location is very high if the network block size is small. However, as the size of the network block increases, the confidence level decreases. In an alternative embodiment of the present invention, as opposed using the “fuzzy logic” with confidence values, “crisp logic” may be utilized. The “crisp logic” implementation differs from the “fuzzy logic” implementation in that the “crisp logic” may implements a pass/fail test. For example, rather crisp logic may specify that networks smaller than size x are correctly located and larger than x are incorrectly located. On the other hand, the exemplary “fuzzy logic” implementation represented by the relationship shown in FIG. 12A present the continuum that represents a probabilistic relationship. [0210]
  • While one-dimensional confidence maps [0211] 150, such as that shown in FIG. 12A, are good indicators of a likelihood of correct location, there are many cases where a nonlinear interaction between two parameters makes a two-dimensional confidence map 160, such as that shown in FIG. 12B, more appropriate.
  • Consider the example where a [0212] RegEx LDM 130 extracts the strings ‘sf’ and ‘santaclara’ out of a hostname. From these, consider that the RegEx LDM 130 generates a number of possible geographic locations: San Francisco, Calif.; San Fernando, Calif.; Santa Fe, N.M.; South Fork, Colo.; and Santa Clara, Calif. With such ambiguity, the question arises as to how the unified mapping process 61 may output an estimated geographic location. Again, by constructing an appropriate confidence map 160, such as that shown in FIG. 12B, the unified mapping process 61 is enabled to separate geographic locations of a high probability from those of a low probability. Specifically, the confidence map 160 relates (1) city population (the y-axis) and (2) string length (the x-axis) to (3) a confidence factor (color).
  • Interpreting the two-[0213] dimensional confidence map 160 shown in FIG. 12B, it will be noted that this confidence map 160 attributes a higher confidence factor when the city is large and/or when the string from which unified mapping process 61 extracted the location is long. For example, as ‘sf’ is a short string and subsequently prone to ambiguity, it does not have the same level of confidence that a long string such as ‘santaclara’. However, if there is a large population associated with a specific geographic location, then the weighting of the string length is discounted. For example, the two-dimensional confidence map 160, when applied to the aforementioned examples, yields the following Table 2:
    TABLE 2
    Example table of results from confidence map
    Location String Length Population Confidence
    San Francisco, CA 2 700,000 35
    San Fernando, CA 2  20,000 10
    Santa Fe, NM 2  70,000 15
    South Fork, CO 2 ? (<5,000) 0
    Santa Clara, CA 10  90,000 40
  • Accordingly, through the use of a single confidence map such as that shown in FIG. 12B, a location determination module (e.g., the Net LDM [0214] 132) can separate reasonable location determinants from unreasonable ones. However, as such separation may depend on a large number of factors, and the unified mapping process 61 may utilize a large number of confidence maps.
  • In one embodiment, each location determination module uses a dedicated set of confidence maps, and combines the results of each confidence map (for each location) by a weighted arithmetic mean. For example, if cf[0215] i is the ith of n confidence factors generated by the ith CM, with associated weight wi, then the combined confidence factor (CCF) is computed according to the following equation: CCF = i = 1 n c f i w i i = 1 n w i
    Figure US20040078490A1-20040422-M00001
  • Every candidate geographic location must pass through each relevant confidence map and has multiple confidence factors associated therewith combined. Once a location determinant has a combined confidence factor, it no longer uses the multiple individual factors. Specifically, the location determinant and the associated combined confidence factor are communicated to the [0216] location filter 122 and subsequently the location synthesis process 124.
  • In the above examples, a confidence map may not assign a value higher than 50 for confidence factor. Since the combined confidence factor is an average of these, it is also less than 50. If a confidence factor is generated by the location synthesis process to have a value greater than 50, a confirming comparison may take place. [0217]
  • It should also be noted that a specific location determination module may utilize a mix of one-dimensional and two-dimensional confidence maps, each of which has advantages and disadvantages. A one-dimensional confidence maps may lack the ability to treat multidimensional nonlinear interaction, but only requires the one parameter to run. Conversely, a two-dimensional confidence map can consider higher dimensional interaction effects, but if one of the parameters is missing, the confidence map cannot be utilized to generate a confidence factor. [0218]
  • It should also be noted that the location determination modules are truly modular, and that none depend on any other, and they can easily be added, modified, or removed with respect to the [0219] unified mapping process 61.
  • In one exemplary embodiment, as illustrated in FIG. 2, confidence maps [0220] 33 are stored within the data collection database 26. The confidence maps 33 are represented either as a matrix, or as a function where an input parameter constitutes a continuum, as opposed to discrete values. To this end, FIG. 12C is an entity-relationship diagram illustrating further details regarding the storage of the confidence maps 33 within the data collection database 26. A reference table 35, which is accessed by an LDM, includes records that include pointers to a matrix table 37 and a function table 39. The matrix table 37 stores matrices for those confidence maps having input parameters that constitute discrete values. The function table 39 stores functions for those confidence maps for which an input parameter (or parameters) constitute a continuum.
  • RegEx (Regular Expression) LDM Location Generation
  • FIG. 13 is a flowchart illustrating a [0221] method 170, according to an exemplary embodiment of the present invention, performed by the RegEx LDM 130 to identify one or more geographic locations for a network address and to associated at least one confidence factor with each of the geographic locations. The RegEx LDM 130 performs a location determination based on searching for string patterns within the host name. Accordingly, the method 170 commences at block 172 with the receipt of input data (e.g., a traceroute or other data collected by the data collection agents 18). At decision block 174, a determination is made as to whether one or more hostnames are included within the input data. If there is no hostname included within the input data (e.g., a traceroute) provided to the unified mapping process 61, the RegEx LDM 130 exits at block 176.
  • On the other hand, if a hostname is included within input data, then the [0222] RegEx LDM 130 at block 178 parses the hostname by delimiter characters (e.g., hyphens, underscores, periods, and numeric characters) to identify words that are potentially indicative of a geographic location.
  • At [0223] block 180, the RegEx LDM 130 runs comparisons on these newly identified words individually, and in conjunction with neighbor words, to check for similarity to patterns that correspond to geographic locations (e.g., place names). In one embodiment, the RegEx LDM 130 accesses the demographic /geographic database 31 contained within the data warehouse 30 to obtain patterns to use in this comparison operation. In one embodiment, the LDM 130 checks individual words, and iteratively “chops” or removes letters from the beginning and end of the word in the event that extraneous characters are hiding valuable information. Strings that are more likely associated with networking and hardware than place names (such as ‘ppp’, ‘dsl’, ‘isdn’, ‘pop’, ‘host’, ‘tel’, etc.) are not included in any pattern matching routines.
  • Examples of valid patterns, as stored within the demographic/[0224] geographic database 31, that may be sought include various combinations of:
  • 1. Full city name; [0225]
  • 2. Full state name; [0226]
  • 3. Full country name; [0227]
  • 4. Two character abbreviation of city name (if and only if city has a two part name); [0228]
  • 5. Two character abbreviation of state name; [0229]
  • 6. Two character abbreviation of country name; [0230]
  • 7. Three character abbreviation of city name (if city has a three part name); [0231]
  • 8. First three characters of city name, including vowels; [0232]
  • 9. First three characters of city name, excluding vowels; [0233]
  • 10. First four characters of city name, including vowels; [0234]
  • 11. First four characters of city name, excluding vowels; [0235]
  • 12. Airport codes; [0236]
  • 13. Common abbreviations for city names; and [0237]
  • 14. Alternate spellings for city names.[0238]
  • The [0239] RegEx LDM 130 is capable of extracting fairly obfuscated geographic information from hostnames. One of the shortcomings, however, of the history of place naming is ambiguity. The RegEx LDM 130, at block 180, therefore accordingly generally identifies not one but many geographic locations, and generates multiple location determinants.
  • The following table presents examples of the location determinants that the [0240] RegEx LDM 130 may generate from the exemplary host names:
    TABLE 3
    Example RegEx LDM location determinant construction
    Actual Hostnames Location Determinants Rules/Reasons/Patterns
    dyn1-tnt4-1.chicago. Duyan, China Three character, no
    il.ameritech.net Dayuan China vowel
    Deyang China Full city name
    Taunton, Massachusetts, Full state name
    USA Two character city
    Tonto Basin, Arizona, USA name
    Tanta, Egypt Two character country
    Taunton, Minnesota, USA code
    Tuntutuliak, Alaska, USA
    Tintah, Minnesota, USA
    Tontitown, Arkansas, USA
    Tontogany, Ohio, USA
    Chicago, Illinois, USA
    Illinois, USA
    Island Lake, Illinois, USA
    Indian Lake, New York,
    USA Israel
    p3-max50.syd. Sydney, Florida, USA Three character
    ihug.com.au Sydney, Australia
    c2501.suttonsbay. Sutton's Bay, Michigan, Full city name
    k12.mi.us USA (multiple words)
    pool-207-205-179- Phoenix, Maryland, USA Four character, no
    101.phnx.grid.net Phoenix, New York, USA vowel
    Phoenix, Oregon, USA
    Phoenixville,
    Pennsylvania, USA
    Phoenix, Arizona, USA
    Phoenix, Virginia, USA
    resaleseattle1- Seattle, Washington, USA Full city name
    1r7169.saturn.bbn.
    com
    usera723.uk. United Kingdom Two character country
    uudial.com code
  • Through the usage of common abbreviations and alternate spellings, the [0241] RegEx LDM 130, for example, also knows to put ‘lsanca’ in Los Angeles, Calif., and ‘cologne’ in Köln, Germany.
  • Because of the large number of location determinants that the [0242] RegEx LDM 130 can potentially generate, in one embodiment rules may restrict location determinant generation of trivially small (e.g., low population or low connectivity index) cities from fewer than 4 characters.
  • The [0243] RegEx LDM 130 is particularly suited to identify geographic locations associated with the Internet backbone/core routers. It is not uncommon for a company to make use of the hostname as a vehicle for communicating location. By using typical abbreviations and a geographical database of many tens of thousands of place names, the RegEx LDM 130 is suited to locating these hosts.
  • The [0244] RegEx LDM 130 has the ability to produce a multitude of location determinants for a particular network address. Because the RegEx LDM 130 is suited to identify geographic locations along the Internet backbone it may not, in one embodiment, be heavily deployed in the geolocation of end node targets. Instead, the immediate (router) locations delivered by the LDM 130 may be stored and used by other LDMs of the collection 120, which make use of these results as Last Known Hosts (LKHs) and Next Known Hosts (NKHs).
  • Returning to the [0245] method 170 illustrated in FIG. 13, at block 180, multiple confidence maps are utilized to attach confidence factors to the geographic locations identified and associated with a network address at block 180. Further information regarding exemplary confidence maps that may be used during this operation is provided below.
  • At [0246] block 184, the RegEx LDM 130 outputs the multiple geographic location determinants, and the associated confidence factors, as a set to the location filter 122, for further processing. The method 170 then exits at block 176.
  • Because of a degree of ambiguity and numerous location determinants that may be returned by the [0247] RegEx LDM 130, the LDM 130 employs a relatively large number of confidence maps when compared to other LDMs of the collection 120. The confidence maps employed by the LDM 130, in one exemplary embodiment, relate parameters such as word position, word length, city population, city connectivity, distance of city to neighboring hosts in the traceroute, etc.
  • An exemplary collection of confidence maps that may be utilized by the [0248] RegEx LDM 130 to attach confidence factors to location determinants is discussed below with reference to FIGS. 14A-14Q. It will be noted that each of the confidence maps discussed below includes a “confidence map weight”, which is a weighting assigned by the RegEx LDM 130 to a confidence factor generated by a respective confidence map. Different confidence maps are assigned different weightings based on, inter alia, the certainty attached to the confidence factor generated thereby. The number of terms or parameters of the confidence maps described below require clarification. The term “hop ratio” is an indication of a hop position within a traceroute relative to an end host (e.g., how far back from the end hosts a given hop is). The term “connectivity index” is a demographic representation of the magnitude or amount of network access to which a location has access within a network. The term “minimum connectivity” is a representation of a lowest common denominator of connectivity between to network entities (e.g., a Last Known Host and an end host). Distances between geographic locations are calculated once a geographic location has been determined. The latitude and longitude co-ordinates of a geographic location may, in one exemplary embodiment, be utilized to performed distance calculations.
  • Hop Ratio—Connectivity Confidence Map (190)
  • X-axis: Hop Ratio (as determined from traceroute) [0249]
  • Y-axis: Connectivity Index [0250]
  • Color: confidence factor [0251]
  • Confidence map weight: 40 [0252]
  • Comments: An exemplary embodiment of the [0253] confidence map 190 is illustrated in FIG. 14A. This confidence map 190 is most assertive in the middle of a traceroute where it provides well-connected location determinants high confidence factors and less connected location determinants low confidence factors. At the beginning and the end of the traceroute, it has the opposite effect; well connected location determinants receive lower confidence factors and less connected get higher.
  • Word Length Confidence Map (190)
  • X-axis: Length of String [0254]
  • Y-axis: confidence factor [0255]
  • Confidence map weight: 100 [0256]
  • Comments: An exemplary embodiment of the [0257] confidence map 192 is illustrated in FIG. 14B. In place name string matching, a longer string provides a high degree of certainty than a shorter string, and decreases ambiguity. This confidence map 192 attributes higher confidence factors for longer strings and confidence factors of zero for two character strings.
  • Word Length—Number of Entries Confidence Map (194)
  • X-axis: Length of String [0258]
  • Y-axis: Number of location determinants generated by the String [0259]
  • Color: confidence factor [0260]
  • Confidence map weight: 100 [0261]
  • Comments: An exemplary embodiment of the [0262] confidence map 194 is illustrated in FIG. 14C. The confidence map 194 couples the word length (an indirect measure of ambiguity) with the number of location determinants returned by the RegEx LDM 130 (a direct measure of ambiguity). Strings that are too short and yield too many location determinants are attributed a lower confidence factors than unique ones. It will be noted that the confidence map 194 is attributed a relatively higher weighting in view of the high degree of certainty delivered by this confidence map 194.
  • Word Length—Population Confidence Map (196)
  • X-axis: Length of String [0263]
  • Y-axis: Population [0264]
  • Color: confidence factor [0265]
  • Confidence map weight: 100 [0266]
  • Comments: An exemplary embodiment of the [0267] confidence map 196 is illustrated in FIG. 14D. As stated in the above, short words are attributed relatively low confidence factors. Nonetheless, it is desirable to attributed a relatively higher confidence factor to geographic locations that are heavily populated, in spite of such geographic locations being indicated by a short word. For example, so that ‘sea’ and ‘sf’ (indicating Seattle and San Francisco, respectively) are attributed higher confidence factors, this confidence map 196 allows well-populated cities to be abbreviated shortly.
  • Word Length—Connectivity Confidence Map (198)
  • X-axis: Length of String [0268]
  • Y-axis: Connectivity Index [0269]
  • Color: confidence factor [0270]
  • Confidence map weight: 100 [0271]
  • Comments: An exemplary embodiment of the [0272] confidence map 198 is illustrated in FIG. 14E. For the same reasons discussed above with reference to the confidence map 196 illustrated in FIG. 14D, well connected cities are more likely to be correct than less connected cities. The confidence map 198 seeks to ensure that even short abbreviations are likely to be mapped correctly by attributing a higher confidence factor too short words (e.g., abbreviations) that exhibit a high degree of connectivity.
  • Distance to LKH—Hop Ratio of LKH Confidence Map (200)
  • X-axis: Distance in Miles to Last Known Host. This is determined from the demographic/[0273] geographic database 31 that stores intra-location distance values.
  • Y-axis: Hop Ratio of Last Known Host [0274]
  • Color: confidence factor [0275]
  • Confidence map weight: 50 [0276]
  • Comments: An exemplary embodiment of the [0277] confidence map 200 is illustrated in FIG. 14F. Two hosts adjacent in a traceroute are expected to be physically near each other, unless they are traversed in the middle of the traceroute. This confidence map 200 is reflective of this expectation. Hosts that are distant and at the end of a traceroute are attributed lower confidence factors.
  • Distance to LKH—Node Distance to LKH Confidence Map (202)
  • X-axis: Distance in Miles to Last Known Host (LKH) [0278]
  • Y-axis: Number of Hops Between this Host and LKH. [0279]
  • Color: confidence factor [0280]
  • Confidence map weight: 100 [0281]
  • Comments: An exemplary embodiment of the [0282] confidence map 202 is illustrated in FIG. 14G. Under the premise that a host should be located near the last known host in a traceroute, the confidence map 202 gives lower confidence factors when the LKH is close in the traceroute but far in physical space. The confidence map 202 is more forgiving of hosts slightly further in the traceroute.
  • Distance to LKH—LKH Population Confidence Map (204)
  • X-axis: Distance in Miles to Last Known Host [0283]
  • Y-axis: Minimum Population of this Host and LKH. This information is again retrieved from the demographic/[0284] geographic database 31.
  • Color: confidence factor [0285]
  • Confidence map weight: 70 [0286]
  • Comments: An exemplary embodiment of the [0287] confidence map 204 is illustrated in FIG. 14H. It is generally found that hops in a traceroute jump great distances only when they travel from one major backbone city to another. A common characteristic of these cities is their large populations. So, in the confidence map 204, larger, closer location determinants are rewarded, while distant, small ones are punished.
  • Distance to LKH—LKH Connectivity Confidence Map (206)
  • X-axis: Distance in Miles to Last Known Host [0288]
  • Y-axis: Minimum Connectivity of this Host and LKH [0289]
  • Color: confidence factor [0290]
  • Confidence map weight: 85 [0291]
  • Comments: An exemplary embodiment of the [0292] confidence map 206 is illustrated in FIG. 141. Similar to the preceding confidence map 204 based on population, this confidence map 206 rewards cities that are generally well-connected. For example, cities like New York and London can be connected to very distant cities.
  • Distance to NKH—Hop Ratio of NKH Confidence Map (208)
  • X-axis: Distance in Miles to Last Known Host [0293]
  • Y-axis: Hop Ratio of Next Known Host [0294]
  • Color: confidence factor [0295]
  • Confidence map weight: 50 [0296]
  • Comments: An exemplary embodiment of the [0297] confidence map 208 is illustrated in FIG. 14J. Two hosts adjacent in a traceroute are expected to be physically near each other, unless they are traversed in the middle of the traceroute. The confidence map 208 is reflective of this expectation. Hosts that are distant and at the end of a traceroute receive lower confidence factors.
  • Distance to NKH—Node Distance to NKH Confidence Map (210)
  • X-axis: Distance in Miles to Next Known Host [0298]
  • Y-axis: Number of Hops Between this Host and NKH [0299]
  • Color: confidence factor [0300]
  • Confidence map weight: 100 [0301]
  • Comments: An exemplary embodiment of the [0302] confidence map 210 is illustrated in FIG. 14K. Under the premise that a host should be located near the last known host in a traceroute, the confidence map 210 attributes lower confidence factors when the NKH is close in the traceroute, but far in physical space. The confidence map 210 is more forgiving of hosts slightly further in the traceroute.
  • Distance to NKH—NKH Population Confidence Map (212)
  • X-axis: Distance in Miles to Next Known Host [0303]
  • Y-axis: Minimum Population of this Host and NKH [0304]
  • Color: confidence factor [0305]
  • Confidence map weight: 70 [0306]
  • Comments: An exemplary embodiment of the [0307] confidence map 212 is illustrated in FIG. 14L. Hops in a traceroute tend to jump great distances only when they travel from one major backbone city to another. A common characteristic of these backbone cities is their large populations. Accordingly, the confidence map 212 generates a confidence factor such that larger, closer location determinants are rewarded, while distant, small location determinants are punished.
  • Distance to NKH—NKH Connectivity Confidence Map (214)
  • X-axis: Distance in Miles to Next Known Host [0308]
  • Y-axis: Minimum Connectivity of this Host and NKH [0309]
  • Color: confidence factor [0310]
  • Confidence map weight: 85 [0311]
  • Comments: An exemplary embodiment of the [0312] confidence map 214 is illustrated in FIG. 14M. The confidence map 214 rewards cities that are generally well-connected. For example, cities like New York and London can be connected to very distant cities.
  • Population Confidence Map (216)
  • X-axis: Population [0313]
  • Y-axis: confidence factor [0314]
  • Confidence map weight: 40 [0315]
  • Comments: An exemplary embodiment of the [0316] confidence map 216 is illustrated in FIG. 14N. Generally speaking, the population of a geographic location is an effective measure of likelihood. Intuitively, the Moscow of the Russian Federation is more likely than the Moscow of Iowa. Especially in the USA, population may be a powerful indicator of the likelihood of location determinant correctness.
  • Neighboring Connectivity Confidence Map (218)
  • X-axis: Mean of LKH and NKH Connectivity Indices [0317]
  • Y-axis: Connectivity Index [0318]
  • Color: confidence factor [0319]
  • Confidence map weight: 90 [0320]
  • Comments: An exemplary embodiment of the [0321] confidence map 218 is illustrated in FIG. 14O. A base premise of the confidence map 218 is that connectivity indices along a traceroute ought to be continuous. That is: host locales go from low connectivity to medium, to high. Any host's connectivity index along a traceroute ought theoretically not to deviate from the mean of its neighbors. This map penalizes such a deviation.
  • Connectivity Confidence Map (220)
  • X-axis: Connectivity Index [0322]
  • Y-axis: confidence factor [0323]
  • Confidence map weight: 50 [0324]
  • Comments: An exemplary embodiment of the [0325] confidence map 220 is illustrated in FIG. 14P. The connectivity index is utilized by the confidence map 220 to provide a direct measure of the probability that a host is in the particular geographic location. According to the confidence map 220, the better connected a geographic location (e.g., city) is, the more likely the host is to be at a geographic location.
  • Word Position Confidence Map (222)
  • X-axis: Position of 1[0326] st Character of Word in Hostname
  • Y-axis: confidence factor [0327]
  • Confidence map weight: 20 [0328]
  • Comments: An exemplary embodiment of the [0329] confidence map 222 is illustrated in FIG. 14Q. It will be noted that the confidence map 222 is assigned a relatively low confidence map weight, which is indicative of a relatively low effectiveness of the confidence map 222. It has been found that information in a hostname is more likely to be found at the extreme ends than in the middle. Also if two city names appear together in a hostname, the names toward the ends of the word tend to have more relevance.
  • Network (Net) LDM Location—Generation
  • FIG. 15 is a flowchart illustrating a [0330] method 240, according to an exemplary embodiment of the present invention, performed by the Net LDM 132 to identify one or more geographic locations for a network address (or block of network addresses) and associate at least one confidence factor with each of the geographic locations.
  • At [0331] block 242, the Net LDM 132 initiates external data collection routines (e.g., data collection agents 18) to query multiple Internet Protocol (IP) registering authorities (e.g., RIPE/APNIC/ARIN) to a smallest possible network size
  • At [0332] block 244, geographical information (e.g., city, state, country, the zip/postal code, area code, telephone prefix) is parsed from the query results and extracted and stored along with the network address range at block 246.
  • At [0333] block 248, the Net LDM 132 utilizes multiple confidence maps to attach confidence factors to each of the geographic locations identified at block 244, or to each of the geographic information items identified at block 244.
  • At [0334] block 250, the Net LDM 132 outputs the multiple geographic locations (or geographic information items) and the associated confidence factors to the location filter 122. The method 240 then terminates at block 252.
  • Because the [0335] Net LDM 132 may be of limited effectiveness along the core routers, the use of the Net LDM 132 may,. in one exemplary embodiment, be restricted to the last three hops of a traceroute. The Net LDM 132 may optionally also not be utilized if a network block size registered is larger than 65,536 hosts, for it is unlikely that so many machines would be located in the same place by the same organization.
  • The [0336] Net LDM 132 is a particularly effective at generating accurate confidence factors for geographic locations when the network blocks registered with the IP registering authority are relatively small (e.g., less than 1024 hosts). If the Net LDM 132 incorrectly attached is a high confidence level to a geographic location, it is most likely related to a large network block or an obsolete record in a registry.
  • The confidence factors generated by the [0337] Net LDM 132 come from distance to a Last Known Host (LKH) and a Next Known Host (NKH) (e.g., calculated utilized in the latitude and longitude co-ordinates of these hosts) the size of the network block, a position in a traceroute (e.g., relative location near the end of the traceroute), population and connectivity. Regarding position within a traceroute, it will be appreciated that a relative position within the traceroute will be dependent upon the number of hops, and the relevant hop's position within that number of hops. For example, if they are 7 hops within a given traceroute, then hop 6 is considered to be near the end host. However, if there are 20 hops within the traceroute, hop 6 to be considered to be very distant from the end host.
  • An exemplary collection of confidence maps that may be utilized by the [0338] Net LDM 132 to attach confidence factors to location determinants are discussed below with reference to FIGS. 16A-16E. It will be noted from the following discussion of the confidence maps utilized by the Net LDM 132 that, while distance and hop ratio are used in similar ways as in the RegEx LDM 130, population and connectivity are used in contrary ways. Again, different confidence maps are assigned different weightings based on, inter alia, the certainty attached to the confidence factors generated thereby.
  • LKH Distance—Hop Ratio Confidence Map (260)
  • X-axis: Distance in Miles Between LKH and Net [0339]
  • Y-axis: Hop Ratio [0340]
  • Color: confidence factor [0341]
  • Confidence map weight: 50 [0342]
  • Comments: An exemplary embodiment of the [0343] confidence map 260 is illustrated in FIG. 16A. The confidence map 260 generates a relatively high confidence factor only at the ends of a traceroute and only when a geographic location (e.g., a city) corresponding to the network addresses within close proximity to the LKH.
  • Net Size Confidence Map (262)
  • X-axis: Number of Nodes in Registered Block [0344]
  • Y-axis: confidence factor [0345]
  • Confidence map weight: 100 [0346]
  • Comments: An exemplary embodiment of the [0347] confidence map 262 is illustrated in FIG. 16B. The confidence map 262 works off of two premises. First, if an entity has gone through the trouble to register a small block of network space, it is probably accurate. Conversely, large networks that are registered to one organization probably have the hosts spread out across a large area. Thus, the confidence map 262 operates such that small network sizes yield large confidence factors.
  • NKH Distance—Hop Ratio Confidence Map (264)
  • X-axis: Distance in Miles Between LKH and Net [0348]
  • Y-axis: Hop Ratio [0349]
  • Color: confidence factor [0350]
  • Confidence map weight: 50 [0351]
  • Comments: An exemplary embodiment of the [0352] confidence map 264 is illustrated in FIG. 16C. The confidence map 264 generates a relatively high confidence factor for a geographic location only at the ends of a traceroute and only when a geographic location (e.g., a city) corresponding to network addresses within close proximity to the NKH.
  • Connectivity Confidence Map (266)
  • X-axis: Connectivity Index [0353]
  • Y-axis: confidence factor [0354]
  • Confidence map weight: 25 [0355]
  • Comments: An exemplary embodiment of the [0356] confidence map 266 is shown in FIG. 16D. Contrary to the relationship in the RegEx LDM 130, here less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that if a network is registered in a small town, hosts on that network are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • Population Confidence Map (268)
  • X-axis: Population [0357]
  • Y-axis: confidence factor [0358]
  • Confidence map weight: 25 [0359]
  • Comments: An exemplary embodiment of the [0360] confidence map 268 is illustrated in FIG. 16E. Contrary to the relationship in the RegEx LDM 130, here smaller geographic locations are rewarded with higher confidence factors. The premise is that if a network is registered, for example, in a small town, hosts on that network are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • Domain Name Server (DNS) LDM Location Generation
  • FIG. 17 is a flowchart illustrating a [0361] method 270, according to an exemplary embodiment of the present invention, performed by the DNS LDM 134 to identify one or more geographic locations for a network address (or block of network addresses) and to associate at least one confidence factor with each of the geographic locations.
  • At [0362] block 272, the DNS LDM 134 initiates external data collection routines (e.g., data collection agents 18) to query multiple Domain Name Server (DNS) registering authorities to collect DNS records. These records correspond to ownership of a particular domain name (e.g., www.harvard.com or www.amazon.com)
  • At [0363] block 274, geographical information (e.g., city, state, country, the zip/postal code, area code, telephone prefix) is parsed from the DNS records and extracted and stored along with the domain name at block 276.
  • At [0364] block 278, the DNS LDM 134 utilizes multiple confidence maps to attach confidence factors to each of the geographic locations identified at block 274.
  • At [0365] block 280, the DNS LDM 134 outputs the multiple geographic locations (or geographic information items) and the associated confidence factors to the location filter 122. The method 270 then terminates at block 282.
  • Similar to the [0366] Net LDM 132, the DNS LDM 134 may not be most effective along the backbone core routers. For example, it is not helpful to know that att.net is in Fairfax or that exodus.net is in Santa Clara. To avoid potential problems related to this issue, the DNS LDM 134 may be deployed only on the last three hops of a traceroute, in one exemplary embodiment of the present invention.
  • If a DNS record, retrieved at [0367] block 272 indicates the same geographic location as a network record, retrieved at block 242, then it may be assumed, in one exemplary embodiment, that this geographic location is a corporate office and that the actual hosts may or may not be at that location. To prevent the location synthesis process 124 from being overwhelmed by redundant data that might not be useful, the DNS LDM 134 is prevented from duplicating the Net LDM 132, because, in an exemplary embodiment, the LDM 134 is less skillful than the LDM 132.
  • Similar to the [0368] Net LDM 132, the DNS LDM 134 may be strongest at the end of a traceroute, but not along the backbone core routers. Accordingly, the DNS LDM 134 may work well to geolocate companies that have a domain name registered and do their own hosting locally. Small dial-up ISPs are also locatable in this way as well.
  • An exemplary collection of confidence maps that may be utilized by the [0369] DNS LDM 134 to attach confidence factors to location determinants, at block 278, are discussed below with reference to FIGS. 18A-18E. The DNS LDM 134 relies on similar parameters as the Net LDM 132 for determining its confidence factors. Major differences include using distance to a network location, the rather than a network block size. It will also be noted that, in the exemplary embodiment, DNS confidence factors yielded by the confidence maps discussed below are significantly lower than in other LDMs.
  • LKH Distance—Hop Ratio Confidence Map (290)
  • X-axis: Distance in Miles Between LKH and DNS [0370]
  • Y-axis: Hop Ratio color: confidence factor [0371]
  • Confidence map weight: 50 [0372]
  • Comments: An exemplary embodiment of the [0373] confidence map 290 is illustrated in FIG. 18A. This confidence map 290 generates a relatively high confidence factor only at the ends of a traceroute and only when the geographic location (e.g., a city) corresponding to the DNS record is within close proximity to the LKH.
  • Distance to Net Confidence Map (292)
  • X-axis: Distance in Miles Between Net and DNS [0374]
  • Y-axis confidence factor [0375]
  • Confidence map weight: 80 [0376]
  • Comments: An exemplary embodiment of the [0377] confidence map 292 is illustrated in FIG. 18B. This confidence map 292 works under the assumption that if the Net and DNS records are identical, then they probably point to a corporate headquarters. If the distance between the two is zero, then the confidence factor is zero. If, however, the distance is not zero but is very small, then there is a greater chance that either one could be correct, or a larger confidence factor is given.
  • NKH Distance—Hop Ratio Confidence Map (294)
  • X-axis: Distance in Miles Between NKH and DNS [0378]
  • Y-axis: Hop Ratio color: confidence factor [0379]
  • Confidence map weight: 50 [0380]
  • Comments: An exemplary embodiment of this [0381] confidence map 294 is illustrated in FIG. 18C. This confidence map 294 gives high confidence only at the ends of a traceroute and only when the geographic location (e.g., the city) corresponding to the DNS record is within close proximity to the NKH.
  • Connectivity Confidence Map (296)
  • X-axis: Connectivity Index [0382]
  • Y-axis: confidence factor [0383]
  • Confidence map weight: 25 [0384]
  • Comments: An exemplary embodiment of this [0385] confidence map 296 is illustrated in FIG. 18D. Contrary to the relationship in the RegEx LDM 130, the DNS LDM 134 operates such that less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that, for example, if a domain name is registered in a small town, hosts associated with it are more likely to be in that small town. Larger cities may just be corporate headquarters or collocations.
  • Population Confidence Map (298)
  • X-axis: Population [0386]
  • Y-axis: confidence factor [0387]
  • Confidence map weight: 25 [0388]
  • Comments: An exemplary embodiment of the [0389] confidence map 298 is illustrated in FIG. 18E. Contrary to the relationship in the RegEx LDM 130, here smaller geographic locations (e.g., small towns) are rewarded with higher confidence factors. The premise is that, for example, if a domain name is registered in a small town, hosts associated with it are more likely to be in that small town. Larger cities may just be corporate headquarters.
  • ASN LDM Location Generation
  • The method by which the Autonomous System Network (ASN) [0390] LDM 136 operates to identify one more geographic locations for network addresses, and to assign at least one confidence factor to each of the geographic locations, is similar to the methods 240 and 270 of other two internet registry LDMs (i.e., the Net LDM 132 and the DNS LDM 134). Specifically, as opposed to the deploying external data collection routines to gather Net and DNS records, the ASN LDM 136 deploys the external data collection routines to gather the Autonomous System data, and parse it for meaningful geographic data. If ASN data is available, then the ASN LDM 136 can run.
  • The [0391] ASN LDM 136 is, in one embodiment, not used if the network block size registered by a blocking algorithm is larger than 65,536 hosts, as it is unlikely that so many machines would be located at a common location under the same Autonomous System (AS).
  • As with the [0392] DNS LDM 134, the ASN LDM 136 does not run if its ASN record matches that of the Net LDM. Again, this is to avoid erroneous duplication.
  • The [0393] ASN LDM 136 is reliable because the ASN data is utilized in real network communication, and is accordingly generally current, correct, and of a reasonable high resolution.
  • An exemplary collection of confidence maps that may be utilized by the [0394] ASN LDM 136 to attach confidence factors to location determinants are discussed below with reference to FIGS. 19A-19E. The confidence factors generated by the ASN LDM 136 come from distance to LKH and NKH, the size of the network, the position in the traceroute, population and connectivity. It will be noted that the following confidence maps, while utilizing distance and hop ratio in similar ways as in the RegEx LDM 130, population and connectivity are used in contrary ways.
  • LKH Distance—Hop Ratio Confidence Map (300)
  • X-axis: Distance in Miles Between LKH and ASN [0395]
  • Y-axis: Hop Ratio color: confidence factor [0396]
  • Confidence map weight: 50 [0397]
  • Comments: An exemplary embodiment of the [0398] confidence map 300 is illustrated in FIG. 19A. This confidence map 300 gives high confidence only at the ends of a traceroute and only when the geographic location (e.g., a city) corresponding to the ASN record is within close proximity to the LKH.
  • Net Size Confidence Map (302)
  • X-axis: Number of Nodes in AS Block [0399]
  • Y-axis: confidence factor [0400]
  • Confidence map weight: 100 [0401]
  • Comments: An exemplary embodiment of the [0402] confidence map 302 is illustrated in FIG. 19B. This confidence map 302 operates off of two premises. First, if an entity has gone through the trouble to register a small block of network space, it is probably accurate. Conversely, large networks that are registered to one organization probably have the hosts spread out across a large area. Thus, small net sizes yield large confidence factors.
  • NKH Distance—Hop Ratio Confidence Map (304)
  • X-axis: Distance in Miles Between LKH and ASN [0403]
  • Y-axis: Hop Ratio [0404]
  • Color: confidence factor [0405]
  • Confidence map weight: 50 [0406]
  • Comments: An exemplary embodiment of the confidence map [0407] 304 is illustrated in FIG. 19C. This confidence map 304 generates relatively high confidence factors only at the ends of a traceroute and only when the geographic location (e.g., city) corresponding to the ASN record is within close proximity to the NKH.
  • Connectivity Confidence Map (306)
  • X-axis: Connectivity Index [0408]
  • Y-axis: confidence factor [0409]
  • Confidence map weight: 25 [0410]
  • Comments: An exemplary embodiment of the [0411] confidence map 306 is illustrated in FIG. 19D. Contrary to the relationship in the RegEx LDM 130, here less-connected geographic locations (e.g., cities) are rewarded with higher confidence factors. The premise is that if a network is registered in a relatively smaller geographic location (e.g., small town), hosts on that network are most likely in that smaller geographic location. Larger cities may be corporate headquarters.
  • Population Confidence Maps (308)
  • X-axis: Population [0412]
  • Y-axis: confidence factor [0413]
  • Confidence map weight: 25 [0414]
  • Comments: An exemplary embodiment of the [0415] confidence map 308 is illustrated in FIG. 19E. Contrary to the relationship in the RegEx LDM 130, here smaller geographic locations (e.g., smaller cities) are rewarded with higher confidence factors. The premise is that if a network is registered in, for example, a small town, hosts on that network are most likely to be located in that small town. Larger cities may be corporate headquarters.
  • Location (Loc) LDM Location Generation
  • The method by which the Loc LDM [0416] 138 operates to identify one more geographic locations for network address, and to associate least one confidence level with each of the geographic locations, is again similar to the methods 240 and 270 of the Net and DNS LDMs 132 and 134 in that external collection processes gather Location (Loc) records from appropriate registries, which are parsed to extract location determinants. The Loc LDM 138 differs from the above described LDMs in that a collection of confidence maps is not utilized to attach confidence factors to each of these location determinants, as will be described in further detailed below.
  • The Loc LDM [0417] 138, in one exemplary embodiment, differs from the previously described LDMs in that it exhibits a high degree of accuracy and precision. Specifically, a DNS Loc record, as collected by external processes, may provide an indication of a hosts' latitude and longitude data, which may be utilized to tie a location determinant to a city (or even smaller).
  • DNS Loc records are rarely available. Fewer than 1% of all hosts actually have a Loc record available. [0418]
  • The Loc LDM [0419] 138 is one of only two LDMs that do not make use of confidence maps. The rationale behind this is that there are no circumstances that would change the belief in the highly accurate DNS Loc record, used by the Loc LDM 138. So as opposed to utilizing a number of confidence maps, if the Loc record is available, the Loc LDM 138 communicates a location determinant derived from the Loc record to the location filter 22, accompanied by a precise confidence factor, for example, 85.
  • LKH LDM Location Generation
  • The LKH LDM [0420] 140 makes use of traceroute contextual data, and asserts that the host in question is in precisely the same location as the one previously identified in the traceroute. Specifically, it is generally found that at the end of a traceroute, the physical distance from the one hop to the next is on the order of miles, not hundreds of miles. It is also not uncommon for a traceroute to spend several hops in the same area (i.e. network center).
  • Take, for instance, a partial traceroute to www.quova.com:[0421]
  • 1 <10 ms <10 ms <10 ms 10.0.0.1 [0422]
  • 2. 30 [0423] ms 20 ms 21 ms loop1.dnvr-6400-gw1.dnvr.uswest.net [63.225.108.254]
  • 3. 270 [0424] ms 20 ms 30 ms 103.port1.dnvr-agw2dnvr.uswest.net [207.225.101.126]
  • 4. 20 [0425] ms 20 ms 20 ms gig3-0.dnvr-gw2dnvr.uswest.net [206.196.128.219]
  • 5. 20 [0426] ms 20 ms 20 ms h4-0.denver-cr2.bbnplanet.net [4.0.212.245]
  • 6. 50 [0427] ms 20 ms 20 ms p4-0-0.denver-br2.bbnplanet.net [4.0.52.21]
  • 7. 30 [0428] ms 30 ms 20 ms p0-0-0.denver-br1.bbnplanet.net [4.0.52.17]
  • 8. 50 [0429] ms 60 ms 50 ms p2-3.lsanca1-ba2.bbnplanet.net [4.24.6.1]
  • 9. 50 [0430] ms 60 ms 50 ms p7-0.lsanca1-br2.bbnplanet.net [4.24.4.38]
  • 10. 50 ms 51 [0431] ms 60 ms p2-0.lsanca1-br1.bbnplanet.net [4.24.4.13]
  • 11. 70 [0432] ms 70 ms 60 ms p7-3.paloalto-nbr2.bbnplanet.net [4.24.5.210]
  • 12. 70 [0433] ms 60 ms 70 ms p1-0.paloalto-cr2.bbnplanet.net [4.0.6.78]
  • 13. 2624 ms 2654 ms * pos2-1.corel.Sanjose1.Level3.net [209.0.227.1][0434]
  • 14. 230 [0435] ms 220 ms 221 ms so-4-0-0.mp2.Sanjose1.level3.net [209.247.11.9]
  • 15. 120 [0436] ms 130 ms 121 ms loopback0.hsipaccess1.Washington1.Level3.net [209.244.2.146]
  • 16. 280 ms 131 [0437] ms 130 ms 209.244.200.50
  • It will be noted that three consecutive hops (1-3) are all in Denver under uswset.net, and the three following that are also in Denver under bbnplanet.net. In three following hops are all in Los Angeles. While the above exemplary traceroute could be interpreted, in one embodiment, solely within the [0438] RegEx LDM 130, the LKH LDM 140 may operate to reinforce the results that the RegEx LDM 130 generates. This interaction is discussed in further detailed below.
  • While the LKH LDM [0439] 140 may provide useful results, it has with it a dangerous side effect that requires careful attention; unless kept in check, the LKH LDM 140 has the power to “smear” a single location over the entire traceroute. The confidence maps utilized by the LDM 140, as described below, are particularly strict to address this issue.
  • An exemplary collection of confidence maps that may be utilized by the LDM [0440] 140 to attach confidence factors to location determinants are discussed below with reference to the FIGS. 20A-20C.
  • The below discussed collection of confidence maps attempt to address the following issues relating to confidence factors associated with a location determinant outputted by the LDM [0441] 140:
  • (1) How many nodes back was the last known host? If it was only one, it is probably a reasonable location determinant and deserves a high confidence factor. [0442]
  • (2) Did the last known host have a high confidence factor? If it did not, then neither should this one. [0443]
  • (3) Where in the traceroute is the last known host? If it is toward the middle, then the two machines are less likely to be in the same place than if it is at the end. [0444]
  • (4) Is the last known host physically located near to any of the Net, Loc, or DNS records for the host in question? If so, there is a higher likelihood that the two are in the same place. [0445]
  • The below discussed collection of confidence maps parameterizes the above concerns, generating confidence factors for the LKH LDM [0446] 140.
  • Node Distance—Confidence Confidence Map (320)
  • X-axis: Number of Hops Between this Host and the LKH [0447]
  • Y-axis: Stored confidence factor of the LKH [0448]
  • Color: confidence factor [0449]
  • Confidence map weight: 50 [0450]
  • Comments: An exemplary embodiment of the [0451] confidence map 320 is illustrated in FIG. 20A. As such above, it is desirable that the confidence maps utilized by the LDM 140 are “strict” to avoid erroneous location determinant smearing. This confidence map 320 only attributes relatively high confidence factors if the LKH is a small number of hops (e.g., less than 2 hops) away and the confidence factor of the LKH is very high.
  • Node Distance—Hop Ratio Confidence Map (322)
  • X-axis: Number of Hops Between current Host and the LKH [0452]
  • Y-axis: Hop Ratio [0453]
  • Color: confidence factor [0454]
  • Confidence map weight: 50 [0455]
  • Comments: An exemplary embodiment of the [0456] confidence map 322 is illustrated in FIG. 20B. This confidence map 322 generates relatively high factors if and only if the hosts are close together (in the traceroute) and at the end of the traceroute. Other scenarios receive low or zero confidence factors.
  • Shortest Registry Distance Confidence Map (324)
  • x-axis: Shortest Distance in Miles to {Net,DNS,Loc}[0457]
  • y-axis: confidence factor [0458]
  • confidence map weight: 50 [0459]
  • Comments: An exemplary embodiment of the [0460] confidence map 324 is illustrated in FIG. 20C. The confidence map 324 gives slightly higher confidence factors if and only if the LKH is proximal to any of the Net, DNS, or Loc Records.
  • NKH LDM Location Generation
  • The mechanics of Last Known Host (LKH) LDM [0461] 140 are substantially similar to the Next Known Host (NKH) LDM 142. While the NKH will usually not be directly instrumental in geolocating an end node, it can play an auxiliary role, and provide useful supplemental information. For example, if Router A is the last hop before a traceroute goes to an end node in, say, Denver, Colo., then it is not unlikely that Router A is also in Denver, Colo. By assigning Router A to Denver, Colo., the next time a traceroute runs through Router A, it can use the LKH to press on further.
  • The NKH LDM [0462] 142, in a slightly less robust way than the LKH LDM 140 and in a substantially way than the RegEx LDM 130, is a mechanism for providing supplemental information in the router space of the Internet, which subsequently provides aid in the end node geolocation.
  • An exemplary collection of confidence maps that may be utilized by the NKH LDM [0463] 142 to attach confidence factors to location determinants are discussed below with reference to FIGS. 21A-21C.
  • Node Distance—Confidence Confidence Map (330)
  • X-axis: Number of Hops Between this Host and the NKH [0464]
  • Y-axis: Stored confidence factor of the NKH [0465]
  • Color: confidence factor [0466]
  • Confidence map weight: 50 [0467]
  • Comments: An exemplary embodiment of the [0468] confidence map 330 is illustrated in FIG. 21A. Again it is desirable that the confidence maps utilized by the NKH LDM 142 are “strict” to avoid erroneous location determinant smearing. This confidence map 330 only gives high confidence factors if the NKH is a small number of hops (e.g., less than 2 hops) away from a current geographic location (e.g., host) and the confidence factor of the NKH is very high.
  • Node Distance—Hop Ratio Confidence Map (332)
  • X-axis: Number of Hops Between current Host and the NKH [0469]
  • Y-axis: Hop Ratio [0470]
  • Color: confidence factor [0471]
  • Confidence map weight: 50 [0472]
  • Comments: An exemplary embodiment of the [0473] confidence map 332 is illustrated in FIG. 21B. This confidence map 332 gives relatively high confidence factors if and only if the hosts are close together (in the traceroute) and at the end of the traceroute. Other scenarios receive low or zero confidence factors.
  • Shortest Registry Distance Confidence Map (334)
  • x-axis: Shortest Distance in Miles to {Net,DNS,Loc}[0474]
  • y-axis: confidence factor [0475]
  • confidence map weight: 50 [0476]
  • Comments: An exemplary embodiment of the [0477] confidence map 334 is illustrated in FIG. 21C. The confidence map 334 gives slightly higher confidence factors if and only if the NKH is proximal to any of the Net, DNS, or Loc Records.
  • Sandwich LDM Location Generation
  • FIG. 22 is a flowchart illustrating a [0478] method 340, according to an exemplary embodiment of the present invention, performed by the sandwich LDM 144 to identify one more geographic locations for a network address, and associated at least one confidence factor with each of the geographic locations.
  • The [0479] method 340 commences at decision block 342, where the sandwich LDM 144 determines whether both the LKH and the NKH LDMs 140 and 142 generated respective location determinants and associated confidence factors. If not, and only one or neither of these LDMs 140 and 142 generated a location determinant, the method 340 then ends at block 352.
  • On the other hand, following a positive determination at [0480] decision block 342, at block 344 the sandwich LDM 144 retrieves the respective location determinants from the LKH and the NKH LDMs 140 and 142.
  • At [0481] block 346, the sandwich LDM 144 identifies the location determinant received at block 344 that has the highest confidence factor associated therewith.
  • At [0482] block 348, the sandwich LDM 144 assigns a confidence factor to the location determinant identified at block 346 based on: (1) a combination of the confidence factors assigned to each of the location determinants by the LDMs 140 and 142 (e.g., by calculating the mean of the location determinants); and (2) the distance between the location determinants generated by the LDMs 140 and 142.
  • At [0483] block 350, the identified location determinant, and the new confidence factor calculated at block 348 are outputted from the sandwich LDM 144 to the location filter 122. The method 340 then ends at block 352.
  • It will be noted that the [0484] sandwich LDM 144 is different from the other LDMs, because it is the only LDM that does not operate to produce a location determinant that is potentially distinct from the location determinants produced by the other LDMs. The sandwich LDM 144 works as an extra enforcer to further empower the LKH and NKH LDMs 140 and 142. For example, if an exemplary host has a LKH location determinant and a NKH location determinant, the sandwich LDM 144 will choose the more confident of the two location determinants and assign a confidence factor based on their joint confidence factors and their distance to one another.
  • The [0485] sandwich LDM 144 addresses a potential inability of LKH and NKH LDMs 140 and 142 to work together successfully in filling in so-called “sure thing” gaps. For example, if hop #10 of a traceroute is in New York City and hop #13 is in New York City, then it can be assumed with a high degree of certainty that hops #11 and #12 should also be in New York City. This scenario is then generalized to treat not just identical NKH and LKH location determinants, but also ones that are very close to one another.
  • The [0486] sandwich LDM 144, in an exemplary embodiment, utilizes a single confidence map 354 illustrated in FIG. 23 to assign a confidence factor to a location determinant.
  • Sandwich/Confidence Factor—Proximity Confidence Map (354)
  • X-axis: Distance in Miles Between LKH and NKH [0487]
  • Y-axis: Mean confidence factor of LKH and NKH location determinants [0488]
  • Color: confidence factor [0489]
  • Confidence map weight: 50 [0490]
  • Comments: After the [0491] sandwich LDM 144 identifies which of the NKH or LKH location determinants as a higher confidence factor, it assigns a confidence factor to the identified location determinant that is only nontrivial if the LKH and NKH location determinants are very close and have a high mean confidence factor.
  • Suffix LDM Location Generation
  • The [0492] suffix LDM 146 operates on hostnames. If a hostname is not available, the suffix LDM 146 does not run. Further, it requires that the hostname end in special words, specifically ISO country codes or state/province codes. Accordingly, the suffix LDM 146 does not employ artificial intelligence, and looks up the code (e.g., the ISO country code or a state/province code) and returns the corresponding geographic location information. The code lookup may be performed on the demographic/geographic database 31. For example, a hostname that ends in ‘.jp’ is assigned to Japan; a hostname that ends in ‘.co.us’ is assigned to Colorado, USA.
  • In addition to the country and state standards, the [0493] suffix LDM 146 can also identify dozens of large carriers that have presences in particular regions. For example, a hostname that ends in ‘.telstra.net’ is assigned to Australia; a hostname that ends in ‘.mich.net’ is assigned to Michigan, USA.
  • The [0494] suffix LDM 146 also has a special relationship with the location filter 122. Because of its accuracy and generally large scale, the suffix LDM 146 is the only LDM that can insert location determinants into the location filter 122, requiring that all other location determinants agree with the location determinant generated by the suffix LDM 146, or they are not permitted to pass onto the location synthesis process 124.
  • Similar to the Loc LDM [0495] 138, the likelihood of accuracy of the location determinant generated by the suffix LDM 146 is not considered to be circumstantial. Accordingly, the suffix LDM 146 attributes a static confidence factor for all location determinants that it returns. This static confidence factor may, for example, be 91.
  • Location Filter (122)
  • In general, the spectrum of LDM “intelligence” is fairly large and, as will be appreciated from the above description, ranges from the thorough, hard-working [0496] RegEx LDM 130, which may attempt to put a hostname with ‘telco’ in Telluride, Colo., to the precise Loc LDM 138, which may generate precise location determinants. While the location synthesis process 124, as will be described in further detail below, is intelligent enough to process a broader range of location determinants utilizing corresponding confidence factors, it is desirable to remove unreasonable location determinants from the location determinants that are forwarded to the location synthesis process 124 for consideration.
  • To this end, the [0497] suffix LDM 146, for example, has a very high success rate in geolocation of a plethora of hosts, especially foreign ones. While the suffix LDM 146 lacks the high precision to be used by itself, the location determinant produced thereby may, in one exemplary embodiment, be deployed as a “filter location determinant”. Such a filter location determinant may, for example, be utilized by the location filter 122 to remove from the unified mapping process 61 location determinants that do not show a predetermined degree of correlation, agreement or consistency with the filter location determinant. A filter location determinant may, for example, be deployed to remove noise data, retaining a smaller, more manageable subset of location determinants that can be processed more quickly by the location synthesis process 124.
  • In one exemplary embodiment, the [0498] location filter 122 is tied directly to the suffix LDM 146. Because of the reliability and accuracy of the suffix LDM 146, the location determinant produced by this LDM 146 may be designated as the “filter location determinant”.
  • FIG. 24 is a flowchart illustrating a [0499] method 360, according to an exemplary embodiment of the present invention, of filtering location determinants received from the collection of LDMs utilizing a filter location determinant.
  • The [0500] method 360 commences at block 362 with the running of a high accuracy LDM (e.g., the suffix LDM 146) to generate the “filter location determinant” and optionally an associated confidence factor. At block 364, after the suffix LDM 146 has executed, the filter location determinant and confidence factor generated thereby are communicated to the location filter 122.
  • At [0501] block 366, the location filter 122 determines whether the received filter location determinant is a state or country. At block 368, the location filter 122 intercepts multiple location determinants outputted by the collection of LDMs and bound for the location synthesis process 124. The location filter 122 then checks to see if each of these location determinants adequately agrees with the filter location determinant. If they do, at block 372, the location determinants proceed onward to the location synthesis process 124 by being retained in an input stack being for this process 124. If they do not, at block 374, then the location determinants are removed from the input stack for the location synthesis process 124.
  • The agreement between the filter location determinant, and anyone of the multiple other location determinants received from the collection of LDMs, in one exemplary embodiment of the present invention, is a consistency between a larger geographic location (i.e., a location determinant of a relatively lower geographic location resolution) indicated by the filter location determinant and a more specific geographic location (i.e., a location determinant of a relatively higher geographic location resolution) that may be indicated by a subject location determinant. For example, [0502] location filter 122 may be effective in the debiasing of the United States data set. If the word ‘london’ is extracted from a hostname by way of the RegEx LDM 130, then the location synthesis process 124 may have a dozen or so ‘Londons’ to sort out. One is in the UK, and all the others are in the US. The confidence factors generated by the RegEx LDM 130 will reflect likelihood of correctness and highlight London, UK, as the best, but if there is a ‘.uk’ at the end of the relevant hostname, then the location filter 122 can save the location synthesis process 124 from doing hundreds of thousands of extraneous operations.
  • Location Synthesis Process (126)
  • The [0503] collection 120 of LDMs can conceptually be thought of as a collection of independent, artificially intelligent agents that continuously look at data and use their respective artificial intelligences to make decisions. In the exemplary embodiment there are thus conceptually eight artificially intelligent agents mapping the Internet at relatively high speeds. An issue arises, however, in that there may be conflicts or disagreements in the results delivered by each of these artificially intelligent agents.
  • The [0504] collection 120 of different LDMs may disagree on any number of different levels. For example, two LDMs may return the same country and region, but different states and DMAs (Designated Marketing Areas). Alternatively, for example, one LDM may return a country only, while another LDM returns a city in a different country but on the same continent.
  • The [0505] unified mapping process 61, in one exemplary embodiment, includes the ability to analyze where the incoming location determinants agree, and where they disagree. From this analysis, the unified mapping process 61 operates to select the location determinant that has the highest likelihood of being correct. In order to perform this selection, the unified mapping process 61 includes the capability to assess the likelihood that it is correct.
  • To assist in the [0506] unified mapping process 61 with decision making, the LDMs provide associated confidence factors along with the location determinants, as described above. The confidence factors comprise quantitative values indicating levels of confidence that the LDMs have that the provided location determinants are in fact true. It should be noted that these confidence factors are not tied to any particular level of geographic granularity (or geographic resolution). In one exemplary embodiment of the present invention, the location synthesis process 124 operates to produce a separate confidence factor for each level of geographic resolution or granularity (e.g., country, state, etc.).
  • FIG. 25 is a flowchart illustrating a [0507] method 380, according to an exemplary embodiment of the present invention, performed by the location synthesis process 124 to deliver a single location determinant which the unified mapping process 61 has identified as being the best estimate of the “true” geographic location associated with any particular network address. An initial discussion provides a high-level overview of the method 380, with further details being provided below in the context of an illustrative example.
  • The [0508] method 380 commences at block 382, where the location synthesis process 124 compares every location determinant received from the location filter 122 against every other location determinant (where appropriate). At block 384, the location synthesis process 124 builds a confirmation confidence factor table. At block 386, the location synthesis process 124 collapses separate confidence factors into one or more confirmation confidence factors, and at block 388 chooses a single location determinant as the best estimate based on one or more confirmation confidence factors. The choice of the “best estimate” location determinant at block 388 is performed by identifying the location determinant that exhibits a highest degree of confidence factor-weighted agreement with all the other location determinants. A final table of confidence factors generated for the “best estimate” location determinant is reflective of that agreement. The method 380 then ends at block 390.
  • The location synthesis process [0509] 124 takes its input in the form of multiple sets of location determinants, as stated above. In one exemplary embodiment, a distinction is made between this method and a method of a flat set of all location determinants. The location determinants are provided to the location synthesis process 124 as multiple sets. The provision the location determinants in sets indicates to the location synthesis process 124 which location determinants should be compared against other. Specifically, efficiencies can be achieved by avoiding the comparison of location determinants within a common set, delivered from a common LDM.
  • To illustrate this issue, suppose that the [0510] RegEx LDM 130 extracts two strings, one that yields twenty (20) location determinants, and another that yields fifty (50). Also suppose that the LKH LDM 140 is able to generate a location determinant. Accordingly, in this example, a total of 71 location determinants require consideration by the location synthesis process 124. If the process 124 flatly compared all 71 against each other, this would result in (70+69+68+ . . . +3+2+1) 2485 comparisons. If, however each location determinant of each set can ignore all sibling location determinants of the same set, it will be appreciated that only (20*51+50*21+70) 2140 comparisons are required. A further advantage of considering LDMs in sets, in addition to the reduction in number of comparisons, is the set interpretation; location determinants generated from the exact same source should not, in one exemplary embodiment, be allowed to confirm one another.
  • Accordingly, at [0511] block 382 of the method 380 described above with reference to FIG. 25, the location synthesis process 124 iteratively compares each location determinant of each set with each location determinant of each other set. The comparison, in exemplary embodiment, because at a number of resolutions, for example:
  • 1. Continent; [0512]
  • 2. Country; [0513]
  • 3. Region; [0514]
  • 4. State; [0515]
  • 5. DMA; [0516]
  • 6. MSA; [0517]
  • 7. PMSA; and [0518]
  • 8. City.[0519]
  • These comparisons give rise to the confirmation confidence factor table, which is generated at [0520] block 384 of the method 380. The confirmation confidence factor table is a matrix of location determinants by geographic location resolution with their respective confirmation confidence factor. The confirmation confidence factor calculation can be interpreted as a calculation of the probability that any of the agreeing location determinants are correct, given that the associated confidence factors are individual probabilities that each is independently correct.
  • An illustrative example of the calculation of the confirmation confidence factor table, which uses a limited number of resolution levels and very few location determinants, is provided below. Table 4, below, illustrates an exemplary input of location determinants and associated confidence factors provided to the location synthesis process [0521] 124 from the location filter 122.
    TABLE 4
    Example input for the location synthesis process 124.
    Post-Filter Location Synthesis Process Input (Location
    Determinants and associated Confidence Factors)
    Set 1 Set 2 Set 3 Set 4
    New York, NY, USA Elizabeth, NJ, London, UK Newark, NJ, USA
    [30] USA [25] [20] [50]
    New York (ST), USA
    [25]
  • In this example, there are four input sets, each with one or more location determinants and a confidence factor for each location determinant. The initial (empty) confirmation confidence factor matrix takes the form of the Table 5 illustrated below. [0522]
    TABLE 5
    Initial confirmation confidence factor matrix.
    Country State City
    New York, NY,
    USA
    New York State,
    USA
    Elizabeth, NJ,
    USA
    London, UK
    Newark, NJ, USA
  • Each element of the matrix is computed by comparing all relevant (no intra-set mingling) matches. For example, evaluating the country confidence factor for New York, N.Y., USA yields the following Table 6: [0523]
    TABLE 6
    Example Location Determinant Comparisons.
    Matches Country (always New York, NY, USA
    match self)
    Cannot Compare (same set) New York State, USA
    Matches Country Elizabeth, NJ, USA
    Does Not Match Country London, UK
    Matches Country Newark, NJ, USA
  • In order to collapse of the separate confidence factors into a combined confidence factor, at [0524] block 386 of the method 380 illustrated in FIG. 25, use is made of a confirmation confidence factor formula. An example of such a confirmation confidence factor formula is provided below:
  • If mcf[0525] i is the ith of n confidence factors from matching location determinants, then the confirmation confidence factor (CCF) is computed by: CCF = 100 × [ 1 - i = 1 n ( 1 - m c f i 100 ) ]
    Figure US20040078490A1-20040422-M00002
  • In the illustrative example, New York City matches with itself, Elizabeth, and Newark at the country level (e.g., a first level of geographic resolution). Accordingly, utilizing the above confirmation confidence factor formula, the location synthesis process [0526] 124 combines these three associated confidence factors (30, 25, and 50) to deliver the following confirmation confidence factor:
  • CCF=100{1−[(1−0.30)(1−0.25)(1−0.50)]}[0527]
  • CCF=73.75[0528]
  • Confirmation confidence factors are, in this way, generated at a plurality of geographic resolutions (e.g., continent, country, state, city) by detecting correspondences between the location determinants at each of these geographic resolutions, and calculating the confirmation confidence factors for each of these geographic resolutions for each of the location determinants. Accordingly, utilizing the about calculation, the confirmation confidence factor table illustrated in Table 6 is populated as illustrated below in Table 7: [0529]
    TABLE 6
    Completed confirmation confidence factor table.
    Country State City
    New York, NY, 73.75 30 30
    USA
    New York State, 71.88 25 NA
    USA
    Elizabeth, NJ, 80.31 62.5 25
    USA
    London, UK 20 20 20
    Newark, NJ, USA 80.31 62.5 50
  • It will be noted that the “state” and “city” confirmation confidence factors for the “New York, N.Y., USA” location determinant corresponded to the original, combined confirmation confidence factor (as generated by a LDM) for this location determinant, in view of the absence of any correspondence, or agreement, at the “state” and “city” geographic resolution levels for this location determinant. On the other hand, as two (2) agreement instances were detected for this location determinant at the “country” geographic resolution level, the confirmation confidence factor at this geographic resolution is higher than the original combined confirmation factor. [0530]
  • After the entire confirmation confidence factor table (or matrix) is generated at [0531] block 386, the location synthesis process 124 then has the task of identifying the “best estimate” location determinant at block 388. In the previous example, the correct answer is apparent from the combined confidence factor table. There is no better choice than Newark, N.J.; it is tied for first place on country and state levels, but it is first at the city level. However, consider the more complex examples in which one location determinant has the highest state confidence factor, but another has the highest DMA (Designated Marketing Area) confidence factor. To handle cases such as this, the location synthesis process 124 generates a combined confirmation confidence factor that is a linear combination of the constituent confirmation confidence factors.
  • For the purposes of generating the combined confirmation confidence factor, different weights may, in an exemplary embodiment, be assigned to each of a plurality of levels of geographic resolution. Exemplary weights that may be utilized in the linear combination of the confirmation confidence factors are provided below:[0532]
  • 1. [0533] City 30
  • 2. [0534] State 20
  • 3. [0535] Country 15
  • 4. [0536] Region 10
  • 5. [0537] MSA 0
  • 6. [0538] PMSA 0
  • 7. [0539] DMA 80
  • 8. [0540] Continent 5
  • These exemplary weights are indicative of the importance and significance of agreement at a given level of geographic resolution. For example, the PMSA and MSA geographic resolutions each have a zero weight because of their close ties with the DMA and City geographic resolutions. Agreement at the continental geographic resolution level is common and easy to achieve, and this resolution level is weighted very low in the combined confirmation confidence factor. Because the DMA geographic resolution level is considered to be the most significant level in the exemplary embodiment, it is allocated the highest weight. [0541]
  • Any geographic resolution levels that are not available (e.g., foreign countries do not have DMAs) are not utilized in the averaging process, and accordingly neither detriment nor assist the combined confirmation confidence factor. [0542]
  • After the generation of the combined confirmation confidence factor, the location synthesis process [0543] 124 selects the largest valued combined confidence factor and uses that location determinant as the final result (i.e., the “best estimate” location determinant). The location synthesis process 124 returns the single “best estimate” location determinant, along with an associated LPT (Location Probability Table) that constitutes the relevant location determinant's row of the confirmation confidence factor table.
  • In an exemplary embodiment of the present invention, an LPT table (not shown) is maintained within the [0544] data warehouse 30 and stores the location probability tables generated for a block of network addresses (or for an individual network address). An exemplary LPT table entry is provided below as Table 7:
    TABLE 7
    LPT
    Column Description
    OCT1
    1st octet of the Network
    OCT2
    2nd octet of the Network
    OCT3
    3rd octet of the Network
    OCT4
    4th octet of the Network
    CONTINENT Continent code from the Continents Reference
    CODE Table where the Network is located.
    CONTINENT Confidence Factor Associated with the
    CONFIDENCE Identified Continent.
    FACTOR
    COUNTRY Country code from the Countries Reference
    CODE Table where the Network is located.
    COUNTRY Confidence Factor Associated with the
    CONFIDENCE Identified Country.
    FACTOR
    REGION Region code from the Regions Reference Table
    CODE where the Network is located. This will be one
    of the Regions in the United States like Mid-
    West, West etc.
    REGION Confidence Factor Associated with the
    CONFIDENCE Identified Region.
    FACTOR
    STATE CODE State code or equivalent like Province Code,
    from the States Reference Table where
    the Network is located.
    STATE Confidence Factor Associated with the
    CONFIDENCE Identified State.
    FACTOR
    DMA CODE Designated Market Area Code in United States
    where the network is located. Applicable only
    for the networks in US
    DMA Confidence Factor Associated with the
    CONFIDENCE Identified DMA
    FACTOR
    PMSA CODE Primary Metropolitan Statistical Area Code in
    United States where the network is located.
    Applicable only for the networks in US.
    PMSA Confidence Factor Associated with the
    CONFIDENCE Identified PMSA.
    FACTOR
    MSA CODE Metropolitan Statistical Area Code in United
    States where the network is located. Applicable
    only for the networks in United States
    MSA Confidence Factor Associated with the
    CONFIDENCE Identified MSA.
    FACTOR
    CITY CODE City code from the Cities Reference Table where
    The Network is located
    CITY Confidence Factor Associated with the
    CONFIDENCE Identified City.
    FACTOR
    ZIP CODE ZIP CODE or equivalent of the location where
    the network is located.
    ZIP Confidence Factor Associated with the
    CONFIDENCE Identified ZIP CODE
    FACTOR
    AREA CODE Telephone Area Code of the location where the
    network is located. Applicable to United States
    networks.
    AREA CODE Confidence Factor Associated with the
    CONFIDENCE Identified AREA CODE
    FACTOR
    LATUTUDE Latitude of the location where the network is
    located.
    LONGITUDE Longitude of the location where the network is
    located.
    TIMEZONE Time Zone of location where the network is
    located.
  • Confidence Accuracy Translator (126)
  • In one exemplary embodiment, in order to assist in the interpretation of the end data, the [0545] unified mapping process 61 outputs the “best estimate” location determinant together with a full Location Probability Table (LPT) (i.e., the end result 128 illustrated in FIG. 11). The values of the location probability table are the probabilities that the given location is correct at a number of geographic location resolution levels (or granularities). The location synthesis process 124 does return an application probability table, and while the values in that are self-consistent and relatively meaningful, they are not location probabilities in the formal sense.
  • In the exemplary embodiment, a translation is provided so that when a customer gets a result that is reported with a “90” confidence factor, the customer can know that if 100 records all with 90 confidence factor were pulled at random, roughly [0546] 90 of them would be correct. This translation function is performed by the confidence accuracy translator 126
  • Accuracy cannot be inferred by a single observation. A single observation is either right or wrong. It is only by looking at aggregate correctness that assertions can be made about accuracy. [0547]
  • FIG. 26 is a [0548] graph 400 illustrating correctness of location determinants, as a function of post-location synthesis process confidence factor. It will be noted from the graph 400 that, in general, incorrect responses are generally given low confidence factors, and the higher confidence factors are generally associated with more correctness. To formalize this relationship, a moving average can be used to infer the rough relationship between confidence factors and accuracy.
  • FIG. 27 is a [0549] graph 402 illustrating correctness of location determinants as a function of post-LSP confidence factor, and the smoothed probability of correctness given a confidence factor range. In FIG. 27, a curve 404 is a 41-point moving average, representing the probability that the given responses in that confidence factor neighborhood are right. Again, it has the desired shape. Low confidence factors are associated with low accuracy, and conversely, high confidence factors are associated with high accuracy. Through this, it is clear that carrying the confidence factors throughout the unified mapping process 61 is beneficial, because, in this way, not only can the unified mapping process 61 generally be skillful, but it can know when it is less skillful. What remains, however, it the final translation of post-location synthesis process confidence factors into probabilistically meaningful confidence factors.
  • This translation is represented by the [0550] curve 404 of FIG. 27. To avoid over-fitting to the noise of the function, the confidence accuracy translator 126 uses a piecewise linear approximation of the function by binning the data into equally sized, disjoint confidence factor bins.
  • FIG. 28 is a [0551] graph 406 illustrating correctness of location determinants as a function of post-LSP confidence factor, and the smoothed probability of correctness given a confidence factor range with picewise linear approximation. As shown in FIG. 28, a curve 408 is the approximation of the confidence factor-Accuracy relationship generated with each abscissa being the average confidence factor of the bin and each ordinate being the number of accuracy within the bin. Accordingly, the curve 408 can be and is used as an interpolation scheme for unified mapping process 61 to make the needed translation.
  • While interpolation is a fairly low-risk method for inferring information, extrapolation can provide incorrect data. Note from FIG. 28 that there is insufficient data with confidence factor less than 20 or greater than 65 to establish a significant relationship. Yet, the required robust translation must account for any confidence factor in the valid range of 0 to 100. In this way, the [0552] confidence accuracy translator 126 is forced to extrapolate, but does so in a restraint manner. Erring on the side of less expected accuracy, the confidence accuracy translator 126 introduces two new points to the interpolation scheme: [0,0], and [100,max(CFavg)]. This implies that if the location synthesis process 124 returns with a zero confidence factor, it is incorrect and that if it returns with any confidence factor greater than the maximum of the binned interpolation nodes, then it has precisely the same accuracy as the best bin.
  • These artificial extrapolations (shown at [0553] 410 in FIG. 28) will make the accuracy over the unified mapping process 61 appear lower than it really is. Combining the curves 408 and 410, the entire set of confidence factors can now be translated. This translation is illustrated in FIG. 29. More specifically, FIG. 29 shows a graph 411 plotting correctness of location determinants as a function of post-CAT confidence factor, and the smoothed probability of correctness. Final results of the post-CAT confidence factors are compared against the actual accuracy in FIG. 29. As can be noted, there is a strong correlation, thus giving the final confidence factor the probabilistic meaning that is useful to end users to make meaningful decisions. While there is strong correlation, it should be noted that this is a general relationship and that, while pulling a random subset and verifying should yield comparable results, data may be noisy, and some populations may show disparities between confidence and real accuracy.
  • A number of further algorithms are now described. These further algorithms may be deployed in alternative embodiments of the present invention, and in conjunction with any of the algorithms (e.g., LDMs) discussed above. [0554]
  • Latitude and Longitude Matching
  • In one embodiment of the present invention, a latitude and longitude matching process may be utilized used to assist in the determination the geographic location of a given record. Only a network address (e.g., and IP address) is required for the longitude and latitude matching process to be successful. However, additional information, such as the owner's location, or proximal routers, may be utilized to achieve a higher probability of success. [0555]
  • The geographic locations identified by the longitude and latitude matching is utilized to compute distances, using this information to determine accuracy of a given record. The information is compared with previous “hops” of the traceroute to the host. If the route forms a predictable pattern, a confidence factor maybe be increased. [0556]
  • Launching traces from network and geographically disperse locations, algorithms may compute the similarity of each trace, arriving at a final confidence factor ranking. The higher the ranking, the more likely the location attempt was successful. [0557]
  • EXAMPLE 1
  • The last four hops in a traceroute form a distal-proximal relationship, meaning that the next hop is geographically closer to its next successive hop:[0558]
  • [0559] Hop 5 is closer to hop 6
  • [0560] Hop 6 is closer to hop 7
  • [0561] Hop 7 is closer to hop 8
  • Thus, the traced route geographically progresses toward the [0562] final hop 8, leading to a decision that the destination is located within a certain range of accuracy.
  • EXAMPLE 2
  • The point of origin is Denver, Colo., and the destination is Salt Lake City, Utah. The last four hops indicate a connection that is back-hauled through Denver, Colo., essentially geographically backtracking the route taken:[0563]
  • 1 Denver Router [0564]
  • 2 Grand Junction Router [0565]
  • 3 Provo Utah Router [0566]
  • 4 Salt Lake City Router [0567]
  • 5 Salt Lake City Router [0568]
  • 6 Denver Router [0569]
  • 7 Provo Utah Router [0570]
  • 8 Salt Lake City Router [0571]
  • 9 Salt Lake City Destination[0572]
  • This example indicates a geographic progression away from Denver toward Utah, directly back to Denver, and finally directly back to Utah with a destination that does not leave Utah. Thus, a human may assume that even though the route taken was very indirect, it did terminate in Utah. Using Latitude/Longitude coordinates, the [0573] data collection agents 18 will see the same scenario and arrive at an intelligent conclusion.
  • Triangulation
  • Using a translation process, in one exemplary embodiment of the present invention, an approximate radius containing the target network address be generated. Launching a latitude/longitude route discovery from geographically disperse locations, the final destination will likely proceed through the same set of routers. Thus, if the final 3 hops leading up to the point of entry into the destination network are proximal, or at the very least, form a line toward the destination's point of entry, one may assume that the destination resides within the common latitude/longitude coordinates. Using the attitude/latitude coordinates of other known landmarks allows a radius to be computed. Within this radius, metro areas and large cities will be known. [0574]
  • EXAMPLE
  • A traceroute is launched from the East Coast, the West Coast, and the North West. Route progression from the East Coast indicates a westward path, terminating in Texas. Route progression from the West Coast indicates an eastward path, terminating in Texas. Route progression from the North West indicates an eastward path, terminating in Texas. [0575]
  • Being that all routes terminated in Texas, and the associated record for the target indicates a Texas-based owner, specifically, Dallas, one may assume that in fact, the target resides in the DFW metro area. [0576]
  • Triangulation is the technique of using traceroutes originating from geographically widely separated locations and using the results to extrapolate a possible location for the target network address. [0577]
  • Once all the traceroutes have been completed, a general direction (e.g. Northward, Eastward) may be extrapolate from the traceroutes using knowledge of the locations of the routers in the traceroute. This can then be used to place bounds on the possible location by creating an intersection of all traceroutes. For example, a traceroute going East from San Francisco, West from New Jersey is probably somewhere in the Central time zones. Directions for the traceroutes can be inferred by subtracting the geographical locations of the originating network address from those of the latest router in the trace that has a known location. Additionally, information about the number of hops in the traceroutes can be used to obtain estimates of distance. [0578]
  • Because a number of traceroutes should be obtained for each target network address, an infrastructure is in place to distribute these requests. One exemplary manner of implementing the system is to have a single script on a single machine make “rsh” calls to remote machines to obtain the traceroutes. This avoids they need for buffering and synchronization (these are pushed off to the operating system calls that implement the blocking for the rsh command). The machines used may actually be the same machines as used for the dialup method. These are already connected to ISPs at widely separated locations. [0579]
  • In addition to a confidence factor, a translation process may also generate a resolution indication. This will depend on: [0580]
  • If all the traces seem to be going in the same direction. If so the resolution is low (do the trigonometry). [0581]
  • The number of traces available. The more traces, the higher the resolution. [0582]
  • The variance in the distances obtained. Each trace will result in a circle around the predicted point according to the expected variance in the distance. The intersection of these circles dictates the probable location. The area of the intersection dictates the resolution (the larger the area the lower the resolution). The distance scale and the variances can only be calibrated using experimental results from known locations. [0583]
  • Computer System
  • FIG. 30 shows a diagrammatic representation of machine in the exemplary form of a [0584] computer system 500 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.
  • The [0585] computer system 500 includes a processor 502, a main memory 504 and a static memory 506, which communicate with each other via a bus 508. The computer system 500 may further include a video display unit 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 500 also includes an alpha-numeric input device 512 (e.g. a keyboard), a cursor control device 514 (e.g. a mouse), a disk drive unit 516, a signal generation device 518 (e.g. a speaker) and a network interface device 520.
  • The [0586] disk drive unit 516 includes a machine-readable medium 522 on which is stored a set of instructions (i.e., software) 524 embodying any one, or all, of the methodologies described above. The software 524 is also shown to reside, completely or at least partially, within the main memory 504 and/or within the processor 502. The software 524 may further be transmitted or received via the network interface device 520. For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
  • Thus, a method and a system to collect a geographical location information associated with a network address have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. [0587]

Claims (48)

What is claimed is:
1. A method to collect geographic location information, the method including:
collecting geographic location information, associated with a network address, utilizing a plurality of geographically dispersed data collection agents; and
utilizing the geographic location information to associate a geographic location with the network address.
2. The method of claim 1, including deploying the plurality of geographically dispersed agents at a plurality of respective and separate service providers.
3. The method of claim 1, wherein the collecting of the geographic location information includes performing a traceroute search.
4. The method of claim 1, wherein the collecting of the geographic location information includes determining validity of the geographic location information utilizing built-in metrics.
5. The method of claim 1, including controlling the plurality of geographically dispersed data collection agents utilizing a data collection broker.
6. The method of claim 5, including controlling a further plurality of geographically dispersed data collection agents utilizing a further data collection broker.
7. The method of claim 5, including, utilizing the data collection broker, determining which data collection agents of the plurality of data collection agents are most appropriate for the collecting of the geographic location information.
8. The method of claim 5, wherein each of the plurality of data collection agents is to advise the data collection broker regarding a success or a failure of a search conducted to collect the geographic location information.
9. The method of claim 6, including transferring the collecting of the geographic location information from the data collection broker to the further data collection broker, associated with the further plurality of geographically dispersed data collection agents.
10. The method of claim 1, including providing the geographic location information from each of the plurality of dispersed data collection agents to a data collection broker.
11. The method of claim 10, including, utilizing the data collection broker, storing the geographic location information within a collection database.
12. The method of claim 1, wherein an analysis module utilizes the geographic location information to associate the geographic location with the network address.
13. The method of claim 1, wherein at least one of the plurality of geographically dispersed data collection agents is capable of performing a plurality of data collection operations.
14. The method of claim 13, wherein the plurality of data collection operations is in accordance with a plurality of analysis techniques utilized by an analysis module.
15. The method of claim 14, wherein a data collection broker is to determine which of the plurality of analysis techniques, utilized by the analysis module, is to be utilized by the analysis module with respect to the network address.
16. The method of claim 10, wherein at least one of the plurality of geographically dispersed data collection agents locally stores the geographic location information, collected utilizing one or more searches, and batch updates the data collection broker utilizing the locally stored geographic location information.
17. The method of claim 3, wherein the collecting of the geographic location information includes launching first and second traceroutes from respective first and second collection agents of the plurality of geographically dispersed data collection agents.
18. The method of claim 17, wherein each of the first and second traceroutes is with respect to the network address.
19. The method of claim 18, including computing a similarity of the first and second traceroutes to generate a confidence factor for the geographic location associated with the network address.
20. The method of claim 18, wherein the association of the geographic location with the network address includes determining whether each of the first and second traceroutes proceeds through a common set of routers.
21. The method of claim 18, wherein the association of the geographic location with the network address includes determining that each of the first and second traceroutes terminates at or approximate the geographic location.
22. The method of claim 18, wherein the association of the geographic location with the network address includes extrapolating a direction indication for the geographic location, utilizing knowledge of locations of routers in each of the first and second traceroutes.
23. The method of claim 22, including extrapolating a plurality of direction indications utilizing the knowledge of the locations of the routers in each of the first and second traceroutes, and identifying the geographic location utilizing the plurality of direction indications.
24. A system to collect geographic location information, the system including:
a plurality of geographically dispersed data collection agents to collect geographic location information, associated with a network address; and
an analysis module to associate a geographic location with the network address, utilizing the collected geographic location information.
25. The system of claim 24, wherein the plurality of geographically dispersed data collection agents are deployed at a plurality of respective and separate service providers.
26. The system of claim 24, wherein at least one of the plurality of geographically dispersed data collection agents is to collect the geographic location information by performing a traceroute search.
27. The system of claim 24, wherein at least one of the plurality of geographically dispersed data collection agents is to determine validity of the geographic location information utilizing built-in metrics.
28. The system of claim 24, including a data collection broker to control the plurality of geographically dispersed data collection agents.
29. The system of claim 28, including a further data collection broker to control a further plurality of geographically dispersed data collection agents.
30. The system of claim 28, wherein the data collection broker is to determine which data collection agents of the plurality of data collection agents are most appropriate for the collecting of the geographic location information.
31. The system of claim 28, wherein each of the plurality of data collection agents is to advise the data collection broker regarding a success or a failure of a search conducted to collect the geographic location information.
32. The system of claim 29, wherein the data collection broker is to transfer the collecting of the geographic location information to the further data collection broker, associated with the further plurality of geographically dispersed data collection agents.
33. The system of claim 24, wherein each of the plurality of dispersed data collection agents is to provide the geographic location information to a data collection broker.
34. The system of claim 33, including a collection database, wherein the data collection broker is to store the geographic location information within the collection database.
35. The system of claim 24, including an analysis module to utilize the geographic location information to associate the geographic location with the network address.
36. The system of claim 24, wherein at least one of the plurality of geographically dispersed data collection agents is capable of performing a plurality of data collection operations.
37. The system of claim 36, wherein the plurality of data collection operations is in accordance with a plurality of analysis techniques utilized by an analysis module.
38. The system of claim 37, wherein a data collection broker is to determine which of a plurality of analysis techniques, utilized by the analysis module, is to be utilized by the analysis module with respect to the network address.
39. The system of claim 33, wherein at least one of the plurality of geographically dispersed data collection agents is to locally store the geographic location information, collected utilizing one or more searches, and to batch update the data collection broker utilizing the locally stored geographic location information.
40. The system of claim 24, wherein the collecting of the geographic location information includes launching first and second traceroutes from respective first and second collection agents of the plurality of geographically dispersed data collection agents.
41. The system of claim 40, wherein each of the first and second traceroutes is with respect to the network address.
42. The system of claim 40, including computing a similarity of the first and second traceroutes to generate a confidence factor for the geographic location associated with the network address.
43. The system of claim 40, wherein the association of the geographic location with the network address includes determining whether each of the first and second traceroutes proceeds through a common set of routers.
44. The system of claim 40, wherein the association of the geographic location with the network address includes determining that each of the first and second traceroutes terminates at or approximate the geographic location.
45. The system of claim 40, wherein the association of the geographic location with the network address includes extrapolating a direction indication for the geographic location, utilizing knowledge of locations of routers in each of the first and second traceroutes.
46. The system of claim 45, including extrapolating a plurality of direction indications utilizing the knowledge of the locations of the routers in each of the first and second traceroutes, and identifying the geographic location utilizing the plurality of direction indications.
47. A machine-readable medium storing a set of instructions that, when executed by a machine, cause the machine to perform a method to collect geographic location information, the method including:
collecting geographic location information, associated with a network address, utilizing a plurality of geographically dispersed data collection agents; and
utilizing the geographic location information to associate a geographic location with the network address.
48. A system to collect geographic location information, the system including:
a plurality of geographically dispersed data collection means for collecting geographic location information, associated with a network address; and
an analysis means for associating a geographic location with the network address, utilizing the collected geographic location information.
US10/686,135 2000-04-03 2003-10-14 Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents Active 2024-03-31 US7809857B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/686,135 US7809857B2 (en) 2000-04-03 2003-10-14 Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US19476100P 2000-04-03 2000-04-03
US24177600P 2000-10-18 2000-10-18
US09/825,675 US6684250B2 (en) 2000-04-03 2001-04-03 Method and apparatus for estimating a geographic location of a networked entity
US10/686,135 US7809857B2 (en) 2000-04-03 2003-10-14 Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/825,675 Continuation US6684250B2 (en) 2000-04-03 2001-04-03 Method and apparatus for estimating a geographic location of a networked entity

Publications (2)

Publication Number Publication Date
US20040078490A1 true US20040078490A1 (en) 2004-04-22
US7809857B2 US7809857B2 (en) 2010-10-05

Family

ID=27393357

Family Applications (6)

Application Number Title Priority Date Filing Date
US09/825,675 Expired - Lifetime US6684250B2 (en) 2000-04-03 2001-04-03 Method and apparatus for estimating a geographic location of a networked entity
US10/686,135 Active 2024-03-31 US7809857B2 (en) 2000-04-03 2003-10-14 Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents
US10/685,692 Expired - Lifetime US9021080B2 (en) 2000-04-03 2003-10-14 Method and system to associate geographic location information with a network address using a combination of automated and manual processes
US10/686,102 Expired - Lifetime US7472172B2 (en) 2000-04-03 2003-10-14 Method and system to initiate geolocation activities on demand and responsive to receipt of a query
US10/685,991 Expired - Lifetime US7072963B2 (en) 2000-04-03 2003-10-14 Method and system to modify geolocation activities based on logged query information
US14/687,635 Expired - Lifetime US9413712B2 (en) 2000-04-03 2015-04-15 Method and system to associate a geographic location information with a network address using a combination of automated and manual processes

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/825,675 Expired - Lifetime US6684250B2 (en) 2000-04-03 2001-04-03 Method and apparatus for estimating a geographic location of a networked entity

Family Applications After (4)

Application Number Title Priority Date Filing Date
US10/685,692 Expired - Lifetime US9021080B2 (en) 2000-04-03 2003-10-14 Method and system to associate geographic location information with a network address using a combination of automated and manual processes
US10/686,102 Expired - Lifetime US7472172B2 (en) 2000-04-03 2003-10-14 Method and system to initiate geolocation activities on demand and responsive to receipt of a query
US10/685,991 Expired - Lifetime US7072963B2 (en) 2000-04-03 2003-10-14 Method and system to modify geolocation activities based on logged query information
US14/687,635 Expired - Lifetime US9413712B2 (en) 2000-04-03 2015-04-15 Method and system to associate a geographic location information with a network address using a combination of automated and manual processes

Country Status (1)

Country Link
US (6) US6684250B2 (en)

Cited By (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032905A1 (en) * 2000-04-07 2002-03-14 Sherr Scott Jeffrey Online digital video signal transfer apparatus and method
US20020059622A1 (en) * 2000-07-10 2002-05-16 Grove Adam J. Method for network discovery using name servers
US20020073199A1 (en) * 2000-05-26 2002-06-13 Matthew Levine Method for extending a network map
US20020129134A1 (en) * 2000-05-26 2002-09-12 Leighton F. Thomson Global load balancing across mirrored data centers
US20020143991A1 (en) * 2001-03-16 2002-10-03 Kingsum Chow Geographic location determination including inspection of network address
US20030110293A1 (en) * 1999-05-03 2003-06-12 Friedman Robert B. Geo-intelligent traffic reporter
US20040078367A1 (en) * 2000-04-03 2004-04-22 Mark Anderson Method and system to modify geolocation activities based on logged query information
WO2005033878A2 (en) * 2003-09-29 2005-04-14 Ebay Inc. Method and apparatus for geolocation of a network user
US20050204064A1 (en) * 2005-06-23 2005-09-15 The Go Daddy Group, Inc. Resolving access to content associated with shared domain name using routing dns
US20050216567A1 (en) * 2005-06-24 2005-09-29 The Go Daddy Group, Inc. System and method for email delivery for shared domain name
US20050234922A1 (en) * 1999-05-03 2005-10-20 Parekh Sanjay M Systems and methods for determining, collecting, and using geographic locations of internet users
US20050289242A1 (en) * 2005-06-24 2005-12-29 The Go Daddy Group, Inc. Resolving access to content associated with shared domain name using routing website
US20060010252A1 (en) * 2004-03-04 2006-01-12 Miltonberger Thomas W Geo-location and geo-compliance utilizing a client agent
US20060053066A1 (en) * 2000-04-07 2006-03-09 Sherr Scott J Online digital video signal transfer apparatus and method
US7062572B1 (en) * 2001-03-19 2006-06-13 Microsoft Corporation Method and system to determine the geographic location of a network user
US20060128397A1 (en) * 2004-12-15 2006-06-15 Choti Joseph F System and method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US20060224752A1 (en) * 1999-05-03 2006-10-05 Parekh Sanjay M Determining geographic locations of private network Internet users
US20070088818A1 (en) * 2005-10-14 2007-04-19 Cisco Technology Inc. Sharing of presence-based time-zone information
US20070260649A1 (en) * 2006-05-02 2007-11-08 International Business Machines Corporation Determining whether predefined data controlled by a server is replicated to a client machine
US20080276004A1 (en) * 2007-05-01 2008-11-06 Cisco Technology, Inc. Populating Location Wiremap Databases
US20090285211A1 (en) * 2005-01-11 2009-11-19 Matsushita Electric Industrial Co., Ltd. Communication method and receiving terminal
US7640339B1 (en) * 2005-02-14 2009-12-29 Sun Microsystems, Inc. Method and apparatus for monitoring a node in a distributed system
US20100145814A1 (en) * 2008-12-08 2010-06-10 At&T Mobility Ii Llc Access modeling in a communication domain
US7739680B1 (en) * 2005-07-21 2010-06-15 Sprint Communications Company L.P. Application server production software upgrading with high availability staging software
US20100299386A1 (en) * 2006-10-26 2010-11-25 Seanodes Computer-based system comprising several nodes in a network
US7844729B1 (en) 1999-05-03 2010-11-30 Digital Envoy, Inc. Geo-intelligent traffic manager
CN102014366A (en) * 2009-09-04 2011-04-13 腾讯科技(深圳)有限公司 Method, device and system for updating IP address home information
US20110113116A1 (en) * 2009-11-11 2011-05-12 Jeff Burdette Method, computer program product and electronic device for hyper-local geo-targeting
US20120102219A1 (en) * 2010-10-20 2012-04-26 Quova, Inc. System and method for managing an internet domain based on the geographic location of an accessing user
US8527633B2 (en) 2011-01-06 2013-09-03 International Business Machines Corporation Techniques for addressing geographical location issues in computing environments
CN103716282A (en) * 2012-09-28 2014-04-09 北京新媒传信科技有限公司 Method and system for correcting IP library
US8756222B1 (en) 2012-11-06 2014-06-17 Google Inc. Systems and methods for confidence-based selection of hierarchical locations
US20140341033A1 (en) * 2013-05-16 2014-11-20 Power-All Networks Limited Transmission management device, system, and method
US20150019758A1 (en) * 2013-07-12 2015-01-15 Skyhook Wireless, Inc. Processing multiple network address observations
US9112667B1 (en) * 2010-08-31 2015-08-18 William Woodcock Geolocation
US9338046B2 (en) 2006-06-26 2016-05-10 Cisco Technology, Inc. Port pooling
US9451050B2 (en) 2011-04-22 2016-09-20 Go Daddy Operating Company, LLC Domain name spinning from geographic location data
US9501211B2 (en) 2014-04-17 2016-11-22 GoDaddy Operating Company, LLC User input processing for allocation of hosting server resources
US9529823B2 (en) 2011-09-07 2016-12-27 Microsoft Technology Licensing, Llc Geo-ontology extraction from entities with spatial and non-spatial attributes
WO2017015454A1 (en) * 2015-07-22 2017-01-26 Dynamic Network Services, Inc. Methods, systems, and apparatus for geographic location using trace routes
US9633128B2 (en) 2014-03-13 2017-04-25 Go Daddy Operating Company, LLC Lightweight web page generation
US9660933B2 (en) 2014-04-17 2017-05-23 Go Daddy Operating Company, LLC Allocating and accessing hosting server resources via continuous resource availability updates
US9779125B2 (en) 2014-11-14 2017-10-03 Go Daddy Operating Company, LLC Ensuring accurate domain name contact information
US9785663B2 (en) 2014-11-14 2017-10-10 Go Daddy Operating Company, LLC Verifying a correspondence address for a registrant
US9838301B2 (en) * 2011-06-30 2017-12-05 Neustar Ip Intelligence, Inc. System and method for predicting the geographic location of an internet protocol address
US9953105B1 (en) 2014-10-01 2018-04-24 Go Daddy Operating Company, LLC System and method for creating subdomains or directories for a domain name
US9967624B2 (en) * 2012-03-02 2018-05-08 Adobe Systems Incorporated Digital rights management using device proximity information
US20180176238A1 (en) 2016-12-15 2018-06-21 Sap Se Using frequency analysis in enterprise threat detection to detect intrusions in a computer system
US10164933B2 (en) 2014-12-19 2018-12-25 Go Daddy Operating Company, LLC System and method for domain name system restore points
US10482241B2 (en) 2016-08-24 2019-11-19 Sap Se Visualization of data distributed in multiple dimensions
US10530794B2 (en) 2017-06-30 2020-01-07 Sap Se Pattern creation in enterprise threat detection
US10534907B2 (en) 2016-12-15 2020-01-14 Sap Se Providing semantic connectivity between a java application server and enterprise threat detection system using a J2EE data
US10534908B2 (en) 2016-12-06 2020-01-14 Sap Se Alerts based on entities in security information and event management products
US10536476B2 (en) 2016-07-21 2020-01-14 Sap Se Realtime triggering framework
US10542016B2 (en) * 2016-08-31 2020-01-21 Sap Se Location enrichment in enterprise threat detection
US10552605B2 (en) 2016-12-16 2020-02-04 Sap Se Anomaly detection in enterprise threat detection
US10630705B2 (en) 2016-09-23 2020-04-21 Sap Se Real-time push API for log events in enterprise threat detection
US10659423B2 (en) 2014-12-19 2020-05-19 Go Daddy Operating Company, LLC System and method for modifying a domain name system template
US10673879B2 (en) 2016-09-23 2020-06-02 Sap Se Snapshot of a forensic investigation for enterprise threat detection
US10681064B2 (en) 2017-12-19 2020-06-09 Sap Se Analysis of complex relationships among information technology security-relevant entities using a network graph
US10764306B2 (en) 2016-12-19 2020-09-01 Sap Se Distributing cloud-computing platform content to enterprise threat detection systems
US20210105305A1 (en) * 2019-10-03 2021-04-08 Accenture Global Solutions Limited Privacy-secure edge-zone computing for secure-operation authorization
US10986111B2 (en) 2017-12-19 2021-04-20 Sap Se Displaying a series of events along a time axis in enterprise threat detection
US11093955B2 (en) * 2010-09-30 2021-08-17 The Nielsen Company (Us), Llc Methods and apparatus to measure mobile broadband market share
US20220058278A1 (en) * 2020-08-19 2022-02-24 Docusign, Inc. Using machine learning to bypass activities of a secure document workflow based on recipient profile
US20220058287A1 (en) * 2020-08-19 2022-02-24 Docusign, Inc. Modifying elements of a secure document workflow based on change in profile of recipient
US11470094B2 (en) 2016-12-16 2022-10-11 Sap Se Bi-directional content replication logic for enterprise threat detection
US11599662B2 (en) 2020-08-19 2023-03-07 Docusign, Inc. Bypassing elements of a secure document workflow based on identity of recipient

Families Citing this family (550)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
US7690043B2 (en) 1994-12-19 2010-03-30 Legal Igaming, Inc. System and method for connecting gaming devices to a network for remote play
US9530150B2 (en) * 1996-01-19 2016-12-27 Adcension, Llc Compensation model for network services
US5823879A (en) 1996-01-19 1998-10-20 Sheldon F. Goldberg Network gaming system
US6264560B1 (en) 1996-01-19 2001-07-24 Sheldon F. Goldberg Method and system for playing games on a network
US20090012864A1 (en) * 2007-07-02 2009-01-08 Goldberg Sheldon F Compensation model for network services
US7268700B1 (en) 1998-01-27 2007-09-11 Hoffberg Steven M Mobile communication device
US7966078B2 (en) 1999-02-01 2011-06-21 Steven Hoffberg Network media appliance system and method
US20010032029A1 (en) * 1999-07-01 2001-10-18 Stuart Kauffman System and method for infrastructure design
US8085813B2 (en) * 1999-10-28 2011-12-27 Lightwaves Systems, Inc. Method for routing data packets using an IP address based on geo position
US6980566B2 (en) * 2000-03-10 2005-12-27 Lightwaves Systems, Inc. Method for routing data packets using an IP address based in GEO position
US9900734B2 (en) 1999-10-28 2018-02-20 Lightwaves Systems, Inc. Method for routing data packets using an IP address based on geo position
US8601373B1 (en) 1999-11-16 2013-12-03 Ebay Inc. Network-based sales system with customizable user interface
US7630721B2 (en) 2000-06-27 2009-12-08 Ortiz & Associates Consulting, Llc Systems, methods and apparatuses for brokering data between wireless devices and data rendering devices
US7812856B2 (en) 2000-10-26 2010-10-12 Front Row Technologies, Llc Providing multiple perspectives of a venue activity to electronic wireless hand held devices
DE10036712A1 (en) * 2000-07-27 2002-02-28 Active Mining Ag Computer-assisted method for evaluating computer processes having characteristic features by weighting individual values using feature tree
US20020016831A1 (en) * 2000-08-07 2002-02-07 Vidius Inc. Apparatus and method for locating of an internet user
US9130954B2 (en) 2000-09-26 2015-09-08 Brocade Communications Systems, Inc. Distributed health check for global server load balancing
US7454500B1 (en) 2000-09-26 2008-11-18 Foundry Networks, Inc. Global server load balancing
US7657629B1 (en) 2000-09-26 2010-02-02 Foundry Networks, Inc. Global server load balancing
US9311499B2 (en) * 2000-11-13 2016-04-12 Ron M. Redlich Data security system and with territorial, geographic and triggering event protocol
US7296088B1 (en) * 2000-11-17 2007-11-13 Microsoft Corporation System and method for determining the geographic location of internet hosts
US6947978B2 (en) * 2000-12-29 2005-09-20 The United States Of America As Represented By The Director, National Security Agency Method for geolocating logical network addresses
US7774453B2 (en) * 2001-01-31 2010-08-10 International Business Machines Corporation System and method for handling location information
US7039689B2 (en) * 2001-01-31 2006-05-02 Telcordia Technologies, Inc. Method and system for determining geographical regions of hosts in a network
US7983349B2 (en) 2001-03-20 2011-07-19 Lightwaves Systems, Inc. High bandwidth data transport system
US8766773B2 (en) 2001-03-20 2014-07-01 Lightwaves Systems, Inc. Ultra wideband radio frequency identification system, method, and apparatus
US7545868B2 (en) 2001-03-20 2009-06-09 Lightwaves Systems, Inc. High bandwidth data transport system
US7895616B2 (en) * 2001-06-06 2011-02-22 Sony Corporation Reconstitution of program streams split across multiple packet identifiers
US7350082B2 (en) * 2001-06-06 2008-03-25 Sony Corporation Upgrading of encryption
US7151831B2 (en) * 2001-06-06 2006-12-19 Sony Corporation Partial encryption and PID mapping
US6990609B2 (en) * 2001-06-12 2006-01-24 Sun Microsystems, Inc. System and method for isolating faults in a network
US7058844B2 (en) * 2001-06-15 2006-06-06 Sun Microsystems, Inc. System and method for rapid fault isolation in a storage area network
US20020199018A1 (en) * 2001-06-21 2002-12-26 International Business Machines Corporation Maping physical locations to web sites
CA2455639C (en) * 2001-07-20 2016-08-16 Fairmarket, Inc. Automated listing management
US7107619B2 (en) * 2001-08-31 2006-09-12 International Business Machines Corporation System and method for the detection of and reaction to denial of service attacks
US20040205118A1 (en) * 2001-09-13 2004-10-14 Allen Yu Method and system for generalized localization of electronic documents
JP4346439B2 (en) * 2001-10-05 2009-10-21 タイコ ヘルスケア グループ エルピー Inclined top anvil for surgical fastener devices
US20030115258A1 (en) * 2001-12-13 2003-06-19 International Business Machines Corporation Time zone difference based locality estimation between web clients and E-business servers
US20030126209A1 (en) * 2001-12-28 2003-07-03 Inventec Corporation Network customer service and method for the same
US7242773B2 (en) * 2002-09-09 2007-07-10 Sony Corporation Multiple partial encryption using retuning
US7292691B2 (en) * 2002-01-02 2007-11-06 Sony Corporation Progressive video refresh slice detection
US7215770B2 (en) * 2002-01-02 2007-05-08 Sony Corporation System and method for partially encrypted multimedia stream
US7376233B2 (en) * 2002-01-02 2008-05-20 Sony Corporation Video slice and active region based multiple partial encryption
US7233669B2 (en) * 2002-01-02 2007-06-19 Sony Corporation Selective encryption to enable multiple decryption keys
US7765567B2 (en) * 2002-01-02 2010-07-27 Sony Corporation Content replacement by PID mapping
US7292690B2 (en) * 2002-01-02 2007-11-06 Sony Corporation Video scene change detection
US7155012B2 (en) * 2002-01-02 2006-12-26 Sony Corporation Slice mask and moat pattern partial encryption
US7823174B2 (en) * 2002-01-02 2010-10-26 Sony Corporation Macro-block based content replacement by PID mapping
US7302059B2 (en) * 2002-01-02 2007-11-27 Sony Corporation Star pattern partial encryption
US7917623B2 (en) * 2002-01-03 2011-03-29 Aspect Software, Inc. Method of allocating data communication sessions based upon user information
US7836160B2 (en) * 2002-01-08 2010-11-16 Verizon Services Corp. Methods and apparatus for wiretapping IP-based telephone lines
US7873985B2 (en) * 2002-01-08 2011-01-18 Verizon Services Corp. IP based security applications using location, port and/or device identifier information
US7843934B2 (en) * 2002-01-08 2010-11-30 Verizon Services Corp. Methods and apparatus for providing emergency telephone service to IP-based telephone users
US7843923B2 (en) * 2002-01-08 2010-11-30 Verizon Services Corp. Methods and apparatus for determining the port and/or physical location of an IP device and for using that information
US7320070B2 (en) * 2002-01-08 2008-01-15 Verizon Services Corp. Methods and apparatus for protecting against IP address assignments based on a false MAC address
US7107048B2 (en) * 2002-01-25 2006-09-12 Chandler Larry S Inversion-conforming data sets processing
US20060059251A1 (en) * 2002-05-01 2006-03-16 Cunha Gary D Method and system for request management processing
US7530084B2 (en) * 2002-05-28 2009-05-05 Sony Corporation Method and apparatus for synchronizing dynamic graphics
US20090180025A1 (en) * 2002-05-28 2009-07-16 Sony Corporation Method and apparatus for overlaying graphics on video
AU2003239916A1 (en) * 2002-06-03 2003-12-19 Sevenspace System and method for reliable delivery of event information
US7162524B2 (en) * 2002-06-21 2007-01-09 International Business Machines Corporation Gapless delivery and durable subscriptions in a content-based publish/subscribe system
US8489435B2 (en) * 2002-07-02 2013-07-16 Amadeus S.A.S. Method and device for storing and accessing data in a computer travel reservation system
US20050114484A1 (en) * 2002-07-09 2005-05-26 Wilson Richard P. Richard and Preston super network, "The Super Net"
US7086061B1 (en) 2002-08-01 2006-08-01 Foundry Networks, Inc. Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics
US7574508B1 (en) 2002-08-07 2009-08-11 Foundry Networks, Inc. Canonical name (CNAME) handling for global server load balancing
US8818896B2 (en) * 2002-09-09 2014-08-26 Sony Corporation Selective encryption with coverage encryption
US20140256422A9 (en) * 2002-10-09 2014-09-11 Michael W. Saunders System and Method for Connecting Gaming Devices to a Network for Remote Play
US9865126B2 (en) 2002-10-09 2018-01-09 Zynga Inc. System and method for connecting gaming devices to a network for remote play
AU2003299668A1 (en) * 2002-12-18 2004-07-22 Emc Corporation Resource allocation aware queuing of requests for media resources
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US20040167981A1 (en) * 2003-02-25 2004-08-26 Douglas Christopher Paul Method and system for monitoring relationships between content devices in a content delivery network
US7131032B2 (en) * 2003-03-13 2006-10-31 Sun Microsystems, Inc. Method, system, and article of manufacture for fault determination
US7409702B2 (en) * 2003-03-20 2008-08-05 Sony Corporation Auxiliary program association table
US7292692B2 (en) * 2003-03-25 2007-11-06 Sony Corporation Content scrambling with minimal impact on legacy devices
US7536695B2 (en) * 2003-03-28 2009-05-19 Microsoft Corporation Architecture and system for location awareness
JP5068996B2 (en) * 2003-04-04 2012-11-07 ヤフー! インコーポレイテッド Search result generation system incorporating subdomain hint search and subdomain sponsored result provision
US7313607B1 (en) * 2003-05-21 2007-12-25 At&T Corp. Method and apparatus of hierarchical node partitioning for address planning in PNNI networks
TWI251157B (en) * 2003-06-20 2006-03-11 Hon Hai Prec Ind Co Ltd Event logging system and method
DE10330596A1 (en) * 2003-07-07 2005-02-03 Siemens Ag Assignment of station addresses to communication users in a bus system
US20050036067A1 (en) * 2003-08-05 2005-02-17 Ryal Kim Annon Variable perspective view of video images
US20050033653A1 (en) * 2003-08-07 2005-02-10 Ian Eisenberg Electronic mail card purchase verification
GB2418276A (en) * 2003-08-13 2006-03-22 Whereonearth Ltd Determining a likely geographical location
US20050066357A1 (en) * 2003-09-22 2005-03-24 Ryal Kim Annon Modifying content rating
US9584360B2 (en) 2003-09-29 2017-02-28 Foundry Networks, Llc Global server load balancing support for private VIP addresses
US8229888B1 (en) * 2003-10-15 2012-07-24 Radix Holdings, Llc Cross-device playback with synchronization of consumption state
US20050097596A1 (en) * 2003-10-31 2005-05-05 Pedlow Leo M.Jr. Re-encrypted delivery of video-on-demand content
US7853980B2 (en) 2003-10-31 2010-12-14 Sony Corporation Bi-directional indices for trick mode video-on-demand
US20050097597A1 (en) * 2003-10-31 2005-05-05 Pedlow Leo M.Jr. Hybrid storage of video on demand content
US7263187B2 (en) * 2003-10-31 2007-08-28 Sony Corporation Batch mode session-based encryption of video on demand content
US7343013B2 (en) * 2003-12-16 2008-03-11 Sony Corporation Composite session-based encryption of video on demand content
US7774292B2 (en) * 2003-11-10 2010-08-10 Conversive, Inc. System for conditional answering of requests
US20050102702A1 (en) * 2003-11-12 2005-05-12 Candelore Brant L. Cablecard with content manipulation
US20050234735A1 (en) * 2003-11-26 2005-10-20 Williams Jim C Digital rights management using proximity testing
US20060206432A1 (en) * 2003-11-26 2006-09-14 Russell John C P Digital rights management using network topology testing
US8271495B1 (en) 2003-12-17 2012-09-18 Topix Llc System and method for automating categorization and aggregation of content from network sites
US7814089B1 (en) 2003-12-17 2010-10-12 Topix Llc System and method for presenting categorized content on a site using programmatic and manual selection of content items
JP2005190068A (en) * 2003-12-25 2005-07-14 Fanuc Ltd Software download system for controller
US8954420B1 (en) 2003-12-31 2015-02-10 Google Inc. Methods and systems for improving a search ranking using article information
WO2005065038A2 (en) * 2004-01-09 2005-07-21 Npx Technologies Ltd. Detecting relayed communications
US20050169473A1 (en) * 2004-02-03 2005-08-04 Candelore Brant L. Multiple selective encryption with DRM
US8126999B2 (en) 2004-02-06 2012-02-28 Microsoft Corporation Network DNA
US7640288B2 (en) * 2004-03-15 2009-12-29 Microsoft Corporation Schema for location awareness
US8099407B2 (en) 2004-03-31 2012-01-17 Google Inc. Methods and systems for processing media files
US7333976B1 (en) 2004-03-31 2008-02-19 Google Inc. Methods and systems for processing contact information
US8161053B1 (en) 2004-03-31 2012-04-17 Google Inc. Methods and systems for eliminating duplicate events
US7941439B1 (en) 2004-03-31 2011-05-10 Google Inc. Methods and systems for information capture
US8631076B1 (en) 2004-03-31 2014-01-14 Google Inc. Methods and systems for associating instant messenger events
US8386728B1 (en) 2004-03-31 2013-02-26 Google Inc. Methods and systems for prioritizing a crawl
US8346777B1 (en) 2004-03-31 2013-01-01 Google Inc. Systems and methods for selectively storing event data
US8275839B2 (en) * 2004-03-31 2012-09-25 Google Inc. Methods and systems for processing email messages
US7496651B1 (en) * 2004-05-06 2009-02-24 Foundry Networks, Inc. Configurable geographic prefixes for global server load balancing
US7584301B1 (en) 2004-05-06 2009-09-01 Foundry Networks, Inc. Host-level policies for global server load balancing
US7231405B2 (en) * 2004-05-08 2007-06-12 Doug Norman, Interchange Corp. Method and apparatus of indexing web pages of a web site for geographical searchine based on user location
DE102004027292A1 (en) * 2004-06-04 2005-12-29 Siemens Ag Procedures for determining position data
US8346593B2 (en) 2004-06-30 2013-01-01 Experian Marketing Solutions, Inc. System, method, and software for prediction of attitudinal and message responsiveness
US20060041451A1 (en) * 2004-08-04 2006-02-23 Jennifer Hessel Lighting simulation for beauty products
US7423977B1 (en) 2004-08-23 2008-09-09 Foundry Networks Inc. Smoothing algorithm for round trip time (RTT) measurements
US7590589B2 (en) 2004-09-10 2009-09-15 Hoffberg Steven M Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference
US7606687B2 (en) * 2004-09-14 2009-10-20 Friendster, Inc. Proximity search methods using tiles to represent geographical zones
US8996603B2 (en) * 2004-09-16 2015-03-31 Cisco Technology, Inc. Method and apparatus for user domain based white lists
US20060069782A1 (en) * 2004-09-16 2006-03-30 Michael Manning Method and apparatus for location-based white lists in a telecommunications network
US7497374B2 (en) * 2004-09-17 2009-03-03 Digital Envoy, Inc. Fraud risk advisor
US20060064374A1 (en) * 2004-09-17 2006-03-23 David Helsper Fraud risk advisor
US8732004B1 (en) 2004-09-22 2014-05-20 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
EP1820147A4 (en) * 2004-11-03 2009-09-23 Motion Picture Ass Of America Digital rights management using network topology testing
US7636785B2 (en) * 2004-11-16 2009-12-22 Microsoft Corporation Heuristic determination of user origin
US7895617B2 (en) * 2004-12-15 2011-02-22 Sony Corporation Content substitution editor
US8041190B2 (en) 2004-12-15 2011-10-18 Sony Corporation System and method for the creation, synchronization and delivery of alternate content
US7996351B1 (en) 2004-12-16 2011-08-09 Apple Inc. Automated estimation of a country where a client computer is configured to operate
US8265991B1 (en) 2004-12-16 2012-09-11 Apple Inc. Automated determination of applicability and value of discounts for a purchase order
US20060205489A1 (en) * 2004-12-30 2006-09-14 Jerome Carpenter Methods for game player identification
US20060167765A1 (en) * 2005-01-12 2006-07-27 Lacey Dominic J Methods of online fund raising over a network
US7904908B2 (en) 2005-03-01 2011-03-08 Csc Holdings, Inc. Methods and systems for distributed processing on consumer devices
US7574530B2 (en) * 2005-03-10 2009-08-11 Microsoft Corporation Method and system for web resource location classification and detection
JP2006285522A (en) * 2005-03-31 2006-10-19 Ntt Docomo Inc Task selection support device and task selection support method
US7353034B2 (en) 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
WO2006108069A2 (en) * 2005-04-06 2006-10-12 Google, Inc. Searching through content which is accessible through web-based forms
US20060259469A1 (en) * 2005-05-12 2006-11-16 Fu-Sheng Chiu Intelligent adaptive programming based on collected dynamic market data and user feedback
US7961717B2 (en) * 2005-05-12 2011-06-14 Iposi, Inc. System and methods for IP and VoIP device location determination
US20060259357A1 (en) * 2005-05-12 2006-11-16 Fu-Sheng Chiu Intelligent dynamic market data collection and advertising delivery system
US20070011176A1 (en) * 2005-07-05 2007-01-11 Vishnubhotla Prasad R Business reporting under system failures
US8185547B1 (en) * 2005-07-29 2012-05-22 Teradata Us, Inc. Data analysis based on manipulation of large matrices on a persistent storage medium
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
AU2006304222B2 (en) * 2005-10-13 2011-04-07 Vonage Network Llc Method and system for detecting a change in device attachment
US8924459B2 (en) 2005-10-21 2014-12-30 Cisco Technology, Inc. Support for WISPr attributes in a TAL/CAR PWLAN environment
CA2619642C (en) * 2005-10-21 2014-07-29 T-Mobile Usa, Inc. System and method for determining device location in an ip-based wireless telecommunications network
US20070100690A1 (en) * 2005-11-02 2007-05-03 Daniel Hopkins System and method for providing targeted advertisements in user requested multimedia content
US7812718B1 (en) 2005-11-21 2010-10-12 The Hong Kong University Of Science And Technology Distributed position estimation for wireless sensor networks
US7930647B2 (en) * 2005-12-11 2011-04-19 Topix Llc System and method for selecting pictures for presentation with text content
US7685144B1 (en) 2005-12-29 2010-03-23 Google Inc. Dynamically autocompleting a data entry
US9262446B1 (en) * 2005-12-29 2016-02-16 Google Inc. Dynamically ranking entries in a personal data book
US7634463B1 (en) * 2005-12-29 2009-12-15 Google Inc. Automatically generating and maintaining an address book
US8584226B2 (en) 2006-01-26 2013-11-12 Iorhythm, Inc. Method and apparatus for geographically regulating inbound and outbound network communications
US7464084B2 (en) * 2006-01-30 2008-12-09 International Business Machines Corporation Method for performing an inexact query transformation in a heterogeneous environment
US7743090B1 (en) 2006-02-08 2010-06-22 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for infrastructure validation
JP2007215781A (en) * 2006-02-16 2007-08-30 Sega Corp Communication game system, game control program, and storage medium
US8185921B2 (en) 2006-02-28 2012-05-22 Sony Corporation Parental control of displayed content using closed captioning
US7555464B2 (en) * 2006-03-01 2009-06-30 Sony Corporation Multiple DRM management
US9953097B2 (en) * 2006-03-16 2018-04-24 Ebay Inc. System and method for managing network traffic routing
US7606875B2 (en) * 2006-03-28 2009-10-20 Microsoft Corporation Detecting serving area of a web resource
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US7860825B2 (en) * 2006-05-08 2010-12-28 Palm, Inc. Method for synchronizing software application and user data for asynchronous client-server and peer to peer computer networks
US20070271339A1 (en) * 2006-05-16 2007-11-22 Barry Katz Telephone-based personnel tracking system with authorization control and reporting
US8229455B2 (en) 2006-07-07 2012-07-24 Skyhook Wireless, Inc. System and method of gathering and caching WLAN packet information to improve position estimates of a WLAN positioning device
US20080046511A1 (en) * 2006-08-15 2008-02-21 Richard Skrenta System and Method for Conducting an Electronic Message Forum
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US8548991B1 (en) * 2006-09-29 2013-10-01 Google Inc. Personalized browsing activity displays
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US8953567B2 (en) 2006-10-20 2015-02-10 T—Mobile USA, Inc. System and method for utilizing IP-based wireless telecommunications client location data
EP2084917B1 (en) 2006-10-20 2019-05-01 T-Mobile USA, Inc. System and method for determining a subscriber's zone information
US7856234B2 (en) 2006-11-07 2010-12-21 Skyhook Wireless, Inc. System and method for estimating positioning error within a WLAN-based positioning system
US9405732B1 (en) 2006-12-06 2016-08-02 Topix Llc System and method for displaying quotations
US20080140727A1 (en) * 2006-12-07 2008-06-12 Karl Christian Pschierer Method and apparatus for managing geographic information system data
US8554868B2 (en) 2007-01-05 2013-10-08 Yahoo! Inc. Simultaneous sharing communication interface
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US8606666B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8768961B2 (en) * 2007-03-09 2014-07-01 At&T Labs, Inc. System and method of processing database queries
US7640105B2 (en) * 2007-03-13 2009-12-29 Certus View Technologies, LLC Marking system and method with location and/or time tracking
US7747645B2 (en) * 2007-03-17 2010-06-29 Informed Control Inc. System and method for calendar-based anomalous access detection
US7788252B2 (en) * 2007-03-28 2010-08-31 Yahoo, Inc. System for determining local intent in a search query
US7774348B2 (en) * 2007-03-28 2010-08-10 Yahoo, Inc. System for providing geographically relevant content to a search query with local intent
US7805450B2 (en) 2007-03-28 2010-09-28 Yahoo, Inc. System for determining the geographic range of local intent in a search query
US8621064B2 (en) * 2007-03-28 2013-12-31 Yahoo! Inc. System and method for associating a geographic location with an Internet protocol address
US8024454B2 (en) * 2007-03-28 2011-09-20 Yahoo! Inc. System and method for associating a geographic location with an internet protocol address
US7730193B2 (en) * 2007-04-03 2010-06-01 Computer Associates Think, Inc. Automated time zone based grouping
WO2008127288A1 (en) 2007-04-12 2008-10-23 Experian Information Solutions, Inc. Systems and methods for determining thin-file records and determining thin-file risk levels
US20080281697A1 (en) * 2007-05-11 2008-11-13 Verizon Services Organization Inc. Systems and methods for using video services records to provide targeted marketing services
US8626788B2 (en) * 2007-06-13 2014-01-07 Continuum Loop Inc. Method for determining relative ranking data in a broker mediated geospatial information service environment
US8533180B2 (en) * 2007-06-13 2013-09-10 The Boeing Company Method and apparatus for enhancing a geographic information system database with operational data
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
US7739169B2 (en) * 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US8028090B2 (en) * 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
WO2009007965A2 (en) * 2007-07-09 2009-01-15 Technion Research & Development Foundation Ltd Routing methods for multiple geographical entities
US7958228B2 (en) * 2007-07-11 2011-06-07 Yahoo! Inc. Behavioral predictions based on network activity locations
US20090063646A1 (en) * 2007-09-04 2009-03-05 Nixle, Llc System and method for collecting and organizing popular near real-time data in a virtual geographic grid
US8301574B2 (en) 2007-09-17 2012-10-30 Experian Marketing Solutions, Inc. Multimedia engagement study
US8364816B2 (en) * 2007-10-12 2013-01-29 Microsoft Corporation Mapping network addresses to geographical locations
US9037694B2 (en) * 2007-11-06 2015-05-19 Neustar Ip Intelligence, Inc. Method and system for determining the geographic location of a network block
US7962404B1 (en) 2007-11-07 2011-06-14 Experian Information Solutions, Inc. Systems and methods for determining loan opportunities
US7996521B2 (en) 2007-11-19 2011-08-09 Experian Marketing Solutions, Inc. Service for mapping IP addresses to user segments
US8055792B2 (en) * 2007-11-30 2011-11-08 Quova, Inc. Method and system for evaluating and selecting traceroutes to be used in determining the geographic location of a network block
US8566431B2 (en) * 2008-01-16 2013-10-22 Razer (Asia-Pacific) Pte. Ltd. Identification device and method for device identification
US9659268B2 (en) * 2008-02-12 2017-05-23 CertusVies Technologies, LLC Ticket approval system for and method of performing quality control in field service applications
US20090216642A1 (en) * 2008-02-25 2009-08-27 Bering Media Incorporated Privacy-enhanced internet advertising system
US8825792B1 (en) * 2008-03-11 2014-09-02 United Services Automobile Association (Usaa) Systems and methods for online brand continuity
US8073959B2 (en) * 2008-03-28 2011-12-06 Microsoft Corporation Automatically detecting whether a computer is connected to a public or private network
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US7543045B1 (en) 2008-05-28 2009-06-02 International Business Machines Corporation System and method for estimating the geographical location and proximity of network devices and their directly connected neighbors
US20090296990A1 (en) * 2008-05-30 2009-12-03 United Parcel Service Of America, Inc. Evaluating driver walk distances and building types using overhead imagery
US9473626B2 (en) 2008-06-27 2016-10-18 Certusview Technologies, Llc Apparatus and methods for evaluating a quality of a locate operation for underground utility
US9208458B2 (en) * 2008-10-02 2015-12-08 Certusview Technologies, Llc Methods and apparatus for analyzing locate and marking operations with respect to facilities maps
US8612271B2 (en) 2008-10-02 2013-12-17 Certusview Technologies, Llc Methods and apparatus for analyzing locate and marking operations with respect to environmental landmarks
US20090327024A1 (en) * 2008-06-27 2009-12-31 Certusview Technologies, Llc Methods and apparatus for quality assessment of a field service operation
US9208464B2 (en) * 2008-10-02 2015-12-08 Certusview Technologies, Llc Methods and apparatus for analyzing locate and marking operations with respect to historical information
US9912740B2 (en) 2008-06-30 2018-03-06 Amazon Technologies, Inc. Latency measurement in resource requests
US9407681B1 (en) 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
US20100011048A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Geospatial Query Region To A Network Identifier
US20100010975A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Query Region To A Network Identifier
US20100010992A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Location Information To A Network Identifier
US8060406B2 (en) * 2008-09-26 2011-11-15 Microsoft Corporation Predictive geo-temporal advertisement targeting
US8620726B2 (en) * 2008-10-02 2013-12-31 Certusview Technologies, Llc Methods and apparatus for analyzing locate and marking operations by comparing locate information and marking information
US8600526B2 (en) * 2008-10-02 2013-12-03 Certusview Technologies, Llc Marking device docking stations having mechanical docking and methods of using same
US20100088399A1 (en) * 2008-10-03 2010-04-08 Yoel Gluck Enterprise security setup with prequalified and authenticated peer group enabled for secure DHCP and secure ARP/RARP
US20100088748A1 (en) * 2008-10-03 2010-04-08 Yoel Gluck Secure peer group network and method thereof by locking a mac address to an entity at physical layer
US8412593B1 (en) 2008-10-07 2013-04-02 LowerMyBills.com, Inc. Credit card matching
US8060582B2 (en) * 2008-10-22 2011-11-15 Google Inc. Geocoding personal information
BRPI0921124A2 (en) * 2008-11-06 2016-09-13 Visa Int Service Ass system for authenticating a consumer, computer implemented method, computer readable medium, and server computer.
US8521880B1 (en) 2008-11-17 2013-08-27 Amazon Technologies, Inc. Managing content delivery network service providers
US8073940B1 (en) 2008-11-17 2011-12-06 Amazon Technologies, Inc. Managing content delivery network service providers
US8732309B1 (en) 2008-11-17 2014-05-20 Amazon Technologies, Inc. Request routing utilizing cost information
US8122098B1 (en) 2008-11-17 2012-02-21 Amazon Technologies, Inc. Managing content delivery network service providers by a content broker
US20100146114A1 (en) * 2008-12-04 2010-06-10 Morris Robert P Methods, Systems, And Computer Program Products For Accessing A Resource Based On Metadata Associated With A Location On A Map
US20100146132A1 (en) * 2008-12-04 2010-06-10 Morris Robert P Methods, Systems, And Computer Program Products For Accessing A Resource Having A Network Address Associated With A Location On A Map
US20100145963A1 (en) * 2008-12-04 2010-06-10 Morris Robert P Methods, Systems, And Computer Program Products For Resolving A Network Identifier Based On A Geospatial Domain Space Harmonized With A Non-Geospatial Domain Space
US9336528B2 (en) * 2008-12-16 2016-05-10 Jeffrey Beaton System and method for overlay advertising and purchasing utilizing on-line video or streaming media
US20100161732A1 (en) * 2008-12-19 2010-06-24 Morris Robert P Methods, Systems, And Computer Program Products For Maintaining Consistency Between Non-Geospatial And Geospatial Network Directory Systems
US20100162230A1 (en) * 2008-12-24 2010-06-24 Yahoo! Inc. Distributed computing system for large-scale data handling
US8280996B2 (en) * 2009-01-29 2012-10-02 The Nielsen Company (Us), Llc Methods and apparatus to collect broadband market data
US9129293B2 (en) * 2009-01-29 2015-09-08 The Nielsen Company (Us), Llc Methods and apparatus to measure market statistics
US20100198865A1 (en) * 2009-01-30 2010-08-05 Bering Media Incorporated System and method for detecting, managing, and preventing location inference in advertising over a communications network
CA2692110C (en) * 2009-02-11 2015-10-27 Certusview Technologies, Llc Providing a process guide to a locate technician
CA2897462A1 (en) * 2009-02-11 2010-05-04 Certusview Technologies, Llc Management system, and associated methods and apparatus, for providing automatic assessment of a locate operation
US7933272B2 (en) * 2009-03-11 2011-04-26 Deep River Systems, Llc Methods and systems for resolving a first node identifier in a first identifier domain space to a second node identifier in a second identifier domain space
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8521851B1 (en) 2009-03-27 2013-08-27 Amazon Technologies, Inc. DNS query processing using resource identifiers specifying an application broker
US8639920B2 (en) 2009-05-11 2014-01-28 Experian Marketing Solutions, Inc. Systems and methods for providing anonymized user profile data
US8718592B2 (en) 2009-05-15 2014-05-06 T-Mobile Usa, Inc. Mobile device location determination using micronetworks
US8239337B2 (en) * 2009-05-30 2012-08-07 Cisco Technology, Inc. Network device proximity data import based on weighting factor
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
CA2706195A1 (en) * 2009-06-25 2010-09-01 Certusview Technologies, Llc Methods and apparatus for assessing locate request tickets
US8022877B2 (en) 2009-07-16 2011-09-20 Skyhook Wireless, Inc. Systems and methods for using a satellite positioning system to detect moved WLAN access points
US8977705B2 (en) * 2009-07-27 2015-03-10 Verisign, Inc. Method and system for data logging and analysis
US20110055571A1 (en) * 2009-08-24 2011-03-03 Yoel Gluck Method and system for preventing lower-layer level attacks in a network
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US8662997B1 (en) 2009-09-30 2014-03-04 Amazon Technologies, Inc. Systems and methods for in-game provisioning of content
US9770654B1 (en) * 2009-09-30 2017-09-26 Amazon Technologies, Inc. Cross device operation of games
US8433771B1 (en) 2009-10-02 2013-04-30 Amazon Technologies, Inc. Distribution network with forward resource propagation
US9960967B2 (en) * 2009-10-21 2018-05-01 A10 Networks, Inc. Determining an application delivery server based on geo-location information
US10581834B2 (en) 2009-11-02 2020-03-03 Early Warning Services, Llc Enhancing transaction authentication with privacy and security enhanced internet geolocation and proximity
US8806592B2 (en) 2011-01-21 2014-08-12 Authentify, Inc. Method for secure user and transaction authentication and risk management
US8341236B1 (en) * 2009-11-02 2012-12-25 Ravi Ganesan Privacy and security enhanced internet geolocation
US10587683B1 (en) 2012-11-05 2020-03-10 Early Warning Services, Llc Proximity in privacy and security enhanced internet geolocation
CN102656579A (en) * 2009-11-04 2012-09-05 塞德克西斯公司 Internet infrastructure survey
US8837360B1 (en) * 2009-12-11 2014-09-16 Google Inc. Determining geographic location of network hosts
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
AU2011210554B2 (en) * 2010-01-29 2014-10-02 Lexisnexis Risk Data Management Inc. Statistical record linkage calibration for geographic proximity matching
US20110199964A1 (en) * 2010-02-12 2011-08-18 Jeyhan Karaoguz Method and system for determining a location of an access point based on association of the access point with a communication device having a known location
US8972397B2 (en) * 2010-03-11 2015-03-03 Microsoft Corporation Auto-detection of historical search context
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8589580B2 (en) * 2010-06-28 2013-11-19 Hulu, LLC Method and apparatus for geofiltering by content
US8554631B1 (en) * 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US9152727B1 (en) 2010-08-23 2015-10-06 Experian Marketing Solutions, Inc. Systems and methods for processing consumer information for targeted marketing applications
US9609619B2 (en) 2010-08-31 2017-03-28 William E. Woodcock, IV Geolocation
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US8577992B1 (en) 2010-09-28 2013-11-05 Amazon Technologies, Inc. Request routing management based on network components
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US10097398B1 (en) 2010-09-28 2018-10-09 Amazon Technologies, Inc. Point of presence management in request routing
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
US8819283B2 (en) 2010-09-28 2014-08-26 Amazon Technologies, Inc. Request routing in a networked environment
US8549148B2 (en) 2010-10-15 2013-10-01 Brocade Communications Systems, Inc. Domain name system security extensions (DNSSEC) for global server load balancing
US8452874B2 (en) 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US8874713B1 (en) * 2011-02-18 2014-10-28 Google Inc. Location correction
US8458069B2 (en) * 2011-03-04 2013-06-04 Brighterion, Inc. Systems and methods for adaptive identification of sources of fraud
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
US20120317087A1 (en) * 2011-06-07 2012-12-13 Microsoft Corporation Location-Aware Search Ranking
IL300140B2 (en) 2011-07-12 2024-02-01 Snap Inc Methods and systems of providing visual content editing functions
US8559975B2 (en) 2011-07-22 2013-10-15 Microsoft Corporation Location determination based on weighted received signal strengths
US8683008B1 (en) 2011-08-04 2014-03-25 Google Inc. Management of pre-fetched mapping data incorporating user-specified locations
US10108757B1 (en) * 2011-08-15 2018-10-23 Adaptrum, Inc. System and method for spectrum usage databases for cognitive radio
US8599009B2 (en) 2011-08-16 2013-12-03 Elwha Llc Systematic distillation of status data relating to regimen compliance
US10140125B1 (en) * 2011-08-23 2018-11-27 RaGaPa, Inc. Methods and apparatus for interactive content injection
US9037852B2 (en) 2011-09-02 2015-05-19 Ivsc Ip Llc System and method for independent control of for-hire vehicles
US20130060721A1 (en) 2011-09-02 2013-03-07 Frias Transportation Infrastructure, Llc Systems and methods for pairing of for-hire vehicle meters and medallions
US8280414B1 (en) 2011-09-26 2012-10-02 Google Inc. Map tile data pre-fetching based on mobile device generated event analysis
US8204966B1 (en) * 2011-09-26 2012-06-19 Google Inc. Map tile data pre-fetching based on user activity analysis
US10270755B2 (en) 2011-10-03 2019-04-23 Verisign, Inc. Authenticated name resolution
US8959082B2 (en) 2011-10-31 2015-02-17 Elwha Llc Context-sensitive query enrichment
US9172716B2 (en) 2011-11-08 2015-10-27 Verisign, Inc System and method for detecting DNS traffic anomalies
US9275374B1 (en) 2011-11-15 2016-03-01 Google Inc. Method and apparatus for pre-fetching place page data based upon analysis of user activities
US8886715B1 (en) 2011-11-16 2014-11-11 Google Inc. Dynamically determining a tile budget when pre-fetching data in a client device
US9063951B1 (en) 2011-11-16 2015-06-23 Google Inc. Pre-fetching map data based on a tile budget
US8711181B1 (en) 2011-11-16 2014-04-29 Google Inc. Pre-fetching map data using variable map tile radius
US9143541B1 (en) 2011-11-17 2015-09-22 Google Inc. Systems, computer-implemented methods, and computer-readable media to target internet-based services on a geographic location
US9305107B2 (en) 2011-12-08 2016-04-05 Google Inc. Method and apparatus for pre-fetching place page data for subsequent display on a mobile computing device
US9197713B2 (en) 2011-12-09 2015-11-24 Google Inc. Method and apparatus for pre-fetching remote resources for subsequent display on a mobile computing device
US9389088B2 (en) 2011-12-12 2016-07-12 Google Inc. Method of pre-fetching map data for rendering and offline routing
US8803920B2 (en) 2011-12-12 2014-08-12 Google Inc. Pre-fetching map tile data along a route
US9413805B2 (en) * 2011-12-15 2016-08-09 Geocomply Global Inc. Geolocation engine
US10021179B1 (en) 2012-02-21 2018-07-10 Amazon Technologies, Inc. Local resource delivery network
US11734712B2 (en) 2012-02-24 2023-08-22 Foursquare Labs, Inc. Attributing in-store visits to media consumption based on data collected from user devices
US8972357B2 (en) 2012-02-24 2015-03-03 Placed, Inc. System and method for data collection to validate location data
US9026145B1 (en) 2012-03-23 2015-05-05 Google Inc. Systems and methods for mapping IP-addresses to geolocations
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US9197595B1 (en) 2012-05-04 2015-11-24 Google Inc. Evaluating IP-location mapping data
US8990327B2 (en) * 2012-06-04 2015-03-24 International Business Machines Corporation Location estimation of social network users
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
GB201211742D0 (en) * 2012-07-03 2012-08-15 Eaton Power Quality S A S Grouping power sources and power loads to groups that share similar properties
US9323577B2 (en) 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
US9858612B2 (en) 2013-01-18 2018-01-02 Loop Commerce, Inc. Buyer interface for a gift transaction system
US10540630B2 (en) 2013-01-18 2020-01-21 Loop Commerce, Inc. Systems and methods of enabling gifting of a gift product on a legacy merchant store front
US9147161B2 (en) * 2013-03-14 2015-09-29 Google Inc. Determining geo-locations of users from user activities
US20150169794A1 (en) * 2013-03-14 2015-06-18 Google Inc. Updating location relevant user behavior statistics from classification errors
US9159030B1 (en) 2013-03-14 2015-10-13 Google Inc. Refining location detection from a query stream
US9553936B2 (en) 2013-03-15 2017-01-24 Google Inc. Targeting of digital content to geographic regions
US9729500B2 (en) 2013-03-15 2017-08-08 Google Inc. IP allocation pools
US9294391B1 (en) 2013-06-04 2016-03-22 Amazon Technologies, Inc. Managing network computing components utilizing request routing
US10320628B2 (en) 2013-06-19 2019-06-11 Citrix Systems, Inc. Confidence scoring of device reputation based on characteristic network behavior
US9509759B2 (en) 2013-09-09 2016-11-29 International Business Machines Corporation Service agreement performance validation in a cloud hosted environment
WO2015038881A1 (en) * 2013-09-13 2015-03-19 ClickTale, Ltd. A method and system for generating comparable visual maps for browsing activity analysis
JP6351235B2 (en) * 2013-11-06 2018-07-04 アルパイン株式会社 Navigation system, computer program, and current position calculation method
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
CN104767837B (en) * 2014-01-08 2018-08-24 阿里巴巴集团控股有限公司 A kind of method and device of identification agent IP address
US9628950B1 (en) 2014-01-12 2017-04-18 Investment Asset Holdings Llc Location-based messaging
EP3102965B1 (en) * 2014-02-05 2023-07-26 Verve Group, Inc. Methods and apparatus for identification and ranking of synthetic locations for mobile applications
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US9900281B2 (en) 2014-04-14 2018-02-20 Verisign, Inc. Computer-implemented method, apparatus, and computer-readable medium for processing named entity queries using a cached functionality in a domain name system
US9576030B1 (en) 2014-05-07 2017-02-21 Consumerinfo.Com, Inc. Keeping up with the joneses
CN105100292B (en) 2014-05-12 2018-12-18 阿里巴巴集团控股有限公司 Determine the method and device of the position of terminal
US9396354B1 (en) 2014-05-28 2016-07-19 Snapchat, Inc. Apparatus and method for automated privacy protection in distributed images
US9537811B2 (en) 2014-10-02 2017-01-03 Snap Inc. Ephemeral gallery of ephemeral messages
IL239238B (en) 2014-06-05 2022-04-01 Mobli Tech 2010 Ltd Automatic article enrichment by social media trends
US9113301B1 (en) 2014-06-13 2015-08-18 Snapchat, Inc. Geo-location based event gallery
US9661066B2 (en) * 2014-06-18 2017-05-23 Yahoo! Inc. System and method for address based locations
US11257117B1 (en) 2014-06-25 2022-02-22 Experian Information Solutions, Inc. Mobile device sighting location analytics and profiling system
US9225897B1 (en) 2014-07-07 2015-12-29 Snapchat, Inc. Apparatus and method for supplying content aware photo filters
US9753946B2 (en) * 2014-07-15 2017-09-05 Microsoft Technology Licensing, Llc Reverse IP databases using data indicative of user location
KR101589279B1 (en) * 2014-08-29 2016-01-28 한국전자통신연구원 Apparatus and method of classifying industrial control system webpage
US10423983B2 (en) 2014-09-16 2019-09-24 Snap Inc. Determining targeting information based on a predictive targeting model
US10824654B2 (en) 2014-09-18 2020-11-03 Snap Inc. Geolocation-based pictographs
US11216869B2 (en) 2014-09-23 2022-01-04 Snap Inc. User interface to augment an image using geolocation
US10284508B1 (en) 2014-10-02 2019-05-07 Snap Inc. Ephemeral gallery of ephemeral messages with opt-in permanence
US10091311B2 (en) * 2014-11-04 2018-10-02 Entit Software Llc Smart location determination
US9015285B1 (en) 2014-11-12 2015-04-21 Snapchat, Inc. User interface for accessing media at a geographic location
US20160171415A1 (en) * 2014-12-13 2016-06-16 Security Scorecard Cybersecurity risk assessment on an industry basis
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10091096B1 (en) 2014-12-18 2018-10-02 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10033627B1 (en) 2014-12-18 2018-07-24 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US9385983B1 (en) 2014-12-19 2016-07-05 Snapchat, Inc. Gallery of messages from individuals with a shared interest
US10242019B1 (en) 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US10311916B2 (en) 2014-12-19 2019-06-04 Snap Inc. Gallery of videos set to an audio time line
US9754355B2 (en) 2015-01-09 2017-09-05 Snap Inc. Object recognition based photo filters
US11388226B1 (en) 2015-01-13 2022-07-12 Snap Inc. Guided personal identity based actions
US10133705B1 (en) 2015-01-19 2018-11-20 Snap Inc. Multichannel system
US20160219120A1 (en) * 2015-01-23 2016-07-28 Netapp, Inc. Methods for providing a staging area for objects prior to erasure coding and devices thereof
US9521515B2 (en) 2015-01-26 2016-12-13 Mobli Technologies 2010 Ltd. Content request by location
US9607414B2 (en) 2015-01-27 2017-03-28 Splunk Inc. Three-dimensional point-in-polygon operation to facilitate displaying three-dimensional structures
US10026204B2 (en) 2015-01-27 2018-07-17 Splunk Inc. Efficient point-in-polygon indexing technique for processing queries over geographic data sets
US9767122B2 (en) 2015-01-27 2017-09-19 Splunk Inc. Efficient point-in-polygon indexing technique to facilitate displaying geographic data
US9916326B2 (en) 2015-01-27 2018-03-13 Splunk, Inc. Efficient point-in-polygon indexing technique for facilitating geofencing operations
US9836874B2 (en) 2015-01-27 2017-12-05 Splunk Inc. Efficient polygon-clipping technique to reduce data transfer requirements for a viewport
US10223397B1 (en) 2015-03-13 2019-03-05 Snap Inc. Social graph based co-location of network users
KR102035405B1 (en) 2015-03-18 2019-10-22 스냅 인코포레이티드 Geo-Fence Authorized Provisioning
US9692967B1 (en) 2015-03-23 2017-06-27 Snap Inc. Systems and methods for reducing boot time and power consumption in camera systems
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9887932B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887931B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9881094B2 (en) 2015-05-05 2018-01-30 Snap Inc. Systems and methods for automated local story generation and curation
US10135949B1 (en) 2015-05-05 2018-11-20 Snap Inc. Systems and methods for story and sub-story navigation
US10733594B1 (en) * 2015-05-11 2020-08-04 Square, Inc. Data security measures for mobile devices
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US10616179B1 (en) 2015-06-25 2020-04-07 Amazon Technologies, Inc. Selective routing of domain name system (DNS) requests
US10993069B2 (en) 2015-07-16 2021-04-27 Snap Inc. Dynamically adaptive media content delivery
US10097566B1 (en) 2015-07-31 2018-10-09 Amazon Technologies, Inc. Identifying targets of network attacks
US10817898B2 (en) 2015-08-13 2020-10-27 Placed, Llc Determining exposures to content presented by physical objects
US9742795B1 (en) 2015-09-24 2017-08-22 Amazon Technologies, Inc. Mitigating network attacks
US9774619B1 (en) 2015-09-24 2017-09-26 Amazon Technologies, Inc. Mitigating network attacks
US9794281B1 (en) 2015-09-24 2017-10-17 Amazon Technologies, Inc. Identifying sources of network attacks
US9652896B1 (en) 2015-10-30 2017-05-16 Snap Inc. Image based tracking in augmented reality systems
US10346446B2 (en) * 2015-11-02 2019-07-09 Radiant Geospatial Solutions Llc System and method for aggregating multi-source data and identifying geographic areas for data acquisition
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US9767309B1 (en) 2015-11-23 2017-09-19 Experian Information Solutions, Inc. Access control system for implementing access restrictions of regulated database records while identifying and providing indicators of regulated database records matching validation criteria
US9984499B1 (en) 2015-11-30 2018-05-29 Snap Inc. Image and point cloud based tracking and in augmented reality systems
US10474321B2 (en) 2015-11-30 2019-11-12 Snap Inc. Network resource location linking and visual content sharing
US10049051B1 (en) 2015-12-11 2018-08-14 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10257307B1 (en) 2015-12-11 2019-04-09 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10348639B2 (en) 2015-12-18 2019-07-09 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US10354425B2 (en) 2015-12-18 2019-07-16 Snap Inc. Method and system for providing context relevant media augmentation
US10285001B2 (en) 2016-02-26 2019-05-07 Snap Inc. Generation, curation, and presentation of media collections
US11023514B2 (en) 2016-02-26 2021-06-01 Snap Inc. Methods and systems for generation, curation, and presentation of media collections
US10679389B2 (en) 2016-02-26 2020-06-09 Snap Inc. Methods and systems for generation, curation, and presentation of media collections
US10339365B2 (en) 2016-03-31 2019-07-02 Snap Inc. Automated avatar generation
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10805696B1 (en) 2016-06-20 2020-10-13 Pipbin, Inc. System for recording and targeting tagged content of user interest
US10638256B1 (en) 2016-06-20 2020-04-28 Pipbin, Inc. System for distribution and display of mobile targeted augmented reality content
US11876941B1 (en) 2016-06-20 2024-01-16 Pipbin, Inc. Clickable augmented reality content manager, system, and network
US11201981B1 (en) 2016-06-20 2021-12-14 Pipbin, Inc. System for notification of user accessibility of curated location-dependent content in an augmented estate
US10334134B1 (en) 2016-06-20 2019-06-25 Maximillian John Suiter Augmented real estate with location and chattel tagging system and apparatus for virtual diary, scrapbooking, game play, messaging, canvasing, advertising and social interaction
US11044393B1 (en) 2016-06-20 2021-06-22 Pipbin, Inc. System for curation and display of location-dependent augmented reality content in an augmented estate system
US11785161B1 (en) 2016-06-20 2023-10-10 Pipbin, Inc. System for user accessibility of tagged curated augmented reality content
US10372883B2 (en) 2016-06-24 2019-08-06 Scripps Networks Interactive, Inc. Satellite and central asset registry systems and methods and rights management systems
US10452714B2 (en) * 2016-06-24 2019-10-22 Scripps Networks Interactive, Inc. Central asset registry system and method
US11868445B2 (en) 2016-06-24 2024-01-09 Discovery Communications, Llc Systems and methods for federated searches of assets in disparate dam repositories
US10430838B1 (en) 2016-06-28 2019-10-01 Snap Inc. Methods and systems for generation, curation, and presentation of media collections with automated advertising
US9681265B1 (en) 2016-06-28 2017-06-13 Snap Inc. System to track engagement of media items
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US10546302B2 (en) 2016-06-30 2020-01-28 Square, Inc. Logical validation of devices against fraud and tampering
US10331141B2 (en) * 2016-06-30 2019-06-25 GM Global Technology Operations LLC Systems for autonomous vehicle route selection and execution
US10387514B1 (en) 2016-06-30 2019-08-20 Snap Inc. Automated content curation and communication
US10855632B2 (en) 2016-07-19 2020-12-01 Snap Inc. Displaying customized electronic messaging graphics
US9992086B1 (en) 2016-08-23 2018-06-05 Amazon Technologies, Inc. External health checking of virtual private cloud network environments
US10033691B1 (en) 2016-08-24 2018-07-24 Amazon Technologies, Inc. Adaptive resolution of domain name requests in virtual private cloud network environments
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users
EP4184438A1 (en) 2016-08-30 2023-05-24 Snap Inc. Systems and methods for simultaneous localization and mapping
US10999240B1 (en) 2016-08-31 2021-05-04 Verisign, Inc. Client controlled domain name service (DNS) resolution
US10616250B2 (en) 2016-10-05 2020-04-07 Amazon Technologies, Inc. Network addresses with encoded DNS-level information
US10432559B2 (en) 2016-10-24 2019-10-01 Snap Inc. Generating and displaying customized avatars in electronic messages
US10298704B2 (en) 2016-10-27 2019-05-21 Microsoft Technology Licensing, Llc Determining geolocation of IP addresses using user transitions over time
KR102163443B1 (en) 2016-11-07 2020-10-08 스냅 인코포레이티드 Selective identification and ordering of image modifiers
US10203855B2 (en) 2016-12-09 2019-02-12 Snap Inc. Customized user-controlled media overlays
US10372499B1 (en) 2016-12-27 2019-08-06 Amazon Technologies, Inc. Efficient region selection system for executing request-driven code
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US11616745B2 (en) 2017-01-09 2023-03-28 Snap Inc. Contextual generation and selection of customized media content
US10454857B1 (en) 2017-01-23 2019-10-22 Snap Inc. Customized digital avatar accessories
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US10915911B2 (en) 2017-02-03 2021-02-09 Snap Inc. System to determine a price-schedule to distribute media content
US10496993B1 (en) * 2017-02-15 2019-12-03 Square, Inc. DNS-based device geolocation
US10319149B1 (en) 2017-02-17 2019-06-11 Snap Inc. Augmented reality anamorphosis system
US11250075B1 (en) 2017-02-17 2022-02-15 Snap Inc. Searching social media content
US10074381B1 (en) 2017-02-20 2018-09-11 Snap Inc. Augmented reality speech balloon system
US10565795B2 (en) 2017-03-06 2020-02-18 Snap Inc. Virtual vision system
US10523625B1 (en) 2017-03-09 2019-12-31 Snap Inc. Restricted group content collection
US10581782B2 (en) 2017-03-27 2020-03-03 Snap Inc. Generating a stitched data stream
US10582277B2 (en) 2017-03-27 2020-03-03 Snap Inc. Generating a stitched data stream
US11170393B1 (en) 2017-04-11 2021-11-09 Snap Inc. System to calculate an engagement score of location based media content
US20180302486A1 (en) * 2017-04-12 2018-10-18 Futurewei Technologies, Inc. Proxy apparatus and method for data collection
US10387730B1 (en) 2017-04-20 2019-08-20 Snap Inc. Augmented reality typography personalization system
US10503613B1 (en) 2017-04-21 2019-12-10 Amazon Technologies, Inc. Efficient serving of resources during server unavailability
US10212541B1 (en) 2017-04-27 2019-02-19 Snap Inc. Selective location-based identity communication
EP4307724A2 (en) 2017-04-27 2024-01-17 Snap Inc. Regional-level representation of user location on a social media platform
US11893647B2 (en) 2017-04-27 2024-02-06 Snap Inc. Location-based virtual avatars
US10467147B1 (en) 2017-04-28 2019-11-05 Snap Inc. Precaching unlockable data elements
US10803120B1 (en) 2017-05-31 2020-10-13 Snap Inc. Geolocation based playlists
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10447648B2 (en) 2017-06-19 2019-10-15 Amazon Technologies, Inc. Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
US10552308B1 (en) 2017-06-23 2020-02-04 Square, Inc. Analyzing attributes of memory mappings to identify processes running on a device
US11032127B2 (en) 2017-06-26 2021-06-08 Verisign, Inc. Resilient domain name service (DNS) resolution when an authoritative name server is unavailable
US11475254B1 (en) 2017-09-08 2022-10-18 Snap Inc. Multimodal entity identification
US10740974B1 (en) 2017-09-15 2020-08-11 Snap Inc. Augmented reality system
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
US10499191B1 (en) 2017-10-09 2019-12-03 Snap Inc. Context sensitive presentation of content
US10573043B2 (en) 2017-10-30 2020-02-25 Snap Inc. Mobile-based cartographic control of display content
US11265273B1 (en) 2017-12-01 2022-03-01 Snap, Inc. Dynamic media overlay with smart widget
US11017173B1 (en) 2017-12-22 2021-05-25 Snap Inc. Named entity recognition visual context and caption data
US10715536B2 (en) 2017-12-29 2020-07-14 Square, Inc. Logical validation of devices against fraud and tampering
US10666681B2 (en) * 2017-12-31 2020-05-26 Rapid7, Inc. Detecting malicious actors
US10678818B2 (en) 2018-01-03 2020-06-09 Snap Inc. Tag distribution visualization system
CN108269087B (en) 2018-01-12 2020-07-28 阿里巴巴集团控股有限公司 Method and device for processing position information
US11507614B1 (en) 2018-02-13 2022-11-22 Snap Inc. Icon based tagging
US10979752B1 (en) 2018-02-28 2021-04-13 Snap Inc. Generating media content items based on location information
US10885136B1 (en) 2018-02-28 2021-01-05 Snap Inc. Audience filtering system
US10327096B1 (en) 2018-03-06 2019-06-18 Snap Inc. Geo-fence selection system
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
KR102494540B1 (en) 2018-03-14 2023-02-06 스냅 인코포레이티드 Creation of collectible items based on location information
US11163941B1 (en) 2018-03-30 2021-11-02 Snap Inc. Annotating a collection of media content items
US10219111B1 (en) 2018-04-18 2019-02-26 Snap Inc. Visitation tracking system
CN108763309B (en) * 2018-04-24 2020-11-27 中国地质大学(武汉) Geoscience data acquisition method and system based on voice control
WO2019210349A1 (en) 2018-05-01 2019-11-07 HowTech Pty Ltd Geolocation system and method
US10896197B1 (en) 2018-05-22 2021-01-19 Snap Inc. Event detection system
WO2019241827A1 (en) * 2018-06-19 2019-12-26 Sine Group Pty Ltd Remote access system and method
US10679393B2 (en) 2018-07-24 2020-06-09 Snap Inc. Conditional modification of augmented reality object
US10924560B2 (en) * 2018-07-30 2021-02-16 Facebook, Inc. Determining geographic locations of network devices
US10380536B1 (en) * 2018-08-28 2019-08-13 Shurpa, Inc. Geo-segregated scheduled delivery optimization engine
US11397925B2 (en) * 2018-08-28 2022-07-26 Shurpa, Inc. Appointment optimization engine
US10997760B2 (en) 2018-08-31 2021-05-04 Snap Inc. Augmented reality anthropomorphization system
US20200098010A1 (en) * 2018-09-20 2020-03-26 PAG Financial International LLC System and method for providing recommendations based on consumer location
US11494762B1 (en) 2018-09-26 2022-11-08 Block, Inc. Device driver for contactless payments
US11507958B1 (en) 2018-09-26 2022-11-22 Block, Inc. Trust-based security for transaction payments
US10698583B2 (en) 2018-09-28 2020-06-30 Snap Inc. Collaborative achievement interface
US10778623B1 (en) 2018-10-31 2020-09-15 Snap Inc. Messaging and gaming applications communication platform
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US10939236B1 (en) 2018-11-30 2021-03-02 Snap Inc. Position service to determine relative position to map features
US11199957B1 (en) 2018-11-30 2021-12-14 Snap Inc. Generating customized avatars based on location information
WO2020115796A1 (en) * 2018-12-03 2020-06-11 株式会社Geolocation Technology Ip address use area identifying system
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
US11032670B1 (en) 2019-01-14 2021-06-08 Snap Inc. Destination sharing in location sharing system
US10939246B1 (en) 2019-01-16 2021-03-02 Snap Inc. Location-based context information sharing in a messaging system
US11294936B1 (en) 2019-01-30 2022-04-05 Snap Inc. Adaptive spatial density based clustering
US10936066B1 (en) 2019-02-13 2021-03-02 Snap Inc. Sleep detection in a location sharing system
US10838599B2 (en) 2019-02-25 2020-11-17 Snap Inc. Custom media overlay system
US10964082B2 (en) 2019-02-26 2021-03-30 Snap Inc. Avatar based on weather
US10852918B1 (en) 2019-03-08 2020-12-01 Snap Inc. Contextual information in chat
US11868414B1 (en) 2019-03-14 2024-01-09 Snap Inc. Graph-based prediction for contact suggestion in a location sharing system
US10687273B1 (en) 2019-03-19 2020-06-16 Bank Of America Corporation Provisioning services based on geolocation data and activity recognition
US11852554B1 (en) 2019-03-21 2023-12-26 Snap Inc. Barometer calibration in a location sharing system
US11249614B2 (en) 2019-03-28 2022-02-15 Snap Inc. Generating personalized map interface with enhanced icons
US10810782B1 (en) 2019-04-01 2020-10-20 Snap Inc. Semantic texture mapping system
US10560898B1 (en) 2019-05-30 2020-02-11 Snap Inc. Wearable device location systems
US10582453B1 (en) 2019-05-30 2020-03-03 Snap Inc. Wearable device location systems architecture
US10893385B1 (en) 2019-06-07 2021-01-12 Snap Inc. Detection of a physical collision between two client devices in a location sharing system
US11307747B2 (en) 2019-07-11 2022-04-19 Snap Inc. Edge gesture interface with smart interactions
WO2021027941A1 (en) 2019-08-15 2021-02-18 华为技术有限公司 Method for learning routing, method for forwarding report, device, and storage medium
US11821742B2 (en) 2019-09-26 2023-11-21 Snap Inc. Travel based notifications
US11218838B2 (en) 2019-10-31 2022-01-04 Snap Inc. Focused map-based context information surfacing
US11128715B1 (en) 2019-12-30 2021-09-21 Snap Inc. Physical friend proximity in chat
US11429618B2 (en) 2019-12-30 2022-08-30 Snap Inc. Surfacing augmented reality objects
US11169658B2 (en) 2019-12-31 2021-11-09 Snap Inc. Combined map icon with action indicator
US11343323B2 (en) 2019-12-31 2022-05-24 Snap Inc. Augmented reality objects registry
US11682041B1 (en) 2020-01-13 2023-06-20 Experian Marketing Solutions, Llc Systems and methods of a tracking analytics platform
US11228551B1 (en) 2020-02-12 2022-01-18 Snap Inc. Multiple gateway message exchange
US11516167B2 (en) 2020-03-05 2022-11-29 Snap Inc. Storing data based on device location
US11619501B2 (en) 2020-03-11 2023-04-04 Snap Inc. Avatar based on trip
US11430091B2 (en) 2020-03-27 2022-08-30 Snap Inc. Location mapping for large scale augmented-reality
US10956743B1 (en) 2020-03-27 2021-03-23 Snap Inc. Shared augmented reality system
US11290851B2 (en) 2020-06-15 2022-03-29 Snap Inc. Location sharing using offline and online objects
US11314776B2 (en) 2020-06-15 2022-04-26 Snap Inc. Location sharing using friend list versions
US11503432B2 (en) 2020-06-15 2022-11-15 Snap Inc. Scalable real-time location sharing framework
US11483267B2 (en) 2020-06-15 2022-10-25 Snap Inc. Location sharing using different rate-limited links
US11308327B2 (en) 2020-06-29 2022-04-19 Snap Inc. Providing travel-based augmented reality content with a captured image
US20210392162A1 (en) * 2020-07-31 2021-12-16 Patrick Kidney Novel dns record type for network threat prevention
CN112232444B (en) * 2020-11-23 2024-02-27 中国移动通信集团江苏有限公司 Method, device, equipment and storage medium for determining geographic position data of object
US11606756B2 (en) 2021-03-29 2023-03-14 Snap Inc. Scheduling requests for location data
US11645324B2 (en) 2021-03-31 2023-05-09 Snap Inc. Location-based timeline media content system
US11829834B2 (en) 2021-10-29 2023-11-28 Snap Inc. Extended QR code
WO2023158523A1 (en) * 2022-02-16 2023-08-24 Paradox Inc. Intelligent assistant system for conversational job search
US20230376483A1 (en) * 2022-05-23 2023-11-23 Cribl, Inc. Searching Remote Data in an Observability Pipeline System

Citations (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5231631A (en) * 1989-08-15 1993-07-27 At&T Bell Laboratories Arrangement for regulating traffic in a high speed data network
US5680390A (en) * 1995-06-06 1997-10-21 Bell Communications Research, Inc. Broadband telecommunications network and method of having operations systems support
US5848373A (en) * 1994-06-24 1998-12-08 Delorme Publishing Company Computer aided map location system
US5862339A (en) * 1996-07-09 1999-01-19 Webtv Networks, Inc. Client connects to an internet access provider using algorithm downloaded from a central server based upon client's desired criteria after disconnected from the server
US5884038A (en) * 1997-05-02 1999-03-16 Whowhere? Inc. Method for providing an Internet protocol address with a domain name server
US5913036A (en) * 1996-06-28 1999-06-15 Mci Communications Corporation Raw performance monitoring correlated problem alert signals
US5944787A (en) * 1997-04-21 1999-08-31 Sift, Inc. Method for automatically finding postal addresses from e-mail addresses
US5978845A (en) * 1997-03-25 1999-11-02 Sun Microsystems, Inc. Network management relay mechanism
US5994787A (en) * 1996-09-19 1999-11-30 Toyota Jidosha Kabushiki Kaisha Control system for a power supply changeover switch
US6154172A (en) * 1998-03-31 2000-11-28 Piccionelli; Gregory A. System and process for limiting distribution of information on a communication network based on geographic location
US6154745A (en) * 1996-12-31 2000-11-28 Nokia Mobile Phones Ltd. Method for transmission of information to the user
US6185598B1 (en) * 1998-02-10 2001-02-06 Digital Island, Inc. Optimized network resource location
US6236365B1 (en) * 1996-09-09 2001-05-22 Tracbeam, Llc Location of a mobile station using a plurality of commercial wireless infrastructures
US6243749B1 (en) * 1998-10-08 2001-06-05 Cisco Technology, Inc. Dynamic network address updating
US6266607B1 (en) * 1996-12-16 2001-07-24 Mannesmann Ag Process for selecting the traffic information transmitted by a traffic information center which concerns a route of a vehicle equipped with a terminal in a road network
US6272150B1 (en) * 1997-01-17 2001-08-07 Scientific-Atlanta, Inc. Cable modem map display for network management of a cable data delivery system
US6275470B1 (en) * 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US6285748B1 (en) * 1997-09-25 2001-09-04 At&T Corporation Network traffic controller
US6286047B1 (en) * 1998-09-10 2001-09-04 Hewlett-Packard Company Method and system for automatic discovery of network services
US6324585B1 (en) * 1998-11-19 2001-11-27 Cisco Technology, Inc. Method and apparatus for domain name service request resolution
US6338082B1 (en) * 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
US20020007374A1 (en) * 1998-12-16 2002-01-17 Joshua K. Marks Method and apparatus for supporting a multicast response to a unicast request for a document
US6343290B1 (en) * 1999-12-22 2002-01-29 Celeritas Technologies, L.L.C. Geographic network management system
US20020015424A1 (en) * 1997-05-19 2002-02-07 Preston Daniel A. Network delay identification method and apparatus
US6347078B1 (en) * 1997-09-02 2002-02-12 Lucent Technologies Inc. Multiple path routing
US6389291B1 (en) * 2000-08-14 2002-05-14 Sirf Technology Multi-mode global positioning system for use with wireless networks
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
US6415064B1 (en) * 1998-05-26 2002-07-02 Samsung Electronics, Co., Ltd. Skew correction apparatus and method
US6421726B1 (en) * 1997-03-14 2002-07-16 Akamai Technologies, Inc. System and method for selection and retrieval of diverse types of video data on a computer network
US6425000B1 (en) * 1996-05-30 2002-07-23 Softell System and method for triggering actions at a host computer by telephone
US20020099955A1 (en) * 2001-01-23 2002-07-25 Vidius Inc. Method for securing digital content
US20020143991A1 (en) * 2001-03-16 2002-10-03 Kingsum Chow Geographic location determination including inspection of network address
US6466940B1 (en) * 1997-02-21 2002-10-15 Dudley John Mills Building a database of CCG values of web pages from extracted attributes
US6484143B1 (en) * 1999-11-22 2002-11-19 Speedera Networks, Inc. User device and system for traffic management and content distribution over a world wide area network
US6487538B1 (en) * 1998-11-16 2002-11-26 Sun Microsystems, Inc. Method and apparatus for local advertising
US6505201B1 (en) * 1999-06-03 2003-01-07 Net Zero, Inc. Apparatus for monitoring individual internet usage
US6513061B1 (en) * 1997-10-07 2003-01-28 Hitachi, Ltd. Proxy server selecting server and proxy server
US6523064B1 (en) * 1999-04-29 2003-02-18 Mitsubishi Electric Research Laboratories, Inc Network gateway for collecting geographic data information
US20030065763A1 (en) * 1999-11-22 2003-04-03 Swildens Eric Sven-Johan Method for determining metrics of a content delivery and global traffic management network
US20030110293A1 (en) * 1999-05-03 2003-06-12 Friedman Robert B. Geo-intelligent traffic reporter
US20030125021A1 (en) * 2001-12-28 2003-07-03 Tell Daniel Francis Method and apparatus for transmitting wired data voice over IP data and wireless data through a common IP core network
US20030212909A1 (en) * 2002-01-18 2003-11-13 Lucent Technologies Inc. Tool, method and apparatus for assessing network security
US6665611B1 (en) * 2001-06-19 2003-12-16 Cisco Technology, Inc. System for discovering and maintaining geographic location information in a computer network to enable emergency services
US6665715B1 (en) * 2000-04-03 2003-12-16 Infosplit Inc Method and systems for locating geographical locations of online users
US6674745B1 (en) * 1998-12-31 2004-01-06 3Com Corporation Method and system for mapping phone numbers to IP addresses
US20040010571A1 (en) * 2002-06-18 2004-01-15 Robin Hutchinson Methods and systems for managing enterprise assets
US6681232B1 (en) * 2000-06-07 2004-01-20 Yipes Enterprise Services, Inc. Operations and provisioning systems for service level management in an extended-area data communications network
US6684250B2 (en) * 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
US6684158B1 (en) * 2001-02-28 2004-01-27 Sirf Technology, Inc. Method for aiding a global positioning system
US20040103315A1 (en) * 2001-06-07 2004-05-27 Geoffrey Cooper Assessment tool
US6760775B1 (en) * 1999-03-05 2004-07-06 At&T Corp. System, method and apparatus for network service load and reliability management
US20050004978A1 (en) * 1996-02-29 2005-01-06 Reed Drummond Shattuck Object-based on-line transaction infrastructure
US20050024265A1 (en) * 1999-01-08 2005-02-03 Trueposition, Inc. Multiple pass location processor
US6873854B2 (en) * 2002-02-14 2005-03-29 Qualcomm Inc. Method and an apparatus for adding a new member to an active group call in a group communication network
US6904449B1 (en) * 2000-01-14 2005-06-07 Accenture Llp System and method for an application provider framework
US20050138144A1 (en) * 2003-12-23 2005-06-23 Cisco Technology, Inc. Providing location-specific services to a mobile node
US20050198265A1 (en) * 2004-01-30 2005-09-08 Peter Veprek Method and apparatus for information notification
US20060010252A1 (en) * 2004-03-04 2006-01-12 Miltonberger Thomas W Geo-location and geo-compliance utilizing a client agent
US7062572B1 (en) * 2001-03-19 2006-06-13 Microsoft Corporation Method and system to determine the geographic location of a network user
US20060128397A1 (en) * 2004-12-15 2006-06-15 Choti Joseph F System and method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US7100204B1 (en) * 2002-04-05 2006-08-29 International Business Machines Corporation System and method for determining network users' physical locations
US20060242072A1 (en) * 2001-03-28 2006-10-26 Vidius, Inc Method and system for creation, management and analysis of distribution syndicates

Family Cites Families (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5042032A (en) 1989-06-23 1991-08-20 At&T Bell Laboratories Packet route scheduling in a packet cross connect switch system for periodic and statistical packets
US4939726A (en) 1989-07-18 1990-07-03 Metricom, Inc. Method for routing packets in a packet communication network
US5115433A (en) 1989-07-18 1992-05-19 Metricom, Inc. Method and system for routing packets in a packet communication network
AU651835B2 (en) 1990-06-13 1994-08-04 Arnold Glazier Phosphorous prodrugs
US5177064A (en) 1990-07-13 1993-01-05 University Of Florida Targeted drug delivery via phosphonate derivatives
US5291550A (en) * 1990-12-26 1994-03-01 At&T Bell Laboratories Dynamic network call distributor
DE4111730A1 (en) 1991-04-10 1992-10-15 Knoll Ag NEW CYTARABIN DERIVATIVES, THEIR PRODUCTION AND USE
US5421024A (en) 1991-04-30 1995-05-30 Hewlett-Packard Company Detection of a relative location of a network device using a multicast packet processed only by hubs
US5734823A (en) 1991-11-04 1998-03-31 Microtome, Inc. Systems and apparatus for electronic communication and storage of information
WO1993009490A1 (en) 1991-11-04 1993-05-13 Vpr Systems Ltd. Lap-top computer for retrieving and displaying text and graphic information encoded on personal library cd-rom
FR2692265B1 (en) 1992-05-25 1996-11-08 Centre Nat Rech Scient BIOLOGICALLY ACTIVE COMPOUNDS OF THE PHOSPHOTRIESTER TYPE.
US5490252A (en) 1992-09-30 1996-02-06 Bay Networks Group, Inc. System having central processor for transmitting generic packets to another processor to be altered and transmitting altered packets back to central processor for routing
US5715396A (en) 1992-10-13 1998-02-03 Bay Networks, Inc. Method for providing for automatic topology discovery in an ATM network or the like
US5493689A (en) * 1993-03-01 1996-02-20 International Business Machines Corporation System for configuring an event driven interface including control blocks defining good loop locations in a memory which represent detection of a characteristic pattern
US5418713A (en) 1993-08-05 1995-05-23 Allen; Richard Apparatus and method for an on demand data delivery system for the preview, selection, retrieval and reproduction at a remote location of previously recorded or programmed materials
US5488608A (en) 1994-04-14 1996-01-30 Metricom, Inc. Method and system for routing packets in a packet communication network using locally constructed routing tables
DE4413451A1 (en) 1994-04-18 1995-12-14 Rolf Brugger Device for the distribution of music information in digital form
US5687319A (en) 1994-09-27 1997-11-11 International Business Machines Corporation Method and system for determining maximum cable segments between all possible node to node paths on a serial bus
US5675741A (en) 1994-10-25 1997-10-07 Cabletron Systems, Inc. Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network
US6269392B1 (en) * 1994-11-15 2001-07-31 Christian Cotichini Method and apparatus to monitor and locate an electronic device using a secured intelligent agent
US6244758B1 (en) * 1994-11-15 2001-06-12 Absolute Software Corp. Apparatus and method for monitoring electronic devices via a global network
US6300863B1 (en) * 1994-11-15 2001-10-09 Absolute Software Corporation Method and apparatus to monitor and locate an electronic device using a secured intelligent agent via a global network
US5563878A (en) * 1995-01-05 1996-10-08 International Business Machines Corporation Transaction message routing in digital communication networks
US5659596A (en) 1995-04-12 1997-08-19 International Business Machines Corporation System for location of communication end users
US6058307A (en) * 1995-11-30 2000-05-02 Amsc Subsidiary Corporation Priority and preemption service system for satellite related communication using central controller
US5878126A (en) 1995-12-11 1999-03-02 Bellsouth Corporation Method for routing a call to a destination based on range identifiers for geographic area assignments
US5777989A (en) 1995-12-19 1998-07-07 International Business Machines Corporation TCP/IP host name resolution for machines on several domains
US6014634A (en) 1995-12-26 2000-01-11 Supermarkets Online, Inc. System and method for providing shopping aids and incentives to customers through a computer network
US5930474A (en) 1996-01-31 1999-07-27 Z Land Llc Internet organizer for accessing geographically and topically based information
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US5870561A (en) * 1996-03-15 1999-02-09 Novell, Inc. Network traffic manager server for providing policy-based recommendations to clients
US5937163A (en) 1996-03-26 1999-08-10 Industrial Technology Research Institute Method and system at a host node for hierarchically organizing the links visited by a world wide web browser executing at the host node
US5944790A (en) 1996-07-19 1999-08-31 Lucent Technologies Inc. Method and apparatus for providing a web site having a home page that automatically adapts to user language and customs
JP3688822B2 (en) * 1996-09-03 2005-08-31 株式会社東芝 Electronic medical record system
US6249252B1 (en) 1996-09-09 2001-06-19 Tracbeam Llc Wireless location using multiple location estimators
US5948061A (en) 1996-10-29 1999-09-07 Double Click, Inc. Method of delivery, targeting, and measuring advertising over networks
US6012088A (en) 1996-12-10 2000-01-04 International Business Machines Corporation Automatic configuration for internet access device
US6012090A (en) * 1997-03-14 2000-01-04 At&T Corp. Client-side parallel requests for network services using group name association
US6009081A (en) * 1997-09-03 1999-12-28 Internap Network Services Private network access point router for interconnecting among internet route providers
US6259701B1 (en) * 1997-09-11 2001-07-10 At&T Corp. Method and system for a unicast endpoint client to access a multicast internet protocol (IP) session
US6035332A (en) 1997-10-06 2000-03-07 Ncr Corporation Method for monitoring user interactions with web pages from web server using data and command lists for maintaining information visited and issued by participants
WO1999034555A2 (en) 1997-12-24 1999-07-08 America Online, Inc. Asynchronous data protocol
US6012052A (en) 1998-01-15 2000-01-04 Microsoft Corporation Methods and apparatus for building resource transition probability models for use in pre-fetching resources, editing resource link topology, building resource link topology templates, and collaborative filtering
US5978745A (en) * 1998-01-23 1999-11-02 Apple Computer, Inc. System and method for automatically calibrating display monitor beam currents
FR2776989B1 (en) 1998-04-06 2000-06-09 Valois Sa FIXING BODY OF DISTRIBUTION DEVICE WITH OGIVAL COVER
AU4125099A (en) 1998-06-01 1999-12-20 S & T Science And Technology Inc. Antiviral phosphorus derivatives of 4'-thio-5-ethyl-2'-deoxyuridine
US6167259A (en) * 1998-06-19 2000-12-26 Ericsson Inc. System and method of quantifying the degree of balance on forward link and reverse link channels
US6130890A (en) 1998-09-11 2000-10-10 Digital Island, Inc. Method and system for optimizing routing of data packets
US6272343B1 (en) 1998-10-13 2001-08-07 Tellus Technology, Inc. Method and apparatus for fast signal acquisition of preferred wireless channel
US6151631A (en) 1998-10-15 2000-11-21 Liquid Audio Inc. Territorial determination of remote computer location in a wide area network for conditional delivery of digitized products
EP1131747B1 (en) 1998-11-16 2013-03-13 Swisscom Mobile AG Method for the location-dependent retrieval of information from databases and system for carrying out said method
US6614781B1 (en) * 1998-11-20 2003-09-02 Level 3 Communications, Inc. Voice over data telecommunications network architecture
US6243746B1 (en) 1998-12-04 2001-06-05 Sun Microsystems, Inc. Method and implementation for using computer network topology objects
EP1598639B1 (en) 1999-03-23 2008-08-06 Sony Deutschland GmbH System and method for automatically managing geolocation information
US6192312B1 (en) 1999-03-25 2001-02-20 Navigation Technologies Corp. Position determining program and method
US6356929B1 (en) * 1999-04-07 2002-03-12 International Business Machines Corporation Computer system and method for sharing a job with other computers on a computer network using IP multicast
US6757740B1 (en) 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
US6091959A (en) 1999-06-02 2000-07-18 Motorola, Inc. Method and apparatus in a two-way wireless communication system for location-based message transmission
WO2000075027A1 (en) 1999-06-05 2000-12-14 Rehrig Pacific Company Stackable low depth case with handle structure
EP1072987A1 (en) 1999-07-29 2001-01-31 International Business Machines Corporation Geographic web browser and iconic hyperlink cartography
US6442565B1 (en) * 1999-08-13 2002-08-27 Hiddenmind Technology, Inc. System and method for transmitting data content in a computer network
US6438594B1 (en) * 1999-08-31 2002-08-20 Accenture Llp Delivering service to a client via a locally addressable interface
AUPQ545600A0 (en) 2000-02-04 2000-03-02 Geobytes Inc Method and apparatus for identifying locale of internet users
US6477150B1 (en) * 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
GB0007403D0 (en) 2000-03-27 2000-05-17 Bp Chem Int Ltd Method and apparatus for influencing customer buying patterns
WO2001075632A1 (en) 2000-04-03 2001-10-11 Quova, Inc. Geographic location estimation method for network addresses entities
US6826172B1 (en) * 2000-06-09 2004-11-30 Steven Augart Network probing using overlapping probe packets
US7337217B2 (en) * 2000-07-21 2008-02-26 Samsung Electronics Co., Ltd. Architecture for home network on world wide web
AU2001281106A1 (en) 2000-08-04 2002-02-18 Digital Envoy, Inc. Determining geographic locations of private network internet users
US20020016831A1 (en) 2000-08-07 2002-02-07 Vidius Inc. Apparatus and method for locating of an internet user
WO2002017139A1 (en) 2000-08-18 2002-02-28 Akamai Technologies, Inc. Method and system for providing content providers with information about how their users access the internet
US7373656B2 (en) 2000-10-27 2008-05-13 Sandisk Il Ltd. Automatic configuration for portable devices
US6947978B2 (en) * 2000-12-29 2005-09-20 The United States Of America As Represented By The Director, National Security Agency Method for geolocating logical network addresses
KR20020097384A (en) 2001-06-20 2002-12-31 미쯔비시 도꾜 세이야꾸 가부시끼가이샤 A Medicament which is Effective for a Virus Having a Resistance Mutation against a Known Medicament
US20020199018A1 (en) * 2001-06-21 2002-12-26 International Business Machines Corporation Maping physical locations to web sites

Patent Citations (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5231631A (en) * 1989-08-15 1993-07-27 At&T Bell Laboratories Arrangement for regulating traffic in a high speed data network
US5848373A (en) * 1994-06-24 1998-12-08 Delorme Publishing Company Computer aided map location system
US5680390A (en) * 1995-06-06 1997-10-21 Bell Communications Research, Inc. Broadband telecommunications network and method of having operations systems support
US20050004978A1 (en) * 1996-02-29 2005-01-06 Reed Drummond Shattuck Object-based on-line transaction infrastructure
US6425000B1 (en) * 1996-05-30 2002-07-23 Softell System and method for triggering actions at a host computer by telephone
US5913036A (en) * 1996-06-28 1999-06-15 Mci Communications Corporation Raw performance monitoring correlated problem alert signals
US5862339A (en) * 1996-07-09 1999-01-19 Webtv Networks, Inc. Client connects to an internet access provider using algorithm downloaded from a central server based upon client's desired criteria after disconnected from the server
US6236365B1 (en) * 1996-09-09 2001-05-22 Tracbeam, Llc Location of a mobile station using a plurality of commercial wireless infrastructures
US20030222819A1 (en) * 1996-09-09 2003-12-04 Tracbeam Llc. Locating a mobile station using a plurality of wireless networks and applications therefor
US20060025158A1 (en) * 1996-09-09 2006-02-02 Leblanc Frederick W Locating a mobile station and applications therefor
US5994787A (en) * 1996-09-19 1999-11-30 Toyota Jidosha Kabushiki Kaisha Control system for a power supply changeover switch
US6266607B1 (en) * 1996-12-16 2001-07-24 Mannesmann Ag Process for selecting the traffic information transmitted by a traffic information center which concerns a route of a vehicle equipped with a terminal in a road network
US6154745A (en) * 1996-12-31 2000-11-28 Nokia Mobile Phones Ltd. Method for transmission of information to the user
US6272150B1 (en) * 1997-01-17 2001-08-07 Scientific-Atlanta, Inc. Cable modem map display for network management of a cable data delivery system
US6466940B1 (en) * 1997-02-21 2002-10-15 Dudley John Mills Building a database of CCG values of web pages from extracted attributes
US6421726B1 (en) * 1997-03-14 2002-07-16 Akamai Technologies, Inc. System and method for selection and retrieval of diverse types of video data on a computer network
US5978845A (en) * 1997-03-25 1999-11-02 Sun Microsystems, Inc. Network management relay mechanism
US5944787A (en) * 1997-04-21 1999-08-31 Sift, Inc. Method for automatically finding postal addresses from e-mail addresses
US5884038A (en) * 1997-05-02 1999-03-16 Whowhere? Inc. Method for providing an Internet protocol address with a domain name server
US20020015424A1 (en) * 1997-05-19 2002-02-07 Preston Daniel A. Network delay identification method and apparatus
US6347078B1 (en) * 1997-09-02 2002-02-12 Lucent Technologies Inc. Multiple path routing
US6285748B1 (en) * 1997-09-25 2001-09-04 At&T Corporation Network traffic controller
US6513061B1 (en) * 1997-10-07 2003-01-28 Hitachi, Ltd. Proxy server selecting server and proxy server
US6185598B1 (en) * 1998-02-10 2001-02-06 Digital Island, Inc. Optimized network resource location
US6154172A (en) * 1998-03-31 2000-11-28 Piccionelli; Gregory A. System and process for limiting distribution of information on a communication network based on geographic location
US6415064B1 (en) * 1998-05-26 2002-07-02 Samsung Electronics, Co., Ltd. Skew correction apparatus and method
US6286047B1 (en) * 1998-09-10 2001-09-04 Hewlett-Packard Company Method and system for automatic discovery of network services
US6243749B1 (en) * 1998-10-08 2001-06-05 Cisco Technology, Inc. Dynamic network address updating
US6487538B1 (en) * 1998-11-16 2002-11-26 Sun Microsystems, Inc. Method and apparatus for local advertising
US6526450B1 (en) * 1998-11-19 2003-02-25 Cisco Technology, Inc. Method and apparatus for domain name service request resolution
US6324585B1 (en) * 1998-11-19 2001-11-27 Cisco Technology, Inc. Method and apparatus for domain name service request resolution
US20020007374A1 (en) * 1998-12-16 2002-01-17 Joshua K. Marks Method and apparatus for supporting a multicast response to a unicast request for a document
US6674745B1 (en) * 1998-12-31 2004-01-06 3Com Corporation Method and system for mapping phone numbers to IP addresses
US20050024265A1 (en) * 1999-01-08 2005-02-03 Trueposition, Inc. Multiple pass location processor
US6760775B1 (en) * 1999-03-05 2004-07-06 At&T Corp. System, method and apparatus for network service load and reliability management
US6338082B1 (en) * 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
US6523064B1 (en) * 1999-04-29 2003-02-18 Mitsubishi Electric Research Laboratories, Inc Network gateway for collecting geographic data information
US20030110293A1 (en) * 1999-05-03 2003-06-12 Friedman Robert B. Geo-intelligent traffic reporter
US6505201B1 (en) * 1999-06-03 2003-01-07 Net Zero, Inc. Apparatus for monitoring individual internet usage
US6275470B1 (en) * 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
US20030065763A1 (en) * 1999-11-22 2003-04-03 Swildens Eric Sven-Johan Method for determining metrics of a content delivery and global traffic management network
US6484143B1 (en) * 1999-11-22 2002-11-19 Speedera Networks, Inc. User device and system for traffic management and content distribution over a world wide area network
US6343290B1 (en) * 1999-12-22 2002-01-29 Celeritas Technologies, L.L.C. Geographic network management system
US6904449B1 (en) * 2000-01-14 2005-06-07 Accenture Llp System and method for an application provider framework
US6665715B1 (en) * 2000-04-03 2003-12-16 Infosplit Inc Method and systems for locating geographical locations of online users
US20040078367A1 (en) * 2000-04-03 2004-04-22 Mark Anderson Method and system to modify geolocation activities based on logged query information
US6684250B2 (en) * 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
US7472172B2 (en) * 2000-04-03 2008-12-30 Quova, Inc. Method and system to initiate geolocation activities on demand and responsive to receipt of a query
US20040068582A1 (en) * 2000-04-03 2004-04-08 Mark Anderson Method and system to initiate geolocation activities on demand and responsive to receipt of a query
US20040078489A1 (en) * 2000-04-03 2004-04-22 Mark Anderson Method and system to associate a geographic location information with a network address using a combination of automated and manual process
US6681232B1 (en) * 2000-06-07 2004-01-20 Yipes Enterprise Services, Inc. Operations and provisioning systems for service level management in an extended-area data communications network
US6389291B1 (en) * 2000-08-14 2002-05-14 Sirf Technology Multi-mode global positioning system for use with wireless networks
US20020099955A1 (en) * 2001-01-23 2002-07-25 Vidius Inc. Method for securing digital content
US6684158B1 (en) * 2001-02-28 2004-01-27 Sirf Technology, Inc. Method for aiding a global positioning system
US20020143991A1 (en) * 2001-03-16 2002-10-03 Kingsum Chow Geographic location determination including inspection of network address
US7062572B1 (en) * 2001-03-19 2006-06-13 Microsoft Corporation Method and system to determine the geographic location of a network user
US20060212601A1 (en) * 2001-03-19 2006-09-21 Microsoft Corporation Method and system to determine the geographic location of a network user
US20060242072A1 (en) * 2001-03-28 2006-10-26 Vidius, Inc Method and system for creation, management and analysis of distribution syndicates
US20040103315A1 (en) * 2001-06-07 2004-05-27 Geoffrey Cooper Assessment tool
US6665611B1 (en) * 2001-06-19 2003-12-16 Cisco Technology, Inc. System for discovering and maintaining geographic location information in a computer network to enable emergency services
US20030125021A1 (en) * 2001-12-28 2003-07-03 Tell Daniel Francis Method and apparatus for transmitting wired data voice over IP data and wireless data through a common IP core network
US20030212909A1 (en) * 2002-01-18 2003-11-13 Lucent Technologies Inc. Tool, method and apparatus for assessing network security
US6873854B2 (en) * 2002-02-14 2005-03-29 Qualcomm Inc. Method and an apparatus for adding a new member to an active group call in a group communication network
US7100204B1 (en) * 2002-04-05 2006-08-29 International Business Machines Corporation System and method for determining network users' physical locations
US20040010571A1 (en) * 2002-06-18 2004-01-15 Robin Hutchinson Methods and systems for managing enterprise assets
US20050138144A1 (en) * 2003-12-23 2005-06-23 Cisco Technology, Inc. Providing location-specific services to a mobile node
US20050198265A1 (en) * 2004-01-30 2005-09-08 Peter Veprek Method and apparatus for information notification
US20060010252A1 (en) * 2004-03-04 2006-01-12 Miltonberger Thomas W Geo-location and geo-compliance utilizing a client agent
US20060128397A1 (en) * 2004-12-15 2006-06-15 Choti Joseph F System and method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network

Cited By (115)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050234922A1 (en) * 1999-05-03 2005-10-20 Parekh Sanjay M Systems and methods for determining, collecting, and using geographic locations of internet users
US7685311B2 (en) * 1999-05-03 2010-03-23 Digital Envoy, Inc. Geo-intelligent traffic reporter
US7698377B2 (en) 1999-05-03 2010-04-13 Digital Envoy, Inc. Systems and methods for determining, collecting, and using geographic locations of internet users
US20100153552A1 (en) * 1999-05-03 2010-06-17 Parekh Sanjay M Method and system for geo-targeted content delivery
US20060224752A1 (en) * 1999-05-03 2006-10-05 Parekh Sanjay M Determining geographic locations of private network Internet users
US20030110293A1 (en) * 1999-05-03 2003-06-12 Friedman Robert B. Geo-intelligent traffic reporter
US7844729B1 (en) 1999-05-03 2010-11-30 Digital Envoy, Inc. Geo-intelligent traffic manager
US8060606B2 (en) 1999-05-03 2011-11-15 Digital Envoy, Inc. Geo-intelligent traffic reporter
US8463942B2 (en) 1999-05-03 2013-06-11 Digital Envoy, Inc. Method and system for geo-targeted content delivery
US9900284B2 (en) 1999-05-03 2018-02-20 Digital Envoy, Inc. Method and system for generating IP address profiles
US20040078367A1 (en) * 2000-04-03 2004-04-22 Mark Anderson Method and system to modify geolocation activities based on logged query information
US7809857B2 (en) 2000-04-03 2010-10-05 Quova, Inc. Method and system to collect geographic location information for a network address utilizing geographically dispersed data collection agents
US20060053066A1 (en) * 2000-04-07 2006-03-09 Sherr Scott J Online digital video signal transfer apparatus and method
US20020032905A1 (en) * 2000-04-07 2002-03-14 Sherr Scott Jeffrey Online digital video signal transfer apparatus and method
US7028083B2 (en) * 2000-05-26 2006-04-11 Akomai Technologies, Inc. Method for extending a network map
US20020073199A1 (en) * 2000-05-26 2002-06-13 Matthew Levine Method for extending a network map
US20020129134A1 (en) * 2000-05-26 2002-09-12 Leighton F. Thomson Global load balancing across mirrored data centers
US7111061B2 (en) 2000-05-26 2006-09-19 Akamai Technologies, Inc. Global load balancing across mirrored data centers
US20020059622A1 (en) * 2000-07-10 2002-05-16 Grove Adam J. Method for network discovery using name servers
US7165116B2 (en) * 2000-07-10 2007-01-16 Netli, Inc. Method for network discovery using name servers
US7454523B2 (en) * 2001-03-16 2008-11-18 Intel Corporation Geographic location determination including inspection of network address
US20020143991A1 (en) * 2001-03-16 2002-10-03 Kingsum Chow Geographic location determination including inspection of network address
US20060212601A1 (en) * 2001-03-19 2006-09-21 Microsoft Corporation Method and system to determine the geographic location of a network user
US7657655B2 (en) 2001-03-19 2010-02-02 Microsoft Corporation Method and system to determine the geographic location of a network user
US7062572B1 (en) * 2001-03-19 2006-06-13 Microsoft Corporation Method and system to determine the geographic location of a network user
WO2005033878A3 (en) * 2003-09-29 2006-04-20 Ebay Inc Method and apparatus for geolocation of a network user
WO2005033878A2 (en) * 2003-09-29 2005-04-14 Ebay Inc. Method and apparatus for geolocation of a network user
US7685279B2 (en) * 2004-03-04 2010-03-23 Quova, Inc. Geo-location and geo-compliance utilizing a client agent
US20060010252A1 (en) * 2004-03-04 2006-01-12 Miltonberger Thomas W Geo-location and geo-compliance utilizing a client agent
US8213898B2 (en) 2004-12-15 2012-07-03 Mlb Advanced Media, L.P. System for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US20090138360A1 (en) * 2004-12-15 2009-05-28 Mlb Advanced Media, L.P. Method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US20110196744A1 (en) * 2004-12-15 2011-08-11 Mlb Advanced Media, L.P. System for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US7486943B2 (en) 2004-12-15 2009-02-03 Mlb Advanced Media, L.P. System and method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US8849255B2 (en) 2004-12-15 2014-09-30 Mlb Advanced Media, L.P. System for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US7929954B2 (en) 2004-12-15 2011-04-19 Mlb Advanced Media, L.P. Method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US20060128397A1 (en) * 2004-12-15 2006-06-15 Choti Joseph F System and method for verifying access based on a determined geographic location of a subscriber of a service provided via a computer network
US20090285211A1 (en) * 2005-01-11 2009-11-19 Matsushita Electric Industrial Co., Ltd. Communication method and receiving terminal
US7924714B2 (en) * 2005-01-11 2011-04-12 Panasonic Corporation Communication method and receiving terminal
US7640339B1 (en) * 2005-02-14 2009-12-29 Sun Microsystems, Inc. Method and apparatus for monitoring a node in a distributed system
US20050204064A1 (en) * 2005-06-23 2005-09-15 The Go Daddy Group, Inc. Resolving access to content associated with shared domain name using routing dns
US9450908B2 (en) * 2005-06-23 2016-09-20 Go Daddy Operating Company, LLC Routing DNS system and method for shared domain name
US8706816B2 (en) 2005-06-24 2014-04-22 Go Daddy Operating Company, LLC System and method for email delivery for shared domain name
US20050216567A1 (en) * 2005-06-24 2005-09-29 The Go Daddy Group, Inc. System and method for email delivery for shared domain name
US20050289242A1 (en) * 2005-06-24 2005-12-29 The Go Daddy Group, Inc. Resolving access to content associated with shared domain name using routing website
US7739680B1 (en) * 2005-07-21 2010-06-15 Sprint Communications Company L.P. Application server production software upgrading with high availability staging software
US20070088818A1 (en) * 2005-10-14 2007-04-19 Cisco Technology Inc. Sharing of presence-based time-zone information
US8078578B2 (en) * 2005-10-14 2011-12-13 Cisco Technology, Inc. Sharing of presence-based time-zone information
US20070260649A1 (en) * 2006-05-02 2007-11-08 International Business Machines Corporation Determining whether predefined data controlled by a server is replicated to a client machine
US8849760B2 (en) 2006-05-02 2014-09-30 International Business Machines Corporation Determining whether predefined data controlled by a server is replicated to a client machine
US9338046B2 (en) 2006-06-26 2016-05-10 Cisco Technology, Inc. Port pooling
US9769253B2 (en) 2006-06-26 2017-09-19 Cisco Technology, Inc. Port pooling
US20100299386A1 (en) * 2006-10-26 2010-11-25 Seanodes Computer-based system comprising several nodes in a network
US20080276004A1 (en) * 2007-05-01 2008-11-06 Cisco Technology, Inc. Populating Location Wiremap Databases
US8838831B2 (en) * 2007-05-01 2014-09-16 Cisco Technology, Inc. Populating location wiremap databases
US20100145814A1 (en) * 2008-12-08 2010-06-10 At&T Mobility Ii Llc Access modeling in a communication domain
CN102014366A (en) * 2009-09-04 2011-04-13 腾讯科技(深圳)有限公司 Method, device and system for updating IP address home information
US20120163372A1 (en) * 2009-09-04 2012-06-28 Tencent Technology (Shenzhen) Company Limited Method, Apparatus And System For Updating Location Information Of An IP Address
US8971313B2 (en) * 2009-09-04 2015-03-03 Tencent Technology (Shenzhen) Company Limited Method, apparatus and system for updating location information of an IP address
US10691730B2 (en) 2009-11-11 2020-06-23 Digital Envoy, Inc. Method, computer program product and electronic device for hyper-local geo-targeting
US20110113116A1 (en) * 2009-11-11 2011-05-12 Jeff Burdette Method, computer program product and electronic device for hyper-local geo-targeting
US8443107B2 (en) 2009-11-11 2013-05-14 Digital Envoy, Inc. Method, computer program product and electronic device for hyper-local geo-targeting
US9112667B1 (en) * 2010-08-31 2015-08-18 William Woodcock Geolocation
US11093955B2 (en) * 2010-09-30 2021-08-17 The Nielsen Company (Us), Llc Methods and apparatus to measure mobile broadband market share
US8838733B2 (en) * 2010-10-20 2014-09-16 Quova, Inc. System and method for managing an internet domain based on the geographic location of an accessing user
US20120102219A1 (en) * 2010-10-20 2012-04-26 Quova, Inc. System and method for managing an internet domain based on the geographic location of an accessing user
US8527633B2 (en) 2011-01-06 2013-09-03 International Business Machines Corporation Techniques for addressing geographical location issues in computing environments
US9451050B2 (en) 2011-04-22 2016-09-20 Go Daddy Operating Company, LLC Domain name spinning from geographic location data
US9838301B2 (en) * 2011-06-30 2017-12-05 Neustar Ip Intelligence, Inc. System and method for predicting the geographic location of an internet protocol address
US9529823B2 (en) 2011-09-07 2016-12-27 Microsoft Technology Licensing, Llc Geo-ontology extraction from entities with spatial and non-spatial attributes
US9967624B2 (en) * 2012-03-02 2018-05-08 Adobe Systems Incorporated Digital rights management using device proximity information
CN103716282A (en) * 2012-09-28 2014-04-09 北京新媒传信科技有限公司 Method and system for correcting IP library
US8756222B1 (en) 2012-11-06 2014-06-17 Google Inc. Systems and methods for confidence-based selection of hierarchical locations
US20140341033A1 (en) * 2013-05-16 2014-11-20 Power-All Networks Limited Transmission management device, system, and method
US10361994B2 (en) 2013-07-12 2019-07-23 Skyhook Wireless, Inc. Mapping/translation techniques for generating associations between network addresses and attributes that were not directly observed
US10305854B2 (en) * 2013-07-12 2019-05-28 Skyhook Wireless, Inc. Ensuring data quality by filtering network address observations
US10594650B2 (en) 2013-07-12 2020-03-17 Skyhook Wireless, Inc. Propagating attributes between network addresses
US10536428B2 (en) * 2013-07-12 2020-01-14 Skyhook Wireless, Inc. Processing multiple network address observations
US10491563B2 (en) 2013-07-12 2019-11-26 Skyhook Wireless, Inc. Determining fixed/mobile and proxy/non-proxy network addresses
US20150019758A1 (en) * 2013-07-12 2015-01-15 Skyhook Wireless, Inc. Processing multiple network address observations
US20150020195A1 (en) * 2013-07-12 2015-01-15 Skyhook Wireless, Inc. Ensuring data quality by filtering network address observations
US9633128B2 (en) 2014-03-13 2017-04-25 Go Daddy Operating Company, LLC Lightweight web page generation
US9660933B2 (en) 2014-04-17 2017-05-23 Go Daddy Operating Company, LLC Allocating and accessing hosting server resources via continuous resource availability updates
US9501211B2 (en) 2014-04-17 2016-11-22 GoDaddy Operating Company, LLC User input processing for allocation of hosting server resources
US9953105B1 (en) 2014-10-01 2018-04-24 Go Daddy Operating Company, LLC System and method for creating subdomains or directories for a domain name
US9779125B2 (en) 2014-11-14 2017-10-03 Go Daddy Operating Company, LLC Ensuring accurate domain name contact information
US9785663B2 (en) 2014-11-14 2017-10-10 Go Daddy Operating Company, LLC Verifying a correspondence address for a registrant
US10164933B2 (en) 2014-12-19 2018-12-25 Go Daddy Operating Company, LLC System and method for domain name system restore points
US10659423B2 (en) 2014-12-19 2020-05-19 Go Daddy Operating Company, LLC System and method for modifying a domain name system template
US10742752B2 (en) 2015-07-22 2020-08-11 Dynamic Network Services, Inc. Methods, systems, and apparatus for geographic location using trace routes
US11399073B2 (en) 2015-07-22 2022-07-26 Dynamic Network Services. Inc. Methods, systems, and apparatus for geographic location using trace routes
WO2017015454A1 (en) * 2015-07-22 2017-01-26 Dynamic Network Services, Inc. Methods, systems, and apparatus for geographic location using trace routes
US11012465B2 (en) 2016-07-21 2021-05-18 Sap Se Realtime triggering framework
US10536476B2 (en) 2016-07-21 2020-01-14 Sap Se Realtime triggering framework
US10482241B2 (en) 2016-08-24 2019-11-19 Sap Se Visualization of data distributed in multiple dimensions
US10542016B2 (en) * 2016-08-31 2020-01-21 Sap Se Location enrichment in enterprise threat detection
US10630705B2 (en) 2016-09-23 2020-04-21 Sap Se Real-time push API for log events in enterprise threat detection
US10673879B2 (en) 2016-09-23 2020-06-02 Sap Se Snapshot of a forensic investigation for enterprise threat detection
US10534908B2 (en) 2016-12-06 2020-01-14 Sap Se Alerts based on entities in security information and event management products
US10534907B2 (en) 2016-12-15 2020-01-14 Sap Se Providing semantic connectivity between a java application server and enterprise threat detection system using a J2EE data
US10530792B2 (en) 2016-12-15 2020-01-07 Sap Se Using frequency analysis in enterprise threat detection to detect intrusions in a computer system
US20180176238A1 (en) 2016-12-15 2018-06-21 Sap Se Using frequency analysis in enterprise threat detection to detect intrusions in a computer system
US11093608B2 (en) 2016-12-16 2021-08-17 Sap Se Anomaly detection in enterprise threat detection
US10552605B2 (en) 2016-12-16 2020-02-04 Sap Se Anomaly detection in enterprise threat detection
US11470094B2 (en) 2016-12-16 2022-10-11 Sap Se Bi-directional content replication logic for enterprise threat detection
US10764306B2 (en) 2016-12-19 2020-09-01 Sap Se Distributing cloud-computing platform content to enterprise threat detection systems
US11128651B2 (en) 2017-06-30 2021-09-21 Sap Se Pattern creation in enterprise threat detection
US10530794B2 (en) 2017-06-30 2020-01-07 Sap Se Pattern creation in enterprise threat detection
US10681064B2 (en) 2017-12-19 2020-06-09 Sap Se Analysis of complex relationships among information technology security-relevant entities using a network graph
US10986111B2 (en) 2017-12-19 2021-04-20 Sap Se Displaying a series of events along a time axis in enterprise threat detection
US20210105305A1 (en) * 2019-10-03 2021-04-08 Accenture Global Solutions Limited Privacy-secure edge-zone computing for secure-operation authorization
US11075959B2 (en) * 2019-10-03 2021-07-27 Accenture Global Solutions Limited Privacy-secure edge-zone computing for secure-operation authorization
US11522920B2 (en) * 2019-10-03 2022-12-06 Accenture Global Solutions Limited Privacy-secure edge-zone computing for secure-operation authorization
US20220058278A1 (en) * 2020-08-19 2022-02-24 Docusign, Inc. Using machine learning to bypass activities of a secure document workflow based on recipient profile
US20220058287A1 (en) * 2020-08-19 2022-02-24 Docusign, Inc. Modifying elements of a secure document workflow based on change in profile of recipient
US11599662B2 (en) 2020-08-19 2023-03-07 Docusign, Inc. Bypassing elements of a secure document workflow based on identity of recipient

Also Published As

Publication number Publication date
US6684250B2 (en) 2004-01-27
US7072963B2 (en) 2006-07-04
US20040078489A1 (en) 2004-04-22
US7472172B2 (en) 2008-12-30
US20040068582A1 (en) 2004-04-08
US20040078367A1 (en) 2004-04-22
US20150295881A1 (en) 2015-10-15
US20030074471A1 (en) 2003-04-17
US9021080B2 (en) 2015-04-28
US7809857B2 (en) 2010-10-05
US9413712B2 (en) 2016-08-09

Similar Documents

Publication Publication Date Title
US9413712B2 (en) Method and system to associate a geographic location information with a network address using a combination of automated and manual processes
US7039689B2 (en) Method and system for determining geographical regions of hosts in a network
US7711846B2 (en) System and method for determining the geographic location of internet hosts
US6778524B1 (en) Creating a geographic database for network devices
US8060606B2 (en) Geo-intelligent traffic reporter
Padmanabhan et al. An investigation of geographic mapping techniques for Internet hosts
JP5438811B2 (en) DNS wildcard beaconing to determine client location and resolver load for global traffic load balancing
US7673032B1 (en) Determining the geographic location of a network device
EP2323350B1 (en) Method, computer program product and electronic device for hyper-local geo-targeting
US6826172B1 (en) Network probing using overlapping probe packets
AU2001253189B2 (en) Geographic location estimation method for network addresses entities
AU2001253189A1 (en) Geographic location estimation method for network addresses entities
Luckie et al. Learning to extract geographic information from internet router hostnames
US6401031B2 (en) Travel time obtaining system, local map data server, travel time obtaining server, control methods thereof, and recording medium
US7395353B1 (en) Method and apparatus for processing internet site names through regular expression comparison
WO2000051359A2 (en) Method for determining geographic location of users connected to or using a network
Gharaibeh Characterizing the Visible Address Space to Enable Efficient Continuous IP Geolocation
Kauffman Sources of Change in Internet Protocol Geolocation Databases

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
AS Assignment

Owner name: MORGAN STANLEY SENIOR FUNDING, INC., NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:NEUSTAR, INC.;NEUSTAR IP INTELLIGENCE, INC.;ULTRADNS CORPORATION;AND OTHERS;REEL/FRAME:029809/0260

Effective date: 20130122

AS Assignment

Owner name: NEUSTAR IP INTELLIGENCE, INC., VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:QUOVA, INC.;REEL/FRAME:029905/0138

Effective date: 20121221

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: NEUSTAR DATA SERVICES, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: NEUSTAR INFORMATION SERVICES, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: NEUSTAR, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: MARKETSHARE ACQUISITION CORPORATION, VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: NEUSTAR IP INTELLIGENCE, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: MARKETSHARE HOLDINGS, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: ULTRADNS CORPORATION, VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: AGGREGATE KNOWLEDGE, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

Owner name: MARKETSHARE PARTNERS, LLC, VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:043618/0826

Effective date: 20170808

AS Assignment

Owner name: UBS AG, STAMFORD BRANCH, CONNECTICUT

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:MARKETSHARE PARTNERS LLC;AGGREGATE KNOWLEDGE, INC.;NEUSTAR INFORMATION SERVICES, INC.;AND OTHERS;REEL/FRAME:043633/0527

Effective date: 20170808

Owner name: BANK OF AMERICA, N.A., NORTH CAROLINA

Free format text: SECURITY INTEREST;ASSIGNORS:MARKETSHARE PARTNERS LLC;AGGREGATE KNOWLEDGE, INC.;NEUSTAR INFORMATION SERVICES, INC.;AND OTHERS;REEL/FRAME:043633/0440

Effective date: 20170808

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A, NEW YORK

Free format text: GRANT OF SECURITY INTEREST IN UNITED STATES PATENTS;ASSIGNORS:EBUREAU, LLC;IOVATION, INC.;SIGNAL DIGITAL, INC.;AND OTHERS;REEL/FRAME:058294/0161

Effective date: 20211201

Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, NEW YORK

Free format text: GRANT OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNORS:TRU OPTIK DATA CORP.;NEUSTAR INFORMATION SERVICES, INC.;NEUSTAR DATA SERVICES, INC.;AND OTHERS;REEL/FRAME:058294/0010

Effective date: 20211201

AS Assignment

Owner name: NEUSTAR IP INTELLIGENCE, INC., VIRGINIA

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:058300/0762

Effective date: 20211201

Owner name: NEUSTAR INFORMATION SERVICES, INC., VIRGINIA

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:058300/0762

Effective date: 20211201

Owner name: AGGREGATE KNOWLEDGE, INC., VIRGINIA

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:058300/0762

Effective date: 20211201

Owner name: MARKETSHARE PARTNERS LLC, VIRGINIA

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:058300/0762

Effective date: 20211201

Owner name: NEUSTAR, INC., VIRGINIA

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:058300/0762

Effective date: 20211201

Owner name: NEUSTAR IP INTELLIGENCE, INC., VIRGINIA

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:UBS AG, STAMFORD BRANCH;REEL/FRAME:058300/0739

Effective date: 20211201

Owner name: NEUSTAR INFORMATION SERVICES, INC., VIRGINIA

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:UBS AG, STAMFORD BRANCH;REEL/FRAME:058300/0739

Effective date: 20211201

Owner name: AGGREGATE KNOWLEDGE, INC., VIRGINIA

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:UBS AG, STAMFORD BRANCH;REEL/FRAME:058300/0739

Effective date: 20211201

Owner name: MARKETSHARE PARTNERS LLC, VIRGINIA

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:UBS AG, STAMFORD BRANCH;REEL/FRAME:058300/0739

Effective date: 20211201

Owner name: NEUSTAR, INC., VIRGINIA

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT RELEASE;ASSIGNOR:UBS AG, STAMFORD BRANCH;REEL/FRAME:058300/0739

Effective date: 20211201

AS Assignment

Owner name: SONTIQ, INC., MARYLAND

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: MARKETSHARE PARTNERS, LLC, VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: NEUSTAR IP INTELLIGENCE, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: NEUSTAR, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRUSTID, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: NEUSTAR INFORMATION SERVICES, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRU OPTIK DATA CORP., ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: AGGREGATE KNOWLEDGE, LLC, VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRANSUNION TELEDATA LLC, ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRANSUNION RENTAL SCREENING SOLUTIONS, INC., ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRANSUNION INTERACTIVE, INC., ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: TRANS UNION LLC, ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: SIGNAL DIGITAL, INC., ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: IOVATION, INC., ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

Owner name: EBUREAU, LLC, ILLINOIS

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 058294, FRAME 0161;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:058593/0852

Effective date: 20211223

AS Assignment

Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, NEW YORK

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE APPLICATION NO. 16/990,698 PREVIOUSLY RECORDED ON REEL 058294 FRAME 0010. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:TRU OPTIK DATA CORP.;NEUSTAR INFORMATION SERVICES, INC.;NEUSTAR DATA SERVICES, INC.;AND OTHERS;REEL/FRAME:059846/0157

Effective date: 20211201

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FEPP Fee payment procedure

Free format text: 11.5 YR SURCHARGE- LATE PMT W/IN 6 MO, LARGE ENTITY (ORIGINAL EVENT CODE: M1556); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12