WO2002001398A2 - System and method for building modular e-commerce engines, processing electronic commerce transactions offline, and designing electronic storefronts - Google Patents

Abstract

A system and method for processing electronic commerce transactions "real-time" and "offline", in addition to providing a method of designing electronic storefronts, i.e., "e-Storefronts" by an integrated, secure, distributed network-accessible system is disclosed.

Description

SYSTEM AND METHOD FOR BUILDING MODULAR E-COMMERCE ENGINES, PROCESSING ELECTRONIC COMMERCE TRANSACTIONS OFFLINE, AND DESIGNING ELECTRONIC STOREFRONTS

CLAIM OF PRIORITY This application claims the benefit of priority from Provisional Application Serial

No. 60/214,793, filed June 28, 2000.

TECHNICAL FIELD The invention relates generally to a system and method of processing electronic commerce ("e-commerce") transactions in "real-time" and "offline," in addition to building modularized e-commerce engines and providing a system and method of designing electronic storefronts, i.e., "e-Storefronts".

BACKGROUND OF THE INVENTION Today, one of the major driving forces in the reshaping of the modern economy is the inter-connected access that the Internet is providing to the world- wide community. Existing companies, in many instances, face heightened pressure to increase revenue and market share. The initial and increased utilization of the Internet and related technological resources provides businesses the opportunity for those increases. Many providers of commercial, as well a non-profit, products and services have yet to participate in the e-commerce market place. There exists a present need for the acquisition and/or development of rapid e-Storefront capability.

Once e-Storefront capability is obtained, an organization begins to grapple the issues and challenges surrounding the business and logistics of product/service fulfillment. A major problem and source of significant loss in e-commerce revenue is the inability of present day e-commerce businesses to successfully complete transactions involving customer inputted erroneous/inconsistent/incomplete data, ISP downtime, failure of credit card authorization, etc. These and associated problems are often the result of the e- commerce system being dependent on "real-time" processing of transactions, such as product orders. Thus, there is a need to develop and incorporate "off-line" systems and methods which would enable e-commerce businesses to successfully complete transactions that would otherwise result in a "non-sale" and accompanying loss of revenue.

dc-240410 i Today, computers connected to the Internet have almost ubiquitous and instant access to information stored in distant locations and provides an ideal mechanism to facilitate, improve and accelerate the connectivity of suppliers, manufacturers, resellers/distributors, content providers and customers. In furtherance of the principle objective of the invention, any means that can rapidly accelerate and reduce the cost of such connectivity would be most welcomed by traditional "brick and mortar" and Internet- based companies. Therefore, an innovative method has been developed for a fully customizable e-Storefront design and e-commerce engine system and method.

SUMMARY OF THE INVENTION

In one embodiment of the invention, there is a method of designing an e-commerce web site. The method includes, for example, gathering information from a user that facilitates the creation of the web site, creating a customized interface for the web site with elements based on the gathered information and defining the functionality of each of the elements.

In one aspect of the invention, the method of gathering includes a non-branded template provided to the user for inputting the information.

In another aspect of the invention, the method includes customizing the customized interface by defining each of the elements such that the elements are modified to identify specific needs of the user, reviewing the customized interface to ensure that each page of the customized interface functions properly and that each page functions with each other page and launching the web site to test the functionality for a specified amount time.

In another embodiment of the invention, there is a system for designing an electronic storefront. The system includes, for example, a template to store the physical layout of elements on the electronic storefront, a creative treatment applied to a corresponding element to define the appearance of each element in the template and a software development unit to define the characteristics and functionality of each element in the template based on the creative treatment applied.

In one aspect of the invention, the system includes a database storing products and/or services content to be displayed on the electronic storefront.

In another aspect of the invention, the system includes the electronic storefront created by the system allows each component to be created, developed and modified independently from each other. dc-240410 2 In yet another embodiment of the invention, there is a computer readable medium having instructions thereon. The computer readable medium includes, for example, the instructions performing the function of gathering information from a user that facilitates the creation of the web site, creating a customized interface for the web site with elements based on the gathered information and defining the functionality of each of the elements.

In still another embodiment of the invention, there is a method of creating an electronic storefront that is customizable. The method includes, for example, providing templates to be selected by a user, the templates including elements that are customizable, providing objects and functions associate therewith to enable the user to customize the elements, and mapping the elements in the templates to the corresponding objects and functions.

DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating an embodiment of the present invention's trading network.

Figure 2 is a diagram illustrating an embodiment of the present invention's e- commerce transaction functional entities and components.

Figure 3 is a block diagram illustrating an embodiment of the present invention's e- commerce engine. Figure 4 is a block diagram of the site manager directory architecture.

Figures 5-7 illustrate the various levels of information that are created, transmitted, exchanged and utilized by the invention's users/clients.

Figures 8-10 are flow diagrams showing how information of differing levels flow between customers and different e-Storefronts of the present invention. Figure 11 is a block diagram illustrating an embodiment of the present invention's data structure.

Figure 12 is a flowchart illustrating the creation of the user/client's commerce engine of the present invention.

Figure 13 is a flow diagram illustrating an embodiment of the present inventions creation of a "branded" user/client prototype-commerce engine.

Figure 14 is a block diagram of an embodiment of the present invention's replication process.

dc-240410 -i Figures 15-20 illustrate various embodiments of the template Web page of the present invention.

Figure 21 is a block diagram of an embodiment of the present invention's hold process. Figure 22 is a block diagram of an embodiment of the present invention's off-line processing.

Figure 23 is a block diagram of an embodiment of the present invention's off-line processing.

Figure 24(a) is a flow diagram illustrating the prior art process of order receipt and fulfillment.

Figure 24(b) is a flow diagram of an embodiment of the present invention's order processing.

Figure 25 is a flow diagram of an embodiment of the present invention's order status processing. Figure 26 is a flow diagram of an embodiment of the present invention' s order processing.

Figure 27 is a flow diagram of an embodiment of the present invention's inventory availability processing.

Figure 28 is a flow diagram of an embodiment of the present invention's shipping rate processing.

Figure 29 is a flow diagram of an embodiment of the present invention's product catalog update processing.

Figure 30 is a block diagram of an embodiment of the present invention's cross- selling functionality. Figure 31 is a diagram illustrating layers of monitoring.

DETAILED DESCRIPTION OF THE INVENTION The invention provides a system and method of integrated managed "e-commerce" services and software applications. The invention provides horizontally integrated on-line applications linking the e-commerce business and consumer community. The invention provides a platform to connect suppliers, manufacturers, resellers/distributors, and end consumers a full solutions trading network, as illustrated in Fig. 1. The invention also

dc-240410 4 connects content providers. This content may include a broad range of multimedia data including textual, graphical, audio, and animation information.

The invention provides a system and method that allows for the building and coordination of an electronic commerce ("e-commerce") infrastructure and provides for the participation and/or assisted management of e-commerce by the user/client's strategic and affiliated partners. Accordingly, user/clients may or may not have one or more lines of e- commerce revenue. Thus, the invention is applicable to a plethora of business organizations, such as "dotcom" startups, traditional "brick and mortar" manufacturers, etc. The invention permits the incubation of either portions or totality of the user/customer's e- commerce business.

The invention provides a system and method to develop many, if not all, the e- commerce business capacity elements of the technology, along with the means to operate that technology. The invention provides an e-commerce business transaction scheme that generally includes of at least seven components, as illustrated in Fig.2. Other components, such as, Product, Web Site, Payment Processing, Warehouse/Fulfillment, Fraud

Accounting, Customer Service, Hosting, Customer Relations Management, Advertising/Marketing, Content Management may also be implemented. This is often referred to as the "back-end" of the e-commerce business, as the ultimate customer principally interfaces with the user/client's "front-end", Web-site design, content and functionality which is provided, in part, by the system's applications, as illustrated in Fig.

3. These "back-end" components include, but are not limited to, product/service, fulfillment, payment processing, customer service, fraud/accounting, hosting, on-line marketing and e-Storefront management. Specifically, the product/service comprises those offered by system users, e.g., manufacturers. The invention fulfillment elements include receiving inventory, inventory management and reporting, warehousing and storage, product pick-up/package/shipment, delivery, including digital, return management and "real-time" order tracking management information. Payment processing includes, but is not limited to, secured on-line transactions, batch-process off-line credit card authorization and tax calculations. The invention's fraud/accounting elements include fully customizable risk management, which involves on-line fraud screening, address verification and order suspension, e.g., orders exceeding $1,000 will be suspended. Also included in the fraud/accounting elements are "real-time" sales/cost reporting, along with daily reconciliation, all of which reduce fraud management expense. dc-240410 5 The invention provides for 24-hour/day customer support, including dedicated toll free support lines, account specific customer service representatives, product education/training models, product specific return policies, on-line and telephony order capability, in addition to customer order history and "real-time" tracking. The invention's hosting elements provide for high reliability and continuous monitoring by the shared server system. There are three layers of monitoring. Hosting Facility monitors equipment at an Operating System Level; 3^rd party partner monitors all applications/software running on hardware and Internal performance monitoring as illustrated in Fig. 31. The invention's hosting system and method provide reduced development costs, improved site sales performance and reduced time to market. The invention's on-line marketing includes "data mining" systems and functionality, direct marketing tools/services, media buying/site marketing, marketing strategization. In particular the data mining includes a membership database, shopper view/buy history profiles and log files. The system's data mining enhances customer relations, increases repeat sales/revenues, while also providing the capability to share customer data mine-generated information. The invention's e-Storefront management tools include product and sales management, ad server, which gives the client the ability to run customized ads on their site through the CSP web interface via a pre- templated design-each location is assigned a tag and reference. (Client posts the ad based on tag and reference number), marketing and promotion and "real-time" online financial reporting. <

Managed Services: Services + Applications

The invention provides for the comprehensive incubation of the user/client's e- commerce-based business, particularly for those user/clients who do not presently have such business. The invention provides for logistics, resources and management on the "back-end" of the supply and delivery of goods and service, along with the design and implementation of the customer accessible "front-end" of a user/client's e-commerce business, as illustrated in Fig. 3. The invention permits the design, development, delivery/operation in, for example 8 to 12 weeks, of a highly customized built to order e- commerce business model for a specific user/client, e.g., manufacturer. Presently, the development of a fully integrated e-commerce capability, from order request to fulfillment and reporting, takes 6-8 months, at a minimum. 100% technology is built from scratch.

For CSP, approximately 80% of the technology already exists, and approximately 20% is customized for customer (a hybrid between customization and shrinkwrap software). Thus, dc-240410 6 the invention permits the creation of the clients/user's e-commerce business "front end," e.g., Web-site, including applications and hardware, along with the establishment and operation of the "back-end" of their e-commerce business, as illustrated in Fig. 3.

Therefore, the client does not have to be knowledgeable about, maintain or operate any new hardware, software, Internet connectivity access points; or applications that sit on top of the software, all of which are necessary to manage his/her e-commerce-based business. The invention provides for warehousing, fulfillment, customer support, payment processing, fraud and accounting. Thus, the invention provides a customized "turn-key" solution where the value proposition to the customer is quick-time to market and mitigated risk by performing many e-business activities that the client does not have competency to engage.

ASP: Applications

The invention's system and method permits the transition from the above mentioned incubation of the user's/client's e-commerce business toward the ASP-type embodiment of the invention, involving the user/client's access and use of only the invention's applications and hardware, e.g., servers. At each stage, the system and method can be selectively used, wherein the user/client can engage in direct contracting for some of its services/products/content, along with the self-management of their own business

< processes and operations. Examples include customer support, payment processing, fraud/accounting, fulfillment and warehousing. The invention permits a client to utilize only applications, thus the system functions as a traditional ASP. Accordingly, the user/client can use their own warehousing company, or customer service company, for instance, while employing the ASP systems and method of the invention.

Branded Solutions: Client In-house Solutions Another embodiment of the invention's method permits a user/client to customize and create a "private label", i.e., "branded", version of the invention's system. As a practical matter, the invention could be purchased and integrated as part of the core the user/client's e-commerce business operations.

Therefore, the first embodiment of the invention's method is particularly useful for a user/company which is a start-up or is new to the e-commerce marketplace. This allows the company to focus on their core competencies. The second embodiment of the invention's method permits the user/customer to operate in the ASP environment. This occurs when the company wants to augment their business model or their revenue volume dc-240410 7 increases and/or get so large that it no longer makes sense to operate in a pure managed solutions environment. In the third embodiment, the invention permits the user/customer to operate using the invention's branded solutions. This would ordinarily occur when a user/company is generating multiple millions, if not billions, of dollars in e-commerce transactions revenue through the invention' system. Thus, the user/customer would not want to be in that ASP environment and would desire to own the embodiment outright.

Thus, the various embodiments of the invention permit a progressive approach to initiating, transitioning and autonomously operating the user/client's e-commerce business. Thus, in one embodiment, the user/client maintains a "hands-off approach. In another embodiment, the user/client utilizes the invention in the ASP mode. In an additional embodiment, the user/client completely manages and operates the e-commerce business on his/her own.

In various above enumerated embodiments, the invention allows a user/client to select and engage a plurality of strategic partners, e.g., product, service and content providers, and business affiliates, based upon the degree of competency in a given e- commerce business function it chooses to develop or maintain.

Figs. 5-7 illustrate the various levels of information that are created, transmitted, exchanged and utilized by users/clients.

As illustrated in the various diagrams, "Level I Information" refers to aggregated user information which is not personally identifiable to any particular user, including, without limitation, site traffic and behavioral patterns, network traffic and behavioral patterns, sales volume, transaction history, and order tracking information; "Level II Information" refers to profiled user information, including, without limitation, gender, age group, geographic area, income, and interests; and "Level III Information" refers to personally identifiable user information, including, without limitation, name, address, phone number, and e-mail address. User/client A (502/602/702) is a network participant without any additional services. User/client B (503/603/703) is not a network participant but has an e-Storefront, i.e., an ASP or a private "branded" label. User/client C (504/604/704) is a network participant that has an e-Storefront. User/client D (505/605/705) is a network participant and licenses content to the network supported by the present invention. User/client E (506) is a network participant that has an e-Storefront and licenses content into the network or licenses content from others. User/client F

(507/607/707) is a network participant that has an e-Storefront, licenses content into the dc-240410 g network and licenses content from others. Finally, user/client G (508/608/708) is a network participant that has an e-Storefront, licenses content into the network, licenses content from others and licenses value chain management software (this is for both buyer and seller). Figures 8-10 are flow diagrams showing how information of differing levels flow between customers and different e-Storefronts of the present invention. The invention allows users/clients to engage in e-commerce with customers in a highly flexible manner that is selectable by the user/client depending on its technical/logistical competencies and business model and objectives. Thus, the invention enables users/clients to select the form functionality of its e-Storefront, i.e., managed service, ASP or private label (licensed and wholly operated), in addition to choosing the type of information, i.e., "levels" it desires to generate, transmit exchange and receive.

The invention provides a novel implementation methodology which brings increased value to the user/clients. The invention integrates system and methodology. The way the system is structured leads to the manner in which the method is implemented. An embodiment of the invention's system comprises a unique data structure, as illustrated in Fig. 11. The structure 1101 comprises templates 1102, creative treatment 1103, business logic middleware software 1106, and database components 1107. These components may be housed on different hardware components, e.g., servers (1102 and 1103 are together referenced to as the presentation layer 1104) or can be housed on a single server. The invention's data structure permits the manner in which the invention's method is implemented. The data structure permits the design, development and operation of a fully integrated e-commerce business within a heretofore timeframe, e.g., 8-12 weeks, heretofore unrecognized and unachievable by the prior art. The comprehensive structure and organizational layout of the invention's system permits the design, creation and operations of a user/client's e-commerce business in just a matter of weeks, as opposed to the prior art timeframe of 6-8 months, as mentioned above. Thus, it is the combination of how the system components are developed and managed that permit this rapid e-commerce implementation. e-Storefront Design Methodology

Fig. 12 illustrates the methodology of creating a user/client commerce engine, according to an embodiment of the present invention. The invention's method involves learning about the user/client current and future e-commerce business needs, i.e., a dc-240410 9 "discovery" period 1202. "Discoverable" information includes, for example, customer patterns, products, and sales process. This phase involves the identification and extraction of information from the client which is necessary and useful in facilitating the creation of a "branded" e-commerce engine. Thus, a dedicated prototype shell, i.e., "non-branded" templated format, is initially provided and transferred to the user/client server, for example, and then, based upon the information obtained in this phase.

Next, the process of customization/creation 1203 take place. The prototype 601 is provided wherein the creative aspects of the commerce engine are tailored to develop a client "branded" prototype 1305. The client begins with the "non-branded" prototype 1301 in a template format, which is replicated by the system's replicator 1302 onto the user/client's servers, or those that have been assigned by the user to perform such a host function. The prototype is then branded by removing the templates 1303, e.g., tailoring them to the user/client's needs, and applying the creative treatment 1304 to create a specific user/client prototype having no functionality differences from the prototype 1301. Creative treatment 1304 is a user interface design, look and feel, done, for example, by a third party developer. Accordingly, Fig. 13 is a flow diagram illustrating the creation of the "branded" prototype.

Thereafter, a process of highly detailed definitization of the elements occurs. An "element" is a single visually apparent unit (e.g., graphic, text box, paragraph, picture, link, etc.) placed on a web page. The next thing that happens is a "fine tuning" process of reviewing and defining the elements by having the user/client review each component of the commerce engine while clarifying and refining his/her operational and functional requirements.

The invention permits the user/client to have an e-commerce engine, and accompanying interfaces, e.g., customer/client, client/manufacturer, manufacturer/supplier, etc., that is a fully branded prototype version that has a "look and feel" that matches their existing brand, without having to customize the functionality of the user/client Web site. Next, customization 1203 occurs, wherein the commerce engine is customized to the client's needs. This is a page-by-page, element-by-element refined customization, that addresses the function requirements, i.e., differences over prototype. At this stage, the client is permitted to identify how it needs to sell products/service/content differently than its competitors, for example. Thus, for example, each page element is individually evaluated for modification. For example, in the check out process-single page process dc-240410 10 with all check out elements on one page or a multiple page with the check out elements — are displayed throughout the multiple pages.

Next is the final review process 1204 which allows the user/client to ensure what was obtained during the discovery and creation, and that customization will actually meet their e-commerce objectives. The invention permits the user/client to make sure that a Web site page functions precisely as it should and correctly interfaces with other pages.

Finally, there is a "soft launch," 1205 i.e., beta launch, of the site and operation of the tailored "commerce engine." Therefore, the client can perform a test launch of his/her Web site for a specified period of time, without any marketing, for example. Thus, the invention permits a client to create a fully functional e-commerce business capability in a heretofore unrecognized timeframe, as compared to the prior art.

In another embodiment, the e-Storefronts are designed around three classes of customer profiles; 1) the "finder"; 2) the "browser"; and 3) the "bargain shopper." First, the "Finder" knows what products/services/content he/she is seeking when accessing the client's Internet Site. Second, the "Browser" is generally characterized as the real-world analog of the "window shopper" who is scanning the available products/services/content and does not have a predefined specific target selection. Third, the "Bargain Shopper" is seeking to become highly informed as to what other shoppers are acquiring and at what price, in order to pay a minimum price for desired products/services/content. The invention permits each page of an e-Storefront to be designed with these three types of customers in mind. Thus, the invention provides a methodology for precisely tailoring the client site content to appeal to both individual and groupings of shoppers based upon preference and biometric data.

The presentation layer section includes a sample Web site and elements used on each Web page. The user/client can design the placement of various creative assets on each page and throughout her Website. Examples of pages provided by the invention include, homepage, product detail, category page, shopping cart, checkout process, and order tracking and receipt, etc.

The presentation layer includes of the templates and creative treatment which are provided during the replication to the user/client servers. The presentation layer's sample web page templates that enable the user/client to place various creative assets on each page and throughout the Web site.

dc-240410 11 Every page is customizable, i.e., laid out, to take advantage of the attributes of each of the classes of shoppers. This is provided in the business layer which has various media objects and functionalities, such as the shopper, basket, receipt, validate, paging, site security, functionality, etc. The three technology layers include the data base layer, business layer, and presentation layer. Interaction between the components is as follows. The presentation layer 1104 interacts with data base layer 1107 through the middleware layer (middleware is the "glue" between the 2 layers). The business layer is designed to not only provide the applications to enable e-commerce purchases, but also to enable the e- Storefront to be successful generating enhanced revenue by generating more sales by tailoring the customer's purchase experience and options. Thus, the invention provides a templated e-commerce business capability that allows the user/client to apply its creative treatment.

The database layer includes of at least two databases, such as the commerce database and commerce manager database. The commerce database houses data and information utilized on the user/client's consumer Web site, while the Commerce manager database houses data and information for the user/client e-Storefront manager. Fig. 4 illustrates an embodiment of the site manager directory architecture.

Fig. 15 illustrates an embodiment of the invention's homepage template. The header 15(1) provides the identification for the e-Storefront, e.g., "shop". The site navigation 15(2) permits order tracking, sign in, check out, customer service and access to various subject matter categories. The search 15(3) provides a category drop-down and text box to search for product, service or content. The shopping-cart 15(4) provides a view of the customer's current shopping cart with items, quantity, price and subtotal, for example. Ads 5, e.g., rotating banner types, for products offered or merchant agreements, for example. Promotions/packages 15(6) link to the promotions that have been entered in the Site Manager. Category navigation 15(7) provides link/drop-down to all categories. Special deals 15(8) link/list to specials that are entered into the Site Manager. Top products 15(9) link/list to a quick view of the products, services and content that is most popular. The footer 15(10) provides a location to link content, such as a document, that will be available on all pages, e.g., terms and conditions and privacy policies. Various elements of each page are optional.

Fig. 16 is an embodiment of the invention presenting illustrative and descriptive content regarding the available products, services and content. Product image provides a dc-240410 12 thumbnail image that shows the product or packaging, for example. Product name provides a short description describing the product; whereas the long description is a detailed description of the product. The manufacturer icon provides an image/text of identifying the manufacturer. The price is also provided for each item. If the item is on sale, the list price will be shown as crossed out and the sale price will be listed below. The SKU is the tracking number for the system's database. Color swatches are used for a product that may be offered in multiple colors. Using this option requires and option box for the selection. Options may be provided for the products offered, e.g., configurations, functions or attributes. Quantity provides a text box for the customer to enter how many of that product she desires to buy. The buy function/add to cart permits the customer to add the product to her shopping cart. Related promotional products, if applicable, are linked to similar products that are being offered with a promotion. Product recommendations are provided for other related products that are available from the invention's cross-sell functionality in the Site Manager which includes thumbnail images, short description, price, etc. Fig. 17 illustrates an embodiment of the category page content. A featured product is a sale item or a random product if no sale item is available. Product name is a short description describing the product. The sale price allows the list price to be shown as being crossed out and the sale price listed below. Promotional images are provided. Thumbnail images show the product or packaging. Fig. 18 illustrates an embodiment of the shopping cart functionality of the invention. The "basket" contents are displayed. Instructions provide an overview of the data or information that the customer is required to input and how to navigate the checkout process. The remove item is used to remove an item from the shopping basket. The name, short description and price per unit of the product placed into the basket may also be listed. The total amount of a discount is subtracted from the list price and presented. The total price after the quantity is entered and the discount is applied and listed, in addition to a subtotal of all items. The method with which the fulfillment center will ship the product is listed, as well as any costs that might be charged for handling. The total tax charged depends on the location of the customer. The total price of the order is listed and includes subtotal, shipping, handling and tax, for example. The continue shopping icon returns the customer to the shopping area to select more products. Update cart re-calculates the total price per item, subtotal for order, shipping, handling, and tax. This figure will be updated in the order total space. Checkout allows the customer to proceed to the next step in the dc-240410 13 check out process. Also, a zip code update is used to determine the customers shipping costs.

Fig. 19 illustrates an embodiment of the checkout page. The checkout page relates to shipping address content and includes fields such as full name, street address, city, zip code and phone number. Upon completing the appropriate fields of information, the continue button permits the customer to continue through the checkout process.

Fig. 20 illustrates an embodiment of the tracking and receipt content of a Web page. The receipt number is the order number for the customer to track her order. The date that the order was placed is listed. The name and address of the place to which the order will be shipped can be inputted, along with the name and address of the entity who will be billed.

Product attributes indicates any options that the customer has selected, such as colors, sizes or attributes.

Software Architecture

In one embodiment, the system's architecture is divided into four components. The first component comprises the templates 1102, which are the physical page architecture.

Specifically, this is where elements are located on a page, as opposed to what they look like and how they work. For example, a header would be an element of a template.

The second component of the commerce engine is the creative treatment 1103. This component involves the elements of the template and how they look. For example, a template having a header would have the creative treatment component applied to define and describe how the header looks, works and functions.

The third component is the software technology 1106. This component defines, for example, how the navigation system in the header operates. Therefore, this component actually operates at the software level and the programming code is "mapped" to the functionality of the template component.

As an example of the relationship between the three components, a search tool, e.g., icon, is represented by the three different components, i.e., where the tool is located on the page, what the search looks like and how the search functions, respectively. In the preferred embodiment, the invention uses standard commercially available search applications, such as Microsoft Search Annex Server™. However, any application can be used with the invention as one having ordinary skills in the art would recognize.

Therefore, the invention's method allows the creation of a user/client system by taking templates and applying the creative presentation layer through the creation process. dc-240410 14 The customization process is illustrated in Fig. 12. The customization component can be worked on individually, without working on the templates or the creative treatment components. Thus, the templates and creative treatments can be finalized well in advance of or later than the software component's finalization. The fourth component is the database component 1107. Because this component is separate from the other components, the interaction that the data might otherwise have on those components, if combined, is prevented.

The invention's system and method allows each component to be created, developed and modified independently of the others. Thus, it is possible to work on each level, i.e., component, individually and never work on other levels at the same time. For example, the physical template to a page can be customized. Therefore, the templates can be re-architected, for example by changing the navigation architecture-i.e. buy button relocation, but their functionality will remain the same as the prototype, because the software technology component has not been altered, at least as of yet. In an embodiment of the invention, the presentation layer which comprises the templates and the creative treatment components reside on a single location space, e.g., same server, as illustrated in Fig. 11. The software technology component resides in a separate space, e.g., server. Thus, this component may be located on a completely separate server from the presentation layer and comprises hard-coded executables, in the preferred embodiment. The presentation layer and the software component have different physical locations because of the system infrastructure. However, one having ordinary skill in the art will recognize that any number of storage locations, e.g. server, can be used, and that the invention is not limited to this physical structure.

There are several advantages to the data structure, i.e., component modularization, of the present invention. This permits there to be differing levels of permitted access and disclosure for the system as a whole. Also, the separation allows the "working" copy of the components to be available and protected from adverse interaction with the other components, such as a database corruption relative to the software components. Accordingly, the invention provides for the separation of the commerce engine components into different servers.

Therefore, the invention permits the efficient management of commerce engine creation/development/operation resources, e.g., human intellectual capital, labor, computer

dc-240410 15 hardware and software, etc. Thus, the right people can work on the right system components, by having access to those components.

In the prior art process of creating a comprehensive and integrated e-commerce engine capability, the templates exist without a creative or software technology component that can be tailored separately. In the prior art process 56 creating e-commerce, components are on a single page and not separated into layers. Therefore, control over each individual component cannot occur and everyone has access to the single page. The invention, on the other hand, can control security at a component level because you can limit access on a component by component basis. Therefore, the prior art process of creating such e-commerce system is much less refined and requires the "front-end" e-

Storefront designers to repeatedly attempt to determine how the templates function, including what level of access to allow system users, e.g., site managers and user/client employees, to modify those templates. In the invention, the system and process are always functionalized. Thus, the invention permits the design and creation of an e-commerce engine through a process that does not entail the simultaneous alteration and modification of aesthetic and functional aspects of the e-commerce engine. The invention allows each component to be worked on individually. Therefore, the entire prior art process which takes 6-8 months, for example, is reduced to a number of weeks or less, for example.

The separation of the components permits all of the components to be worked on independently, simultaneously or sequentially, if desired, because creative treatment can be in one phase for two different customers, while an entire software engineering group can be working on other matters or components. Thus, instead of having a software engineer assigned to this process for 12 weeks, for example, he/she can reduce the amount of time to 4 weeks, for example. The invention provides for the rapid replication of the prototype components. This also enables the development of these components and their associated technologies, such as software, to continually progress. The invention's system can be efficiently replicated onto an existing sever, so that it is now a dedicated system for a specified user/client.

Traditionally, a development system, e.g., commerce engine, had to be rebuilt each time a new client wanted a system. In contrast, the invention permits the user to replicate the entire e-commerce engine, e.g., components, which in turn provide a duplicate working system immediately. The replication tool, as illustrated in Fig. 14, performs all the threads and registers. It actually goes into a server level, thereby functioning as an install dc-240410 6 processing mechanism and device, i.e., an entire install process. The replicator 1402 not only replicates at a software level, but also replicates the functioning e-commerce engine in its entirety (i.e., templates, creative, middleware, database, etc.).

The system's database comprises a unique software architecture, i.e., database structure.

COPS System

The invention provides a method and system for processing customer and user/client transaction independently of either being on-line. It operates on its own separate hardware. The prior art processing systems run while the user/customer is on-line during order processing.

Today, the prior art e-commerce-based businesses, along with traditional "brick and mortar" businesses perform major on-line business transactions, e.g., credit card authorization, order facilitation, EDI, warehouse interfaces, in "real-time." The prior art maintains a pervasive utilization of real-time processes. However, the modern complexities of business operation make it clear that, although generally reliable, such realtime processes are often subject to interim computer system failures and communications break downs, therefore accounting for real-time delays and unprocessed transactions. In the real- world, businesses are in large part dependent upon real-time systems capability, thus jeopardizing their business operations. Hold System

The present invention, as illustrated in Fig. 21, permits the systematic holding, evaluation and release of customer orders received on-line. Under the prior art, a customer's electronic order has to satisfy all order processing requirements, e.g., correct account information, credit authorization, etc., in order for the order to be fully executed. The present invention's hold system 2101 permits an order to be received even if an on-line connection to the customer account credit authorization institution has failed, for example.

Under the prior art's real time transaction processing systems, businesses are continuously vulnerable to systems failure. For example, if a credit card authorization did not go through, the system would just reject the order and terminate the transaction. Further, if the payment authorizing institution, e.g., Cybersource™, goes off-line or the client business is unable to process the credit card orders, for example, the business may not even be able to take any orders because of its' real-time processing systems.

dc-240410 17 Furthermore, the processes of communicating and transacting business with warehousing facilities, for example, similarly subject the client business to transaction- related losses of revenue or increased cost of operation. If the client business attempts to perform any business transaction in real-time and on-line with a warehousing facility, whereby it attempts to get product information, for example, then they are dependent on that real-time system to be fully operational. However, the reality of any technologically sophisticated distributed network, such as the internet, is that it is rarely fully and continually operational. Systems become operational and experience problems. This happens for varying lengths of time ranging from mili-seconds to days or weeks of downtime. Thus, the prior art on-line processing systems make it imprudent for a business to become totally dependent on such real-time systems.

Accordingly, the invention provides a solution to this problem that results from online processing in real-time. The invention performs business transaction processing offline. The system architecture, as illustrated in Fig. 9, reveals that processing occurs off- line. The invention is structured such that the ordering process is not dependent on the infrastructure availability of real time connections, vendor accessibility or payment authorization.

The invention provides the opportunity to increase the rates for order fulfillment, increased revenue due to completed transactions, even aside from that generated by increased consumer "good will." Thus, the invention allows the user to avoid performing all business operations/transactions during the customer on-line business transaction process, e.g., order request. Thus, the invention permits the user/client to be able to proceed through the order request process, for example, and input the requisite data, in which the determination of the validity thereof are not dependent upon any real-time communications to and between any other e-commerce logistics, support or service provider, e.g., credit card authorization. Accordingly, the invention provides a Commerce Off-line Processing System ("COPS").

Under the prior art, a single application performed each component. The components included, for example, are payment authorization, fulfillment inventory availability, fulfillment confirmation, and credit card realization. Accordingly, the prior art is structured such that one application, i.e., one executable, performs one function, e.g. credit card authorization, which in turn has to be monitored, e.g., the monitoring of 17 different applications running on a single server. In contrast, the present invention takes dc-240410 18 the transaction, e.g., customer order request, after completion on the user/client Web-site, for example, through the off-line processes of the system and monitors it and manages what is happening to the order, i.e., how the order is being acted upon. The present invention is different in that if the user/client does not meet the acceptable criteria while online, the order is not necessarily cancelled (the process goes back a second time and re-checks to make sure that criteria can be met). In the prior art, the user/client must satisfy all of the criteria while online in order to complete the order. Thus, the invention processes the credit card authorization, "e-loan" notifications, customer service interactions, warehouse fulfillment, etc., off-line, in addition to on-line. The architecture of the present invention, as illustrated in Fig. 9, is a robust back- end system for processing business transactions, particularly once the customer reaches the "buy" button, i.e., on-line buy decision.

The prior art systems are directed toward simply submitting a customer's Web- based order, receipt and notification and recording the "new" order. However, this is where the prior art ends. For example, prior art e-commerce servers allow the user/client to proceed to and arrive at a certain point in the transaction, such as logging an order as received. As stated above, the prior art on-line processing systems allow the customer to get the buy button, i.e., decision, by providing tools, i.e., software applications. Given the problems inherent to on-line business transactions, there exists a need to create an off-line processing system.

Fig. 22 illustrates an embodiment of the present invention can be envisioned as an automobile combustion engine, having cams running four different pistons, as illustrated in Fig. 23, which is a simplified embodiment of the that depicted in Fig. 22. In this embodiment, the invention is composed of four independently operating "pistons," all running under one system. The first piston is an authorization piston; the second is the fulfillment out piston; the third is the fulfillment in piston; and the last being the payment piston. These four components run independently and concurrently process the orders through to the back-end of the system. However, each component can operate on separate sets of orders. Each order has a status. Each piston operates to see if the order meets certain criteria, and if approved, updates the centralized status of the order. They operate independently of each other and can be working on different orders at the same time.

Orders have distinct stages of their lifetime. After an order is created, it enters the authorization component and process, e.g., payment and fraud screening. Thereafter, the dc-240410 19 order will either be authorized or declined. In either case, the second piston acquires the order, if it's authorized, and forwards it to the fulfillment entity, e.g., warehouse, in addition to a number of other orders that are authorized and ready to be sent off to the warehouse. Thus, the invention permits instantaneous or batch messaging to the fulfillment entity, organization or center. The invention retrieves or accepts the messaging back from the fulfillment center, e.g., warehouse. The invention also allows the retrieval of information from a plurality of different sources, e.g., geographic and data locations. Moreover, a particular piston will periodically check, i.e., look in a specified location, e.g., it can check any delineated format, XML, XLS, Spreadsheet, FTP, EDI, which may or may not be local. When the system finds that there is a notification messaging being sent by the fulfillment entity, e.g., warehouse, it retrieves such messaging. This process occurs in the Fulfillment Outbound Component ("FOC"). Once the messaging is retrieved, it is then broken down according to a specified map. Following mapping, the status is then communicated back into the communications pipeline of the system.

The system is flexible enough to be interoperable with various communications format technologies, such as email, FTP, DDVP or XML. The invention is designed to integrate very easily with, for example, a plurality of different legacy systems and ERP systems. Once the system obtains the information contained in the "return" messages, the system identifies what that order is and whether or not the requested product has been sent out from the fulfillment center. If so, then the system can bill against the order, i.e., charge funds against the customer account.

In another embodiment, the system has an additional layered application built around it that provides fully integrated transaction processing and status notification, i.e., automatic messaging component. Therefore, as an order arrives at different stages in its transaction process lifetime, the system permits the automatic user/client and customer notification. In another embodiment, the user/client has its own uniquely branded message component. Thus, the message that is sent to the customer has the user/client's own brand associated with it, e.g., colors, stylization of text and trade/service marks. The system permits the automatic branding of each message.

dc-240410 20 Fulfillment In/Fulfillment Out

Under the prior art, as illustrated in Fig. 24(a), the customer 24(a)(2) places an order 24(a)(3) which then undergoes an authorization 11(a)(4) determination, and, if approved, the order is sent to the warehouse, i.e., Fulfillment Out 24(a)(5). In contrast, under an embodiment of the present invention, as illustrated in Fig. 24(b), a customer

24(b)(2) places an order 24(b)(3) which undergoes an authorization 24(b)(4) determination, which, if approved, is sent to a warehouse for Fulfillment Out 24(b)(5). Subsequently, the invention permits the warehouse to notify the user/client of the inventory status, fulfillment In 24(b)(6), of the ordered item, e.g., in stock or on back order. Electronic billing 24(b)(7) is performed by the system, followed by processing of the billing request by the payment processing entity 24(b)(8), e.g., Cybersource ™ for example.

Both the fulfillment Out 24(b)(5) and fulfillment In 24(b)(6) components operate independently, but are designed for the needs of each individual user/client, such as in the case of the "branded" solutions system and method describe above. In that case, when the template and creative component of the commerce engine of the present invention are replicated for each user/client, as illustrated in Fig. 14. During "discovery" process, as illustrated in Fig. 12, the user/client identifies their preferred e-commerce engine system requirements, particularly when the ASP embodiment model of the invention is selected, although the same may be true of the managed services and "branded" solutions embodiment models.

For example, in the ASP embodiment, the invention permits a multitude of very customized means, manners and mechanism to communicate the fulfillment entities, e.g., warehouses or call centers, and send orders and receive orders from these product and service providers. Thus, in the case where customization is desired, during the replication of the template and creative treatment components, the system permits the definitization and selection of how that component will communicate with the warehouse. The Fulfillment-In and the Fulfillment-Out pistons enable communication with the warehouse. Various communication pipelines ("CP"), such as MTP, HTTP, FTP, are used in the system. The invention provides a means for mapping back and forth between different CP technologies. Hence, the selection of various layouts, such as text files or XML documents, is permitted and will be sent back and forth between user/client and warehouse.

It should be noted that the specific fulfillment entities may have unique communications dc-240410 21 interface protocol and operational procedure requirements, i.e., a "custom" warehouse. The invention permits such customization, not only between user/client and warehouse, but also warehouse-to-warehouse transactions .

Accordingly, once the communication pipeline is defined and mapping requirements defined, then the fulfillment Out and fulfillment In can be performed.

Real Time Status Reporting

The system monitors trends and specific occurrences of successful and unsuccessful data processing and transaction components, such as those illustrated in Fig. 21. The system's functionality allows the user/client servers, for example, to do more than simply send data, as in the prior art.

The real time status component allows an authorized third party entity, e.g., customer service representative, to be informed of the status of a customer's order, i.e., at what stage in the order's lifetime, in addition to letting a customer know, based upon their own independent access to the system, the status of their order. The system provides access by an authorized party to multiple orders that have been placed by or on their behalf.

However, the real time status component involves instantaneous and continuous automatic updating of the status of a customer's order. In the case of the real time component, the user/client can specify whom and to what extent one is authorized to have access to the real-time status information. Accordingly, Fig. 25 illustrates several components, i.e., CCPIC, OSRIC, OSROC and OSRC, which have associated queues into which status information is automatically forwarded. Thus, order status information is instantaneously provided to those authorized entities, e.g., customer service representatives.

The system assigns a status to each customer order at various points along the communications pipeline, such as new order, authorization of payment, order shipped, and back order ("b/o"). The system permits the periodic sending of accumulated orders, as well as the periodic inquiry into the communication pipeline for the status of an order. As illustrated in Fig. 25, an embodiment of the invention including an order status request component which permits the communication of such requests to an ASP who can in turn provide such service to the fulfillment entity, e.g., fulfillment center, supplier, or channel partners. "Channel Partners" refer to certain third party suppliers of commodity-type

Products (e.g. books, CD's, DVD's, electronics) which may, at a client's election, be offered for sale on the client's storefront. The system permits the communication of such requests to its own "Inbound Queue", as well as to both an order status results queue, an dc-240410 22 order status results Inbound Queue and an external buyer order status results Outbound Queue ("ROQ"). The order status Results Outbound Component ("ROC") communicates the related results to External Buyer Order Status Results Outbound Queue ("EBOSROQ"), as well as a forward order status service provider, which in turn forward the order status results to the buyer, e.g., customer. The order status results Inbound component ("RIC") communicates with the order status Results Inbound Queue ("RIQ") and adds a completely shipped order to the payment/create invoice queue ("P/CIQ"), e.g., credit card ("CC"). In addition, RIC saves the local status to the user/client's commerce database. The Payment Invoice Creation Component ("P/ICC") communicates with the P/CIQ and sends a payment request to the payment service provider, e.g., WebMethods ™ credit card payment service, which in turn send such payment requests to the payment processing entity, e.g., Cybersouce, the order status RIQ.

Fig. 26 illustrates an embodiment of the system's order processing components which also have associated queues into which order processing information is automatically forwarded. Therefore, customers are able to submit an order which is received by an External Sales Order Service. The order is automatically forwarded to the purchase order queue ("POQ"). Also, orders received at the user/client's e-Storefront are similarly forwarded to the POQ. The CC Authorizing/PO Credit Check Component permits that order to be invalid, upon which time, it is automatically placed into the Hold Queue ("HQ") or forwarded to the Authorized POQ ("APOQ"). The PO Component

("POC") monitors the APOQ to determine the presence of newly provided authorized orders. The POC adds the PO to both the user/client Internal POQ ("IPOQ") and the External Supplier POQ ("ESPOQ"). The PO is then automatically forwarded to the user/client's FOC and the External PO Outbound Component ("EPOOC") Fulfillment and subsequently the PO is sent to an External Fulfillment Outbound Service ("EFOS") and

External POOS, respectively. An order fulfillment request if forwarded to a fulfillment center. The PO can also be sent to an external supplier.

Fig. 27 illustrates an embodiment of the systems inventory availability processing which includes Inventory Availability Results Outbound ("IAROC") and Inventory Availability Request Components ("IARC"). Both components are automatically monitored by their associated queues, and the IARC saves inventory availability information in the commerce database.

dc-240410 23 Fig. 28 illustrates an embodiment of the Shipping Rates Request Component ("SRRC"). In this instance, the client can get Shipping Rates from the Shipping Rates Partner by executing a shipping rate request queue from the Site Manager. The inquiry goes through the system (e.g. Shipping Rates Request Component), then through WebMethods shipping rates request service, and finally to the Shipping Rates Partner (e.g. GoShip™).

The Shipping Rates Partner sends its response back through the same system, and eventually reaches the end client. This occurs on-line "real time". The Client can then mark up/down the shipping rates for the Site via, for example, the Site Manager Tools. Fig. 29 illustrates an embodiment of the Product Catalog Update Request Component ("PCURC"), wherein new product catalog information is saved to the commerce database. In this instance, clients can remotely add (the same applies for subtracting and modifying products) products to the Product Database using Site Manager tools. This occurs by a client clicking on the add product catalogue update request queue, and filling in the appropriate fields and adding applicable content (i.e. description, price, sizes, pictures). Once the client executes this update request, the information is stored on the Commerce Database and is sent through product catalog update request service (e.g. the WebMethod's), who, in turn notifies the systems of the client's supply chain partners. Depending on the technology infrastructure of the supply chain partner, the updated catalog may take effect in "real time" or may require manual entry prior to taking effect. The invention provides robust flexibility to interface with and utilize a whole host of existing communications technology, whether the user/client/customer utilizes communication by FTP flat files or email, for example. In fact, very basic technology formats, such as XML transfers and NEDI transactions are accommodated by the system. The present invention is completely scalable. There are two types of scalability, horizontal and vertical. Horizontal scalability means you can add additional servers (breadth) and therefore more applications can easily be integrated into the system (e.g. wireless, PDA, Enhanced Television, content management, and supply-chain management capabilities). Vertical Scalability means you can add to the depth of existing components by offering more options and/or choices within the existing architecture without adding hardware or applications (e.g. larger product selection). The present invention is advantageous for at least its horizontal scalability. The system employs a structure using multiple NT Server platforms allowing the invention to be technology-ready for different applications as they become available (i.e. you can "plug" in content management, and supply-chain dc-240410 24 management software to the engine by merely coding the middleware and business rules while setting up the software on its own server). The invention is also advantageous for at least its vertical scalability. The NT architecture allows multiple databases to be added (as needed) and allows for the presentation layer to be enhanced by a branded solution (i.e. the transition from Managed Services to ASP to Private Label).

The invention's commerce engine is capable of performing functions off-line. Thus, the functionality permits such activity to occur without the user, e.g., customer, having to be actually sitting in front of their distributed network interfaced device, e.g., personal computer ("PC"). For example, the system performs its functions after the customer has placed his/her on-line e-commerce order, e.g., once they've hit the "buy" button, turned off their interface device monitor and walked away.

The present invention provides a unique solution to one of e-commerce 's major problem involving the increased dependency of on-line transactions and processes. Batch Ordering The invention provides for a highly flexible customer ordering system. The invention has the capability to process batches of orders in any range. For example, orders ranging from one at a time to thousands at a time in different formats, such as an FTE file can be processed. This batch ordering is a component of the overall e-commerce transaction system, which can operate off-line. The prior art on-line transactions occur in "real-time", i.e., single order by single order.

As illustrated in Fig. 23, the batch ordering processes support the system components, e.g., Authorization 2302, Fulfillment-Out 2303, Fulfillment-In 2304 and Payment 2305. Thus, the invention provides an operational and functional solution for how to communicate with each one of those components, e.g., functionalities, as opposed to any one specific component. The scenario that is most often played out in prior art systems in the performance of complex transactions, e.g., XML transfers and credit card on-line processing, is that they are actually simultaneously operating multiple software applications that must run at a secure level on a specific server which often results in system processing overload, i.e., system "crashes". In contrast, the invention permits vast amounts of e- commerce information processing, e.g., customer orders, to occur off-line which further provides substantial increases in e-commerce system reliability and "uptime" for user/client Internet sites.

dc-240410 25 The invention provides a ubiquitous approach to communicating and transmitting formatted data by allowing a data re-configuration, translation and conversion between formats. The prior art e-commerce engines have yet to implement such a formatting solution. This flexibility between formats is accomplished by the present invention. The system permits user/clients and ultimately the customers to go from email to XML, for

^• example. In other words, the invention seamlessly interfaces differing systems from the most basic to the most complicated. Therefore, the invention permits the user/client-base to be quite broad in industrial representation and sophistication of operations.

Instant Messaging System The system also provides for instant messaging to both the user/client and to the customer. If a customer's order is successful, i.e., the transaction has been completed, then at least two messages will be automatically generated and forwarded to the customer, e.g.

"Thank you for your order!" and "Your order has been shipped!"

Instant messaging provides a functionalized mechanism that acts as a layer that surrounds the engine that as orders pass from and into different stages of its lifetime, such as the phases illustrated in Fig. 23. Whether the ultimate customer gets a system generated message notification depends on the user/client's customer service objectives. For example, from the embodiment of the invention illustrated in Fig. 9, it can be seen that the customer is notified of: 1) his credit card being on a predetermined unauthorized list, 2) the denial of his credit card authorization ("CC"), 3) his order being placed in a hold status, and

4) the authorization of his order. Thus, the system permits the user/client to decide and tailor the temporal and substantive aspects of customer message notifications.

Accordingly, the system allows the user/client to tailor the messaging content and aesthetics. Thus, the user/client can determine what the message says and how it looks. Accordingly, the subject matter of the displayed content, as well as the presentation style, e.g., fonts, colors, etc., is a matter of design choice for the user/client.

Moreover, the instant messaging component allows the reporting, at different stages of the order process, the status of an order, as well as other relevant information that the user/client desires. If it is determined by the user/client that the customer should receive such messaging notifications, then the system generates and forwards the message. For example, in a successful transaction, only two messages: 1) order was placed and 2) order has been shipped, should preferably be sent. However, if the order transaction is not initially successful, different messages are automatically generated by the system and sent dc-240410 26 to the customer at some point during the attempted e-commerce transaction process. For example, if a customer attempts to use a credit card that is invalid, the customer will be notified of such information.

On the other hand, there are times when a customer will not be sent a message. For instance, when the order is actually sent successfully to the fulfillment center, e.g., warehouse, the center receives the order, however, the customer is not notified of this particular activity, although the order has progressed from one stage to another in the e- commerce transaction. Thus, the instant messaging component is highly tailorrable based upon the user's/client's customer service requirements. Hold Order System Component

The invention permits the user/client to realize e-commerce revenue that it might not otherwise obtain in the circumstance where there is an error generated during transaction processing. Under the prior art, this normally results in lost revenue for the user/client. With the invention, if there is an error, e.g., customer input or system processing error, an error message will be automatically generated by the system. Instead of removing the order from further processing, thus canceling or rejecting the order, the system will automatically place the order in a "hold" status, as in the embodiment of the invention illustrated Fig. 26, wherein the orders are being placed into the hold queue. Once "hold" status is assigned to an order, as illustrated in Fig. 22, and a notification of such is automatically sent to the customer. At this point, the invention allows customer service to be able to proactively remove or approve such hold orders. For example, if a customer's order is placed on hold because of an incorrect shipping address, e.g., customer typing input error, a customer service representative can review the order, correct the error and release the order. Here, a user/client customer representative can call the customer to have the order released. Such release from the hold status can be facilitated by obtaining a correct address or in the case of fraud threat, obtain another credit card, digital signature or required authorization level/method that has been pre-defined by either the user/client.

The system also provides fraud management. Therefore, in addition to screening and identifying errors, the system automatically screens and identifies potential customer transaction fraud. In one embodiment, a fraud rating level is automatically obtained from a payment authorization entity Fig.26, such as Cybersource™ and Visa®, customer, e-

Storefront manager, etc., Thus, the system allows pre-defined fraud levels to be dc-240410 27 determined. For example, an e-Storefront manager may set a quantity of 100 items and a total purchase of $10,000 as the limits above which a hold status will be assigned, as a measure to prevent fraud purchase activity. Thus, instead of many orders being rejected as being fraudulent, they are reviewed through the hold process of the invention. The prior art merely has a 'yes/no' alternative to suspected purchase fraud. Thus, the present invention allows these orders to be reviewed, along with the accompanying revenue realization which results from the successful "release" orders. Thus, the invention provides an automated comprehensively managed "hold" and "release" process for e-commerce retailers.

The system is a robust e-commerce management system which comprises flexible customer service applications, which enable electronic and their associated "real-world" transactions to be actively monitored and managed throughout the e-commerce process. In another embodiment, an e-Storefront manager monitors the status of customer orders and associated logistics and reporting activities. Further, a customer service representative can work on the "hold" orders and actively attempt to remove those orders from such a status. The system automatically and selectively, based upon user input, generates reports related to various subject matters; such as logistical, financial biometric, etc.

In one embodiment, the customer interface allows the user to receive a message notification informing her of the "hold" status, the reason for such status, and an authorized point of contact, e.g., a user/client call center phone number, to release the order. Thus, the system provides a means of automatic customer notification as well as access to a mechanism and a process to release an order in a delayed pre-determined or immediate manner. Further, the customer can obtain immediate notification and an instantaneous mechanism to fix a problem with the order. As stated above, the system also permits a call center, for example, to actively seek to resolve a problem by reviewing the customer order information, as well as our call center is actively calling on that hold system, releasing orders. In another embodiment, the customer may access the "Web" to check the status of her order, at which point, the options for releasing the order will be presented and outlined.

The system allows the user/client to tailor the required actions on part of the customer/e-Storefront manager/call center/customer service representative that are necessary to be accomplished in order to get a "release" for the order. In addition, the system allows an individual customer to pre-customize those required actions and options for releasing an order placed in the hold status. The system provides a process for

"release" that's defined by and for each customer. Further, depending on how aggressive dc-240410 28 the customer or the user/client wants to be, they can customize their fraud level. For example, a physical act may be required wherein the receipt of a customer/user/client generated document may be necessary to release the order, e.g., fax receipt. Cross-Selling System The invention provides a cross selling functionality where the customer is automatically presented with recommendations for other items or services that would compliment her past, present and future purchases. The system as illustrated in Fig. 30 combines two principal functionalities to produce a hybrid cross-selling system, wherein: 1) a user/client creates business rules, e.g., computer code executables, for cross-selling items, e.g., e-commerce retailer sets a laser printer as an automatic cross-sell item to the purchase of a personal computer ("PC") and 2) an automated software application which utilizes artificial intelligence ("Al") to automatically select and present the customer with logical complimentary items/service for purchase.

The prior art does not contain software development tools/programs/products that have the capability to intelligently increase customer selectivity of the user/client provided products/services/content. Neither does the prior art recognize the advantage of combining, i.e., integrating, hard-coded executable programs with artificial intelligence to create such a robust system and method of cross-selling.

Shopping Cart Calculation Functionality The invention allows a customer to calculate the total cost of purchase before inputting point of contact and shipping information prior to proceeding to checkout. In the alternative, the user can continue shopping once she provides such information. For example, if the customer provides partial information, the system automatically assesses that information and presents her with the option of calculating associated costs, such as domestic shipping and taxes, before proceeding to checkout if she has entered her destination zip code. Thus, the system actively monitors the data inputted by the customer and converts that data into increasingly valuable information upon which the consumer can be more accurately informed about the logistics and costs associated with her purchase. Fig. 18 illustrates an embodiment of the invention's shopping cart web page template.

Shipping logistics applications, such as GoShip, that provides a matrix of rates for multiple shipping carriers and methods of shipment (e.g. Next Day Air, etc.) in a grid system for an e-commerce shopper to comparatively shop based on different shipping dc-240410 29 prices. Additionally, their system will allow for the e-tailer to mark up/mark down displayed shipping prices from the back end. Checkout Process

The system provides a "checkout" functionality that automatically, selectively and in a user/client pre-defined manner direct, i.e. "pushes", the customer through the check out

. This is accomplished by eliminating choices and directing the customer towards the final order submission. Fig. 19 illustrates an embodiment of the invention's checkout web page template.

II. PRODUCT CATALOG MANAGEMENT The invention permits the management of a database "Product Catalog." The system and method allows users/clients, e.g., "Network Participants," to submit any of their products/services into the system, thus becoming a "Provider". Users/clients can also select, a la carte, any displayed product/service/content, whose profile/identifier information is housed in a database, and place it on their own Internet/web site, e.g., e- Store front, thereby becoming a "Reseller." The invention's system and method manages the Product Catalog and provides updates to the all Reseller sites.

III. CONTENT CATALOG MANAGEMENT

The invention permits the management of a database "Content Catalog". The system and method allows users/clients, e.g., "Network Participants," to submit any of their Content, e.g., text, streaming video/audio, graphics, games, pictures, into the system, thus becoming a "Provider". Users/clients can also select, a la carte, any displayed Content and place it on their own Internet/web site, e.g., e-Store front, thereby becoming a "Licensee." The invention's system and method manages the Content Catalog and provides updates to the all Licensee sites. IV. SERVICE CATALOG MANAGEMENT

The invention permits the management of a database "Service Catalog." The system and method allows users/clients, e.g., "Network Participants," to submit information regarding any of their services to the system, thus becoming a "Provider". Users/clients can also select, a la carte, any displayed service, whose profile/identifier information is housed in a database, and place it on their own Internet/web site, e.g., e-

Store front, thereby becoming a "Service Facilitator." The invention's systέm and method manages the Service Catalog and provides updates to the all Service Facilitator sites.

dc-240410 30 Various preferred embodiments of the invention have now been described in fulfillment of the objects of the invention. While these embodiments have been set forth by way of example, various other embodiments and modifications will be apparent to those skilled in the art. Accordingly, it should be understood that the invention is not limited to such embodiment, but encompasses all that which is described in the following claims.

dc-240410 31

Claims

We claim:

1. A method of designing an e-commerce web site, comprising: gathering information from a user that facilitates the creation of the web site; creating a customized interface for the web site with elements based on the gathered information; and defining the functionality of each of the elements.

2. The method according to claim 1 , wherein gathering includes a non-branded template provided to the user for inputting the information.

3. The method according to claim 1, further comprising: customizing the customized interface by defining each of the elements such that the elements are modified to identify specific needs of the user; reviewing the customized interface to ensure that each page of the customized interface functions properly and that each page functions with each other page; and launching the web site to test the functionality for a specified amount time.

4. An system for designing an electronic storefront, comprising: a template to store the physical layout of elements on the electronic storefront; a creative treatment applied to a corresponding element to define the appearance of each element in the template; and a software development unit to define the characteristics and functionality of each element in the template based on the creative treatment applied.

5. The system according to claim 4, further comprising: a database storing products and/or services content to be displayed on the electronic storefront.

dc-240410 32

6. The system according to claim 4, wherein the electronic storefront created by the system allows each component to be created, developed and modified independently from each other.

7. A computer readable medium having instructions thereon, the instructions performing the function of: gathering information from a user that facilitates the creation of the web site; creating a customized interface for the web site with elements based on the gathered information; and defining the functionality of each of the elements.

8. A method of creating an electronic storefront that is customizable, comprising: providing templates to be selected by a user, the templates including elements that are customizable; providing objects and functions associate therewith to enable the user to customize the elements; mapping the elements in the templates to the corresponding objects and functions.

dc-240410 33