NOMAUACAAA
`
`US 20050144082A1
`
`as) United States
`a2) Patent Application Publication (10) Pub. No.: US 2005/0144082 Al
`
` Coolmanetal. (43) Pub. Date: Jun. 30, 2005
`
`
`(54) SYSTEMS AND METHODS FOR ORDERING
`FROM MULTIPLE VENDORS
`
`Publication Classification
`
`(76)
`
`Inventors: Jeron Wayne Coolman, Escondido, CA
`(US); David Ryan Placko, Vista, CA
`(US); Tuhin Ghosh, Valley Center, CA
`(US)
`
`Correspondence Address:
`TRAN & ASSOCIATES
`6768 MEADOWVISTA CT.
`SAN JOSE, CA 95135 (US)
`
`(21) Appl. No.:
`
`10/747,929
`
`(22)
`
`Filed:
`
`Dec. 30, 2003
`
`Tint. C07 eeeeeeccecccceeeecceseeeeeeceeneseeenneeess GO06F 17/60
`(SV)
`(52) US. C0 eeeecccccsssssseessccsssssseeesecceessseeceesssssnneeeeseees 705/26
`
`(57)
`
`ABSTRACT
`
`Systems and methods to support an electronic market place
`include a communication network to communicate purchase
`requests; one or more buyers coupled to the networkto issue
`a purchase order specifying items from two or more sup-
`pliers; and a server coupled to the network to receive the
`purchase order, the server generating sub-orders from the
`purchase order and sending the sub-orders to the two or
`more suppliers for fulfillment.
`
`—x—SF
`100 Buyer Terminus
`
`| | | 4 | | | |
`
`HTTPAHTTPS
`FTPfFTPS
`XML
`ED
`SMTP/POP3
`
`|
`|
`{
`
`| |a
`
`|
`
`Protocols
`
`Repository
`300 Government Data
`CCR Registration
`DFAS Debenture
`DFAS Requital
`
`|
`
`HTTPHTTPS
`FTPIFTPS
`XML
`EO Te
`SMTPSPOPS
`
`Protocols
`
`
`
`Buyer Business Function
`RFQURFPIRFI
`Order
`|
`
`AP
`
` Seller Business Function
`|
`Quote/Proposalfinformation
`
`Purchase Order
`
`|
`|
`Le ee ee—_—S —
`
`400 Exchange \
`
`| | |t
`
`| |
`
`»|HTTPHTTPS
`3|FTPIFIPS
`3
`XML
`=
`EC
`SMTPIPOPS
`
`
`
`PROVI-1020 - Page 1
`
`PROVI-1020 - Page 1
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 1 of 19
`
`US 2005/0144082 Al
`
`-- FC TC Or ere en nr eeeTTLT 4d
`
`100 Buyer Terminus |
`
`| | | | | | |
`
`|
`|
`|
`
`|
`
`|
`
`Protocols
`
`HTTPAHTTPS
`FTPIFTPS
`XML
`Eo
`SMTP/POP3
`
`-_-_ Coe
`300 Government Data
`Repository
`CCR Registration
`DFAS Debenture
`DFAS Reauital
`
`|
`
`|
`
`— — —— ee
`
`ave
`
`HTTPUHTTPS
`FTPIFTPS
`XML
`ED
`SMTP/POP3
`
`Buyer Business Function
`RFQIRFPRFI
`Order
`AP
`
`
`Protocols
`
`
`
`
`
`400 Exchange \
`
`| | |{
`
`| | |
`
`
` Seller Business Function
`Quote/Proposaliinformation
`Purchase Order
`AR
`:
`
`Wwer
`
`«|MTTPHTTPS
`2
`FTPIFTPS
`3
`XML
`&
`ED
`SMTP/POP3
`
`
`
`FIG. 1A
`
`PROVI-1020 - Page 2
`
`PROVI-1020 - Page 2
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 2 of 19
`
`US 2005/0144082 Al
`
`
`
`Exchange400
`
`FIG. 1B
`
`PROVI-1020 - Page 3
`
`PROVI-1020 - Page 3
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 3 of 19
`
`US 2005/0144082 Al
`
`rT |
`Presentation
`|
`Services |
`|
`|
`| Business
`|
`
`Logic
`
`APIAR 120
`
`4
`AML
`
`
`
`
`
`
`
`|
`
`|
`
`|
`
`x Framework140 3
`
`Internet
`130
`
`Exchange
`
`Protocols 150
`
`EDI
`Legacy
`
`PROVI-1020 - Page 4
`
`PROVI-1020 - Page 4
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 4 of 19
`
`US 2005/0144082 Al
`
`
`
`
`Browser 180
`
`Presentation
`
`Services 182
`184
`
`Windows 2000
`
`ASP.NET
`
`'
`
` Middle-Tier ,
`
`Erameworkyarchitecture
`
`Business Logic
`Components
`
`,
`
`:
`
`\
`Business
`Rules & Data
`Validation
`
`Windows 2000
`
`Managed SQL Server Provider
`
`186
`
`Persistent
`Data Storage
`
`FIG. 2
`
`PROVI-1020 - Page 5
`
`PROVI-1020 - Page 5
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 5 of 19
`
`US 2005/0144082 Al
`
`
`
`
`
` epee a
`
`eeSourcn
`aren| onecertgCan
`|
`Penneker
`
`
`
`© searchtris category
`Search al categories
`
`All Categories/ Janitorial and Cleaning Equipment, Supplies, and Services/FLOOR MAINTENANCE MACHINES, PARTS, AND ACCESSORIES/
`
`Vacuum Cleaners, (Commercial, Wet or Dry), Parts, and Accessories
`
`
`
`~~ NIGe
`So
`a
`
`VHITHEY WORLDAMDE, INC.
`Tesa]
`
`
`
`‘SME GMBH
`EUREKA
`lot wRcoannen6AMPF4DIATTCUP
`.
`9560
`
`=ieeoe fees parc “ek
`REKA
`
`
`wt 10CUREKATO AMPCOMMERCIAL ~ “
`30880
`~
`~HARRIS|COMPUTERS —
`7
`
`wv TP EURERASAMP WaTCUP
`~
`[sss00.|
`i
`eeC. PHILLIPS,ne ——
`~ &
`
`
`edAZEURERAGAMP WoTCUP 0SSe RARIUS COMPUTERS go
`
`gf 2 EUREKA6 AMP WERT CUP
`,
`_| nestaf \
`A
`eee
`EUROS
`HRT uP 36680
`
`
`ofEUREKA to AMPCOMMERCIAL,
`~~ ~] osse0 | 7 ~TwanitaeyWORLUWLIE, INC,
`afl 1 EUREKATO AMPCOMMERCIAL, oo 386aD
`ToramG
`
`
`eftecunena 7,© AMPCOMMERCIAL — | 38600 CE e 6 MC
`~
`gaIS CUREMAT.O.AMPCOMMERCIAL
`~
` 3nsa0
`:
`STRAUB CONSTRUC TOt, NC,
`(gd 10 EUREKA 1.0 AMPCONMERCIAL
`| sosoa |: _)naawes coMPUTERS
`gd (8 EUREMA7.0 AMPCOMMERCIAL
`©, 368ep > HARRIS COMPUTERS
`
`
`
`~
`
`
`Organization: Dept of terior
`ee AeekeA OL)
`Be ss
`Bt ade SRE
`
`a re
`ve
`open etn enimnnene
`:
`ILfs.
`
`
`
`Fig. 3A
`
`PROVI-1020 - Page 6
`
`PROVI-1020 - Page 6
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 6 of 19
`
`US 2005/0144082 A1
`
` FearenteaeataRiedyainahss9re
`
`
`
`Favortes
`Took
`thelp
`aearneristetine
`{| Dsoach(Biravoraes Prats 9] SS
`Oo 8)
`
`
`
`
`© search this cotegory © Seorch ofl categories
`All Categories? Janitorial and Cleaning Equipment, Suppties, and ServicesFLOOR MAINTENANCE MACHINES, PARTS, AND ACCESSORIES/
`
`
`
`Vacuum Cleaners, (Commercial, Wet or Ory), Parts, and Accessories
`
`
`HOO2075
`2vacuun,sHouLoer VAC
`RARRIS COMPUTERS
`1002075
`SKE GMBH
`ef vacuursSHOULDER VAC
`a
`—
`~
`pm
`cence
`.
`
`
`
`
`
`
`
`maces Nene stratneesonannnansgsnrasaeee — ss juerttetaateegesSstnnene: enannagtat manam a oarmare
`
`rs PHILLIPS, INC
`et VACUUM,SHOULNER VAC
`HOO2075
`36680
`T
`ied VACUUN,SHOULTER VAC
`38880
`TORK INC
`HOO2075
`
`
`
`
`
`>=
`uhf
`
`i ia
`
`u
`an
`a
`Oiganizetion Dept af tnterior
`
`ee
`(Betenet
`
`Ordering Otticer, Tuhin Ghash
`Fa
`
`_
`
`PR Soaks03
`
`deeded
`
`so
`
`:
`
`PROVI-1020 - Page 7
`
`
`
`
`
`Catalog : All Vendors
`
`
`
`
`PROVI-1020 - Page 7
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 7 of 19
`
`US 2005/0144082 Al
`
`ABNet Procurement System- Micrusalt Lnternet Explorer
`[ Ele
`Ect Yow Favorites
`
`
`
`
`
`
`
`
`
`
`
`:
`4
`ms
`GkcrowseI|
`Shappiag Cart
`‘
`.
`V
`
`Shopping Cart - 6/6/2003 3:19:25 PM
`wt
`
`“2
`_
`wane
`omen a ne UE
`apn soe nen
`pen UPB ce ee AMOUR
`wed a
`[ReeseProd __
`Un Quart Pete Amount dg
`
`sets teenenaetna
`-
`_ cl a —
`—
`a
`4
`[oes
`{16" EUREKA 7.0 AMPCOMMERCIAL,
`ea
`|
`cE | $815.60
`351560] Dette
`i ;
`VACIIIM SHOULDER VAC
`
`
`nas
`
` Raed - ee
`
`ettPamek ute
`[sy oors
`
`PROVI-1020 - Page 8
`
`PROVI-1020 - Page 8
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 8 of 19
`
`US 2005/0144082 Al
`
`
`
`
`
`
`
`
`
`
`_Reauletionmumber "| FundCkeHumber
`|
`Fv, WK4S¥4-3010-0000
`
`“Cancel
`
`
`Cantinu Credit Cord Perchaso
`
`| Cortinue Fund Cite Purchsse
`
`wd
`rt
`
`21 320200000089430132076F0.43725400MKHEUKHBUSAK3010077HHBUOMO00000.
`
`
`DidenoaGlticersvahi Ghosts
`{5}.Dene.
`
`PROVI-1020 - Page 9
`
`PROVI-1020 - Page 9
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 9 of 19
`
`US 2005/0144082 Al
`
`b> ay Procurement System- Mucrasoft Internet Cxplorer
`
`eo 3) hatpafoweLov!reat.commerespxTsa0C350574349049519taetd¥b7¢7079 seuss
`Projact: USD Funding Project
`Ordar Nemo:
`|Shopping Can_- 66/2009 3:19:25 PM
`Delivery Location:
`[SanDiego Location- $678 Mira Mesa Bid
`Location Name:
`|SanDiego Location
`Street Address 1:
`|5678MiraMesa Eid
`Street Address2:|
`
`
`
`
`Shipping POC:
`POC Phone:
`
`Delivery data:
`Notas:
`
`
`
`16" EUREKA 7.0 AMPCOMMERCIAL
`
`PROVI-1020 - Page 10
`
`PROVI-1020 - Page 10
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 10 of 19
`
`US 2005/0144082 A1
`
` ret Procurement Systeni
`Rinse eelad
`
`
`
`Requisition Status:
`Projact:
`Ml
`Roturntc Uist
`
`
`Organization; Ospt ofInterior
`PO Box 12924
`Ft. Huachuca, AZ 85670
`USA
`
`
`
`eTetary)
`
`
`
`Aed
`Requisition Name:
`Orde: Number:
`Ordor Entry Date:
`To be delivered by:
`Shipping Addrese:
`
`Shipping POC:
`
`Shopping Cart - 6/4/20033:19:25 PM
`cost
`,
`“6A B/2003
`Wednesday, June 25, 2003
`San Disgo Location
`5678 Mira Mesa Bhd
`San Diago, CA 927121
`USA
`Bob
`866-1212
`Pending
`USD Funding Projact
`
`aTe
`
`VACULIM,SMOULDER VAC
`Manutocturer Port Number: 002075,
`
`Fig. 3F
`
`PROVI-1020 - Page 11
`
`PROVI-1020 - Page 11
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 11 of 19
`
`US 2005/0144082 Al
`
`
`Project: USD Funding Project
`
`© Order : Detaits
`Requisition Name: Shopping Cart - 6/6/2003 3:19:25 PM
`Order Number, 0061
`Order Entry Date: 6/18/2003
`To ba delivarad by: Wednasday, June 25, 2003
`Shipping Address: San Diego Location
`5678 Mire Masa Bhd
`San Diego, CA 92121
`USA
`Shipping POC: Bob
`§85-1212
`Requisition Status: Panding
`
`Cis
`
`Organization: OeptofInterior
`PO Box 12924
`Fi. Huachuea, AZ 85670
`USA
`
`Itams | Vandors S
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`elon rrso)
`
`
` Sa
`
`
`
`PROVI-1020 - Page 12
`
`PROVI-1020 - Page 12
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 12 of 19
`
`US 2005/0144082 Al
`
`AbNet Procurement
`
`System - Micrasolt Internet Explorer
`
`OR
`Vendor. HAWyS Compurens
`Requisition Nama: Shopping Cart - 6/6/2008 3:19:25 PM
`Vendor Order Number: 0081-001
`Order Entry Date: 8/18/2003
`To Be Delivered Gy: Wednesday, June 25, 2003
`Shipping Address: San Diego Location
`5676 Mira’ Mesa Blvd
`San Diego, CA 92121
`USA
`
`Status: Sent
`
`» Vendor Ole
`
`Organization: Dept ofInterior
`PO Box 12924
`Ft. Huachuca, AZ 85570
`USA
`
`Ordering Officer:
`
`eeeeo
`
`VACUUMSHOULOER VAC
`
`aFS oct
`
`Notes:
`
`Menutacturer Pert Number: HOO2075
`
`UScuserUy)
`
`9773.08
`
`View
`
`PROVI-1020 - Page 13
`
`PROVI-1020 - Page 13
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 13 of 19
`
`US 2005/0144082 Al
`
`@ Vendors Order ; Details
`Vendor, WHITNEYWORLOWIDE, INC,
`Requisition Name: Shopping Cart - 66/2003 3:19:25 PM
`Vendor Order Number, 0061-002
`Order Entry Date: 6716/2003
`To Be Dalverad By: Wednesday, June 25, 2003
`Shipping Address: Sen Diego Location
`6676 Mira Moca Ghd
`San Diego, CA92121
`USA
`
`Status:
`Notes:
`
` «
`
`AY Net Procurement System- Microsoft Internet Explorer ACCU LGcu
`memeeeSemaSTeatee
`
`Organization: Dept of Interior
`POBox 12924
`Ft. Huachuce, AZ 85670
`USA
`
`Ordering Officer:
`
`Aer]
`
`Orgenizeian Oept of interior
`feLhReusied
`ER[Siloneni
`
`
`Fig. 31
`
`PROVI-1020 - Page 14
`
`PROVI-1020 - Page 14
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 14 of 19
`
`US 2005/0144082 Al
`
`For each order:
`
`Search/Displayofa list of vendors selling a particular item (300);
`
`Add product has been added to the Shopping Cart (302)
`
`through the vendor’s CCR data (310).
`
`Check-out (304)
`
`Group items from multiple vendors together (306)
`
`For each vendor, place the order with a fund cite number and a delivery
`
`address (308).
`
`Whenitemsare received and accepted, the system pays each vendor
`
`FIG. 4
`
`PROVI-1020 - Page 15
`
`PROVI-1020 - Page 15
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 15 of 19
`
`US 2005/0144082 Al
`
`Central C ontractR egistry Database
`
`360
`
`350
`
` System Database
`
`362
`
` Vendor Registration
`
`SearcniSatect Vendor{s)
`364
`
`Vendor AP
`366
`
`Vendor Profile
`368
`
`FIG. 5
`
`PROVI-1020 - Page 16
`
`PROVI-1020 - Page 16
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 16 of 19
`
`US 2005/0144082 Al
`
`Central Contract Registry
`(CCR)
`370
`
`CCRData File
`
`CCR Import Process
`372
`
`
`
`
`
`Process CCR Data File
`
`
`
`PROVI-1020 - Page 17
`
`PROVI-1020 - Page 17
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 17 of 19
`
`US 2005/0144082 Al
`
`360 CCR PUBLIC
`
`cD
`Data
`Database
`
`
`:
`!
`
`
`
`
`Government POC Information
`E-Business POC Information
`
`
`382
`
`
`
`Registration Confirmation
`384
`
`VENDORREGISTRATION
`
`
`
`
`
`CCR PUBLIC
`Data
`
`oe
`\
`'
`
`i
`.
`:
`Services Offered
`(NAICS, SIC Codes) 394
`
`PROVI-1020 - Page 18
`
`PROVI-1020 - Page 18
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 18 of 19
`
`US 2005/0144082 Al
`
`eee ee ae _—— OO 4
`
`| | | |
`
`
`VENDOR BUSINESS NAME
`
`
`VENDOR MAILING ADDRESS
`
`
`400
`
`
`/
`
`RoutinyNumberAled)402
`
`J
`
`‘Hh
`
`
`System Database |
`360
`
`<CCR_PRIVATE_DATE
`
`e«CCR_PUBLIC_DATA>
`|
`|
`|
`|
`}
`l
`|
`|
`|
`|
`|
`|
`/
`/
`I
`|
`|
`| _____VendorParentinfomation |
`
`
`
`
`
`
`
`
`
`
`Systam Database
`360
`
`ACCTG DB 420
`
`
`
`j
`
`VENDOR EFT
`INFORMATION
`AIP VOUCHER412
`
`/
`
`EFT File 422
`
`FIG. 9
`
`PROVI-1020 - Page 19
`
`PROVI-1020 - Page 19
`
`

`

`Patent Application Publication Jun. 30,2005 Sheet 19 of 19
`
`US 2005/0144082 Al
`
`SEARCHCRITERIA
`
`
`
`
`
`
`
`
`
`
`System DB 360
`
`
`CCR_PUBLIC_DAT__|]
`A
`
`Vendor Name
`Vendor DUNS & CAGE Code
`Socio Economic Factors
`Business Type
`Geographic Location
`NAICS Code
`SIC Code
`
`430
`
`VENDOR SEARCH
`
`
`
`
`
`
`
`VendorList
`440
`
`
`
`FIG. 10
`
`PROVI-1020 - Page 20
`
`PROVI-1020 - Page 20
`
`

`

`US 2005/0144082 Al
`
`Jun. 30, 2005
`
`SYSTEMS AND METHODS FOR ORDERING
`FROM MULTIPLE VENDORS
`
`BACKGROUND
`
`[0001] Buyers in need of goods and services often spend
`considerable time locating an appropriate vendor. Buyers
`use trade publications, directories, recommendations, and
`other meansto locate vendors. If the type of vendor needed
`is in a foreign country, the problem compounds. Vendors
`advertise through various media and by direct sales methods
`to make knownto potential buyers what they sell and how
`to contact them. Once a buyeridentifies a few vendors, each
`must be contacted to obtain product or service, price and
`availability information. This is a time-consuming process
`and companies typically rely on experienced purchasing
`staff to accomplish it. In addition, when buyers mustsell
`surplus inventory from time to time, they must advertise,
`cold-call, sell to brokers or the like. These processes are
`costly and time-consuming for most businesses.
`
`[0002] As discussed in U.S. Pat. No. 6,556,976, the prior
`art includes computerized shopping systems that employ a
`central database of goods and services offered to buyers.
`Information about the goods and services offered is stored
`centrally and must be kept current centrally. The volume of
`information required to be maintained and updated in a
`central database system restricts it
`to a limited type or
`number of goods and services or number of vendors it can
`offer. These systemsare like electronic supermarkets that are
`owned by a single company or an association of suppliers.
`In such systems, a vendor provides its database of goods
`and/or services to a buyer who orders items from the
`vendor’s database. It is analogous to walking into a vendor’s
`store and selecting items from the vendor’s available stock.
`Another such system is analogous to shopping in a mall. In
`this case a number of (complementary) vendors combine to
`offer their collective inventory to the buyer through indi-
`vidual databases or a combined database of available goods
`or services. In yet another existing system, a primary,seller,
`such as an insurance agency, offers to provide buyers
`premium quotations from the insurance carriers for which
`the agencyis an agent. In all of the above cases, the vendors
`responding to the buyer’s request regarding a particular
`good or service are either the service provider or a vendor
`with whom the service provider is involved in another
`business relationship, such as advertisers in a common
`publication or affiliated insurance carrier. These select ven-
`dors provide the product and pricing information supplied
`by the system to buyers.
`
`SUMMARY
`
`[0003] Systems and methods to support an electronic
`market place include a communication network to commu-
`nicate purchase requests; one or more buyers coupled to the
`network to issue a purchase order specifying items from two
`or more suppliers; and a server coupled to the network to
`receive the purchase order, the server generating sub-orders
`from the purchase order and sending the sub-orders to the
`two or more suppliers for fulfillment.
`
`[0004] Advantages of the invention may include one or
`more of the following. The system reduces the cost and
`complication of automating commerce communications and
`transactions to help users reduce overhead, strengthen rela-
`
`tionships, and improveprofitability. Additionally, the system
`can handle a large number of goods and services from any
`number of vendors who wish to become members of the
`system. The scalable distributed database can handle sizable
`information about products, services and vendors. Each
`vendor can provide detailed information to the central
`database about its product lines and can update the database
`on a timely basis.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`invention will now be
`the
`[0005] Embodiments of
`described with reference to the accompanying drawing, in
`which:
`
`[0006] FIGS. 1A-1C show an exemplary architecture for
`serving buyers and sellers with a government data reposi-
`tory.
`
`FIG.2 illustrates an exemplary logical architecture
`[0007]
`in accordance with one aspect of the invention.
`
`[0008] FIGS. 3A-3I show various exemplary user inter-
`face screens for the multi-vendor purchase process.
`
`[0009] FIG. 4 illustrates an exemplary multi-vendor
`ordering process.
`
`a communications network
`[0010] FIG. 5 illustrates
`between a Central Contract Registry (CCR) Database and a
`system database for handling orders.
`
`[0011]
`Cess.
`
`[0012]
`process.
`
`FIG.6 illustrates an exemplary CCR update pro-
`
`FIG.7 illustrates an exemplary vendorregistration
`
`[0013]
`
`FIG. 8 shows an exemplary vendorprofile process.
`
`[0014]
`
`FIG. 9 shows a vendor payment process.
`
`[0015] FIG. 10 shows an exemplary process to locate a
`particular vendor.
`
`DESCRIPTION OF THE INVENTION
`
`In the following description, numerous details are
`[0016]
`set forth to provide an understanding of the present inven-
`tion. However, it will be understood by those skilled in the
`art that the present invention maybepracticed without these
`details and that numerous variations or modifications from
`the described embodiments maybe possible.
`
`[0017] Referring now to FIG. 1, an exemplary architec-
`ture for on-line commerce is shown. A buyer 100 such as a
`federal or state government, a conglomerate, or a pooled
`purchasing group typically buys from many suppliers. The
`system of FIG. 1 provides a single point of contact for the
`buyer 100 to centralize administrative and financial opera-
`tion support.
`
`[0018] The buyer 100 has a group of one or more pur-
`chasing agents connecting to the marketplace. A purchasing
`agent may have shared interests in particular commodities,
`or may not have any commonality in their purchases. The
`purchasing agents access data from an exchange 400 oper-
`ated by an intermediary companytypically through common
`Internet based protocols.
`
`[0019] A seller 200 can be an individual seller or a seller
`community with one or more vendors or suppliers. The
`PROVI-1020- Page 21
`
`PROVI-1020 - Page 21
`
`

`

`US 2005/0144082 Al
`
`Jun. 30, 2005
`
`seller community can communicate directly with users of
`the purchasing workstations or indirectly through the server.
`The community provides the client workstations with access
`to a network of sellers that can enhance the purchasing
`experience. For rapid market penetration and to prevent
`channel conflict problem,
`the system can integrate third
`parties into its business models as partners and also as
`(micro-) aggregators of supply and demand.
`[0020]
`In addition to the proprietary or Internet network,
`users can also communicate with the exchange 400 by
`sending facsimiles to one or more fax-modem boardsthat
`communicate with a server at
`the exchange 400. Upon
`receipt, the facsimiles are fed through an optical character
`recognition (OCR) software or subassembly. The OCR
`software or hardware in turn generates one or morefiles that
`can be processed by the server as though the information had
`been received over the Internet. In this manner, the system
`of FIG. 1 supports buyers who are not fully Internet-
`enabled.
`
`[0021] The system of FIG. 1 also includes a Government
`Data Repository 300, which is a federation of data and
`standards used for exchanges between buyers andsellers.
`The Government Data Repository 300 provides
`the
`Exchange 400 with data allowing for pre-registration of
`Buyers 100 and Sellers 200. Using pre-registration allows
`the Buyer 100 or Seller 200 to gain access to the Exchange
`400 with only the entry of identity validation credentials.
`[0022] The exchange 400 is the aggregation of facilities
`for interaction with the buyer 100, the seller 200, and the
`Government Data Repository 300. The exchange 400 uses
`an application framework consisting of a core base object
`library with database abstraction, table-to-association map-
`ping, database scalability and transaction mapping, and an
`integrated business class generator with business-rule sup-
`port, and an object-to-relational map interface. The appli-
`cation framework decouples the DB design from the object
`class design, standardizes the code base, provides for seam-
`less object and DB tier scalability, allows ultra-thin client
`access, an efficient testing cycle, and a fast prototype-to-
`production cycle.
`[0023] Although the exchange 400 can be services pro-
`vided by an individual server, typically the exchange 400 is
`a cluster of redundant servers and services. Such a cluster
`
`can provide automatic data failover, protecting against both
`hardware and software faults. In this environment, a plural-
`ity of servers provides resources independent of each other
`until one of the servers fails. Each server can continuously
`monitor other servers. When one of the servers is unable to
`
`respond, the failover process begins. The surviving server
`acquires the shared drives and volumesofthe failed server
`and mounts the volumes contained on the shared drives.
`Applications that use the shared drives can also be started on
`the surviving server after the failover. As soon as the failed
`server is booted up and the communication between servers
`indicates that the server is ready to ownits shared drives,the
`servers automatically start the recovery process. Addition-
`ally, a server farm can be used. Network requests and server
`load conditions can be tracked in real time by the server farm
`controller, and the request can be distributed across the farm
`of servers to optimize responsiveness and system capacity.
`Whennecessary, the farm can automatically and transpar-
`ently place additional server capacity in service as traffic
`load increases.
`
`[0024] The exchange 400 can also be protected by a
`firewall. The exchange 400 supports a reservation transac-
`tion portal that provides a single pointof integration, access,
`and navigation through the multiple enterprise systems and
`information. The exchange 400 allows a purchasing agent to
`log onto a computerized purchasing system over a network
`and automates the steps required to complete a purchase
`transaction. Using the exchange 400, the purchasing agent
`would be able to use specific criteria and parameters to
`rapidly search through a large database of available suppli-
`ers. Buyers 100 and sellers 200 get several support services
`and document
`templates during the whole process. The
`system provides these services, of which, someare basic and
`some are value added. In addition, information relating to
`the various portions of a transaction are captured and stored
`in a single convenient location where it can be accessed at
`any time.
`
`[0025] The exchange 400 contains high-performance vir-
`tual protocols that exchange information with Buyers 100,
`Sellers 200, and Government Data Repository 300. These
`protocols bypass conventional disk or other media based
`staging areas and operate directly in memory. These proto-
`cols allow exchangeddata to be stored and retrieved directly
`with caching or database systems. The protocols for inter-
`action between the Buyer 100 and the Exchange 400 are
`typically HTTP, HTTPS, FTP, FTPS, XML, EDI, SMTP,
`and POP3. The protocols for interaction between the Seller
`200 and the Exchange 400 are typically HTTP, HTTPS, F
`1’P, FTPS, XML, EDI, SMTP, and POP3. Theprotocols for
`interaction between the Government Data Repository 300
`and the Exchange 400 are typically HTTP, HTTPS, FTP,
`FTPS, XML, EDI, SMTP, and POPS.
`
`[0026] The exchange 400 facilities manage foreign cur-
`rency via a matched currency system that uses the same
`currency on eachtransactionforall parties to the transaction.
`This matched currency system avoids the typical currency
`fluctuation losses and gains found in systems relying upon
`at-transaction or post-transaction currency exchange.
`
`[0027] The exchange 400 enables buyer(s) 100 to select
`one or moreseller(s) 200 for procurement by ranking and
`comparing based upon business type, cost, performance,
`desired business development qualities, location, or other
`characteristics. A weighted score is available to Buyer 100
`to aid in selection. The exchange 400 also communicates
`data such as CCRregistration, DFAS debenture and DFAS
`requital information with the government data repository
`300.
`
`[0028] Turning now to FIG. 1B, a physical computer
`manifestation of the architecture of FIG. 1A is shown. In
`
`FIG.1B,a server for exchange 400 communicates over the
`Internet 130 with a plurality of computers 102-18 for
`account payable operations, account receivable operations,
`request for proposal operations, and seller clearing house
`operations, respectively. FIG. 1C shows a corresponding
`view of modules and their interactions.
`In FIG. 1C, a
`presentation services tier includes account payable/receiv-
`able module 120, a request for proposal module 122, a seller
`clearing house module 124, and other modules 126. The
`presentation services communicate over the Internet 130 to
`a businesslogic tier including software framework 140 and
`protocol handling module 150, which can translate among
`protocols such as EDI, legacy, XML, HTTP and FTP, among
`PROVI-1020 - Page 22
`
`PROVI-1020 - Page 22
`
`

`

`US 2005/0144082 Al
`
`Jun. 30, 2005
`
`others. The framework 140 and protocol handling module
`150 in turn communicate with the exchange 400.
`[0029]
`FIG.2 illustrates an exemplary logical architecture
`in accordance with one aspect of the invention. A browser
`180 communicates over the Internet using HTML with a
`server that provides presentation services 182. The server
`also communicates with a middle tier 184 for performing
`business rules and data validation using Microsoft’s ASP-
`.NET. The architecture includes business logic components
`that access data using ADO.NET. The middle tier 184 in turn
`communicates with a database in persistent data storage 186.
`The communication between the middle tier 184 and the
`
`persistent data storage 186 is done through a managed SQL
`server provider. In one implementation, the
`[0030] FIGS. 3A-3I show various exemplary user inter-
`face screens for the multi-vendor purchase process. During
`the purchase process, the buyer can search for one or more
`desired items. For example, FIG. 3A shows an exemplary
`display of a list of vendors selling a particular item, in this
`case Eureka vacuum cleaners. After selecting a desired item
`from a vendor and purchasing the desired item (by selecting
`the item to be placed in a purchasecart in this example), the
`buyer can repeat the search process for another item.
`[0031] The Ordering Officer viewsa list of products in the
`“Vacuum Cleaners” category in the Catalog. When any
`hyperlink is clicked in the “Product Name” column, a
`Product Detail Windowis displayed. From that window,the
`Ordering Officer may add a quantity of the product to a
`Shopping Cart. When the product has been added to the
`Shopping Cart, the Shopping Cart icon to the left of the
`name will display a check mark in the basket (FIG. 3B).
`Clicking the Vendor’s name hyperlink activates a window
`displaying details about the Vendor. A status bar is shownat
`the bottom of the Product Category List,
`indicating the
`numberof items in the Shopping Cart and the subtotal for
`those items in the quantities ordered at the listed prices.
`[0032] FIG. 3B is an exemplary display of a list of
`vendors selling accessories,
`in this case an item called
`“Shoulder Vac.” In a single purchase order, the buyer can
`buy a plurality of items from completely different vendors
`and can order from multiple vendors in the same shopping
`cart. For example, FIG. 3C shows an exemplary view of the
`shopping cart after adding the above two items from SKE
`GmbH and from Harris Computers, respectively. The Shop-
`ping Cart showsline items, quantities, prices and cost. The
`Ordering Officer may update quantities, delete line items,
`empty the entire Shopping Cart or complete a purchase with
`this feature.
`
`[0033] When the buyer is done shopping, he or she com-
`pletes a check-out process. As shown in FIG.3D, the check
`out process first selects a payment method by selecting
`either a fund cite (line of accounting) or Credit Card cite.
`Next, as shown in FIG. 3E, ordered items from multiple
`vendors are grouped together with a fund cite number and a
`delivery address. FIG. 3F shows a buyer’s Order View for
`the Purchase Order (in this example Order 0081) that was
`placed for the above items. The Purchase Order is a perma-
`nent, online record of the purchase that is always available
`to the Ordering Officer. FIG. 3G showsthe exchange’s view
`of the Order 0081, which shows that
`the order will be
`fulfilled by two vendors. Each vendor suborder has the same
`order number followed by a suffix. FIGS. 3H-3I show each
`vendor’s suborder view needed to fulfill Order 0081.
`
`[0034] As shown above, a multi-vendor purchase order
`system is supported: The buyer may fill a shopping cart
`(Electronic Storefront purchase) with goods from multiple
`vendors and proceed seamlessly to checkout. The system
`distributes the orders for the purchased items to the indi-
`vidual vendors andtracks fulfillment history, invoicing and
`paymentindividually per vendor, while preserving the buy-
`er’s purchasing history for the entire shopping cart (multi-
`vendor) as well as individually per vendor. During the
`solicitation process,
`the buyer may compare competing
`vendor’s offers onscreen, providing a solid cost-based com-
`parison for the purposes of making a purchase decision.
`
`In one embodiment, the system hosts all partici-
`[0035]
`pating Vendors’ catalogs on its own servers. This capability
`is a paradigm shift in e-commerce technology away from the
`model where an originating website accesses and processes
`information on the secondary website and the secondary
`website then returns data to the originating website.
`
`Instead of this model, one embodiment hosts all
`[0036]
`catalogs of registered Central Contract Registry (CCR)
`vendors on the system’s network infrastructure. These CCR
`vendors must navigate to the system, register and then post
`a catalog themselves. The system “pulls” vendor informa-
`tion from CCR daily. This is high-level information such as
`company name, address, point of contact, etc. OMC accepts
`the catalog when the vendorposts the catalog, not when the
`vendor information gets “pulled.” Moreover, these Vendors
`have a choice of industry and technical formats with which
`to upload their catalogs, and may update the information as
`often as they want (e.g. more than once per day if desired).
`
`Industry catalog formats supported by one embodi-
`[0037]
`ment of the system include the following:
`
`[0038] NIGP (National Institute of Government Pur-
`chasing), URL:http://www.nigp.org/
`
`[0039] NAICS (North American Industry Classifica-
`tion System), URL: http:/Avww.census.gov/eped/
`www/naics.html
`
`[0040] UNSPSC (United Nations Standard Products
`and Services Code), URL: http:/Awww.unspsc.org/
`
`[0041] Vendors using any of the above listed industry-
`standard formats do not have to reorganize their information
`prior to upload. After receiving the catalog,
`the system
`organizes and stores the catalog in NIGP format. This is the
`format displayed in the browser when the Ordering Officer
`views the Catalogs feature.
`
`In uploading catalogs, vendors have two choices
`[0042]
`for technical formats when uploading a catalog to the
`system. For small Vendors, a web-based form for manual
`user data-entry is provided. Large vendors may choose
`instead to convert
`their catalog data to an intermediate
`format known as a .cif format. In brief, the Vendor uses a
`highly standardized format and a Microsoft Excel spread-
`sheet to input the catalog data. Whenthe catalog is finished,
`the Vendor converts the spreadsheet to comma-separated
`values(.csv file format) and uploads to the system. Vendors
`can update their catalogs as often as daily if they so desire.
`
`[0043] The system allows the buyer to form a selectlist of
`vendors, to whom they will send a solicitation, and sends the
`solicitation to this list. The system also provides a rating
`system by requiring a vendorrating as the buyer approves an
`PROVI-1020 - Page 23
`
`PROVI-1020 - Page 23
`
`

`

`US 2005/0144082 Al
`
`Jun. 30, 2005
`
`invoice. This creates a body of knowledge that will provide
`subsequent buyers valuable information about vendor per-
`formance. The system also accepts an assignment of fund-
`ing: Buyers are able to “pre-fund” purchases. This means
`that buyers create requisitions,
`lines of accounting and
`designate amounts for spending prior to transactions. As
`transactions are made against these accounts, the system
`automatically draws down on the pre-funded amount. Fund-
`ing objects include Requisitions, Funding Items(line items)
`and Fund Cites (account numbers).
`
`[0044] Turning nowto FIG.4, an exemplary multi-vendor
`ordering process is shown. For each order,
`the process
`accepts a search query from the user and display ofa list of
`responsive vendors (300). The process allowsthe user to add
`products from diffe