WO1996034354A1 - Systeme et procede de validation et de geocodage d'adresses - Google Patents

Systeme et procede de validation et de geocodage d'adresses Download PDF

Info

Publication number
WO1996034354A1
WO1996034354A1 PCT/US1996/005734 US9605734W WO9634354A1 WO 1996034354 A1 WO1996034354 A1 WO 1996034354A1 US 9605734 W US9605734 W US 9605734W WO 9634354 A1 WO9634354 A1 WO 9634354A1
Authority
WO
WIPO (PCT)
Prior art keywords
application program
address
client application
data
program
Prior art date
Application number
PCT/US1996/005734
Other languages
English (en)
Inventor
Buff Colchagoff
Carol Yates
Louis R. Konior
Clinton James Shank
Original Assignee
United Parcel Service Of America, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by United Parcel Service Of America, Inc. filed Critical United Parcel Service Of America, Inc.
Publication of WO1996034354A1 publication Critical patent/WO1996034354A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention relates to a method and system for validating and geocoding addresses, and more particularly relates to such a method and system in which a user may obtain such information from within an application program mnning on a personal computer.
  • Businesses of various types maintain databases to store the names and addresses of current or potential customers.
  • the address data may be unreliable or inaccurate due to clerical errors, errors in data entry, or other problems. There is a need to reduce the chances of misdelivery.
  • people ordering goods or services may provide fraudulent addresses in an attempt to defraud a vendor.
  • businesses utilize reference address databases, such as the United States Postal Services ZIP+4 database to validate addresses.
  • the second drawback results from the size of the validation databases. There are over 40 million valid addresses in the United States. Therefore, the validation databases are large and require large amounts of space on computer disk drives. This makes it difficult for businesses to maintain such databases on their own personal computers. Furthermore, the databases must be updated from time to time to ensure that the latest data is available.
  • Some service providers address the problems of updating and local storage by providing a type of remote batch mode processing as described above. This may require the user to export the files into suitable format and upload the reformatted data to a bulletin board. After the requested data is provided, the data must be downloaded from the bulletin board, reformatted and imported into the user's application program.
  • a system that allows a user to validate and geocode address data from within the user's application program, without requiring the user to expo ⁇ and reformat the data.
  • a system that allows the user to access current address validation and geocoding databases without requiring the data to be exported and reformatted.
  • the present invention addresses the above-described problems in the an by providing a system and method that allow a user to validate and/or geocode address data residing within the user's application program, using a separate validation and or geocoding program, which may in some cases reside on a remote address validation server. This is accomplished from within the user's application program, such as a spreadsheet, word processor, desktop mapping program, or database management program, running on a personal computer, without requiring the user to export and reformat the data.
  • the present invention provides a system for validating and/or geocoding addresses stored in a user application program running on a personal computer, comprising: a personal computer configured to run: a multitasking operating system: an interprocess communication mechanism for enabling communication between application programs running under the operating system; a client application program running under the operating system, and capable of storing and operating on stored data representing addresses of persons, entities, and structures; and a server application program running under the operating system, the server application program including: means for generating commands required for controlling the address validation and/or geocoding program; means for establishing an inte ⁇ rocess communication link between the server application program and the client application program; means for detecting a request for address validation and/or geocoding from the client application program via the inte ⁇ rocess communication link; means for receiving address data from the client application program via the inte ⁇ rocess communication link and for preparing the data for processing by the address validation and/or geocoding program; means for establishing communication with an address validation and/or geocoding program operative to match input
  • the client application program may be, for example, an off-the-shelf spreadsheet program, database management program, word processing program, or desktop mapping program.
  • the inte ⁇ rocess communication link preferably comprises a Dynamic Data Exchange (DDE) utility.
  • DDE Dynamic Data Exchange
  • the address validation and/or geocoding program may reside on a remote computer, and communication between the personal computer and the remote computer may be direct or by way of modem communication with a gateway computer connected to the remote computer by a local area network.
  • the three programs, the client application program, the server application program, and the address validation and/or geocoding program may reside on the same computer of any type capable of performing the functions described herein.
  • the system preferably has the capability to geocode addresses as well as validate the addresses, or may have only geocoding or only address validation capability.
  • the present invention also provides a method for validating addresses stored in a user application program running on a personal computer, comprising the steps of: running a client application program on a personal computer under a multitasking operating system, and storing under the client application program data representing addresses of persons, entities, and structures; running a server application program on the personal computer under the multitasking operating system; establishing an inte ⁇ rocess communication link between the server application program and the client application program: detecting a request for address validation and/or geocoding from the client application program via the inte ⁇ rocess communication link; receiving address data from the client application program via the inte ⁇ rocess communication link; establishing communication with an address validation and/or geocoding program; transmitting commands and the data to the address validation and/or geocoding program in a form usable thereby; receiving from said address validation and/or geocoding program any valid matching address data and/or geocoding
  • a user application program such as a spreadsheet, word processor, desktop mapping program, or database management program.
  • FIG. 1 is an illustration of a personal computer suitable for use in implementing the present invention, and a remote address validation server.
  • Fig. 2 is a block diagram showing the principal components of the processor chassis in the personal computer of Fig. 1.
  • Fig. 3 is a block diagram illustrating the interface between a computer's input/ou ⁇ ut devices, an operating system, and application programs.
  • Fig. 4 is a flow diagram illustrating the method of the present invention as perceived by a user.
  • Fig. 5 is a state diagram illustrating the method of the present invention as implemented in a dynamic data exchange (DDE) client application program running on a personal computer.
  • Fig. 6 is a state diagram illustrating the method of the present invention as implemented in a DDE server application program running on a personal computer.
  • DDE dynamic data exchange
  • Fig. 7 is a state diagram illustrating the method of the present invention as implemented in a computer program running on a gateway computer communicating with the personal computer and with an address validation server.
  • Fig. 8 is a state diagram illustrating the method of the present invention as implemented in a computer program running on a remote address validation server.
  • Fig. 9 is a representation of a window presented to the user when the generic DDE server application program is run.
  • Fig. 10 is a representation of a window presented to the user when "Preferences" is selected from the pull down menu shown in Fig. 9.
  • Fig. 11 is a representation of a window presented to the user when the "Communications” button is clicked in the window of Fig. 10.
  • Fig. 12 is a representation of a window presented to the user when the "Filters” button is clicked in the window of Fig. 10.
  • Fig. 13 is a representation of a window presented to the user when "Geocode" is selected from the pull down menu shown in Fig. 9.
  • Fig. 14 is a representation of a window presenting returned candidates to the user in the interactive mode.
  • Fig. 15 is a representation of a window presenting a scorecard to the user upon completion of address processing.
  • a process is generally conceived to be a sequence of computer-executed steps leading to a desired result. These steps generally require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It is conventional for those skilled in the an to refer to these signals as bits, values, elements, symbols, characters, terms, objects, numbers, records, files or the like. It should be kept in mind, however, that these and similar terms should be associated with appropriate physical quantities for computer operations, and that these terms are merely conventional labels applied to physical quantities that exist within and during operation of the computer.
  • FIGs. 1-3 illustrate various aspects of the computing environment in which the present invention is designed to operate. Those skilled in the art will immediately appreciate that Figs. 1-3, and the associated discussion, are intended to provide a brief, general description of the preferred computer hardware, operating system, and application programs, and that additional information is readily available in the appropriate programming manuals, user's guides, and similar publications.
  • Figs. 1 and 2 illustrate a conventional IBM-compatible personal computer 10 suitable for implementing the present invention.
  • the personal computer 10 includes a processor chassis 15, which houses a mother board and other printed circuit boards (not shown) of the type conventionally used in a personal computer.
  • Fig. 1 also shows the personal computer 10 connected to a gateway computer 16 via a communications link such as a telephone line 18.
  • the gateway 16 is in turn connected to a remote address validation server 17 via a local area network 19, preferably by Novell named pipes.
  • the remote address validation server 17 contains extensive databases and application programs that are used for address geocoding or validation.
  • the present invention may be utilized with a variety of such validation and geocoding programs, such as those provided or maintained by United Parcel Service ("LookUPS system").
  • the mother board of the personal computer 10. which is illustrated in the block diagram of Fig. 2, includes a central processing unit (CPU) 20, such as the 80486 or "PENTIUM" microprocessors manufactured by '* ⁇ tel.
  • the mother board also includes read only memory (ROM) 25 and random access memory (RAM) 30. which are connected to the CPU by the data bus 35.
  • ROM read only memory
  • RAM random access memory
  • An internal modem 57 allows the personal computer 10 to communicate with the gateway 16 via the telephone line 18.
  • many other internal components of the processor chassis 15 are not shown, those of ordinary skill in the an will appreciate that such components and the interconnection between them are well known. Accordingly, additional details concerning the internal construction of the personal computer 10 need not be disclosed in connection with the present invention.
  • the personal computer 10 includes a floppy drive 60 and a hard drive 65, which are connected to the CPU via the hard drive/floppy drive interface 55 (Fig. 2), for use in reading data from and writing data to magnetic media.
  • the personal computer displays data of various types on a display 70.
  • a user enters commands and information into the personal computer 10 by using a keyboard 75 and/or a pointing device such as a mouse 80.
  • Other types of pointing devices include a track pad, track ball or other device suitable for positioning a cursor on a computer display.
  • the operating system, application programs and data are provided to the computer via one of its memory devices, which include the hard drive, floppy drive, RAM and ROM.
  • the hard drive 65 is used to store data and programs, including the operating system and the application program that embodies the present invention.
  • the personal computer 10 When the personal computer 10 is turned on or reset, it loads the operating system from the hard drive 65 into the RAM 30. Once the operating system is loaded into RAM, the CPU 20 executes the operating system code and causes the visual elements associated with the operating system to be displayed on the display 70.
  • the application program When the application program is opened by a user, the program code and relevant data are read from the hard drive 65 and stored in the RAM 30.
  • the preferred embodiment of the present invention is designed to operate with Microsoft Co ⁇ oration's "WINDOWS" operating system, which provides a graphical user interface.
  • a graphic operating system enables the user to select and manipulate objects using the mouse 80 or other suitable pointing device, thereby minimizing the amount of alphanumeric input the user is required to input via the keyboard 75.
  • a graphic operating system provides icons or objects that can be selected by using the mouse to move the mouse cursor over the desired icon and clicking the appropriate mouse button.
  • the file associated with an icon may be executed or opened by double clicking on the icon associated with the file. Icons may be moved by dragging them to the desired location.
  • the gateway 16 may be a personal computer similar to the computer 10, configured with a modem for communication with the personal computer 10 as well as suitable hardware and software to enable it to communicate with the address validation server computer over Novell named pipes in a local area network.
  • Other protocols known to those skilled in the an could be used in the local area network.
  • Fig. 3 is simplified block diagram illustrating the interaction between the input ou ⁇ ut drivers 300 of the computer 10, the operating system 305, a DDE server application program 310 and a client application program 315.
  • the CPU fetches instructions from the ROM. These instructions perform a power on self test and load the basic input output system (BIOS), which controls the most basic level of communications between the CPU and the peripheral devices. The CPU then loads the operating system into RAM and runs the operating system.
  • BIOS basic input output system
  • the operating system (in conjunction with the BIOS and device drivers) provides the basic interface between the computer's resources, the user, and the application program.
  • the operating system inte ⁇ rets and carries out instructions issued by the user. For example, when the user wants to load an application program, the operating system inte ⁇ rets the instruction (e.g., double clicking on the application program's icon) and causes the hard drive to load the program into RAM. Once the application program is loaded into RAM, it is executed by the CPU. In case of large programs, CPU loads various portions of program into RAM as needed.
  • the operating system also provides a variety of functions or services that allow an application program to easily deal with various types of input/output (I O). This allows an application program to issue relatively simple function calls that cause the operating system to perform all of the steps required to accomplish various tasks.
  • I O input/output
  • the operating system communicates with the application program by sending input and window-management messages to the application program.
  • a "window procedure" in the application program then responds to messages received from the operating system.
  • the window procedures must examine each message from the operating system. At that point, the window procedure carries out some specific action based on the message, or passes the message back to the operating system for default processing.
  • the "WINDOWS" operating system supports Dynamic Data
  • DDE Disposabled Data Exchange
  • server Two application programs, which are referred to as a "server” and a “client”, carry on a DDE conversation by posting messages to each other.
  • a DDE server is a program that provides data to another program (the DDE client).
  • a DDE conversation is initiated by the client program.
  • the DDE server responds by providing the requested data.
  • the DDE client identifies the type of data it wants using three characters strings called the "application,” the data "topic,” and the data "item.”
  • the application string identifies the server application program.
  • the topic name identifies the desired topic. All DDE servers suppon at least one topic.
  • the item name identifies the specific data item that is being requested. Within each topic, a DDE server supports one or more data items.
  • the DDE server application is written in Visual Basic and communicates with a DDE client application program, which may be used by a user for compiling lists of addresses, etc.
  • the address data from the DDE client application is made available to the DDE server application program via DDE. This allows the user to initiate the address validation or geocoding functions from the client application program without reformatting or exporting the data.
  • the DDE server application program communicates with the remote address validation serv er via the gateway, and transmits the input address data.
  • the requested validation data or geocodes are returned to the DDE server application program, and are made available to the client application program via DDE.
  • the current implementation of the DDE server application program supports several DDE client applications, including Microsoft Excel, published by Microsoft Co ⁇ oration, FoxPro, published by Microsoft Co ⁇ oration, Maplnfo. published by Maplnfo Co ⁇ oration, and a generic client provided with the DDE server application program.
  • the generic client may open other database files or import text and use it to create a database.
  • stubs that run under control of the original application.
  • a stub is written for each client application program, and includes a DDE server application menu, and other features related to the DDE server application.
  • the stubs are installed on the hard drive of the personal computer 10 as separately executable programs. The menu and other features are discussed more completely below in conjunction with the operation of the preferred program.
  • the input address data in the client application program 315 is passed to the server application program via DDE messages.
  • the server application program 310 passes the address data to the operating system 305 with instructions indicating that the data is intended for the modem.
  • the operating system 305 transmits the address data to the gateway 16 via the input/ou ⁇ ut drivers 300. which drive the modem.
  • the data is in turn transmitted to the address validation server 17 via the local area network.
  • the data returned by the remote address validation server reaches the client application program 315 by traveling in the opposite direction along the same path.
  • Fig. 4 is a flow diagram illustrating the steps performed by the user in order to validate or geocode address data.
  • Fig. 5 is a state diagram illustrating the method of the present invention as implemented in a DDE client application program running on a personal computer.
  • Fig. 6 is a state diagram illustrating the method of the present invention as implemented in a DDE server application program running on a personal computer.
  • Fig. 7 is a state diagram illustrating the method of the present invention as implemented in a program running on a gateway personal computer positioned to interconnect the personal computer with a remote address validation server.
  • Fig. 8 is a state diagram illustrating the method of the present invention as implemented in a computer program running on a remote address validation server.
  • Fig. 4 is a flow diagram that illustrates the method of the present invention in terms of the steps carried out by the user.
  • the discussion presented in conjunction with the flow diagram summarizes the steps that are required in order to use the preferred embodiment of the present invention to geocode or validate address data.
  • the discussion also describes the options and parameters that are selected by the user.
  • the object selection method 400 of the present invention begins at step 405 when the user launches the DDE server application program. This is accomplished by double clicking on the DDE server application icon. When the DDE server application program is launched, it runs in the minimized mode, and provides an icon at the bottom of the display in order to indicate that the program is running. At this point, the DDE server application program does not have an active window associated with it.
  • the user launches the desired DDE client application stub by double clicking on the appropriate icon in the DDE server application group window.
  • the user then opens or creates the file containing the address that will be validated or geocoded.
  • the preferred DDE server application supports at least four client application programs: Microsoft Excel, FoxPro, Maplnfo, and a generic client program. Icons are provided in the DDE server application group window identifying stubs associated with supported client application programs. These icons are duplicates of the original program icons, and are intended to be used only to run the client application stubs with the DDE server application program.
  • a client application window 460 is opened as shown in Fig. 9, and a special menu item 462 appears on the menu bar that appears at the top of the active client application window.
  • the name of the DDE server application would be used as the title of the menu item, and for pu ⁇ oses of this specification it will be assumed that the title is "Maximatch,” and the menu will be referred to herein as the "Maximatch menu.”
  • the Maximatch menu appears in addition to the menu items normally provided by the client application program, thereby adding functionality to the client dawn, ⁇ - .-. * PCT/US96/05734
  • the user sets the preferences that will be used by the DDE server application program. This is accomplished by selecting the 5 "Preferences" item 464 from the Maximatch menu. This causes a DDE message to be sent to the DDE server application asking it to display its "Preferences" window. In response, the DDE server application program displays a preferences window 470. as shown in Fig. 10, which allows the user to select the preferences that will be used by the address searching programs that run on the remote address 10 validation server and the gateway computer. These selections are entered directly into the DDE server application. Each of the preferences is discussed below.
  • the preferences window 470 includes a communications button 472 that allows the user to open a communications window 474, as shown in Fig.
  • This window prompts the user to set the communications parameters used by the DDE server application program.
  • the communications window allows the user to specify the communications port that the modem is connected to, the type of modem that is connected, and the telephone number that will by dialed by the modem to call the remote gateway 16.
  • the communications window also allows
  • the preferences window 470 allows the user to choose from options 476 pertaining to the notification mode. If the user selects the "notify upon completion” option, the computer will display a scorecard upon completion of the 25 address processing, as shown in Fig. 15. If the user selects the "show progress'' option, the computer will also display a status window that is continuously updated while the DDE server application program is processing addresses.
  • the validation portion of the preferences window 470 allows the 30 user to specify at 478 whether the addresses will be processed automatically or interactively. If the user selects interactive, the DDE server application program displays, for each input address for which there is a match, a validation panel (Fig. 14) showing the current record and a list of candidate addresses returned after processing on the remote address validation server. The program waits for the user 35 to select the correct address. If the user selects automatic, the address validation or geocoding process runs automatically and returns a single address to the user for each input address for which there is a match. The returned address is identified based on search criteria that are discussed below. In automatic mode, or batch mode, the input addresses are transmitted and processed one-by-one without user intervention until all have been completed or the user selects "cancel" and terminates processing.
  • the preferences window 470 provides several search criteria at 480 that are set by the user and applied to both automatic and interactive address validation and geocoding.
  • the choices for the search criteria depend on the particular validation or geocoding program running on the address validation serv er.
  • the first of these search criteria is called a quality value.
  • the user specifies a number ranging from 1 to 100.
  • the quality value provides a level of acceptability for the remote address validation server to consider when matching addresses.
  • a quality value of 100 tells the remote address validation server software to search for exact matches.
  • a quality value of 1 would allow consideration of everything. Lowering the quality value results in a broader, but slower search.
  • the default quality value is 80.
  • the algorithm used by the remote address validation server is discussed below in conjunction with Fig. 8.
  • the user also specifies a candidate value that determines how many possible matches will be retained for consideration by the user (in interactive mode) or the gateway (in automatic mode). For example, this number may range from 1 to 15. Increasing the number results in broader, but slower searches. If the user selected the interactive mode, the maximum number of possible matches displayed to the user is determined by this parameter. The default candidate value is 5.
  • the preferences window 470 also allows the user to instruct the geocoding function to use "zip centroids" if an address cannot be matched. When zip centroids are used, the geocode function will return the coordinates of the center of the zip code area if no match can be found. (5) Automatic match criteria
  • the preferences window 470 provides additional parameters at 482 for selection by the user.
  • the automatic match criteria parameters specify how the gateway application chooses the best match when in the automatic mode. Examples of automatic match criteria are: Exact All address components of the candidate address must exactly match the input address.
  • the preferences window 470 also allows the user to select additional filters that are used to filter out unwanted matches in the automatic mode. Clicking on a "Filters" button 484 in the preferences window opens a window 486, shown in Fig. 12. for selection of filters.
  • the address range matching filter selected at 488 filters out potential matches that do not satisfy the user's address range accuracy requirements. This is especially useful for geocoding areas with sparse address range data.
  • the choices for the automatic range matching criteria are:
  • Exact Street range of candidate must be an exact match to input address.
  • any Any candidate address range can be accepted.
  • the user may also activate filters 490 and/or 492 to specify whether the candidate address must match the correct side of the street and/or the original zip code. If “must match correct side of street” is selected, the gateway filters out candidates whose address ranges do not match the input street number's parity (if the database indicates that there is an "even” and “odd” side of the street). If “must match original zip code” is selected, the gateway filters out potential matches that do not match the input address's zip code.
  • the method proceeds to step 420 of Fig. 4, and the user selects the address components that will be used by the remote address validation server program. In the preferred system, this step is only required when the client application program is Microsoft Excel. This allows the user to select the cells that contain the input address data.
  • the user selects the desired function from the
  • Maximatch pull down menu The user may select "Geocode” or "Validate,” resulting in the display of a window 495 by the client application, as shown in Fig. 13 for the case of the generic client.
  • the user identifies the source of the input address data by selecting fields at area 496 of the window 495. In the prefened system, this step is not required when the client application program is Microsoft Excel. However, with some client application programs, the user must identify the table that includes the input addresses and the specific fields that hold the address components.
  • the user selects the desired return values from all of the data that will be returned by the gateway. The is done using area 497 of the window 495 in a well known manner. The user also identifies the fields in the client application program in which the return values will be stored.
  • the possible return values include:
  • the reject codes include:
  • the longitude and latitude return values are not available.
  • the matching addresses or geocodes with matching addresses are returned by the gateway 16 program.
  • the DDE server application program will present a validation window 499 that includes the current input address and a list of possible candidates, as shown in Fig. 14.
  • the size of the list is controlled by the number of candidates variable described above in conjunction with the preferences.
  • the user may select one of the candidates, which is stored in the designated destination fields, or may cancel consideration, or modify the displayed input address and click the "retry" button in the window 499.
  • the status window will then continue to be updated to show the number of addresses completed, the percentage matched, and what portion of the addresses remains to be processed.
  • the data sending and return steps are repeated until all of the addresses selected at steps 420 or 430 are processed. If the system is operating in the automatic mode, the return values will be stored in the destination fields. At that point, the method 400 is complete.
  • Figs. 5-8 are state diagrams illustrating the method of the present invention as implemented in the client application program, the DDE server application program, the gateway program, and the remote address validation server, respectively.
  • the pu ⁇ ose of the state diagrams is to illustrate the interaction betw een each of the program modules. State diagrams have been chosen because the processes are primarily event driven (rather than process driven).
  • Fig. 5 is a state diagram illustrating the method 500 of present invention as implemented in a client application program.
  • the client application program is Microsoft Excel, FoxPro, Maplnfo, or the generic clienL modified by a DDE client application stub.
  • a stub is a program module that is used to alter an application program.
  • the stub is typically written in a macro language or other prograrriming language supported by the application program, such as MS Visual Basic or MapBasic.
  • the stub is written to add the Maximatch menu to the menu bar, and to add functionality associated with the DDE server application program. This added functionality is described in conjunction with the state diagram.
  • the method 500 begins at state 505. At this point, the client application program has not been launched by the user. When the user goes to the DDE server application group and double clicks on the client application stub's icon, the method proceeds to state 510 and loads the client application stub program. After the client application stub is loaded, at state 515 the menu bar with the Maximatch menu item is displayed.
  • the method advances to the idle state 520.
  • the DDE server application functions have not been initiated and the normal functions provided by the client application program are available to the user.
  • the method proceeds to state 525.
  • the client application sends a DDE command string to the server application program indicating that the server application program should display its preferences window.
  • the method 500 then returns to the idle state 520.
  • the method proceeds to state 530 and the client application displays a window 495 that allows the user to specify the source (table, fields. etc. ) of the input address data, the return values, and the destination fields for the return values (except in the case of Microsoft Excel). The user may elect to cancel the function from the window 495. After the user supplies this information and clicks "OK" in the window, the method proceeds to state 535. where the client application program uses a DDE link to transmit a "connect" command to the DDE server application, which in response establishes modem communication with the gateway 16. After the "connect" command is sent, the client application waits for
  • the client application program sends the first address to the DDE server application program.
  • the client application program waits for "ready" to appear in a status field provided by the server application program to indicate that the return data is available. This is accomplished using DDE messages to poll the status item on a form posted by the DDE server application program.
  • the program, topic, item for the DDE message are the NAME of the DDE server application, VALIDATE (OR GEOCODE), and STATUS, respectively.
  • the client application retrieves the value of the status item from the DDE server application program in response to the polling message.
  • the method proceeds to state 545 and requests the desired return data from the DDE server application program. This is accomplished using a separate DDE message to request each of the specific items (e.g., latitude, longitude, method, rank, etc.) that were identified by the user in the window 495 displayed at state 530.
  • the DDE server application program makes each piece of requested data available to the client application.
  • the method goes to state 548.
  • the client application receives and stores the return data in the designated field. If the client application program has additional addresses to send to the DDE server application program, it returns to state 540 and sends the next address. The method 500 then returns to the idle state 520.
  • Fig. 6 is a state diagram illustrating the method 600 of present invention as implemented in a DDE server application program.
  • the DDE server application program interacts directly with the client application program.
  • the method 600 begins at state 605. At this point, the server application program has not been launched by the user. When the user goes to the DDE server application group and double clicks on the DDE server application icon, the method proceeds to state 610 and loads the DDE server application program.
  • the method advances to the idle state 615.
  • the idle state the DDE server application functions have not been initiated and the normal functions provided by the client application program are available to the user when it is loaded.
  • the client application program sends a preferences command to the DDE server application program via DDE. This causes the method to proceed to state 620, where the DDE server application program displays the preferences window. As described above in conjunction with Figs. 4 and 9-12, the preferences window allows the user to set the parameters that will be used to control the validation or geocoding session. After the preferences are entered, the method returns to the idle state 615.
  • the method goes to state 621 after it receives a "connect" message via DDE from the client application.
  • the DDE server application then establishes telephone communication with the gateway 16.
  • parameters including the selected preferences and the nature of the processing request are received from the client application program.
  • This DDE message is sent by the client application program after the user selects the Geocode or Validate options from the Maximatch menu and selects the return data and destination.
  • the DDE server application program transmits the input address data to the gateway 16.
  • the DDE server application program sends the current preference settings to the gateway, which stores them.
  • a status window is displayed.
  • the DDE server application program receives and stores the matching address data from the gateway. In the interactive mode, the method moves to state 641 and displays the match candidates for the user in a validation window 499, shown in Fig. 14.
  • An additional text box holds all of the characters of the input address concatenated into a single string.
  • the user may select one of the candidates, whose information is stored in various text boxes of a form ready to be accessed by the client application program. Or, the user may modify the original input address, select
  • the method 600 continues to make return data items available to the client application program by returning to state 630 as long as it continues to receive data requests from the client application program. If the client application program indicates that all of the input addresses have been processed, the method disconnects the communications link with the gateway.
  • Fig. 7 is a state diagram illustrating the method 700 of present invention as implemented in a computer program running at the gateway 16.
  • the gateway is connected by modem to the personal computer 10 for cornmunication between the DDE server application program and a gateway application program, the function of which will become apparent from the following description.
  • the gateway application program may be written in an appropriate language such as visual basic.
  • the method 700 begins at state 702. At this point, the gateway application program has not been launched. When this is done in a conventional manner, the method proceeds to state 703 and launches the gateway application program. At this point, no communication has been established with the personal computer 10. At state 705. the gateway application initializes the modem, and the method proceeds to state 710 and establishes separate connections via the local area network 19 to the validation program and the geocoding application programs running on the address validation server 17. Then the method proceeds to an idle state 715 and waits for a signal from the DDE server application program.
  • the gateway program When a call comes in via the modem from the DDE server application program, the gateway program answers the call at state 720. Then the method proceeds to state 725 where data consisting of the entered preferences and request type (validate or geocode) is received from the DDE server application program and stored. This is followed at state 730 by address data.
  • the gateway program Upon receiving an address, the gateway program detects whether the address is parsed in a manner required by the requested address validation server function (validation or geocoding). If parsing is necessary, this causes the method to proceed to state 735, at which the gateway program parses the address data.
  • Various parsing programs arc readily available. The parsing program identifies the components of an address. Those skilled in the art will understand that the parsing parameters and insertion of delimiters between pieces of text will vary depending upon the needs of the particular validation or geocoding application running on the address validation server.
  • the method proceeds to state 740, where the parsed pieces of the address and the user's preferences are stored in a data structure suitable for transmission over the Novell named pipes to the address validation server 17, and acceptable to the application running on the address validation server.
  • the gateway transmits the parsed input address data and preferences to the address validation server 17.
  • the gateway receives and stores the return matching address data and/or geocoding values, and other return values, from the address validation server. The return values that may be specified by the user are listed above. All candidates that are a match according to the address validation server matching program, operating within the "search criteria" preferences described above, are returned to the gateway.
  • the candidates are sorted. First, the candidates are assigned the automatic match criterion which they achieved. Next, they are so ⁇ ed by such criteria, in descending order of exactness of the match. Then a secondary sort is conducted by quality score within candidates having the same automatic match criterion. Then a tertiary sort is conducted by closeness oi address range. If the user has selected interactive mode, the method proceeds to state 760, where the candidate matches and return value are transmitted to the DDE server application program (see state 640 of Fig. 6) for user review. If the user has selected automatic mode, the method then proceeds to state 755, at which the return data is processed and filtered by the gateway application. The filters specified in the "Filters" window shown in Fig.
  • each candidate 12 are applied to each candidate starting at the top of the sorted list. For example, if the "must match original zip code" filter is selected, the candidate will be discarded if it has a differing zip code. If the "must match conect side of street” filter is selected, the candidate will be discarded if its street number has a parity opposite to the original address.
  • the address range filter is applied according to the level selected to discard the candidate if its address range is not close enough to the range of the original address. The first candidate to pass the tests of the filters will be returned to the DDE server, in the automatic mode.
  • Fig. 8 is a state diagram illustrating the method 800 of present invention as implemented in a computer program running at the remote address validation server.
  • the remote address validation server contains the databases ti at are used for address geocoding and validation.
  • the remote address validation server also performs the geocode and validate functions based on the input data and search parameters provided by the DDE server application program running on the personal computer 10 via the gateway 16.
  • the database used to validate addresses is based on the ZIP+4 database provided by the United States Postal Service. This database includes virtually all of the valid addresses in the United States.
  • the database used to geocode addresses is based on commercially available geocoding data, such as the TIGER database, provided by the United States Government. This database includes geographic coordinate data associated with addresses in the United States.
  • the addresses in these databases may be stored all or in part as ranges of addresses and their parity (odd or even side of street) rather than individual addresses. The present invention does not require access to any individual address data.
  • the method 800 begins at the idle state 805.
  • the remote address validation server 17 is available to receive calls from the gateway 16 over the local area network 19.
  • the method goes to state 810 and establishes a communications session with the gateway for each of the application programs running on the address validation server.
  • the remote address validation server is capable of conducting multiple communications sessions simultaneously. As described above, the remote address validation server will use the preference settings to determine the parameters of the validation or geocode process.
  • the method goes to state 820, where the remote address validation server searches the appropriate database (geocode or validation) to find matching addresses. This process is controlled by the search criteria included in the preferences that were set by the user.
  • the searching and matching algorithm (which is not part of the present invention) may be any one of several as described above. One skilled in the art will be able to modify the form of the address data and preference parameters according to the input needs of the particular validation or geocoding program being used.
  • the method proceeds to state 825 and transmits the return data to gateway 16. This data includes all of the data discussed above in conjunction with the selection of the return values.
  • the method returns to state 820 and processes the new address. If a message from the gateway instructs address validation server to terminate processing, the method terminates the communication session and returns to the idle state 805.
  • the foregoing methods of the present invention may conveniently be implemented in a program module that is based upon the state diagrams of Figs. 5- 8. No particular programming language has been indicated for ca ⁇ ying out the various procedures described above because it is considered that the operations, steps and procedures described above and illustrated in the accompanying drawings are sufficiently disclosed to permit one of ordinary skill in the art to practice the instant invention. Moreover, there are many computers and operating systems which may be used in practicing the instant invention and therefore no detailed computer program could be provided which would be applicable to these many different systems. Each user of a particular computer will be aware of the language and tools which are most useful for that user's needs and purposes.
  • the present invention may be embodied on a single computer in various ways.
  • One way is to use the DDE utility for communication between the program units including the address validation and/or geocoding application.
  • Another way would be by linking the functional units represented in the above embodiment by the DDE server application and the address validation and/or geocoding application, into one executable program group. This would eliminate the need for communication via modem.
  • languages such as Visual Basic include commands such as "Call to External Function" that can be utilized to link program units found in a library such as a "Dynamic Link Library.”

Abstract

Cette invention concerne un système et un procédé permettant à un utilisateur de valider et/ou d'effectuer le géocodage de données d'adresses permanentes dans un programme d'application de l'utilisateur, ceci à l'aide d'un programme de validation ou de géocodage permanent dans un serveur de validation d'adresses à distance. Cette opération est réalisée depuis l'intérieur d'un programme d'application de l'utilisateur, tel qu'un tableur, un traitement de texte, un programme de mappage de bureau, ou encore un programme de gestion de banque de données fonctionnant sur un ordinateur personnel et sans que l'utilisateur ait à exporter ou reformater les données. Ce système fait appel à un programme d'application de serveur fonctionnant sur l'ordinateur personnel et communicant avec le programme d'application de l'utilisateur par l'intermédiaire d'une liaison telle qu'un serveur DDE.
PCT/US1996/005734 1995-04-28 1996-04-24 Systeme et procede de validation et de geocodage d'adresses WO1996034354A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43104695A 1995-04-28 1995-04-28
US08/431,046 1995-04-28

Publications (1)

Publication Number Publication Date
WO1996034354A1 true WO1996034354A1 (fr) 1996-10-31

Family

ID=23710213

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/005734 WO1996034354A1 (fr) 1995-04-28 1996-04-24 Systeme et procede de validation et de geocodage d'adresses

Country Status (1)

Country Link
WO (1) WO1996034354A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000057258A2 (fr) * 1999-03-19 2000-09-28 Cybersource Corporation Procede et dispositif de verification d'informations relatives a des adresses
US6182227B1 (en) 1998-06-22 2001-01-30 International Business Machines Corporation Lightweight authentication system and method for validating a server access request
EP1402472A1 (fr) * 2001-05-31 2004-03-31 Mapinfo Corporation Systeme et procede de geocodage de structures d'adresses diverses
WO2005050481A1 (fr) * 2003-10-21 2005-06-02 United Parcel Service Of America, Inc. Structure de donnees et systeme de gestion pour un sur-ensemble de bases de donnees relationnelles
US7305404B2 (en) 2003-10-21 2007-12-04 United Parcel Service Of America, Inc. Data structure and management system for a superset of relational databases
US7542972B2 (en) 2005-01-28 2009-06-02 United Parcel Service Of America, Inc. Registration and maintenance of address data for each service point in a territory
US7574447B2 (en) 2003-04-08 2009-08-11 United Parcel Service Of America, Inc. Inbound package tracking systems and methods
US20100088132A1 (en) * 2008-10-08 2010-04-08 Oracle International Corporation Merger and acquisition data validation
US7743043B2 (en) 1999-10-19 2010-06-22 Stamps.Com Address matching system and method
US9898497B2 (en) 2015-03-31 2018-02-20 Oracle International Corporation Validating coherency between multiple data sets between database transfers
US10140352B2 (en) 2014-07-17 2018-11-27 Oracle International Corporation Interfacing with a relational database for multi-dimensional analysis via a spreadsheet application

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994011810A1 (fr) * 1992-11-13 1994-05-26 Microsoft Corporation Procede et systeme de classement d'indicateurs d'interface pour appels de traitement a distance
US5341505A (en) * 1990-10-30 1994-08-23 Whitehouse Harry T System and method for accessing remotely located ZIP+4 zipcode database

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5341505A (en) * 1990-10-30 1994-08-23 Whitehouse Harry T System and method for accessing remotely located ZIP+4 zipcode database
WO1994011810A1 (fr) * 1992-11-13 1994-05-26 Microsoft Corporation Procede et systeme de classement d'indicateurs d'interface pour appels de traitement a distance

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Don't forget the postcode (addressing systems)", WHICH COMPUTER?, OCT. 1994, UK, ISSN 0140-3435, pages 46 - 47, 49 - 50, 53, 55, XP000578839 *

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6182227B1 (en) 1998-06-22 2001-01-30 International Business Machines Corporation Lightweight authentication system and method for validating a server access request
WO2000057258A3 (fr) * 1999-03-19 2001-01-18 Cybersource Corp Procede et dispositif de verification d'informations relatives a des adresses
WO2000057258A2 (fr) * 1999-03-19 2000-09-28 Cybersource Corporation Procede et dispositif de verification d'informations relatives a des adresses
US8103647B2 (en) 1999-10-19 2012-01-24 Stamps.Com Address matching system and method
US7882094B2 (en) 1999-10-19 2011-02-01 Stamps.Com Address matching system and method
US7743043B2 (en) 1999-10-19 2010-06-22 Stamps.Com Address matching system and method
US8392391B2 (en) 1999-10-19 2013-03-05 Stamps.Com Address matching system and method
US8843464B2 (en) 1999-10-19 2014-09-23 Stamps.Com Address matching system and method
US7685108B2 (en) 2001-05-31 2010-03-23 Pitney Bowes Software Inc. System and method for geocoding diverse address formats
EP1402472A4 (fr) * 2001-05-31 2007-10-31 Mapinfo Corp Systeme et procede de geocodage de structures d'adresses diverses
EP1402472A1 (fr) * 2001-05-31 2004-03-31 Mapinfo Corporation Systeme et procede de geocodage de structures d'adresses diverses
US7574447B2 (en) 2003-04-08 2009-08-11 United Parcel Service Of America, Inc. Inbound package tracking systems and methods
US7305404B2 (en) 2003-10-21 2007-12-04 United Parcel Service Of America, Inc. Data structure and management system for a superset of relational databases
WO2005050481A1 (fr) * 2003-10-21 2005-06-02 United Parcel Service Of America, Inc. Structure de donnees et systeme de gestion pour un sur-ensemble de bases de donnees relationnelles
US8386516B2 (en) 2005-01-28 2013-02-26 United Parcel Service Of America, Inc. Registration and maintenance of address data for each service point in a territory
US7912854B2 (en) 2005-01-28 2011-03-22 United Parcel Service Of America, Inc. Registration and maintenance of address data for each service point in a territory
US7542972B2 (en) 2005-01-28 2009-06-02 United Parcel Service Of America, Inc. Registration and maintenance of address data for each service point in a territory
US20100088132A1 (en) * 2008-10-08 2010-04-08 Oracle International Corporation Merger and acquisition data validation
US8725701B2 (en) * 2008-10-08 2014-05-13 Oracle International Corporation Merger and acquisition data validation
US10140352B2 (en) 2014-07-17 2018-11-27 Oracle International Corporation Interfacing with a relational database for multi-dimensional analysis via a spreadsheet application
US9898497B2 (en) 2015-03-31 2018-02-20 Oracle International Corporation Validating coherency between multiple data sets between database transfers

Similar Documents

Publication Publication Date Title
US10311073B2 (en) System and method for asynchronous retrieval of information from a server to a client based on incremental user input
US5339392A (en) Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US7206998B2 (en) System and method for automatically learning information used for electronic form-filling
US8260844B2 (en) Information messaging and collaboration system
US8306506B1 (en) Apparatuses for requesting, retrieving and storing contact records
US6708166B1 (en) Method and apparatus for storing data as objects, constructing customized data retrieval and data processing requests, and performing householding queries
EP0960377B1 (fr) Procede d'acces a des informations sur un ordinateur central a partir d'un ordinateur client
US6701352B1 (en) Method and apparatus for importing information from a network resource
US7607100B2 (en) Method, system and program product for display management of web page phone/fax numbers by a data processing system
US7487223B2 (en) Method and apparatus for regenerating message data
US20040093317A1 (en) Automated contact information sharing
US6219054B1 (en) Information processing method and apparatus for preparing a GUI on a client by utilizing an electronic mail message or an agent
JP3969595B2 (ja) メール情報提供サーバ、メール情報提供システム、メール情報提供方法、メール情報提供プログラム
WO2002019127A1 (fr) Integration d'applications d'entreprise (eai) axee sur les operations et systeme de mise au point
US7330876B1 (en) Method and system of automating internet interactions
US20030226104A1 (en) System and method for navigating search results
US5897630A (en) System and method for efficient problem determination in an information handling system
US20020059360A1 (en) Local-file-transfer method and local-file-transfer system for client-server system
WO1996034354A1 (fr) Systeme et procede de validation et de geocodage d'adresses
US20030018789A1 (en) Information providing method and information providing system and terminal therefor
WO2000074193A9 (fr) Systeme de support utilisateur et procede s'y rapportant
JPH09507595A (ja) 家庭用銀行業務システム
JPH10289206A (ja) ホームページ通信システム
JP2002006970A (ja) アプリケーションソフトウェア試用システム
JP2002334112A (ja) データベース管理システム及びプログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA