Source: https://patents.google.com/patent/US20020007321A1/en
Timestamp: 2019-04-18 14:55:00+00:00

Document:
2001-07-06 Assigned to AMERICA TO GO LLC reassignment AMERICA TO GO LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BURTON, PETER A.
Systems and methods for ordering supplies from suppliers or for other e-commerce activities are described. Standards for placing orders and registering catalog information in a database are described. Systems and methods for placing orders, preprocessing supplier information using geographic information, conducting data searches and analyses locally on user access devices, continuously updating displays of browser frames, tracking orders using accounting codes, placing graphical custom orders, submitting graphical orders to suppliers, placing group orders, reducing risks associated with delinquent accounts receivable, and combinations thereof are described.
This application claims the benefit of U.S. Provisional Patent Application No. 60/191,359, filed Mar. 22, 2000; U.S. Provisional Patent Application No. 60/191,205, filed Mar. 22, 2000; U.S. Provisional Patent Application No. 60/245,503, filed Nov. 3, 2000; U.S. Provisional Patent Application No. 60/245,826, filed Nov. 3, 2000; and [P. A. Burton] U.S. provisional application entitled SYSTEMS AND METHODS FOR USING CODES TO IDENTIFY OR GROUP ORDERS, filed Jan. 2, 2001, Attorney Docket No. ATG-6 PROV2.
Some embodiments may receive from a user an order that includes payment information corresponding to a given payment method (e.g., credit card, cash, house account, etc.). If payment by credit card is indicated, a supplier's claim for payment from the user's financial institution may be trapped instead of forwarding it to the supplier. The trapped claim may be presented directly to the financial institution and corresponding funds may be received. An amount corresponding to the sale reduced by any commission, any receivable funds from other orders purchased (for example, using non-trappable payment methods), or any associated service charges may be remitted to the supplier. Systems and methods for defraying costs due to financial institution service charges may be provided.
FIG. 18 a is a generalized flowchart of steps involved in providing data and functionality to a user in accordance with some embodiments of the present invention.
FIGS. 21, 22, and  23 show illustrative examples of relationships between zones and supplier delivery areas in accordance with some embodiments of the present invention.
FIG. 43, 44, and  45 show illustrative displays that may be used to display information about suppliers, display a list of suppliers, and/or allow the system to receive user indications of preferred suppliers in accordance with some embodiments of the present invention.
FIGS. 46, 47,  48, and 50 show illustrative displays that may be used to display catalog information, display a list of suppliers, allow the system to receive user indications of preferred suppliers, and/or allow the system to receive user indications of desired products in accordance with some embodiments of the present invention.
FIGS. 49, 51,  52, and 53 show illustrative displays that may be used to display catalog information, display desired products, allow the system to receive user indications of desired products, and allow the system to receive indications of a desire to complete an order in accordance with some embodiments of the present invention.
FIGS. 54, 55,  56, 57, 58, 59, 60, 61, 62, and 63 show illustrative displays that may be used to display order information, display choices of order options, and allow the system to receive indications of a desire to change ordering options in accordance with some embodiments of the present invention.
FIGS. 71, 72,  73 and 74 show an illustrative displays that may be used to allow the system to receive indications regarding suppliers to be added to the system in accordance with some embodiments of the present invention.
FIGS. 81, 82,  83, and 84 show illustrative displays that may be used to display customer service data and allow the system to receive indications regarding customer service activity in accordance with some embodiments of the present invention.
FIGS. 104, 105 and  106 show illustrative displays that may be used to allow the system to receive indications regarding changes to administrative user data in accordance with some embodiments of the present invention.
FIGS. 107, 108, and  109 show illustrative displays that may be used to display past order data and allow the system to receive indications regarding which past orders to display data about in accordance with some embodiments of the present invention.
In the illustrative on-line arrangement of FIG. 1 access devices  102 may be connected via links 103 to Internet 100. Access devices 102 may include any device or combination of devices suitable for providing Internet access to a user of the system. Access devices may include, for example, any suitable personal computer (PC), portable computer (e.g., a notebook computer), palmtop computer, handheld personal computer (H/PC), automobile PC, personal digital assistant (PDA), Internet-enabled cellular phone, combined cellular phone and PDA, ebook, set-top box (e.g., a Web TV enabled set-top box), or other device suitable for providing Internet access.
Internet and application server  104 may be any server suitable for providing on-line access to an e-commerce web site. Internet and application server 104 may, for example, provide one or more pages to access devices 102 using one or more suitable protocols (e.g., the HyperText Transfer Protocol (HTTP) and Transmission Control Protocol/Internet Protocol (TCP/IP)). The pages may be defined using, for example, any suitable markup language (e.g., HyperText Markup Language (HTML), Dynamic HyperText Markup Language (DHTML), pages defined using the Extensible Markup Language (XML), JavaServer Pages (JSP), Active Server Pages (ASP), or any other suitable approaches). The pages may include scripts, computer code, or subsets of computer code, that define mini-programs (e.g., Perl scripts, Java applets, Enterprise JavaBeans (EJB), or any other suitable approaches). The system may be designed using suitable modular approaches such as, for example, Java 2 Platform—Enterprise Edition (J2EE), Component Object Model (COM), Distributed Component Object Model (DCOM), or any other suitable approach.
Internet and application server  104 may run a database engine suitable for maintaining a database of user, order, supplier, or catalog information such as, for example, Microsoft SQL Server, Oracle 8i, or any other suitable database engine. Internet and application server 104 may run Microsoft Internet Information Server. In practice, features of Internet and application server 104 may be integrated into a single server, or may be distributed across multiple servers that are interconnected via Internet 100.
Links  103 may include any transmission medium suitable for providing Internet access to access devices 102. Links 103 may include, for example, a dial-up telephone line, a computer network or Internet link, an infrared link, a radio frequency link, a satellite link, a digital subscriber line link (e.g., a DSL link), a cable TV link, a DOCSIS link, or any other suitable transmission link or suitable combination of such links. Different links 103 may be of different types depending on, for example, the particular type of access devices 102.
Any protocol or protocol stack suitable for supporting communications between access devices  102 and Internet and application server 104 over links 103 based on the particular device 102 and link 103 may be used. For example, Ethernet, Token Group, Fiber Distributed Data Interface (FDDI), Circuit-Switched Cellular (CSC), Cellular Digital Packet Data (CDPD), RAM mobile data, Global System for Mobile communications (GSM), time division multiple access (TDMA), code division multiple access (CDMA), wireless application protocol (WAP), serial line Internet protocol (SLIP), point to point protocol (PPP), Transmission Control Protocol/Internet Protocol (TCP/IP), Sequenced Packet Exchange and Internetwork Packet Exchange (SPX/FPX) protocols, or any other suitable protocol or combination of protocols may be used.
FIG. 2 shows another illustrative arrangement for the e-commerce system of the present invention. Network  110 may be any suitable wire-based, fiber-based, or wireless local area network (LAN), wide area network (WAN), intranet, or other suitable network. Personal computers, and their interconnection via networks, are well known. Personal computers 112 may run suitable e-mail, HTTP, or other clients and client applications for providing users with access to the features of the system. In still another suitable approach, personal computers 112 may run suitable Internet browsers to provide users with access to the Internet via an Internet server (not shown). If desired, one or more personal computers 112 may be accessed by remote access device 113 to provide remote access to users to the system. Remote access device 130 may be any suitable device, such as a personal computer, personal digital assistant, cellular phone, or other device with remote access capabilities.
Database server  105 of FIGS. 1 and 2 may be any computer-based system suitable for maintaining a database of user, order, supplier, or catalog information. In particular, database server 105 may store attributes of users and suppliers, orders, order-related information, and catalog information. Database server 105 may run a database engine suitable for maintaining a database of item information such as, for example, Microsoft SQL Server, Oracle 8i, or any other suitable database engine. Database server 105 is shown as being connected to server 104 via Internet 100 and server 114 via network 110. In practice, database server 105 may be connected to server 104 or server 114 using a direct communications link. The features of database server 105 may be provided using a single server, distributed across multiple servers, or integrated into server 104 or server 114.
FIG. 3 shows an illustrative, generalized arrangement for the access devices  102 of FIG. 1. Access devices 102 may have, for example, user input device 124, processing circuitry 126, communications device 128, storage 129, and display device 122. User input device 124 may be any suitable input device. User input device 124 may include, for example, a pointing device, keyboard, touch-pad, touch screen, pen stylus, voice recognition system, mouse, trackball, or any other suitable user input device. Processing circuitry 126 may include any suitable processor, such an Intel Pentium® microprocessor, and other suitable circuitry (e.g., input/output (I/O) circuitry, direct memory access (DMA) circuitry, etc.). Communications device 128 may be any device suitable for supporting communications over links 103. Communications device 128 may include, for example, a modem (e.g., any suitable analog or digital standard, cable, or cellular modem), network interface card (e.g., an Ethernet card, token group card, etc.), wireless transceiver (e.g., an infrared, radio, or other suitable analog or digital transceiver), or other suitable communications device. Storage 129 may be any suitable memory, storage device, or combination thereof, such as RAM, ROM, flash memory, a hard disk drive, etc. Display device 122 may include, for example, a cathode ray tube (CRT) monitor, liquid crystal display (LCD), voice synthesis processor and speaker, or any other suitable user output device. Users, suppliers, and any ordering system personnel may interact with system 101 using an access device such as access devices 102 or a personal computer such as personal computer 112.
FIG. 4 shows a general flowchart of illustrative steps involved in operating some embodiments of the e-commerce system of the present invention. The steps shown in FIG. 4 are only illustrative and may be performed in any suitable order. In practice, there may be additional steps or some of the steps may be deleted. Some of the steps shown in FIG. 4 involve providing users with opportunities to interact with the system, performing various processes, or providing various displays. These and other steps may be performed by, for example, a client application that is programmed to generate or download screens suitable to provide such opportunities, an Internet browser that downloads suitable pages to provide such opportunities, peer applications, or using any other suitable approach. In an on-line arrangement, access device  102, for example, may be used to run client-based applications, such as a web browser. In non-on-line arrangements, personal computer 112, for example, may run client-based applications.
Other steps illustrated in FIG. 4 may involve additional processing, such as searching, grouping, calculating, generating e-mail, receiving and assembling order information, ordering, communicating with other systems, or other types of processing. In on-line arrangements (as shown in FIG. 1), such processing may be performed by, for example, access device  102, Internet and application server 104, or database server 105, depending on, for example, the processing and storage capabilities of access device 102, the chosen implementation for the markup language documents used, the processing requirements of such operations, or other factors. In non-on-line arrangements (as shown in FIG. 2), such processing may be performed by personal computer 112, remote access device 113, application server 140, database server 105, or distributed among peer applications, depending on the chosen system implementation and the processing requirements of such operations.
For clarity, the following discussion will describe the steps shown in FIG. 4 as being performed by “the system,” which is intended to include any suitable e-commerce system, such as, for example, any non-on-line or on-line arrangement suitable for performing the steps. The system may receive orders from internal ordering sites or external ordering sites. Internal sites may be maintained by the system using Internet and application server  104 or application server 114 (as shown in FIGS. 1 and 2, respectively). External sites may be maintained independently from the system, but may submit orders that comply with standards determined by the system.
When a user places an order using an internal ordering site, the system may provide an initial display for at step  130. The initial display, and any subsequent displays, may correspond to any preselected themes, preferences, or requirements associated with the ordering site. Themes, preferences, or requirements may be determined by the system or by a group of users. The initial display may provide users with opportunities to log in (step 132), or may provide users with access to other system features. In some embodiments, users may be required to log in by, for example, entering a user name and a password. In other embodiments, users may not be required to log in to access the features of the system.
In step  134, the system may initialize the user's access device by loading portions of a distributed database engine into the access device browser, for example. The distributed database engine includes, in part, a presentation engine for driving a graphical user interface (sometimes referred to hereinafter as “GUI”) and a translation engine for decompressing data that are to be received from the system.
In step  140, the system may receive an indication of the user's location. The location is a geographic place where the user is located or where the user desires to receive or receive delivery of ordered supplies. The system may provide the user with a list of suppliers that are close to the user's location for convenience, economy, or any other reason.
In step  142, the system may choose a list to provide to the user. The list may include suppliers that correspond to preselected preferences associated with the ordering site through which the user entered the system (145). Alternatively, the system may provide the user with a list that corresponds to the user's location. If the system may provide a list known from prior transactions to correspond to the user's location (archived location list 144), or it may use a geozoning engine (146) to map the user's location into geographic coordinates and retrieve or generate a list of suppliers corresponding to those coordinates.
In steps  148 and 150, the user may select a supplier and the system may receive an indication of the selection. In step 152, the system may provide a catalog from the selected supplier to the user. In step 154, the system may receive an indication that the user desires to place a group order. If so, the user is referred to as a host user and the system may generate, distribute, and manage invitations to other users (hereinafter, “invitees”) to gather order information from the members of a group. Group orders may be processed using e-mail engine 158 for distributing invitations, group order holding bin 160 for receiving and holding orders from members of the group, and group order status engine 162 for monitoring the status of orders and invitations and providing status information to the host user. If no group order is requested, step 156 may be skipped.
In step  164, the system may receive order information from the user. (In the case of a group order, the system may already have ordering information, for example, in group ordering bin 160). When the system receives order information, it may receive accounting codes 165 for accounting and reporting purposes. Accounting codes may be especially useful if the user is a member of a group that monitors ordering activity of its member users. Graphical custom order 163 may provide methods of receiving order information in step 164 that involve manipulating graphical representations of items and customized features on a user's display, such as display device 122.
In step  168, the system may receive orders from ordering sites external to the system provided that the site is approved for ordering from the system and that the order complies with an open catalog standard (hereinafter, “OCS”) that may be defined and distributed by the system. Internal orders may be stored in a database in step 170. When the system is compensated by suppliers in the form of a commission in connection with a sale of supplies to a user, the system may selectively trap credit card claims using credit card pricing logic (step 172). Trapped credit card claims may be submitted to the user's financial institution. When the financial institution remits funds to the system, the system can transfer the funds, less commission due, to the supplier.
In step  176 order information may be output. Order information may be output to a supplier by any communications device or link, including e-mail, fax, phone, or mail (180). Order information may be output to authorized users, including administrative users of a user group, in the form of reports that may be generated in connection with accounting codes or user attributes (182). Push engine 178 may be used to provide a continuous display of order information at various stages of the ordering process to authorized users (e.g., customer service representatives). For example, different authorized users of push engine 178 may have permission to view orders in different stages of the process or orders from different users or user groups.
When the source of an order is an OCS-compliant external site, orders may be stored in an order information database (step  184) as in the case of orders from internal sites. OCS-compliant external orders may be output in step 176 in a manner similar to the output of internal orders. In some embodiments, OCS-compliant sites may not need credit card pricing logic (172) since suppliers may have financial arrangements with the OCS-compliant external sites that are independent of the system. In some embodiments, step 172 may follow step 184.
FIG. 5 shows illustrative ordering system  1 in accordance with some embodiments of the present invention. Ordering system 1, including server module 7 may be driven by any of the apparatus illustrated in FIGS. 1 and 2. In particular, in some on-line embodiments, for file serving, searching, storing, grouping, calculating, and other necessary function of system 1 or server module 7 may be provided by Internet and application server 104, database server 105, or a combination thereof. User 10 and suppliers 40 may interact with ordering system 1 using access devices, such as devices shown in FIGS. 1 and 2. Ordering system 1 may receive orders for items, merchandise, or services (hereinafter, “supplies”) from users 10 through order sites, such as order site 20. Order sites may have order engines (hereinafter, “order modules”) that may present supplier information, catalog information, and order-related content to users and receive user selections regarding the presented information, assemble orders, and transmit orders and related information to order server 30. Order server 30 may pass order information to suppliers 40. Suppliers 40 may provide catalog information to system 1. Order information may be passed through secure internal interface 18 to administration engine 50 and accounting engine 60.
Some order sites may provide users with order-related content. The order-related content for a given site may be keyed to cuisine, location, business promotion, or any other theme or interest. Order site may require that users have permission to order from the sites. For example, public site  20 may be open to users 10 from the general public. Order module 21 in order site 20 may receive order information from users 10 and transmit order information to order server 30. Public sites may be provided by a service provider to facilitate or promote the sale services or products provided by a given supplier or family of suppliers or for any other reason.
Groups of users that have common interests, business, or accounting requirements may be given common permissions to order from a group order site. For example, order site  22, provided with order module 23 is a group site for Group Y of users 10. Site 22 may be restricted to use only by users 10 who are members of Group Y. Site 22 is an unadministered group site, because Group Y does not include an administrative user. Unadministered group sites may be suitable for organizations such as colleges and universities, clubs, associations, unions, companies, or interest groups that may benefit from consolidating orders and gaining access to preselected suppliers.
Order site  24 may be an administrated site for Group X of users 10. Order module 25 may provide special content and ordering features to members of Group X. Group X may include one or more administrative users, such as administrative user 11. Administrative user 11 may have permission to access administration module 27 of site 24. Administration module 27 may be used to add, delete, or edit content or features provided by order module 25.
Administrative user  11 may use administrative module 27 to add, delete, edit, and manage user information for Group X users and general Group X information that may be stored by administration engine 50. User information may include identification, permission, location information, and any other information relating to Group X users. Group X information may include supplier selections, accounting codes, house account information, billing information, and any other information related to customized use of system 1 by Group X users.
Accounting engine  60 may receive order information from order server 30 in connection with orders placed by members of Group X. For example, administrative user 11 may generate reports detailing orders (including, e.g., items ordered, order costs, and billing particulars) placed by a given user or user subgroup. Administrative user 11 may use accounting engine 60 to receive and analyze order information. An administered site, such as site 24, may be used by companies, firms, divisions, departments, partnerships, associations, agencies, subsidiaries, or any other organization or sub-organizational unit or entity.
Suppliers  40 may be organized into families such as Family A and Family B for convenience or economy. Suppliers 40 that are members of Family A, for example, may share common catalog information. For example, one joint catalog may be registered in file server 80 while more than one of users 40 in Family A may be capable of fulfilling an order from the joint catalog. A user 10 placing an order from system 1 for an item in a Family A catalog may therefore be able to receive delivery of merchandise from any supplier in Family A. The determination of which supplier 40 within Family A actually fulfills the order may be made based on proximity, inventory, or the preference of user 10.
In this example, Family A further includes administrative supplier  42. Administrative supplier 42 may be an individual or group of individuals appointed to provide catalog information to system 1 and manage orders received from system 1. System 1 may provide administrative supplier 42 with tools for submitting Family A catalog information to file server 80, editing or managing Family A catalog information in file server 80, or implementing rules that determine which of suppliers 40 in Family A may fulfill a given order from a user 10. An administered family, such as Family A, may be used by companies, firms, divisions, departments, partnerships, associations, agencies, subsidiaries, or any other organizations or sub-organizational units or entities that may benefit from the ability to manage one or more joint catalogs or from access to family information from accounting engine 60.
Family B is an example of an unadministered supplier family. Unadministered supplier families may be used by companies, firms, divisions, departments, partnerships, associations, agencies, subsidiaries, or any other organizations or sub-organizational unit or entities that may benefit from the convenience or economy of sharing a common catalog, but for whom the functions of an administrative supplier  42 are unnecessary.
Some embodiments of the invention may transfer catalog information, order information, or other suitable transaction information between end users (e.g., consumers) and remote computers (e.g., suppliers) using standard data formats. In some of these embodiments, an open standard, such as an Open Catalog Standard (“OCS”), is generally represented in steps  166, 168, and 176 of FIG. 4. In accordance with embodiments of the invention having OCS features, an ordering service may provide standard data formats for receiving orders for supplies, submitting orders to suppliers, receiving catalog information from suppliers, and transmitting catalog information to users.
FIG. 6 shows illustrative server module  607 integrated into ordering system 601 with secure interfaces 614 and 616. Server module 607 may transfer order information from ordering web sites such as sites 620, 622, and 624 to suppliers 640 in a manner generally similar to that of server module 7 shown in FIG. 5. Ordering web sites 620, 622, and 624 may be internal to system 601. Users 610 and administrative users, such as user 611, may have the benefits of administrative engine 650 and accounting engine 660, which are analogous to administration engine 50 and accounting engine 60 of FIG. 5, as described above.
The addition of secure interface  614 may enable server module 607 to provide ordering services to external ordering sites, such as external ordering site 670, that are outside of ordering system 601.
Site  676 may receive orders from external users 672, using, for example, external order module 679. Order module 79 may be of any design or architecture, including designs or architectures that differ from those of internal sites, such as sites 620, 622, 624, or any other internal sites that may be included in system 601.
In some embodiments, external site  670 may be provided with permission, protocols, or standards necessary to submit orders to system 601, for example, along path 676. External users 672 may be identifiable or completely anonymous to system 601. System 601 may treat orders received from users 672 as if they originate at ordering site 670 (although suppliers 640 may ship, deliver, or otherwise provide services and supplies directly to users 672). Billing procedures, used in connection with internal sites, including credit card pricing methods (discussed below), may be used in connection with receipt of OCS orders from external sites (not shown in FIG. 4). Although administrative engine 650 and accounting engine 660 are shown communicating with server module 607, the functions of these engines may be reserved for users 610 ordering through internal sites.
FIG. 7 is an illustrative data-flow diagram showing the use of an OCS-based ordering module and associated elements. FIG. 7 shows that external ordering site  670, which includes external ordering module 679, may be equipped with filter 604 for translating order requests and order-related requests into a form that may be compatible with the requirements of order server 630. Filter 604 may include an application programming interface and OCS requirements or explanations of OCS requirements. For example order server 630 may require that external orders use HTTP-based protocols (e.g., HTTP or S-HTTP), be coded using a suitable markup language (e.g., SGML or DHTML, or defined in accordance with a meta language, such as XML), or structure order requests according to any OCS format determined and controlled by a service provider in connection with server module 607.
Supplier  640 may be provided with filter 608 that supplier 640 can use to translate OCS order information into a format compatible with information system 609 of supplier 640. Filter 608 may include an application programming interface and OCS requirements or explanations of OCS requirements. Filter 608 may translate catalog information from the format of information system 609 to OCS catalog information for uploading to file server 680.
External ordering site  670 may request catalog information from server module 607 and receive OCS catalog information from file server 680. Filter 604 may translate OCS catalog information into a catalog information format used by server module 679.
Secure interface  614 may accept only OCS order requests accompanied by an encrypted key. Secure interface 614 may require that the encrypted key be received from an approved external ordering site.
Some embodiments of the present invention may include a distributed database engine (hereinafter, referred to as “DDBE”). In some of the embodiments, this feature is generally represented in steps  134, 148, and 182 of FIG. 4. The DDBE may distribute searching, sorting, grouping, translation, or other processes from a centralized database or database server to a user access device. Some embodiments of the DDBE are described in U.S. Provisional Patent Application No. 60/245,503, filed Nov. 3, 2000, which is hereby incorporated herein in its entirety.
Features of some embodiments of the DDBE involve providing users with opportunities to interact with the system, performing various processes, or providing various displays. These and other steps may be performed by, for example, a client application that is programmed to generate or download screens suitable to provide such opportunities, an Internet browser that downloads suitable pages to provide such opportunities, peer applications, or using any other suitable approach. In an on-line arrangement, access device  102 (as shown in FIG. 1), for example, may be used to run client-based applications. In non-on-line arrangements, personal computer 112 (as shown in FIG. 2), for example, may be used to run client-based applications.
Other features of the DDBE may involve additional processing, such as searching, sorting, grouping, calculating, exchanging information and processing code, or other types of processing. In on-line arrangements (as shown in FIG. 1), such processing may be performed by access device  102, Internet and application server 104, or database server 105, depending on, for example, the processing and storage capabilities of access device 102, the chosen implementation for the markup language documents used, the processing requirements of such operations, or other factors. In non-on-line arrangements (as shown in FIG. 2), such processing may be performed by personal computer 112, remote access device 113, application server 140, database server 105, or distributed among peer applications, depending on the chosen system implementation and the processing requirements of such operations.
FIG. 8 illustrates multiple layers of processes that code may be loaded into browser  236 or another client application of user access device 221. The code for these layers may be downloaded from a server to browser 236. Translation layer 201 may be loaded for data compression and decompression. Object layer 202 may be loaded in browser 236 to store data objects or other data structures that correspond to data resident in database server 105 of FIG. 1.
Presentation layer  204 may be loaded to present data to a user and receive selections and instructions from a user. Data processing layer 203 may be loaded to provide, for example: (a) search functions that extract data from the object layer and route data to the presentation layer; and (b) analysis functions that receive presentation layer instructions for analyzing object layer objects or search results. It will be appreciated that additional layers of code may be loaded into an access device browser as necessary.
FIG. 9 shows an example of back end process layering. Compression and decompression may be carried out in translation layer  206, which may correspond to Internet and application server 104 (shown in FIG. 1). FIG. 9 also shows object layer 207, which may be resident in Internet and application server 104 (shown in FIG. 1). Object layer 207 may include data objects that correspond to data that may be included in database layer 208, which may reside in database engine 105 (shown in FIG. 1).
FIG. 10 shows a generalized example of restaurant information record fields that may include fields  212. Fields 212 may include searchable fields 214, which may be none, some, or all of fields of 212. A user may use fields 214 to search among data objects in a browser. Fields 214 may be fields that are chosen by a provider of the ordering system and made available to users. Fields 212 may be presented to the user in the form of summary information that may be viewed by a user after a search is performed.
In some embodiments of the invention, data may be stored, compressed, or downloaded to a user's browser in binary format. In some embodiments of the invention, data may be stored, compressed, or downloaded to a user's browser in text format. FIG. 11 shows an illustrative example of data record  216 in a compressed text format. Record 216 may correspond to an individual restaurant and may include reference number 218, restaurant name 220, restaurant street address 222, cuisine identifier 224, restaurant attributes 226, hours of operation information 228, field delimiter 219, and record delimiters 230. As shown in FIG. 11, fields such as reference number 218, cuisine identifier 224, restaurant attributes 226, and hours of operation 228 may be stored (and transmitted) in base 62 digits. Record 216 may include variable width fields (e.g., restaurant name) and fixed width fields (e.g., a fixed number of characters indicating cuisine). Variable width fields (VWFs) may be delimited by field delimiters such as field delimiters 219. Fixed width fields (FWFs) may be grouped logically together to avoid the need for delimiters between those fields.
When a field includes multiple attributes, the multiple attributes may be represented using bit masks. For example, a field containing restaurant services information may need to include more than one service. Accordingly, each service may be assigned a digit in a binary structure. To represent multiple services simultaneously, the sum of the digits corresponding to each of the included services may be included in the restaurant services field. For example, if eat-in=1, take-out=2, delivery=4, and on-line ordering=8, then (eat-in and take-out and on-line ordering)=11. For example, restaurant attributes field  226 may include 4 base-62 digits. The first may represent services offered, the second may represent average meal price, and the third and fourth may represent attributes such as non-smoking, romantic, or kosher.
where D i is the ith digit in a base-62 number of length I, and A(Di) gives the base-10 value of the position of Di in the 62 element array. The same method may be used to convert from any base-N, where N is an arbitrary integer.
Hours of operation information  228 may include hours of operation of a restaurant for each day of the week and may be further optimized. Each day of the week may be viewed separately by a user, but days whose hours match the hours of other days may be grouped together. For example, hours of operation field 228 (also referred to as a “TimeDef”) may contain information such as “M,W,F 10:30 a.m. to 8:00 p.m. The restaurant hours information may then be represented with a bit mask (e.g., 1=Sunday, 2=Monday, 4=Tuesday, etc.). Bit masks of days having like hours may be summed and converted to base-62. Using the present invention, most groups of days having like hours can be represented using one character (and may never require more than two).
FIG. 12 shows browser  420 when user 410 initially logs onto an ordering system, such as system 1 (as shown in FIG. 5). Browser 420 may initially include empty frame 421. At login, a request may be sent by user 410 to request generator 402 of browser 420. Request generator 402, which may be a built-in browser feature, may transmit an unverified request object to request filter 405. Request filter 405 may determine that user 410 has just logged in and that a DDBE should be installed in frame 421. Request filter 405 may then transmit a verified request for installation of a DDBE to server 480. Accordingly, server 480 may then transmit DDBE code 422 to frame 421 in browser 420. As shown in FIG. 12, user 410 may receive HTML, or data in any other suitable format, as necessary for the log-in or ordering processes.
FIG. 13 is an illustrative example of DDBE  435 after it has been installed in frame 421 (as shown in FIG. 12). DDBE 435 may include translation engine 460 for decompressing compressed data from a server; object later 470, which may be populated by data and browser-resident functions decompressed by translation engine 460; data processing engine 440 for searching, sorting, grouping, and otherwise manipulating data objects in object layer 470; and presentation engine 450, for presenting readable text and graphics to user 410 and for receiving data from user 410.
FIG. 14 shows DDBE  435 installed in browser 420. User 410 may select a location to receive delivery of an order. When a location is selected, an unverified request object corresponding to a request for a list of suppliers may be received by request filter 404. Request filter 404 may generate a verified request object that has any formatting or ordering process state variable values that file server may require to return an appropriate list of suppliers to user 410. If user 410 submits a location that is known to server 480, file server 410 may return a list corresponding to the location. If the location is unknown to server 480, a new list may be generated by geozoning engine 490 (as shown in FIG. 15 and discussed in greater detail below). A compressed data file, such as data compressed data file 482 may be transmitted to DDBE 435 for decompression, any desired local analysis, and presentation to user 410.
FIG. 16 is a general illustration of DDBE  435 in a data presentation mode. Compressed data may be received and uncompressed by translation engine 460 and retrieved, as necessary, by presentation engine 450 for presentation to user 410. Data processing engine 440 is shown disconnected from presentation layer 450 and object layer 470, but may be active in the presentation process. For example, data processing engine 440 may provide user 410 with interactive functions for selecting and manipulating data objects. Data processing engine 440 may provide system functions to presentation layer 450 that may be necessary for data presentation.
FIG. 17 is a general illustration of DDBE  435 in a data analysis mode. Data processing engine 440 may retrieve, sort, search, group, or otherwise analyze data objects in object layer 470. The data objects may then be presented to user 410 through presentation engine 450. FIG. 17 also shows that user 410 may provide requests to data processing engine 440 using presentation engine 450.
FIG. 18 is an illustrative example of data flow when DDBE  435 is in a data analysis mode, as shown in FIG. 18. User 410 may submit requests for data analysis or presentation (e.g., a search command) to request filter 404. Request filter 404 may provide DDBE 435 with a request for analysis that is readable by presentation engine 450. No client/host interface is shown in FIG. 18 to emphasize that in at least the data analysis mode, there may be no need to transmit user-generated requests or commands to a remote or central server. Conversely, there may be no need to transfer data or search results from a central server.
In some embodiments of the DDBE, compressed data, (for example, compressed data files or compressed data as shown in FIGS.  14-16) may include, or be packaged together with, functions that are selected or preselected to provide functionality related to the compressed data or a request for the data originating from the user, the user's browser, or the user's access device. For example, compressed data including information about a restaurant and its menu may be packaged together with a function for drawing the menu that differs from a DDBE default menu drawing function that was previously loaded in the browser. This type of function may be used, for example, when all members of a chain of restaurants are required to use a standard menu display.
FIG. 18 a shows a flowchart of illustrative steps involved in implementing some features of the of the DDBE that may include providing a user with data and accompanying specialized functions for modifying DDBE functionality. The steps shown in FIG. 18a are only illustrative and may be performed in any suitable order. In practice, there may be additional steps or some of the steps may be deleted. For clarity, the following discussion will describe the steps shown in FIG. 18a as being performed by “the system,” which is intended to include any suitable e-commerce system, such as, for example, any non-on-line or on-line arrangement suitable for performing the steps.
In step  401, the system may receive catalog data from suppliers and input the catalog data into a database. In step 403, one or more special functions may be identified for providing specialized presentation, analysis, or other special features, or for setting values of structures in a DDBE object layer. If no specialized DDBE functionality is desired, the process may skip to step 408. If specialized DDBE functionality is desired, required specialized DDBE code may be retrieved from a database or input from any other suitable source in step 406. In step 408, the catalog data may be compressed. In step 409, compressed catalog data may be packaged with any special DDBE code for transmission to the DDBE of a user's browser. On receipt of a request for supplier information from a user (step 411), the packaged data and code may be downloaded to the user's browser (step 412). The downloaded code may provide DDBE functionality related, for example, to DDBE processes 413 (data decompression or translation), 414 (data presentation), 415 (data analysis). The downloaded code may also modify the ways processes 413-415 interact with each other (DDBE modification 416).
In some embodiments, the invention may provide systems and methods for selectively replacing content in a display of a web page that is displayed by a user access device. In some of the embodiments, this feature is generally represented in step  178 of FIG. 4. The display may be driven by a browser that presents the web page to a user. The content of the display may be replaced by data from a server in communication with the access device via an electronic communication network.
Push engine  800 may include automatic refresh request generator 802, which may include a built-in automatic refresh function of browser 820. Automatic refresh request generator 802 may generate an unverified request for a frame refresh for hidden frame 804. The unverified request may be passed through request filter 804 to generate a verified request that may include any browser state variables, push engine state variables (which may include current data frame URLs, permission levels for user 810, or any other information necessary to specify the required information or data format), or order server variables that may be necessary for order server 830 to process the request.
Order server  830 may continuously receive updated order information from an order database server (e.g., database server 105 shown in FIG. 1) that provides data from an order database (not shown). The order database may include records from every order received from an ordering system, such as system 1 shown in FIG. 1. Therefore, when order server 830 receives a verified request from push engine 800, order server 830 may fulfill the request by sending current data back to push engine 800.
Translation engine  860 in push engine 800 may receive compressed data from order server 830 and decompress the compressed data into data objects that may fill object layer 870. Presentation engine 850 may selectively replace portions of content 812 with data from object layer 870. This may generate a display that has portions that may appear to be dynamically updated.
In some embodiments, features of push engine  800 may be modified by downloading specialized functions to browser 804 from a server (not shown) that may be linked to order server 830. For example, presentation engine 850, object layer 870, and translation engine 860 may be modified using downloaded functions in accordance with principles of the DDBE described above.
FIG. 81 is an illustrative display that may be created by push engine  800. Content 812 includes fixed content, such as various search mechanisms, and dynamic content, such as attention item 4112 and counter display features 4116. For example, one counter display feature 4116 shows a number of orders received by order database server 105 (shown in FIG. 1) that require the attention of user 810, who may be a customer service representative. As the number of orders requiring attention changes, only the number in one of the counter display features 4116 may be updated using push engine 800. The fixed search mechanisms may remain unchanged and may be displayed continuously.
Some embodiments may select suppliers according to the locations of a user and prospective suppliers. In some of the embodiments, this feature is generally represented in steps  146 of FIG. 4. In some approaches, geographical areas may be divided into regions. A supplier inside or on the border of the region associated with a user's location can be identified and presented to the user. The borders of the region may be selected to exclude suppliers that are located more than a preselected distance from the user's location. The preselected distance may be selected based on convenience to the user or the supplier. The preselected distance may be chosen to include a suitable number of suppliers from which the user may choose.
FIG. 5 shows that user  10 may submit an order to a supplier 40 using system 1. System 1 may provide catalog information 82 to user 10. Catalog information 82 may include a list of suppliers that conform to criteria, which may specify proximity between supplier 40 and user 10.
FIG. 14 shows that server  480 may receive order information 434 from user 410. Order information 434 may include location information 481, which may specify the geographical address of user 410. If server 480 receives location information 481 corresponding to a location known to system 1, server 480 may retrieve a supplier list corresponding to the known location. In some embodiments, this may be accomplished by including a list identification code in a location data object. A location data object may be initialized with a location value when user 410 first accesses system 1. User 410 may have one or more locations, each of which has a corresponding list or list identification code. In such an embodiment, server 480 may use the list identification code directly to retrieve the corresponding supplier list.
If server  480 receives location information 481 corresponding to a location that is new to system 1, server 480 may pass location information 481 to geozoning engine 490. Geozoning engine 490 may use any suitable algorithm to convert location information 481 into geodetic coordinates.
FIG. 20 shows logic that an embodiment of the invention may use choose a supplier list for user  410 (as shown in FIG. 14). After user 410 chooses a location, server 480 determines if the location is new, or “known,” to the ordering system (e.g., system 1 of FIG. 5). If the location is known, a supplier list may be retrieved from a web server (such as Internet Application server 104, shown in FIG. 1) using a list identification code. The retrieved list is then presented to the user. FIG. 14 shows server 480 transmitting a retrieved list in the form of compressed data file 482 back to user 410.
FIG. 20 also shows that if server  480 determines that a received location is new to system 1, server 480 may pass the new user location to geozoning engine 490. Geozoning engine 490 may use any suitable algorithm or utility to convert, or “geocode,” the new user location into geodetic coordinates. By truncating the coordinates at a given number of significant figures, a trapezoidal region, or “zone,” that circumscribes the new user location is defined. In some embodiments, new zones may be defined using U.S. Postal Service Zip Codes. If a supplier list associated with the zone resides in the system, the supplier list may then be retrieved.
If user  410 is a member of a group, the list retrieval process may be expedited. For example, FIG. 1 shows that users 10 may be members of Group X or Group Y. FIG. 20 shows that geozoning engine 490 determines if user 410 is a member of a group. If user 410 is a member of a group, geozoning engine 490 checks to see if the user and the group (which may itself be associated with a location) have a shared location in the user zone. If there is a shared location, geozoning engine 490 may take the existing supplier list identification code from a data object that includes attributes of the group, associate it with the new user location, and pass the supplier list identification code back to server 480. The list corresponding to the supplier list identification code may then be presented to the user.
When geozoning engine  490 determines that a user, such as user 410 shown in FIG. 14, is not a member of a group, a default list may be presented to user 410. Each zone served by system 1 (of FIG. 5) may be associated with a supplier list and a corresponding supplier list identification code. Geozoning engine 490 may associate the default supplier list identification code with the new user location, pass the default supplier list identification code to server 480. Server 480 may then present the corresponding list to the user.
FIGS.  21-23 show different relationships between a zone and a supplier's delivery area. A supplier list presented to a user may include suppliers that have fixed delivery areas. (For example, suppliers may be included in a default supplier list for a zone based on proximity to the zone. A supplier may have independent delivery criteria, however, or may not offer delivery service.) A delivery area may exclude, include, or overlap with a zone.
FIG. 21 shows a delivery area that excludes the zone of a user. Geozoning engine  490 may associate a “Doesn't deliver” attribute with such a supplier in supplier lists associated with the zone or circumscribed locations. When user 410 (as shown in FIG. 14) receives the list, the delivery attribute may help user 410 select an appropriate supplier.
FIG. 22 shows a zone completely circumscribed by a delivery area of a supplier. When this supplier is listed in a supplier list for the circumscribed zone, geozoning engine  490 may associate a “Does Deliver” attribute, and any delivery charge or sales tax information corresponding to the delivery area (sales tax information may include sales tax rate information and may include different rates for different types of supplies and services), with such a supplier.
FIG. 23 shows overlap area  950, which may be a polygonal overlap area, that may result when delivery area 970 partially overlaps zone 980. Geozoning engine 490 (as shown in FIG. 14) may associate a “May Deliver” attribute with a supplier when the supplier is included in a default list for zone 980, but whose delivery area 970 partially overlaps zone 980. The use of a “May Deliver” attribute enables an ordering system, such as system 1 as shown in FIG. 5, to maintain archives of preprocessed supplier lists with at least some delivery information. This data organization and transmission strategy decreases the response time of a file server, such as server 480 shown in FIG. 14.
Coordinates of vertices  960 of overlap area 950 and coordinates of location 990 may be transmitted to a user for local determination of whether location 990 lies within overlap area 950. If location 990 lies within overlap area 950, the supplier does deliver to the location. FIG. 14 shows that the local determination may be performed, for example, by distributed database engine 435 using data processing engine 440 in browser 420. In some embodiments, delivery charge or tax rate determinations for “May Deliver” suppliers may be performed locally.
The system may preprocess lists of suppliers in step  920. Preprocessing may involve gathering supplier information in step 922. Supplier information may include, for example, supplier names, addresses, delivery areas. The system may then divide a geographic region of users and suppliers into zones (step 924). A geographic region may be, for example, a major metropolitan area, a rural county, or any other cartographically definable region. In step 926, the system may generate zone default lists for each zone. A zone default list is a list of suppliers and supplier information for suppliers assigned to the zone. Suppliers may be assigned to zones on the basis of proximity between suppliers and users, marketing, distribution channels, or any other basis. A supplier may be assigned to more than one zone.
In step  928, the system may determine delivery attributes for each supplier on each zone default list. Delivery attributes may indicate whether or not the supplier delivers everywhere in the zone corresponding to the zone default list in which the supplier is included. If the zone falls entirely within the delivery area, the delivery attribute may be set to “Does Deliver.” If the zone falls entirely outside of the delivery area, the delivery attribute may be set to “Does Not Delivery.” If the zone and the delivery area overlap, the delivery attribute may be set to “May Deliver.” In step 930, delivery information, including delivery attributes and related information, may be added to the zone default lists in connection with the respective suppliers.
If a delivery attribute is “Does Deliver” or “Does Not Deliver,” the system may add the appropriate attribute to the zone default lists (step  932). If a delivery attribute is “May Deliver,” the system may add the “May Deliver” attribute to the zone default lists (step 936). The system may determine coordinates defining the region of overlap between the zone and the delivery area (step 938) and add the coordinates to the zone default lists. Delivery attributes and coordinates may be added to the list in compressed form using bit-masking (for delivery attributes), truncation or rounding (for coordinates), and conversion to base-N digits (wherein N may be any integer).
In step  942, the system may receive an indication of a user location. In step 944, the system may provide the user with a zone default list corresponding to the user's indicated location. Step 944 may include presenting the list using features of a distributed database engine. In step 946, the system may download any data processing tools necessary for ascertaining whether suppliers with a “May Deliver” delivery attribute do or do not deliver. The data processing tools may be downloaded to a user's access device as compressed data objects. Data processing tools may be decompressed and activated using features of a distributed database engine.
In step  948, the data processing tools are used in the user's access device to ascertain, for each “May Deliver” supplier on the provided zone default list, if “May Deliver” suppliers deliver to the user's location or not. This determination may be made, for example, by determining if the user's location falls within the region of overlap encoded into the zone default list in step 940.
Some embodiments of the present invention may include an accounting codes feature. In some of the embodiments, this feature is generally represented in steps  164, 165, and 182 of FIG. 4. Some embodiments of the accounting code feature are described in U.S. Provisional Patent Application No. 60/245,826, filed Nov. 3, 2000, and U.S. Provisional Patent Application No.______, filed Jan. 2, 2001, (Attorney Docket No. ATG-6 PROV2), both of which are hereby incorporated herein in their entirety.
Accounting codes may be used in connection with an ordering system, such as ordering system  1 (as shown in FIG. 5), by users, administrative users, and any other users who need to track orders or associated billing information. Some aspects of this feature may involve providing users with opportunities to interact with the system, performing various processes, or providing various displays. These and other steps may be performed by, for example, a client application that is programmed to generate or download screens suitable to provide such opportunities, an Internet browser that downloads suitable pages to provide such opportunities, peer applications, or using any other suitable approach. In an on-line arrangement, access device 102, for example, may be used to run client-based applications. In non-on-line arrangements, personal computer 112, for example, may be used to run client-based applications.
Other aspects of this feature may involve additional processing, such as searching, grouping, calculating, generating reports, and communicating with other systems, or other types of processing. In on-line arrangements (as shown in FIG. 1), such processing may be performed by access device  102, Internet and application server 104, or database server 105, depending on, for example, the processing and storage capabilities of access device 102, the chosen implementation for the markup language documents used, the processing requirements of such operations, or other factors. In non-on-line arrangements (as shown in FIG. 2), such processing may be performed by personal computer 112, remote access device 113, application server 140, database server 105, or distributed among peer applications, depending on the chosen system implementation and the processing requirements of such operations.
For the sake of simplicity and not of limitation, the accounting codes feature will be illustrated herein in the context of an Internet-based system for providing restaurant information and opportunities to order food on-line. This feature of the invention may be used, however, in connection with the placement of orders for any type of services or merchandise. In particular, this feature will be illustrated using the example of providing restaurant information and ordering services to users  510 of Group X using illustrative system 501 as shown in FIG. 25. System 501 may be a simplified version of system 1, as shown in FIG. 5.
Tracking orders and order patterns of users  510 can be important for increasing organizational efficiency and minimizing losses (including those due to error and fraud). Some embodiments of this feature may provide systems and methods for increasing organizational efficiency and for minimizing losses in connection with the placement of orders. Accordingly, some embodiments of this feature may provide systems and methods for identifying orders (or portions of orders) and relating them to associated information using accounting codes.
When user  510 places an on-line order, system 501 may prompt user 510 for any appropriate order information. Order module 525 in group X ordering site 524 may provide user 510 with a user interface features for exchanging information with system 501. The user interface features may be provided through presentation engine 450 of DDBE 435, as shown in FIG. 13.
Order data entry forms and accounting code fields may be provided to users  510 for entering expensing data in connection with orders. Expensing data may be in the form of accounting codes. A user may enter any appropriate accounting codes. System 501 may prompt user 510 to assign one or more accounting codes to a given order. Order expenses may be divided or split among multiple accounting codes according to cost, specific items or services, accounting code groups (in cases where codes are logically grouped according to organizational functions, e.g., client or department), any other accounting function or code, or a combination thereof.
Accounting codes may be stored with order information (which may include electronic transaction receipts). Order information may be saved and indexed, for example, in a database or other data-storage device. Some embodiments of the invention may provide reporting functions to search the stored order information. Reporting processes may be run using accounting engine  560. Accounting engine 560 may include a database for order and accounting information. Accounting engine 560 may receive order and accounting information from order server 530. Administrative user 511 may use administrative module 527 in Group X site 524 to submit requests for data, analysis, reports, or other information products to accounting engine 560. Reports and data may be returned to administrative user 511 using administration module 527, or any other means, which may include e-mail, fax, or postal service.
Administrative user  511, who may be a system administrator, organization accountant, or other designee of Group X, may request reports in connection with a variety of analyses. For example, system 501 may provide administrative user 511 reports for any given time period, order placement history, patterns, and costs associated with given users, accounting codes, suppliers, and projects.
Administrative user  511 may customize an expensing program for Group X interactively, using a administration module 527. For example, administrative user 511 may provide the names of expense codes (e.g., Client Code, Matter Code, User Code, and Project Code) and formatting parameters of the codes (e.g., the number or type of characters in a code). Administrative user 511 may provide to accounting engine 560, and may periodically update, a list of current and valid accounting codes. The list may be keyed in at web site 524 or uploaded to accounting engine 560 from a user access device. The accounting code list may be used to validate codes entered by users 510.
Administrative user  511 may activate an expense code validation process based on a list of valid and current expense codes. The validation process may run in accounting engine 560 (in connection with codes received by order server 530 from order module 525). After user 510 enters a code to expense an order, the code may be checked against the list of valid and current codes. If user 510 enters a code that is not included in the valid code list, user 510 may be informed that the codes are not listed. The company or service provider may choose to allow the user to enter the order using the invalid code or to change the code. If an order is placed using an unlisted or otherwise invalid code, the order may be flagged for later investigation and an electronic mail notification of the suspect transaction may be sent automatically to administrative user 511 or the Group X accounting department.
Administrative user  511 may provide text or other information to accounting engine 560 that describes Group X's order-expensing policies. The policy-oriented text, or any other text, may be presented to users 510 when they log in or enter accounting codes using order module 525. The text may be conveyed to order module 525 via order server 530 or by any other suitable server (not shown).
Administrative user  511 may provide a list of users and user identifiers to accounting engine 560 for validation of orders or transactions submitted by users 510. (User e-mail addresses may be used as user identifiers.) Administrative user 511 may associate each user with one or more permission levels to control access to administrative and accounting functions of the accounting site and to enforce order-expensing policies. (Each permission level may have a corresponding set of order-expensing rules or restrictions. Order expensing rules may impose restrictions based on order-related information including, but not limited to, user position (e.g., partner, associate, or assistant), time of day, and expense code. For example, a rule established at the associate permission level may state that associates can expense $25.00 for dinners between 7:00 p.m. and 1:00 a.m. during weekdays. Another rule may limit the amount that may be expensed for a particular client for a food order.
Using Group X expensing rule information, accounting engine may, via order server  530 or another server, display warnings to user 510 at the time an order is assembled using order module 525. A warning may be keyed to one or more elements of the order (e.g., the permission level or position of user 510, the time of day, or the expense codes chosen by user 510). Administrative user 511 may place special limitations on users' expensing privileges in accordance with Group X policy or expensing rules. For example, a user's privilege to order via a house account can be turned off in response to abuse by the user.
Users  510 may be enabled to enter a Group X account number for a given restaurant to charge a food order to the corresponding house account. Restaurant account charges and project, client, and matter expense codes associated with the order may be stored by system 501 and accessed by or transferred to administrative user 511 for subsequent accounting, reconciliation, and billing tasks. (For example, at the discretion of administrative user 511, user 510 may charge a personal order to a house account and enter his user identification number and/or an appropriate expense code so Group X can subsequently bill user 510.) When a house account is not available, user 510 may pay the restaurant for the order using, for example, cash, a personal credit card, or a credit card owned by Group X for either a personal order or a Group X order.
In some embodiments of this feature of the invention, system  501 may provide a company with a bill consolidating all charges to house accounts made by users of a user group during a given billing period. Accordingly, for all of those restaurants holding house accounts for the group, the group would receive a single bill and make a single payment, for example, to the system 501 or a service provider that provides system 501 to users.
When an order is submitted to system  501 by user 510, order information, including project, client, matter, and expense splitting codes and information are stored in a database on any suitable storage medium. Subsequently, they may be accessed by administrative user 511 for accounting purposes.
Accounting engine  560, which may include an expense reporting engine (not shown), may generate reports that include any information associated with a given order, including the full text of the order. The expense reporting engine may provide summary reports or detail reports. The reports may be viewed, printed, or downloaded in any suitable format. Accounting data may be accessed by administrative user 511 or other authorized users and reports may be generated 24 hours a day.
A report may list any set of users  510 selected by administrative user 511. Such a set may include all users 510 in Group X, a single user 510, or any subset of users 510 that is useful for Group X accounting purposes or other purposes. Similarly, the system may generate reports based on any set or subset of any of the order information elements. For example, a report may show only those orders placed with a particular restaurant, at a particular time of day, or having a particular total. (Tools for generating these reports are not shown).
Reports may include an order identifier (“order I.D.”). The order I.D. may be a unique number that may be used throughout the system to identify, access, group, and file orders. The order I.D. may be assigned to an order by order module  525 at the time an order is created. The detailed report also displays any adjustments that may have been made to an order total. Adjustments may be made by administrative user 511 to reconcile accounting discrepancies or correct errors. Reports may highlight ordering activity that violates company rules, exceeds predetermined threshold spending values for a given category of spending, or uses invalid or outdated expense codes.
Each type of object may include attributes that are necessary for processing information associated with that object. For example, a group may be represented by a group object that has attributes including user identifiers and valid expense codes. A user may be represented by a user object that has attributes including position (e.g., partner, associate, clerk). A food order may be represented by an order object that has attributes including menu items, total amount, and the identifier of the user who placed the order. Order module  525 may use an order engine data object. Data objects may be stored in an object layer or database layer within an user's local browser.
Expensing rule functions may be stored in a web or database server within system  501 and transferred to a user's local browser where they may be stored in an object layer of a database. The expensing rule processing module may activate functions and may evaluate them based on the values of predetermined data object attributes. Function activation and evaluation may be localized in the translation layer and function output may be channeled to a user via the presentation layer.
In step  562, the system may receive an indication from a user that an order, which may have been entered using a user access device, is in final form and that the user is ready to make payment arrangements. Payment may be made either on-line (e.g., by credit card, or house account) or off-line (e.g., by cash or C.O.D.).
In step  564, the system may receive an indication from the user that the user desires to use accounting codes to keep track of expenses connected with the order. If the user does not want to track the expenses, the process proceeds to final steps of the process, in which the order may be stored, submitted to a supplier, and reported to an administrative user.
If the user elects to use accounting codes to track the expenses, the system may present the user with group expensing policy information (step  566). The system may provide hotlinks to details about group expensing policies or rules that govern the use of accounting codes for users (steps 568 and 570, respectively).
In step  572, the system may prompt the user for accounting codes (e.g., client codes, matter codes, project codes, employee codes, any other relevant codes, or any combination thereof). In step 574, the system may receive an indication from the user to split the order expenses between two or more accounting codes. If the system receives an indication to split an order in step 574, the system may receive an indication of a splitting method in step 576. Splitting methods may include percentage splits (e.g., a percentage of the order may be charged to each accounting code), amount splits (e.g., a selected number of dollars, pounds sterling, francs, etc., may be charged to each accounting code), or sub-order splits (e.g., the system may receive indications of which items in the order are to be charged to each accounting code).
The system may receive any accounting codes associated with the order in step  578. In step 580, the system may perform validity testing on any submitted codes by comparing the codes to codes listed in a system database by an administrative user. If the codes are deemed invalid (e.g., a submitted code is not found in the database or a submitted code is found in the database, but is inactive), the system may issue a warning to the user in step 582. The system may issue notices to an administrative user or other authorized individual. If the accounting code is found to be valid in step 580, the system may check if the prospective transaction is permitted, according to group rules, in step 584. Group rules may include criteria related to user authority or permission level, time of day, day of week, cost of order, budgetary restrictions, user usage history, or any other criteria or combination of criteria. In step 586, the system may issue warnings or messages similar to those of step 582. Steps 582 and 586 may loop back to steps 580 and 584, respectively, when warnings are required to be issued. Users may be provided with the ability to bypass or override warnings in some of those embodiments.
In step  588, the system may store order information including information related to the user, any supplies ordered, billing information, and accounting codes, if any, in a database. In step 590, the order may be submitted to a user-selected supplier. Any accounting codes may be submitted to the supplier with the order for subsequent accounting purposes. In step 592, the system may report order information, which may include accounting codes, to an administrative user. A report, which may be customized by the administrative user, may be made by the system upon the request of the administrative user.
Some embodiments of the invention may include systems and methods for using an electronic communication network for placing a graphical custom order for items with a supplier. In some of the embodiments, this feature is generally represented in step  163 of FIG. 4. Items may include consumer products, electronics, automobiles, automobile accessories, sporting equipment, industrial equipment, clothing, food items, and any other items that may be customized. If items are food items, they may include restaurant menu items, grocery items, specialty food items, or other food items. Some embodiments of graphical custom ordering are described in U.S. Provisional Patent Application No. 60/191,359, filed Mar. 22, 2000, which is hereby incorporated herein in its entirety.
FIG. 27 is a generalized flow chart showing steps involved in illustrative graphical custom order  1100 in connection with an on-line ordering system. In step 1105, the system may receive an indication an item from a user. For example, the system may display a graphical representation of the item and the user may select the item by clicking on the graphical representation. In another suitable approach, the user may click on a textual link to the item. Any other suitable approach for prompting a user to select an item may be used. In step 1110, the system may display a graphical representation of the selected item or an outline or schematic framework of the item.
In step  1115, the system may display graphical representations of options, which may be preselected options, for “integration” into the selected item. In step 1120, the system may display an active button to allow the user to divide the selected item into sections or subsections. For example, a pizza may have wedge-shaped sections, a sandwich may have slab-shaped sections arranged in a stack, and a salad platter may have polygonal sections or cells. In step 1125, the system may receive an indication to divide the selected item. If the user indicates that the selected item should be divided, the system may divide the display of the selected item into sections. The user may indicate finer degrees of sectioning by repeated clicks on the active button. The user may highlight a displayed section and indicate subdivisioning of the displayed section.
After the selected item is divided into sections, step  1130 shows that the system may receive an indication from the user to activate a section for applying an option. For example, a user may click on a quarter section of a pizza for subsequent application of a topping. The system may highlight the selected quarter section of the pizza. If, in step 1125, no indication to divide the item is received, graphical custom order 1100 may skip step 1130 and proceed directly to step 1135.
After an item or section of an item has been selected for the application of an option, the system may receive an indication of an option selection from the user in step  1135. For example, the user may click on a graphical representation of an option displayed in step 1115. When the user clicks on the option, the system may convert the cursor graphic to a graphical representation of the option.
In step  1140, the system may receive an indication of the application of an option to an item or section. For example, the user may drag the representation of an option to a position on top of the item or selection and up-click the mouse button. The system may respond by displaying the item or section as it would appear when modified by the dragged option (step 1145).
In step  1150, the system may receive an indication from the user to finalize the order. If the order is to be finalized, the display of the item, with any option selected, may be transformed into a cooked version of the item (step 1160). For example, a pizza may appear to have shredded cheese during virtual assembly, but would appear to have melted cheese after cooking. Displays of items that do not require cooking may be left in an “uncooked” state. After finalization, the item and any selected options may be recorded in a data object corresponding to the order. The system may transform displays of other items into final form. For example, if a user selects an automobile wheel and a tire, the system may illustrate the tire as mounted on the wheel and use animation or video to illustrate the tire as it is inflated.
In step  1150, the user may choose to select additional options for the selected item, section, or sub-section. The user may also choose to create new divisions in the item. Accordingly graphical custom order 1100 may reiterate from step 1125. In step 1161, the item, as modified by any options, may be added to the order.
FIG. 28 shows a general flow chart for illustrative steps involved in custom order decomposition. In step  1170, the system may receive an indication from a user to submit an order for a custom item to a supplier. The system may submit the order to the supplier in step 1172 by an suitable means, including, but not limited to, fax and e-mail. The system may provide the supplier with textual description 1174. The system may provide the supplier with graphically decomposed order 1176. Graphically decomposed order 1176 may decompose an order into easily comprehensible components to simplify the process of assembling the item.
FIG. 29 shows graphically decomposed order  1180 as an example of graphically decomposed order 1176 when the selected item is pizza and there are several selected options. The system may decompose the custom pizza into layers that correspond to each option and show the distribution of the option across the surface of the pizza. Layer 1 may be an option for thin sourdough. Outline 1182 shows that the options associated with layer one cover the entire pizza. Outlines 1184 and 1186, and 1188 show that layers 2,3, and 4 (regular pizza sauce, mozzarella cheese, and mushrooms, respectively) also cover the entire pizza. Layers 5 and 6 (olives and green peppers, respectively), cover only selected sections of the pizza as shown by outlines 1190 and 1192.
The pizza can be assembled by adding one layer at a time in numerical order. When options are applied to limited sections of the pizza, the outlines may give the relative orientations of the limited sections. For example, outlines  1190 and 1192 correspond to layers having ½ coverage by olives and ¾ coverage by green peppers.
In some embodiments of the invention, client-side user interface functionality for graphical custom orders or order information formatting functionality for custom order decomposition (as shown, for example, in FIGS. 27 and 28- 29,respectively) may be provided by downloading special functions to the user's browser. Providing special functions may be accomplished, for example, using some or all of the DDBE principles illustrated in FIG. 18a.
In some embodiments of the invention, systems and methods for placing group orders with suppliers via an ordering system may be provided. In some of these embodiments, this feature is generally represented in steps  154, 156, and 164 of FIG. 4. A group order may be an order that is placed by a group of users of the ordering system. The group order may be initiated by a host user who submits an order, accompanied by a list of invitee users (hereinafter, “invitees”) to the ordering system. The system may forward invitations, which may be electronic invitations (e.g., e-mail invitations) to the invitees. The invitation may identify a supplier proposed by the host user. Some embodiments of group ordering are described in U.S. Provisional Patent Application No. 60/191,359, filed Nov. 3, 2000, which is hereby incorporated herein in its entirety.
FIG. 30 shows group order holding bin  731, email engine 732, and group order status engine 733, each of which may be included as modules that interact with, or are components of, order server 730. Order server 730 may be part of an on-line ordering system such as system 1 (as shown in FIG. 5) that may be implemented using database server 105 and Internet and application server 104 (as shown in FIG. 1).
Host user  710 may submit an unverified request to initiate a group order to request filter 704. Request filter 704 may process the unverified request into a verified request. The verified request may include any system, user, or order state variables necessary to identify the request as a group order request or to specify permission levels for user 710. The verified request may include any other variables that may be necessary for order server 730 to process the request. Request filter 704 may format the verified request as necessary for proper processing by order server 730.
According to some embodiments, host user  710 may initiate a group order in connection with an order placed in accordance with methods described elsewhere in this document. A group order may be placed using, for example, a user interface having displays or data entry screens similar to those illustrated in FIGS. 33 and 35-67. Order server 730 may receive an indication from host user 710 that the order should be processed as a group order.
Order server  730 may receive, via the verified request, indications of invitees 711 that host user 710 desires to include in the group order, a deadline for receipt of an RSVP from an invitee 711, a time or time frame for an order event (e.g., a time or range of times for picking up supplies, meeting at a restaurant, or meeting at a designated location to receive delivery from a supplier), and a deadline for placing an order. Invitees 711 may be identified by any suitable identification code, including, but not limited to, a login name, an e-mail address, or a given name.
When the verified request for a group order includes a request for an individual order for host user  710, order server 730 may direct host user order information to group order holding in 731. Group order holding bin 731 may hold the individual host user order while waiting for the submission of corresponding orders from invitees 711. When the verified request for a group order includes a request to issue one or more invitations, order server 730 may direct invitation information (e.g., information specifying invitees, supplier, or particulars relating to an event) to e-mail engine 732.
E-mail engine  732 may send email invitations to invitees 711 identified by identification codes in the verified request. When identification codes other than e-mail addresses are used, email engine 732 may search for and find corresponding e-mail addresses using a system database server, such as database server 105 (shown in FIG. 1). Database server 105 may use a user variable identifying user 710 as member of a group or as a user of a given location that is also linked to a user variable corresponding to an invitee.
Invitees  711 may be provided with a hotlink to an ordering site for submitting an order to order server 730. State variables of the invitation, which may be sent by e-mail engine 732 in accordance with the verified request, may automatically identify each of invitees 711 to order server 730 as an invitee of the group order. Any orders placed by invitees 711, therefore, may be held in group order holding bin 731 and associated with the individual order placed by host user 710.
Group order holding bin  731 may assemble orders from invitees 711 and host user 710 into a single group order for issuance to a supplier. Assembly and issuance of the group order may be initiated by an instruction from host user 710.
Group orders may include accounting code attributes as described above. In some embodiments, accounting codes may be input by host user  710 and invitees 711 at the time their respective orders are submitted to order server 730. In these embodiments, order server 730 may communicate accounting code information to an accounting engine, such as accounting engine 60 shown in FIG. 5, for later analysis by authorized system users.
Invitees  711 may send an RSVP, which may be a hotlink RSVP, to host user 710. RSVPs may be sent to host user 710 or to group order status engine 733. Group order status engine 733 may track the status of all RSVPs received and all orders placed in connection with the group order. Group order status information may be presented to host user 710 via email or by presenting group order status a web page that host user 710 is permitted to view.
In some embodiments, host user  710 may view group order status information using a push engine as described above. When a group order in group order holding bin 731 is deemed sufficiently complete by host user 710, order server 730 may receive a “SEND GROUP ORDER” request from host user 710.
In other embodiments, host user  710 may request a group order without placing an individual order. Accordingly, host user 710 may request an “incomplete” group order and complete the group order at a later time. For example, host user 710 may request an incomplete group order and delay placing an individual order until receiving a response from invitees 711. If a favorable response is received from invitees 711, host user 710 may complete the order by directly accessing the incomplete order in order server 730. Alternatively, host user 710 may place an order as an invitee via a self-addressed invitation requested in connection with the incomplete group order.
If inadequate or an unfavorable response is received, host user  710 may send a request to order server 730 that the group order be canceled. E-mail engine 732 may send suitable cancellation notifications to invitees 711.
Some embodiments of the invention may include systems and methods for reducing the risk of bad debt that may accrue to a provider of an on-line ordering system or service. In some of the embodiments, this feature is generally represented in steps  172 and 174 of FIG. 4. An on-line ordering system or service provider may agree with a supplier that the provider will facilitate a sale of supplies or services by a supplier to a system or service user. In turn, the supplier may agree to pay a commission (e.g., a percentage of the value of the sale or a fixed fee per sale) to the provider. Credit card pricing is described in U.S. Provisional Patent Application No. 60/191,359, filed Mar. 22, 2000, which is hereby incorporated herein in its entirety.
where m discount may be less than mdirect. Pprov may thus be greater than Psupp/direct.
where q prov is a service charge rate imposed on the supplier by the provider in exchange for processing the credit card payment and n is a commission rate. For example, qprov may be 1.5% and n may be 5%.
According to the principles of some of these embodiments, the supplier may benefit from having the provider process the credit card claim to the extent that q prov is less than mdirect equations (5) and (6)). Additional benefit may be conferred by the provider to the supplier by setting qprov less than mdiscount (equation (4)). The cost of the additional benefit may be offset by investing the payment to the provider Pprov (equation (2)) for a fixed period of time before making payment Pdelay to the supplier.

References: Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60