WO2001073645A1

WO2001073645A1 - Procurement system and method having interactive functionality

Info

Publication number: WO2001073645A1
Application number: PCT/US2001/010529
Authority: WO
Inventors: Dan Lejeskar; Christian Lauritzen; Mikael Jacobsson
Original assignee: Realitybuy.Com, Inc.
Priority date: 2000-03-28
Filing date: 2001-03-28
Publication date: 2001-10-04
Also published as: AU2001247926A1

Abstract

A procurement system and method having interactive functionality. The procurement system utilizes an interactive customer interface (110) that operates over a network (130), such as the Internet. The system requests certain information from a customer related to a product preference to determine the products to be presented. The system interactively presents simulation objects of components and products to the customer to provide interactive functionality. The simulation objects are manipulated by the customer to facilitate the customer's familiarity with the product, increasing customer connectivity with the products and thereby increasing online purchasing of products. The present invention provides the capability for dynamically configuring a product or linking the attributes of a product directly to a database (160). The present invention provides for the seamless integration of product visualization and interaction to the processing of transactions.

Description

S P E C I F I C A T I O N

This International application claims priority to United States application

No.09/537,584, filed March 28, 2000, and entitled, "Procurement System and Method Having

Interactive Functionality." The disclosure of the foregoing is incorporated by reference herein

as if set forth in full herein.

PROCUREMENT SYSTEM AND METHOD HAVING

INTERACTIVE FUNCTIONALITY

BACKGROUND OF THE INVENTION

Field of Invention

The present invention relates generally to a network-based procurement system, having

customer input and interactive functionality, that increases customer connectivity by delivering

the ability online to see components and products, interact with components and products, and

ultimately purchase these components and products.

Description of Prior Art

Recently, there has been a push to move both the business (B2B) supply chain and the

consumer (B2C) supply chain online ~ over the Internet; both manufacturers and retailers are

transforming their businesses with Web-enabled capabilities. This online procurement allows the streamlining of the procurement process. Manufacturers and retailers recognize that value

can be created when online purchasing is used to reduce supply chain costs. To realize this

value, in the online business-to-business (B2B) supply chain and in the business-to-consumer (B2C) supply chain, it is necessary to optimize the procurement functionality between

manufacturers and resellers, and between resellers and their buyers. To optimize the

procurement process, increasing the efficiency of the customer's ability to select the products

or components desired, and then effectively execute the order-to-delivery process is crucial.

While online purchasing permits the reduction in supply chain costs, this methodology

has its shortcomings. Moving the purchasing function online often removes the ability of the

customer to connect (i.e., associate) with the product. Having the ability to see a product and

interact with that product before purchasing increases the association with the product - that

is, it increases the connectivity between the customer and the seller's products. A high degree

of connectivity is necessary to insure increased procurement by the customer. Numerous online

systems are currently in use that provide for the expeditious requisition of products and

components, and then facilitate payment and delivery. However, this online procurement

methodology of the prior art does not provide for adequate customer connectivity. The

standard Web interface — a product catalog of photographic images ~ remains a stumbling

block to increasing the connectivity between the customer and the seller's product. No online

procurement systems exist that provide the high degree of connectivity desired.

In recent years, businesses have endeavored to increase the procurement connectivity

of their online catalogs. Various approaches have been widely used to deliver product

information over the Internet. Sellers attempt to creatively display and describe their products

to customers using their web pages. Manufacturers lay out and display product catalogs on web

pages having content, such as text, pictures, sound and video. The technologies for delivery of product images in online catalogs employ images of photographs and artistic renderings

(including those that are computer generated). These images are delivered to the customer as photographs, pictures, stitched 2D pictures where multiple images are used to deliver a scrolling panorama, canned or streaming 2D media including video and canned or streaming

3D pictorial objects (e.g., stereographies). More recently, collections of photographic images

are provided that permit the customer to view the product from different vantage points through

photographic images taken from those vantage points.

For customer Internet access, catalog web pages are stored for later display on a web

server that responds to Hypertext Transfer Protocol (HTTP). A catalog web page is accessed

using a browser, e.g. , Netscape® Communicator or Microsoft® Internet Explorer. In response

to a customer query, a browser requests a catalog page from a web server using HTTP. The

web server responds to the request by returning the catalog page using HTTP. The web page

is typically encoded using HyperText Markup Language (HTML). The browser interprets the

HTML to format and display the catalog pages.

A great variety of enhancements to HTML are available, and many of those implement

the image deliveries previously discussed. An online catalog can use these enhancements by

embedding in its HTML codes references to these enhanced image files. To correctly present

these files and their enhanced interface, the browser must often be configured with an

appropriate plug-in. When encountering an HTML enhancement for the first time, most

modern browsers are configured to query the browser user if the download of an appropriate

plug-in is desired. If directed to do so, the browser searches a master list of available plug-ins

and begins a download. After successful download and installation of an appropriate plug-in,

subsequent encounters with that type of HTML enhancement will be correctly rendered in the

catalog page. Popular plug-ins include Adobe's Acrobat Reader® and Apple Computer's

QuickTime® and QuickTime VR®. These enhanced image viewers permit the customer to

view products and components according to the predetermined images provided. Customers may browse through a catalog to identify products of interest, to obtain specific product information and to electronically purchase products after reviewing product inforaiation. Yet,

there still is no interactivity between the product and the customer online; the ability to pick up,

freely turn and manipulate a product is not possible.

In view of the foregoing, there is a need for an interactive procurement system and

method that overcomes the deficiencies of the prior art.

SUMMARY OF THE INVENTION

The present invention provides a procurement system and method based on the use of

3D simulation objects. Simulation objects provide a 3D model of a product or component.

Further, a simulation object can include codes for their own manipulation or interaction with

other simulation objects. Simulation objects are typically rendered from polygons, textures,

colors, rules of behavior (e.g., equations of motion, physically based modeling) and the like.

A simulation object viewer is preferably configured as a plug-in for a browser. This allows a customer to orient and interact with simulation objects from within their browser, by using

input devices such as a keypad, mouse, touch sensitive screen or other input device. Simulation

objects can be moved and re-oriented with respect to the customer, or the objects can remain

stationary and the customer can move around them. Simulation objects can be taken apart, or

components can be added. Simulation objects can be manipulated. A close, intuitive

relationship is created between the customer and the displayed simulation obj ect because of the

interactivity provided.

Use of simulation objects provides a method for exploring and examining objects and

phenomena in a natural and intuitive way that exploits man's highly developed skills in visual

recognition. 3D spatial processing capabilities are matched with the computer's representation

of objects. Use of the system and method of the present invention conveys to a customer a level

of personal presence with a remote product. A visually-coupled system is created that presents the products alone, as part of other products, and/or in various real-world environments.

Unique product offerings are showcased through visualization, configuration and selection. For

many products, it is desirable to insure that the individual components of a product fit together,

or interact in a manner to meet the customer's needs. A customer may need to identify a

component within a product, and the attributes of that component. Dynamic computer graphic

displays of simulation objects help with the understanding of how various parameters interact

with each other. Provided is the ability for the customer to see the products, and interact with

the products before the purchase. Thus, the present invention addresses the need for an

interactive method for improving procurement connectivity and obtaining increased

procurement functionality by providing a process for interactively displaying components and products for sale over the Internet.

A system and method for delivering purchasing information through a computer

network such as over the Internet or the World Wide Web is provided. Customers can establish

a bi-directional communication link, preferably log into the system, then browse among

simulation objects of available components and products, interact with the components and

products through the proxy of their simulation objects, and ultimately place an order online.

The system merges interactive 3D simulation objects of the products with inforaiation about

the products and creates a 3D viewable object for viewing and manipulating by the customer.

Simulation objects implemented in an online products catalog provides for extensive

customer interaction with the products being offered. By making products and components available as simulation object representations, a higher-quality and more precise procurement

evaluation of the products is possible. The object is manipulated independently, or as part of a group of objects or components. This significantly enhances the customer's ability to understand the product inforaiation, to perceive the product, and to visualize the product or components.

A method for product procurement consistent with the present invention may be

initiated by the requesting of information from a customer at a terminal connected to the

Internet. The customer may provide the information requested through a remote server

maintained by a merchant. The customer is logged in to a web page that is the starting point

for each session. The customer is provided with an interface from which all the major functions

of the merchant's system can be reached. From the interface the customer may select various

components and products of interest to the customer. The customer's selection information is

processed by the merchant's server.

In the present invention, the simulation obj ects of component and product are preferably

stored as data in a database and provided on demand, online to the customer. Typically, a

relational database is used. The online system interfaces with the database to access, transfer

and display product information. A database management system (DBMS) is used to build the

database and to operate on data within the database. The DBMS stores, retrieves and modifies data associated with the database.

Simulation objects of components and products from the database include update

dynamics to provide that the changes of the properties (position, orientation, configuration, etc.)

of the objects appear to the customer to be in real-time (i.e., the behaviors of the simulation objects appear realistic). In addition, audio feedback may also be provided.

The customer receives fully interactive and configurable simulation objects depicting

the components or products. In addition, the customer may be provided with a hybrid of

traditional images enhanced by simulation objects. Various points within or behaviors of the simulation objects may be linked to sound or video. Once the viewer has manipulated the

product and component images, he or she may select to purchase it. The customer then provides the information necessary to process the transaction.

In another embodiment of the present invention, a single server is provided that

implements multiple, online catalogs that appear discrete. The server communicates bi-

directionally with customers, and to and from it information flows for products from more than

one merchant. Requests for product viewing are associated with a particular merchant based

upon the online storefront visited by a customer, or upon the credentials presented by a

merchant. Requests result in merchant specific product information being presented.

The present invention facilitates customer/seller interaction and customer connectivity.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the

specification, illustrate presently preferred embodiments of the invention and, together with the

preceding general description and the following detailed description, explain the principles of

the invention.

In the drawings:

FIGURE 1 is a retrieval process diagram of a procurement system and method

implemented over the Internet consistent with the present invention;

FIGURE 2 is an exemplary database table containing data representative of simulation

objects used to implement a procurement system and method consistent with the present

invention;

FIGURE 3 is a flowchart for a prior art procurement system;

FIGURE 4 is a flowchart of a method of procurement of products consistent with the

present invention; FIGURE 5 is a flowchart of another method of procurement of products consistent with

the present invention;

FIGURE 6 is a flowchart of an alternative method of procurement of products consistent with the present invention;

FIGURE 7 is a data flow diagram for providing product data and simulation objects to

and from a multiple customer and non-customer user procurement system and method consistent with the present invention;

FIGURE 8 is an example of a functional diagram of one system architecture for a

procurement system and method consistent with the present invention;

FIGURE 8 A is an example of a functional diagram demonstrating the scalability of the

system architecture for a procurement system shown in FIGURE 8;

FIGURE 9 is a flowchart for a multiple customer and non-customer user procurement

system and method consistent with the present invention;

FIGURE 10 is a graphical user interface consistent with the present invention;

FIGURE 11 is a graphical user interface highlighting the log-in location for a customer

to access the procurement system of the present invention;

FIGURE 12 is a graphical user interface consistent with the present invention

highlighting the log-in area and the feature area;

FIGURE 13 is a graphical user interface consistent with the present invention denoting

the location of the customer interface to begin the procurement process;

FIGURE 14 is a graphical user interface consistent with the present invention denoting

the location of the customer drop down boxes for a customer to select the type of products to

be viewed and for which information is to be obtained; FIGURE 15 is a graphical user interface consistent with the present invention presenting the requested simulation objects, product information and purchase order area;

FIGURE 16 is a graphical user interface consistent with the present invention

highlighting the requested simulation objects and product information, and the purchase order

area;

FIGURE 17 is a graphical user interface consistent with the present invention presenting

the requested simulation objects, product information and purchase order area, and further

highlighting add-on components for a product;

FIGURE 18 is a graphical user interface consistent with the present invention presenting

having an add-on component added to the product and depicted as a simulation object;

FIGURE 19 is a graphical user interface consistent with the present invention having

a drop down box for a customer to select additional products to be viewed and purchased and

for which product information and simulation objects may be obtained. DETAILED DESCRIPTION OF THE INVENTION

Embodiments consistent with the present invention address the need for increased

customer connectivity by providing a 3D interactive procurement system and method. The procurement system and method described herein may be implemented over a variety of

platforms, including wide area networks (WANs), local area networks (LANs), or CD-ROMs. Nevertheless, for purposes of setting forth the preferred embodiment of the present invention,

the system and method of the present invention is described with regard to the Internet.

Figure 1 is a diagram of a procurement system 100 having interactive functionality

implemented over the Internet consistent with a preferred embodiment of the present invention.

Procurement system 100 includes a customer terminal 110, a web browser 120, an Internet 130, a HTTP server 140, an application server 150, and a Simulation Object Database Management

System (SODBMS) 160 including a Simulation Object Database (not shown). Alternatively,

HTTP Server 140 and application server 150 may be combined as a single server. One skilled

in the art will recognize that the procurement system 100 may include more or less components

depending on the desired customer environment. For example, procurement system 100 may

include additional servers for handling a high volume of customers. Moreover, procurement

system 100 may operate as a store-front having multiple servers and multiple merchants. The

HTTP server 140 may also act as a store front and communicate directly with merchants who

maintain their storefront on the application server 150 over Internet 130 or via another

communication channel (not shown).

Customer terminal 110 is preferably a stand-alone computer terminal that is configured

to communicate over Internet 130 (e.g. , using Terminal Control Protocol/Internet Protocol, that

is, TCP/IP). To facilitate this operation, customer terminal 110 includes components typical

to an Internet-ready computer terminal, such as a processor, memory, input/output terminals,

client software (e.g. , web browser 120), and modem (or similar communication device). Web

browser 120 is capable of displaying and manipulating simulation obj ects. This capability may

be an inherent feature, such as is found in EON Reality Viewer, Macromedia Flash, and/or

Panoramic Environment Viewers, or this capability may be supplied by a plug in as common

for plug ins used by Microsoft® Internet Explorer® and Netscape Communicator®. The

viewer enabled web browser 120 communicates with the web page and the database storing the simulation objects.

When a customer first directs his web browser 120 to a merchant web site that employs simulation objects, the web browser 120 will detect that the needed plug in (or viewer) must

be downloaded (this is standard browser functionality). The customer can choose to download the recommended plug in, which is ordinarily downloaded, installed and loaded dynamically,

and is thus in a few moments ready to display simulation objects. In subsequent visits to this

or other websites employing simulation objects of the same type, no further plug in downloads

will be required: the plug in software is already present and ready to operate.

Once equipped with the simulation object plug in, a web browser 120 requests and

receives simulation objects. Simulation objects are customized, configurable entities. They are

displayed and manipulated via the web browser plug in. When these configuration choices are

made.

The integration of the simulation objects with the components of a web centric

procurement system creates the improved connectivity procurement environment. Allowing the

customer to choose components, configure components, and through their virtual experience

gain enough familiarity with the product or components to enable a purchase decision.

Upon execution of the web browser 120, a customer can access HTTP server 140 over

Internet 130 by inputting the appropriate uniform resource locator (URL) into the web browser

120 (e.g. , "www.realitybuy.com"). Alternatively, web browser 120 may be preconfigured with

one or more URLs so that a URL may be selected b y a customer rather than entered.

HTTP server 140 is preferably a computer dedicated to communication with the customer for implementing the procurement system consistent with the present invention in

response to external requests from customer terminal 110. HTTP server 140 receives a call for

a web page by the web browser 120, which passes the HTTP server 140 the query parameters.

The query parameters from the web browser 120 include an embedded reference for a simulation obj ect 200, which is sent as a secondary request to the application server 150 for the

simulation object. The HTTP server 140 receives the query parameters and passes a web page

request 145 to application server 150. The application server 150 queries the Simulation Object Database Management System (SODBMS) 160 for the simulation (not shown). The

type of application server is not critical; it may be based on ASP, JSP, CGI or any other process

capable of querying the SODBMS 160. The simulation object 200 may be stored within the

SODBMS in a Binary Large Object Field (BLOB) 165.

The HTTP server receives the secondary request and preferably sends it to an

application server for processing. The application server then runs the query through the

SODBMS, and retrieves the simulation object data as a BLOB (Binary Large Object) field

from the database. Alternatively, a table is returned containing data representing multiple simulation objects.

In Figure 2 there is shown a sample of a BLOB 165 containing the simulation object

200. A typical BLOB 165 containing a simulation object 200 (not shown) will provide the field

type, and the field description. Thus, a simulation object 200 is stored dynamically, rather than

statically as a photograph or still image of a product would be stored. The simulation object

200 is linked to a product database containing information about the products and components.

As components of a simulation object 200 are changed by the customer, the view of the

simulation object 200 dynamically changes for the customer. As the dynamic changing of

components of a simulation object 200 create different products, the product identification

number, typically a SKU may be identified by a query to the product database, from the product

information stored in the product database, and information about product availability provided

to the customer. If product information for a particular product configuration does not exist in

the product database, a new product identification number may be generated and added to the product database, or the new product configuration may be provided to the customer as a list of component parts. Figure 2 is a sample a table of simulation object data in the SODBMS.

For an actual catalog, the table would commonly contain hundreds of rows, and for many purposes may contain more than tens of thousands (e.g. the number of spare parts carried by a automobile manufacturer or an appliance repair service).

Referring again to Figure 1, the SODBMS 160 returns BLOB 165 to the application

server 150. The application server 150 then passes the BLOB 165 back to the web browser

120; the resultant simulation object data is then returned to the customer's browser via the

HTTP connection already open. The web browser 120 sends the BLOB imbedded in and

HTML document to the customer terminal 110 from the HTTP server 140 over the Internet 120.

The customer then views the simulation object 200 at the customer terminal 110.

In Figure 3 there is shown a flowchart for a prior art online procurement method. To

use a prior art method, a customer first accesses a merchant website hosted by a server (Step

300). Upon accessing the merchant website, the customer may conduct a search for products

and product information (Step 305). The customer may scroll through the topics of products

that he wishes to view. Upon receipt of the customer's selection, the customer's inputs are used

to select appropriate product and/or product areas. The customer then views the products and

product information selected (Step 310). After viewing the products and product information,

the customer may decide to purchase the product (Step 315). If no decision is made to

purchase, the customer may start from the beginning (Step 300), continue by beginning a new

search (Step 305), reviewing the results of his present search (Step 310), or simply return to the

home page, or the customer may log off.

In Figure 4 there is shown a flowchart for a method of implementing procurement

system 100. To use the system of the present invention, a customer first accesses a merchant website with a web browser 120 configured with a viewer to view simulation objects 200 (Step

400). Upon accessing the merchant website, the customer may conduct a search for products

and product information (Step 405). The customer may scroll through the topics of products that he wishes to view. The customer may then select the product or product areas that he desires. Preferably, the customer's selection from the procurement system 100 is made rapidly

accessible by allowing the customer to type the first few letters of a product or product area.

Alternatively, products and/or product areas may be presented hierarchically, whereby a

customer would first select a category (e.g. , automobiles) from among a short list of categories.

An embodiment may use a search engine, where keywords entered limit the list to selections

containing at least a majority of the keywords. Selection strategies such as these and others will

be well known to those skilled in the art. Upon receipt of the customer's selection, the

customer's inputs are used to select appropriate product and/or product areas. One skilled in the

art will recognize that the procurement system 100 may be configured to output any

combination of data relating to products and/or product areas. The customer then views the

products and product information selected, with the products launched as simulation objects

(Step 410). Product selection and simulation object launch may be a single step, or may be a

series of steps. In Figure 4, it is represented as a single Step 410.

With the product information and simulation objects, a customer may be provided with

both general information and details about a particular product. When viewing the product, the

customer will typically receive a description of the product, and be able to view the product as

a simulation object. Product availability, and other inforaiation such as price, weight, shipping

information, etc. may also be provided.

With products and components configured as simulation objects 200, the customer will be able to look at the product in more detail. The customer will be able to interact with the

product as if were in front of him or her (Step 415). There will be the ability to look at the

product from a 3D aspect, being able to rotate, examine and try the functionality. For example,

a customer may be able to open and close a car door, adjust the seat, and open the trunk. Alternatively, products may also be provided as 2D or 3D images having components within these images configured as simulation objects. After interacting with the products and viewing

product information, the customer may decide to purchase the product (Step 420). When

purchasing, the customer will specify shipping requirements, such as ship date, ship to, bill to,

etc. Quantities may be adjusted here, should the customer desire to determine any price

reduction based on quantity purchases. An order is then placed, and the purchase and goes through a transaction handling process.

If no decision is made to purchase, the customer may continue (Step 425) by starting

from the beginning (Step 400), continue by beginning a new search (Step 405), reviewing the

results of his present search (Step 410), or simply return to the home page, or the customer may log off. Alternatively, there may be provided the further option of saving the product

information and simulation objects viewed for later review. Later viewing off line may be

accomplished by saving the product information and simulation objects in the web browser's

cache.

In Figure 5 there is shown a flowchart for an alternative method of implementing

procurement system 100. The procurement system 100 of Figure 5 is similar to that of Figure

4. A customer first accesses a merchant website with a web browser 120 configured with a

viewer to view simulation objects 200 (Step 500). Upon accessing the merchant website, the

customer may conduct a search for products and product information (Step 505). The customer

then views the products and product information selected, with the products launched as simulation objects (Step 510).

With products and components configured as simulation objects 200, the customer will

be able to look at the product in more detail. The customer will be able to interact with the product as if were in front of him or her (Step 515). There will be the ability to look at the product from a 3D aspect, being able to rotate, examine and try the functionality. After

interacting with a product, the customer may decide to select other related products or

components to add to the product. This may entail changing the color, size, quantity, etc. For

example, a customer may select a product such as a car to be presented as a simulation object.

The customer may then add an after market product such as a bike rack to a car. The customer

may attached the bike rack, put a bike in it, and then remove it from the car. This process of

configuring a final product based on trying various products and components and then making

a selection is Step 525. The customer may decide to purchase the configured product (Step

530). If the product that is configured corresponds to a particular product number, that product

number is noted as the purchased product. If the product that is configured has not been

assigned a particular product number, then the newly configured product may be assigned a

product number, or, alternatively, the product may be purchased as a bill of materials listing

its components.

If no decision is made to purchase, the customer may continue (Step 535) by starting

from the beginning (Step 500), continue by beginning a new search (Step 505), reviewing the

results of his present search (Step 510), or simply return to the home page, or the customer may

log off. Alternatively, there may be provided the further option of saving the product

cache.

In Figure 6 there is shown a flowchart for an alternative method of implementing

procurement system 100. The procurement system 100 of Figure is similar to that of Figs.4

and 5. A customer first accesses a merchant website with a web browser 120 configured with

a viewer to view simulation objects 200 (Step 600). Upon accessing the merchant website, the customer may conduct a search for products and product information (Step 605). In the

procurement system shown in Figure 6, the customer knows information about a component

part of a particular product, and desires to obtain more information about the component part.

The customer may generally know the product, but may not know, for example, the name of

the part, or how that part fits together with the other components to make the product. The

customer desires this information, and may, or may not want to purchase the component part.

As before, the customer views the products and product information selected, with the products

launched as simulation objects (Step 610).

be able to look at the product in more detail (Step 615). The customer is able to take apart the

product to ascertain the component part of interest (Step 620). For example, the customer may

remove the body of a car represented as a simulation object to view the exhaust system. The

customer may then pull apart the exhaust system to identify a particular component part of the

exhaust system.

This process of finding a component part based on trying various products manipulating

the component parts is Step 625. The customer may decide to purchase the configured product

(Step 630).

If no decision is made to purchase, the customer may continue (Step 635) by starting

from the beginning (Step 600), continue by beginning a new search (Step 605), reviewing the

results of his present search (Step 610), or simply return to the home page, or the customer may

cache. The procurement system 100 of the present invention may be used in an online

marketplace environment. Figure 7 provides the data flow for product data and simulation

obj ects to and from procurement system 100 for a multiple merchant environment. Simulation

object developers 700 generate simulation objects of products and components that are

uploaded through a database upload application 705 to a simulation object database 715 having

a SODMS 160. Product information for the products and components is supplied (and updated)

by the merchants 710. Product information is uploaded through a database upload application

705 to a product database 720. An online multiple merchant marketplace 725 is provided. The

digital marketplace is a fully integrated commerce platform for providing multiple merchant

product information and procurement capabilities. Core transactions and interface provide the

entire procurement process, including, for example, product catalog and search engines, real¬

time tracking and receiving, routing and approval. Typical graphical user interfaces (GUIs) are

provided as well as management of the interfacing of multiple customers with multiple

merchants. The online multiple merchant marketplace 725 may be implemented using

TRADEX® Commerce Center software by Ariba, or the like.

The online multiple merchant marketplace 725 shown in Figure 7 provides marketplace

web pages 730 for customers. Access to these web pages 730 is either direct, or may be

through links from the web pages 745 of other sites. Once the online multiple merchant

marketplace 725 is accessed, customers are provided with product information from the product

database 720 and simulation objects 200 as more fully described with reference to Figures 4

through 6. Non-customer users of the simulation objects 200 may be provided with direct access to the SODMS 160 and simulation database 715.

In Figure 8 there is shown an architecture diagram of a typical implementation of the

procurement system 100 of the present invention in a multiple merchant marketplace environment. The multiple merchant marketplace environment may be implemented using an application server 800, providing interoperability and coordination between the various

elements of a procurement system 100, such as shipping, purchasing, accounting, inventory

control, etc. The application server may be a Java based application server, but any comparable

application server may also be used. If the application server 800 is a Java based application

server, it may included several Java classes which are called as and when required to perform

specialized set of operations. The functional modules of the procurement system 100 may be

implemented using these Java classes or comparable classes of another application. For

example, a class or collection of classes may implement product customization, while another

implements the ordering process. Subsystems that are a part of the application server 800 may be preferably designed as Java Beans, but those skilled in the art may find other architectural

choices better fit their particular circumstances.

The application server 800 as shown in Figure 8 provides connectivity to the product

database server 805 for the online multiple merchant marketplace. A database connection 820

is shown between the application server 800, and in Figure 8 the database connection 820 is

a Java database connection (JDC). The database server typically contains the product

information and functions necessary for implementation of the related online multiple merchant

marketplace 725 shown in Figure 7. A database implementation such as a SQL relational

database, provided by various vendors, for example, Oracle 8i may be used for the database

server 805 or for the simulation object database server 810, or both. Using a JDC for the

database connection 820 for implementation, and using an amount of parameterization provides

for future migration, if desired, to other Javabased database configurations. The SODBMS 160

may be implement on a simulation engine 815 using a Java application. Typical hardware for application server 800 or simulation engine 815 may be a Sun Solaris® or Weblogic® Application Server.

The application server 800 may provide for the determination of the location of a

particular simulation object 200 located in the simulation object database server 810 through

an API 825 that may be a Java API. Enterprise Java Beans (EJB) 830 may be used to provide

the product information to the HTTP server 140. The HTTP server 140 is designated as a

Netscape Directory Server 835 or equivalent. Simulation objects 200 are received from the

simulation objects engine 815, and product information is received from the application server

800. The simulation objects 200 and product information are linked and transmitted by the

HTTP server 140 to the customer. Because Java is a platform independent language, for the

present invention, the system architecture may alternatively be configured so a Java based

application server 800 could possibly interact with external Java based management information systems/enterprise resource planning systems (MIS / ERP systems). For other non-

Java based MIS/ERP, most ERP/MIS system have available support and interfaces for Java.

In the absence of such a availability, the application server 800 would need to make

connections to these resources using interoperability technologies such as CORBA (common

object request broker architecture) or COM+.

The procurement system 100 of the present invention may also include dynamic loading

of files from an Internet URL or compatible file.

A secure socket layer (SSL) and firewall 850 may be used to provide access control and

content security for the procurement system 100. As the data exchanged in the procurement system 100 may be commercially sensitive, the system architecture may be SSL secured with server and client authentication. This would imply that only authorized/identified customers

would be allowed access. The client identification/authentication may be implemented using client certificates; the customers' operations such as issuing quotes, discounts orders etc. will

be traced back to the customer. The server certificate facilitates encryption of the transferred

data (and its subsequent decryption at the receiving end), so that a secure network is realized

comprising of all the participants of the online multiple merchant marketplace environment.

In Figure 8A, it is noted that the system architecture of Figure 8 provides system

scalability. Scalability is necessary to maintain procurement system functionality and

efficiency as the number of merchants and customers participating in the multiple merchant

marketplace increases. Thus, with the procurement system 100 of the present invention, the

data that is required appears seamlessly obtained. Further, a cluster of geographically

distributed resources (e.g., server hardware) may be efficiently utilized in a manner transparent to the customer.

In another embodiment of the present invention shown in Figure 9, non-customer users

are provided with an access system 900 having web-based front ends to view and try products

and components. Various classes of non-customer users may include, but are not limited to,

those responsible for shipping (who make sure products get shipped, or make sure catalog

represents current shipping costs), buyers (who check inventory levels for reorders, monitor for

popular/unpopular products, or place orders with other entities), a merchants employees, etc.

Each class will have differing demands and will interact with various kinds of resources to

conduct their commerce operations.

For only viewing and trying a product, browser 920 is an augmentation of a web

browser 120, or, alternatively another web-based front end may be implemented with special

code to display and manipulate simulation objects. In addition to a plug in, an Active X

Control, JAVA Applet, or other relatively portable, easily integrated module may be used. The

web browser 920 makes HTTP requests to the web server (not shown), but the result is a corresponding web page retrieved and processed by the application server (not shown). The

application server makes the necessary connections to the SODMS, or to an external resource

like an MIS/ERP system for performing any operations as required by the customers.

Non-customer user operations on these pages are again conveyed using the HTTP protocol to

the web server, and in turn to the application server. The application server receives these

events and performs the requisite 'event-processing' and returns results to the customers, as

appropriate. After retrieving the data from these resources, and performing the necessary

processing on them, the page sent to the customers' browser for display. This type of

integration to other commerce oriented back-end systems is well known in the art. Particularly

unique to the present invention is the enhancement to the activity provided by the presence of

simulation objects representative of the products.

FIGURE 10 is a graphical user interface (GUI) 1000 for using the multiple merchant

marketplace environment consistent with the present invention. GUI 1000 is an example of a multiple merchant marketplace home page. GUI 1000 may be generated on the screen of

customer terminal 110 remotely (e.g., HTTP server 140). The customer interacts with

procurement system 100 through GUI 1000. One skilled in the art will recognize that GUIs

described herein represent just one example of a user interface for procurement system 100. Other GUIs representing different methods consistent with the present invention may also be

displayed to a customer.

GUI 1000 first requests the customer to enter identification information. As shown in

Figure 11, GUI 1000 in the log in area 1105, information such as a name and password may be requested. (Plugs in or viewers may be downloaded previously from an introduction page (not shown).) GUI 1000 may be provided with enhancements such as a feature section 1205

highlighted in Figure 12 that features selected products and components. In Figure 13, entry into the multiple merchant marketplace is effected by using the menu 1305 requiring the

customer to choose from the predetermined criteria. Once the customer has made a selection,

categories of available products may be available in drop down menus as shown in Figure 14.

For example, in GUI 1000, the customer must select from a plurality of subject areas (Step

1405). The drop down menus of GUI 1000 shown in Figure 14 request information pertaining

to products, products areas, particular merchants, etc. Each product area includes a drop down

menu for selection of a product type within the product area (Step 1410). Each product type

includes a drop down menu for selection of product listings (Step 1415). Product listing may

also be displayed according to availability according to country, or some other identified criteria.

The GUI 1000 provides that a customer may select to review information about a

particular product and one or more components of that product at the same time. For example,

in Figure 15, the customer has requested information about a Jeep® Grand Cherokee®. GUI

1500 of the present invention provides for the customer to see a Jeep® Grand Cherokee® and

several after market parts. In addition, the customer may search through component parts of

a product or view component part of that product. A simulation object 1505 of a Jeep® Grand

Cherokee® is provided for the customer to interact with the product. The customer may view

the simulation object 1500, and manipulate and interact with the simulation object 1505 using

an input device to manipulate the simulation object 1505. Various component parts of the

simulation object 1505 may also be viewed by, for example, removing the body of the

simulation object 1505 (not shown).

If the customer desires to purchase the product, the customer is prompted to input

product information (Step 1605) into the product selection fields 1610 as shown in Figure 16. The merchant information is may also be requested using pop-up menus or other means known in the art. After entering product selection information into GUI 1500, the customer can

continue to view and interact with other products and components, and add those selected to

the product information fields 1610. For example, in Figure 17, the customer has selected to

view a component part 1705 — a wheel. In Figure 18 the component part 1705 is featured. The

component part 1705 is shown as an image, and the wheels of the simulation object 1505 have

been replaced with component part 1705 creating new simulation object 1805.

If the customer desires to purchase the product depicted as new simulation object 1805,

the customer is prompted to input product information (Step 1605) into the product selection

fields 1610 as shown in Figure 18. The customer may then continue to view and interact with

other products and components, and add those selected to the product information fields 1610.

Alternatively, the customer may select another product area, product type or product (Step

1905) as shown in Figure 19, and continue the procurement process of the present invention. The customer may configure, re-configure by, for example, adding or subtracting components)

any product or components desired. When the customer has completed the information

requested in the purchase fields, the purchase order would be routed through the fulfillment

process. The fulfillment process typically would include a confirmation of the customer's order, confirmation of availability, shipping and fulfillment and online billing.

While only some embodiments consistent with the present invention have been

described, those skilled in the art will understand that various changes and modifications may

be made to these embodiments, and equivalents may be substituted for elements in these embodiments, without departing from the true scope of the invention.

In addition, many modifications may be made to adapt a particular element, technique

or implementation to the teachings of the present invention without departing from the central

scope of the invention. Therefore, this invention should not be limited to the particular embodiments disclosed herein, but should include all embodiments falling within the scope of the appended claims.

The improved connectivity procurement process enables a customer to, over the Internet

or in an application, view, examine, understand and even configure products. After this, the

customer can proceed to buy the product with, if selected, the preferred configuration. The

present invention provides the elements necessary to achieve integration and interoperability with external systems.

Claims

We claim:

1. A procurement system having interactive functionality, comprising:

a customer terminal for exchanging product data with a product data storage device,

said product data comprising at least one simulation object;

said customer terminal capable of displaying said at least one simulation object for

manipulating by a user of said customer terminal.

2. A procurement system as claimed in claim 1 where said product data storage device is

a server.

3. A procurement system as claimed in claim 1 or in claim 2 wherein said customer

terminal further comprises a system for placing and fulfilling product orders.

4. The system of claim 1, 2 or 3, wherein the communication between the catalog server

and the customer terminal takes place over a network.

5. A procurement system having interactive functionality, comprising:

means for storing a simulation object of a product;

means for displaying said simulation object of a product; and,

means for providing customer interaction with said simulation object when said

simulation object is displayed.

6. The system of claim 5, wherein means for providing customer interaction with said

simulation object when said simulation object is displayed takes place over a network.

7. A procurement system having interactive functionality, comprising:

said product data comprising at least one simulation object;

said customer terminal capable of displaying said product data for manipulating said

simulation object.

8. A procurement method having interactive functionality comprising the steps of: creating a simulation object of a product;

displaying a simulation object of a product at customer terminal;

providing for a customer to interact with said displayed simulation object at said

customer terminal.

9. A procurement system having interactive functionality with a product, comprising:

a customer terminal configured to exchange product data with a product data server;

said product data server having product data including at least one simulation object,

said product data server in communication with said customer terminal, and providing to said

customer terminal said simulation object;

whereby said customer terminal creates an interactively controllable display of said

simulation object representative of said product.

10. A procurement system having interactive functionality with a product as claimed in

claim 9, said customer terminal further capable of handling purchase request for said product.

11. A procurement system having interactive functionality, comprising:

said product data comprising at least one simulation object of a product and at least one

simulation of a component related to said product;

said customer terminal capable of displaying said at least one simulation object, and

said customer terminal capable of displaying said at least one simulation object and at least one

simulation of a component related to said product, for manipulating and configuring by a customer.

12. A procurement system as claimed in claims 9, 10 or 11, said product data further

comprising an order form for said product.

13. A procurement method having interactive functionality comprising the steps of:

creating a simulation object of a product;

storing a simulation object of a product;

displaying a simulation object of a product at customer terminal;

providing for a customer to interact with said displayed simulation object at said customer terminal.

14. A method of providing an online merchant marketplace having procurement interactive

functionality comprising the steps of:

creating a web page capable for providing at least one product of a merchant available

for purchasing from said web page;

creating a simulation object of said at least one product for displaying and manipulating

on said web page;

providing for purchasing said product online at said web page.

15. A merchant marketplace having procurement interactive functionality comprising:

an online catalog of product data for at least one product,

said product data for at least one product including a simulation object of said

product;

a customer terminal for displaying and manipulating said at least one product.

16. A merchant marketplace having procurement interactive functionality as claimed on claim 15, further comprising an online purchasing of said product