METHOD FOR GEOGRAPHICALLY TARGETING ONLINE ADVERTISING CAMPAIGNS

RELATED APPLICATIONS

This application claims priority to United States Application number 61/500,482 filed June 23, 2011, the contents all of which are hereby incorporated by reference in their entirety.

1. BACKGROUND OF THE INVENTION

1.1 Field of the Invention

The present invention relates to the field of online advertising. In particular, the present invention relates to a geographical targeting solution to improve the effectiveness of advertising campaigns in the online environment across a variety of ad platforms.

1.2 Background Information

The rise of the Internet has seen an accompanying increase in the popularity of online ad platforms as a means to advertise products and services. The advertising market continues to go through structural changes as time spent online continues to grow, while newspaper and other traditional media use declines. As online content creation and distribution costs continue to decrease, competition between traditional and online media is expected to intensify, bringing new content producers into the market.

Consumers continue to expect ubiquity of content and the ability to share this content. Traditional media sources are not equipped to fulfill these changes in consumer habits and the trend toward online publishing and advertising is expected to grow. While currently representing only 10% of total advertising expenditures in 2009, Internet advertising is expected to double by 2014 while most other platforms are stagnant or declining. Currently the Internet accounts for 20% of overall media consumption but only 10% of advertising budgets. As a result, there is a tremendous potential for growth as advertisers bridge this gap. Furthermore, as Internet advertising grows, competition among advertisers will increase. Finding a competitive advantage within this market will be key in order for advertisers to get their message across.

Several different online advertising networks have evolved, including: Google™ AdWords, Facebook™ ads, and embedded ads on YouTube™. These and other ad environments typically offer the ability to target people based upon general demographic filtering, as well as targeting based upon the consumer's geographic location ("geotargeting").

The existing methods available for the geo-targeting of online advertising are, however, very general and do not help businesses understand where to locate more customers. For instance, Ad platforms such as Goog le™ AdWords or YouTube™ offer the ability to geo-target advertising, however the available functionality provided is extremely limited and offers only a crude implementation of this powerful opportunity to reach potential new markets. The limited capacity of existing geo-targeting options results in many businesses having poor or inefficient performance with their geo-targeted ad campaigns.

Current geo-targeting solutions typically offer the ability to target general geographic regions, such as entire states (e.g. California) or entire cities (e.g. San Francisco). They also provide the capacity to target within a distance radius (e.g. 50 km) of a location point, such as a business address or point of interest. Platforms such as Google™ AdWords and YouTube™ also include a functionality called "custom shapes" which allow campaign managers to define arbitrary geographic boundary regions by uploading sets of latitude/longitude point values. These "custom shapes" permit an exact definition of the geographic boundaries within which to place a particular ad.

Although solutions such as these allow for more precise geo-targeting, businesses are not provided with any assistance for the complex process of determining and optimizing these boundary shapes. This divide between theory and implementation ensures that the majority of online campaigns are either not geo-targeted, or poorly geo- targeted.

In view of these geo-targeting issues within the online ad space, it would be of great benefit to provide a solution to allow businesses the ability to intelligently and accurately geotarget their ideal customers in order to increase sales.

2. SUMMARY OF THE INVENTION

One aspect of the present invention is to improve the accuracy and effectiveness of the geotargeting of online advertisements, across a variety of online ad platforms, by transforming client sales data, geographically referenced attribute data, and geographic boundary data into sets of geographically referenced polygons which may be implemented for ad geotargeting purposes.

Another aspect of the present invention is to provide a method for importing and storage of spatially referenced attribute data into a spatial database. The spatially referenced attribute data may be input from, but are not limited to, the following sources: a) Demographic / Census Data, b) Attitude Data, c) Expenditure Data, d) Behavior Data.

Another aspect of the present invention is to provide a method for importing and storage of geographic boundary data into a spatial database, as defined by sets of latitude/longitude values, for the purpose of determining spatial filtering parameters. The geographic boundary data may have, but are not limited to, the following spatial formats: a) National, b) Regional, c) State or Province, d) City, e) Metropolitan Area, f) ZIP or Postal Code, g) Area Code, h) Neighborhood, i) Census Tract.

Yet another aspect of the present invention is to provide a method for importing and storage of client-provided location information into a database, whereby the location data is first processed to remove errors, converted to a standardized format of latitude/longitude points (geocoded), then stored in a spatial database. The input client location information may have, but is not limited to, the following point-based input formats: a) Mobile Network Coordinates, b) Street Address, c) GPS Coordinates, d) Latitude/Longitude. The input client location information may also have, but is not limited to, the following polygon-based input formats: e) Area Code, f) IP Address, g) City, h) ZIP or Postal Code, i) State or Province, j) Region, k) Custom Boundary, I) Neighborhood.

A further aspect of the present invention is to provide a method for filtering geographically referenced attribute data, client custom field data, and spatial boundary data, for the purpose of conforming to the geotargeting goals of a client's online advertising campaign.

Another aspect of the present invention is to provide a method to calculate the spatial scope statistics for a series of geographically referenced attribute variables, by calculating average statistical values for discrete geographic neighborhoods, as well as calculating average values for entire regions that define the geographic scope for a geotargeted online advertising campaign. Another aspect of the present invention is to provide a method for calculating the spatially proportioned weight statistics for a series of geographic point locations, as defined by geocoded latitude/longitude values, by calculating the average attribute values for these point locations.

Another aspect of the present invention is to provide a method for establishing useful geographic buffer areas around geographic points, as defined by geocoded latitude/longitude values, for the purpose of calculating statistically relevant, indexed attribute values for these points.

Another aspect of the present invention is to provide a method for indexing and sorting attribute variables based upon their relative value contribution within a defined geographic area, when compared to all other geographic areas as defined by the geographic scope of a geotargeted online advertising campaign.

Another aspect of the present invention is to provide a method for determining the relative value contribution (i.e. the weight) for typically between, but not limited to, 1 to 5 attribute variables that have been co-related to a particular geographic neighborhood, as selected from a master list of indexed, normalized attribute variables.

Another aspect of the present invention is to provide a method for assigning an ordered ranking to a collection of geographic neighborhoods by calculating the sum of a series of 1 or more normalized, indexed attribute variables which have been calculated for each individual neighborhood.

Another aspect of the present invention is to provide a method for creating geometrically optimized spatial aggregates of selected neighborhoods (known as GeoSh pes) via the use of: neighborhood circumference calculation algorithms, the elimination of spatially isolated neighborhoods with fewer than a minimum number of adjacent neighborhoods, the application of polygon line-generalization algorithms, the application of circular buffer approximation algorithms, the removal of internal void spaces that exist within aggregated shapes, and the splitting of larger shape aggregates into smaller shapes as guided by ad platform data import limits.

Another aspect of the present invention is to provide a method for creating a list of geographically referenced polygons (i.e. GeoShapes) that have been ranked according to index values that have been calculated for each polygon.

3. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a Master Flow Diagram which shows the main logical components of the present invention, and illustrates a summary of how the present invention initializes the GIS Server and Spatial Database, imports location data from a client, processes the data through several core procedures, and then outputs final results.

FIG. 2 is a flow diagram for the GIS Server & Data Setup, showing the connection between the primary components of the GIS server architecture and the initial data import procedures for the present invention.

FIG. 3 is a flow diagram for the Import Client Data to Database and Geocode Data procedure, which shows how the present invention accepts client location data then converts it to geometric data in a format required for the following steps. FIG. 4 is a flow diagram to Determine Client Targeting Scope for the present invention, showing the steps required to determine the ad campaign scope for the geotargeting operations.

FIG. 5 is a flow diagram for the Attribute Indicator Analysis for the present invention, which shows the process used by an automation script whereby spatially referenced attribute variables are indexed, selected and weighted.

FIG. 5b is a flow diagram for the Calculate Location Data Statistics in the present invention, which shows the process used by an automation script that calculates and assigns normalized attribute values to location data.

FIG. 6 is a flow diagram for the process of GeoShape Creation for the present invention, showing the steps used by an automation script whereby optimized geographic polygons are created, indexed and sorted.

FIG. 6b is a flow diagram for the Shape Geometry Optimizer for the present invention, showing the steps used by an automation script whereby a collection of GeoShape polygons are fine-tuned to remove inefficiencies and maximize relevance.

FIG. 7 is a diagram of the Database Table Structure, showing the table layout, including all table fields and table relationships, for an exemplary database of the present invention.

FIG. 8 is a collection of data tables showing Sample Data Input Rows, indicating a sampling of the different types of data fields which may be input into the present invention.

FIG. 9 is an overview of the hardware architecture for the GIS Server computing environment for the present invention.

4. DETAILED DESCRIPTION

The present invention details new methods for the geotargeting of advertising in the online environment. The following description is presented as a means for one who is skilled in the art to create and use the invention for its intended purpose as described herein. Other embodiments of this invention may be apparent to those who are skilled in the art, and this document intends the patentable technology to apply to all such potential applications.

4.1 Definitions

"Geotargeting" is a method of online content delivery that provides different content to users based upon their geographical location, considering factors such as country, state, city, ZIP code, IP address or latitude/longitude coordinates. Online geotargeted methodologies have many uses, including: pay-per-click advertising based on user location, content-localization for website providers, media copyright restrictions based on country, display network advertisements that show various types of location-sensitive ad banners, website data analytics (such as via Google Analytics), city-based advertising campaigns, and content that is time-sensitive based on the user's time zone. By serving out different content to users based on their geographical location, the experience of the online environment can be greatly enhanced and personalized, with potential for much greater efficiencies.

The acronym "GIS" is terminology that means "Geographic Information System", or "Geospatial Information System", that describes any information system that integrates, stores, edits, analyzes, shares, and displays geographic information for informing decision making. GIS applications are tools that allow users to create interactive queries (user-created searches), analyze spatial information, edit data & maps, and present the results of all these operations. GIS is the merging of cartography, statistical analysis, and database technology.

The "Geocoding" of data refers to the process whereby geographic location data, such as street addresses or zip codes, are translated into a usable geographic coordinate system, typically expressed as latitude and longitude data points.

"GeoShapes" are a collection of one or more polygons, with each polygon defined by a series of 3 or more geographic coordinates, with each geographic coordinate expressed by a latitude & longitude data point. The series of data points that comprise a single GeoShape are constrained such that a line connecting 2 adjacent points may not intersect the line connecting any other 2 adjacent points. The geometry of a GeoShape may also be approximated with a circle, as defined by a center point expressed by a latitude & longitude data point, and a radius value expressed in kilometers. When a collection of GeoShape polygons are overlaid on top of their associated geographic map, they delineate a potentially non-contiguous boundary condition for a specific geographic area. GeoShapes are the primary output of the present invention.

A "Neighborhood" or "Attribute Area" is defined as a populated area of variable size that generally contains between 500 to 3,000 people. These areas are co-related to the attribute information used to geotarget an online ad campaign. These terms may refer to any other type of geographic boundary region that can potentially be used for GeoShape creation.

An "Online Ad" or "Ad" refers to an advertisement for a product or service that is distributed over the Internet. Online ads are typically shown on websites, both personal & professional, and search engine results pages, such as the Google search engine results page. An online ad will usually contain an image of a product or service, a text description of the product or service, and an interactive link which redirects users to another webpage which is used by the vendor to complete the sale of their product or service.

An "Online Ad Platform" is an online environment that supports the creation, distribution and tracking of client- created online ads. Online ad platforms may be represented by any place on the Internet that incorporates advertising into their model of operation, and includes a system by which clients may create and distribute their own online ads to sell products or services. Ad platforms may distribute ads to a variety of different environments, including computers, mobile devices, digital phones, computing tablets, or other Internet-ready devices. Examples of online ad platform types include: online search engines, community video websites, social networking websites, and e-commerce websites.

The term "Customer" or "Consumer" refers to the online end-users who view online ads and potentially purchase the advertised products or services.

The term "Client" refers to the creator of an online ad and is the end-user of the output of the present invention. This is the agent who places an ad on an online ad platform for the purpose of selling their particular product or service, and is the provider of all client location data.

"Client Location Data" or "Client Sales Data" refers to historical sales data provided by a business client which itemizes previous sales transactions over a period of time, typically spanning several months or years. These transaction lists include the geographic location information of the past customers. This location information may be in the format of latitude/longitude data points, or may be more commonly listed as street addresses, in which case a geocoding process will be required to convert the data into standardized latitude/longitude data points. Other client sales data formats may also be supplied that are specific to each individual client, such as other types of point data (in which case a geocoding process may also be necessary) or polygon-based location data.

An "Attribute Variable", "Attribute Data", or "Variable", refers to the data found in a source of spatially referenced attribute data, such as a demographic census database, which describe the attributes for collections of neighborhoods of people. Examples of attribute variables include, but are not limited to: Income, Age, Gender and Ethnicity.

A "Normalized Variable" is a variable whose value has been converted to a percentage or fractional value, for the purpose of standardizing variable values so that they can be compared to one another.

A "Variable Weight" is the proportional statistical significance granted to one variable relative to one or more other variables, in the context of two or more variables that have been selected for analysis as a group. The "weight" of all variables in a grouping will equal 100% (or normalized to a value of 1.0). A variable weight value is typically used as a multiplier in statistical calculations.

An "Indexed Variable" refers to one of a collection of several attribute variables that have been normalized and weighted so that exceptional variables which are above the average within the geographic scope may be identified.

4.2 Exemplary Embodiments - Overview

The present invention is a system comprised of many interdependent software components, database structures, automation scripts, hardware components, manual processes & analytic procedures, and control interfaces. The system imports data from several different sources, such as historical sales data from clients and from other commercial or public sources, and ultimately transforms this data into sets of geographically referenced geotargeting polygons for use in a wide range of online ad platforms. These ad platforms can employ the output of the present invention to increase their effectiveness by boosting online sales while reducing the associated advertising costs. Following is an overview of the process, as illustrated in the Master Flow Diagram FIG. 1, and all of the remaining Figures in this document will be explained in detail in sections 4.2.1 Exemplary Methods, and 4.2.2 Exemplary Data Structures.

Before the present invention can begin a standard cycle of calculation operations for a client, the GIS Server and Spatial Database must be initialized and configured. The GIS Server & Data Setup, as described in FIG. 2, involves the creation of all required data tables in the Spatial Database, and then the importing of spatially referenced Attribute Data and geographic Boundary Data into the Spatial Database via data import scripts. In an exemplary embodiment, all of the automation scripts used by the present invention are typically stored on the server computer alongside the Spatial Database. While several scripts are completely automatic, some of the scripts have their parameters selected and are manually activated by an operator interacting with a Web-based Graphical User Interface (GUI). However, potential embodiments of the present invention may fully automate the manual control aspects for all automation scripts, and this would be well within the capabilities of a person skilled in the art. In addition to the automation scripts, a collection of GIS Spatial Functions communicates with the Spatial Database to analyze the data using several mathematical and geometrical calculations. After the system has been initialized, it is ready to receive new client data. In an exemplary embodiment of the present invention, the client will upload or send their historical sales data via email, secure FTP, direct database connection, portable hard disk, USB storage media, or via other data transfer media, of which a common data file format is the Microsoft™ Excel document format (due to its ubiquity of use in the business community). In an exemplary embodiment of the present invention, this data file is manually received by an operator, and is then cleaned and verified via a combination of short verification scripts and verification procedures. Alternate embodiments of the present invention may fully automate this data import and verification process, without the need for sophisticated or innovative algorithms. This would be well within the capabilities of a person skilled in the art. The next step is to Import Client Data to Database and Geocode Data, as described in FIG. 3, whereby the cleaned and verified client data is stored into the Spatial Database, and then converted into a standardized format of geographic coordinates, which is a process known as Geocoding.

The next step of the present invention is the process to Determine Client Targeting Scope as describe in FIG. 4, whereby the initial client input dataset may be reduced to a subset of the original input dataset, as determined by spatial and attribute parameters corresponding to the geotargeting goals of the client. This client data scope-filtering also creates a subset of any custom attribute fields provided by the client. In an exemplary embodiment of the present invention, the filtering procedures of this step are accomplished by automation scripts, whereby the parameters of the scripts are manually selected by the client via a Web-based GUI. After filtering parameters have been determined, SQL queries are constructed based upon the selections and are submitted to the database to create a filtered subset of the data.

After the client's geotargeting scope has been determined, the next step for the present invention is the Attribute Indicator Analysis process, as described in FIG. 5, which is performed by an automation script that utilizes the Spatially Referenced Attribute Data to calculate the key spatial scope and sales location data statistics for each attribute variable. An associated automation script is also used to Calculate Location Data Statistics, as described in FIG. 5b. These scripts calculate how each geographic client location spatially co-relates with the geographically referenced attribute variables. Using a further series of statistical calculations, all attribute variables are then indexed and sorted to determine which attribute variables have the highest co-relation to the client's location data, and the best attribute variables (typically between 1 to 5 variables) are selected based upon their ranking within the ordered indexed list. Statistical weights are assigned to all selected top variables, in order to give a relative importance to all selected top attribute variables when analyzed together as a group. The scripts that are used for this step are responsible for calculating the key statistical values that are used for building the final geographically referenced result, as follows.

The next step for the present invention is the GeoShape Creation process, as described in FIG. 6, which is an automation script that is used to construct geographically referenced polygon sets, or rank existing polygon sets, that highlight the geographic regions of maximum statistical co-relation for the preceding stages of the analysis. Neighborhood areas are ranked according to their attribute variables and calculated weights through a multi-criteria evaluation. The creation of custom shapes involves spatially aggregating clusters of high opportunity neighborhoods. A supplementary script is used to optimize the shapes with the Shape Geometry Optimizer, as described in FIG. 6b. This shape optimization process is an important step to prepare the GeoShape results for integration with different ad platform environments (e.g. as preparation for use in Google™ AdWords or other ad platforms). The intersection of the shapes and the underlying attribute co-related neighborhoods is calculated to build a spatially proportioned weight for each GeoShape, which are then indexed and sorted into an ordered list. The scope of the client's geotargeting request will determine whether the process continues processing another loop of GeoShape creation for another ad campaign. When this processing loop has been completed, the GeoShapes are ready for implementation into any of several different ad platforms.

Once all GeoShapes have been created for the current set of ad campaigns, for all required ad platforms, the results are delivered to the client. The client may then insert the resulting GeoShape data into their online ad platforms via the interfaces provided by those ad platforms.

Following is the full and detailed explanation of all Figures and processes for the present invention.

4.2.1 Exemplary Methods

As illustrated in Master Flow Diagram FIG. 1, the first step in the process of the present invention is the configuration and initialization of the system via the GIS Server and Data Setup, as more fully portrayed in FIG. 2. This diagram shows all of the key software and data components that are required for the operation of the present invention.

The Spatial Database 200 is the core of many operations, and several processes will directly or indirectly interact with it. For an exemplary embodiment of the present invention, this database is a PostgreSQL 8.4.5 database, which is an open-source O DBMS (Object Relational Database Management System). This choice of database is not exclusive to the implementation of the present invention, and many other alternate embodiments are possible. This database is installed on the GIS Server 900.

The initialization of the Spatial Database 200 requires the importing of several key elements, the first of which is the collection of GIS Spatial Functions 205. The GIS processes implemented by the present invention rely upon these GIS Spatial Functions for all of the many spatial calculations. The present invention uses the PostGIS 1.5 spatial extension for PostgreSQL to implement this functionality (as an example of a non-exclusive choice of implementation for an exemplary embodiment of the present invention). The GIS Spatial Functions are software and database independent and may be implemented in any number of different ways, whereby the choice of implementation is not a constraint of the present invention. These functions are considered standard functionality in many commercially or publically available GIS packages, and thus do not require innovative solutions for their individual implementation. For an example of how these functions are used in the code, please refer to the code sample in section 4.3.2. Following is a list of the GIS Spatial Functions 205 used by the present invention:

Exterior Ring (used in steps 610, 645) - This function returns a polygon object of the outermost ring in a string of points. This is useful when removing inner 'doughnut' holes or void holes from a polygon object.

Dump (used in step 610) - This function can break a single multi-polygon object into individual standalone, non-touching polygon objects.

Union (used in step 610) - This function is used to merge touching or overlapping polygon objects into a single polygon object. This function also dissolves the inner boundaries of the original polygons, taking the outermost ring in a string of points.

Intersection & Intersects (used in steps 550, 620) - These are spatial topology functions which test if Object A and Object B are touching or overlapping in any way, then return a new polygon object of the overlap found between Object A and Object B. Intersect is used to detect all database rows where Object A and Object B share the same space. Intersection is used to create the actual geometry where Object A and Object B share the same space.

Number of Points (used in step 680) - This function will return the number of points found within each polygon object. This function is useful when trying to identify complex polygons which will require simplification.

Simplify with Preserve Topology (used in step 685) - This function uses the Douglas Peucker line simplification algorithm which can eliminate unnecessary points within a polygon object based on a tolerance parameter. As the size of the tolerance parameter increases, the polygon object will become further simplified in shape. This function also enforces the rules of spatial topology to prevent self intersection or the creation of invalid polygon objects.

Distance (used in steps 650, 660, 674, 690) - This function is used to measure the distance between Object A and Object B. This function is useful when identifying polygons with points that are too close together (requiring shape simplification), and it is also useful when determining the width and height of a polygon.

Buffer (used in step 545, 676) - This function creates a larger polygon based on a geometrical shape. The new polygon is generated based on a specified distance from the original shape and fully covers the original.

Area (used in steps 550, 620) - This function calculates the surface area of a polygon. The measureable units come from the data projection.

Within (used in step 695) - This function is used to determine any geometrical objects that lie within a polygon.

Centroid (used in step 672, 695) - This function takes a polygon and generates a point that lies at the geometrical center of the shape. The output point is within the boundaries of the original shape.

Extent (used is step 674) - This function returns the coordinate values of the "minimum bounding rectangle" of any polygon object. This function determines the spatial limits of each object (i.e. xmin, ymin, xmax, ymax) and returns a box object which is defined by the lower-left and upper-right coordinate pairs. An example of the query result is as follows: BOX (-119.521, 49.762, -119.326, 49.894)

Split (used in steps 655, 665) - This function uses a polygon and a line to split the polygon into 2 separate shapes. The splitting edge is defined by the line.

Convex Hull (used in step 610) - This function creates a convex polygon (i.e. contains no concave angles) based on an original polygon. It uses the outermost nodes of the original geometrical shape and connects them to form linear lines encompassing the original geometry.

The next required database import operation is to Import Boundary Data 210 into the Spatial Database 200, which is processed via the Attribute and Boundary Data Import Script 225. The Boundary Data used by the present invention is in the format of GIS polygon data, in which a string of latitude and longitude coordinates is used to delineate a specific spatial area on the Earth's surface. All Boundary Data is referenced using a unique identifier, allowing for direct relationships with Spatially Referenced Attribute Data, as presented in table 810 of FIG. 8. The imported boundary data is typically in, but not limited to, one of the following formats: National, Regional, State or Province, City, Metropolitan Area, ZIP or Postal Code, Area Code, Neighborhood, Census Tract or Other Boundary Data types. The next step is to Import Spatially Referenced Attribute Data 215 into the Spatial Database 200, via the Attribute and Boundary Data Import Script 225. Attribute Data consists of the attributes or information associated with geographical features. The Attribute Data used by the present invention is in a database table format, where many columns of attribute variables are spatially referenced by individual Boundary Data unique identifiers as presented in table 800 of FIG. 8. The imported attribute data is typically from, but not limited to, one of the following sources: Demographic/Census Tract, Attitude Data, Expenditure Data, Behavior Data, or Other Spatially Referenced Attribute Data sources.

The Client Location Data 220 is the other type of data that is used by the present invention. FIG. 2 shows this data is imported and related to the Spatial Database 200, however the actual import operation is delayed until the Import Client Data to Database and Geocode Data stage, as discussed in FIG. 3.

The present invention uses several script modules to perform the core operations of data importing and statistical calculation. These Automation Scripts 222 are stored on the GIS Server 900, and are divided into separate files according to their functionality. Each script communicates with the Spatial Database 200 via a database connection. The Attribute and Boundary Data Import Script 225 is responsible for importing new data into the Spatial Database 200 as performed in the Boundary Data 210 step, and the Attribute Data 215 step. The Data Verification Script 230 is responsible for performing data checking operations for all imported client location data. The Address Geocoding Script 235 is responsible for importing and geocoding of client location data as illustrated in FIG. 3 to Import Client Data to Database and Geocode Data. The Targeting Scope Script 237 is responsible for processing the scope filtering operations that correspond to the ad campaign specifications of the client. The Attribute Indicator Analysis Script 240 is responsible for all operations of the Attribute Indicator Analysis stage as illustrated in FIG. 5. The Calculate Location Data Statistics Script 245 is responsible for all operations of the Calculate Location Data Statistics stage in FIG. 5b. The GeoShape Creation Script 250 is responsible for all operations of the GeoShape Creation stage as illustrated in FIG. 6. The Shape Geometry Optimizer Script 255 is responsible for all operations of the Shape Geometry Optimizer stage as illustrated in FIG. 6b. Together these scripts represent all of the Automation Scripts 222 of the present invention, and the further details of their operation will be explained later in this document.

The Spatial Database 200 is also connected to the GIS Mapping and Geoprocessing Software 260 module via a database connection. The GIS Mapping and Geoprocessing Software includes two open-source technologies: GRASS GIS and Mapserver. GRASS GIS is used by the present invention for producing inverse distance weighted (IDW) interpolation maps using neighborhood index values which are calculated and stored within the Spatial Database 200. Mapserver is used by the present invention for producing cartographic maps of the GeoShape output for all advertising platforms and scales of geography.

The GIS Mapping and Geoprocessing Software 260 module is connected to the Application Services 265 module. This module contains all additional software services that have been installed on the GIS Server 900. In an exemplary embodiment of the present invention, the installed components of this module include the following software: Zend Optimizer, ImageMagick and the PEAR framework for PHP.

The Application Services 265 module then connects to the Web Server 270. The primary function of the Web Server module is to deliver web pages on the request to Internet browsers, This means delivery of HTML documents and any additional content that may be included by a document, such as images, style sheets and JavaScript code. For an exemplary embodiment of the present invention, the Web Server uses Apache HTTP Server, commonly referred to as Apache which supports the server-side scripting language, PHP. The server-side scripting function is used to generate and run commands "on-the-fly" as opposed to returning fixed documents. The Web Server also executes the Automation Scripts 222.

The Web Server 270 module then connects to the GIS Interface 275 module. This module is the custom-built front- end interface code, installed on the GIS Server 900 that allows manual control, if desired, of all Automation Scripts 222, and allows the selection of all variable parameters to configure these scripts.

The GIS Interface 275 module is then accessed via Internet Browsers 280, which represents any Internet-enabled device, such as a desktop computer, laptop computer or Internet-enabled mobile device, that is running a Web browser to connect to the Internet via the HTTP Internet protocol. Possible Internet browsers include, but are not limited to, Microsoft™ Internet Explorer, Mozilla™ Firefox, or Google™ Chrome.

The Scripting Language 285 module represents the choice of programming language that has been selected to implement all coding operations for the present invention. The scripting language affects all of the Automation Scripts 222, the GIS Interface 275, the Application Services 265 and the GIS Mapping and Geoprocessing Software 260. In an exemplary embodiment of the present invention, the language used as the choice of scripting language is PHP, which is a general-purpose Web development scripting language.

The initialization of the GIS Server and Spatial Database is a process that occurs once at the beginning of the operation of the present invention, before all other operations can commence. However, future operations may require an additional configuration step for the Potential Updates of Boundary and/or Attribute Data 100. Such a situation will be required whenever new Boundary Data 210 or Attribute Data 215 is acquired for integration with the present invention. This situation will occur, for example, whenever data for a new geographic territory (such as a new country) is added to the data processing scope of the present invention. For example, if the present invention has already been configured with imported Boundary Data 210 and Attribute Data 215 for the United States & Canada, and new data for Mexico was to be acquired, this additional step would be processed before the present invention could provide results for the new country. Similarly, new Attribute Data 210 may be acquired for importing at any time, for any geographic scope, from any of the data sources as already described. This data update step would also be required to integrate the new Attribute Data 215 into the Spatial Database 200.

After the present invention has been initialized and/or updated, it is ready to Receive New Client Data 110. In an exemplary embodiment of the present invention, the client will manually upload or send their historical sales location data via email, secure FTP, portable hard disk, USB storage media, direct database connection, or via any other data transfer method. A common data file format for the transmission of client location data is the Microsoft™ Excel document format, due to its ubiquity of use in the business community. However, alternate embodiments of the present invention could potentially accept any possible data format for this purpose, such as plain text files or database files that correspond to any of the publically or commercially available databases that may be in use by a client. In one embodiment of the present invention, the client data is manually received by an operator who then manually initiates the steps that follow. Alternate embodiments of the present invention may automate the acquisition of new client data via a variety of methods, such as by using automated, direct database transfers. The potential development of such an automation system for receiving new client data would not require innovative procedures, and is well within the capabilities of a person who is skilled in the art.

The location data that is sent from the client may be in either Point or Polygon format. Examples of point-based location data include, but are not limited to, Mobile Network Coordinates, Street Addresses, GPS Coordinates, or Latitude/Longitude values. Examples of polygon-based location data include, but are not limited to, Area Code, IP Address, City, ZIP or Postal Code, State or Province, Region or other types of custom boundaries.

Once the client location data has been received, the next step is to Clean and Verify Client Data 120, by running the Data Verification Script 230, which is typically located on the GIS Server 900. If the previous step to Receive New Client Data 110 has also been fully automated, then this script will be automatically activated, and will otherwise be manually activated by an operator after receiving the new client data. The first step the script uses to verify the data is to check that the required data columns have been included in the input dataset. If the client has provided street address data, the following columns must be present in the data: a) City, b) State, c) Country, and d) Address. This ensures that further geocoding operations may proceed without error. A single column containing all this location information (i.e. address, city, state or province, country, address, etc.) is also accepted. The script then proceeds to parse the input data file, and scans each address row. The script will then: a) remove or replace invalid characters (particularly from foreign addresses), b) remove any row of addresses that are duplicated, and c) remove any rows that contain no data or a blank row. The script uses SQL to insert the cleaned data into the database in the ClientJD Upload Data table 720, and it also creates a data upload tracking record in the Client Upload Log table 760.

The next step in the present invention is to Import Client Data to Database and Geocode Data as described in FIG. 3. The operations of this Figure are executed by the Address Geocoding Script 235 automation script that is typically located on the GIS Server 900. This script will be automatically activated after the completion of the client location data cleaning process as detailed in the preceding steps.

The cleaned and verified data is entered into the Spatial Database 200, and each data record is sequentially analyzed to determine the Data Type 300. If the data format of a client location record is of the type: GPS Coordinates, Latitude/Longitude values, or Mobile Device Coordinates, then no further modification to the data is required since such a data record would already be in a geographical coordinate format, and the data is stored in the Spatial Database 200 as a geometry record via the Create Geometry step 330.

If the input data format is of the Street Address type, then the record must be geocoded into a standardized latitude/longitude (x,y) format via the Geocode Address step 320. The geocoding process can be accomplished via several different methods, and the choice of method is not particular to the implementation of the present invention. In a preferred embodiment of the present invention, the geocoding of location records proceeds by accessing an online geocoding service via an API request method sent from the Address Geocoding Script 235 automation script. Examples of publically available geocoding services include the Yahoo!™ PlaceFinder API and the Google™ Geocoding API provided by Google™ Maps, both of which allow geocoding operations for large volumes of records. Using one of these API's, the present invention sends a request for each record to the online geocoding service and waits for a response. Upon receiving a valid response, the process then proceeds to create a geometry record in the Create Geometry step 330. If the geocoding service returns an error code, the automation script skips the address (and it will not be used in the analysis), then continues the geocoding process for all remaining records. Sample code for the Address Geocoding Script 235 can be found later in this document in section 4.3.1.

If the input data format is of the type: City, State, Region, ZIP or Postal Code, Area Code, or Custom Boundary, then the process will execute the Fetch Boundary step 310 for this geographic area, whereby the geometry data is retrieved from the Boundary Data 210 as already stored in the Spatial Database 200. A boundary dataset is a polygon defined as a series of 3 or more geographic coordinate data pairs that define a geographical region. Once this geometry data has been retrieved, the process continues to process the next record. The next step in the present invention is the process to Determine Client Targeting Scope, as illustrated in FIG. 4. This step uses the Targeting Scope Script 237 to perform its calculations. This shows the method by which the present invention filters the client's custom field data and spatial data to satisfy the geotargeting requirements of the client's online ad campaign initiative. The first stage in the scope-filtering process is to Determine Client Ad Campaign Specification 400. This stage requires the transmission of ad campaign parameters from the client, as selected by the client via a Web-based GUI. The Web-based interface allows the client to indicate all the relevant parameters for a particular ad campaign, as detailed below. Once a client has selected all of the required options via the selection interface, the processing scripts in the steps that follow are then activated. The structure of the Web-based GUI is a simple online form, and the development of such a system is well within the means of someone skilled in the art. In an alternate embodiment of the present invention, this configuration information may be transmitted via other means of consultation with the client, such as via email, voice conversation, written request, or other communication channels, whereby the client indicates the specific parameters of the advertising campaign (or multiple campaigns) they wish to geotarget. If this information is gathered with such a manual method, the information can be entered into the Web-based GUI via an operator acting on behalf of the client. As an example of how to potentially configure an ad campaign, a client may wish to target a service specifically to women (a client custom field) who live in the city of San Francisco (requiring spatial data filtering), and these parameters are used to configure the steps that follow.

Once the ad campaign specifications have been determined, the next step is to Filter Client Custom Field Data 410. This step selects from the available custom data fields which are stored in the Client Location Data 220, based upon the needs of a particular ad campaign. Custom field data may or may not have been provided by a client, and therefore this step is not always required. An SQL database query is constructed to filter the data, based upon the selections made in the preceding step. The resulting SQL Where_Clause field is stored in the Spatial Database 200 in the Client Indicator Log Table 770. This SQL code is then executed and the resulting client custom field data subset is stored back into the Spatial Database 200 in the ASCJD Locations Table 730.

The next stage in the process is to Filter Spatial Data 420. Another SQL query is constructed to select from the relevant Boundary Data 210 based upon the ad campaign specifications. The SQL code is built based upon the selections made during the step to Determine Client Ad Campaign Specification 400. The SQL query is then executed and the results are stored back into the Spatial Database 200. The Within GIS Spatial Function is also used during this operation. The Boundary Data 210 is typically filtered according to the selection of 1 or more of the following: a) National, as defined by selection of country, b) 1 or more Regions, as defined by geographic areas typically spanning 1 or more state or provinces, c) 1 or more states or provinces, as defined by standard state or provincial borders within a country, or d) 1 or more metropolitan areas, as defined by an aggregate city area that often includes multiple suburban areas around a city core.

Once the client's ad campaign scope specifications have been determined, the present invention is ready to begin its core set of geotargeting calculations for an ad campaign. This next stage in the process is the Attribute Indicator Analysis, as illustrated in FIG. 5. The processing for all the steps in this stage are handled by a the Attribute Indicator Analysis Script 240 automation script that is located on the GIS Server 900, which is automatically activated after the client targeting scope has been determined (as illustrated in FIG. 4), after the completion of the Filter Spatial Data step 420.

This stage begins with the step to Calculate Attribute Normalization (AN) Values 500 for each attribute variable in the Spatially Referenced Attribute Data 215. This calculation is shown below in Function (1): Attribute Normalization (AN)

w A M _{/ \} attr_var(y,z)

vattr area, am var : AN(y,z) = — -

- norm_var(y,z)

(l)

Where y = the neighborhood array index, and z = the attribute variable array index, for all neighborhoods in the geographic scope, and for all attribute variables, divide the attribute variable by the normalization variable to find the Attribute Normalization (AN) percentage values. The normalization variable refers to the total population or the total number of households of a particular neighborhood. The properties of the normalization variable also depend on the nature in which the data was originally collected; these values are typically unprocessed statistics, such as total population, total adult population, or total number of households.

The next step is to Calculate Spatial Scope Statistics 510 for each attribute variable in the Spatially Referenced Attribute Data 215. This is accomplished by finding the Region Average (RA) values, as shown in Function (2):

Region Average (RA)

Vattr_var. RA(z) = Avg (AN(y ₍ z) )

(2)

Where y = the neighborhood array index, and z = the attribute variable array index, for all attribute variables, this finds the average Attribute Normalization (AN) value for all neighborhoods in the geographic scope (example geographic scopes include: country, region, state, or metropolitan area).

The next step (which runs in parallel with the preceding step) is to Calculate Location Data Statistics 515. This process, as illustrated in FIG. 5b, is controlled by the Calculate Location Data Statistics Script 245 automation script, located on the GIS Server 900. The input into this script is the output from the Calculated Attribute Normalization (AN) Values 500 step.

The first step in this stage is to determine the Data Type 540 of each geolocation from the Client Location Data 220. If the data type of a client location is determined to be in Point format then the process continues to the Create Buffer Area (BA) step 545, as illustrated in Function (3):

Buffer Area (BA)

V/oc: BA(x) = Buffer( loc(x), radius)

(3)

Where x = the client location array index, for all point locations, the Buffer GIS Spatial Function is used to calculate a radial area of a pre-determined radius around each point location. The radius size of the buffer can be set to any value, although an effective buffer value is one which is approximately the size of a large city block. A typical example of a buffer radius is 150 meters. Alternate embodiments of the present invention may define other sizes of buffer in order to suit other potential applications. If the location data type is of polygon format, then a buffer calculation is not required since a polygon already defines a geographic area, and the process can then continue to the next step. Next in the process is to Calculate Area Intersection (Al) and Location Area (LA) 550 for each geographic location. This begins with the calculation of the location Area Intersection (Al) value, as illustrated in Function (4):

Area Intersect (Al)

VBA: Al(x,y) = Area ( Intersect ( BA(x), attr_area(y) ) )

(4)

Where x = the client location array index and y = the neighborhood array index, for all Buffer Areas (BA), determine the amount of intersecting area between each buffer or polygon and the underlying neighborhoods. This function uses the Intersection, Intersects and Area GIS Spatial Functions. The process will then calculate the overall Location Area (LA) as illustrated in Function (5):

Location Area (LA)

G /oc /oc: LA(x) =∑ Al(x,y)

(5)

Where x = the client location array index and y = the neighborhood array index, for all locations, find the sum of all Area Intersects (Al) for every location, and group the results by location. This sum calculation is particularly relevant when a buffer area overlaps a coastline or other body of water, where the total calculated area could be less than the area of the original buffer.

Next in the process is to Calculate Spatially Proportioned Weight (PW) 555 for each Buffer Area or polygon. The calculation for finding the Proportional Weight (PW) is illustrated in Function (6):

Proportional Weight (PW)

G /OC VAI : PWfoy) =

y LA(x)

(6)

Where x = the client location array index and y - the neighborhood array index, for all locations, divide each value of the Area Intersect (Al) by the Location Area (LA) to find a percentage weight value, grouped by each location.

The final step for the calculation of location data statistics is to assign normalized values to all location data via the step to Calculate Average Client Location Value (ACLV) 560, as illustrated in Function (7):

Average Client Location Value (ACLV)

V/oc: ACLV(z) = Avg (∑ AN(y,z) * PW(x,y) )

(7)

Where x = the client location array index, y = the neighborhood array index, and z = the attribute variable array index, for all locations, multiply each Attribute Normalization (AN) value by each respective Proportional Weight (PW), then find the sum of these values. Once every location has a value, find the average of all location values. This step concludes the processing of the automation script as illustrated in FIG. 5b.

After the statistics have all been calculated for each attribute variable, the present invention continues on FIG. 5 to Calculate Index Variable (IV) Values 520 for each attribute variable, as shown below in Function (8):

Index Variable (IV)

w _lw/ > ACLV(z)

v attr var. IV z = —

RA(z)

Where z = the attribute variable array index, for all attribute variables, find the Average Client Location Value (ACLV) and divide by the normalized Region Average (RA) of the geographic scope. The resulting Index Variable (IV) value is an index value for each attribute variable. An index value greater than 1 indicates that the average client location is located in neighborhoods that have higher-than-average values for that attribute, as compared to the rest of the geographic scope.

The next step in the process is to Sort Indexed Variables 525 according to their index value, using a standard sorting function. From this sorted list, the process will then Select Variables 530, which will identify 1 or more of the top- indexed variables. In an exemplary embodiment of the present invention this variable selection process is made by selecting the first 5 variables in the sorted list, after skipping over any variables that are considered category duplicates. A duplicate category variable is any variable for which a variable has already been selected in the list that is from a similar variable category. Examples of some different variable categories include Income or Education. As an example, if the first selected variable in the list is an Income demographic variable, then if the fifth variable in the list is also an Income variable, then the algorithm will skip the fifth position and instead use the next available variable in the sorted list that represents a unique variable category.

In an alternate embodiment of the present invention, these variable selections may also be made manually by a trained analyst using a Web-based GUI run on an Internet Browser 280. In such a case, the automation script would pause, and resume after the variable selection had been made. The manual selection of top variables could be used to ensure the relevance of the selected variables if the client had particular targeting requirements that may not be satisfied by the automated algorithm.

The next step is to Calculate Variable Weight (VW) Values 535 for each attribute variable that has been selected in the preceding step. This calculation is illustrated in Function (9):

Variable Weight (VW)

IV(n)

Vvar(n) VW(n) =

∑ IV(n)

(9)

Where n = the array index for selected top attribute variables, for all selected top attribute variables, divide the Index Variable (IV) value for each top selected variable by the sum of all Index Variable (IV) values for the top selected variables. This produces a relative value weighting between all top selected attribute variables. This step concludes the processing of the automation script as illustrated in FIG. 5.

The next stage of the present invention is the process of GeoShape Creation, as illustrated in FIG. 6. GeoShapes are the geographically referenced polygon sets that highlight the geographic regions of maximum statistical co-relation between client location data and attribute data. The processing for all the steps in this stage is handled by the GeoShape Creation Script 250, which is an automation script that is located on the GIS Server 900. This script is automatically triggered after the completion of the Attribute Indicator Analysis Script 240, as illustrated in the previous stage in FIG. 5.

The first step in this process is to Rank Neighborhoods 600 in the geographic scope by calculating the Neighborhood Index (Nl) values according to the selected top 1 or more attribute variables and their associated weight values. The Neighborhood Index (Nl) calculation is illustrated in Function (10):

Neighborhood Index (Nl)

_∑ Ar¾n)_ , _(n)

^ RA(n)

(10)

Where y .= the neighborhood array index and n = the selected variable array index, divide the Attribute Normalization (AN) value for each neighborhood by the normalized Region Average (RA). This creates an index value for each neighborhood, for each of the 1 or more top attribute variables. These index values are multiplied by their calculated weight, and the results are summed to build a single index value for each neighborhood.

The Shape Type to be Analyzed 605 decision is made whether to create new, custom GeoShapes, or to use existing boundaries to define the GeoShapes. This decision is determined by the specifications of the target ad platform, whereby some ad platforms use custom boundaries for geotargeting, while other ad platforms may use pre-existing city or place boundaries for geotargeting. For ad platforms that use pre-existing boundary shapes for geotargeting, the process will continue on to the Calcu late GeoShape Area Intersect (GSAI) 620 step. For all custom shapes a process of shape aggregation will proceed to group the geographic "hot spots" and consolidate the optimal geographic areas. The calculation will proceed with the Create Spatial Aggregates 610 step, using the Dump, Union, Convex Hull and Exterior Ring GIS Spatial Functions, according to the formula defined in Function (11):

geo = ExteriorRing(Dump(Union(ConvexHull(attr_area))))

(11)

The attr_area function parameter is a reference to all neighborhood areas that have been identified as "high opportunity" areas. A high opportunity area is defined as a geographic area with an index value > 1, indicating that the area was rated as above the average of the geographic scope. In general, an index value > 1 for any indexed variable will indicate that the variable is statistically above the average, and is thus often used as the criteria when selecting from an indexed list of variables. The method for creating spatial aggregates as illustrated in Function (11) is one exemplary method for this type of calculation, and there may be alternate methods for implementing this calculation in alternate embodiments of the present invention.

After the creation of the spatial aggregates, the Shape Geometry Optimizer 615 step proceeds to modify the shapes to fulfill the required geometric parameters for different ad platforms. This process, as illustrated in FIG. 6b, is controlled by the Shape Geometry Optimizer Script 255 that is located on the GIS Server 900. The input into this script is the spatial aggregate shape data, for each new GeoShape, as calculated in the previous step.

The first step in this process is to Remove Interior Rings 645, which is a means to remove any void spaces, or "doughnut holes" inside of each aggregated GeoShape. Such internal holes are integrated with the shape that surrounds it, and thus removed. This is accomplished by using the Exterior Ring GIS Spatial Function.

The next step is to Check GeoShape Width 650 to verify if the width of each polygon exceeds the GeoShape width limit of 200 km, as defined in Function (12):

IF Distance(xmin(geo) ymin(geo), xmax(geo) ymin(geo))>200km

(12)

This limit value may be set to any value, and the present invention is not constrained by this limit, however it is often useful or required to limit the size of GeoShapes to ensure proper integration with ad platform applications. Constraining the size parameters helps to manage abnormally sized geographic regions that may result from the GeoShape creation process. An example width limit that is representative of typical GeoShape size constraints is 200 km. If the GeoShape has a width that exceeds the limit, the shape is vertically split into 2 smaller shapes in the Split GeoShapes Vertically 655 step, using the Distance and Split GIS Spatial Functions, as defined in Function (13):

line.vpl = xmin(geo) + (xmax(geo)-xmin(geo))/2, ymin(geo)

Iine.vp2 = xmin(geo) + (xmax(geo)-xmin(geo))/2, ymax(geo)

geo = Split(geo, line)

( 13)

These new, smaller shapes are then tested again in the Check GeoShape Width 650 step, and this process loop continues until each shape has a width within the defined limit. Each GeoShape is then tested to ensure the height is less than the defined height limit, using the Check GeoShape Height 660 step, as defined in Function (14):

IF Distance(xmin(geo) ymin(geo), xmin(geo) ymax(geo))>200km

(14)

This process, its requirements, and rationale, are similar to the Check GeoShape Width 650 step; a typical GeoShape height limit is 200 km, but the present invention, as noted above, is not constrained by this limit. If a GeoShape has a height that exceeds this limit, the shape is horizontally split into 2 smaller shapes in the Split GeoShapes Horizontally 665 step, using the Distance and Split GIS Spatial Functions, as defined in Function (15): line.hpl = xmin(geo), ymin(geo) + (ymax(geo)-ymin(geo))/2

Iine.hp2 = xmax(geo), ymin(geo) + (ymax(geo)-ymin(geo))/2

geo = Split(geo, line)

(15)

These new shapes are then tested again with the Check GeoShapes Height 660 step, and this process loop continues until each shape has a height within the defined limit. After this size-verification loop has completed, the GeoShape Type 670 is then assessed, which is determined based on the required parameters of the targeted ad platform. Some ad platforms are capable of accepting an arbitrarily shaped Custom polygon format, in which case the process continues to optimize the coordinate points for each polygon (as detailed below, beginning with the step to Check GeoShape #Points 680).

Alternately, some ad platforms require that their input geotargeting polygons are approximated using a circle, as defined by a center point and a radius value. If the current ad platform is of this Map Point type, the process will then proceed to Store Centroid Coordinates 672. This step determines the geometric center point, stored as a latitude/longitude coordinate, for each GeoShape object by using the Centroid G\S Spatial Function.

The next step is to Calculate Distance of Buffer Radius 674. This step measures the height and width of each GeoShape to determine the ideal radius value for a circle that encompasses the GeoShape. It uses the Extent GIS Spatial Function to gather the spatial limits of each GeoShape, and the Distance GIS Spatial Function to measure the height and width of each GeoShape. The radius value for each GeoShape is calculated by measuring the distance from the Centroid coordinate (as calculated in the previous step) to the spatial limits of the GeoShape, and selecting the larger of the two values. This circular buffer radius is measured in meters, converted to kilometers, and stored as an integer value in the database.

The next step is to Create Minimum Bounding Buffer 676. For each GeoShape, this process converts the shape into a more basic (circular) buffer polygon. The Buffer GIS Spatial Function creates the circular buffer shape, as defined by each Centroid coordinate and radius value.

The previous three steps to process a Map Point GeoShape Type 670 all create temporary tables in the database. The final result is then stored within the TYC_GeoShapes table 750. For GeoShapes that have been processed according to the Map Point GeoShape Type 670, the process continues to Eliminate Small GeoShapes 695 (as defined later in this section).

For GeoShapes that are of a Custom GeoShape Type 670, after size-verification, the next step can proceed. A check is performed to verify that each GeoShape has fewer than a defined number of polygon vertices with the Check GeoShape #Points 680 step, using the Number of Points GIS Spatial Function. It is important to limit the number of polygon vertices in order to reduce unnecessary complexity in the GeoShape object data. Many ad platform environments may impose such limits on geotargeting import data. An example polygon point limit that has proven useful is 100 points, although this limit may vary, and is not a constraint of the present invention. If a GeoShape contains more points than the determined limit, the geometry optimizer process will use the Apply Line- Generalization Algorithm 685 step while preserving the spatial topology, using the Simplify GIS Spatial Function as defined in Function (16). This process will loop until the GeoShape tolerance has reached a value whereby the GeoShape has been sufficiently reduced to within the permitted point limit. geo = Simplify(geo, tolerance)

(16)

Once each GeoShape has been reduced to within the point limit, a check is performed to ensure that the individual polygon vertices are separated by a sufficient distance with the Verify Distance Between Vertices 690 step, using the Distance GIS Spatial Function. Adjacent GeoShape polygon vertices that are too close together can introduce unnecessary complexity to the GeoShape. An example minimum distance limit between points that has proven useful is 20 meters, although this limit may vary, and is not a constraint of the present invention. If it is determined that the GeoShape contains vertices that are too close together, the geometry optimizer process will use the Apply Line- Generalization Algorithm 685 step while preserving the spatial topology, using the Simplify GIS Spatial Function as defined by Function (16), until the GeoShape tolerance has reached a value whereby the GeoShape points have been sufficiently spaced apart to within the permitted point distance constraint.

The final step in the Shape Geometry Optimizer process is to Eliminate Small GeoShapes 695 step, which removes all small polygons from the collection of GeoShapes. This process is accomplished using the Within and Centroid GIS Spatial Functions, as defined in Function (17):

geo = Count(attr_area) Where Within (Centroid(attr_area), geo)

( 17)

A GeoShape is determined to be too small if the number of attribute areas within the GeoShape is below a minimum threshold. An example minimum threshold that has proven useful is a minimum of 3 attribute areas within each GeoShape, although this limit may vary, and is not a constraint of the present invention. Removing small GeoShapes helps to optimize the collection of all GeoShapes by only including those GeoShapes that are most statistically relevant.

Once the GeoShapes have been optimized, the GeoShape Creation Script 250 continues on FIG. 6. The spatially optimized GeoShapes, along with all existing polygon data types (as received from the Shape Type to be Analyzed 605 conditional step) are then processed to Calculate GeoShape Area Intersect (GSAI) 620 values, as illustrated in Function (18):

GeoShape Area Intersect (GSAI)

Vgeo: GSAI(i,y) = Area ( Intersect ( geo(i), attr_area(y) ) )

(18)

Where y = the neighborhood array index, and i = the GeoShape array index, for all GeoShapes, determine the amount of intersecting area between each GeoShape and the underlying neighborhoods. This fu nction uses the Intersection, Intersects and Area GIS Spatial Functions. Sample code for this calculation can be found later in this document in section 4.3.2.

Next in this step is to calculate the GeoShape Area (GSA) as illustrated in Function (19): GeoShape Area (GSA)

G geo Vgeo GSA(i) =∑ GSAI(i,y)

Where i = the GeoShape array index and y = the neighborhood array index, for all GeoShapes, find the sum of all the GeoShape Area Intersects (GSAI), and group the results by GeoShape. This sum calculation is particularly relevant when a GeoShape area overlaps a coastline or other body of water, where the total calculated area could be less than the area of the original GeoShape.

The next step in the process is to Calculate Spatially Proportioned Weight (GSPW) 625 for each GeoShape, as illustrated in Function (20);

GeoShape Proportional Weight (GSPW)

(20)

Where y = the neighborhood array index, and i = the GeoShape array index, for all GeoShapes, divide each piece of the GeoShape Area Intersect (GSAI) by the total GeoShape Area (GSA) to find percentage weight values, as grouped for every GeoShape.

After the spatially proportioned weight values are determined, the next step will Calculate GeoShape Indexing (GSI) Values 630 for all GeoShapes, as illustrated in Function (21):

GeoShape Indexing (GSI)

Vgeo GSI(i) =∑ Nl(y) * GSPW(i,y)

Where y = the neighborhood array index, and i = the GeoShape array index, for all GeoShapes, multiply each Neighborhood Indexing (Nl) by each respective Proportional Weight (GSPW), then find the sum of these values, as grouped for each GeoShape. These results are then sorted into an ordered list by index value in the Sort GeoShapes by Index 635 step.

The final step is the Multiple Ad Platform Process Loop 640, whereby it is determined if the process should do another round of GeoShape creation for another type of ad platform. If multiple ad platforms are being processed, the script will loop back to the Shape Type to be Analyzed 605 conditional step and create an alternate version for each GeoShape. In an exemplary embodiment of the present invention, the GeoShape Creation process (via the GeoShape Creation Script 250 and the Shape Geometry Optimizer Script 255 has been optimized for use in the Google™ AdWords ad platform. For alternate embodiments of the present invention, different variants of these scripts may be necessary to properly optimize the output for use in other ad platforms.

This step concludes the processing of the automation script as illustrated in FIG. 6, and represents the conclusion of the description for the core calculation procedures used by the present invention.

As illustrated in a return to FIG. 1, the next step is to check whether to Process Another Ad Campaign 130, whereby the scope of the client's geotargeting request will determine whether the process continues with another loop of GeoShape creation for another ad campaign.

Once all GeoShapes have been created for the current set of ad campaigns, for all required ad platforms, the final step is Results Delivered to Client 140. The data result may be transmitted to the client in several different ways, including but not limited to, via email or secure FTP transfer. The client may then insert the resulting GeoShape data into their online ad platforms via the interfaces provided by those ad platforms. There are many possible ad platforms that may accept GeoShape data into their system for the purpose of implementing the online geotargeting solution provided by the present invention. Some ad platforms include: Online Ad Platforms for Search Engines (e.g. Google™ AdWords), Online Ad Platforms for Media (e.g. YouTube™ Ads), Online Ad Platforms for Social Networking (e.g. Facebook™ Ads), and Online Ad Platforms for Mobile Devices (e.g. Apple iAd™). GeoShapes may also be implemented into other Online Ad Platforms that have not yet been foreseen, and it is claimed that the output of the present invention (i.e. GeoShapes) may be modified in order to integrate with these other geotargeted online ad platforms. It is claimed that for all known, unknown, or future ad platforms, there may be required modifications to the GeoShape output format in order to integrate with these systems, and the core functionality of the present invention is adaptable enough such that it may easily integrate with all such known, unknown or future applications.

4.2.2 Exemplary Data Structures

There are many possible types of data that may enter into the present invention. The first type of data is geographic Client Location Data 220, stored in the Spatial Database 200, as sent from the client in the Receive New Client Data 110 step. This location data may be in either point-based or polygon-based format. The types of geographic point- based input data accepted include: a) Mobile Network Coordinates sent from mobile/cellular hand-held devices, b) Street Address data, as potentially gathered from client historical sales, c) GPS Coordinates sent from GPS-enabled devices, d) Latitude/Longitude data pairs or other geographic coordinates, which may be gathered from many different types of sources, and e) Other Geographic Point types that are not presently listed. There may be other unforeseen data sources and formats, at the present time or in the future, which may provide acceptable inputs into the present invention.

A common type of point location data collected for geotargeting is Street Address. This data may, for example, represent customer addresses from historical sales and past business transactions. An example of how this data may be represented is seen in FIG. 8 in the Client Address Data table 820. The table fields: Address, City, State, Zipcode and Country represent a typical series of fields that a client may use to transmit street address data. Additional location information and custom fields may also be included by the client when transmitting street address data. The custom fields provide additional attributes for each location and may be used in the geotargeting analysis. The extra fields shown on the Client Address Data 820 table, LocationJD, ClientJD, Longitude, Latitude and Geometry, represent additional data that is generated by the present invention, and do not represent typical geographic point input data.

Geotargeting location data may also be input in polygon-based format. The types of geographic polygon input data accepted by the present invention include: a) Area Code, which delineate standard telephone code regions, b) IP Address, which indicate geographic areas of Internet connectivity, c) City, which indicate entire city regions, d) ZIP or Postal Code, which indicate standard postal mailing regions, e) State or Province, which indicate standard state or provincial borders within a country, f) Region, which typically indicates larger regions within a country that encompass more than one State or Province, and g) Custom Boundary, which refers to any custom-shaped geographically referenced polygon. There may be other unforeseen data sources and formats, at the present time or in the future, which may provide acceptable inputs into the present invention.

An example of polygon-based input data is illustrated in FIG. 8 in the Client Polygon Data table 830. The table fields: City, State and Country indicate the general geographic region, while the Geometry field contains a Multipolygon formatted data item that defines a polygon area for each record. The remaining ClientJD field identifies which client the data is input from, and the Location D field is a unique key for each record, and these last two fields are defined by the present invention and are not input as part of the geographic polygon data.

The present invention also accepts many different types of geographic boundary data, stored in the Spatial Database 200, as input via the Import Boundary Data 210 step. The types of geographic boundary data formats accepted by the present invention include: a) National, which indicates the country, b) Regional, which indicates larger geographic regions that typically span multiple states or provinces, c) State or Province, which is defined by standard state or provincial borders within a country, d) City, which indicates an standard city, e) Metropolitan Area, which indicates aggregate city area that often include multiple suburban areas around a city core, f) ZIP or Postal Code, which indicate standard postal mailing regions, g) Area Code, which delineates standard telephone code regions, h) Neighborhood, which indicates a populated area of typically 500 to 3000 people, i) Census Tracts, which indicate a populated area for which a census survey has been deployed, and j) Other Boundary Data Types that are not presently listed. There may be other unforeseen data sources and formats, at the present time or in the future, which may provide acceptable inputs into the present invention.

An example of a possible boundary data input format is shown in FIG. 8 in the Boundary Data table 810, using a sample dataset that represents a Neighborhood input type. The State and Metropolitan Area fields indicate the name of the metropolitan area and the enclosing state, and the Geometry field is a Multipolygon data field that represents a series of latitude/longitude (x,y) value pairs that define geographically referenced polygons for each table record. The Neighborhood_ID field provides a unique identifier for each record.

The present invention also accepts many different types of attribute data, stored in the Spatial Database 200, as input via the Spatially Referenced Attribute Data 215 step. The format types of attribute data accepted by the present invention include: a) Demographic/Census Data, which may be acquired from a variety of public or private sources, b) Attitude Data, which are typically the results of consumer attitude questionnaires, and are typically acquired from private data providers, c) Expenditure Data, which are typically sourced from consumer surveys or private retail sources, d) Behavior Data, which are typically the results of consumer attitude questionnaires, and are typically acquired from private data providers, and e) Other Spatially Referenced Attribute Data that are not presently listed. There may be other unforeseen data sources and formats, at the present time or in the future, which may provide acceptable inputs into the present invention. An example of a possible spatially referenced attribute data input format is shown in FIG. 8 in the Attribute Data table 800, using a sample dataset that represents a Demographic/Census data type. The Neighborhood D field uniquely identifies each record by corresponding to a unique geographic neighborhood. The fields: Caucasian, African American, Asian and Other Race all indicate the number of people of each racial category who live in the neighborhood as identified by the NeighborhoodJD field. The Population & Households fields indicate the total population and number of households in each neighborhood.

FIG. 7 is the Database Table Structure diagram which represents an exemplary database layout for the present invention, representing the layout for the Spatial Database 200. This database serves as the storage location for geocoded input geographic data, processed boundary data, and processed attribute data, contains tables to store intermediate levels of data processing, and stores the final GeoShape geometry and statistics. It also contains log tables that document results from important stages used in the calculations of the present invention. Within the Database Table Structure diagram, a Geometry field, as indicated by a "globe" graphic icon, is a data field format composed of a series of geographic coordinate pairs that trace the perimeter of a geographically referenced polygon, or a single pair of geographic coordinates representing a single geocoded point. Any field with the "JD" suffix is a table key that is used to identify a record in a table, and may be used to cross-reference records in other tables. Any field with a "key" graphic icon represents a primary table key, which uniquely identifies a record in the table in which the "key" graphic is located. Table relationships are indicated by connecting lines between tables. A "One to One Relationship" means that the two connected tables are joined such that a single record in the first table corresponds to a single record in the second table. A "One to Many Relationship" or "Many to One Relationship" means that the two connected tables are joined such that a single record in the first table corresponds to 1 or more records in the second table.

The calculation algorithms of the present invention create many other temporary tables which are "dropped" (i.e. deleted) after they have been used, and are thus not represented in FIG. 7. This Figure shows all database tables that permanently store data and results of calculations. The database tables, fields, and field formats represented in FIG. 7 are neither meant to be an exclusive nor exhaustive implementation of the present invention, and other database tables, fields and field formats potentially exist which are compatible with the present invention.

The Boundary Data Table 700 stores the processed input data in the form of Geometry objects that are keyed to a unique NeighborhoodJD primary key. This table has a one-to-one relationship to the Attribute Data Table 710 and a one-to-many relationship with the ASCJD Locations table 730, as referenced by the NeighborhoodJD field (recall that the term Neighborhood may refer to any format of geographic boundary). The Boundary Data Table is accessed during the process to Rank Neighborhoods 600 according to variables and weights, as well as during the process to Calculate GeoShape Area Intersects 620.

The Attribute Data Table 710 stores the attribute variables for each geographic neighborhood, and the records are keyed to a unique NeighborhoodJD primary key. Since the input of attribute data may occur over several discrete time periods, potentially from different data sources, there is typically more than 1 instance of the Attribute Data Table (i.e. the full set of attribute data is divided into more than one table). The 1 or more Attribute fields of each table represent 1 or more spatially referenced attribute values for each neighborhood area. This table has a one-to- one relationship to the Boundary Data Table 700, as referenced by the NeighborhoodJD field. The Attribute Data Table is accessed during the step to Calculate Attribute Normalization Values 500 and the step to Rank Neighborhoods 600 according to variables and weights. The ClientJD Upload Data Table 720 stores the geocoded geographic location information that is delivered from the client, typically, but not exclusively, via the transmission of formatted Microsoft Excel data documents. The Excel data format is an expected format due to its current prevalence in the global business environment, but is only one such possible format used by the present invention. Other viable input format options include .CSV (Comma Separated Value) files, or direct connections to client databases. The data is input into the present invention via the Receive New Client Data 110 step, and the records are keyed to a unique LocationJD primary key. This table may also contain an Address field, which is a composite data field that contains location information. This table also contains Latitude and Longitude data fields, which are number-formatted fields that store geographic location data, from either unprocessed geographic location data that is already in a latitude/longitude format, or from street address data that has undergone a geocoding process in the Geocode Address 320 step. The table also contains a Geometry field to store input polygon and/or point data. This table has a one-to-one relationship to the ASCJD Locations Table 730 via the LocationJD field, and this table has a many-to-one relationship to the Client Upload Log Table 760 via the ClientJD field.

The ClientJD Upload Data Table 720 also contains a series of zero or more Custom Fields which are received from the client. These fields are defined separately for each client, and may be of any data format. The purpose of these custom fields is to define additional data items that are specific to each client and may be used to define the parameters of the geotargeting process in the Filter Client Custom Field Data 410 step, and whose usage may also differ between separate ad campaigns.

The ASCJD Locations Table 730 stores the scope-filtered geographic location data as processed in the Filter Client Custom Field Data 410 step and Filter Spatial Data 430 step. This data table is used for: the step to Filter Client Custom Field Data 410, the step to Filter Spatial Data 420, determination of geographic Data Type 540 while calculating location data statistics, and during the step to Create Buffer Areas 545 while calculating location data statistics. Records in this table are identified by a unique LocationJD primary key, have a Geometry field to store point or polygon geometric data, have State_Prov and Metro_Region fields for further location identification, a NeighborhoodJD field to indicate geographic neighborhood location, and contain a set of zero or more Custom Fields, as illustrated in the description of the ClientJD Upload Data Table 720. This table has a one-to-one relationship with the ClientJD Upload Data table 720 as referenced by the LocationJD field, a many-to-one relationship with the Boundary Data Table 700 as referenced by the NeighborhoodJD field, and a many-to-one relationship to the Client Indicator Log Table 770 via the ASCJD field.

The ASCJndexes Table 740 stores the list of indexed spatially referenced attribute variables, and records are uniquely identified by a VariableJD primary key. This table is used for: the step to Calculate Index Variable Values 520, the step to Sort Indexed Variables 525, the step to Select Variables 530, and the step to Calculation Variable Weight Values 535 for top indexed attribute variables. Records in this table contain: a Variable field that defines each attribute variable with an alphanumeric code, an Alias field to identify each variable with a readable text descriptor, a Table field to indicated which of the several possible Attribute Data table instances store the attribute variable for this record, a Normalize_Variable field to store the code (in the same format as the Variable field) for the relevant normalizing variable, and an Index field to store the assigned Index value. This table has a many-to-one relationship to the Client Indicator Log Table 770 via the ASCJD field.

The TYC_GeoShapes Table 750 stores the list of GeoShape polygon objects created by the present invention. This table is used for: the step to Calculate GeoShape Area Intersect 620, the step to Calculate Spatially Proportioned Weight 625 of GeoShapes, the step to Calculate GeoShape Indexing Values 630, and the step to Sort GeoShapes by Index 635. Records in this table are uniquely identified by a GeoShapeJD primary key, have a Geometry field to define each GeoShape polygon, have Country, State_Prov and Metro_Region fields to identify the geographic location of each GeoShape, have a Population field to indicate the total population contained within each GeoShape's geographic extent, and have an Index field to store the calculated index value for each GeoShape. This table also has an Ad_Platform field which records what kind of ad platform this GeoShape has been optimized for (e.g. Google™ AdWords), and a Place field which is a specialized location identifier used specifically for the Facebook™ ad platform. This table also has a Coordinates field to store a single latitude/longitude location and a Radius field to indicate the radius of a circular buffer, both of which are used when approximating GeoShapes with circular buffers (as required by some types of ad platform). This table has a many-to-one relationship with the GeoShape Log Table 780 via the TYCJD field.

The Client Upload Log Table 760 is used to store log entries related to the input of point and/or polygon geolocation. Each record represents a single input dataset and is uniquely identified by the ClientJD primary key. Client_Name and Date fields are used to provide further information for each record. This table has a one-to-many relationship with the Client Indicator Log Table 770 via the ClientJD field, and a one-to-many relationship with the ClientJD Upload Data Table 720 via the ClientJD field.

The Client Indicator Log Table 770 is used to store log entries related to the scope-filtering operations performed during the determination of the client targeting scope, for both custom field filtering and spatial data filtering, and during the creation of the ASCJD Locations Table 730. Each record is uniquely identified by an ASCJD primary key. The spatial parameters of the scope filtering operation are identified by the fields: Analysis_Name, Country, State _^ Prov, City, and Place, and the log operation is further identified by the Date field. The Where_Clause field contains the actual SQL code segment that is used for the scope-filtering operation logic. This table has a many-to-one relationship with the Client Upload Log Table 760 via the ClientJD field, a one-to-one relationship with the GeoShape Log Table 780 via the ASCJD field, a one-to-many relationship with the ASCJndexes Table 740 via the ASCJD field, and a one-to-many relationship to the ASCJD Locations Table 730 via the ASCJD field.

The GeoShape Log Table 780 is used to store log entries related to the creation of GeoShapes. Each record is uniquely identified by the TYCJD primary key, and contains a summary of the necessary parameters used to build a full set of GeoShapes that are generated for a particular client campaign. The Variables field contains a list of 1 or more top variables that have been selected for GeoShape creation. The Weights field contains a list of 1 or more numeric weight values which have been calculated 750, with one weight value for each selected top attribute variable. The Variable and Weight field values are used during the ranking of neighborhoods according to these variables and weights. The fields: Nickname, Country, State _^ Prov, Metro_Region, and Date provide further information for each record. This table is related to the Client Indicator Log Table 770 with a one-to-one relationship via the ASCJD field, and a one-to-many relationship to the TYC GeoShapes Table 750 via the TYCJD field.

4.2.3 Exemplary Apparatus

Examples of well known computer systems that may be suitable for use in the present system with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, laptop devices, multiprocessor systems, network personal computers, mainframe computers, distributed computing environments where tasks are performed by remote processing linked through a communications network, remote systems, etc., and the like. In a distributed computing environment, program components or modules may be located in both local and remote computer storage media including memory storage devices. Remote systems may involve remote computers, such as personal computers, a router, a server, a network personal computer, a peer device or other common network node, and the like.

In addition, components of suitable platforms may include, but are not limited to, a central processing unit, a system memory, and a system bus that integrates various system components, including the system memory to the processing unit. The system memory may include computer storage media in the form of volatile or non-volatile memory, such as read only memory (ROM), random access memory (RAM), EEPROM, flash memory, CD-ROM, DVD, magnetic storage devices, etc., which can be used to store the desired information and is accessible by the computer system. The system bus may be any of several types of bus structures including a memory controller, a peripheral bus, and a local bus of various bus architectures. Suitable platforms also include a variety of computer-readable media comprising, for example, computer communication media and computer storage media. Computer storage media may include both removable and non-removable media, or volatile and non-volatile media alike, for information storage of computer-readable instructions, program modules, data structures, or other data, etc. Computer communication media generally comprises any information delivery media for delivering media information to a user, computer-readable instructions, program modules, data structures, or other data, etc.

For an exemplary embodiment of the present invention, FIG. 9 is a diagram that illustrates the key hardware components used for the GIS Server Architecture. The Web Server 270 and GIS Server 900 are systems that exist within a cloud computing environment, meaning that their physical components are potentially spatially distributed across many physical machines. Each of these systems consists of a CPU, Memory, and SAN (Storage Area Network), in addition to all other required components for the typical operation of such a computing system (as detailed above). The details of the Web Server 270 are already described in the description of FIG. 2. The GIS Server 900 is the primary system that contains much of the remaining functionality as illustrated in FIG. 2, including: the Spatial Database 200, Boundary Data 210, Spatially Referenced Attribute Data 215, Client Location Data 220, GIS Spatial Functions 205, GIS Mapping and Geoprocessing Software 260, Application Services 265, and all Automation Scripts 222.

In an exemplary embodiment of the present invention, both the Web Server 270 and the GIS Server 900 are connected together via a Fiber Channel over Ethernet (FCoE) connection, and are similarly connected to an Internet Firewall 910 which provides security from unauthorized external access. The Firewall is connected to the Internet 920, and the entire system is accessible via the Internet by using an Internet Browser 280.

4.2.4 Alternatives & Extensions

The present invention is designed to provide geotargeting data to a wide range of potential ad platforms and it is possible that the GeoShape output of the present invention may assume other modified formats in order to optimally interface with the particular requirements of all ad platforms. Therefore the GeoShape Creation process as shown in FIG. 6 and the Shape Geometry Optimizer process shown in FIG. 6b may require future modification, and the current shape creation & optimizing processes as detailed in this document represent an exemplary version of this procedure, yet is not meant to be an exhaustive treatment of all possible methods of GeoShape creation & optimization.

Another potential alternative to the present invention is regarding clients who do not provide any historical, geographic sales location data as input into the present invention. For such clients, there is insufficient data to perform the Attribute Indicator Analysis process as illustrated in FIG. 5. It would therefore be necessary that all selected attribute variables and their corresponding variable weights would be determined during the stage to Determine Client Targeting Scope as shown in FIG. 4. This adaptive process may also be used for clients who have already (internally) determined their ideal consumer attribute & demographic parameters, yet still wish to determine the GeoShape output that applies to their selected geographic scope. Therefore the Attribute Indicator Analysis process is not always necessary for the implementation of the present invention.

4.2.5 Example Implementation

The operation of the present invention may be better understood by reviewing an example of an actual implementation in a real online advertising environment. The following Case Study will be analyzed in a step-by-step fashion to illustrate how the present invention was implemented, as well as to show the measurable benefits that resulted in the associated Google™ AdWords campaign of the client, thus showing the quantifiable business benefits afforded by the implementation of the present invention. For the following analysis it will be helpful to first define some of the terminology that is used when discussing the performance metrics of a Google™ AdWords campaign.

An "Impression" is defined by Google™ as: "an AdWords ad impression is counted when an ad is displayed on Google™". The number of impressions is a critical part of increasing the number of conversions as it represents Google showing your ad to online users.

A "Click" is defined as a measured and recorded action taken by an online viewer where they select an ad placed in front of them. This click action directs the viewer to the advertised Web page.

The "Click-Through-Rate" is a measure of the success of an online ad, obtained by dividing the number of users who clicked on an ad on a Web page by the number of times the ad was delivered ( Impressions).

A "Conversion" in AdWords can be defined by a sale, a lead, a page view, or an online viewer signing up for a free product or service trial offered by the client. Some businesses may also have alternate definitions of a conversion that are specific to their particular business model.

The "Cost-Per-Conversion" is the cost to achieve a conversion and it is critical to the general success of any AdWords cam paign. As Web viewers interact with an AdWords campaign they click on ads resulting in an incrementa lly added cost to the advertiser. The number of clicks it takes to get one conversion is reflected by the cost-per-conversion.

The "Conversion Rate" is the ratio between the number of clicks and the number of conversions. It is the rate at which clicks turn into conversions.

The "Quality Score" is a measure of the quality of a campaign's keywords and ads. Quality Score is calculated by the click-through-rate of keywords, releva nce of an ad's text and landing page, historical keyword performance, and other factors. The higher the Quality Score, the lower the price paid per click. 4.2.5.1 Case Study #1 : Method

Case Study #1 involves a company that builds and hosts online websites, who wished to increase the performance of one of their Google™ AdWords ad campaigns. This company was searching for an effective method to drive additional traffic to their website, increase their daily leads (online ad Conversions), maintain their cost-per- conversion (CPC), and increase the general efficiency of their AdWords account. Following is the full analysis of the steps that were used for the processing of Case Study #1.

The first step required before the primary analysis could begin was the GIS Server and Data Setup as illustrated in FIG. 2. It is required that before the present invention can begin, all script components and software architecture must be in place as illustrated in this Figure, including all Automation Scripts 222, the GIS Spatial Functions 205, GIS Mapping and Geoprocessing Software 260, Application Services 265, the Web Server 270, the GIS Interface 275 and an Internet Browser 280.

After the system configuration was established, the Boundary Data 210 was imported into the Spatial Database 200 via the Attribute and Boundary Data Import Script 225. The Boundary Data for the United States was acquired from the data provider company Tetrad™ as part of their AGS Demographics package. The Spatially Referenced Attribute Data 215 was also imported into the Spatial Database 200 via the Attribute and Boundary Data Import Script 225. The Attribute Data was acquired from the same source as the Boundary Data, as it was distributed as a single data package.

For many situations, the preceding steps to configure the system, as illustrated in FIG. 2, only need to occur once, and will remain valid for many cycles of operation of the present invention. If a new set of Spatially Referenced Attribute Data 215 or Boundary Data 210 is acquired at a later date, the Spatial Database 200 can be updated, as detailed in the step for Potential Updates of Boundary and/or Attribute Data 100.

The next step was to Receive New Client Data 110 from the client. This data was transmitted from the client via email as a Microsoft™ Excel document. This address data represented historical sales locations within the United States that had been collected from the prior sales transactions made by online customers of the client. This data was manually verified in the Clean and Verify Client Data 120 step, and was standardized to match the proper import requirements of the present invention by ensuring data columns were named to match the standard heading names: Address, City, State and Country. The data was then processed to Import Client Data to Database and Geocode Data, as illustrated in FIG. 3, by activating the Address Geocoding Script 235, as illustrated in FIG. 2, via the GIS Interface 270 as connected to an Internet Browser 275. This processing script ran successfully, importing the Cleaned and Verified Client Data from step 120. The script used this address information to geocode the latitude and longitude (x,y) coordinate values in the Geocode Address 320 step. The latitude and longitude pairs were then used to Create Geometry 330 as point objects, which were then stored back into the Spatial Database 200.

The next step was to Determine Client Targeting Scope, as illustrated in FIG. 4. The ad campaign targeting goals of the client had already been established via prior email communications that had been sent alongside the client's location data, and so the step to Determine Client Ad Campaign Specification 400 was already accomplished. It was then necessary to review these stated goals and translate them into useful data filtering operations. The first client scope request was to determine geotargeting for their Google™ AdWords campaign, since that was the primary ad platform they used to generate online sales. The client did not supply additional custom fields with their sales location data, therefore the Filter Client Custom Field Data 410 step was not required. The client requested an analysis of the entire United States geographical region, and so a simple SQL data query was executed to select all sales that occurred within the United States, using the national USA Boundary Data 210 in the Filter Spatial Data 420 step,

The next step was to begin execution of the primary Automation Scripts 222 to calculate the GeoShapes for the client's AdWords campaign. The Attribute Indicator Analysis Script 225 was manually activated via the GIS Interface 275, as controlled via an Internet Browser 280. This script proceeded through all the calculation steps as illustrated in FIG. 5, including the automatic activation of the Calculate Location Data Statistics Script 245, as illustrated in FIG. 5b. The script assessed which were the best demographic variables and selected the Top 5 indexed variables while skipping over any variable that represented a duplicate category. For example, in the top variable list identified for this Case Study, there were two different attribute variables that referred to income within the Top 5, and since it is redundant to include two income variables, only the first income variable was selected. The Attribute Indicator Analysis Script 225 then finished its calculations by finding the variable weights via the Calculate Variable Weight (VW) Values 535 step.

The 5 attribute variables that were determined to best represent the client's geotargeted ad campaign were: 1) Education - Bachelor's Degree (23% weight), 2) Population Age 30-45 (20% weight), 3) "For Information the First Place They Look is the Internet" (19% weight), 4) Household Income $50,000 - $100,000 (19% weight), 5) "Think You Should Seize Opportunities in Life" (19% Weight).

The completion of the Attribute Indicator Analysis Script 225 then automatically triggered the start of the GeoShape Creation Script 250, as illustrated in FIG. 6. Since the Google™ AdWords ad platform allows the implementation of fully customized geotargeting shapes, all of the shapes were tagged as "Custom Shapes" during the step, Shape Type to be Analyzed 605. And therefore, the geographic areas were all then processed to Create Spatial Aggregates 610, and then run through the Shape Geometry Optimizer 615. This shape optimizing step automatically called the Shape Geometry Optimizer Script 255, and followed all of the steps as illustrated in FIG. 6b. The GeoShape Type 670 for this ad campaign was previously determined by the client to be Custom (as determined by the existing requirements of the Google™ AdWords ad platform), thus indicating that the standard GeoShapes were sufficient, and point-based buffer calculation was not required. The optimized GeoShapes were then run through the remainder of the steps in the GeoShape Creation Script 250, thus resulting in a sorted-by-index list of the optimized GeoShapes for the client's Google™ AdWords campaign. This list of GeoShape polygons represented a target population of 102 million people in the United States. Since the client did not require processing for any other ad platforms according to the Determine Client Ad Campaign Specification 400 step, this script was then complete.

The client only wished to geotarget a single ad campaign, and so this marked the end of the processing required for the present invention for Case Study #1. The final results were sent to the client via a secure FTP connection. For this specific Case Study we provided assistance to the client by helping them configure their Google™ AdWords campaign with the new GeoShapes, although in a typical situation the client would perform this step on their own initiative. This GeoShape insertion step was accomplished by the client inviting us to register as a co-administrator for their Google™ AdWords account. Once administrative access was granted, the GeoShapes were inserted into the ad campaign by editing the location targeting settings via the Web-based administrative interface provided by the Google AdWords ad platform environment. 300 GeoShapes were added to the campaign by copying over the latitude/longitude coordinate data that was output from the present invention. This GeoShape insertion process may be fully automated by implementing the functionality provided by the Google™ AdWords API.

4.2.5.2 Case Study #1 : Results After running the geotargeted ad campaign of the present invention for 30 days alongside the previous ad campaign (simultaneously running both ad campaigns alongside each other), an analysis of the Google™ AdWords metrics for the Case Study #1 client test shows that the geotargeted ad campaign was experiencing significant levels of improvement:

The 7-day average Click-Through-Rate (CTR) increased from 1.38% (previous campaign) to 2.40% (geotargeted campaign of the present invention), which demonstrated a significant increase when compared to the previous 30-day average of 1.60%.

The 7-day average Quality Score increased from 3 points (previous campaign) to 7 points (geotargeted campaign of the present invention), which demonstrated a significant increase when compared to the previous 30-day average of 3 points.

The 7-day average Conversions increased from 89 conversions (previous campaign) with an extra 92 conversions (via the geotargeted campaign of the present invention) for a total of 181 conversions. This compared quite favourably with the previous campaign's 30-day average of 91 conversions. The Cost- Per-Conversion (CPC) remained unchanged.

4.3 Sample Code

4.3.1 Code Sample #1

The following code sample for the present invention is from the Address Geocoding Script 235, which is used in the Geocode Address step 320 to geocode street address data into a standardized latitude/longitude (x,y) format. This automation script uses the Yahoo! PlaceFinder API which sends a request for each record to the online geocoding service and waits for a response. Upon receiving a valid response, the process then proceeds to create a geometry record. This code sample is written using the PHP scripting language.

<?php

// Sample geocoding script which will take a multi-part address information store within the database, parse the // information, send the request to the Yahoo! PlaceFinder API and store the geocoding latitude/longitude values // back into the database

// Fetch all the required address information sent through the URL

$address_col = $_REQUEST [ "address_col" ] ;

$city_col = $_REQUEST["city_col"]

$state_col = $_REQUEST [ " state _^ col" ] ;

$zip_col = $_REQUEST["zip_col"]

$country_col = $_REQUES [ "country_col" ] ;

// Format the select query to select the appropriate columns from the cu#_locations database table

$batchgeocode_query = "SELECT busid, ";

if ($address_col != "na")(

Sbatchgeocode_query .= $address_col . " as address, " ;

}

if ($city_col ! = "na") {

$batchgeocode_query .= $city_col." as city, ";

if ($state_col != "na") (

$batchgeocode_query .= $state_col." as state, " ;

if ($zip col ! = "na" ) {

$batchgeocode_query . ^■ = $zip_col." as zip, "; if ($country_col != "na") {

$batchgeocode_query .= $country_col . " as country, ";

}

$batchgeocode_query = substr ( $batchgeocode_query, 0, -2 ) ; // remove the ", " from the end of the query

$batchgeocode_query .= " FROM " . $cu . "_locations" ;

11 ================ start UPDATE clientupload_log ================================

$recordcheck_query = "SELECT * FROM clientupload_log WHERE client_upload = '".$cu. ;

$recordcheck_result = pg_query { $dbconn, $recordcheck_query) ;

$recordcheck_numro s = pg_num_rows ( $recordcheck_result ) ;

if ($recordcheck_nurarows > 0){ // Perform an update if the record already exists

$as_update_query = "UPDATE clientupload _^ log SET

client_upload = '".$cu."',

nickname = ' " . $client . " ' ,

location = ' na ' ,

address = ' " . $address_col . " ' ,

city = ' " . Scity_col . " ¹ ,

state = ' " . Sstate_col . " ' ,

zip = ' " . $zip_col . " ' ,

country = ' " . $country_col . " ' ,

geom__type = 'points',

datestamp = current_timestamp

WHERE client_upload = ¹ " . $cu . " ' ; " ;

pg_query ($dbconn, $as_update_query) ;

)

else( // If no record exists then insert a new record for this analysis

$as_insert_query = "INSERT INTO clientupload_log (client_upload, nickname, location, address, city, state, zip, country, geom_type, datestamp)

VALUES

( ' " . Scu . " ' , ' " . Sclient . " ' , ' na ¹ , ¹ " . $address_col . " ' , ' " . $city_col . " ' , ' " . $state_col . " ' , ' " . $zip_col . " ' , ' " . $cou ntry_col . " ' , ¹ points ' , current_timestamp) "

pg_query ($dbconn, $as_insert_query) ;

}

11 ================ end UPDATE clientupload_log ==================================

$batchgeocode_result = pg_query ( $dbconn, $batchgeocode_query) ; // executes the select statement echo $batchgeocode_query . "<br/>";

$batchgeocode_numrows = pg_num_rows ( $batchgeocode_result ) // store the number of rows returned, use this value for looping

$rejectcount = 0; // initialize the number of rejected addresses to 0

$totalcount = $batchgeocode_numrows; // initialize the total number of addresses set for geocoding for ($x=0 $x<$batchgeocode_numrows; $x++) { // run the loop through all the addresses returned from the query

$latitude = ""; // initialize lat/long to blank values

$longitude = "";

$batchgeocode = pg_feteh assoc ( $batchgeocode_result, $x); // fetch individual row z of the query results

// begin to parse the values and create the Yahoo' PlaceFinder API call string

$search = 'http://where.yahooapis.com/geocode?'; if ( $address_col != "na") {

$search .= "addr=" . urlencode ( $batchgeocode [ "address" ])."&";

}

if($city_col != "na" && $state_col != "na" St $zip_col != "na"){

$search .=

"csz=" .urlencode ( $batchgeocode [ "city"] ) .",+". urlencode ( $batchgeocode [ "state" ] ) . "+" . urlencode ( Sbatchgeoco de ["zip"] ) .

}

else if($city_col '= "na" && Sstate_col != "na"){

$search .=

"csz=" .urlencode ( $batchgeocode [ "city" ] ) . " , +" .urlencode ( $batchgeocode [ "state"] ) . "s"

)

i f ( $country_col != "na")]

$search . = "country=" . urlencode ( $batchgeocode [ "country" ])."&"; // displays the address number

// displays the Yahoo! PlaceFinder API call string

// Performs the call to Yahoo! API, which is counted for 24 hour period, fetch the xml response Sxml = simplexml_load_file (Ssearch, ' SimpleXMLElement ' , LIBXML_NOCDATA) ;

// parse the xml response and store the lat/long values into variables

Slatitude = $xml->Result->latitude;

$longitude = $xml->Result->longitude ;

echo "<p>Yahoo! values<br />";

echo "Latitude: ".$latitude . "<br>";

echo "Longitude: ".$longitude . "<br>"

// if lat/long both have values set, update the spatial database with the new values

if($latitude != "" && $longitude != "") {

$update_latlong_query = "UPDATE " . $cu . " _^ locations SET latitude = '" . $latitude . " ' , longxtude = ¹ " . $longitude . " ' WHERE busid = ' " . $batchgeocode [ "busid" ] . " ' " ;

pg_query ( $dbconn, $update_latlong_query) ;

echo $update_latlong_query . "<br/>";

}

else{ // skip this record, add 1 to the reject count

echo "<h4>Address was not geocoded</h4xbr/>";

$ re ect ount++ ;

)

}

// continue to loop through all addresses until geocoding process is complete

?>

4.3.2 Code Sample #2

The following code sample for the present invention is from the GeoShape Creation Script 250, which is used in the Calculate GeoShape Area Intersect (GSAI) step 620 to determine the amount of intersecting area between each GeoShape and the underlying neighborhoods. This code builds an SQL query, which is then submitted to the database. This code illustrates the method of use for several of the available GIS Spatial Functions 205: ST_Area, STJntersection and STJntersects. Many of the scripts used in the present invention follow a similar structure to this piece of code, whereby SQL statements are dynamically constructed, while incorporating calls to GIS Spatial Functions. This code sample is written using the PHP scripting language.

<?php

// This code uses the $inv variable, which is a unique identifier for the analysis. All temporary and // permanent tables relating to a particular analysis will contain the sinv variable in it's name. // This code also uses the $dbconn variable which is string used to connect to the database and execute queries .

//Drop the table if it currently exists in the database. This is used for re-running the anaysis.

$droptable_query = "DROP TABLE IF EXISTS " . $inv . "_geoshapes_areaoverlay " ;

pg_quer ( Sdbconn, $dropquery) ; //execute the query

// Create the table schema. This defines the table name, column names, and column types

$createtable_query = "CREATE TABLE " . $inv . "_geoshapes_areaoverlay (gid serial PRIMARY KEY, \"cid\" bigint, V'blockgroupV character ( 12) , areaoverlay numeric) WITH OIDS ";

pg_query (Sdbconn, $createtable_query) ;

// This query inserts the data values into the table. An intersection between the geometry of the bg_msa table

// (boundary data) and the geoshapes geometry is executed and the area of each is calculated. The result is a // table containing the unique id of the GeoShape, the unique id's of all the boundary areas that intesect with

// each GeoShape, and the actual area of each intersecting boundary.

$insert_areaoverlay_query = "INSERT INTO " . $inv . "_geoshapes_areaoverlay (cid, blockgroup, areaoverlay)

SELECT a. cid AS cid, b.bgOO AS blockgroup, ST_AREA (ST_Intersection (a . t e_geom, b.the_geom)) AS areaoverlay

FROM " . $inv. "_geoshapes AS a, bg_msa AS b

WHERE ST_Intersects (a . the_geom, b . the_geom) ; " ;

pg_query (Sdbconn, $insert_areaoverlay_query) ;

?>