System for placing product delivery orders through the internet

[0001] 1. Field of the Invention

[0002] This invention relates in general to the delivery of product orders. In particular, the invention relates to a system by which a delivery or pick up order can be placed over the Internet to one of a plurality of potential vendors.

[0003] 2. Background Art

[0004] In recent years, the Internet has rapidly become a prominent aspect of commerce throughout many areas of the world due to its efficiency and convenience. Furthermore, the Internet offers consumers access to a breadth of information and services greater than ever before. The concept of “electronic commerce” has now become a reality whereby a consumer can purchase goods via the Internet. Consumers can view both descriptions and pictures of items offered for sale via a web browser, place an order and make payment via a web site. While sitting at a computer, within mere minutes a person can comparison shop at numerous stores across the country, and even the world.

[0005] However, certain types of commerce for which the Internet can be effectively employed still depend upon the geographic proximity between a user wishing to purchase goods and/or services and a business offering goods and services. Specifically, some services, such as the delivery of prepared food items, are provided by a business only to customers located within a specific predefined geographic area relative to the business' location. Therefore, while a user in New York could easily access a Chicago pizzeria's web site via the Internet and order a pizza for delivery to New York, such an order would not typically be fulfilled. Accordingly, it is an object of this invention to identify business locations that have service areas covering the user's location.

[0006] Oftentimes, a user may wish to order a product or service from one of a chain of related businesses, such as a pizza delivery franchise, over the Internet. Franchisees are typically assigned rigidly defined market areas by the franchiser. Furthermore, a franchisee business may desire to include or exclude specific geographic regions from its assigned service area. Therefore, it is highly desirable, and an object of this invention, to allow vendors to customize and very accurately define specific geographic areas that they wish to service via orders placed over the Internet.

[0007] One prior art technique for correlating users with local service providers relies upon the user providing his postal zip code to a central computer server operated by or on behalf of the business. The central computer then determines which if any relevant businesses service the user's zip code. The list of relevant businesses identified by the server can either be returned to the user, or else the central office can automatically select one business to which the order is to be placed. However, this model is of limited utility insofar is it correlates users to local businesses by matching postal zip codes—which are arbitrarily predefined regions unrelated to typical delivery area boundaries that may be desired by a business. Accordingly, it is an object of this invention to provide for the arbitrary implementation of service area boundaries for orders placed via the Internet.

[0008] Another technique for correlating Internet consumers with local businesses is disclosed by Cupps, et al., U.S. Pat. No. 5,991,739. The Cupps et al. technique involves the generation of an arbitrary geographic grid through which the world is divided into an array of quadrilateral regions. Each region is assigned an identifier code which is a function a series of longitude and latitude coordinates. A business providing a service over a defined geographic area, such as a food delivery business, can therefore associate itself with identifier codes for each of the grid regions within its defined delivery region. When a customer desires to place an order, the customer's address is received by a central computer server, and therein associated with a specific geographic grid or region. Businesses that service the customer's location can then be rapidly identified by indexing the store delivery grid database with the customer geographic grid or area. The customer is then presented with a selection of businesses whose associated service areas include the grid in which the service is to be provided. The customer can choose a desired business, and electronically transmit an order to the central server. The central server then relays the order to the selected business via a telephone call by an interactive voice system.

[0009] Cupps et al. provides for faster correlation between customers and businesses, and increased flexibility in business service area definition, compared to the zip code matching prior art, insofar as the geographic areas associated with the service area can be smaller than postal zip codes. However, by defining the location of the customer and the business' service areas in terms of predetermined geographic areas, the Cupps et al. technique inherently introduces uncertainty and imprecision to the positional identification of both the consumer, and the borders of a business service area.

[0010] In areas of commerce with very tightly defined service boundaries, such as pizza delivery franchises, accurate and precise association of customers with store service areas is particularly important. Franchisees who provide service to areas outside of their assigned territory may violate or breach their franchise agreements and be subject to penalty or even termination of their franchise rights. Franchisers often look to police franchisee activities to protect adjacent franchisees. Because the Cupps et al. technique is based upon a predefined grid, it is susceptible to erroneous and imprecise correlation between stores and customers. One source of imprecision is that each store must define its service region in terms of the predetermined grid areas, rather than a geographic definition corresponding to the service area. A second source of error is that a customer is referenced by association with a geographic grid or area, rather than the customer's actual position. Furthermore, as grid size is reduced linearly, the complexity and inefficiency of the Cupps et al. algorithm increases geometrically due to the geometrically increasing number of quadrilateral grid areas that must be stored and searched within the service area database. Accordingly, it is an object of this invention to correlate Internet customers with business service areas to a degree of accuracy limited only by the precision of commercially available mapping software.

[0011] As use of the Internet becomes increasingly prevalent, many more businesses will have digital communication network access available in-store, via either a dedicated Internet connection or a telephone line modem or other communication device capable of receiving data or information transmissions. Furthermore, stores often use electronic Point Of Sale (“POS”) order systems for the electronic entry and tracking of orders placed by customers who place orders by telephone. Accordingly, it is also an object of this invention to utilize communications networks to transfer a customer's order from a central server to a store's POS for automatic entry into a selected store's order system, whereby the order is processed automatically as if it were entered in-store.

[0012] The POS order systems used by many delivery businesses incorporate street address files to identify and log locations to which orders are delivered. In implementing an Internet order delivery system for such businesses, it may be beneficial, when possible, to match a customer's location with a particular entry in the store's street address file. By correlating the customer's location to the in-store delivery area file, an order placed electronically can be automatically processed by an existing POS system according to the pre-existing order protocol. Accordingly, it is an object of this invention to correlate customers with stores using a street address file defined for each store.

[0013] Many areas utilize vanity addresses, or other non-standard addresses, that may not appear in commercially available location indexing software packages. For example, a customer located on the 63rd floor of the Sears Tower, in Chicago, Ill., may enter a delivery address of 6300 Sears Tower, Chicago, Ill. Likewise, a student on a college campus may enter the room number and name of a dormitory, rather than the actual dormitory street address. Insofar as such vanity addresses are not actual street addresses, they typically may not appear in common address/geographic databases. Therefore, many prior art systems, such as the Cupps et al. system, may fail to automatically process such an order. Accordingly, it is an object of this invention to allow a business to extend its definition of acceptable service areas to include non-standard addresses.

[0014] One particular object of the present invention is to provide a registration engine to enroll users and at the time of enrollment associate one or more business locations who serve the user's geographic location such that when the user logs into the system at a later time the system will recognize the user and provide the previously identified business locations from which the user may order goods or services.

[0015] A further object of the present invention is to provide a marketing engine whereby a business' POS system can update the central server with store manager specials relating to price or items or services offered to thereby provide highly customized offerings to user's who have a particular association with a business location. For example, a pizza store located near a college campus may offer “homecoming” specials while a store across town that does not deliver to the campus location may not.

[0016] Yet another object of the present invention is the provision of a unique POS identification such that users who access a particular business's records stored on the central computer view a unique visual presentation which may differ from that offered to a user who seeks another business.

[0017] These and other objects of the present invention will become apparent to those of ordinary skill in the art in light of the present specifications, drawings and claims.

[0018] The invention provides a technique by which a customer can place an order over the Internet for provision of a service to a business with a geographic service area that includes the customer's desired delivery location. Through the use of a web browser, the customer logs into a central service web site, and provides his street address thereto. Alternatively, such information could be transmitted to the web site from a third party provider, such as a cable access provider, as in the case of interactive television.

[0019] The web site first indexes a master database of ZIP codes to generate a first list of stores that provide service to at least some part of each ZIP code.

[0020] The web site contains databases of service area street map information for each business with which it is associated. The street map information includes city, state, and street names, along with precisely defined ranges of addresses to which delivery is available on the named streets. The site searches to determine whether the delivery address is located within the street map file for each store of the first list of stores. For each street map file in which the delivery address is located, the associated store is added to a list of available stores.

[0021] When a delivery address cannot be located within a store's street map, the web site utilizes a geopointing technique as an alternative determination of whether the store services the delivery location. Each store is associated with a set of latitude and longitude coordinate points, which points define the vertices of a geographic polygon within which the store provides service. The delivery address is converted to a precise latitude and longitude coordinate point via software techniques known in the art of geographic location. The site then determines whether the delivery address coordinate point lies within the polygon associated with the store service area. If so, the store is added to the list of available stores.

[0022] Stored for each store in conjunction with the polygon vertices, are the coordinates of a rectangle that encompasses the entire polygon, and convex hull information derived from the polygon vertices. The process of determining whether the delivery address coordinate point lies within the service area polygon is then accomplished in three steps. Firstly, a store is considered not available if the delivery address coordinate point lies outside of the rectangle bounding the entire store service area. Secondly, the store is considered not available if the delivery address coordinate point lies outside of the convex hull of the polygon vertices. Finally, an exact determination of whether the delivery address coordinate point lies within the store polygon is performed. The store is considered not available if a ray extending from the coordinate point crosses segments of the polygon boundary an even number of times. Stores remaining after these three steps are considered to be available as geopointing matches.

[0023] Finally, if a store fails to match the delivery address by way of both the street map file lookup and geopoint matching, alternative matching techniques can be employed. The delivery address provided by the user can be progressively truncated until it matches one or more street names found in the store street map file, at which point the user has the option of selecting one of the partially matched street names as the delivery address, and the store with which the street map file is associated as an available store. The web site can also search a store's customer database for records with a telephone number field matching the delivery telephone number provided by the user. Matching records in the store customer database are then displayed to the user for possible selection thereof as delivery information for the user's present order. Accordingly, the store from which the matching customer database record was retrieved is deemed to be an available store.

[0024] If one or more stores are found to be available to service the delivery location, one of the available stores is assigned to the user for receipt of orders therefrom. The user is presented with an order entry page, with which an order can be entered into the web site. The web site then places the order electronically with the assigned store, and emails an order confirmation to the user.

[0037] While this invention is susceptible to embodiment in many different forms, there are shown in the drawings and will be described in detail herein several specific embodiments. The present disclosure is to be considered as an exemplification of the principle of the invention intended merely to explain and illustrate the invention, and is not intended to limit the invention in any way to embodiments illustrated.

[0038] The embodiment illustrated is a system for placing orders for pizza delivery or carry out using a web browser via an Internet web site to a store that is a part of a chain of restaurants. For purposes of this disclosure the web site is referred to by the name Quikorder.com. While the present invention is disclosed in the context of businesses providing pizza and pizza delivery and carry out services the invention is deemed to have utility in other fields. The invention implements multiple techniques by which customers are associated with restaurants. However, it is envisioned that the techniques could be implemented individually, or in other combinations, as desired. Furthermore, the techniques taught herein can readily be adapted for use in conjunction with restaurants not part of a franchised chain, or with businesses providing services other than food delivery. The system disclosed can also be implemented using access mechanisms other than an Internet World Wide Web interface, such as other Internet protocols, modems, wireless modems, or interactive television data terminals.

[0039] The user first accesses the QuikOrder site by following a Universal Resource Locator (“URL”) link to the logon/registration page of the QuikOrder web site, step 100, depicted in FIG. 1. Businesses can implement their own branded entry points to the system by utilizing branded third level domains (for example: http://dominos.quikorder.com for Domino's Pizza restaurants). In step 110, the user is presented with the option to either log on with an existing username and password (step 120) or to register themselves as a new user. If the user is a pre-existing user and enters a valid username and password, the user will be next directed to the order taking process 800. If the user is new to the system, the user will then proceed to the new user registration page (step 200).

[0040] FIG. 2 illustrates operation of the registration engine which executes the new user registration process. The user enters the ZIP code of the address to which delivery is to be made in step 210. The system then retrieves a list of stores that service the delivery ZIP code from a store-ZIP association database (step 220). Step 220 serves several functions. It provides a quick rough check to see whether or not the user can be serviced at all, thereby allowing for a prompt response to users with no nearby participating restaurants—before the user is required to undergo a time consuming data entry process. Also, step 220 serves as a rough sort to narrow the list of restaurants that must be analyzed for precise correlation with the user delivery location.

[0041] It is understood that the user login procedure and the provision of information, as described in steps 100–210 of the illustrated embodiment, could be performed in an automated manner in other embodiments of this invention. For example, when a user accesses the system via an interactive television or wireless access device, the login and/or address information could be previously associated with the user and transmitted automatically by a third party service provider upon the user's access to the food delivery system disclosed herein.

[0042] In step 230, the system determines whether any restaurants at all were found that service the user's delivery ZIP code. If there are no stores found that service the entered ZIP code, the user is presented with a message informing them that the system is unable to service them (step 240). If one or more stores are found to service the user's ZIP code, the user is prompted to provide full account information, including complete delivery address, telephone number, and e-mail address (step 250).

[0043] After the user provides the requested account information, the system first performs a basic standardization by converting the input to all uppercase characters and removing any extraneous punctuation, such as periods placed at the end of abbreviations (step 260). Because the user is prompted to enter their street address in a natural manner, by including the house number with the street address, in step 270 the system parses out the numeric part of the user input to separate the house number from the street name. In step 300, the system then processes that address in a series of successive steps to determine if any of the stores that had previously been identified as servicing some portion of the user's ZIP code are able to service the user's exact address.

[0044] FIG. 3 illustrates step 300, the process by which the delivery address is tested against store data to determine which stores, if any, service the exact delivery address. For the first store identified as servicing the user's ZIP code, the system first references a predefined STREET file database associated with that store. The STREET file database is based upon information set up manually by the store owner, and is comprised of state, city, and street name combinations that are serviced by each store. For each street name, there is also a series of entries listing the address ranges serviced on that street. Sample data from a store STREET file is shown in FIG. 4.

[0045] If an exact match of the delivery state, city, and street name is made with an entry in the store's STREET file database, and the house number is within a range appearing therein, the store is included in a list of stores that service the requested user delivery location (step 315). After a matching store is added to the list, the system determines if any additional stores were identified as including the user delivery ZIP code within its service area, step 330. If all potentially matching stores have already been evaluated for an exact match with the delivery address, the system proceeds via step 290 to assigning one or more business locations to the user and via step 295 toward order entry process 800. If additional stores serving within the delivery ZIP remain to be checked, the matching process is incremented to identify the next potentially matching store, step 335, and the matching process is repeated back to step 310.

[0046] If an exact match of the user's address with an entry in the store's STREET file is not found, the system then iteratively tries to substitute in all valid postal abbreviations in the user's address, step 320, and checks to see if there is an exact match, step 330. Again, if there is an exact match, the system includes the identified store to a list of stores that can service the user (step 315). If not, the system proceeds to use various other address transforming techniques derived from postal Coding Accuracy Support System (“CASS”) techniques, to try to match the user's delivery address to addresses contained within the STREET file, step 340. If an exact match is found between the processed delivery address and an address within the store's STREET file, the store is added to the list of stores that service the user's address, step 315.

[0047] If an exact match between the user's address and a store STREET file entry is still unable to be made, the system then implements a geopoint lookup procedure 400. A geopoint lookup procedure is illustrated in the flowchart of FIGS. 5–7. As illustrated in FIG. 5, the first step in the geopoint lookup procedure is to try to determine an exact geographic position (latitude/longitude) for the address the user submitted, step 410. This step can be implemented by feeding the provided delivery address information to commercially available, standardized databases and software packages such as MAPINFO. The system then determines whether latitude and longitude coordinates were located for the specified delivery address, step 420. If an exact determination of the customer's longitude and latitude (“cLat/cLon”) cannot be made, the system will process the customer supplied address to normalize the address, step 424 and return again to step 410 to determine whether latitude and longitude coordinates can be located, this time for the normalized address. Specifically, step 424 comprises the step of processing the customer supplied address using a United States Postal Service certified CASS program to normalize the address. If it is determined that the process resulted in a modified address indicating that normalization was accomplished, step 426, the normalized address is again processed using commercially available software to assign a latitude and longitude coordinate, step 410. If the address was not modified, the geopointing match for that address/store is marked as unsuccessful, step 430. Prior to performing step 424 it is determined whether a CASS normalization had previously been attempted, step 422, so as to not repeat the process in a never ending loop. If previously attempted, the geopointing match for that address/store is marked as unsuccessful, step 430.

[0048] If cLat/cLon is determined, the system attempts to retrieve previously stored geographic data describing each store's service area from a LATLON database file, step 440, and determined whether that attempted retrieval is successful, step 450. A typical LATLON database file defining the service area of a store is shown by FIGS. 8a and 8b. The data shown in FIGS. 8a and 8b is shown as an ANSI standard M data file (formerly a MUMPS file). The data shown in FIG. 8c corresponds to the type of data contained in FIGS. 8a and 8b but formatted to be more easily read. A typical map illustrating the service area of a business is shown in FIG. 11 whereby the vertices thereof describe the polygon and define the perimeter of the service area. As can be seen from FIG. 11 a very detailed and specific service area can be defined with great precision by use of a virtually unlimited number of vertices or points. Unlike the prior art, there are no portions of pre-defined grids or areas which describe a geographic area that are outside the area actually serviced by the business.

[0049] If predetermined geopoint data is not found for a particular store, the geopointing match for that address/store association is marked as unsuccessful, step 430. If geographic data is found for that store, the system then begins its determination of whether cLat/cLon lies within the polygonal service area defined by the store's LATLON database record.

[0050] In the embodiment illustrated, three successive processes are used to determine if the customer's exact location (cLat/cLon) is located within the store's service area boundaries. The first two processes cannot positively determine if cLat/cLon is located within the store's boundary, but rather provide positive indications if cLat/cLon is outside the store's service area boundary. These processes are used because they can provide a fast and efficient rejection of delivery addresses that are completely outside of a store's service area, thus providing faster system response and reducing processing overhead for addresses that are not serviced by a particular store.

[0051] The predetermined geographic data retrieved for a given store from the LATLON database includes the following datasets: a) latitude and longitude points defining a rectangle that encompasses ALL vertices of a store's polygonal delivery area boundary, b) latitude and longitude points defining the convex hull polygon that encompasses ALL vertices of a store's polygonal delivery area boundary, and c) latitude and longitude points comprising vertices of the store's actual service area boundary.

[0052] The first comparison process, step 460, compares cLat/cLon to the latitude and longitude points defining the encompassing rectangle. In step 470 of FIG. 6, a determination is made as to whether cLat/cLon lies within the range defined by the rectangle. If cLat/cLon is not within the rectangle, then cLat/cLon cannot be within the store's service area boundary, and the store is marked as not servicing the customer delivery location, step 480.

[0053] If cLat/cLon is within the bounding rectangle, the system next retrieves the bottom-most latitude and longitude coordinate in the convex hull (“sLat/sLon”), step 490, and compares sLat/sLon to cLat/cLon, step 500. A convex hull is a geometric set of points that encompasses a set of interior points. If cLat/cLon is exactly equal to sLat/sLon, then the customer is located at a vertex of the store service area boundary, and the customer is within the convex hull of the store service area (step 570), and therefore may be within that store's service area. If cLat/cLon is not equal to sLat/sLon, the angle θ to cLat/cLon from horizontal with sLat/sLon determining the base (0,0) coordinate is calculated in step 510. Angle θ is calculated as follows:

[0054] Angle (θ) between cLat/cLon and sLat/sLon (in radians):
If cLon=sLon,cLat>sLat,θ=π/2
If cLon=sLon,cLat<sLat,θ=π/2
If cLon>sLon,θ=π−ATAN((cLon−cLat)/(sLon−sLat))
If cLon<sLon,θ=−1*ATAN((cLon−cLat)/(sLon−sLat))

• • [0055] (where ATAN=the arctan or inverse tangent function)

[0056] The LATLON database geographic data for the store's convex hull is then referenced to see if any convex hull vertex coordinates (“vLat/vLon”) form an angle to sLat/sLon that is equal to θ, step 520. The angle value for each vertex is precalculated and stored at the time the store's LATLON convex hull database is generated, thus reducing the processing required during the geopoint lookup procedure. If an exact angle match is found, then the distance between sLat/sLon and cLat/cLon is compared to the distance between sLat/sLon and vLat/vLon, step 560. Because the distance between points (x1, y1) and (x2, y2) is calculated as SQRT((x1−x2)^2+(y1−y2)^2), processing time can be further reduced by making the distance comparison between distances squared so as to avoid additional square root calculations.

[0057] In addition, the distance squared value from sLat/sLon to vLat/vLon for each vertex point in the convex hull is precalculated and stored at the time the store's convex hull database is generated. If the distance (or distance squared) from cLat/cLon to sLat/sLon is equal or less than the distance from vLat/vLon to sLat/sLon, then cLat/cLon is within the convex hull for the store boundary, step 570. If the distance (or distance squared) from cLat/cLon to sLat/sLon is not less than the distance from vLat/vLon to sLat/sLon, then cLat/cLon lies outside of the service area convex hull, and the customer is not within the store's service area, step 480.

[0058] If an exact angle match is not found in step 520, then the system next retrieves the convex hull vertices immediately clockwise (“cwLat/cwLon”) and counterclockwise (“ccLat/ccLon”) from cLat/cLon, step 530. The segment joining cwLat/cwLon and ccLat/ccLon defines the nearest edge boundary to the convex hull for cLat/cLon. A calculation is then performed to determine if cLat/cLon lies within the convex hull by determining on which side of the segment cLat/cLon lies, step 540. The determination is made by implementation of the following calculation:
SIDE=(cLon*(cwLat−ccLat))−(cLat*(cwLon−ccLon))+((cwLon*ccLat)−(ccLon*cwLat))
If SIDE=0 then cLat/cLon is collinear with ccLat/ccLon−cwLat/cwLon segment
<0 then cLat/cLon is “below” segment
>0 then cLat/cLon is “above” segment
If cLat/cLon is determined to be below the segment (i.e. SIDE <0), then cLat/cLon is outside of the store's service area, step 480.

[0059] If cLat/cLon is determined to be on or above the segment in step 550 (i.e. SIDE is ≧0), it is within the convex hull of the points defining the store boundary, step 570. The system then proceeds to determine if cLat/cLon is within the actual polygon that defines the store boundary via the process illustrated in FIG. 7. This is done by first extending a ray straight north (90 degrees or π/2 radians), and counting the number of times that ray crosses a segment defining the store boundary, step 600. The system then determines whether the ray crosses boundary segments an even number of times, step 610. According to a fundamental principle of geometry, if the number of segment crossings is even, the point (cLat/cLon) is not located within the polygon (store service area boundary), meaning the customer delivery address is outside of the store delivery area, step 650.

[0060] If the number of boundary segment crossings is odd for the northerly ray, the system proceeds to check rays extending in each of the other principle directions (east, south, and west, or 0, 270, and 180 degrees, or 0, −π/2, and π radians) in step 620. In step 630, the system determines if any ray crosses boundary segments an even number of times. If the number of line crossings is even for any ray, the delivery location point does not lie within the service area polygon, step 650, and the subsequent directions do not need to be checked. If, after all directions are checked, there are no even number of crossings in any direction, then the cLat/cLon lies within the store service area boundary, step 640.

[0061] Upon completion of geopoint lookup procedure 400, the system determines whether a store match was found for the customer's delivery location in step 360 of FIG. 3. If the geopoint lookup was successful, the store is added to the list of available stores, step 315.

[0062] If the geopoint lookup procedure did not match the customer's address to a store (either because the customer address could not be assigned a lat/lon value, the store's geographic information data is not available, or the cLat/cLon value did not lie within the store's boundary), the system next performs an alternative address lookup 700, illustrated in FIG. 7. Alternative address lookup 700 uses two procedures to try to determine possible alternate serviceable addresses. An alternate address is one which is known to be serviceable by the system (i.e. it has one or more stores associated with it), but cannot be automatically matched to the address the customer entered.

[0063] The first step 710 is to progressively remove the end portion of the user's address until one or more partial matches can be found in the store's STREET database. Step 720 determines whether possible matches to the partial street name were found. For example, if the user entered “MAIN ST” and no exact match was found in the STREET database, the system would then shorten the input to “MAIN”. In this case there might be a “MAIN PL” and a “MAIN AVE”, and these would then be possible alternate addresses. If there are one or more possible alternate addresses, the list is presented on-screen to the user for manual selection in step 730. If the user then chooses to select one of the addresses as the desired delivery address, step 770, then the store that is known to service that address is added to the list of available stores, step 315. It is also contemplated that the store street map database may include one or more vanity addresses which service to minimize the number of unnecessary notices of unavailability sent to users.

[0064] If no alternate addresses are found by partial street matching, the system then accesses a customer database that is cross-indexed by phone number in step 740. Such customer databases are commonly maintained by store POS systems known in the art. If there is an exact match of the phone number that the user entered and a phone number in the customer database in step 750, then the address associated with that phone number in the customer database is presented as a possible alternate address for the user, step 760. The system again determines whether the user has selected a possible alternative address, step 770, and reacts accordingly.

[0065] If no possible alternate addresses are located, or the user declines to choose any alternate addresses presented to them, the system next checks how many times the user has attempted to register during their current session, step 780. If the user has attempted to register less than three times, the system prompts for them to try modifying their address and resubmitting it, step 785, in hopes that they will enter in an address more compatible with the registration process and incorporated databases. However, if the user has attempted at least three times to register, the system presents them with a different message informing them that they are unable to be registered automatically and that their address information will be submitted to the QuikOrder development staff for review and/or manual assignment to a store servicing their area if one is available, step 790.

[0066] Once each potential store has been tested to determine whether the customer's exact delivery location matches its service area, the system determines whether at least one match was found in step 280. If the delivery location does not match the service area of any store in the system, the user is informed that service is not available for their area, step 240.

[0067] If at least one match is found, then one matching store is assigned to the user for any orders placed thereafter, step 290, FIG. 3. When more than one store matches, the assignment may be made in a number of ways. For example, the store assigned may be randomly selected. The system may assign the first store determined to be matching. The system may also prioritize stores that pay a service premium. The system may select the store that is physically closest to the delivery location. As another option, the user may be presented with the option to manually select their preferred store. Once a store is assigned, the user proceeds to an order entry page, step 297.

[0068] An order entry process is illustrated by FIG. 10. In step 810, the active/inactive status of online ordering, hours of operation, and holiday status information is retrieved from the database for the customer's assigned store. Step 820 determines whether the assigned store is currently available for ordering. If the store is not available to receive an order, the customer is notified that the store is closed and provided with store operating schedule information, step 830.

[0069] If the assigned store is open, the system retrieves product menu, pricing and other related ordering information for the specific assigned store, step 840. The system then displays a dynamically generated order entry screen based upon the store-specific information, step 850. The user interactively enters the desired order information, step 860, and the completed order is submitted for electronic transmission to the assigned store in step 870. The system next determines whether transmission of the order was successful in step 880. If so, then the system sends a status email to the customer that includes the estimated delivery time from the assigned store's POS system, if such information is available. If the order is placed for takeout, the message includes the estimated time at which the order will be ready for pickup. If order transmission fails, the system responds accordingly in step 895. For example, the system may send an email to the customer, explaining that the order has failed and that the assigned store should by called directly for telephone placement of the order. Additionally, the system may page support technicians. The support technicians may contact the store, forward the order information manually, and/or attempt to help the store resolve its order reception problems.

[0070] The foregoing description and drawings merely explain and illustrate the invention and the invention is not limited thereto except insofar as the appended claims are so limited, inasmuch as those skilled in the art, having the present disclosure before them will be able to make modifications and variations therein without departing from the scope of the invention.