WO2000050968A2

WO2000050968A2 - New media electronic commerce (nmec) system and method

Info

Publication number: WO2000050968A2
Application number: PCT/US2000/004789
Authority: WO
Inventors: Paul E. Jaquish; Viet A. Nguyen; Mark K. Webster
Original assignee: Internet Plus, Inc.
Priority date: 1999-02-26
Filing date: 2000-02-25
Publication date: 2000-08-31
Also published as: EP1399859A4; WO2000050968A3; EP1399859A2; AU4004100A

Abstract

A system and method to conduct electronic commerce not necessarily over the Internet has a plurality of individual consumers, network groups of consumers, and a server (Fig. 1) (22, 34). The consumers receive a distributed computer-readable medium having: a pre-stored interactive database of product information of a plurality of products; (Fig. 2) (22, 52) and predetermined software for performing graphic-user-interface-based review, selection, and order processing by a respective consumer of selected products from the pre-stored interactive database to generate the pre-stored order stored in the respective computer of the respective consumer (Fig. 33). The predetermined software is installable on a computer associated with a respective consumer. The predetermined software is installable on a computer associated with a respective consumer, with the predetermined software isolated from and not in constant communication with the Internet. The server includes a communications module with electronic communication connections to a computer of a consumer and receiving the pre-stored order therefrom, and an order-processing module for processing the transmitted pre-stored order for product fulfillment.

Description

NEW MEDIA ELECTRONIC COMMERCE (NMEC) SYSTEM AND METHOD

BACKGROUND OF THE INVENTION The present invention relates to electronic commerce (E-commerce) applications, and more particularly, to a method and system for electronic commerce to be conducted at high processing speeds using computers unconstrained and uninhibited by network communication constraints.

Electronic commerce appears to have endless potential, yet the earlier application of Electronic Data Interchange (EDI) has already given way to the World Wide Web (WWW, also known as the "Web" or "web") and the Internet (also known as the "Net" or "net"). Despite their many benefits, the web and Internet are not the total answer for electronic commerce. The web and Internet are often considered to offer a level playing field because they offer widespread access to basic features and most everyone can afford the access.

Simply because these tools are designed to provide basic features to mass audiences, they will not work for the more sophisticated applications. The web Internet problem is rooted in the fact that all electronic commerce is not equal. In some business-to-business applications, electronic commerce simply cannot be conducted with continuous connection across a communications network extending for hours or days. In a similar manner, some electronic commerce applications involving shopping can not be supported with the constraints resident on the World Wide Web and the Internet.

Businesses choose efficiency every time; consumers choose convenience every time. And they're both willing to pay for it. Wired communication was the height of speed and convenience until wireless came along. E-commerce on the web was the height of speed and convenience in the prior art, but existing disadvantages described herein are prevalent in the prior art. Although the operational problems or service limitations created by the WWW and the Internet are similar for both business-to-business and business-to-consumer, the scope and clarity of the problems are more easily understood by examining consumer electronic commerce. This is where the problems become most visible.

High-end consumers want the convenience of Internet commerce but with richer images, faster connections, greater efficiency, and greater security of information. Vendors want the low fulfillment cost of the Internet, but with less risk of counterfeits, more precise targeting of consumers, protection from bargain hunting, and more control over the selling environment.

Sellers commonly encounter the following barriers to selling on the web: bandwidth limits the use of powerful graphics, audio and video sales presentations; consumers can easily get sidetracked to competitors; counterfeit merchandise is easily sold to unwary consumers; and the web limits the amount of interaction with consumers. Consumers commonly encounter the following barriers to purchasing on the web: poor graphics and color display prevent detailed inspection of products; web site or Internet Service Provider is often slow, down, or breaks connections; product offerings are not tailored to meet the consumer's personal tastes; personal and credit card information is exposed on the web; vulnerability to the "dark" side of the web, such as accidentally encountering unpleasant content, con artists, counterfeits and viruses; and intimidation, such as how most affluent consumers are intimidated by PCs, particularly the World Wide Web, and are too busy to get beyond the intimidation.

Sellers and consumers both need a solution for those people who, for their own reasons, do not use the Internet access to web sites. These needs manifest themselves in today's very competitive business environment. The marketplace, companies, manufacturers and retailers are looking for different approaches in internal business applications as well as to reach new consumers and increase sales to existing ones. While the Internet may have been intriguing to them, the World Wide Web and Internet are often disappointing in their ability to actually perform services and sell product.

There has been a need to conduct business more effectively, identify new consumers, provide content in a way that will stimulate more business purchases and then provide an efficient mechanism to receive and fulfill orders. In summary, businesses in general, and manufacturers and retailers in particular, are looking for new ways to find additional consumers and increase profits.

Electronic commerce will continue to grow rapidly. As Internet and web- based commerce matures, however, a demographic/marketing shift will occur in online audiences. More traditional audiences, people with little interest in technology, who simply want a more convenient, orderly and sane way to e-shop with ease, will continue to resist coming online. Electronic commerce is changing to require a refashioned mix of old and new media technologies, creating new digital channels and marketing tools.

At present, competitive forces are pushing technology on consumers and requiring them to climb the learning curve and become more technically/computer savvy before they can shop with ease. Because of this approach, the existing E- commerce audience consists of people who are very experienced at computer use and web navigation.

A need exists for an E-commerce system to target all audiences. In traditional electronic commerce, web sites and portals fall into two basic categories. The first are the "successful," though not necessarily profitable, entities which sell commodity type items, such as books, music CDs, flowers, videos and airline tickets. These web sites focus on items that are considered pre-sold in the minds of their viewers and are mostly low priced items that do not require high bandwidth to sell. A typical consumer may have already decided to purchase the latest music CD and doesn't care about the source as long as they get the lowest price.

The second group of web sites and portals are non-commodity retail sites. These include mostly computer sales sites and syndicated electronic shopping malls. Again, consumers are pre-sold, know what type of computer they want, usually have a brand or style preference, and select items based on price alone. Electronic shopping malls are indirect competitors but are not very successful because they must focus on low price items and products that sell well via low bandwidth and must advertise heavily to draw traffic.

As broadband becomes more readily available, many of these web sites will not be able to provide expensive broadband content and will drop out or simply continue to provide narrowband content. Those who can, will have to play catch-up to systems which have developed faster-than-broadband, richer-than-web content with superior distribution channels for far greater security.

Paper catalog commerce using paper catalogs have had a recent resurgence and direct marketing sales revenues are growing at a rate of 7.8% annually (Direct Marketing Association 1998, Economic Impact: U.S. Direct Marketing Today). While paper catalogs represent competition, they can be more expensive to produce and distribute than a CD-ROM, are mostly limited to direct mailings, and do not provide a multimedia shopping experience. Additionally, paper catalogs generate higher order processing costs, with a high rate of order entry mistakes and cannot be electronically updated to reflect pricing and availability changes. In today's very competitive marketplace, sellers are looking for a different approach to reach new consumers and to increase sales to existing ones. While the Internet may be intriguing to them, it is often disappointing in its ability to actually sell product. Traditional printed catalogs are expensive and not interactive like E- commerce. There is a need to identify new consumers, provide content in a way that will stimulate purchases and then provide an efficient mechanism to receive and fulfill orders. In summary, manufacturers and retailers are looking for new ways to find additional consumers and increase profits.

SUMMARY OF THE INVENTION A method and system are provided for electronic commerce to be conducted at processing speeds using computers unconstrained and uninhibited by network communication constraints. The invention utilizes application software that interacts with database files on a consumer's personal computer, and does not require a browser as all Internet-based electronic commerce services do. The new system eliminates the need for browsers and eliminates the need for an Internet Service Provider (ISP). Because the new system is totally different than web-centric electronic solutions, it is a new media for electronic commerce.

Both business-to-business and business-to-household electronic commerce applications benefit from this new system which should be characterized as a new electronic media because it brings together the best features of Internet, television, and catalog shopping to create operational or sales channels that provide faster connections, faster processing, richer product presentations and greater security. This combination of features is unique and makes for a convenient, rewarding and safe e-shopping experience free of cyber delays, disconnects, clutter and fraud. The latter four are all common elements of Internet-based electronic commerce and nonexistent in this invention of new media which throughout this discussion will be referred to as the New Media Electronic Commerce (NMEC). The NMEC provides the same benefits for business-to-business electronic commerce as it does for business-to-household electronic commerce. Benefits of NMEC include: permitting database interaction at high speeds, avoiding extended Internet delays; avoids line contention and line drop; eliminating the need for continuous connection to a server; permitting full integration with personal processor, LAN, WAN or intranet- resident programs; distributing by any media especially direct mail to targeted individuals; proactively capturing new users and consumers; reducing by two-thirds the acquisition cost of traditional E-commerce consumers; doubling sales over paper catalogs; outselling typical web sites by four to ten times; benefiting from 100 % feedback to fine-tune future selling; utilizing a global virtual private network for consumers without ISP access; offering a syndication of sellers with a controlled selling environment; and creates a venue for presenting products in an intimate, persuasive and entertaining manner. NMEC is a new media for special business applications. These applications often require user interaction throughout the day. Browser-based Internet applications cannot support the ongoing, extended interaction that's required, because lengthy Internet connections are so prone to line loss, data loss, and associated delays. Applications requiring full motion video, sound and fast interaction are supported perfectly by NMEC and are virtually impossible to support via Internet. In comparison to traditional E-commerce and paper catalogs, NMEC's system allows manufacturers and retailers to successfully sell the many products that currently under-perform using web sites, achieve low cost fulfillment, with better control over the selling environment, including more precise and highly-targeted marketing that leads to increased sales and profitability. The NMEC invention combines proven technologies in a new way and achieves performance that is far superior to the World Wide Web and the Internet.

The NMEC system allows manufacturers and retailers to successfully sell the many products that currently under-perform using web sites. Typically, they under- perform because the Internet and WWW cannot support the level of graphic detail required to make the sale. Manufacturers and retailers may also achieve the low cost fulfillment of the Internet, but with better control over the selling environment, including more precise and highly-targeted marketing that leads to increased sales and profitability. This advantage is illustrated by the elimination of the single greatest complaint about WWW shopping. Web sites all too often allow consumers to order items that are not in stock. Published reports state that the number one complaint of web purchasers is that an item is out of stock. NMEC eliminates this problem by keeping a running inventory and when a consumer launches an NMEC session the application automatically dials out, accessing the server and downloading a small data file which will lock out any out-of-stock product so that it can not be seen. Because it can not be seen, it will not be ordered and the consumer will not be disappointed. Rather, the consumer will be satisfied with the buying experience because the NMEC store or service will always have what they want. Manufacturers and retailers can also serve the majority of shoppers who are not technically-sawy web users and will not buy on the web because of the complexity and confusion of an overcrowded "dot com" marketplace. NMEC users are not intimidated and have the benefit of knowing that the CD or electronic transmission came from a trusted third party and is free of fraud and fake products. Better yet it is easy to use, requiring no special knowledge of computers.

Manufacturers and retailers also increase brand awareness in addition to increasing sales as a natural by-product, because NMEC syndicates compatible brands. The closed nature of a syndication brings similar and compatible products together, again, giving the consumer a certain sense of satisfaction that is not found on the web.

While electronic commerce in general and the Internet/web specifically, manufactures and retailers in the prior art are limited to electronic distribution, but the NMEC is not limited and can be distributed in a highly targeted fashion to specific individuals. While Internet companies build large sites and wait for consumers to find them, NMEC can, through list processing, target individuals and mail or send electronically to each individual. This feature extends to the possible situation where each consumer views slightly different merchandise and has different pricing. Presentations are based on very detailed information collected about the consumer, as the consumer makes selections, places orders, and indicates preferences: a feature which is impossible via the Internet and WWW.

The NMEC invention disclosed herein includes numerous benefits, such as combining highly specialized software to provide the power of a virtual private network or, in the alternative, the Internet, and available distribution technology including optical or electronic. The NMEC system offers sellers of specialty goods convenience that surpasses Internet commerce plus increased revenue and profitability. It creates a powerful union: the speed to convey a sophisticated mix of audio, video, graphics and other information offline and the connectivity and convenience to electronically transact business over the Internet or a virtual private network on-line.

NMEC is a complete selling solution that is easy for consumers to use and profitable for sellers, utilizing highly-targeted distribution to individuals via magazines and other direct marketing vehicles. The NMEC invention also targets a different demographic. Some of the target demographic includes: inexperienced computer and Internet users who will not do business or buy on the web because of the complexity and confusion of an overcrowded "dot com" marketplace. Other demographics, such as those who are more computer-sawy, are also well served by NMEC's attention to convenience, speed, and quality of presentation.

Heretofore, the prior art failed to provide the elements, features, and benefits of the disclosed NMEC system and method, since changed circumstances and timing are the tangible elements leading to the creation of the New Media Electronic Commerce invention. The PC market share increase and particularly the number of PCs with CD capability has increased significantly in the past three years. The use of CDs has expanded rapidly exceeding two billion per year. Purchasing of goods and services electronically is now widely accepted and the notion of enhanced electronic services extending E-commerce still further is reinforced by the capital commitments for E-commerce being made by industries.

In addition, the heightened expectations for Internet and web site E- commerce, along with the false notion that the web and Internet are the end-all/be-all answer for E-commerce, have produced many failures of high-end web sites. The failure in progress and/or widespread use and adoptions of the thin client machine, which was anticipated as the replacement for the personal computer, has added to the broader failure of the web and the Internet. Again, thin client developers assumed also that the Internet and web would be the end-all/be-all for E-commerce. The thin client machines would have had to be connected to the Internet and a web site continuously. Clearly, this logic failed to generate a success of the thin client. Failure of ubiquitous broadband has added still further to the Internet web problems. A study by Xiawei Yang at M.I.T. published in Scientific American in October 1999 demonstrates that, based on the speed of light and network processing times, there is a fundamental limit to how fast a complex web page can load from a remote server. For example, a graph shown on page 98 of the October 1999 issue of Scientific American illustrates such higher-speed access. Even if heroic efforts by telecommunication companies over the next five years succeed in reaching most consumers with broadband (which is unlikely), the complex page load time will still be 6-9 seconds. Even infinite bandwidth will not get loads below about 6 seconds.

The perception of time affects consumer behavior and attitude toward use of technology, including E-commerce systems. For example, one can try counting out 6 seconds (1001, 1002, 1003...) and see how long that is. If consumers had to go through half a dozen screens that took 6 seconds each, shopping would not be enjoyable and they would give up. To reach the desired one-second load times requires a local program with local data.

PC performance doubles about every 18 months, making PC-based shopping ever more efficient and enjoyable for the consumer. The Internet can never match this level of performance. During the years or decades needed for broadband to reach 6-9 second load times for the average consumer, local PC speeds will increase at least 4-8 times beyond the current speed. Fundamentally, increasing bandwidth cannot make Internet multimedia shopping a pleasure.

Still another failure of the prior art is that of interactive TV. At one time the press was filled with promises of set top boxes and interactive TV E-commerce. The lack of standards, the high cost and the failure of industry to demonstrate ease-of-use has resulted in interactive TV going nowhere. The combination of PC survival and the failure of the Internet and web to meet expectations created the opportunity for rethinking how E-commerce should be conducted. That thinking has led to the realization that there is likely no single perfect solution, rather several solutions whose performance characteristics match the particular E-commerce requirements.

NMEC is focused on higher price, specialty items presented in a rich multimedia format at local processor (six times faster than broadband) speeds. Additionally, the NMEC method of reaching consumers is proactive. Unlike web sites, it finds consumers instead of requiring heavy advertising spending and waiting patiently for consumers to find the web site.

NMEC is a byproduct of pooled intellectual resources seeking a solution that recognizes needs not served by the existing E-commerce technologies.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates the disclosed new media E-commerce (NMEC) system;

FIG. 2 illustrates an example architecture of the NMEC system of FIG. 1;

FIG. 3 illustrates relationships between dialogs and other objects;

FIG. 4 illustrates a framework for dialogs;

FIG. 5 illustrates operation of a Start Up dialog; FIG. 6 illustrates operation of a Start Shopping dialog;

FIG. 7 illustrates operation of a Product dialog;

FIG. 8 illustrates operation of a Shopping Bag dialog;

FIG. 9 illustrates operation of a Current Order dialog;

FIG. 10 illustrates operation of a User Profile dialog; FIG. 11 illustrates operation of an Industry Specific dialog;

FIG. 12 illustrates operation of a Program Settings dialog;

FIG. 13A illustrates a flowchart to process a purchase; FIG. 13B illustrates an order process;

FIG. 13C illustrates an automatic update procedure;

FIG. 14 illustrates a process order procedure;

FIG. 15 illustrates a cancel order procedure; FIG. 16 illustrates a return order procedure;

FIG. 17 illustrates an update order procedure;

FIG. 18A illustrates a check order status procedure;

FIG. 18B illustrates a tax request procedure;

FIG. 19 illustrates an update check procedure; FIG. 20 illustrates a product database update procedure;

FIG. 21 illustrates of a server product database update procedure;

FIG. 22A illustrates an installation procedure;

FIG. 22B illustrates application startup events;

FIG. 23 illustrates a welcome screen; FIG. 24 illustrates a quick start message screen;

FIG. 25 illustrates a search screen;

FIG. 26 illustrates a shopping bag screen;

FIG. 27 illustrates an alternative search screen of FIG. 25 with thumbnail images of products; FIG. 28 illustrates a product page;

FIG. 29 illustrates the product page of FIG. 28 with a menu for user selections;

FIG. 30 illustrates a window displaying a video or slideshow;

FIG. 31 illustrates another product page with a magnified view of a product; FIG. 32 illustrates an alternative version of the shopping bag screen of FIG.

26 with purchase information; FIG. 33 illustrates a search screen as in FIG. 27 with a menu for options selection;

FIG. 34 illustrates a user profile wizard screen;

FIG. 35 illustrates a view/alter order screen; FIG. 36 illustrates the view/alter order screen of FIG. 35 with order status; and

FIG. 37 illustrates an industry-specific screen.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now to FIG. 1, the NMEC system 10 and method of operation are disclosed which implement a business method for E-commerce applications. The NMEC system 10 includes an NMEC server 12 and a distribution server 14, which may be an IBM server. FIG. 1 shows the flow of information between key participants in the NMEC system 10 during the order generation and fulfillment process. Activity is centered around the NMEC server 12 and the IBM server 14. NMEC users 16 from all channels send orders and queries via the Internet 18 or dialup connection to the NMEC server 12.

The NMEC server 12 sends the user orders and queries to the IBM server 14, which distributes information to the merchant bank 20, vendors 22, fulfillment houses 24, export expediters 26, and shippers 28. When the IBM server 14 receives messages back from the merchant bank 20, vendors 22, fulfillment houses 24, export expediters 26, and shippers 28, the IBM server 14 relays the information, usually via E-mail, to the appropriate party, most commonly back through the NMEC server 12. Consumer support 32 E-mails requests travel from the user through the Internet 18 or dialup connection, to Consumer Support 32; E-mail responses return via the same route. Vendor Support 34 messages may travel directly between Vendor Support 34 and the Vendors 22 or they may travel through the NMEC server 12 and the IBM server 14. In addition, the merchant bank 20 may be connected to other institutions such as an issuer bank 36. The NMEC server 12 generates usability and question/answer (QA) data 38, as well as marketing data 40 which are provided to supply or supplement product development and updates 42 in conjunction with such developments and updates from other sources 44.

The NMEC 10 of FIG. 1 has a client/server architecture as shown in FIG. 2, with four main modules: a client module 46, a communication module 48, a server module 50, and a database module 52. The client module 46 provides the application user interface, by which the user 16 can browse and view items from one or more vendors 22. The user can also search for a particular item by category, price, style, etc... by selecting the desired items and putting them in a shopping bag, user can change the quantity, size, color, and/or other options before committing to purchase. During this time, the client does not need to connect to the Internet 18. The application will automatically make the connection to a server in a server farm 54 for a very short time when the user decides to purchase the items. The server module 50 and servers in the sever farm 54 a component of the NMEC server 12 and may be connected to or incorporate a firewall 56.

The client regularly queries a server 54 to get the latest availability information. That information is updated in the client's product database stored in the database module 52, having a database server, so that unavailable products are not offered. The client can also request order status, cancel orders, initiate order return, or change the order. All user information such as name, addresses and credit card info will be stored locally on the user's machine, to avoid security risks. The communication module 48 is the medium for data communication between clients 46 and server 50. It uses a highly secure and reliable Virtual Private Network (VPN) to accomplish the task. The user does not need a user name or password to access the system. The VPN is only accessible to NMEC clients. The server module 50 is the main contact mechanism between client and server 54. The client sends order requests to the server through the communication module. The server 50 processes the requests such as credit card verification and interfaces with different vendor servers for product fulfillment and shipping. The server 50 sends information back to the client (and, in turn, to the consumer) regarding the results of the transaction.

The server module 50 includes various specific server types, used to carry out a variety of functions, such as business/accounting server 58, database server 52, backup server 60, etc. The collection of specialized servers is called a server farm 54. The database server 52 interfaces with the vendor servers of the vendors 22 to keep the product database in the database sever 52 current, for example, through product data entry 62. The database module having the database server 52 is designed to handle all database operations between client and server 54.

THE CLIENT MODULE

On the client side in client module 46, there are two databases: a user database and a product database. The user database stores all personal information, such as name, billing and shipping addresses and credit card info, as well as all order histories and other valuable information. The product database stores information about all products available for purchase, including description, price, size, color, image, video and audio. The product database resides locally on the client, rather than remotely, to reduce load time of data and images. On the server side, there are two databases: a journal database and an audit database. The journal database keeps track of all of a user's orders, and the audit database keeps track of all server activities.

Each server 54 and the server module 50 is configured behind a firewall 56 for security reasons.

The client module 46 has the following features: consumer entry points to initiate the shopping process; processes are initiated by keyboard, mouse and/or voice; the ability to work off-line, without a permanent Internet connection; the client module 46 does not require an Internet browser or an

Internet Service Provider (ISP); the client module 46 avoids unnecessary web browsing; the client module 46 connects to communication medium through Virtual Private Network (VPN) protocol when ready to purchase, with a communication session being very short; high level of security, through VPN; and the ability to use a modem on the client machine. All personal information (name, credit card number, billing address, etc..) is stored locally. The product database is distributed to the client physically by CD-ROM,

DVD and/or any available, transferable, and/or portable storage medium including optical or electronic. The product database is also available electronically, through download to the user's computer having the client module 46 from the server module 50. Each client accesses the product database directly from the distributed medium or copies the product database to the client computer hard drive for faster access time. All multimedia (3D, picture and sound) are stored and played locally, and the client module 46 saves a record of selected items to be purchased later, prints the order, sets up an account for payment, cancels orders, returns items, and sets up user profile and stores information locally. There is no need to re-enter user information each time a purchase is made. The system 10 provides intelligent search capabilities: by price, by season, by brand name, by size, by occasion, by style, etc. Items can be viewed in 360° presentation.

The NMEC client application implementing the client module 46 is designed to run on a single computer running on most popular platforms. The NMEC client application may be distributed in many ways, including DVD, CD-ROM, broadband, and other available optical or electronic service options available. Users will have the options of installing all application components, recommended components, or a minimum set of components required to run the application. The merchandiser product database can reside on the storage medium (such as DVD) to save hard disk space, and still be accessible by the program. For better performance, however, it is recommended that the entire application be installed on the hard drive.

In an illustrative embodiment, the platform for the NMEC system 10 may include the "MICROSOFT WINDOWS" (PC), "APPLE MACINTOSH" and "LINUX" computing platforms. The NMEC application may be developed using programming languages such as C++, C, Visual Basic, Java or any other object- oriented language.

The distribution medium may be a CD-ROM, a DVD, or computer files downloadable from a server.

Regardless of the development language or desired platform, NMEC client application architecture employs the modularity, flexibility and scalability of the 3- tier design methodology. The NMEC application implementing the system 10 has application layers with communication between layers through their appropriate interface modules.

In Layer- 1, the presentation layer provides a user interface (UI), which is a collection of dialog objects, called a dialog module, where each dialog object represents a specific UI to interact with the user. In Layer-2, the data layer, data objects are supported. In Layer-3, the database layer, database serves are provided.

The dialog module for the UI is constructed using customized modern "WINDOWS" UI components such as dialog windows, list boxes, combo boxes, list views, tree views, buttons, etc. As shown in FIG. 3, each dialog 64 has one or more data objects 66 associated with it, which in turn are associated with database objects 68 for storage and retrieval of the data objects.

Dialog boxes are windows used to display status information or to obtain information from the user. The user uses dialog boxes to have a "dialog" with the application. Dialog boxes contain common components such as edit boxes, pushbuttons, list boxes, combo boxes, tree controls, list controls, and progress indicators.

Most dialog boxes are modal, meaning the user can interact with only the dialog box (and no other windows or screens) while the box is open. But, it is possible to create modeless dialog boxes, which let users work with other windows while the dialog box is open. Most of the time, the NMEC application utilizes modeless dialogs.

The user interface (UI) is the main interface between the user and the application. It allows the user to execute and carry out all the actions that the program is designed to do. All dialogs are integrated and functionally related to each other to allow users to accomplish program functions: setting up a personal profile, selecting items to buy, viewing the items, and purchasing the selected items. The application is designed using Single Document Interface architecture. This means that only one document (a dialog) is presented to the user each time the user chooses to perform a particular action. There will be no more than one dialog overlapping another, thus avoiding confusion and providing a cleaner and easier-to- use UI.

All dialogs are housed in a framework called Document/View Architecture, such as shown in FIG. 4. This framework handles all the commands when the user interacts with the application through keyboard or mouse inputs. For example, when the user clicks a button to purchase the selected item, the framework will intercept the mouse click action and notify the application of this action. The application's logic will analyze the mouse click action and route the message to the appropriate method in the program to perform associated action. All other user inputs are carried out in the same logic as described in the example above.

The Document/View Architecture of FIG. 4 provides a coherent framework for managing the application's data and UI. The fundamental concept of this architecture is the separation between an application's data, represented by a document object, and the views that can exist of this data. Each view is responsible for managing one visual presentation, or rendering, of the data of its associated document. Each main window framework 70 acts as a container for all dialog objects 72. The dialog objects conduct main entry for all user interaction with the NMEC application. The dialog object resides within the framework, acting as children inside the framework container. All input messages from the user are routed through the framework to the dialogs. Only one dialog is displayed at a time to perform a particular function. At run-time, the dialog is shown in a maximized state, to occupy the full screen, thus giving users the impression that there is only one dialog present. The dialog 72 shown inside the container 70 provides a visual view of the container

(parent)/dialog (child) relationship.

In a common implementation, each dialog consists of one or more data objects. When collecting information from the user, data are stored in the appropriate objects. To store info in the database, the data objects are passed to the

Database Service object to be processed. Results may be storing data to the database or querying for additional information. When requesting information to be presented to user, the Database Service object will perform database queries on the request. It fills the data objects with the information then passes these objects to the dialog. The dialog reads and retrieves info from the objects that were sent by the database object and displays the information to the user. All dialogs in the NMEC application follow this same inter-communication method.

The documents described herein uses an example case of the StyleSource

NMEC application, to help illustrate the invention. StyleSource is a single implementation of a NMEC application, which happens to be designed to sell women's fashion products.

In the example case, there are eight main dialogs implemented as view objects in the StyleSource application: Start up, Shop, Product, Shopping Bag, User

Profile, Order Info, Fashion World, and Program Settings. The operation and implementation of each dialog object is described in detail herein.

START UP DIALOG In operation, as shown in FIG. 5, this dialog appears every time the application is started. Its purpose is to display a welcome image, to inform the user that the application will be starting very shortly. As soon as the application starts, this dialog disappears and the user can start using the application. The dialog also contains a multimedia video player capable of playing video in Audio Video Interleave (AVI) format. The video may be a welcome video clip from a vendor the very first time the application is launched. From then on it might only show the welcome image on the subsequent launches. The implementation depends upon vendor and consumer preferences. The user has the option of stopping the video at any time by clicking a button on this dialog to stop the video and go directly to the application. If the user lets the video play to the end, the video will disappear and the user can start using the application.

In implementation, when the application starts, it queries the computer's registry to determine if this is the new installation of the application. If it is, it will instantiate an instance of a multimedia control and attach this control to the dialog to allow playing the video.

The application also queries the computer's registry to determine the location of the video file installed on the user machine. It will use this video file with the multimedia control to play the video. Where desired, the application then writes to the computer's registry to change the video flag from Yes to No. This action will prevent the video from being played again on the subsequent launches.

Then, if it is not the very first time the application is started, the application will query the computer's registry to determine the location of the startup image file installed on user's machine and display the image. The application will not modify the registry.

When the application is ready, it will destroy the Startup dialog object and show the main application screen, starting with the Shop dialog.

SHOPPING DIALOG

In operation as shown in FIG. 6, this is the main dialog where the user can shop for and/or search for products. The type of searches available depend upon the type of products being offered. In the example case, the user searches by fashion brand names and categories. Brand names are designer names such as Gucci, Calvin Klein, Giorgio Armani, etc.... Categories are types of items, such as Women's Attire and Accessories. Under each category are sub-categories, such as Dresses, Coats and Skirts under the Women's Attire category.

If the user rests the mouse cursor on a brand name, a picture representing that brand name will appear for the user to view. If the user rests the mouse cursor on a clothing sub-category, a picture representing that sub-category will appear for user to view. This browsing capability provides user instant feedback and creates a sense of connectivity between the user and the application.

There are two ways to browse and search from this dialog: Categories and Designers. In browsing by Designers, one clicks on a brand name, and the application will display the thumbnail images of available items from that designer. If "All Categories," under the Categories section is selected, all items in all categories belong to the selected designer will be shown as thumbnails. If a sub- category item is selected, only items from that subcategory will be shown.

In browsing by Categories, one clicks on a sub-category, and the application will display the thumbnail images of available items of that sub-category. If "All Designers," under the Designers section is selected, all items in the selected sub- category for all the designers will be shown. If a particular designer is selected, only items for that designer will be shown.

The thumbnail images will be shown as a set of zero (0) to five (5) images each time the user selects to shop, either by Categories or Designers. This limitation is due to the screen size and thumbnail images sizes. If there are more than five items, the thumbnail section will automatically display the "Next" button to inform the user that there are more images. When the user clicks on the "Next" button, the next set of thumbnail images is shown and, at the same time, a "Previous" button also appears to inform users that they can view the previous images by clicking the "Previous" button. This is the main navigation method for the thumbnail image section.

To view more detail for a product, the user clicks on a thumbnail. This action prompts the application to display the "Product Dialog" and hide the current Shop dialog.

In implementation, on starting up this dialog, the application performs the following steps:

1. Build the Categories section - the application queries the product data base and builds a list of sub-category objects. This list is used to create a tree control and display all sub-categories under the "All Categories" section of the dialog. It associates each sub-category object in the list with sub-category item text in the tree component.

When the user moves the mouse over the sub-category text, the framework will detect the mouse position and send a message to the application. The application receives the message and extracts the sub-category object associated with the sub-category text that the mouse is resting on. In this object is a property parameter that points to the path of the location of the image file associated with the sub-category. The application then uses this image file to display the image. This operation occurs whenever the mouse is over any of the displayed sub- categories.

2. Build the "All Designers" section - the application queries the product database and builds a list of Vendor Info objects. This list is used to create and display the logo images of all designers under the "All Designers" section. It associates the appropriate Vendor Info object from the list with its corresponding logo image. When the user moves the mouse over the logo, the framework will detect the mouse position and send the message to the application. The application receives the message and extracts the Vendor Info object associated with the logo that the mouse is resting on. In this object is a property parameter that points to the path of the location of the image file associated with the logo. The application then uses this image file to display the image.

This operation works whenever the mouse is over any of the displayed designer's logos. If there are more logo images, the application will enable the "Next" button to inform the user that there are more available logo images to browse.

3. Build the Thumbnail Images Section - when user clicks on a logo image, the framework detects the mouse click action and sends the message to the application. The application receives the message and extracts the Vendor Info object associated with the logo that the mouse has clicked on. In this object the application will retrieve two parameters: the Vendor ID and the Brand ID values.

The application also determines from the "All Categories" section which sub-category was selected or highlighted. If none-of the sub-categories are selected, it assumes the user wants to show all categories. If a sub-category is selected, the application will extract the sub-category object associated with this sub-category. In this object the application will retrieve two parameters: The Category ID and the Sub-Category ID.

Using the four parameters Vendor ID, Brand ID, Category ID and Sub- Category ID the application will query the product database to retrieve a list of all the products that meet the criteria. Each product record is stored in an Item Info object and each object is stored in the list.

Upon finishing building this list, the application will call a method and pass in this list to build and display the thumbnail images in the Shop dialog. The function of this method is to extract each Item Info object from the list, retrieve the image name and path and display them as a set of from zero (0) to ten (10) or more thumbnail images each time.

If there are more than ten or more images in the list, the application will automatically enable the "Next" button to inform the user of more available thumbnails to view. When the user clicks the "Next" button, the application will again retrieve from the list the next five images to display and at the same time enable the "Prev" button to inform the user of the ability to display the previous thumbnail images. The application also checks if there are still more images. If not, it will disable the "Next" button to inform the user that there are no more images to view next. When use clicks on the "Prev" button, the application will retrieve from the list the previous five images to display. It will also check if there are still more previous images. If not, it will disable the "Prev" button and enable the "Next" button.

The application will associate an image ID and Item Info object to each displayed thumbnail image. This information will be used when the user clicks on the thumbnail image to go to the product dialog.

PRODUCT DIALOG

In operation, as shown in FIG. 7, this dialog allows the user to see a more detailed description and image of the item. It appears when the thumbnail image of the item is selected. Other information is typically presented. In the example case, such information includes description, price, quantity and available color and sizes. The quantity, color and sizes may be selected from the dropdown combo boxes. Clicking the pointing down arrow on combo box will allow the user to see the available choices, e.g. colors and sizes. After the combo boxes are dropped down, user can make selections of the desired quantity, size and/or color by clicking the mouse.

To view this item in 360° view, the user clicks the button labeled "Show 360° View". This action will show a video picture of the item rotating slowly in 360°. If there are additional images of the same kind as the selected item, the "Prev Image" and "Next Image" buttons will be automatically enabled to allow the user to view more images in full view.

After viewing the item and selecting quantity, size and color, the user can start the purchasing process by first putting this item in an electronic shopping bag by clicking on the button labeled "Add to Shopping Bag." At this point the user has not yet actually purchase the item but only put it in a temporary storage area to be purchased later.

In implementation, this dialog is initiated when the user selects a thumbnail from the Shop dialog or clicks on the button "Go to Product Page" from the Shopping Bag dialog. In either case, since each thumbnail image is associated with an Image ID and Item Info object, this data object will be passed on to the Product dialog.

When the user clicks on the thumbnail image or the "Go to Product Page" button, the application will extract the Item Info object associated with the thumbnail. In this object, the application will retrieve and use the following parameters:

1. Path to a larger image file. This is used to display the large image.

2. Item description and price. These are used to display item description and price. 3. Available sizes. These are placed in a combo box to be selected by the user. 4. Available colors. These are placed in a combo box to be selected by the user.

5. Available 360° image. This is used to show 360° views when user

clicks "Show 360° View" button. 6. List of any additional images for this product.

When the user selects the quantity, size and/or color, the Item Info object's parameters are dynamically updated to reflect the new changes. When the user clicks "Next Image" or "Prev Image", the application will retrieve from the list of Item Info objects the next or previous image for this product and display that image. When the user clicks the "Add to Shopping Bag" button, the application will update the Item Info object and store it in a list in the application global data object pool Order Info object. When the user clicks the "Go to Previous Page" button, the application will not update the Item Info object and it discards all the changes or selections from this dialog.

SHOPPING BAG In operation, as shown in FIG. 8, this dialog contains all items the user has selected with the intent to purchase. It shows the thumbnail images of all the items as a set of zero to five images at a time. This limitation is due to the screen size and thumbnail image sizes. If there are more than five items, the thumbnail section will automatically display the "Next" button to inform the user that there are more images. By clicking on the "Next" button, the next set of thumbnail images will be shown, and at the same time, a "Previous" button also appears to inform users that they may view the previous images by clicking the "Previous" button. This is the main navigation method for the thumbnail image section. To view the description and price of the item, the user clicks on the item thumbnail in the thumbnail area. Item description, price, selected quantity, color and size will be shown in the item detail section of the dialog. These values are set based on user selections in the Product dialog. The quantity, color and size may be selected from the dropdown combo boxes. To change the quantity, size and/or color, the user clicks the pointing down arrow on each quantity, color and size combo box. This allows the user to see the available color and sizes. After the combo boxes are dropped down, the user may make selections of the desired quantity, size and/or color by clicking the mouse. To remove this item from the Shopping Bag, select the item from the thumbnail area of the dialog then click the "Remove" button. To view this item in detail again, select the item from the thumbnail area of the dialog, then click the "Go to Product Page" button. To continue shopping, the user clicks the "Return to Shopping" button. This action will take the user back to the Shopping dialog where user may browse through Categories and/or Designers for more items.

To purchase all items in the Shopping Bag, the user clicks the "Purchase" button. This action hides this dialog and displays the "Current Order" dialog. This dialog shows a summary of all items to be purchased and also shows the user profile information, such as user name, address and credit card information. To begin purchasing the items, the user clicks the "Proceed to Purchase" button.

In implementation, the Shopping Bag dialog is initiated by selecting the "Shopping Bag" button. When the dialog starts, it will query the application global data object pool to retrieve the Order Info object. In this object is a list of Item Info objects. This list of Item Info objects is created from the Product dialog when a user selects the "Add to Shopping Bag" button. The application will retrieve from this list of each Item Info object the following parameters: 1. Path to a thumbnail image file. Use this to display thumbnail image.

2. Item description and price. Use these to display the item description and price. 3. Current selected quantity. These are placed in the quantity combo box to be changed by the user.

4. Current selected size. This is placed in a combo box to be changed by the user.

5. Current selected color. This is placed in a combo box to be selected by the user.

Upon finishing retrieving this list of Item Info objects from Order Info object, the application will call a method and pass in this list to build and display the thumbnail images in the Shopping Bag dialog. The function of this method is to extract each Item Info object from the list, retrieve the image name and path and display them as a set from zero to five thumbnail images maximum each time. If there are more than five images in the list, the application will automatically enable the "Next" button to inform the user that there are more available thumbnails to view. When the user clicks the "Next" button, the application will again retrieve from the list the next five images to display and at the same time enable the "Prev" button to inform the user of the ability to display the previous thumbnail images.

The application also checks if there are more next images. If not, it will disable the "Next" button to inform the user that there are no more images to view next. When the user clicks on the "Prev" button, the application will retrieve from the list the previous five images to display. It will also check if there are still more previous images. If not, it will disable the "Prev" button and enable the "Next" button. If the user selects to make changes in quantity, color and/or size, the Item Info object is updated to reflect the changes. The application will associate an image ID and Item Info object with each displayed thumbnail image. This information will be used when user clicks on the "Go to Product Page" button to go to the product dialog.

When the user selects the "Remove" button, the thumbnail image disappears from the display section and, at the same time, it is removed from the Item Info object list. The Order Info object will dynamically update this list to reflect the change. When the user clicks the "Return to Shopping" button, all changes (quantity, color and size) are updated in the Item Info object and the Shopping dialog appears.

When the user selects the "Purchase" button, all changes (quantity, color and size) will be updated in the Item Info object and the Current Order dialog will appear.

CURRENT ORDER DIALOG In operation, as shown in FIG. 9, this dialog contains two sections: Current Order and Payment and Shipping Info. It is designed to give the user the summary view of the items, payment and shipping information before actually purchasing. The Current Order section shows the summary of the current order items in a table format. It shows number of items, item name, designer, size, color, price and quantity. The total cost for this order is also shown. The Payment and Shipping Info section shows the user's billing and shipping addresses as well as the payment method for this order. The payment method shows credit card information to be used to purchase the current order. This section also provides an opportunity for the user to enter this information if it has not already been entered. The saved profile to be used for future orders All user information is retrieved from the local database and stored in the user's machine. The user either enters the information at application setup time or any time after that. The "User Profile" dialog is used to enter user information. This user profile will be used for future purchasing so the user does not have to reenter the information unless there are changes.

In implementation, the Current Order dialog is initiated by clicking the "Purchase" button from the Shopping Bag dialog. It contains two main sections: Current Order: shows a summary of all items in the order; and Payment and Shipping Info: Billing and Shipping Addresses and Credit Card information. When the dialog starts, it will query the application global data object pool to retrieve the Order Info object. In this object is a list of Item Info objects. This list of Item Info objects is created from the Product dialog when the user clicks the "Add to Shopping Bag" button. The data (quantity, size and color) may have been changed in the Shopping Bag dialog. The application will retrieve from the list of each Item Info object the following parameters and display them in the Current Order section: item names, designer names, item descriptions, items prices, item sizes, and item colors.

The above data is shown to the user in the Current Order section in a table, where each row represents an Item Info object. The List View component is used to accomplish this operation. The Order Info object also contains a User Info object. The User Info object is an object that holds all user information such as name, billing and shipping addresses and credit card information. The user enters this personal information using either the User Profile. The information is stored in a local database. The User Info object is automatically generated from the database and added to the Order Info object when the Order Info object is created from the Product dialog. If the user information has been setup previously, the data will be shown here in the Payment and Shipping Info section. If it has not been setup, the user can go into the User Profile area and complete the information. The application will generate a new User Info object with the new data and add it to the Order Info object. The Order Info object is the master object for the application. There is only one Order Info object per order. It is the only object that will be sent to the server to complete the purchasing process.

USER PROFILE In operation, as shown in FIG. 10, the "User Profile" dialog is used to enter user information. This user profile will be stored in a local database on the user's computer. It will be used for future orders so the user does not have to reenter the information again unless there are changes. The dialog contains the following sections: Billing Address, where the user enters billing address and name as it appears on the credit card; Shipping Address, where the user enters the shipping address, if it is different than the billing address; and Credit Card Information, where the user enters the card type, card number, and expiration date from the credit card.

The user clicks the "OK" button to save this information. The user can setup for different kinds of credit cards by keeping all the info in the Billing and Shipping sections the same while changing the credit card information in the Credit Card section. The user clicks the "OK" button each time the new credit card info is entered to save the changes, and clicks the "Cancel" button to exit this dialog, not save any information and return to the previous dialog.

In implementation, the User Info object encapsulates the User Profile dialog. It is an object that holds all user information such as name, billing and shipping addresses and credit card information. The user enters this personal information using either the User Profile or Current Order dialog. The information is stored in a local database.

The User Info object contains three objects where each object encapsulates a section in the dialog. The three objects are: User Address object which encapsulates the Billing Address section; User Shipping object, which encapsulates the Shipping Address section; and User Card object, which encapsulates the Credit Card Info section.

After the user enters personal information and clicks the "OK" button, the application will collect the data and put them in the appropriated object as follows: Billing Address info is stored in the User Address object; Shipping Address info is stored in the User Shipping object; and Credit Card Info is stored in the User Card object

The application then sends the User Info object with the new data to the Database Service object to perform the database operation to save data in the local database.

INDUSTRY SPECIFIC DIALOG In operation, as shown in FIG. 1 1, depending on the industry, there may be a dialog to provide certain industry-specific information and marketing. In the example case, this dialog is called Fashion World. It provides the user with the latest information on fashion news, fashion tips and fashion videos, which may be viewable by the consumer. In implementation, this dialog is initiated by selecting the "Fashion World" menu item from the Options menu actuated by clicking the Options button or icon. The dialog contains an embedded Multimedia ActiveX control to allow playing video. It also contains hyperlink text to display information when the user selects a topic such as fashion news, fashion tips, latest fashion show, etc. When selecting, for example, a Latest Fashion Show hyperlink, the application will read the computer's registry database to determine the directory path to the corresponding video file. The application also instantiates a new instance of the Multimedia control and passes to this control the path of the video file to start playing the video.

When selecting other hyperlinks beside video, the application launches an embedded control to display information in a multimedia format. The directory path to these files is obtained by the application from the computer's registry database.

PROGRAM SETTINGS

In operation, as shown in FIG. 12, this dialog allows the user to set certain personal preferences for the application such as playing background music while shopping or playing a video every time the application launches. The settings vary among NMEC products. In implementation, all settings made by the user in this dialog are stored in the computer's registry database.

THE COMMUNICATION MODULE The communication module 48 is the primary medium for data communication between NMEC clients and servers. It may employ one of the following technologies: standard Internet protocol (IP), regular HTTP or secured

HTTP connections; standard modem; Digital Subscriber Line (DSL); Cable Modem;

Broadband; Wireless; Virtual Private Network (VPN); Local Area Network (LAN);

Wide Area Network (WAN); Internet Service Provider (ISP); and Protocol such as

XML (Extensible Markup Language), COM/DCOM (Distributed Component Model), CORBA (Common Object Request Broker Architecture), EJB (Enterprise

Java Beans) or any other advanced protocol in the foreseeable future. In one embodiment, NMEC applications employ XML protocol through Virtual Private Network. XML provides an industry standard protocol to exchange data between clients and servers on different platforms, and a Virtual Private Network provides the highest security for web transaction. It also provides a single point of contact for all clients to communicate with servers.

The communication module 48 in NMEC applications is activated when the user clicks the "Proceed to Purchase" button in the Current Order dialog. It happens in the following sequence, as shown in greater detail in FIG. 13 A:

1. Application instantiates a new instance of the XML object. 2. Order Info object is translated to XML format.

3. The XML object sends a "POST" command to inform the server of the method type.

4. The application instantiates a new instance of the VPN object to start a VPN session. 5. The telephone numbers, account name and password are passed to this VPN object.

6. If successful, a VPN tunnel is opened and prepared to send and receive data.

7. The XML object calls the application's method to start sending Order Info data to the server through the opened VPN.

8. The server processes the data then sends back to the client an updated Order Info object in XML format.

9. The XML object parses the XML data and translates the data back to data object Order Info. 10. The application extracts info from Order Info object and displays results of the order transaction to the user. 11. The application extracts a list of Item Info objects from the Order Info object and saves the order history for these items in the user local database.

12. The application extracts the User Info object from the Order Info object and saves the user information that relates to the items ordered in user local database.

13. The application closes the VPN session and destroys the VPN object and XML object.

Note that by employing VPN, each NMEC client does not need a unique user name and password to access the system. There is only one account name and password assigned to the VPN that NMEC uses. The account name and password are embedded in the application and are identical for all users. The use of VPN also prevents the user from using the system to browse the web. Its only purpose is to open a VPN session, process the order and close the session.

SERVER MODULE

The server module 50 has the following features, as shown in conjunction with FIG. 2: it is a single contact point for all clients, which sits behind firewall to improve security and includes a server farm for connection to specialized servers (Backup, Data Recovery, Accounting, Business, Database, etc...). The server module 50 operates with respective clients to perform order process events, for example, as shown in FIG. 13B. The server module 50 provides automatic update, if needed, each time the client connects to the server 54. It performs updates including to the product database and application. For example, as shown in FIG. 13C, StyleSource clients connect, through the server module 50, to a StyleSource server in the server farm 54 to perform the following functions:

1. place a new order;

2. request for tax; 3. cancel an order;

4. update and modify an order;

5. request an RMA;

6. request sales and promotions; 7. request a product update;

8. check order status and tracking; and

9. auxiliary requests.

When one of such functions is evoked by a StyleSource client, the StyleSource server performs an automatic order status update after the client connects to the StyleSource server to perform and finish one or more of such functions.

The server module 50 stores a copy of each client's latest transaction in case of communication failure and automatically reconnects to finish the transaction. It provides product data entry application to keep the product database up-to-date, and it supports consumer help desk. The server module 50 performs tracking of order status, and provides real-time sales tax and shipping charges. It also interfaces with merchant banker for credit card transaction, and interfaces with vendors for order fulfillment.

The NMEC Server 12 is the main contact for all NMEC clients, with the high-level configuration between clients and servers shown in FIG. 2. The following modules are stored in the NMEC server 12 in the form of binary Dynamic Link Library (DLL): Process Order module, Notify Order module, Product Update module, and any additional libraries to support the NMEC client.

PROCESS ORDER MODULE

All orders initiated by NMEC clients must connect to the main server and send to it the Order Info object. The main DLL to handle these requests is the Process Order Module DLL. NMEC features five types of order processes that utilize the Orderlnfo object and the Process Order DLL. 1. Shopping for new items

The Process Order DLL operates as shown in FIG. 14, in which it extracts the User Info object from the Order Info object sent from the client. It then extracts the User Card object from the User Info object to perform credit card verification. If the credit card verification is valid, the Order Info object is put in a message queue server. All information about this order will be saved in the server SQL database at this time for record keeping purposes. If there is any failure on the server itself, the server will be able to attempt to process this order again by retrieving the saved information from the database. If the credit card verification fails, the server will send back to the client the reason for the failure, so it may be corrected before another attempts to process this order.

The server will not send the Order Info object to the vendors, but rather the vendors will retrieve the Order Info object in two ways: continuously query the queue server to retrieve the Order Info objects to process the order, or batch processing in which the vendor might query the server once or twice or more each day to obtain the new Order Info objects.

After successfully processing the order, vendors will assign the new user with a vendor-specific User ID and Order Number for this order. The status of each item in this order is also updated. The item status is set in each Item Info object. The updated Order Info object is sent to the server from the vendor. The server will save the returned updated Order Info object in the server database and send this updated data to the client to inform the consumer of the current order status. The server is not capable of initiating a connection with the client if the client is disconnected before the server returns the updated object. The client must initiate the connection with the server. The order status will be sent to the client and stored in the client's local database on the next connection initiated by the client.

2. Cancel the order As shown in FIG. 15, when the user opens the View/ Alter Orders dialog, the application performs a database query from the local user database. The Database Service object will perform this operation. It queries the database for all of the user's orders. It creates an instance of each Order Info object, places the query results in this object and presents the order items to users. To cancel an order, the user selects an item and clicks the Cancel Order button.

The application starts the standard client/server communication session as described in the Communication Module section of this document. The Order Info object is sent to the server. The server's Process Order Module DLL is responsible for this operation. It extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to cancel, it puts the Order Info object in the message queue server.

The server will not send the Order Info object to the vendors, but rather the vendors will retrieve the Order Info object in two ways: continuously query the queue server to retrieve the Order Info objects to process the order, or batch processing, in which the vendor might query the server once or twice or more each day to obtain the new Order Info objects.

After retrieving the Order Info object from the queue, the Vendor server extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to cancel, it extracts the User Info object, Order Number, Vendor Info object and Item Info objects from this Order Info object. It uses these data to perform the cancel order operation.

The vendor server then sets a status flag in the Order Info object to record the status of the request to cancel order and sends the Order Info object back to the main server. The server saves this information in the server database before sending it back to the client. The client application again extracts the cancel order status from the returned Order Info and displays the results to the user.

3. Return Order To return an order, which may include obtaining a Returned Merchandise

Authorization (RMA) number, the system 10 operates according to FIG. 16, in which the user selects View/Alter Orders from the Options menu. The View/ Alter Orders dialog appears to allow the user to select an item to be returned. When the dialog opens, the application performs a database query from the local user database. The Database Service object will perform this operation. It queries the database for all user orders. It creates an instance of the Order Info object and places the query results in this object and presents the list of items to users.

When user selects an item and clicks the Return button, the application starts the standard client server communication session as described in the Communication Module section of this document. The Order Info object is sent to the server. The server's Process Order Module DLL is responsible for this operation. It extracts the order type flag from Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to return, it puts the Order Info object in the message queue server.

After retrieving the Order Info object from the queue, the Vendor server extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to return, it extracts the User Info object, Order Number, Vendor Info object and Item Info objects from this Order Info object. It uses these data to perform the return order operation. The vendor server then sets a status flag in the Order Info object to record the status of the request to return the item. The vendor server also generates a Returned Merchandise Authorization (RMA) number, and sends the updated Order Info object back to the main server. The server saves this information in the server database before sending it back to the client. The client application again extracts the return order status from the returned Order Info and displays the results to the user, along with the RMA number.

4. Update Order

To update an order, as shown in FIG. 17, the user would select View/ Alter Orders from the Options menu. The View/ Alter Orders dialog appears to allow the user to select the order to be updated. When the dialog opens, the application performs a database query for all of the ordered items. The Database Service object performs this operation. It queries the database for all of the user's orders. It creates an instance of the Order Info object and places the query results in this object and presents the items to the user.

The user selects an item. The user can change the item quantity, size and/or color then clicks the "Submit" button to start the change. The application starts the standard client/server communication session as described in the Communication Module section of this document. The Order Info object is sent to the server. The server's Process Order Module DLL is responsible for this operation. It extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to update the order, it puts the Order Info object in the message queue server.

After retrieving the Order Info object from the queue, the Vendor server extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request to update order, it extracts User Info object, Order Number, Vendor Info object and Item Info objects from this Order Info object. It uses these data to perform the update order operation.

The vendor server then sets a status flag in the Order Info object to record the status of the request to update order. The vendor server sends the updated Order Info object back to the main server. The server would save this information in the server database before sending it back to the client. The client application again extracts the update order status from the returned Order Info and displays the results to the user.

5. Check Order Status To check the status of an order, as shown in FIG. 18 A, the user selects View/ Alter Orders from the Options menu. An Order Status dialog appears, allowing the user to select the item for status check. When the dialog opens, the application performs a database query from local user database. The Database Service object performs this operation. It queries the database for all user's orders. It creates an instance of the Order Info object, places the query results in this object and presents the ordered items to users.

The user selects a desired item to check for status then clicks the Check Order Status button to start the process. The application starts the standard client/server communication session as described in the Communication Module section of this document. The Order Info object is sent to the server. The server's Process Order Module DLL is responsible for this operation. It extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request for order status, it puts the Order Info object in the message queue server.

After retrieving the Order Info object from the queue, the vendor server extracts the order type flag from the Order Info object to determine what type of order it is. If this is a new order, it performs the new order operation as described in the New Order section above. If this is a request for order status, It extracts the User Info object, Order Number, Vendor Info and Item Info objects from this Order Info object. It uses these data to perform the order status checking operation. The vendor server then sets status flags in the Item Info objects of the Order Info object to record the status of each item in this order. The vendor server sends the updated Order Info object back to the main server. The server saves this information in the server database before sending it back to client. The client application again extracts order status from the returned Order Info and displays the results of the order status operation to the user.

6. Perform Tax Requests

When a consumer has entered order information for specific items, for example, in the Shopping Bag, the NMEC system 10 provides two ways for the consumer to request the exact tax amount for all items to be purchased, as shown in FIG. 18B.

The first method is a Manual Request procedure, which occurs when the user selects to proceed to purchase the desired items. The client application will show the estimated tax for the order, and give the user the option to see the actual tax amount before placing the order. The Manual Request procedure is carried out when the user selects a button or icon, such as an "OK" icon, to cause the system 10 to display the actual tax to the user for viewing.

The second method is an Automatic or Auto Tax Request, which occurs when the user selects to proceed to purchase the desired items. The client application will show the estimated tax for the order, and give the user the option to see the actual tax amount before placing the order. If the user does not want to view the actual tax before ordering, the respective server processing the order, such as the StyleSource server, performs the tax calculation request when the order is placed. In either case, the server, such as the StyleSource server, sends the tax request with an ORDERTYPE TAX flag set in an Orderlnfo object to the IBM server 14, shown in FIG. 1. The server 14 then extracts the Itemlnfo objects from the Orderlnfo object, and sends the tax request information to another module or entity, such as CyberSource, to determine the actual tax amount. The corresponding tax information and calculations is then saved on the StyleSource server and in the user's local database only if the order has been placed. PRODUCT UPDATE MODULE

The Product Update DLL is the module responsible for handling all data updates, product updates and database updates requested by NMEC clients. It resides on the NMEC main server 12. The server 12 will route all requests for update through this module. There are three types of update: automatic update, manual update, and product database update.

1. Client Automatic Update

As shown in FIG. 19, an update check occurs every time a client connects to the server. The client sends the version numbers of the following components to server: NMEC Application version number, Product Database version number, and User Database version number. The data is embedded in a Version Info object. Note that the application always sends this request first before sending the Order Info object when requesting a new order. When the server receives the Version Info object from a client, it extracts these version numbers from the object. It also queries the server's registration database to obtain the server's own data. It compares the version number of each component between client and server. If the server's component number is greater than the client's is, it sends a message to the client to inform the client of the request for automatic update. If the client accepts the auto update request, the server will send the required update, which may include: new NMEC application executable code, the auto update executable code, and the user and product databases. The client application starts the automatic update process. The application performs auto update in the following sequences: a. Close the user and product databases. b. Replace client's product database with one from server. c. Import user database data from the client to one from the server, then replace it. d. Shutdown the application itself and replace it with new application executable code. e. Automatically restart the application.

2. Client Manual Update

Manual update goes through the exact same procedures as the automatic update, as described herein and with reference to FIG. 19. The only difference is that the user manually requests this update through a menu option from the application. After the server receives this request to update, it will perform the same sequence of actions as the automatic update described above.

3. Client Product Database update

As shown in FIG. 20, the product database update process occurs every time the user places a new order by sending an Order Info object to server. The server extracts Item Info objects from the Order Info object. It uses Item Info objects to verify each item's availability against the server product database. The server product database always contains the latest information on all items. If the item is not available or there are any other changes for this item, the server will automatically send a new product database to client and perform auto update of this database on the client's machine. It also informs the user of the item's changes before proceeding with the order. 4. Server Product Database Update

As shown in FIG. 21, This operation ensures the server product database is always up-to-date. There are two ways to perform this update: by automatic update, and by manual update. For automatic update, this process happens within the NMEC server environment and does not involve the NMEC clients. The Server Product database update occurs every time the Vendor changes the product database. The vendor server automatically sends the changes to the NMEC server using a list of Item Info objects. The server extracts Vendor ID and Item ID from each Item Info object and performs the database update using Database Service object.

For manual update, this process happens when the NMEC server product database is corrupt or there is a need to refresh the database. The server operator will select the Product Update option from the server application. The server sends a request for product database update to all vendor servers. Each vendor server sends the latest product data to the NMEC server using a list of Item Info objects. The NMEC server extracts Vendor ID and Item ID from each Item Info object and performs the database update using the Database Service object.

USER REGISTRATION MODULE This module is designed to handle all user registration info. When installing the NMEC client for the very first time, as shown in FIG. 22A, the user will have the option to register by providing name and addresses and choosing a user account ID. The user is not required to register to use the NMEC application. Consumers can choose to register later or the application will automatically register the user with the server when the user makes a first purchase.

Each time the user connects to the server, the server will check if the client has been registered by examining the register flag. If not, the server automatically adds the user to the server database. The server extracts the User Info object from the Order Info object sent by the client to perform the registration process.

CONSUMER PROGRAM OPERATIONS The NMEC system 10 and method of operation are designed to be easy for consumers to use. Before release, each NMEC product undergoes multiple extensive design review and changes based on input from multiple focus groups. Focus groups are conducted with potential users of the product. These are the people most capable of indicating how well the product, its features and design really work. The end result of the focus group and design revision process is a product that is intuitive and easy-to-use for consumers with a wide range of computer experience. Many other software products focus on usability only for "experienced" computer users or only for the novice. NMEC development has taken the steps necessary to provide a high level of usability for the whole spectrum of consumers. Consumers who are already familiar with computer software standards and with using the World Wide Web will find that NMEC software complies with many of the standards they've encountered in the past. Users with less computer experience will find that there's a very low learning curve, with intuitive navigation and operation, as well as help that's readily available on all screens. For installation, as with the NMEC system 10 in general, the product installers are designed to be easy to use. In the example case, StyleSource, a helpful start screen opens as soon as the consumer puts the CD in the drive. This screen provides basic options, such as starting the installation process, getting an overview of the product, and running a product tutorial. When the consumer chooses to start the installation, very little interaction is required and all components are automatically installed in the correct locations. The goal of NMEC installation is to help the consumer get the product installed with the very minimum consumer effort. This makes the consumer more likely to complete the installation and start using the product. Although there should be little difficulty with installation, Internet Plus Customer Support contact information is readily available on the packaging material, to provide an additional level of support to consumers.

STARTUP OPERATIONS After installation of the application implementing the NMEC system 10 and method on a consumer's computer, the very first time that the application is launched, the application will not connect to the server 50 to request for a product database update. After the first launch, as shown in FIG. 22B, the application will give the user the option to request for a product database update each time that the application is started. However, the user can only make this request once in an allowed elapsed time period.

The requested time is stored/written to the registry. Each time that the application is started, it checks for an expiration date, and queries the registry for the last update time. The application then calculates and compares the last update time with the current time. If the elapsed time is within a predetermined allowed time to update, the application displays a message box or window to the user asking if the user wants to perform a product database update. If the user selections "YES", the application will connect to the server and perform a product database update operation, and then write the last update time to the registry. If the user selects "NO", the application will proceed to the Shop dialog. If the elapsed time is not within the allowed time to update, the application will not display the message box asking the user whether to update. The application will proceed normally, and display the Shop dialog. The application is then ready to use by the consumer. During a Startup operation, after installation and the procedures shown in FIG. 22B, the consumer can start NMEC simply by placing the CD in the drive or by choosing the NMEC menu item from the Start menu (if the CD is already in the drive). In either case, a welcome screen greets the consumer. A welcome screen for the example case can be seen in FIG. 23.

The welcome screen is purposely uncomplicated, in order to make entry to the program easier for the novice computer user. It consists only of a greeting, a video showing some of the current styles, and a button called "Go Shopping." The video is fast-paced, with exciting background music, so it catches the consumer's attention and motivates the consumer to continue using the product. When the user clicks the "Go Shopping" button, or when the video is finished, the main shopping screen appears.

For Quick Start operations, the first time the main shopping screen appears, a "Quick Start" message appears, as shown in FIG. 24 for the example case. The Quick Start message serves to point out basic navigation features for the novice computer user. In this case, it explains the "rollover" feature. Rollover is a computer term for when the user moves the mouse over an item on the screen and that item changes appearance. It's used to indicate that clicking on that item will have some effect. For example, when the user rolls the mouse over the name of a clothing designer, the name changes from white text on a black background to black text on a white background. This tells the user that clicking here will accomplish something - in this case, it will display thumbnail images of garments by that designer. Rollover is used throughout NMEC products, to assist consumers who may not otherwise be certain where to click or how to proceed within the program.

The Quick Start message disappears when the user clicks the OK button. When the Quick Start message disappears, the main shopping screen appears, for example, as shown in FIG. 25. Since the Quick Start message only appears the first time the program is started, the main shopping screen ordinarily appears just after the welcome screen.

BASIC NAVIGATION USING THE NMEC SYSTEM As explained above, rollover is used throughout NMEC products to show consumers where there are "hot" areas on the screen, i.e. places they can click to make something happen. This, in addition to the words and images on the screen, provides a guide for how to navigate.

As shown in FIG. 25, the main navigation buttons may appear across the top of the screen, along the bottom, down the side, and/or anywhere they are easy to see and access. In the example case, the main buttons, shown in FIG. 25, are across the top of the screen. They are present at the top of all product screens, except in cases where this type of navigation isn't desired. The screen for viewing and altering orders, for example, does not include these buttons. Since this is an activity that can be started from many different locations, the only navigation button is a Done button that returns the user to the screen where she started.

In the example case, the main navigation buttons are Shop, Shopping Bag, Options, Help, and Exit. Clicking on a button has the same effect each time; that is, Shop always moves to the main shopping screen; Shopping Bag always opens the Shopping Bag screen; Options contains sever menu items, to navigate to other screens: Fashion World, User Profile, View/ Alter Orders, and Program Settings; Help always opens the main Help screen; and Exit always closes the program.

SCREEN-SPECIFIC BUTTONS Screen-specific buttons are those that appear on one (or occasionally more) of the product screens, but not on all screens. These are typically used to operate the screen itself or to move to another specific screen. For example, FIG. 26 shows several screen-specific navigation buttons. The "Go to Product Page" button moves to the product page for the selected Shopping Bag item. The "Purchase" button moves to the first screen of the purchase sequence. And, the "Return to Shopping" button moves to the main shopping page. This latter button is actually redundant with the Shop button at the top of the screen. However, most of the activity on this page is focused at the bottom of the screen and it appears to be easier at this point for shoppers to click on "Return to Shopping."

Arrow buttons are used on many screens to allow the user to navigate to the next or previous set of data, such as the next image of a garment, or the next set of thumbnail images that match a product search.

Locating products are relatively easy to perform. NMEC products are tailored to make it easy for consumers to find the products they want, in they way they want to find them. Note that the methods of searching for products will change, depending on the type of goods offered. If fine art products are being offered, the options might be to search by artist, subject matter, or style. If furniture is being offered, the options might be to search by article (couch, chair, armoire), style, or room of the house. In all cases, these design decisions will be made based on market research and focus group results. In the example case, women are shopping for fashion products, but have a few different ways they like to search: by category, designer, and look.

Some consumers shop by category of product. For example, the consumer may be looking for a coat. She can easily find all coats offered, by selecting the Coats category. The All Designers setting is also selected, as the default. In FIG. 25, the categories can be seen along the left side of the Search box. When a consumer clicks on Coats, thumbnail images of all the available coats will be displayed in the box at the bottom of the screen. FIG. 27 provides for an example of how the screen looks with thumbnail images at the bottom. Some fashion consumers shop by designer. For example, the consumer may be interested in Giorgio Armani clothing. She can easily find all Giorgio Armani clothing offered, by selecting Giorgio Armani as the designer. All Categories is also selected, as the default. In FIG. 25, the designers can be seen in the middle of the Search box between the Categories and the MaxMara image. When a consumer clicks on Giorgio Armani, thumbnail images of all the available Giorgio Armani products will be displayed in the box at the bottom of the screen. FIG. 27 also shows how the screen looks when the designer Giorgio Armani has been selected. Some fashion consumers shop for a "look", such as casual, business, leather, plaids, animal prints, etc., depending on the occasion and what is currently in vogue. A method of shopping by look is likely to be added to the StyleSource software, in order to satisfy even more consumers, by offering another popular method of shopping. This feature would function similarly to the Category and Designer shopping features that are already in place. Some consumers desire even more targeted shopping, and may require more complex searching. Such consumers may choose to select both a category and a designer. For example, if the consumer selected both Coats and Giorgio Armani, the thumbnail images at the bottom of the screen would change to reflect only the coats that are available from Giorgio Armani. When viewing products and product information, as with product searching, there are many different potential ways to have consumers view products and product information. The design and type-of-product information depends upon the type-of-product and the audience of the NMEC system 10. If the product is fine art, it may be important to display very close detail images and present the work with different types of matting and framing. If the product is furniture, it may be important to display groupings of furniture and coordinating colors for walls and rugs. In the example case, each product has a single display screen, showing a large, clear image of the product, the description, pricing, size, and color information, as well as additional images of the product and a 360° view, where available. The consumer gets to a product information page by clicking on a thumbnail image at the bottom of the main shopping page.

PRODUCT PAGES As shown in FIG. 28, a product page may include the main navigation buttons along the top, a large image of the garment on the left side, the designer's name such as MaxMara, a product name such as "Long Wool Coat", a description, a price, and a size selection area. The user may click on the Size pop-up box to select a size, which causes the system 10 to generate an example screen in FIG. 29 which the user would see when selecting a size.

Color-selection areas and windows may also be provided, in which the user may click on the Color pop-up box in FIG. 29 to select a color. Similarly, the user may click on the Quantity pop-up box to use a quantity selection area or window to select a quantity.

Other functions may be included such as rotational control of the images of the model and the products. For example, the Show 360° View button may be provided, as shown in FIG. 29. When the consumer clicks this button, the image on the left is replaced by a video or slideshow in a window shown in FIG. 30, displaying the garment in 360° view. Refer to Figure 33. Video or slideshow controls, such as rewind and play icons, appear at the bottom of the image window, and the Show 360° View button changes to the name "Back to Main View." The video or slideshow starts immediately, but the user may click a Pause/Play button to start and stop the presentation. The button name toggles between "Pause" and

"Play." The user may also click a Rewind button to restart the presentation from the beginning. Clicking the "Back to Main View" button closes the video/slideshow and re-displays the primary image of the garment.

An Add to Shopping Bag button may be provided, such that when the consumer clicks this button, the product is added to the Shopping Bag, in the size, color and quantity selected. Previous Image and Next Image buttons are also provided. Clicking the Next Image button replaces the current image with the next available image of this garment, possibly from a different angle, or in a different color. Clicking the Prev Image button replaces the current image with the previous image in the series. The images cycle, so the consumer can keep clicking Next, if desired, to click through all the images repeatedly. FIG. 31 illustrates the screen might look when cycling through images and viewing a fabric close-up. Other buttons include a Go to Previous Page button may be provided. When the consumer clicks this button, the main shopping screen appears.

For viewing the shopping bag, as with other elements of the NMEC consumer interface, the Shopping Bag will vary with the products. In the example case, the consumer gets to the Shopping Bag by clicking on the Shopping Bag button near the top left of the screen shown, for example, in FIG. 31. FIG. 26 shows an example of the StyleSource Shopping Bag. Elements of the Shopping Bag include: 1. The main navigation buttons.

2. Thumbnail images of the consumer's selected items

3. A product review area allowing the consumer to review details of a selection by clicking on the thumbnail image of the selection in the Items in the Shopping Bag area with selection details appear in the box at the lower left of the screen. 4. Go To Product Page button such that, if the consumer wishes to review all available product information, the consumer can click on the Go to Product Page button to return to the product information screen for the selected item.

5. Remove button, such that if the consumer wishes to remove an item from the Shopping Bag, the consumer can select the item in the Shopping Bag, for example, by clicking on its thumbnail inside Items in the Shopping Bag, and then click the Remove button.

6. Size, Color and Quantity selection areas, which work in the same way as described under Viewing Products/Product Information. They are located in the Shopping Bag to give the consumer an easy opportunity to change the order. A different size, color, or quantity may be selected, just as described in the section on Viewing Products/Product Information.

7. A Purchase button, which the consumer clicks on to initiate the purchase process. Clicking this button brings up the first screen of the Purchase sequence. 8. A Return to Shopping button, which the consumer may click on this button to return to the main shopping screen.

For purchasing, before the consumer's purchase is complete, the consumer must enter User Profile information, and verify that the order is correct.

To enter User Profile information, if the User Profile is incomplete, the Purchase Info Wizard will open automatically when the consumer clicks the

Purchase button. This Wizard is a series of screens that prompt the consumer for the needed information: shipping address, billing address, and credit card information.

Refer to the description herein on User Profile for more information. If the User

Profile is complete when the consumer clicks the Purchase button, all User Profile information is displayed, so the consumer may review it and decide if any changes should be made. FIG. 32 shows an example of how the User Profile information is displayed. To verify that the order summary is correct, referring to FIG. 32 which displays a summary of the Current Order, if the order is incorrect, the consumer may return to shopping or the Shopping Bag to make additions and changes.

Once User Profile and order summary are correct, the consumer clicks the Proceed button. This initiates the connection to the server. After all order information has been transferred, the consumer sees a message on the screen, indicating that the order has been placed.

In addition to being available at the time of purchase, the User Profile is available through the Options menu actuated by one of the main buttons, at the top of the screen. FIG. 33 illustrate the screen shown in FIG. 27 modified to have the appearance of a pull-down menu thereupon when the Options menu is opened. This menu makes it easy for consumers to change their shipping and/or billing information at any time. When the consumer chooses User Profile from the Options Menu, the User Profile Wizard opens, as shown in FIG. 34, and guides the user through completion of the necessary information.

Required information includes: billing name; billing street address; billing city; billing state; billing ZIP code; credit card type such as Visa, Mastercard, Amex; credit card number; credit card expiration such as month/year; shipping name; shipping street address; shipping city; shipping state; and shipping ZIP code. An E-mail address is optional, for those consumers who wish to receive order confirmation and updates via E-mail.

The consumer can view/alter orders. Consumers need a way to get information about orders, after they've been placed. The View/ Alter Orders screen shown in FIG. 35 makes this possible. To open this screen, the consumer chooses View/Alter Orders from the Options menu. For example, the View/ Alter Order screen in FIG. 35 displays three items that have been ordered. For each ordered item, the consumer may do one of three things: get item status, cancel an item, or return an item. To get item status, the consumer may select any item in the View/ Alter Order window and then click the Get Item Status button. This prompts a server connection and query about the status of this item. Information returned by the server is displayed in the Order Status area. FIG. 36 shows order status information for a MaxMara dress, including a shipper's tracking ID number and the shipping date.

To cancel an item, the consumer may select any item in the View/ Alter Order window and then click the Cancel Item button. This prompts a server connection and a request to cancel the order of that item. If the item has not already been shipped, the server will contact the vendor and fulfillment house to cancel the order. If the item has already been shipped, the consumer may still return the item.

To return an item, the consumer may select any item that has already been received from the View/ Alter Order window and then click Return Item. This prompts a server connection and a request for a return authorization number. The consumer will be presented with the return authorization number and return shipping information for that item.

To exit from the View/ Alter Order screen, the consumer clicks the Done button. This action brings up the screen the consumer was viewing previously. A Program Settings area on a given screen or window is designed to allow consumers to change simple things about the program interface, such as the sound, help settings, etc. Such Program Settings areas or windows may be implemented in a manner known in the art, such as via pop-up windows. The consumer accesses the Program Settings window by choosing Program Settings from the Options menu. In the example case shown and described herein, the settings available may include settings for sound. The user may click on a Music On checkbox to turn background music on, or click again on that checkbox to turn the background music off. If the Music On checkbox is selected, then the consumer may also choose the music to be played, by clicking on the radio button for a type of music, e.g. Classical or Modern. The Program Settings window can be closed by clicking OK or Cancel. Special industry sections may be supported by the NMEC system 10 and method, so that, depending on the industry represented by the NMEC product, there may be a special section and related procedures and displayed windows and screens relating to the industry. The purpose of this section is to entice consumers to use the product, by providing information and ideas on the topic of interest. In the example case, the special industry section provided may be called Fashion World. The consumer opens the Fashion World screen as shown in FIG. 37 either by clicking the Fashion World button provided on the welcome screen of FIG. 23 or by choosing Fashion World from the Options menu displayed on FIG. 33.

FIG. 37 shows an example of the Fashion World screen, although this screen may change with each StyleSource release. There are several links on this screen, which take the consumer to pages with the latest fashion information and styles.

The products showcased on those pages are all items that are for sale. So, when an item catches the consumer's attention, the consumer may click on the product image to go to the product information screen. This organization of information helps sell more product, by bringing the consumer's attention to certain showcased items.

CUSTOMER INTERFACE TO SYSTEM Virtually any business can be a customer of the NMEC system 10, since the NMEC system 10 and method provide a new medium for capturing marketshare, increasing sales, and building the base of loyal consumers. Some examples of the types of customers who interface with the NMEC system are distributors, product vendors, and merchandisers. Distributors play the critical role of getting NMEC purchasing media for implementing the NMEC system 10 and method into the hands of consumers. As with customer types in general, there are many types of distributors who can be NMEC customers. Some examples are magazines, travel agents, schools, mail-order companies, and traditional direct mail operations.

In the example instance, distribution of the StyleSource CD is accomplished through a fashion magazine. By including the StyleSource CD in its normal distribution, the magazine provides added value to its subscribers and those who purchase their magazine from the newsstand. Therefore, they benefit through greater sales. Even better for the magazine is the added value they can offer to advertisers when the StyleSource CD is distributed with the magazine. Advertising space is filled by premium advertisers, paying premium rates.

Distributors provide the connection between those selling goods and those buying goods. In the example case, the distributor also works to facilitate the business relationship between the NMEC system 10 and method, and the vendors and merchandisers. Marie Claire magazine has existing relationships with vendors such as Calvin Klein and Gucci, and with merchandisers such as Bloomingdale's who buy advertising space in the magazine. As the distributor, Marie Claire is in a unique position to make introductions between the NMEC system 10 and method and the vendors and merchandisers.

The administrators of the NMEC system 10 and method contract and work directly with the vendors and merchandisers to collect content, finalize presentation, ensure communication of order data and ensure fulfillment mechanisms are in place. However, the administrators also work closely with the distributors to ensure that all aspects of distribution correspond with the administrators' standards. The NMEC administrators and the distributor collaborate on the CD cover embodying the NMEC system 10 and method in computer-readable format, the branding elements for both the NMEC administrators and the distributor, packaging, timing, placement, publicity, as well as the level of distribution such as in all magazine copies or just to subscribers.

The NMEC administrators deliver a product master, in this case a CD, to the distributor. The distributor is responsible for duplication, packaging, insertion where relevant, and distribution to consumers.

Vendors are those who manufacture and sell goods, either to consumers or to merchandisers/resellers. As with customer types in general, there are many types of vendors who can be NMEC customers. Some examples are fashion designers, cosmetic companies, computer software and hardware vendors, furniture makers, wineries, etc.

In the example instance, there are multiple vendors: companies who design and produce women's fashions, accessories, cosmetics, etc. These are all companies who advertise with Marie Claire as the distributor. They benefit through the synergy of advertising in Marie Claire magazine and presenting products for sale on the CD that's distributed along with the magazine. More consumers are likely to purchase, when the printed sales appeal is coupled with the convenient means of electronic ordering. New consumers are also likely to be captured with the strength of this synergistic marketing approach. For providing a vendor interface to the system 10, the NMEC administrators develop contractual relationships with each vendor and, subsequently, works with them on the product content. A typical vendor will provide electronic images of the products it wishes to showcase, along with specifications on each product, such as description, price, and available sizes and colors. The specifications are collected using a content-entry tool provided by the NMEC administrators. The vendor enters specifications for a single product at a time, into a software program with a simple interface. That program saves the content information in a format which may be imported by the NMEC administrators into its product database.

The vendor must also establish a mechanism for order receipt and processing, if none exists already. The vendor may work with the technical teams of the NMEC administrators to set up the required computer systems. Alternatively, the vendor may choose to contract with a fulfillment house or merchandiser to handle orders. If the vendor chooses to receive and process orders, its technical staff will work with the NMEC administrators to ensure that the computer systems in place are configured properly to communicate with the NMEC server 12. The vendor's order software must be prepared to accommodate all the information associated with an order: item name, ID, color, size, quantity, price, ship date, etc. If the vendor chooses to contract with another company to handle orders, the process is the same, except that the NMEC administrators work with that other company on the technical issues. Merchandisers are those who physically sell the products, by stocking them on store shelves or delivering products via mail. The merchandisers may sell their own brand name products or they may be resellers for a variety of goods designed and manufactured by other companies. In the example case, the merchandiser is Bloomingdale's, which agrees to provide fulfillment, so it will stock the products to be sold, receive orders, and mail products to consumers. It profits through increased sales and increased visibility, through NMEC marketing materials.

For providing a merchandiser interface to the system 10, the NMEC administrators develop a contractual agreement with the merchandiser, for example, to have all sales or an agreed-upon portion of all sales will go to the merchandiser and that certain marketing and advertising efforts will be taken on behalf of the merchandiser. The merchandiser agrees to fulfill the designated orders, provide rapid shipment and return service, and provide merchandiser-related artwork that may be necessary for product design. Additional mutually agreed-up terms are included.

The merchandiser provides the NMEC administrator with appropriate artwork, such as a corporate logo to be used in designing and marketing the product. When consumers place orders, the order information is transmitted, through server connections, to the merchandiser, who then fills the order and ships the merchandise and updates the server with status information, e.g. date of shipment and tracking number, or date of expected shipment. The merchandiser handles returns and cancellations in a similar way; requests come through the server. If a consumer would like to return an item, a Return Merchandise Authorization number is provided. If a cancellation is requested, the order will be cancelled and a confirmation will be sent. In the case that a consumer wishes to cancel an order that has already been shipped, merchandiser involvement is not necessary; the server generates an automatic response indicating that the item has already been shipped. The distribution of the NMEC application software and the associated content can be achieved by several different electronic and physical methods. Electronically, the NMEC system 10 and method, as application software, can be distributed via broadband services, and via conventional "narrowband". Although the transmission times may be unacceptable to some users, it is possible. Since broadband will always be much slower than processor access, the preferred manner of distribution is physical distribution. Several types of physical distribution are possible, including targeted and direct through a magazine, targeted and direct through a catalog, targeted and direct via direct mail, random but direct via strategic displays located in featuring stores, and random but direct via shipped goods ordered by 800 number, facsimile, mail-in order form, or from an order placed through a web site For fulfillment, the NMEC system 10 and method includes: maintaining an inventory of goods and the on-hand balances of each item, confirming the receipt of an order and communicating the confirmation to the consumer, picking and packaging to fulfill an order, arranging for the shipment of goods and communicating the tracking number to the consumer, issuing return merchandise authorizations to consumers, and processing returned goods by receiving, recording, returning to inventory and disposal, when needed.

The NMEC system 10 and method communicate to the banking function and, following receipt of credit card validation, communicates to a fulfillment provider who performs the foregoing functions.

For financial considerations, the NMEC system may serve in two different types of business models: business-to-business, and business-to-consumer. The financial systems for each of these cases will have unique characteristics. In the business-to-business case, the customer will be a business that will use the NMEC system 10 and method to buy products that will then be sold separately to their customers, that is, the consumer. The NMEC system 10 and method may have no direct interaction with the customer's customer; that is, the consumer.

Typical flow of a business-to-business transaction within the NMEC system 10 and method will include the following categories: customer order placement, customer order authorization and acceptance of a new customer, customer order authorization and acceptance of an existing customer, order placement with vendor, shipment confirmation and invoicing, and accounts receivable collection.

For customer order placement, after selecting products to purchase, the customer such as an art dealer will input order information. The customer will be asked if it is an existing or new account. If it is an existing account, the order will proceed toward authorization. If it is a new account, the customer will be required to complete, onscreen, a new account registration form. This will include information regarding corporate structure, key contacts, key financial information, bank accounts and vendor references. This will be forwarded with the order for acceptance and authorization.

For customer order authorization and acceptance of a new customer, the new customer application information will be received by the host server and downloaded to the business' s order entry module at pre-determined intervals during the business day. The order entry module will then post an E-mail message to the individual(s) responsible for new account approval indicating that a new customer application has been submitted. At intermittent times throughout the day, the individual will check for new accounts.

When a new account application has been received, the individual will check the information against pre-determined approval criteria. Dependent upon the criteria, the individual may check credit references, banking references and perform analysis on financial information. If the pre-determined criteria are met for a new account, a credit limit is set based on the information and the order is passed on to customer acceptance. The customer is notified that it has been accepted as a customer and of the credit terms that apply.

Certain information from the new account application is then stored in a customer master file. This includes information including company name, address, contact information, references, credit terms and price discount information. If a customer is rejected under the criteria, the application is forwarded to a supervisor who will have the option of gathering additional information including speaking directly to the new customer. The supervisor may override the criteria and accept the new customer. Once a customer has been accepted, the order is forwarded to new order acceptance.

For customer order authorization and acceptance of an existing customer, when an order for an existing customer is received by the host server, the order is "priced" based on a pre-determined price schedule and a pre-determined discount designation for the customer. The priced order will then be sent to the host server and downloaded to the order entry module at pre-determined intervals during the day. The order entry module will receive the information as a new order and check the credit status of the customer that is based on predetermined criteria. If the customer's credit status allows further shipment of product, the order amount is then checked to determine if the order amount in addition to the existing accounts receivable balance and the total of orders previously accepted but not yet billed to the customer (open orders) is less than the credit limit for the customer. If the order amount is less, then the order is passed backed to the server as an accepted order at predetermined intervals during the day.

If the order is rejected under either of the criteria above, a supervisor will be sent an E-mail being notified of the rejection. The supervisor will then be allowed to gather additional information, including speaking directly to the customer. The supervisor may override the criteria's rejection and pass the order to the host as an accepted order.

For order placement with a vendor, when an order has been accepted and sent back to the host server, the server then prepares purchasing information for the vendor. The quantity will be extended at a price determined by a pre-existing price schedule. The part numbers, descriptions, quantity ordered, and shipping information will be included. In addition, the order sent to the vendor will include a sequential purchase order number.

The same information, in addition to the appropriate vendor information, will be sent by the host server to the purchase order module at pre-determined intervals during the day. The purchase order module will then include an open purchase order. For shipment confirmation and invoicing, upon shipment of an order by the vendor, a confirmation will be sent to the host server via the communication link. The confirmation will be sent to the order entry module and the purchase order module at pre-determined intervals during the day. The order entry module will receive the confirmation and match it to the appropriate open customer order. The customer order will then be closed for the items shipped. The order entry module will then extract from the customer master file the necessary information to prepare an invoice. This information will include billing address, E-mail address and contact and payment terms. An invoice is then prepared and then E-mailed to the customer. The invoice will then be posted to the customer's account in the accounts receivable module.

The purchase order module will match the confirmation with the appropriate open purchase order. The purchase order will then be closed for the items shipped. The purchase order will then create a pending accounts payable file which will be ready to be matched to the vendor's invoice when received. When the vendor's invoice is received and successfully matched against the pending accounts payable, an account payable in the accounts payable module will be created and payment will be scheduled according to the negotiated terms included in the vendor master file. The vendor's invoice will be received electronically through the communications link and will be forwarded to the accounts payable model for matching.

For accounts receivable collection, when a payment is received from a customer, it will be posted to the customer's account in the accounts receivable module. If an amount is past due, it will notify the host server. The next time a customer places an order, when the customer dials into the host server, the host server will send a message to the customer notifying them of the past due amount. The notes will become harsher as the receivable becomes aged. The past due amount will also be flagged in the order approval and authorization cycle.

In the business-to-consumer model, the customer's customer (the consumer) will place the order directly through the NMEC system 10 and method, which process the transaction on behalf of its customer and there is no relationship with the consumer. The order and the obligation to fill the order reside with the customer. The NMEC-involved company will be reimbursed a fee based on the revenue associated with the customer's sale. In every case, the consumer will pay the customer for purchased products with a credit card. Typical flow of a business-to-consumer transaction within the NMEC system

10 and method will include the following categories: consumer order placement and credit card authorization through merchant banking system, order placement with fulfillment, shipment confirmation and communication with issuing bank, credit card settlement with acquiring bank, and forwarding of settlement to customer. For customer order placement and authorization through merchant banking system, after selecting products to purchase, the consumer will be directed to input order information. This will include standard credit card information that is the only way to pay for a purchase. When completed, and while the consumer remains connected to the host server, the credit card information is sent through the merchant banking system for approval.

The information will be sent by the host server to a third party front-end processor. The front-end processor will then take the data and put it into a format compatible with a back-end processor that is affiliated with the issuing bank. The issuing bank will then receive the information and authorize or reject the transaction based on its own criteria. If the order is approved, the issuing bank will encumber the credit on the consumer's account for the transaction amount. Whether the transaction is accepted or rejected, the consumer will be notified while still dialed in to the host server. If it is accepted, the order will be sent by the host server to the fulfillment house through the communication link.

For order placement with fulfillment, the order will be received electronically through the communications link by the fulfillment operation. The order will be processed and product shipped to the customer. The fulfillment house will then send a confirmation to the host server notifying it the order has been shipped.

For order confirmation with issuing bank, once confirmation has been received by the host server that shipment has occurred, it will communicate with the front-end processor. It will refer to the original transaction number and provide the actual amount the customer will charge the consumer for the products. The front- end processor will communicate with the back-end processor and the issuing bank will make a charge against the consumer's credit card account.

For settlement with the acquiring bank, the issuing bank through the back- end processor, will notify the acquiring bank of the transaction and the acquiring bank will settle with the issuing bank. The acquiring bank then will deduct the discount fee and deposit the net amount into a pre-determined bank account owned by the NMEC-involved business.

For settlement with a customer, each day, the NMEC-involved business will examine the transactions, including the deposit amount, in its account with the acquiring bank. This examination will be done via the Internet. The NMEC- involved business will calculate the amount of the fee to which it is entitled and will deduct that amount from the amount deposited. It will then send a wire transfer to the customer for the net amount. The net amount will be the total amount billed consumers, less the discount fee charged by the acquiring bank and less the fee charged by the NMEC-company company. Settlement with the customer will occur on a daily basis. In the event where a deposit is received into the account with the acquiring bank on behalf of multiple customers, the procedures above will be repeated for each customer.

The transaction amounts will be recorded on the books of the NMEC- involved company via a journal entry based on the transaction detail provided by the acquiring bank. The entry will include the revenue from the fee deducted from the customer's proceeds.

ADVANTAGES OF THE NMEC SYSTEM AND METHOD Through the NMEC system 10 and method described herein may be used in many different business-to-business applications and business-to-consumer applications, including small office and home office business environments. The NMEC system 10 and method offers Internet-independent communications for conducting E-commerce via a virtual private network (VPN), which is a secure, private, highly reliable communication link between widely distributed users, who receive the computer-readable media distributed to implement the NMEC system 10 and method. In particular, the NMEC system 10 and method may be used with consumers having computer-capability but without Internet connections through Internet Service Providers (ISPs). For example, consumers may use computers connected through telephone lines as well as wireless and/or satellite connections to the NMEC server 12.

The NMEC system 10 and method provide users with a controlled and safe environment for conducting business applications as well as shopping, since it is not possible in the NMEC system 10 and method to be inadvertently swept from a shopping activity to a website which the user does not want to visits, which is possible in Internet-based shopping and browsing. In addition, unlike Internet-based E-commerce, the NMEC system 10 and method does not allow or permit the placement of Internet-based cookies onto the computer of the customer. Also, the NMEC system 10 and method may be used to prevent access by minors to undesirable web sites by virtue of the fact that NMEC consumers are not connected to the Internet or to a website while shopping. In addition, accidental errors in navigation through the NMEC product interactive database cannot result in being taken to a website, let alone an undesirable website.

By virtue of its design and implementation, the NMEC system 10 and method has a generally lower delivery cost of images and editorial content because the service is directly distributed to consumers, so the massive costs of advertising are avoided, such as the typical amount of, for example, 21 % of gross revenues expended by Internet-based businesses on advertising.

In addition, the NMEC system 10 and method is capable of advertising and at the same time combining with the method of distribution of the NMEC system 10 and method. In conjunction with using traditional hardcopy media such as magazines for distribution, the NMEC system 10 and method may also be used in targeted distribution and use. Widely used direct mail techniques may be used to obtain and leverage a broad range of demographic data to select those users who are most likely to conduct E-commerce through the NMEC system 10 and method. The NMEC system 10 and method allows for the storing of customer payment information such as credit card information on the customer's computer rather than on a website. The only time that credit card information is passed from a consumer to another entity is when such information is sent to the NMEC system 10 and its merchant bank for validation. Accordingly, the NMEC system 10 and method handles the settlement account through its merchant bank, and at no time do the retailers and manufacturers of goods and services have access to the consumer's credit card information. This feature offers consumers a higher level of security. The NMEC system 10 is a new media solution to E-commerce combining technologies in a way never before combined and eliminating all of the Internet and WWW problems that have kept the web from serving more sellers and buyers. The NMEC system 10 is the only distributed E-commerce application that utilizes client side application software for E-commerce. The benefits of client side E-commerce are substantial, and include the ability to store all transactional data on the consumer's machine, resulting in greater security and consumer confidence.

The NMEC system 10 does not require a web browser to work and, as a consequence, does not need to be connected across a communications network to a server for successful operation. The NMEC system 10 does not require the Internet to work because it operates using a virtual private network which can, but need not, be accessed via the Internet.

The NMEC system 10 provides for optional ISP Internet access or virtual private network access to server, which is achieved by allowing ISP served consumers to reach the virtual private network by a bridge from one network to another.

The NMEC system 10 allows each individual consumer to have unique pricing or promotional information because there are no HTML pages such as found in web sites, and because the web site offers a universal view to consumers, and the NMEC system 10 can support different information and video at each consumer application.

The NMEC system 10 provides tracking of inventory and locking out items as they go out of stock. The ability to preclude a consumer from buying an out-of- stock item is powerful and is absolutely unique to the NMEC system 10. The NMEC system 10 provides for credit card verification with only the merchant bank and assigning bank having access to the credit card information. The NMEC system 10 collects consumer data and uses it to assist in improving the application software design, thereby making the NMEC system 10 a more and more effective tool for consumers to utilize when shopping electronically.

The NMEC system 10 allows the application software to be improved through the analysis of what design elements work better than others, and what variables have what effects. The NMEC system 10 also allows for preprogrammed notices to be released to consumers. The NMEC system 10 client application can be distributed physically or electronically, and is capable of responding, for example, six times faster than web sites with broadband access.

The NMEC system 10 server connections are as short as forty seconds allowing updates on costs, promotional items, and related information. The NMEC system 10 server connections are in the background, so the consumer is not prevented from shopping or continuing with other tasks on the PC. When the

NMEC system 10 application launches, it updates pricing, availability, etc. The

NMEC system 10 errors, if any, associated with individual consumer information, can be corrected in the background when the application is launched. The NMEC system 10 rich graphics, audio and video are easily supported and run at processor speed, unhindered by any communications constraints.

With the NMEC system 10, large volumes of information are quickly accessed because most of the information arrives along with the application and is updated or modified each time the consumer launches the application. The NMEC system 10 allows different consumers to receive different pricing and offers for different products.

The NMEC system 10 permits order confirmation to be made electronically and available the following time the consumer launches the application or, as an alternative for those consumers who have E-mail, confirmation can be provided via

E-mail. The NMEC system 10 permits the option to browse all items visually. The NMEC system 10 permits the selection of multiple items for purchase, and offers the option to use a credit card for payment. The NMEC system 10 offers the option to establish an account for payment, and the option to electronically submit an order. The NMEC system 10 also provides for the option to calculate sales tax, and to add shipping charges.

The NMEC system 10 allows for the cancellation of an order prior to shipment, and an option to return an item. In addition, the NMEC system 10 offers an option to store shipping addresses for later use without re-entry.

The NMEC system 10 offers an option to check status of orders, and also offers an option to search for products by occasion, by designer, by look, by season, and by style. In addition, the NMEC system 10 offers the option to search by category, such as dresses, coats, skirts, etc., as well as by color, by texture of material, by type of material, by item size, and/or by virtually any criteria appropriate to the goods and/or services. The NMEC system 10 permits consumers to copy files and store them locally on the PC which can be made to interface with the NMEC system 10 application, whereas a browser can not. The NMEC system 10 permits consumers to subscribe to services directly from the application. The NMEC system 10 allows consumers to place an order via a web site without providing access to the site, and permits consumers to mark and view favorite items.

In addition, the NMEC system 10 permits consumers to place items on controlled hold, and the NMEC system 10 also permits sellers to communicate the small remaining inventory balances so that consumers can act before a favorite item is no longer available. The NMEC system 10 also permits objects/items to be displayed in three dimensions, with controllable viewing and orientation. The NMEC system 10 has the capacity to communicate between the application and the server in its own language and therefore the NMEC system 10 allows the consumer or user to engage the application with the language and currency of their preference.

By the foregoing, the disclosed system and method have been disclosed by way of the preferred embodiment. However, numerous modifications and substitutions may be had without departing from the spirit of the invention. For example, while the preferred embodiment discusses distribution of the NMEC system and method via optical means such as CD-ROMs, it is wholly within the purview of the invention to contemplate distribution via microchips and memory cards, or any other electronic alternative including smart cards accessible through kiosks in the manner as set forth above.

In one embodiment, such as the example embodiment shown and described herein, the system 10 and method may receive, process, and display text in English, and receive, process, and display currency data for currencies and prices in U.S. dollars. It is to be understood that different languages and/or currencies may be supported, for example, with the system 10 and method distributed by optical and/or electronic storage media in the French language with a default currency being francs, for distribution and use in French-speaking countries. In addition, the system 10 and method may be embodied on a universal storage media supporting multiple languages and multiple currencies such that, during installation of the system 10 and method on a consumer's computer, customized language and currency settings may be configured for each individual consumer. Accordingly, the invention has been described by way of illustration rather than limitation.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A computer-based method of conducting electronic commerce, comprising the steps of: distributing a computer-readable medium to a plurality of potential consumers, wherein the computer-readable medium includes: a pre-stored interactive database of product information of a plurality of products; and predetermined software for performing graphic-user-interface- based review, selection, and order processing by a respective consumer of selected products from the pre-stored interactive database to generate an order stored in the respective computer of the respective consumer, wherein the predetermined software is installable on a computer associated with a respective consumer, wherein the predetermined software includes functionality to enhance the shopping experience, with the predetermined software isolated from and not necessarily in communication with the Internet; electronically connecting an electronic commerce server to a respective computer of a respective consumer; receiving the stored order to the electronic commerce server; and processing the transmitted stored order at the electronic commerce server for product fulfillment.

2. The method of claim 1, wherein the pre-stored interactive database includes advertisements associated with a portion of the product information.

3. The method of claim 1, wherein the step of distributing includes the step of: targeting consumers to receive the computer-readable medium.

4. The method of claim 1, wherein the computer-readable medium includes optical or electronic storage media.

5. The method of claim 1, wherein the predetermined software stores the order, including credit card information for product purchase, on the respective computer of the respective consumer.

6. The method of claim 5, wherein the step of processing the transmitted stored order includes the step of: fulfilling the transmitted stored order with a retailer, manufacturer, or vendor without transmitting the credit card information from the electronic commerce server thereto.

7. An electronic commerce processor comprising: a communications module for establishing an electronic communications connection to a computer of a consumer and for receiving a pre- stored order therefrom, wherein the consumer received a distributed a computer- readable medium having: a pre-stored interactive database of product information of a plurality of products; and predetermined software for performing graphic-user-interface- based review, selection, and order processing by a respective consumer of selected products from the pre-stored interactive database to generate the pre-stored order stored in the respective computer of the respective consumer, wherein the predetermined software is installable on a computer associated with a respective consumer, with the predetermined software isolated from and not necessarily in communication with the Internet; and an order processing module for processing the transmitted pre-stored order for product fulfillment.

8. The electronic commerce processor of claim 7, wherein the pre-stored interactive database includes advertisements associated with a portion of the product information.

9. The electronic commerce processor of claim 7, wherein the consumer is a member of a plurality of targeted consumers to receive the computer-readable medium.

10. The electronic commerce processor of claim 7, wherein the computer-readable medium includes optical or electronic storage media.

11. The electronic commerce processor of claim 7, wherein the predetermined software stores the order, including credit card information for product purchase, on the respective computer of the respective consumer.

12. The electronic commerce processor of claim 11, wherein the order processing module includes: a fulfillment module for fulfilling the transmitted stored order with a retailer without transmitting the credit card information from the electronic commerce server to the retailer.

13. An electronic commerce system comprising: a plurality of consumers, being recipients of a distributed computer- readable medium having: a pre-stored interactive database of product information of a plurality of products; and predetermined software for performing graphic-user-interface- based review, selection, and order processing by a respective consumer of selected products from the pre-stored interactive database to generate the pre-stored order stored in the respective computer of the respective consumer, wherein the predetermined software is installable on a computer associated with a respective consumer, with the predetermined software isolated from and not necessarily in communication with the Internet; and an electronic commerce processor including: a communications module for establishing an electronic communications connection to a respective computer of a respective consumer and for receiving the pre-stored order therefrom, an order processing module for processing the transmitted pre-stored order for product fulfillment.

14. The electronic commerce system of claim 13, wherein the pre-stored interactive database includes advertisements associated with a portion of the product information.

15. The electronic commerce system of claim 13, wherein the plurality of consumers include: a plurality of targeted consumers to receive the computer-readable medium.

16. The electronic commerce system of claim 15, wherein the computer- readable medium includes optical or electronic storage media.

17. The electronic commerce system of claim 15, wherein the predetermined software stores the order, including credit card information for product purchase, on the respective computer of the respective consumer.

18. The electronic commerce system of claim 17, wherein the order processing module includes: a fulfillment module for fulfilling the transmitted stored order with a retailer without transmitting the credit card information from the electronic commerce server to the retailer.