WO2004006143A1 - Systeme et procede de commerce electronique - Google Patents

Systeme et procede de commerce electronique Download PDF

Info

Publication number
WO2004006143A1
WO2004006143A1 PCT/AU2003/000853 AU0300853W WO2004006143A1 WO 2004006143 A1 WO2004006143 A1 WO 2004006143A1 AU 0300853 W AU0300853 W AU 0300853W WO 2004006143 A1 WO2004006143 A1 WO 2004006143A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
site
services
goods
bureau
Prior art date
Application number
PCT/AU2003/000853
Other languages
English (en)
Inventor
Peter James Forsyth
Original Assignee
Common Component Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Common Component Pty Ltd filed Critical Common Component Pty Ltd
Priority to AU2003236579A priority Critical patent/AU2003236579A1/en
Publication of WO2004006143A1 publication Critical patent/WO2004006143A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • This invention relates to an ⁇ Commerce system and method and relates particularly but not exclusively to such for use on the Internet.
  • a merchant wishing to offer goods or services will establish a website and homepage offering the goods and/or services.
  • the homepage can be configured to provide a menu type structure so a visitor to the merchant's site and homepage can quickly negotiate through a series of possible options to select the desired goods and/or services.
  • the creation of such home sites and the webpage and related directory structures require a detailed understanding of HTML language.
  • the cost of engaging a software organisation to create the necessary site and homepage and related directory structures is within the normal marketing budget. For other smaller enterprise merchants however, the cost can be relatively prohibitive.
  • a bureau administrator site configured and linked for use in online e-commerce via the Internet or a like communication medium
  • said bureau administrator site having; access to merchant site homepage generator for permitting a merchant to configure a home site with a homepage from a homepage tempelate sourced from the home page generator for offering goods and/or services to be sold by the merchant, access to an ordering engine for permitting customers who visit a merchant's home site configured by said home page generator to order goods and/or services offered by the merchant via that homepage, access to a payment engine to effect payment by a customer of goods and/or services ordered by the customer via the ordering engine, and, access to a bureau administrator engine to receive confirmation of payment for goods and/or services transacted via the payment engine, and to permit the merchant to be informed of purchase and payment of goods and/or services ordered by the customer via the ordering engine.
  • a bureau administrative method in online e- commerce conducted via the Internet or a like communication medium said method including:
  • an Internet or a like communication medium e- com erce method for permitting a merchant to configure a merchant site homepage online for the sale of goods and/or services, via a bureau administrator site, and to permit customers to access the established merchants home site, and to permit an administrator of the bureau administrator site to provide to the merchant's administrative services which are related to any purchases and payments of the merchant's goods and/or services made by customers visiting the merchant's home site, said method including:
  • an e-commerce system for use on the Internet or a like communication medium to permit merchants to configure a home site and homepage online via a bureau administrator site for the sale of goods and/or services, and to permit customers to access the any so established merchant sites and make purchases of those goods and/or services, and to permit an administrator of the bureau administrator site to provide administrative services to the merchants which are related to any purchases and payment of the merchant's goods and/or services, said system having said bureau administrator site accessible by merchants intending to establish a merchant site for the sale of goods and/or services, said bureau administrator site having access to a merchant site homepage generator, said home page generator being activatable when the intending merchants visit the bureau administrator site to enable a site domain name to be applied and have that assigned as the merchant's home site address, the merchant also being able to configure at least a merchant homepage from a homepage template sourced from the homepage generator to identify the merchant and to permit display of merchant specific goods/and or services when customers access the homepage,
  • the displayed merchant specific goods or services being associated with a customer goods or services ordering engine administered by the bureau administrator
  • said ordering engine being associated with a payment engine for payment of goods and/or services ordered via the ordering engine
  • said payment engine being able to confirm payment to said administrator
  • said administrator having a bureau administrative engine which can be used to permit the merchant to be informed of the successful purchase and payment of goods and/or services by a customer visiting the merchant's home site, so said merchant can, in turn, deliver the purchased goods and/or services to the customer.
  • said bureau administrator is configured to accept a "user name" and a "password" of a merchant before said merchant can create a home site and homepage.
  • said bureau administrator site is configured to accept a "user name” and a "password" of a merchant before said merchant can make changes to any home site pages.
  • said bureau administrator engine is connected with an online mail message module to automatically provide mail messages to both a customer ordering goods and/or services, and a merchant who has offered and sold goods and/or services, that a purchase has been made.
  • said bureau administrator engine is connected with a database to store particulars of purchases made from individual merchants home sites, so a report can be compiled from the database to be forwarded to a merchant.
  • a scheduler is provided to initiate the providing of reports to a merchant.
  • all home sites and homepages of all merchants are formed from common templates, and data is stored in memory to recall to dynamically compile a homepage and other pages, when a customer visits a merchant web site.
  • screen display components of any display of a homepage or other page are individually configurable by the merchant as to merchant specific goods and/or services content.
  • screen display components of any display of a home page or other page that are common to all merchants are individually configurable by the merchant as to specific colours chosen by the merchant.
  • said bureau administrator site has a module for billing merchants for use of the bureau service.
  • the module for billing merchants is configured to make a charge based on maintenance of the merchant site, and any purchases made to the merchant's website.
  • Figure 1 is an overview block schematic diagram of an example of a preferred embodiment of the invention.
  • Figure 2 is a representation of a particular template used in the system.
  • Figure 3 is a overview system functional diagram.
  • Figure 4 is a functional diagram concerned with the steps involved in using a template.
  • Figure 5 is a functional flow diagram associated with an order package record.
  • Figures 6a and 6b are a database schemer for a bureau administrator.
  • Figure 7 is an overview block schematic diagram of an e-mail module.
  • Figure 8 is an e-mail functional flow diagram.
  • Figure 9 is an overview diagram of a payment gateway.
  • Figure 10 is a functional diagram of the processes involved in making a payment .
  • Figure 11 is a schematic overview diagram showing local image manipulation.
  • Figure 12 is a functional flow diagram of the processes involved in image manipulation.
  • Figure 13 is an overview block schematic diagram of a batch job schedular.
  • Figure 14 shows a functional flow diagram of delete sessions.
  • Figure 15 is a functional flow diagram showing some possible daily jobs that are initiated by the schedular.
  • Figure 16 is a functional flow diagram of a delete/abandon session.
  • Figure 17 is a functional flow diagram showing scheduled reports.
  • Figure 18 is a back-up functional flow diagram .
  • Figure 19 is a clean-up functional flow diagram.
  • Figure 20 is a screen display of a typical homepage created from a template.
  • Figure 21 is an overview diagram showing the tiered structure of the database.
  • Figure 22 is a screen display at level 1 of the database.
  • Figure 23 shows a screen display at level 2 of the database.
  • Figure 24 shows a screen display at level 3 of the database.
  • Figure 25 shows a screen display at level 4 of the database.
  • Figure 26 shows a screen display of an order.
  • Figure 27 shows a screen display that appears during payment for goods and services ordered.
  • Figure 28 shows a screen display of a tax invoice and receipt that is provided.
  • Figure 29 shows a screen display that occurs during a "fast order”.
  • Figure 30 is a screen display of a review order.
  • Figure 31 is a detailed view of part of a screen display showing particular buttons that appear in the screen display.
  • Figure 32 is a further screen display showing particular options available when configuring a homepage.
  • Figure 33 is a further screen display showing "orders" .
  • Figure 34 is a screen display observed by an administrator of a merchant to review product orders.
  • Figures 35 is a screen display showing possible reporting options.
  • Figure 36 is a further screen display of a report and
  • Figure 37 is a screen display of a typical finaneia1 report .
  • FIG 1 there is shown an overview of an example of a preferred embodiment of the invention for use .on a communication medium 1 such as the Internet.
  • the system has a bureau administrator site 3 which is connected to the Internet 1.
  • a number of merchants 5 are also connected to the Internet 1, as are a number of customers 7.
  • the customers 7 have their own personal computer device appropriately interconnected with a modem to permit communication via the Internet 1.
  • the bureau administrator site 3 also has a modem for permitting connection with the Internet 1 so that data can be exchanged between the merchants 5 and the bureau administrator site 3 and/or the customers 7.
  • Each of the merchants 5 and customers 7 typically have a usual browser software package resident on their personal computer.
  • the bureau administrator site 3 typically is comprised of a server computer and resident software. It may comprise independent server computers dedicated for particular functions, although in one embodiment, all of the functions can be performed within a single server computer at the bureau administrator site 3. Accordingly, within the bureau administrator site 3 there is provided a bureau administrator site server 9 which is linked to a merchant site homepage generator 11. Accordingly, a merchant 5 wishing to establish a home site with a homepage makes contact with the bureau administrator site 3 via a letter, telephone or the Internet 1. The merchant provides a merchant domain name to the administrator site and the merchant site, then establishes a merchant site and homepage using the domain name as the domain address and so it will be accessed by the public via the administrator site.
  • the bureau administrator site server 9 then directs the merchant to the merchant site homepage generator 11.
  • the merchant site homepage, generator 11 contains a software package that permits a merchant 5 to configure the site and homepage by allowing the merchant 5 to access a template homepage, and subsequent template directory pages, in which the merchant's particulars of goods and/or services can be entered.
  • the merchant 5 is required to enter their name into the homepage and any other desired contact particulars together with particulars of the goods and or services to be offered.
  • the homepage may contain buttons which can be clicked to access subsequent pages.
  • the homepage is configured to have a directory type structure which can lead a customer 7 to particular pages easily, so that goods or services can be readily ordered.
  • a customer visits the merchant's website.
  • the customer orders goods and/or services through an ordering engine 15.
  • the price of the goods and services can be displayed on the various pages.
  • a shopping trolley software package can be utilised to permit orders to be made and the cost price to be determined.
  • this data information is stored as merchant sites 13 having their domain name directed through the bureau administrator site server 9.
  • a path is established through the bureau administrator site server 9 directly to the particular merchant's home site 13.
  • the ordering engine 15 is invoked to permit orders to be assembled.
  • the ordering engine 15 may interact directly with the customers 7 so that the customers 7 have some comfortable look and feel to the way orders are made.
  • a shopping cart type ordering system may be invoked if required.
  • a payment engine 17 is invoked which arranges for payment of the goods and/or services ordered by the ordering engine 15.
  • the payment engine enables a customer 7 to enter payment type information into the system and to make contact with a financial institution 19 which may be outside of the bureau administrator site 3, although this is not essential.
  • a bank for example, may be administering the bureau administrator site 3, and therefore the payment engine 17 may link directly into the bank's software to effect payment.
  • an acknowledgment of the payment can be provided to a bureau administration engine 21 to, in turn, provide payment information to the bureau administrator site server 9.
  • the bureau administrator site server 9 then has the function of informing the customer 7 that payment for the goods and services has been accepted, and to inform the merchant that there has been payment for the goods and/or services.
  • a customer 7 there can be a direct indication on the monitor of the customer's personal computer that payment has been accepted. Simultaneously, an e-mail can be sent to the customer's mail box to provide a further confirmation of the successful purchase of the goods and/or services. If desired, a hard copy letter can also be prepared and dispatched by post. Simultaneously, the merchant concerned will be advised by e-mail of the order that has been made and payment has been made and accepted. In that way, the merchant 5 can deliver the goods and/or services to the customer 7. A conventional mail letter may be posted and mailed to the merchant as well.
  • the bureau administrator site server 9 also serves a further function - to assemble audit type reports for the merchant. For larger enterprise customers 7, it may also assemble audit type reports concerning purchases made. These reports may be sent to the merchants 5 and larger enterprise customers 7 at predetermined intervals such as daily, fortnightly, monthly etc. In the case of disputed orders, it can provide a point of contact for resolution.
  • the bureau administrator site can also serve as a means for storing flag indicators or like indicators for particular customers, that can be used to trigger application of predetermined discounts or special offers to particular customers. Such discounts or the like may be applied monthly as a refund to a customer or may be applied for each transaction. If desired, the flags may be activated when a particular customer visits the bureau administrator site 3 to access a particular merchant 13. In this way, predetermined discounts and special offers may be displayed to the particular customers 7 during the customers 7 access of a particular merchant site 13.
  • the template (s) used by the merchant site homepage generator 11 will be common for all merchants. As a merchant intends to establish a website with a particular homepage, the merchant will be able to insert unique company logos and other information concerning the company's particulars including the specific goods and/or services to be offered. In that way, a merchant can tailor the particular required look and feel of the homepage, and other pages, within the confines of the possible variations within the template (s) .
  • the template (s) may be such that background colours, print colours and size of images can be altered by the merchant to give some individuality over and above the basic template.
  • the software resident within the merchant site homepage generator 11 is able to accept logos, images and the like and to re-size those images and logos automatically and with the right resolutions to correctly display on the various homepages and other pages in the prescribed size areas on those pages.
  • the bureau administrator site server 9 may store particular user names and passwords for each of the merchants 5, so that as new products and/or prices are developed the merchant can access the merchant's pages and alter those relevant pages to show the new products and/or prices.
  • the bureau administrator site 3 can charge fees for the establishment, and maintenance of home sites, and for the subsequent purchase of goods and/or services transacted through the system.
  • the service charges may be billed directly to the merchants 5 and may be paid for online by a connection through the payment engine directly with the financial institution 19. Alternatively, the merchants 5 may otherwise have to maintain a credit payment facility acceptable to the bureau administrator site 3.
  • the system desirably facilitates online trade between businesses or individuals wishing to sell goods and/or services, and businesses or individuals wishing to buy these goods and/or services.
  • the system therefore provides merchant's sites with homepages and provides for online product catalogue ordering and payment. It also provides for online administration of the product catalogue, customer's accounts and reports of orders and payments.
  • the system operates using Internet browsers such as Microsoft Internet Explorer Version 5 and above, or Netscape Version 6.2 and above.
  • the system enables a homepage to be established as the first point of contact to a customer.
  • the page is able to display images and text concerning the merchant's Mission Statement or Vision, contact details, promotional specials and highlights and benefits and other matters relating to goods and/or services offered.
  • a catalogue is associated with the homepage and, for example, the catalogue may have four levels of pages set up in a branching directory structure, showing images and text describing the merchant's offerings. From the third and fourth levels, the purchaser/customer will be able to enter a quantity of the goods and/or services to create an order.
  • the customer will be able to pay by credit card or by other account billings through the financial institution. Desirably the customer requires a user name and password to log-on to the system, however it is contemplated in the broader concept that the system be
  • the system at the bureau administrator site, can keep a log of the various customers and user names and passwords.
  • the merchant will be able to access pages to add customer accounts, update customer account detail or delete customer accounts etc.
  • the merchant will be able to use an "input" facility to directly input details of existing customers from external systems and applications .
  • the merchant can access two types of reports through the system, being, firstly, operational reports, so as to provide the merchant with information as to what is selling, when it is sold, and who is buying; and secondly, financial reports, detailing the dollar amounts to invoice to be transferred into the merchant's bank account.
  • operational reports so as to provide the merchant with information as to what is selling, when it is sold, and who is buying
  • financial reports detailing the dollar amounts to invoice to be transferred into the merchant's bank account.
  • the merchant when the merchant is updating the home site, he may be able to place the home site into a "construction" mode until that process is completed. During this update, the merchant will be able to add/update/delete images and texts from the homepage, logon page and review page.
  • the reports that are provided to the merchant may be run as a batch process and scheduled periodically such as daily, weekly, fortnightly, monthly etc.
  • a scheduling process may backup all databases and store the results in backup files in a convenient location such as off site.
  • a clean up function
  • the system operates as a client - server application over the Internet.
  • the server hardware is typically PC based and operates on an internal LAN speed of 100M with an external Internet connection of at least 256K.
  • the hardware supports MS SQL server, MS Internet Information Server, an e-mail client and the basic system bureau server application.
  • the system at the bureau administrator site server may be hosted in separate physical hardware platforms.
  • the server at the bureau administrator site 13 will be configured to service at least ten simultaneous requests giving a response to each within two seconds approximately.
  • the customer's hardware will require sufficient PC capacity to run a browser within its operating system.
  • the homepage and other pages of a merchants site 13 will be generated dynamically through template (s) for each visit to the home site and pages.
  • templates there are templates available which are dynamically loaded with merchant particulars and other related data that have been pre-stored within a database at the administrator site.
  • Figure 2 shows a representation of a particular template. Accordingly, when a merchant 5 configures the homep.age and related pages, all of the pages established are not stored as pages per se but rather stored as data which can be inserted into the templates as needed and as a customer 7 visits a particular home site and traverses the particular directory page (5) ..
  • Figure 2 shows a typical template which has a logo area 23 in which a merchant's logo can be displayed. It also has a banner area 25 which displays the name of the page and provides buttons to reach each of the general areas of the site being:
  • FIG 3 shows a further system functional overview. Here it can be seen that the system is still functionally identical to that shown in Figure 1.
  • a number of customers being merchants 5 and/or customers 7 have access to the Internet 1.
  • the bureau administrator site 3 has a server 9 that hosts a web server 33. Forming part of the bureau administrator site server 9 is a bureau engine 35 and management data 37.
  • the web server 33 is able to host many domains (merchants sites) concurrently. Typically, all requests received by the web server 33 can be processed by a single bureau engine 33. The engine will verify requests using local management data.
  • the bureau engine 35 will then build dynamic HTML pages populating templates with data from a database associated with the respective domains (merchant sites).
  • the resulting HTML pages are then presented on the client browser with links to image files associated with the particular domains.
  • each merchant has their own unique domain name, which is hosted by the web service 33 within the bureau administrative site server 9. All normal port 80 HTTP requests to the bureau domain will then receive a response from the same domain. All req ⁇ iests to a secure port (443), via HTTPS will then receive a response from a common domain.
  • the common domain shall, in tun, implement standard SSL via a trusted server certificate.
  • the web service 33 will service ports 80 and 443 and will run under a windows user with access only to the bureau engine 35 API and only those files associated within the particular merchant's domain. Every request to a particular merchant recorded in the system will return a response created from a single template. The same template is used for each of the merchants. The template performs the following tasks:
  • the process consists of browsing general information about the merchant and its products and/or services, browsing catalogue items, product lines and product prices and information, creating an order and reviewing the order, optionally logging on to receive purchaser terms, paying for the order using credit card or invoicing with specific purchaser terms, and receiving e-mail acknowledgment of the purchase and confirmation of possible delivery.
  • the various pages at the merchants site 13 are populated with data applicable to the above processes. This process is set out in Table 2.
  • catalogue pages are made of a four level tree structure of records as follows:
  • Level 2 The functionality of Level 2 is shown in Table 4.
  • the package - Level 3 - provides groups of images and text associated with a particular Level 2 criteria record, to populate the body of the page. Each group contains a name text, and image and a description text, an order code text and a price text.
  • a Package record shall only be shown for sale if today's date is within a merchant specified Start and Stop date range.
  • the Price in a Package record shall be either GST inclusive or GST exempt.
  • a Package record shall optionally have a merchant defined maximum order allotment.
  • the Delivery Option of a Package record shall be ⁇ delivery only', pickup only', or x both' .
  • a Package record shall only be shown for sale if a ⁇ Relationship' has been set up between the Merchant and the Purchaser.
  • a Relationship shall define a Price Discount.
  • - Package records shall represent two Types of data: x Merchant product for sale' data, or ⁇ Purchaser buying a product' data.
  • a Package, representing a ⁇ purchased product' shall always be Linked to a Transact record.
  • the product Level 4 shows text that populates the body of the page, Each group contains a name text and description text. The functionality of this is shown in Table 6 below:
  • the ordering pages which are administered by the ordering engine 15, provide text to populate the body of the particular pages displayed.
  • the order page presents data concerning the package being sold, the package being bought, the parties and the relationship between the parties and for paid orders, the transaction. This is shown in Figure 5.
  • Logging on to the system invokes an "information page" which requires a customer or merchant to insert a "user name” and a "password”. Logging on as a customer enables invoicing with (if applicalbe) a user specific discount, payment term, delivery cost and credit limit. A successful log-on also allows a history of previous orders to be displayed. An unsuccessful log-on returns an "invalid log-on" response. A logged on customer/merchant will be considered inactive by the system if the bureau administrator site 3 does not receive a response within a set period such as 10 minutes. In this case the session will be deleted from management processing and management data.
  • a history page can be developed which provides text to populate the body of the page displayed.
  • the content of the page is constructed by the system using the catalogue information and displays all products/services for offer to the particular customer. The customer will then be able to create an order from this page by entering a quantity for any products/services listed. If the customer has logged on, the page will then show a history of previously paid orders.
  • Table 10 The functionality of paying for an order is set out in Table 11.
  • An administrator type person authorised by a merchant will be able to insert, modify and delete text and images from the merchant's site for any purpose whatsoever.
  • the administrator person typically at the merchant's site, will be able to insert, modify and disable customer accounts, and also be able to create reports and schedules for reports.
  • Such person will also be able to set up integration to external financial institutions and other related software that may be needed for monitoring purposes .
  • the administrator person at the merchant's site will be able to modify the elements of each page as shown in Table 12.
  • FIG. 6a and 6b there is shown a database schemer for the bureau administrator. It can be seen that the database that is managed within the bureau administration site server 9 is able to retain relevant information for each domain/merchant and information about the product/service that may be offered, and retain relevant information for providing confirmation of purchases to a customer and to the merchant and to provide various reports and searching functions for data.
  • FIG. 7 there is shown an e-mail module which forms part of the bureau administrator site 3 for forwarding e-mail advice of purchasers and/or reports to various recipients.
  • the bureau engine 35 provides a signal to forward an e-mail.
  • the signal enables data to be assembled and forwarded to an e-mail module 39 which passes a message through an e- mail tool such as Microsoft Outlook. That tool then forwards the mail through a gateway 41 for dispatch over the Internet to a recipient.
  • Figure 8 shows a functional flow diagram of the processes involved.
  • FIG 9 shows an overview diagram of a payment gateway with the financial institution 19.
  • a payment engine 17 is invoked which represents a payment gateway.
  • the payment gateway in turn, communicates with the financial institution 19 and processes a credit card payment or direct debit or other processing through an approved account.
  • the financial institution in turn, sends advice back through the payment gateway that the payment has been accepted.
  • the bureau engine 35 can then invoke the bureau administration engine 21 to, in turn, provide advice to both the purchaser customer and the merchant of a successful purchase and transaction, and the need for delivery of the required goods or services purchased.
  • FIG. 10 shows a functional diagram of the processes involved.
  • FIG 11 is a schematic overview diagram showing local image manipulation to manipulate images provided by a merchant for placing onto the merchant's home site in the homepage or any subsequent pages.
  • the images are downloaded and processed through the web service 33 to, in turn, be reprocessed by a pixel grabber and encoder for local image file manipulation and subsequent storing.
  • a pixel grabber and encoder for local image file manipulation and subsequent storing.
  • Figure 13 is an overview diagram of a batch job schedular which can be invoked to provide reports to merchants at periodic intervals such as daily, weekly, fortnightly, monthly etc.
  • the schedular per se is a known utility forming part of the system software resident at the bureau administrator server 9.
  • Figure 14 shows the functional flow process in a delete session process which is triggered by the schedular shown in Figure 13.
  • Figure 15 is a functional flow diagram showing some possible daily jobs that are initiated by the schedular.
  • Figure 16 is a delete/abandon session functional flow diagram.
  • Figure 17 shows a schedule reports functional flow diagram.
  • Figure 18 shows a back-up functional flow diagram.
  • Figure 19 is a clean-up functional flow diagram.
  • Figure 20 shows a typical homepage layout for a fictitious company that offers stickers, seals and cards.
  • a number of conventions have been adopted so as to provide merchants 5 and customers 7 with a graphical interface which appears in a consistent manner throughout various pages in the site. These conventions are:
  • Products for sale appear in a menu on the left - BACK, PRINT, NEXT buttons always appear bottom right .
  • buttons 49, 51, 53, 55 & 57 appear on the product menu 27. Wherever something can be changed or removed, the words update and delete appear as administrative options
  • FIG 20 shows a typical homepage that can be created from a template using data supplied by the merchant 5.
  • This homepage represents the page display in accordance with that shown in Figure 2 herein.
  • the banner 25 displays a homepage, a company logo 23, and a product menu 27 which in this case represents products being stickers, seals, and cards.
  • the navigation bar 31 is shown having clickable buttons 43, 45 and 47 for moving backwards or forwards within the system or for printing a particular page.
  • a part of the navigation bar shows possible credit cards that are accepted by the system. These can form a permanent part of the template according to the financial institution that the merchant signs up for and wishes to use when goods and/or services are purchased.
  • the product menu includes five clickable buttons 49, 51, 53, 55 and 57. When those buttons are clicked by a customer 5 the customer can negotiate through the directory structure for the subject matter related to that button.
  • the customer 7 can be introduced to a four level tiered structure.
  • Four levels have been provided, but other number of levels are also possible.
  • the first level displays catalogue "items”.
  • the second level displays product "lines”.
  • the third level displays "products”.
  • the fourth level provides "individual product detail”.
  • Figure 21 shows the arrangement.
  • Figure 22 shows a screen display at level 1. It is noted that this screen display is not overly cluttered. It also should be noted that the buttons 43 and 47 are still shown present, as are the five clickable buttons 49 - 57. By clicking a particular one of the images 59, 61 or 63 the customer 7 will be taken to level 2 of the directory structure.
  • Figure 23 shows the particular display provided at level 2. It can be seen in this figure that "cards" 63 have been selected and a choice of possible cards is shown. The screen display also again replicates the backwards and forward buttons 43 and 47 and the five 3D clickable buttons 49 -57.
  • FIG. 28 shows the screen display at Level 4. It can be seen that the back button 43, print button 45, and forward button 47, are again displayed, and that the catalogue button in the top right hand corner is also again highlighted.
  • a quantity box 73 is provided for placing a final order and numbers. In some instances, Level 4 may need not be invoked. Accordingly, Level 3 shows a quantity box 69 which can be invoked to signify the number of units required if Level 4 is not provided.
  • quantity box 69 shown in Figure 24 can be merely tagged to indicate the particular product required, and then when the customer 7 is transferred to Level 4 as shown in Figure 25, the customer can make a particular quantity purchase.
  • An additional comments box 75 is provided to place any special orders or notes with the order. For example, the notes may tell the merchant that the goods are to be sent by courier or some other form of delivery means.
  • a "Order" button 77 is provided to invoke purchase.
  • the customer When a customer clicks the "Order" button 77 the customer is transferred to a screen display as shown in Figure 29 where there is provided a summary of the purchase/order made.
  • the customer 7 can review the order and decide to either proceed with purchase or to reject the purchase.
  • the ordering engine 15 forming part of the process of the bureau administrator site is invoked.
  • the order shown in Figure 26 includes a part, in the body of the screen display that shows, the order number, when the order expires, the date the order was created, and whether the order has been paid or unpaid.
  • the order also shows a description of the product, the code number of the product, the price of the product, the quantity ordered, the total price and GST component. It also shows totals.
  • the customer can add or remove individual items in the order. Desirably, for any charge to an individual item an item should be removed from the order and then re-ordered via the catalogue.
  • products that have been placed in the order as shown in Figure 26 can be removed by clicking on the "X" at the end of each line. This will remove a single item from the order.
  • the item can be removed from the order, and then re-ordered from the catalogue as described previously.
  • the order shown in Figure 29 also displays a "delivery", line entry. This shows a particular cost associated with delivery (if applicable) .
  • a customer 7 can elect to pick the goods up directly by clicking the "X" at the end of the "delivery", line item. Once this is done, the cost of delivery . disappears from the order.
  • the customer can then print the order by pressing the print button 45.
  • FIG. 27 A screen as shown in Figure 27 then appears. Here the types of payment methods possible are displayed. In this example, payment can be made by direct debit or invoicing the customer's 7 account or by using credit card. By clicking the required payment option the customer is taken to a log-on page where for direct debit invoice payment or invoice payment, the customer must enter both their particular user name and password, and click a "commit" button. The order is then again displayed, but this time there is provided an extra column which shows a discount which is a percentage discount of the GST inclusive product price that may be offered to the particular customer 7. The totals of all the purchase amounts are then appropriately readjusted.
  • a discount which is a percentage discount of the GST inclusive product price that may be offered to the particular customer 7.
  • a "pay” button is provided so that the customer can then effect payment.
  • the customer has an option to change the way in which payment is to be made at this stage.
  • the applied discount will still apply. Particulars relating to the customer will have been prestored with the bureau administrator and will be recalled.
  • a pay by credit card option is chosen, the user is presented with a screen to enter the credit card particulars. A "commit” or “purchase” button is provided so that once the particulars are entered, the credit card payment can be effected. If desired, appropriate security logos may be applied to this page to give confidence to the customer 7, that providing credit card details via the Internet will not be able to be intercepted. Usual security protocols are invoked through the payment engine 17 and the financial institution 19.
  • Figure 28 shows a tax invoice and receipt that is provided as a further screen display. This can be printed by the customer 7.
  • the receipt whether invoiced or not, will have the merchant's name and other particulars including address and contact details provided.
  • the order number of a paid or invoice order will appear in a contrasting colour to allow the recipient to clearly discern that number and the fact that it has been paid or invoiced.
  • a receipt number is provided that can be used as a reference for administrator reports.
  • the order status is now shown as "accepted” which advises the customer that the credit card has been accepted or the order has been invoiced, and that the merchant has accepted the order.
  • For credit card payment a payment received date is displayed.
  • For invoicing payment terms are displayed.
  • the invoice shows payment method as either invoice or credit card. All the receipts whether invoiced or not include the customer's name, address and contact particulars.
  • a first e-mail is sent to the merchant's e-mail address with a new order message.
  • a second e-mail is sent to the customer's e-mail address with a "thank you" message. If the purchase was made by a credit card, then a further e-mail will have been sent to the customer's e-mail address via the payment gateway to indicate payment has been made.
  • a fast order processing can be invoked. This is typically for customers that have repeat orders and do not require to negotiate through particular levels and pages as described previously.
  • a customer can click on the "Order” button 53 on the navigation bar 31.
  • the second way is to click the "log-on” button on the product menu 27.
  • a "review order” button 57 is provided on the product menu 27 as one of the buttons 49 - 57. If this button is clicked, then a review order display is provided - see Figure 30 - where the customer needs to enter the order number and to press a "Review” button 83. If the order was created under a specific customer account, the customer will then be prompted to log-on with the name and password before he can proceed further. Once the order page is then displayed, the customer may resume working on the order. Previously paid or invoiced orders are also able to be reviewed in exactly the same manner.
  • a merchant administrator person i.e. a person employed by the merchant
  • This administrator is to be contrasted with the bureau administrator of the administrator site.
  • the merchant administrator is a person with authority to change images and words appearing at the merchant's homepage and other directory pages .
  • the merchant administrator also has the ability to confirm orders, create reports, add customer accounts, and even disable the home site.
  • the merchant administrator has the power to administer the particular merchant's home site and because of this ability is required to log-on with a user name and password.
  • buttons 85, 87, 89, 91 and 93 being respectively "orders”, “accounts”, “reports”, “options” and “log-off”.
  • the merchant administrator is not able to place an order but is able to navigate through the catalogue and go to the homepage and logon page and review page represented by the buttons 49 - 57.
  • the bottom of the logon page is also provided with additional buttons representing "report", “show”, “hide” and "add”.
  • the merchant administrator logs-on, the products orders page is displayed as the screen display. n order to change the settings of the homepage, it is necessary for the merchant administrator to click on the "options" button 91. This allows the merchant administrator to change and customise the homepage.
  • “Favourites” is a feature that provides customers direct links to specific pages on the website. Up to five additional buttons will appear as a horizontal line above the body 29. Their appearance would be very similar to the buttons 85, 87, 89, 91 and 93. Each button is linked to a page set within “favourites”.
  • “Features” offers the merchant administrator to enable or disable additional functionality within the homepage.
  • Some of the functions include a Find a page' function and also a *Send us to a friend' function.
  • “Delivery Costs” allow the merchant administrator to set the delivery costs and options of their website.
  • GST Display sets the option whether the prices within the website are to be GST inclusive or exclusive.
  • “Integration” sets the financial package (MYOB) to which the financial data is to be expprted to.
  • “Positioning” sets the option whether the website does automatic positioning or manual positioning of the order of the goods. When set on automatic positioning' the website will order the goods by the title of the good then the price of the good.
  • Promotions will display a list of options concerning the promotion of items within the website.
  • the merchant administrator can stop all promotions on the website or view a list of items that are currently being promoted.
  • the merchant administrator When the merchant administrator is building a homepage, the merchant administrator logs on and then clicks the homepage button in the top right hand corner. At the merchant administrator level, the merchant is able to similarly negotiate the displayed homepage, insert images and/or text particular to the merchant's goods or services.
  • the merchant administrator can then create a "log-on" page for customers when the system requires only approved customers to access the site.
  • the merchant administrator by clicking the "long-on button" of the group of buttons 49 - 57, the merchant administrator is directed to the log-on page for log-on by a customer and allows tailoring of the images and words appearing on that page.
  • the merchant administrator can navigate through the various pages required, to construct the pages as they would appear to customers.
  • the various pages are provided within templates for the particular merchant's site and the merchant administrator merely configure those templates to suit the particular goods and services being offered.
  • the merchant administrator In order to monitor product orders, the merchant administrator will log-on to the system and press the "product orders" button 85 (see Figure 31) . A screen will then be displayed similar to that as shown in Figure 33.
  • the merchant administrator will be aware of the need to monitor product orders after receiving an e-mail sent by the bureau administrator to advise that there have been products and purchases made. It is then up to the merchant to fulfil the order. Accordingly, the merchant administrator logs on to the "product orders" page and notes the orders made. As can be seen from Figure 35, the orders are shown under "status" as being accepted.
  • the system proposes that it store accounts. These accounts relate to the merchant itself, to customers, and to suppliers of goods and/or services to the merchant.
  • the administrator account is for the merchant administrator.
  • the supplier account typically represents special business offerings. These accounts are set up to allow only specific supplier customers to access specific business offerings. It is assumed that the supplier is someone who will be able to fulfil orders made for the supplier's specific business offerings.
  • the customer account is typically for someone who will purchase the goods and services offered by the merchant.
  • the customer accounts are provided with an order history (as discussed in the fast order processing above) . No history records are provided for casual customers.
  • a merchant administrator can log on to the system and click "account” button 87 - see Figure 31. This allows the merchant administrator to obtain access to the account details and update and/or delete account particulars. Accounts are created by clicking the "ADD" button and an option will be provided for further clicking for creating either a new customer or a new supplier. Customer detail can be imported from the associated accounts package such as MYOBTM. The account details are used for providing the tax invoice and receipt that is generated by the system. Typically, the account details include business name, first name, last name, business registration number, user name, password, address, state, postcode, phone number, fax number, e-mail address. Further, relationships can be set up with the account concerning discounts, deliveries, terms and credit limits.
  • Financial reports can be provided for any of the following month, week, day, period to date, fiscal period.
  • a screen display can be provided for an operator to click any one of these particular options and then the report will be run.
  • a typical financial report is shown in
  • the report shows a receipt number (as a unique reference number for each transaction) , customer name, total amount transacted, GST inclusive, the GST portion of the total, date and time transaction.
  • the administrator of the merchant's site can log in to the system and schedule reports through the schedular facility that is provided. This is achieved by the administrator generating a report.
  • the report has options which can be clicked by the administrator if scheduling is required. The options may be - e-mail this report to me 1. Now, 2. Daily, 3. Weekly, 4. Monthly. Once clicked, a report is stored in the database and updated and e-mailed as per the option selected.
  • the administrator of the administrator site arranges for the various credit card facilities to be in place, and that administrator can then take the responsibility directly for the payments of the ordered goods and services.
  • each of the merchants may be required to obtain the necessary credit card facility themselves. In this way, the administrator of the administrator site is not directly responsible for the credit card transactions themselves.
  • the merchant Whilst it has been described that the merchant must acquire it's own domain name, it is also within the context of the general scope of the invention that the merchant can online apply with the administrator of the administrator site for that administrator to obtain a domain name on behalf of the merchant. An appropriate service charge can be rendered for that activity. In this way, the domain name can be assigned directly by the administrator and the merchant informed that the domain name is in place. Accordingly, the administrator of the administrator site can then access the various initial pages to configure them for the merchant's particular requirements. All of the above processes can be conducted online during a single session. These and other modifications may be made without departing from the ambit of the invention the nature of which is to be determined from the foregoing description.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne des sites et des procédés de commerce électronique faisant appel à un site administrateur de bureau (3). Le site administrateur de bureau (3) a accès à un générateur de page d'accueil de site commercial (11) qui contient un modèle de page d'accueil qui peut être configuré par un commerçant, de sorte que les biens et tous les services destinés à être vendus par le commerçant peuvent être affichés sur la page d'accueil. Le site administrateur de bureau (3) a également accès à un moteur de commande (15) permettant aux clients qui visitent un site d'accueil d'un commerçant (13) de commander des biens et/ou des services proposés par ledit commerçant via la page d'accueil. Le site administrateur de bureau (3) a également accès à un moteur de paiement (17) de sorte n'importe quel biens et/ou services commandés par des clients (7) peut être payés. Le site administrateur de bureau (3) a également accès à un moteur d'administration de bureau (21). Lorsque le paiement est effectué, le site d'administration de bureau (21) informe des commerçants (5) que les biens et/ou services spécifiques qu'ils proposent ont été payés.
PCT/AU2003/000853 2002-07-03 2003-07-02 Systeme et procede de commerce electronique WO2004006143A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003236579A AU2003236579A1 (en) 2002-07-03 2003-07-02 E commerce system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AUPS3348 2002-07-03
AUPS3348A AUPS334802A0 (en) 2002-07-03 2002-07-03 E commerce system and method

Publications (1)

Publication Number Publication Date
WO2004006143A1 true WO2004006143A1 (fr) 2004-01-15

Family

ID=3836904

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2003/000853 WO2004006143A1 (fr) 2002-07-03 2003-07-02 Systeme et procede de commerce electronique

Country Status (2)

Country Link
AU (1) AUPS334802A0 (fr)
WO (1) WO2004006143A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8621575B2 (en) 2008-04-28 2013-12-31 Ice Organisation Ltd Secure web based transactions
TWI422962B (zh) * 2006-12-05 2014-01-11 Hoya Corp 灰階光罩之檢查方法、液晶裝置製造用灰階光罩之製造方法以及圖案轉印方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000029976A1 (fr) * 1998-11-16 2000-05-25 Trade Access, Inc. Systeme integre de conception d'un site web a distance
WO2001050391A1 (fr) * 1999-12-30 2001-07-12 Ecatalystone.Com, Inc. Procede de gestion de transactions sur l'internet au moyen de proxy et avec des instruments financiers uniservice
US20020013760A1 (en) * 2000-03-31 2002-01-31 Arti Arora System and method for implementing electronic markets
US20020065772A1 (en) * 1998-06-08 2002-05-30 Saliba Bassam A. System, method and program for network user access

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065772A1 (en) * 1998-06-08 2002-05-30 Saliba Bassam A. System, method and program for network user access
WO2000029976A1 (fr) * 1998-11-16 2000-05-25 Trade Access, Inc. Systeme integre de conception d'un site web a distance
WO2001050391A1 (fr) * 1999-12-30 2001-07-12 Ecatalystone.Com, Inc. Procede de gestion de transactions sur l'internet au moyen de proxy et avec des instruments financiers uniservice
US20020013760A1 (en) * 2000-03-31 2002-01-31 Arti Arora System and method for implementing electronic markets

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI422962B (zh) * 2006-12-05 2014-01-11 Hoya Corp 灰階光罩之檢查方法、液晶裝置製造用灰階光罩之製造方法以及圖案轉印方法
US8621575B2 (en) 2008-04-28 2013-12-31 Ice Organisation Ltd Secure web based transactions

Also Published As

Publication number Publication date
AUPS334802A0 (en) 2002-07-25

Similar Documents

Publication Publication Date Title
US20040078276A1 (en) System for electronic merchandising and shopping
US7006993B1 (en) Method and apparatus for surrogate control of network-based electronic transactions
US7668782B1 (en) Electronic commerce system for offer and acceptance negotiation with encryption
AU2011276949B2 (en) A system for electronic transactions
KR100620192B1 (ko) 저장값 전자 인증서 처리
US20160132842A1 (en) Presenting previously hidden user interface options within a graphical user interface
US20080172304A1 (en) System and method for enabling cash gifts in an online gift registry
US20090099941A1 (en) System and method for enabling cash gifts in an online registry
US20030182204A1 (en) System for managing eletronic receipt according to eletronic commerce and method for managing thereof
US20030014328A1 (en) Method and apparatus for offering digital content for sale over a communications network
US20080208717A1 (en) Internet auction system and method
US20150186391A1 (en) Method of Document Processing for a Fully Integrated Ecommerce System
EP1170690A1 (fr) Caddie en ligne partagé
WO2002029508A2 (fr) Systeme et procede d'achat en ligne assiste par courtier
US7548888B2 (en) Digital computer system and methods for implementing a financial transaction
US20010037263A1 (en) Electronic commerce support system
KR20010077123A (ko) 공동 장바구니를 이용한 컴퓨터 네트워크상에서의 쇼핑일괄 지불 및 배송 방법
JP7239211B1 (ja) ギフトプロモーション支援システム及び実店舗
WO2004006143A1 (fr) Systeme et procede de commerce electronique
US20020052783A1 (en) Method and apparatus for establishing a customized electronic site
KR20010087572A (ko) 물품 구매와 제공을 위한 방법
CA2390714A1 (fr) Methode et appareil facilitant une operation de commerce electronique par le biais d'un etat detaille
KR20050083397A (ko) 인터넷 판매대리인을 통한 전자상거래 운영시스템 및 그운영방법
JP2001306968A (ja) 商品購入事務処理方法
WO2001022333A9 (fr) Reseau de financement de comptes d'unites d'achat prepayees electroniques et procede associe

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP