Systems and methods for transaction authorization and dynamic memberhips to facilitate E-commerce

A method for managing an e-commerce system comprising: accepting an order to sell one or more goods or services from a seller to a buyer; charging the buyer an amount according to the order; holding the amount in an intermediary; receiving a first signal from the buyer upon the seller's delivery of said one or more goods or services; retrieving a second signal; verifying the first signal against the second signal; and making at least a portion of the amount available to the seller if the first signal and the second signal satisfy a predetermined relationship.

FIELD OF INVENTION

The present invention is related to a system and method for managing e-commerce transactions, in particular, to a system and method for enabling transaction authorization and dynamic membership to facilitate e-commerce transaction.

BACKGROUND OF THE INVENTION

E-commerce has exploded over the past decade, as more and more merchants move from having physical brick and mortar stores to having online stores to increase their sales.

Method presently available generally include a transaction involving a buyer and a seller, wherein the buyer agrees to make a payment to seller in exchange for certain goods or services from the seller. There are drawbacks that can be associated with such transactions, such as vulnerability to counter-party issues. For example there is likely no guarantee that the buyer will receive the goods or services ordered. Or, after receiving the goods or services, the goods or services may be different from what was described or expected. In addition, in accordance with many methods currently available, when the buyer pays the seller, sensitive payment information about the buyer is passed on to the seller104and the buyer must rely on the seller to charge the correct amount and protect the buyer's sensitive payment information.

In accordance with another example of methods presently available, a buyer may attempt to repudiate online purchases claiming that the goods or services were not received or that the goods or services are unsatisfactory. It can be difficult for the seller to prove otherwise even with a tracking number from a shipping company.

Accordingly, it is desirable to provide an improved e-commerce method and system that overcomes drawbacks and inadequacies of known methods and systems.

SUMMARY OF THE INVENTIONS

Generally speaking, the present invention is aimed at improving the management and increase security of an e-commerce system. In accordance with the invention, a method for managing an e-commerce system is provided, comprising the steps of accepting an order to sell one or more goods or services from a seller to a buyer; charging the buyer an amount according to the order; holding the amount in an intermediary; receiving a first signal from the buyer upon the seller's delivery of said one or more goods or services; retrieving a second signal; verifying the first signal against the second signal; and making at least a portion of the amount available to the seller if the first signal and the second signal satisfy a predetermined relationship.

Another object of the invention is to provide an improved computer system for managing an e-commerce system, the computer system comprising: a data processor; a memory storage device comprising a plurality of modules, wherein the plurality of modules comprise: a first module comprising a first computer code executable by the data processor, wherein upon execution of the first computer code, the first module accepts an order to sell one or more goods or services from a seller to a buyer; a second module comprising a second computer code executable by the data processor, wherein upon execution of the second computer code, the second module charges the buyer an amount according to the order; a third module comprising a third computer code executable by the data processor, wherein upon execution of the third computer code, the third module synchronizes an algorithm for generating signals with the buyer; a fourth module comprising a fourth computer code executable by the data processor, wherein upon execution of the fourth computer code, the fourth module receives a first signal from the buyer upon seller's delivery of said goods or services; a fifth module comprising a fifth computer code executable by the data processor, wherein upon execution of the fifth computer code, the fifth module retrieves a second signal; a sixth module comprising sixth computer code executable by the data processor, wherein upon execution of the sixth computer code, the sixth module verifies the first signal against the second signal; and a seventh module comprising seventh computer code executable by the data processor, wherein upon execution of the seventh computer code, the seventh module makes at least a portion of the amount available to seller if the first signal and the second signal satisfy a predetermined relationship.

Yet another object of the invention is to provide an improved system for managing an e-commerce transactions comprising: a shopping module; an order verification module; and a payment module; wherein the shopping module accepts an order from a buyer for a purchase of a product or service, charges the buyer an amount according to the order and holds the amount in an intermediary; wherein the order verification module verifies the buyer's receipt and acceptance of the purchase; and wherein the payment module makes at least a portion of the amount available to the seller.

Still other objects of the invention will in part be obvious and will, in part, be apparent from the specification.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Certain exemplary embodiments of the present invention will now be described with reference to the drawings. In general, such embodiments relate to a system or a method of managing an e-commerce system.

As used herein, a buyer includes any entity placing or attempting to place an order for example, for a purchase of goods or services, or seeking information about goods or services, regardless of whether the transaction ultimately takes place. Said information may include but is not limited to product/service descriptions, prices, seller reputation, pickup/delivery options, payment options and any user-contributed content. In addition, a buyer may also include a buying agent that makes a purchase on another entity's behalf.

A seller includes any entity that offers products and/or services to be acquired with or without any web or physical presence. A seller may include any selling agent regardless of the existence of inventory or delivery service.

A special user includes any entity using an e-commerce system with a purpose other than purchase or sale. A special user may be but is not necessarily a registered user. By way of non-limiting example, a special user may be an entity that wishes to track the status of a specific transaction.

A user includes any entity using a platform regardless of said entity's actual intent. A user may also be a member of an e-commerce platform. A user may have more than one role in one or more transactions using the e-commerce platform. Each user may have a user profile in a user database, wherein the user profile may contain user-contributed content, public information and system data.

A network includes a collection of members who are user(s), the network having at least one member. A network can be created for any purpose. Some nonexclusive examples of networks are personal networks comprising users who are friends to one party, geographical networks comprising users within a specific area and product user networks comprising users that use a particular product.

An example of a method presently available is illustrated inFIG. 1, wherein generally, a transaction106involves a buyer102and a seller104. In accordance with the method shown, transaction106begins when buyer102agrees to make a payment110to seller104in exchange for a goods or services120from seller104. The method does not provide a guarantee that buyer102will receive goods or services120and if received, that they will be satisfactory. In addition, as buyer102pays seller104, sensitive payment information about buyer102is passed on to seller104and buyer102must rely on seller104to charge the correct amount and to protect sensitive payment information of buyer102. Reference is made toFIG. 2, wherein an e-commerce transaction in accordance with an embodiment of the present invention includes an order is placed by a buyer210for goods or services from a seller230, and a payment240is made from buyer210to seller230using a payment instrument through an intermediary220. The payment instruments may include one or more of credit card, prepaid refill card, cash deposit, electronic fund transaction, virtual private payment account, physical check, or other instruments suitable for transferring funds from buyer210to seller230.

In the embodiment shown, intermediary220receives payment240from buyer210and intermediary220temporarily holds payment240, for example, while buyer210and seller230make efforts to complete the transaction. If buyer210is satisfied with the goods or services from seller230, buyer210may cause payment250to be transferred from intermediary220to seller230, such as by sending an authorization signal to intermediately220.

The authorization signal may include a code generated based on the transaction number, buyer210's identification or biometric character, or a combination of parameters. The authorization signal may also include a signal with embedded identification information, and may be in any form or presentation that can be recognized directly or indirectly by intermediary220. Examples of authorization signal may include simple random code, such as3242, or it may a more complex code, such as DFS32S213-SD20-3FFD, which may embed optional transaction or security information. Authorization signals may be, but not limited to numerical, alphabetical, visual, audio signals or combinations thereof.

Once intermediary220receives the authorization signal from buyer210, intermediary220may forward payment250to seller230through one or a combination of acceptable disbursement instruments. An exemplary embodiment of disbursement instruments may include an electronic fund transaction, a credit to a bank account, a virtual private payment account, or the issuance of a physical check, as a matter of application specific to design choice.

Intermediary220may charge a transaction fee for facilitating the receipt of payment240and the transfer of payment250. This fee may be billed to buyer210, seller230, or both. Intermediary220may also collect this fee by charging an additional amount from buyer210, deducting an amount payable to seller230or in any other way contemplated by one of ordinary skill in the art.

In accordance with an embodiment of the invention illustrated inFIG. 3, an e-commerce system300resides on a network of computers accessible by a plurality of clients such as buyers210, sellers230and/or special users310. E-commerce system300may be implemented through the use of a centralized database or one or more individual databases for each module or sub-module, or a combination thereof.

As shown, E-Commerce system300may include one or more interfaces341,342,343which may facilitate communication between parties, between parties and devices, between parties and modules, and between devices and modules between various parties, devices and media, and various interfaces, via one or more communication devices330.

Communication devices330may include, but not limited to, computers331, phones332and any device or means capable of receiving information from e-commerce system300and/or sending instruction to e-commerce system300.

Users may interact with e-commerce system300through one or more user interfaces, such as a buyer interface341, a seller interface342or a special user interface343, over one or more communication links335to engage in activities. Communication links335may be any media supported by the user interfaces3411,342,343, including but not limited to one which enables the connection of computers, such as the Internet, a phone service network or which allows communication over phones, and satellites on which GPS-capable devices can operate.

User interfaces may include one or more web pages351, programmable Application Programming Interfaces (API)352, automated phone services353or combinations thereof. Web pages351may enable the users to interact using a browser. Programmable APIs352may enable interaction via custom application, such as a custom application for a specific portable device. Automated phone services353may enable users to interact via voice or Short Message Service (SMS) phone service. Through these interfaces, users may be able to manage sales, purchases, transaction logistics and related activities.

In an exemplary embodiment of the present invention, e-commerce system300may include user interfaces for three groups of users, namely buyer interface341, seller interface343and special user interface342for buyers210, sellers230and special users310, respectively, and a database cluster320and a network of modules. These modules may include, by way of non-limiting example, an integrated shopping module360, a reward module370, a product discovery module380and a membership status evaluation module390. These modules may be connected to a database cluster320. These modules may be implemented in a single data processor or in a plurality of data processors. It is to be understood that the number of modules and sub-modules may vary without deviating from the scope of the invention, as a matter of application specific design choice.

Integrated Shopping Module360

In accordance with an exemplary embodiment, integrated shopping module360may facilitate all the shopping activities within e-commerce system300. Integrated shopping module360may be the central processing module that preferably facilitates buyers210and sellers230in trading, reaching a final agreement and completing the transaction. Integrated shopping module360may interact with reward module370, product discovery module380, membership status evaluation module390and central database cluster320.

In an exemplary embodiment of the present invention, integrated shopping module360preferably includes six sub-modules, a purchase/sale sub-module361, an order management sub-module362, an order verification sub-module363, a cancellation/return sub-module364, a post sale sub-module365and a payment sub-module366, each one specializing in handling one aspect of a typical purchase/sale routine. Preferably, purchase/sale sub-module316enables seller230to create new listings or modify an existing listing and enables buyer210to make a purchase. Purchase/sale sub-module316may also accept an order to sell goods from seller230to buyer210. Preferably, order management sub-module362enables buyer210and seller230to manage pending orders, completed orders and canceled orders. Order verification sub-module363preferably ensures that buyer210is satisfied with the order before releasing payment to seller230. Cancellation/return module364preferably facilitates buyers210and sellers230initiate, manage and complete order cancellations. Post sale sub module365preferably enables both buyers210and sellers230to carry out post-sale activities, such as leaving feedback for each other. Payment sub module366preferably handles the payment and refund related activities and issues.

In addition, special users310may also communicate with integrated shopping module360via special user interfaces343for special purposes, which will be discussed in further detail below with respect toFIG. 8.

In accordance with an exemplary embodiment, reward module370may calculate and issue reward points based on users' activities. The reward may be part of either or both of a royalty system and a payment instrument for buyers to purchase goods or services. Reward module370preferably includes a reward calculation sub-module371, a reward issuer sub-module372, a reward redemption sub-module373and other supplemental sub-modules to manage reward activities in accordance with application specific design choice.

Reward calculation sub-module371preferably calculates the amount of reward for one or more activities by buyer210and issues the reward. By way of nonlimiting example, when buyer210attempts to redeem a reward, reward redemption sub-module373validates the reward redemption request.

Reward module370is preferably connected to buyer interfaces341, through which buyers210can manage handle certain aspects of the rewards, such as crediting an user's account for rewards earned from purchases made.

Product Discovery Module:

In accordance with an exemplary embodiment, both buyers210and sellers230may interact with product discovery module380, which preferably enhances the shopping experience, for example, by facilitating both parties in locating products/services, recommending products and managing user-contributed contents for the products/services.

In accordance with an exemplary embodiment of the present invention, product discovery module380may include an integrated search engine sub-module381, a social networking sub-module382and a user-contributed content engine sub-module383.

Integrated search engine sub-module381preferably allows a user to search for product/service offering in a vast database of product inventory/description, user profile/reputation, user contributed content, manufacturer information and the like. Integrated search engine381can preferably find the closest match if nothing matching all the criteria is found. It preferably makes recommendations for products and services that may interests the user based on one or more parameters, such as the user's purchase/sale patterns, occupation, geographical location and other information available.

Social networking sub-module382preferably allows a user to connect with other users within different kinds of networks, such as personal networks, geographical networks or product user networks. It also may allow buyers210to subscribe to updates (such as new listings, user contributed contents) from fellow users and research about product usability information within a specified network. User-contributed content engine383preferably allows users to submit reviews, pictures, videos or any other user-contributed content regarding one or more products/services. These contents may ultimately help other users in making decisions regarding selling and purchasing the products/services.

Membership Status Evaluation Module390:

In accordance with an exemplary embodiment, membership status evaluation module390calculates membership status based on external parameters from other modules, such as integrated shopping module360. It preferably enables the implementation of a dynamic membership and policy system. Whereas membership status evaluation module390may be directly connected to user interfaces341,342,343, such a direct connection is not necessary. Rather, membership status evaluation module390may be networked with other modules whose activities are contributing parameters to membership status evaluation module390that effectively influence the membership status.

It is to be appreciated that the embodiments of the modules and sub-modules in the aforementioned example are merely a logical organization of different features offered by e-commerce system300. Although the present disclosure has been illustrated with respect to a particular sample module organization and architecture, it is to be appreciated that various module organization and/or architecture suitable for carrying out the present disclosure may be employed and are intended to fall within the scope of the hereto-appended claims.

FIG. 4illustrates an embodiment of an integrated instrument processor400, which includes a payment processing interface403and a disbursement processing interface404. These two interfaces may be connected to one or more individual instrument processors401, which may be linked to one or more corresponding intermediary instrument accounts402. Integrated instrument processor400may be linked to a payment sub module366, which allows buyer210and seller230to set up preferred payment and distribution instruments. Exemplary embodiments of registration processes for the various payment instruments available to buyer210are illustrated inFIGS. 6A-6F. Exemplary embodiments of registration processes for the various disbursement instruments available to seller230are illustrated inFIGS. 7A,7B and7C.

In accordance with an embodiment, payment sub module366delegates the responsibility for processing each payment instrument to individual instrument processors401via payment processing interface403and delegates the responsibility for processing disbursement through disbursement processing interface404.

Referring toFIG. 4, the links between individual instrument processors401and interfaces403,404represent communication between processors401and their corresponding interfaces403,404. These links may be a wired or wireless connection regardless of communication protocol. One skilled in the art will appreciate that the network practicing an embodiment of the present invention may take various forms. Accordingly, one may use other types of networks and combinations of network connections in a given embodiment of the present invention without deviating from the scope of the invention.

Each individual instrument processor401may be implemented as a module within a computer system, a stand-alone system, a group of networked computers, or other systems as contemplated by one of ordinary skill in the art. Individual instrument processors401within the integrated instrument processor400may have individual database and/or a centralized database cluster for storing information related to the payment and disbursement process.

Individual instrument processors401may specialize in processing one form of instrument. These instrument processors401may include a reward processor410, a credit card processor420, a prepaid refill card processor430, a cash processor440, an electronic fund transaction processor450, a virtual private payment account processor460and a physical check processor470.

Furthermore, certain individual processors401may be connected to one or more corresponding intermediary accounts402. In the embodiment illustrated inFIG. 4, when payment is received by one of the individual instrument processors401, the corresponding intermediary account402is credited. For example, payment received by credit card processor420is credited to an acquirer account421; payment received by prepaid refill card processor430is credited to a sale account431; payment received by cash processor440is credited to a bank account441; payment and disbursement received by electronic fund transaction processor450is credited and debited from a payment bank account451and a disbursement bank account452respectively; payment and disbursement via virtual private payment account processor460are credited to and debited from two virtual accounts461and462respectively; payment and disbursement via physical check processor470are credited to and debited from two bank accounts471and472respectively.

Referring to the embodiment shown inFIG. 4, the links between the individual instrument processors401and corresponding instrument accounts402represent association between processors and accounts. Although there are separate accounts for different cash flow activities of different processors in this exemplary embodiment of the present invention, it is to be appreciated that the association of the processors and bank accounts can be re-organized. Multiple processors may share compatible accounts. Alternatively, cash flow activities within an instrument processor may be further broken down to use more accounts for categorization. Although not illustrated here, the fund within intermediary220instrument accounts may be transferred from one to another to optimize the operation of the payment system.

In accordance with an exemplary embodiment, payment sub module366is linked to a seller account database405and an order verification module363. Seller account database preferably stores seller account information, such as balance, disbursement history, etc. Order verification module363preferably continuously monitors the status of pending transactions and notifies payment sub module366as transaction status changes. For example, order verification module363may notify payment sub module366if a cancellation of a pending transaction occurs. Payment sub module366may post pending credit to seller230account and make the credit available for disbursement after order verification module363confirms the satisfactory delivery of goods to buyer210. Seller230may also request disbursement of the available fund in the preferred disbursement instrument(s). The instrument processors may fulfill the disbursement request by transferring the fund from the intermediary's account(s) to the seller's account(s).

For reasons of security control, fund transfer execution or any other reason, it may be preferred to require payment sub module366to collect identification information, conduct preliminary background checks and extract historical user information (e.g. transaction history) prior to the registration and execution of payment and disbursement instruments. With the user's authorization, payment sub module366may also make use of information that was previously provided by the user along with newly gathered data and payment sub module366may pass on such information to the appropriate processor, for example, to complete payment or disbursement registration or execution. By way of non-limiting example, reward processor410may require buyer210's transaction history from e-commerce system300to calculate the available reward that buyer210may redeem; electronic fund transaction processor450may request account information from the bank authority.

One skilled in the art will appreciate that the present disclosure is not limited to computer network architecture400. Specifically, various instrument processors and their functions as illustrated above may be distributed differently. It is to be appreciated that payment module363along with all the individual instrument processors401and their components may be broken down and managed by intermediary220or any other third-party systems. Payment sub module366may incorporate functions of certain instrument processors, such as reward processor410, and process internal rewards.

Reference is made toFIG. 5, which illustrates how payment is submitted by buyer210and released to seller230via an intermediary220in accordance with an aspect of the present invention. In the embodiment illustrated, in step505, seller230registers at least one disbursement instrument with payment sub module366. In step510, buyer210registers at least one payment instrument with payment sub module366. Alternative, buyer210may register at least one payment instrument with payment sub module366prior to seller230registering at least one disbursement instrument with payment sub module366. In step515, buyer210and seller230agree upon a transaction through interaction in e-commerce system300. The transaction may involve seller230listing goods for sale and buyer210committing to make a purchase. Alternatively, buyer210may list what is wanted and seller230may commit to fulfilling providing what is in the buyer's listing. However, the mutually agreed upon transaction is not limited to the aforementioned examples. For example, Steps510may precede step505without deviating from the scope of the invention.

In accordance with the embodiment illustrated, in step520, if payment is necessary, buyer210is prompted to make a payment to intermediary220. Buyer210may use one or more payment instruments such as one or a combination of the previously registered payment instruments. Buyer210submits payment to intermediary220with the preferred instruments via payment sub module366. In step525, intermediary220charges and receives the payment from buyer210and holds the payment in one or more intermediary instrument account(s)402. In step530, payment sub module366shows the amount payable to the seller230as pending in seller's account. At this time, seller230is not yet authorized to access the fund. In step535, buyer210authorizes the transaction to the seller230. Seller230proves delivery to order verification module363. Once the transaction is verified, payment sub module366makes the amount payable to seller230available in seller's account for disbursement in step540. In step545, seller230selects a previously registered disbursement instruments or registers for a disbursement instruments then instructs payment sub module366to disburse the available fund from seller230's account. Alternatively, seller230may instruct payment sub module366to disburse available balance from seller230's account to external bank account periodically. In step550, payment sub module366disburses the available balance in seller's account according to predetermined rules, if any.

Payment Instrument Registrations

Reference is made toFIGS. 6A-6F, wherein certain embodiments of the buyer registration of at least one payment instrument with the payment module of step510are illustrated. More specifically,FIGS. 6A,6B,6C,6D,6E and6F illustrate embodiments of the process of step510wherein the payment instrument is a credit card, pre-paid card, cash, bank account, virtual private payment account and physical check, respectively.

1. Credit card: In accordance with the embodiment illustrated inFIG. 6A, the routine preferably begins with step605A, in which payment sub module366presents buyer210with a user interface enabling buyer210to enter credit card registration information. In step610A, buyer210preferably enters name, address, card association, card number, and card expiration date and/or other credit card related information through a user interface. In step615A, payment sub module366may send user-provided information to credit card transaction processor420for comparison and registration processing. In step620A, credit card transaction processor420may compare the user-provided information against the official record on file. Alternatively, credit card transaction processor420may delegate the data comparison task to the credit card issuer. Upon completing the comparison, a metric indicating the degree to which the provided information match with the official record is preferably returned. This metric may be a score indicating the risk associated with the transaction. In step625A of the embodiment illustrated, credit card transaction processor420sends payment sub module366a metric indicating such risk. In step630A, payment sub module366, based on the returned metric, determines whether the risk metric poses significant risk, wherein the metric is greater or lower than the predetermined threshold metric value in accordance with an embodiment of the invention. If the metric indicate a significant risk, the “YES” branch is followed to step640A, wherein credit card registration is denied, and the routine returns to the end of step510. If the metric indicates that the credit card registration does not pose significant risk, the “NO” branch is followed to step635A, wherein payment sub module366creates a registration record for the credit card. The registration record may then be stored in a registration database at payment sub module366. Preferably, the routine then proceeds to the end step510.

2. Pre-paid card: As illustrated inFIG. 6B, an embodiment of the routine may begin at step605B, in which buyer210locates a prepaid refill card vendor. In step610B, buyer210may purchase a prepaid refill card with a specified card value. The prepaid refill card may have a visible card number and a covered pin number. Each card number for the prepaid refill card can be unique and accompanied with a pin number. In step615B of the embodiment illustrated, seller230activates the prepaid refill card upon purchase by sending the card number to prepaid refill card processor430. The activation process may involve an activation server. The value of the card may be stored on the card, a remote server, both, or on another suitable device. In step620B in the illustrated embodiment, buyer210uses buyer interface341to initiate the refill procedures via payment sub module366. In step625B, buyer210preferably enters the unique card number and the accompanied pin number using buyer interface341. In step630B, prepaid refill card processor430may enter the user-provided information (e.g. card number and pin number with the card numbers) in the system to validate the card. In step635B, prepaid refill card processor430preferably determines whether or not the user-provided information is correct. Preferably, if prepaid refill card processor430determines that the user-provided information is incorrect, the “NO” branch is followed to step645B, wherein refill of the buyer's account is denied, and the routine returns in the end of510. If the information is determined to be correct, then the “YES” branch is preferably followed to step640B, wherein payment sub module366applies a one-time credit to buyer210's account and disables the used card. The routine then may proceed to the end of step510.

3. Cash: An embodiment of the invention is illustrated inFIG. 6D, wherein in step610C, payment sub module366instructs buyer how to make a cash deposit. In step615C, buyer210may deposit cash at an acceptable cash deposit location which is registered with cash processor406. In step620C, cash processor406may notify payment sub module366that buyer210has deposited prearranged amount of cash. Upon the notification that buyer210has made a cash deposit, payment sub module366preferably updates buyer's account and applies a one-time credit to indicate that buyer210has completed the deposit.

4. Bank Account: Referring toFIG. 6D, an embodiment of the routine begins with step605D. Payment sub module366preferably presents buyer210with a user interface enabling buyer210to enter bank account registration information, such that in step610D, buyer210may enter name, routing number, account number and other relevant information through the user interface. In step620D, payment sub module366may provide user-provided information to electronic fund transaction processor450to retrieve account information, wherein electronic fund transaction processor450may review a negative history database to determine if there is negative history related to the account. One may use any negative history review known to those skilled in the art without deviating from the scope of the invention. If negative history is found to an extent surpassing a preferably predetermined threshold and determined to be significant negative history, the “YES” branch may be followed to step635D, and registration of the bank account as a payment instrument is denied. If significant negative history is not found, then the “NO” branch is preferably followed to step630D wherein electronic fund transaction processor450notifies payment sub module366that transaction requests will be accepted for the bank account. Payment sub module366may then create a registration record indicating that the bank account has been registered for debiting in electronic fund transactions. This registration record is preferably stored in a registration database at payment sub module366.

5. Virtual private payment account: Reference is made toFIG. 6E, wherein an embodiment of the invention is illustrated. The routine preferably begins in step605E, in which payment sub module366presents buyer210with a buyer interface341enabling buyer210to enter the virtual private payment account registration information. In step610E, buyer210may enter the account provider and the account number for the virtual private payment account. In step615E, payment sub module366may provide user-provided information to virtual private account processor460for validation. If the account validation process fails, the “NO” branch may be followed to the step635E where the virtual private account registration is denied. If account validation succeeds, the “YES” branch may be followed to step620E where virtual private account processor460retrieves the account information from the virtual private account provider. In step625E, virtual private account processor460may determine the account's eligibility for being accepted as a payment instrument based on the information previously retrieved. The grounds for determining the account's eligibility may vary according to the virtual private account. In step630E, payment sub module366may add the virtual private account into a registration database if the account is determined to be eligible in step625E. Preferably, the routine then proceeds to the end of step510. If the account is determined to be ineligible in step625E, then in step635E, the virtual private account registration may be denied and the routine may return to the end of step510.

6. Physical check: In accordance with the embodiment illustrated inFIG. 6F, in step605F, payment sub module366instructs buyer210to submit a physical check, such as a paper check or other physical check as contemplated by those of ordinary skill in the art. In step615F, buyer210may submit a physical check in a method specified by check processor470. As illustrated, in step620F, check processor470receives a physical check and verifies buyer210's identity and in step625F, check processor470processes the check and obtains the payment specified by the check. Preferably, if the check is cleared, the routine proceeds to step625F, otherwise the routine proceeds to the end of step510. In step630F, check processor470may electronically notify payment sub module366that the buyer's check has been cleared. In step635F, payment sub module366may receive notification from check processor470and update buyer's account with a onetime credit to indicate that buyer210has completed the check deposit. The routine then preferably proceeds to the end of step510.

Disbursement Instrument Registrations

Reference is made toFIGS. 7A-7F, wherein certain embodiments of the disbursement instrument registration of at least one disbursement instrument with the payment module of step505are illustrated. More specifically,FIGS. 7A,7B and7C illustrate embodiments of the process of step505wherein the payment instrument is a bank account, virtual private payment account and physical check disbursement, respectively. As illustrated inFIGS. 7A,7B, and7C, registration may begin when seller230initiates registration on payment sub module366. See Steps705A,705B and705C. Seller may enter necessary information, such as user information, account identifier and other information. Using information provided by payment sub module366, individual instrument processors401preferably validates the account's existence and/or the user's identity. For example, in the embodiment of step715A illustrated, payment sub module366provides the information entered by seller230to electronic fund transaction processor450to check if the account information matches with an existing account; in step715B, payment sub module366provides the information entered by seller230to virtual private account processor460to check if the account information matches with an existing account; and in step715C, payment sub module366provides the information entered by seller230to physical check processor470for validation.

In the case of bank account registration and virtual private payment account registration, if the account exists, then the “YES” branch may be followed after which, preferably, individual instrument processor approves the account in steps725A and725B and payment sub module366adds the bank account under seller approved disbursement instruments in735A or adds the virtual private account as a disbursement instrument in735B. The routine may then return to the end of step505. If the account does not exist, the “NO” branch is preferably followed to step730A or730B. The registration of the bank account or the virtual private account as a disbursement instrument is preferably denied, and the routine may then proceed to the end of step505.

In situations involving a physical check, payment sub module366or physical check processor470may require another existing valid disbursement method, credit history check and/or pending payment period to reduce security risk, in additional to seller230entering basic identification information. In step720C, physical check processor470preferably determines whether the provided information can be used towards check disbursement. If yes, then the “YES” branch may be followed to step730C and payment sub module366may add physical check under seller's approved disbursement instruments. Otherwise, the “NO” branch is preferably followed to step725C wherein the registration of the physical check as a disbursement instrument is denied. The routine may then returns to the end of step505.

Authorization of Transactions

Reference is made toFIG. 8, wherein an embodiment of the authorization of transactions is illustrated. In the embodiment shown, buyer210uses communication device330to make a purchase with purchase/sale module361. Buyer210preferably also interacts with order verification module363to conduct initialization or synchronization required by one or more chosen authorization methods in step810. Order verification module363may delegate the initial set up and verification process of these methodologies to different system modules, as illustrated inFIG. 9.

If a payment (deposit or full payment) is required for the transaction, buyer210may be prompted to specify payment information, which is preferably forwarded to payment sub module366for approval before order is accepted and notice is sent to seller230. The required payment amount may be arbitrarily determined based on the seller's preference or buyer's selection. For example, the required amount may be a specified percentage as a deposit or full payment. Because payment sub module366may act as an escrow agent in this transaction, buyer210's payment information may not be disclosed to seller230and payment may not be released to seller230until buyer210authorizes the transaction during pick up or delivery.

In step815, purchase/sale module361may send an order notice to seller230after the transaction is finalized or seller230may check for new orders. This order notice may include order and buyer information. After receiving the order notice, in step820, seller230may request goods from an inventory provider865, who then may dispatch requested goods to a designated delivery agent860.

It is to be appreciated that step820and step825exemplify communications between seller230, inventory provider865and delivery agent860. Such communication may be conducted within or outside the e-commerce platform300or a combination thereof, without deviating from the scope of the invention.

Depending on the offering of seller230and the preference of buyer210, buyer210may have the option to pick up the goods or have the goods delivered to a specified address. Upon buyer's satisfaction after inspection in step830, buyer210may pay the remaining balance, if any. Buy210may pay delivery agent860or any party authorized by seller230.

Alternatively, buyer210may authorize the transaction by submitting an authorization signal to a verification agent870. Verification agent870may be any entity that accepts the authorization signal from buyer210for transaction authorization. In one embodiment, verification agent870may also be the same entity as delivery agent860that accepts a code as the authorization signal from buyer210and enters such code into special user interface343that links to order verification module363. In another embodiment, verification agent870may be any communication device, with which buyer210may authenticate himself and authorize the transaction. A non-exclusive list of potential communication devices as verification agents870includes phone, fax, smart-card read or biometric input device which takes biometric sample upon buyer's authorization.

Upon receiving the authorization signal from buyer210, verification agent870may send the signal to order verification module363for verification and to authorize delivery. Order verification module363may be a server as part of e-commerce system300, a separate entity that belongs to a different organization or a combination thereof. For security purposes, it may be preferred for order verification module363to block excessive authorization attempts. If the authorization signal is verified and the order is still valid, order verification module363may notify delivery agent860to transfer the goods/services to buyer210. Alternatively, delivery agent860may check the transaction authorization status with order verification module363. Upon successful authorization, order verification module363may notify payment sub module366that the delivery has been authorized and payment may be released. In step855, payment sub module366preferably makes payment available to seller230within a predetermined amount of time.

It is to be appreciated that even though seller230, inventory provider865and delivery agent860are illustrated herein as different entities, one entity may take on one or more roles across different transactions. In one embodiment, seller230may also be the inventory provider865and delivery agent860if seller230holds an inventory of goods for sale and handles all the delivery and pick up. In another embodiment, seller230may be inventory provider865for some of the merchandizes but also cooperate with other third party inventory providers and hire third-party delivery agents860. Accordingly, various arrangements are contemplated within the scope of the invention.

Authorization Methodologies

In accordance with an embodiment of the invention as shown inFIG. 9, order verification module363is connected to three different specialized modules: an authorization signal processing module910, an authorization algorithm processing module920and a user identification processing module930. It is to be appreciated that these processing modules may be internal entities, external entities that are maintained by a separate organization or a combination thereof. Order verification module363may delegate the initial setup and synchronization procedures to each of these processing modules before any transaction authorization takes place. Order verification module363may also delegate the verification procedures to one of these three specialized processing modules when transaction authorization is requested. It is to be appreciated that these processing modules may be used independently or in combination thereof to authorize transactions.

1. Authorization Signal Processing Module910: An embodiment of this module utilizes an authorization signal that may be generated by either buyer or seller. Each transaction may be associated with its corresponding authorization signal that is kept by buyer210as a secret signal.

Authorization signal processing module910may include authorization signal manager911and authorization signal database916. Upon placing an order in step1005, buyer210and order verification module363preferably interacts to create an authorization signal. Order verification module363may delegate this process to authorization signal processing module910for associating the authorization signal to a specific transaction. Authorization signal processing module910preferably synchronizes the authorization signal and the synchronized authorization signal may be stored in authorization signal database916.

In steps1005and1025ofFIG. 10A, buyer210may place an order and inspect the goods during pick up or delivery. If buyer210decides the goods are not in an acceptable condition, buyer210may decide to cancel the order in step1045, by way of non-limiting example, within a predetermined time frame from pick up or delivery. If the order is cancelled, previous payment is preferably refunded according to the policy of e-commerce system300in step1050.

Alternatively, if buyer210accepts the goods/services, buyer210may offer the remaining payment, if applicable, and tender the authorization signal to verification agent870upon satisfactory acceptance of goods or services ordered in step1055A. Upon receipt of the signal, in step1075A, verification agent870preferably verifies and acquires transaction authorization through order verification module363.

Upon the request of delivery authorization from verification agent870, order verification module363may delegate the verification process to authorization signal processing module910, specifically to authorization manager911, which verifies the submitted signal by comparing the provided authorization signal with the previously synchronized authorization signal stored in authorization signal database916.

An embodiment of the present invention may require the submitted signal to be the same as the previously synchronized signal, different, or different and in accordance with a pre-determined mathematical formula. The submitted signal may also be any transformed representation of the previously synchronized signal or vice versa.

In accordance with an embodiment of the invention, if the submitted signal is determined not to be valid based on the pre-determined rule, verification module363returns a negative result from authorization signal processing module910and increases a counter for unsuccessful authorization by 1 or other unit as a matter of application specific design choice. For security, order verification module363may allow only a predetermined number of attempts for requesting authorization before authorization for the transaction becomes suspended. For example, the transaction may be suspended if the counter value for unsuccessful authorizations is greater than a predetermined number. The suspended order may be canceled after a predetermined period, and order verification module363may trigger payment sub module366to issue refund to buyer210afterwards.

The verification result is preferably sent back to order verification module363in step1075A. Preferably, if the provided authorization signal is the same as the previously synchronized signal or other acceptable predetermined value, order verification module363authorizes delivery agent860to deliver goods to buyer210in step1085. Otherwise, buyer210may re-submit the authorization signal to verification agent870.

Order verification module363may also notify payment sub module366to release payment available to seller230within a predetermined time period in step1095. The disbursement may be automatic or manual upon seller's request.

2. Authorization Algorithm Processing Module920: An embodiment of this module involves the use of a secret authorization algorithm and parameters that allows the system and the buyer to synchronize and independently generate an authorization signal for verification. Authorization algorithm processing module may include an algorithm manager921, an algorithm database926, a device attributes database927and a digital clock922.

After buyer210places an order and before the pickup or delivery of such order, buyer210may activate an authorization device. The activation procedure preferably includes the synchronization of authorization algorithm and parameters between an authorization device1710and authorization algorithm processing module921. The synchronization procedures may allow both authorization device1710and algorithm manager921to have the same algorithm and parameters, which may allow both to independently generate an authorization signal in real time. The synchronized algorithm and associated device parameters may be stored in algorithm dataset926and device attributes database927. In one embodiment, synchronization conducted anytime before authorization device1710is first used. Afterwards, the synchronization process may take place regularly which may enhance the overall security of the device. Authorization device1710may not necessarily require synchronization after every purchase.

In steps1005and1025, buyer210may place an order and inspects the goods during the pick up or delivery. If buyer210decides the goods are not in an acceptable condition, buyer210may decide to cancel the order in step1045. If order is cancelled, previous payment is preferably refunded according to the policy of e-commerce system300in step1050.

If buyer210accepts the goods, buyer210may tender the remaining payment required and use authorization device1710to generate and submit an authorization signal to verification agent870in step1065B. Verification agent870may submit the authorization signal to order verification module363for transaction authorization. Order verification module363may delegate verification to algorithm processing module920, more specifically to algorithm processing manager921.

Preferably, upon receiving the verification request, algorithm manager921retrieves the previously synchronized algorithm from algorithm database926and other associated parameters from device attributes database927to independently generate an authorization signal for comparison. In one aspect of the present invention, algorithm manager921and authorization device1710uses time and transaction information to generate the authorization signal and thus create an authorization signal specific to transaction and point in time. Authorization algorithm processing module920may compare the submitted signal with the generated authorization signal.

One embodiment of the invention may require the submitted signal to be the same as the previously synchronized signal. Alternatively, it may be required for the submitted signal and the previously synchronized signal to be in accordance with a pre-determined mathematical formula (e.g. submitted signal=previously synchronized signal+offset). In accordance with an exemplary embodiment, the submitted signal may be a transformed representation of the previously synchronized signal or vice versa. If the submitted signal is not valid based on the pre-determined rule, verification module363may return a negative result from authorization algorithm processing module920and increase a counter for unsuccessful authorization by 1 or other unit as a matter of application specific design choice. It may be beneficial for security purposes for order verification module363to allow only a predetermined number of attempts for requesting for authorization before authorization for the transaction is suspended. More specifically, the transaction may be suspended if the counter for unsuccessful authorization is greater than a predetermined value. The suspended order may be canceled after a predetermined period, and order verification module363may trigger payment sub module366to subsequently issue refund to buyer210.

The verification result is preferably sent back to order verification module363in step1075B. If the provided authorization signal matches the previously synchronized signal or other acceptable predetermined value, order verification module363may authorize delivery agent860to deliver goods to buyer210in step1085. Otherwise, buyer210may re-submit the authorization signal to verification agent870.

Order verification module363may also notify payment sub module366to release payment available to seller230within a predetermined time period in step1095. The disbursement may be automatic or manual upon seller's request.

3. User Identification Processing module930: An embodiment of this module involves the use of an authorization signal associated with the identity of the user. For security reasons, it may be preferable for the authorization signal to be difficult to replicate, so that it will be difficult to be used by an unauthorized entity. The authorization signal may embed certain identification information, such as password or biometric characteristics, such as fingerprints and face reorganization.

User identification processing module930may include an identification manager931and identification information database936. Preferably, identification manager931accepts user authorization signal securely and stores the authorization signal in identification information database936during the initialization process in step810. A special device, as shown inFIG. 25, may be used to collect this authorization signal from buyer210upon buyer's satisfactory acceptance of goods or services.

In steps1005and1025, buyer210may place an order and inspect the goods during the pick up or delivery. If buyer210decides the goods are not in an acceptable condition, buyer210may decide to cancel the order in step1045. If order is cancelled, previous payment is preferably refunded according to the policy of e-commerce system300in step1050.

Alternatively, if buyer210accepts the goods or services, buyer210may offer the remaining payment, if applicable, and tender the authorization signal to verification agent870upon satisfactory acceptance of goods or services ordered in step1055C. Verification agent870may be a telephone or other audio communication system or device allowing buyer210to establish a link with order verification module363via an audio interface, wherein buyer210may identify himself by entering certain credential information. Alternatively, buyer210may log into e-commerce platform300via a portable communication device, such as a smart phone with internet access, and interact with the platform to authorize the transaction. Although phones are discussed above as examples, any communication device capable of establishing a connection with order verification module363and allowing buyer210to submit order identifying information are contemplated within the scope of the invention. A non-exclusive list of such devices includes a pager, PDA, fax and portable computer.

In yet another embodiment, verification agent870may be a display panel with an identification information input component which accepts identification information from buyer210. A non-exclusive list of identification information input components includes a numeric key pad allowing buyer210to enter a numeric passcode, an alphanumeric key pad for entering an alphanumeric passcode, biometric readers for reading fingerprints, detecting voice or other biometric identifiers. An exemplary device is illustrated inFIG. 24When this device is presented to buyer210, buyer210may review the order detail through the display panel and authorize the transaction using any compatible input.

In yet another aspect of the present invention, verification agent870may be a smart-card reader or token reader. Upon buyer's satisfaction with the goods, buyer210may present the smart-card or token to the reader for authorization. Upon submission of smart-card or token information, verification agent870may communicate with order verification module363to authorize the transaction.

Upon receipt of the signal, in step1075C, verification agent870may submit the signal to order verification module363for transaction authorization. Order verification module363may forward the authorization signal to identification module930, more specifically identification manager931. Identification manager931preferably compares the provided authorization signal with the previously synchronized authorization signal stored in identification information database936.

Preferably, if the submitted signal is determined not to be valid based on the pre-determined rule, verification module363returns a negative result from user identification processing module and increases a counter for unsuccessful authorization by 1.

In the interest of providing security, order verification module363may allow only a predetermined number of attempts for requesting for authorization by verification agent870before authorization for the transaction is suspended. More specifically, the transaction may be suspended if the counter for unsuccessful authorization is greater than a predetermined value. The suspended order may be canceled after a predetermined period, and order verification module363may trigger payment sub module366to issue a subsequent refund to buyer210.

The verification result is preferably sent back to order verification module363in step1075B. If the provided authorization signal matches the previously synchronized signal or other acceptable predetermined value, order verification module363may authorize delivery agent860to deliver goods to buyer210in step1085. Otherwise, buyer210may re-submit the authorization signal to verification agent870.

Order verification module363may also notify payment sub module366to release payment available to seller230within a predetermined time period in step1095. The disbursement may happen automatically or manually upon seller's request.

Authorization of Transaction Using User Identification Method

Reference is made toFIG. 24, wherein a graphical interface of an embodiment of an authorization device2500is shown, the device allowing the user to view order details and to authorize the transaction via a fingerprint sensor2520. In the embodiment illustrated, authorization device2500includes a display panel2510capable of displaying information regarding the order and fingerprint sensor2520capable of reading the user's fingerprint when the finger is placed in contact with fingerprint sensor2500. Upon the buyer's inspection of the goods/services, authorization device2500may be presented to buyer210. If buyer210is satisfied with the goods/services, buyer210may review the order detail on display panel2510, pay the remaining balance (if any) to delivery agent860and authorize the transaction using fingerprint sensor2520.

Upon submission of the fingerprint to authorization device2500, buyer's identification information may be submitted to order verification module363. Order verification module363, in turn, may delegate the verification process to identification manager931of user identification processing module930. The identification information may be verified with a pre-registered fingerprint in identification information database936. If the verification is positive, delivery agent860is preferably authorized to deliver the goods to buyer210.

Generation of Authorization Signal Using Synchronized Authorization Signal Method

There are many possible ways for generating an authorization signal. Authorization signal processing module910may issue an authorization signal to buyer210, as illustrated inFIG. 11A. Alternatively, buyer210may randomly or arbitrarily create an authorization signal as illustrated inFIG. 11B.

In one aspect of the invention, authorization signal may be required to comply with a set of rules. For example, the authorization signal may be a collection of random or pseudo-random characters; the authorization signal may also be unique among all the authorization signals for a specific user. These rules may be enforced by authorization signal manager911of authorization signal processing module910.

Buyer210begins by making a purchase via interaction with purchase/sale module361. Preferably, purchase/sale module361notifies order verification module363about the purchase and order verification module363delegates the authorization signal synchronization process to authorization signal manager911of authorization signal processing module910. Authorization signal manager911may use an authorization signal generator1230A to generate an authorization signal and compare the newly generated authorization signal against all previous authorization signals in authorization signal database916to avoid duplications. In addition, order verification module363may also check previous transactions using a transaction history database1290directly as shown inFIG. 11Aor indirectly through authorization signal processing module. Order verification module363, either directly or indirectly via authorization signal processing module, may associate the newly generated signal with the new transaction and informs buyer210about this newly generated authorization signal in step1210A.

Alternatively, as seen inFIG. 12B, a signal may be generated by a user regardless of the user's active participation. In one embodiment, communication device330includes an authorization signal generator1220B and an authorization signal interface1230B. Authorization signal generator1220B may automatically generate an authorization signal without any interaction with buyer210. Authorization signal generator1220B may be, without limitation, software or hardware-based. It may be a stand-alone device or application, or embedded in another devices or application. For example, it may be an embedded JavaScript application in the purchase interface and executed by the browser. In another embodiment, the authorization signal may also be generated by buyer210's manual input of a desirable authorization signal through authorization signal input interface1230B. Preferably, as soon as an authorization signal is generated, communication device330submits the authorization signal to authorization signal coordinator1235B of authorization signal processing module910for approval in step1210B.

Authorization signal coordinator1235B may check whether the submitted authorization signal complies with the rules, if any, enforced by authorization signal manager911. In one embodiment, authorization signal coordinator1235B directly checks transaction history database1290and compares the newly generated signal against all previous authorization signals in authorization signal database916to avoid duplication. Alternatively, authorization signal coordinator may go through order verification module363to access transaction history database1290.

When the submitted authorization signal fulfills the requirements, if any, preferably authorization signal manager911associates the authorization signal with the transaction and confirms the authorization signal with the user in step1215B. Otherwise, authorization signal coordinator1235B rejects the authorization signal and requests the authorization signal to be regenerated.

Steps1210B and1215B preferably take place between buyer210and authorization signal processing module910to generate and synchronize an authorization signal. These steps may take place before, after, during or concurrently with order notification of step1205. Steps1210B and1215B may be reiterated until an authorization signal is successfully generated.

An authorization signal may also be generated in a hybrid manner. In one embodiment, order verification module363may allow a predetermined number of attempts from buyer to set the authorization signal. Upon successive failure, order verification module363may generate an authorization signal for the buyer.

It is to be appreciated that the authorization signal may be a picture, video, text or anything that may be presented by buyer210. Devices used by buyer210may be used as a substitution for the authorization signal in the aforementioned example.

Graphical User Interfaces for Using Synchronized Authorization Signal Method

FIG. 12Ashows an embodiment of an interface that includes a unique order ID1310A, a retrieve authorization signal button1320A, a request cancellation button1330A, and a confirm delivery button1340A. Buyer210may identify the order by order ID1310A and retrieve its authorization signal by pressing retrieve authorization signal button1320A. Buyer210may also request cancellation of the order by pressing request cancellation button1330A and confirm the delivery of the order by pressing confirm delivery button1340A.

Preferably, after buyer210presses retrieve authorization signal button1320A, buyer210is brought to another interface shown inFIG. 12B, which illustrates a system message showing an order ID1310B and an authorization signal1320B. Although an 8-digit code is shown as the authorization signal in the example shown, authorization signal1320B may be any signal, preferably a transferable signal that may be sent to the server for verification. The interface shown inFIG. 12Bmay also include a message reminding buyer210to do a complete inspection and warning the implication of offering the authorization signal to seller230.

FIG. 13Aillustrates yet another an exemplary graphical user interface for retrieving an authorization signal on portable device1410A in accordance with the first authorization methodology of generating an authorizing signal of the preferred embodiment of the present invention. As illustrated, buyer210may identify the order by its unique order ID1420A and retrieve its authorization signal by pressing retrieve authorization signal button1430A. After buyer210presses retrieve authorization signal button1430A, a dialog box1410B as illustrated inFIG. 14Bmay be presented to buyer210. Authorization may be presented in a simple dialog box, such as dialog box1410B or in other forms.

Dialog box1410B may display an authorization signal1420B. Although an 8-digit code is shown as the authorization signal in the example shown, authorization signal1420B may be any signal, preferably transferable to the server for verification. In addition, dialog box1410B may warn buyer210the implication of offering the authorization signal and remind buyer210to do a complete inspection.

Yet another exemplary graphical user interface is illustrated inFIG. 14A. Seller230may identify the order by its unique order ID1510A and enter its authorization signal by pressing enter authorization signal button1520A. After buyer210presses enter authorization signal button1520A inFIG. 14A, seller230is preferably brought to another interface illustrated inFIG. 14B, which shows order ID1510B and text box1520B for entering authorization signal.

It is to be appreciated that although the exemplary interfaces illustrated inFIGS. 14A and 14Bare geared toward seller230, detailed sensitive information may be trimmed down so that special user310, such as delivery agent860and the like, may use a similar interface to input authorization on behalf of seller230or track the status of the order. In addition, although an 8-digit code is shown as the authorization signal in the examples illustrated, the authorization signal can be any signal preferably transferable to the server for verification.

FIG. 15shows an exemplary interface for displaying order information and entering the authorization signal. As illustrated, seller230may identify the order by a unique order ID1620, enter the authorization signal in a text box1630and submit the authorization signal by pressing a verify button1640. It is to be appreciated that although the exemplary interface illustrated inFIG. 16is geared toward seller230, detailed sensitive information may be trimmed down so that special user310, such as delivery agent860and the like, may use a similar interface to input authorization on behalf of seller230or track the status of the order. In addition, although an 8-digit code is shown as the authorization signal in the example illustrated, the authorization signal can be any signal preferably transferable to the server for verification.

Generation of Authorization Signal Using an Authorization Device

In accordance with the embodiment of the invention illustrated inFIG. 16, authorization device1710generates an authorization signal in real time without communication with ecommerce platform300in accordance with the second authorization methodology of the present invention described above. Authorization device1710may include a user interface1790, an authentication module1730, a digital clock1750, a device memory1780, a secure interface1770and a central processor1720. Preferably, user interface1790further includes a transaction identifier1740, which allows buyer210to choose the desired transaction for authorization, and an authentication interface1742, which allows buyer210to authenticate himself.

The embodiment of authentication module1730as illustrated is an optional module that adds another layer of security to prevent unauthorized use of authorization device1710. Buyer210may present his credential to authorization device1710via authentication interface1742. The credentials may then be passed to authentication module1730for authentication. The credentials may be a password or biometrics such as fingerprint and voice. In accordance with an exemplary embodiment, buyer210is granted the authority to use authorization device1710if and only if authentication module1730validates the credentials presented.

Digital clock1750is preferably an internal timing device that allows other parts of the device to retrieve the current time or a value related to the current time.

Preferably, device memory1780is a central storage that contains information useful for authorization signal generation, diagnosis or other purposes. In one aspect of the present invention, device memory1780includes an algorithm1783, an algorithm timestamp1785, an activity history1784and other device attributes1786such as a device serial number.

Secure interface1770may be responsible for establishing a communication link335between central processor1710and algorithm manager921. Preferably, algorithm manager921manages algorithms associated with each authorization device1710and is capable of generating the correct authorization signal independently to validate authorization signals from buyers210. In accordance with an embodiment of the present invention, authorization device1710communicates with algorithm manager921and exchanges sensitive information such as algorithm, activity history and other information.

Preferably, upon successful authentication with the authentication module1730, central processor1720proceeds to collect the transaction number and processes buyer210's request to generate an authorization signal. Central processor1720preferably retrieves algorithm1783from device memory1780and other necessary parameters, which may or may not reside in device memory1780, to generate the official authorization for comparison. In one embodiment, central processor1720collects the transaction number from the user, the current time from digital clock1750, device attributes1786from device memory1780and other information that is known to algorithm manager921. Central processor1720may then generate an authorization signal based on these attributes and certain rule of transformation. It is to be appreciated that the parameters may be removed or added to alter the security level of the device.

Although authorization device1710has been illustrated with respect to a particular sample module organization and architecture, it is to be appreciated that various module organization and/or architecture suitable for carrying out the present disclosure may be employed and are intended to fall within the scope of the hereto-appended claims. It is to be appreciated that different components of the present implementation may be regrouped, and the order of the steps may be varied to achieve the same purpose without deviating from the scope of the invention. It is also to be appreciated that the authorization device can be implemented, by non-limiting example, with hardware, software or any combination of software and hardware.

In one embodiment of the present invention, algorithm manager921is connected to algorithm database926, device attributes database927as well as user database321. Algorithm manager921preferably keeps track of the ownership of each authorization device, device algorithm, as well as all the attributes for the authorization signal generation. Therefore, algorithm manager921is preferably capable of generating the authorization signals independently and validating the provided token against the official ones.

Furthermore, order verification module363may be connected to algorithm manager921. When order verification module363receives a token for validation, order verification module363may delegate this task to algorithm manager921. Upon validation, algorithm manager921may return the result to order verification module363.

Activation and Updating the Authorization Device

In accordance with the embodiment shown inFIG. 17, in step1815, authorization device1710connects to algorithm manager921via the secure interface over communication links335. Authorization device1710may be connected to algorithm manager921manually or automatically. Communication link335may be any medium that allows direct or indirect communication between authorization device1710and algorithm manager921.

In step1820, authorization device1710may submit device attributes and other algorithm parameters to the algorithm manger. Information transmitted may include device information such as device attributes1786, digital clock time, activity history and any other information. Some of this information may be useful to the authorization signal generation process while some may be used for future diagnosis and research. This step may be conducted the first time authorization device1710is connected to algorithm manager921and periodically thereafter.

In step1825, algorithm manager921preferably makes a determination whether to conduct an algorithm update based on the information receive, such as timestamps and activity history of the device memory, from authorization device1710. Algorithm manager921may automatically check authorization device1710when it is connected and conduct an update periodically at a predetermined time interval. If algorithm manager921decides to conduct an algorithm update, the routine may proceed to step1840. Otherwise, the routine may proceed to the step1870, which may end the entire procedure.

In accordance with the embodiment illustrated, in step1840, algorithm manager921selects an algorithm from a pool of algorithms and associates authorization device1710with the selected algorithm. Alternatively, algorithm manager921may also dynamically create a new algorithm for authorization device1710. In step1845, algorithm manager921may send the new algorithm to authorization device1710. In step1855, central processor1720may test the integrity of the algorithm received by authorization device1710from algorithm manager921. For example, check sum verifications, such as Message-Digest Algorithm, a widely used cryptographic hash function, may be conducted to determine if the entire algorithm is received without any error. Preferably, upon successful algorithm validation by central processor1720, the routine proceeds to step1860where central processor1720acknowledges successful algorithm delivery by sending a message to algorithm manager921. Upon validation failure in step1855, the routine may proceed to step1875where authorization device1710may request algorithm redelivery from algorithm manager921and the algorithm delivery procedure may start over. In step1865, authorization device1710updates authorization device1710with new algorithm1783and algorithm timestamp1785.

Generation of Authorization Signal

Authorization device1710may require a user to authenticate oneself before using authorization device1710. As illustrated in step1915, buyer210may verify his identity with his authorization device1710by providing his credential to authorization device1710, wherein the credential may include a password or a biometric sample, such as a fingerprint. Such authentication may be done through the graphical interface shown inFIG. 20A, wherein boxes2110A allow the user to enter his passcode, and an enter button2120A, for submission of such passcode. It is to be appreciated that although the passcode authentication is illustrated as an example, there are many other authentication methods that may be used without deviating from the scope of the invention.

The provided credential is preferably forwarded to authentication module1730for verification. If authentication fails, the routine may proceed back to step1915where buyer210may re-enter the credential. In accordance with an embodiment of the present invention, a limit on the number of attempts may be enforced to reduce false authentication due to numerous attempt. If authentication succeeds, the routine may proceed to step1945illustrated inFIG. 18.

In step1945, buyer210may specify a transaction to authorize. Buyer210may choose the desired transaction among other existing transactions or manually enter a transaction number. It is to be appreciated that this step may be optional if transaction information is not a parameter to the authorization algorithm.

An example of a user interface for user's identification of the desired transaction is shown inFIG. 20B. As illustrated, buyer210may choose the desired transaction from a list of pending transactions2110B. An item2120B within list of pending transactions2110B may be a link allowing buyer210to retrieve more information about the transaction and/or execute different actions on the transaction. Pressing button2120B may direct the user toFIG. 20Cwhere buyer210may further request the authorization signal corresponding to the transaction.

Another example of the authentication interface is shown inFIG. 21A, including a displaying area2220A with instruction directing user to either to enter a numeric passcode or fingerprint for authentication, a display showing the values that the user has entered2230A, a backspace button2240A allowing the user to delete the value entered previously, and an enter button2250A leading authorization device to proceed to the next step.

FIG. 21Bshows yet another example of the transaction identification interface having a display2210B, instructing buyer210to enter the transaction number, a display2220B showing the values that the user has entered and an enter button2230B that instructs the authorization device to proceed to the next step.

Preferably, once buyer210identifies the transaction to be authorized, central processor1720retrieves stored algorithm1783, device attributes1786and other information, if any, (such as time from digital clock1750) required for authorization signal generation. Based on the algorithm and parameters retrieved in step1955, central processor1720may generate an authorization signal.

FIG. 20Cis an exemplary graphical interface that includes an order summary area2110C and a generate authorization signal button2120C. By pressing generate authorization signal button2120C, buyer210may generate an authorization signal specific to this transaction, leading the user to a dialog box2110D as shown inFIG. 20D. Dialog box2110D may remind buyer210to conduct an inspection before tendering the authorization.2120D may also show a code that represents the authorization signal. Although an 8-digit code is shown as the authorization signal in the example illustrated, the authorization signal may be any signal, preferably transferable to the server for verification.

FIG. 21Cshows yet another interface that outputs an authorization signal. The interface may include a display2210C showing a code that represents the authorization signal. In addition, although an 8-digit code is shown as the authorization signal in the example illustrated, the authorization signal can be anything transferable to the server for verification.

Verification of an Authorization Signal by an Authorization Device1710

In accordance with the embodiment shown inFIG. 19, in step2010, verification agent870receives an authorization signal for a specific transaction from buyer210and submits the authorization signal to order verification module363. Preferably, order verification module363delegates the authorization procedure and the authorization signal to algorithm manager921, which retrieves the current algorithm from algorithm database926and collects other parameters from device attributes database927, digital clock922and other source. These parameters may include the transaction number, certain device attributes as well as a value related to the clock reading. In step2040, algorithm manager921may generate one or more correct authorization signals specific to the transaction pending buyer's authorization based on the information collected and compare them to the authorization signal provided by buyer210. If the authorization signal fails to verify positively, the route may proceed to step2075, wherein. In step2075, algorithm manager921may forward the negative authorization result to the order verification module363. In step2085, order verification module363preferably sends the negative authorization result to verification agent870, which in turn takes buyer210back to step2010.

Alternatively, if the authorization signal is valid, the routine may proceed to step2070, where algorithm manager921forwards the positive authorization result to order verification module363. In step2080, order verification module363preferably authorizes the transaction and notifies verification agent870for order authorization.

Graphical Interfaces for Sellers

FIG. 22Ashows an exemplary graphical user interface showing order information and a button that triggers the input of an authorization signal in accordance with the second authorization methodology of the preferred embodiment of the present invention. As illustrated, seller230may identify the order by a unique order ID2310A and enter its authorization signal by pressing an enter authorization signal button2320A.

FIG. 22Bis an exemplary graphical user interface with an input for authorization signal in accordance with the second authorization methodology of an embodiment of the present invention. Preferably, after the buyer presses the enter authorization signal button2320A inFIG. 22A, seller230is brought to the next interface, shown inFIG. 22B, which includes a display of order ID2310B and a text box2320B for entering authorization signal. The authorization signal may be submitted to order verification module363for verification after the user clicks on a confirm button2330B.

FIG. 23shows yet another embodiment of a graphic interface for seller230having a display of order ID2420to identify the order, a text box2430suitable for entering the authorization signal and a verify button2440suitable for submitting the authorization signal.

It is to be appreciated that although the exemplary interfaces illustrated inFIGS. 22A,22B, and23are shown to display information for seller230, detailed sensitive information may be trimmed down so that special user310, such as delivery agent860and the like, may use a similar interface to input authorization on behalf of seller230or track the status of the order. Although an 8-digit code is shown as the authorization signal in the example illustrated, the authorization signal can be anything transferable to the server for verification.

Cancellation System

Another embodiment of the present invention includes a dynamic cancellation system. Such dynamic cancellation policy may optimize customer satisfaction while reducing costly abusive or excessive cancellation. Cancellation may be triggered by both buyer210and seller.

Preferably, as illustrated inFIG. 25, the dynamic cancellation system includes a cancellation module364, which includes a cancellation processor2640, a rule/policy retriever2650, and a request processing module2660. Furthermore, cancellation module364may be networked to various resources including but not limited to transactions database2691, accounting database2692, user database2693, membership status database2694, and rules & policies database2695. Rules and policies are defined in a rules & policies database2695. These rules and policies may be static and defined arbitrarily. They may also change dynamically based on different parameters. In addition, they may be a hybrid or combination of both.

Buyer210and/or seller230may use communication devices330to establish communication links335to interact with e-commerce system300. Buyer interfaces340and seller interfaces350are preferably connected to different modules of the system300, allowing buyer210and seller230options to modify different aspects of existing orders. Through cancellation module364, buyer210and seller230may request a cancellation of an existing order. As buyer210or seller230initiates a cancellation request, the cancellation request is forwarded to request processing module2660.

In the first stage of the cancellation procedure, request processing module2660may determine if the order can be canceled based on rules that are static across different membership statuses. For example, request processing module2660may be programmed to allow cancellation of orders placed within 24 hours. Afterward, module2660may forward the cancellation request to the cancellation processor2640, which may use rule/policies retriever2650to look up rules and policies specific to the subject order, membership status and any parameter related to the cancellation in rules and policies2695database.

Based on the information queried by rule/policies retriever2650, cancellation processor2640may process the cancellation. At this stage, a cancellation request may still be rejected based on rules/policies retriever2650.

Cancellation processor2640may also determine the follow-up actions to be carried out upon cancellation. These follow-up actions may also depend on rules and policies defined in the database. For example, cancellation processor2640may determine if a relisting should take place after an order cancellation. This decision may be based on the membership status of the seller, the reason for cancellation and also other user/transaction attributes.

Another example of follow-up actions may be reward cancellation. Given that a reward may be issued when a transaction takes place, the reverse of reward may follow an order cancellation. Cancellation processor2640may send a reward cancellation request2620to reward module370. Both cancellation process2640and reward module370may determine how the reward should be reversed.

Yet another example of the follow-up actions may be a refund request2630. Cancellation processor2640may determine how the refund should be executed based on rules and policies. For example, buyer210may qualify for full refund in the original form of payment instrument if buyer210is in certain membership statuses; otherwise, buyer210may receive refund in the form of credits.

After the execution of the cancellation, cancellation processor2640may update networked databases to reflect the cancellation and associated changes. Finally, cancellation processor2640may notify membership status evaluation module390of the change of parameters attributable to the membership status evaluation. Thus, membership status evaluation module390may then re-evaluate the membership status for buyer210and seller230involved in the transaction.

It is to be appreciated that the roles of the cancellation processor and the external module are inter-changeable. For example, the amount of fund, the instruments of the refund and how the refund should be executed may be determined either in cancellation processor2640or payment sub module366or both.

Membership Statuses and Corresponding Prerequisites

As illustrated inFIG. 26, in accordance with an embodiment of the invention, six membership statuses are included, which are default membership status2760and membership status A-E. Each membership status, other than a default membership status2760, may be associated with a corresponding prerequisite, preferably a set of non-conflicting conditions.

The universe of membership prerequisite condition2700is preferably a collection of possible mutually exclusive conditions, more preferably all possible mutually exclusive conditions. A condition may be anything that a member may achieve. A list of exemplary conditions includes but is not limited to: membership registration, 5 lifetime purchases, 3 sales within the last 10 days, cancellation rate of 20% or less, and composition of 3 product reviews with a helpfulness rate of 90% or above.

Inside this universe, there are preferably 5 prerequisites, namely prerequisites A-E, each being associated to one membership status. More specifically, in accordance with an embodiment, prerequisite A is associated with membership status A, prerequisite B is associated with membership status B, prerequisite C is associated with membership status C, prerequisite D is associated with membership status D, and prerequisite E is associated with membership status E. If one member fulfills a specific prerequisite exclusively, said member may be assigned to the membership status associated with the prerequisite. For example, if a member fulfills the prerequisite A exclusively, it will be assigned the membership status A. If a member does not fulfill any of the membership prerequisite A through E, it may be assigned the default membership status2760. It is to be appreciated that there is no limit to the number of prerequisites, membership statuses and conditions in implementation,

For simple illustration of the relationship between prerequisites and conditions, the following exemplary conditions and prerequisites are defined. This embodiment of universe of conditions includes 9 mutually exclusive conditions defined numerically as 1, 2, 3, 4, 5, 6, 7, 8 and 9, and five prerequisites A, B, C, D and E, as discussed above. The elements are showed as followed:

If the prerequisite is a set of non-conflicting conditions, it is possible that a member fulfils multiple prerequisites if the union of the conditions of the said prerequisites are non-conflicting. For example, if a member fulfills non-conflicting conditions [1, 2, 3, 4, 5, 6, 7], then this member may fulfill prerequisite A, B and E at the same time. Should this situation occur, it may be preferred to have a rule to correctly determine the membership status of the said member. In accordance with an embodiment of the present invention, a priority system is introduced to ensure deterministic assignment of unique membership status to a member. More specifically, each membership status may contain a priority attribute to resolve the possible overlap of multiple prerequisites at the same time. For example, membership status A has a priority higher than those of membership statuses B and E while membership status B may have a priority higher than that of membership status E. If a member fulfills the conditions [1, 2, 3, 4, 5, 6, 7], this member may be assigned the membership status A because membership status A has a priority higher than those of membership statuses B and E. If a prerequisite B is a subset of prerequisite C, prerequisite C may be more restrictive than prerequisite B. Should the described situation occurs, the member may not be assigned the membership status C unless the membership status C has a priority higher than that of the membership status B.

In an embodiment of the present invention, each membership with non-conflicting prerequisite may have a unique priority to ensure predictable membership status assignment. As a prerequisite is merely a set of conditions, a member's membership status may shift from one to another as the set of conditions the member fulfills changes. For example, member will change from membership status B to membership status C if the member fulfills the new condition A.

FIG. 27illustrates a dynamic policy switching mechanism in accordance with an embodiment of the present invention. For the purpose of simple illustration, a linear and reversible membership status structure is illustrated. Throughout the description, the cancellation policies may be used as an example to emphasize the benefit of a dynamic policy system. However, it is to be appreciated that the dynamic policy is not restricted to just the cancellation policy but to any policy that potentially affects the system user.

According toFIG. 27, there may be infinite number of membership statuses, including a membership status A2802, a membership status B2812, a membership status C2822and so on. There is a prerequisite associated with each membership status. Upon fulfilling a specific set of prerequisite, the member is assigned the corresponding membership status of said prerequisite. E-commerce system300preferably treats the member according to the membership policies. For example, for membership status A2802, the prerequisite may include requirements A1, A2, A3. . . AN. If a member fulfills all the requirements and reaches the membership status A, e-commerce system300treats the member according to a policy A2804. The policy may be a combination of predetermined and dynamic terms and benefits.

In accordance with an embodiment of the invention, the highest membership status (membership status A) has the strictest prerequisite but holds the most privileged policy. Using the cancellation policy as an example, membership status A may have a prerequisite of lifetime and recurring fulfillment rate of 95% or less and may hold a policy that allows unconditional cancellation/return with full refund guarantee.

Membership status C may be a default status, which members begin from this level of membership once they sign up for services. In reality, there may be multiple default statuses in order to separate members into different from the very beginning. The default membership status C may have a stricter prerequisite and holds a less privileged policy. Using the cancellation policies as an example again, it may have a prerequisite of lifetime fulfillment rate of 70% or more and may hold a policy that allows cancellation within 24 hours with full refund.

In order to encourage constructive participation and discourage destructive members, a membership status X may be created for abusive or non-cooperative members. The membership status X may have the least strict prerequisite and hold the strictest policy. For example, using the cancellation policies as an example, a member with a lifetime fulfillment rate of 30% or less may qualify for membership status X. With the strictest policy enforced in this membership status category, policies for the members may include cancellation of orders only within 24 hours from placing the order and payment refunds only as credit for future purchase. This cancellation system may resemble a negative feedback control system, in which seller's cancellation and order fulfillment resemble a negative and a positive signal respectively. Each membership status may represent a state in which a seller can reside. As buyer210cancels an order (negative signal), his or her membership status is driven to a state with stricter policy and less privilege. With a stricter policy and less privilege, buyer210's likelihood to abuse the e-commerce platform or the seller attenuates, and thus may lead to a lower order cancellation rate. Should this occurs, buyer210may be inclined to complete more orders with fewer cancellations and drive the membership status up. Thus, cancellation module364preferably attenuates/discourages buyer210's abusive cancellation.

In yet another example, buyer210starts with the membership status C. Due to the order cancellations, buyer210's may not qualify for the minimum requirement for membership status C anymore. In transition2828, membership status evaluation module390may re-assign buyer210to an inferior membership status2832. As buyer210completes more orders (positive signal), buyer210's membership status may be driven to a state with less strict policy and more privileges. For example, while buyer210may start with membership status C, after buyer210completes more orders, membership status evaluation module390may detect change of parameters that govern the membership status and new membership status may be assigned to buyer210.

Relisting after Cancellation

A relisting mechanism may be incorporated into cancellation module363and purchase/sale module361. Upon cancellation, a listing may be relisted automatically or manually under predetermined rules. These rules may reside in rule/policy database1695and/or defined elsewhere.

As illustrated inFIG. 28, in step2905, an order cancellation is accepted by the cancellation module364. The routine proceeds to step2910, where cancellation module364determines where seller230meets the requirements for auto-relisting. This requirement may be based on seller's membership status, reason of cancellation or any other factors that cancellation module364may retrieve. If seller230qualifies for auto-relisting, the branch “YES” may be followed to step2920and the branch “NO” may be followed to step2915otherwise.

In step2920, cancellation module364may further determine if seller230opts for the auto-relisting feature. If seller230does not opt for auto-relisting, the branch “NO” may be followed to step2915, or alternatively, the branch “YES” may be followed to step2925. In step2915, purchase/sale module361may offer different relisting options, such as discounts.

In step2925, purchase/sale module361preferably checks if the original listing has a remaining quantity for sale at the moment of the order cancellation. If the listing still has a remaining quantity for sell, the “YES” branch may be followed to step2930where the inventory may be updated with the new quantity. If step2925does not have any remaining inventory from original listing, the branch “NO” may be followed to step2935where the cancellation module sends a relisting request to purchase/sale module361.

Buyer Triggered Cancellation

An order includes a mutual agreement between buyer210and seller230to exchange goods or service for financial return, regardless of whether it was actually fulfilled or canceled. A canceled order may be an order that is terminated either by buyer210or seller230.

The fulfillment count and the non-fulfillment count may be the number of orders completed and the number of the order canceled by a user, respectively. The total order count may be the number of orders associated with the user. However, an order can be ignored and taken out of the calculation of fulfillment count, non-fulfillment count, total order count, etc. It is to be appreciated that an order can be taken out of the calculation towards one user's fulfillment rate while remaining in another user's fulfillment rate. For example, a canceled order may be ignored in calculating the seller's fulfillment count and total order count while taken into account of the buyer's fulfillment count and total order count.

The fulfillment rate may be the ratio of fulfillment count to total order count. The non-fulfillment rate or cancellation rate may be the ratio of non-fulfillment count to number of orders placed.

It is to be appreciated that the definition of fulfillment and nonfulfillment can be defined arbitrarily with a specific set of rules. In one aspect of an embodiment of the present invention, the nonfulfillment count attributes only to the party that causes the cancellation. For example, if buyer210canceled the order because he had changed his mind, this canceled order will be counted toward the buyer's nonfulfillment count but not the seller's. Should this situation occurs, the fulfillment rate and non-fulfillment rate will not be add up to 1 but a number smaller than 1. The missing portion attributes to the number of orders that is taken out of the equation.

FIG. 29Aillustrates an embodiment of a methodology of a flexible cancellation policy based on the buyer's historical fulfillment rate in accordance with an embodiment of the present invention. In the embodiment shown, the routine begins at step3005A where buyer210requests a cancellation, after which in step3010A, the cancellation request is first tested by request processing module2660to determine if request may be granted based on some predetermined requirements. If the request is not rejected by request processing module2660, it may be tested again by cancellation processor2640based on rules and policies defined in rules & policies database2695.

If cancellation request is rejected by any of these two modules, the “NO” branch is followed to step3015A where request processing module2660rejects the cancellation request by buyer210. If the cancellation request is granted, the “YES” branch is followed to step3020A where cancellation processor2640processes the cancellation.

During request for cancellation, buyer may specify the reason of cancellation. Buyer210may be presented with a survey inquiring the reason of cancellation. Based on the answer provided, cancellation processor2640may analyze buyer's cancellation reasons to determine if buyer210should assumes the responsibility of canceling the order. Specifically, if the reason for cancellation is because he changed his mind, cancellation processor2640may conclude that buyer210is responsible for the cancellation. Alternatively, if seller230states that the goods are out of stock, buyer210does not assume any responsibility.

If buyer210assumes the responsibility, the “YES” branch may be followed to step3030A where cancellation processor2640may increase the buyer's non-fulfillment count and total order count by 1. Upon the change of the non-fulfillment count, membership status evaluation module390may re-evaluate buyer210's membership status based on the new fulfillment rate. Membership status evaluation module390may assign a new membership status to buyer210if a membership status change occurs.

Referring again to step3025A, if buyer210does not assume the responsibility, the “NO” branch is followed to step3035A where cancellation module364may survey seller230about the cancellation reasons. Upon receiving the cancellation reasons from seller230, the routine may proceed from step3035A to step3040A where cancellation processor2640may determine if seller230assumes responsibility for the cancellation. If seller230assumes the responsibility, the “YES” branch may be followed to step3055A where cancellation processor2640increments seller's non-fulfillment count and total order count by 1.

Referring again to step3040A, if seller230does not assume the responsibility, the “NO” branch may be followed to step3045A where cancellation processor2640increments both parties' nonfulfillment count and total order count by 1. In step3050A, membership status evaluation module390may re-evaluate the membership statuses of both parties based on the new fulfillment rates. In step3060A, membership status evaluation module390may re-assign membership statuses if any change occurs.

Seller Triggered Cancellation

Preferably, the routine begins at step3005B where seller230specifies the reason of cancellation and requests a cancellation. Seller230may be presented a survey inquiring the reason of cancellation. Based on the answer provided, cancellation processor2640determines the party to which the cancellation is attributed.

Preferably, in step3010B, cancellation request is first tested by request processing module2660to determine if the request should be granted based on some predetermined requirements. If the request is not rejected by request processing module2660, it may be tested again by cancellation processor2640based on rules and policies defined in rules & policies database2695. If the cancellation request is rejected by any of these two modules, the “NO” branch may be followed to step3015B where request processing module2660rejects the cancellation request by seller230.

Referring again to step3010B, if the cancellation request can be granted, the “YES” branch may be followed to step3020B where request processing module2660analyzes seller's cancellation reasons to determine if seller230assumes the responsibility for order cancellation. More specifically, if the reason for cancellation is because the seller runs out of stock, request processing module2660may attribute the responsibility to seller230. Alternatively, if seller230claims that buyer210does not want to proceed with the completion of the order, seller230may not assume any responsibility. If seller230assumes the responsibility, the “YES” branch may be followed to step3025B where request processing module2660increments the seller's non-fulfillment count and total order count by 1. If seller230does not assume the responsibility, the “NO” branch may be followed to step3035B where cancellation processor2640processes the cancellation. Cancellation processor2640may also determine and delegate any of the following post-cancellation procedures (e.g. re-listing, reward reverse, payment refund and the like) according to seller's membership status at the moment the order was made.

In step3040B, cancellation module364may survey buyer210about the cancellation reasons. Upon receiving the cancellation reasons from buyer210, the routine may proceed to step3045B where cancellation processor2640determines if buyer210assumes that the responsibility of cancellation. If buyer210assumes the responsibility, the “YES” branch may be followed to step3050B where cancellation processor2640increments buyer's non-fulfillment count and total order count by 1.

Referring again to step3045B, if buyer210does not assume the responsibility, the “NO” branch may be followed to step3055B where cancellation processor2640increments both parties' nonfulfillment count and total order count by 1. In step3060B, membership status evaluation module390may re-evaluate the membership statuses of both parties based on the new fulfillment rate. In step3065B, membership status evaluation module390may re-assign membership statuses if any change occurs.

Whereas the fulfillment rate and the non-fulfillment rate may be assumed to be the ratio of the fulfillment count and non-fulfillment count to the total order count, respectively. It is to be appreciated that the fulfillment rate and the non-fulfillment rate could be any rate that is positively related to the number of order completed and canceled with respect to the number of all order placed.

Preferably, in this dynamic cancellation policy, both buyer210and seller230have nothing to gain by changing only his or her own strategy unilaterally because neither buyer210nor seller230benefits by not assuming his or her responsibility for cancellation without the counter-party's confirmation.

In general, after an order is completed in step3105ofFIG. 30, both the buyer's and the seller's fulfillment counts and total order count may be incremented by one. At step3115, membership status evaluation module390may re-evaluate the membership statuses of buyer210and seller230and new membership statuses may be assigned to both parties if they were changed upon evaluation. It is to be appreciated that although fulfillment count is described herein as the sole parameter to determine the membership status, membership status can be based on various types and number of parameters and re-evaluated anytime any parameter is changed.

It is also to be appreciated that the definition of order completion may vary. In one embodiment, an order may be considered completed upon successful establishment of an agreement between buyer210and seller230to trade an item. In another embodiment, the order may not be considered completed until a predetermined amount of time has passed after the delivery of goods.

FIG. 31Ais an exemplary graphical user interface showing order review information along with information about the current cancellation policy in accordance with the present invention. The exemplary interface shown includes a display area3210A showing order details, a display areas3220A showing the cancellation policy, a “more about cancellation policy” button for buyer210to obtain more information about the cancellation policy and a place order button3240A.

FIG. 31Bshows an example of a graphical user interface displaying current membership status and various metrics related to the membership status in accordance with one aspect of the present invention. The user interface may include display areas showing various parameters, including current membership status3215B, number of completed orders3220B, number of canceled orders3225B, fulfillment rate3230B and non-fulfillment rate3235B. It may also include a reference (i.e. AB34DL) to the policies and benefits associated with the subject membership status. In addition, it may describe how to achieve the next membership status (i.e. AB65EK)3240B and a link to the corresponding policies and benefits. The interface may also show a warning message about a potential membership status downgrade3245B.

FIG. 32illustrates an example of a graphical user interface displaying current membership status, including a display of current membership status3310, a display for other membership statuses3320, fulfillment requirement3330, benefits display3340, and remark display3350. Although a 6-character combination is used to identify the membership status in the example, it is to be appreciated that the membership status could be presented in any way that is identifiable to the member and the ecommerce platform. Preferably, requirement3330displays the requirements to achieve a specific membership status while benefit display3340and3350display the benefits and additional information associated with the membership status, respectively.

FIG. 33Ashows an example of a graphical user interface allowing one party to request cancellation of an existing transaction in accordance with an aspect of the present invention. The interface may include a unique order ID3410A and a request order cancellation button3420A. When request order cancellation button is pressed, the user is preferably brought to the next interfaceFIG. 33B.

An embodiment of a graphical user interface is shown inFIG. 33Bhaving a display area3420B for displaying order information, display area3420B including order ID3410B, a display area3430B showing a warning to the user about the potential consequence of cancellation and additional information, a display area3440B showing a list of reasons of cancellation for the user to choose from, a confirmation check box3450B to make sure that the user understands important information about the order cancellation, a cancel my order button3460B to confirm the cancellation and a back button3470B to cancel the cancellation request.

Yet another exemplary graphical user interface is shown inFIG. 34A. As illustrated, the user interface may have a display area3510A showing order details and a request cancellation button3520A. By pressing request cancellation button3520A, the user is preferably brought to another graphical interface shown inFIG. 34B.

The embodiment of the interface shown inFIG. 34Bincludes a display area3510B for showing order details, including order ID, a warning message display area3520B, a reason of cancellation3530B, a confirmation checkbox3540B and a proceed with cancellation button3550B. Display area3510B may show the order ID with brief order information to help the user identify the order to be canceled and reduce the risk of canceling the wrong order. Warning message display area3520B preferably shows a warning to the user about the potential consequence of cancellation and additional information. Reason for cancellation3530B may show a list of reasons of cancellation for the user to choose from. Confirmation checkbox3540B preferably ensures that the user understands the important information about the order cancellation. A button3550B preferably confirms the cancellation.

The examples provided are merely exemplary, as a matter of application specific to design choice, and should not be construed to limit the scope of the invention in any way.

Thus, while there have been shown and described and pointed out novel features of the present invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the disclosed invention may be made by those skilled in the art without departing from the spirit of the invention. For example, the user interfaces on the portable devices for order verification, payment and placing orders can be changed without deviating from the scope of the invention as a matter of application specific to design choice. Additionally, other alterations can be made, as a way of non-limiting example, network setup, database connections, buyer inspection process, etc. as a matter of application specific to design choice, without deviating from the scope of the invention. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.