JP2004005731A - Electronic commerce system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To eliminate a factor of the occurrence of a trouble in performing a desired transaction at ease, because the credit condition of a dealing partner is difficult to be determined, and because a dealt article is difficult to be determined whether it is one met to a transaction condition or not, in many cases, in addition to the fact that a customer is difficult to decide the dealing partner, since the transaction is carried out between a seller and a purchaser. <P>SOLUTION: A server determines the reliability of a customer writing the desired transaction based on a credit limit (S360), when receiving the condition of the desired transaction from a customer computer (YES in S350), and it is registered as far as an advantageous condition is not notified in the same subject (S380-S430) when reliable (YES in S360). The desired transaction is notified hereafter on an electronic bulletin board, not as the customer's one but as one exhibited by a bank of a server controller. <P>COPYRIGHT: (C)2004,JPO

Description

The present invention relates to an electronic commerce system that performs electronic commerce using a server connected to a customer computer via a network.

Conventionally, there are known auction-type and reverse auction-type systems in which a customer writes transaction needs using the Internet and mediates between a selling side and a buying side.

However, in such a system, since it is a transaction between the selling and buying parties, the customer cannot easily determine the counterparty, in addition to the credit status of the counterparty and whether the trading product is really according to the conditions. In many cases, it was difficult to make a decision, which was a cause of trouble.

The object of the present invention is to solve the above-mentioned problems, and an object of the present invention is to provide an electronic commerce system that can execute a desired transaction with confidence.

In order to solve the above problems, the present invention provides an e-commerce system for performing e-commerce using a server connected to a customer computer via a network, wherein the server receives a desired transaction from any of the customer computers, The credibility of the customer is determined, and if there is credibility, the desired transaction is posted on its own electronic bulletin board as its own, not as its own.

The present invention is used, for example, as follows. That is, a customer browses each desired transaction posted on the electronic bulletin board of this server and checks whether there is a desired transaction that meets his own needs. If no match is found, the customer writes the desired transaction from his computer to the server's bulletin board. When the server receives the condition of the desired transaction from the customer computer, the server determines the credibility of the customer who wrote the desired transaction, and if so, the server does not consider the desired transaction as belonging to the customer. Post it on your own electronic bulletin board as that of the administrator.

As described above, according to the present invention, the server administrator posts the desired transaction of the customer on his own electronic bulletin board as the desired transaction of the server administrator in a form to guarantee the trust of the customer. This has the effect that the customer who intends to make a contract can execute the transaction with confidence.

In the electronic commerce system of the present invention, when the server receives an offer for a contract for a desired transaction posted on its own electronic bulletin board from any of the customer computers, the server judges the reliability of the offered customer, If so, it is preferable to allow the transaction. In this case, since the transaction is permitted only when the customer making the offer to trade is reliable, the occurrence of troubles can be suppressed. At this time, the server administrator may conduct the transaction as a counterparty (intermediary) of the customer who has written the desired transaction and the customer who has offered to conclude the transaction. By doing so, both customers who want to make a transaction can always determine their trading partner as a server administrator, and can make a transaction with confidence. In that case, the server may execute transaction work with both customer computers.

In the electronic commerce system of the present invention, when checking the reliability of the customer, the server sets the total credit amount of the customer including the current transaction credit amount of the customer to a predetermined credit limit of the customer. It is preferable to judge whether or not it is settled, and if so, judge that there is reliability. Here, the credit limit refers to the maximum amount of credit for each customer determined by determining the credit status of the customer. When a customer writes a new desired transaction, it is posted on the electronic bulletin board as the desired transaction of the server administrator instead of the customer. Therefore, the server administrator also writes the desired transaction according to the customer's credibility. It is necessary to determine the appropriateness of doing this. As one method of the appropriateness judgment, it is checked whether or not the total credit amount of the customer exceeds the credit limit of the customer. Since the credit limit is determined based on a credit check, there is an advantage that a transaction can be made with confidence within the range of the credit limit.

At this time, the total credit amount is calculated based on the customer's current transaction credit amount, the customer's transaction credit amount posted on its own electronic bulletin board, and the customer's transaction amount that has been executed but the credit transaction period has not yet expired. It is preferable that the total is the sum of the credit amount of the balance.

In the electronic commerce system of the present invention, the server determines whether or not a request which has been received this time and which is different only in price and all other conditions are the same has already been posted on its own electronic bulletin board, and has already been posted. In that case, it is preferable to post preferentially those having an advantageous price for the trading partner. In this case, since the profit of the trading partner is prioritized, the transaction is activated.

In addition, if the price you received this time is different from the desired transaction only and the other conditions are all the same and already posted on your electronic bulletin board, if the price already posted is more advantageous, Conversely, if the one received this time is more advantageous, it is preferable to replace it with the one already posted and to notify the customer of the deletion from the electronic bulletin board. In this case, since the desired transaction already posted is not deleted without the customer's knowledge, the customer is not confused. If the price already posted is more favorable, it is preferable to send a message to the customer's computer that has written the desired transaction this time that the message cannot be written.

In the electronic commerce system of the present invention, it is preferable that the server can post the desired transaction of the server administrator himself / herself on his / her electronic bulletin board. In this case, the product lineup posted on the electronic bulletin board can be expanded.

In the electronic commerce system of the present invention, it is preferable that the server be managed by a bank. In this case, the desired transaction on the electronic bulletin board is posted as being presented by the bank, but generally, the bank has a high degree of credibility from customers, so that the transaction can be made with confidence. In particular, when a bank conducts transactions as a counterparty (intermediary) of a customer who has written a desired transaction and a customer who has ordered the desired transaction, the customer who wishes to transact can always determine his or her counterparty as a bank. You can do business with confidence.

In the e-commerce system of the present invention, the transaction may be for any product or service, but is preferably a credit derivative. Credit derivatives are financial derivatives that focus on the credit risk inherent in financial transactions such as loans and securities, and enable the transfer by extracting the credit risk component from the underlying asset. Since the electronic commerce system of the present invention is suitable for such credit derivative transactions, it is useful for expanding the market for credit derivatives.

Here, specific examples of credit derivatives will be described. For example, Company A has the receivables of Company B, but they become non-performing loans at the time of the event of Company B (in the event of a credit destruction such as bankruptcy or default). To avoid that danger, you may want to guarantee the principal at Company B's event, but instead pay a premium. In this case, Company A wants to pay a premium to purchase protection. Company A pays the premium, but the credit amount is calculated based on the total amount of the premium payment if the payment is made in a lump sum and zero if the payment is made in a lump sum.

On the other hand, if Company C does not believe that an event will occur at Company D, it will guarantee its principal to the debt holders of Company D at the event of Company D in order to increase the investment yield. Sometimes I want to get a premium. In this case, Company C wants to receive the premium and sell the protection. Since the company C pays the principal of the receivables of the company D at the time of the event, the credit amount is calculated according to the principal, the term, and the brand of the receivables.

Hereinafter, a preferred embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a schematic explanatory diagram of the device configuration of the present embodiment.
This embodiment includes a server 10 managed by a bank, a customer computer 20 managed by a customer of the bank, and the Internet 30 connecting the server 10 and each customer computer 20.

The server 10 is connected to the Internet 30 via a communication line 31. The server 10 outputs the contents of the electronic bulletin board from the transaction case database in the storage device 11 to the customer computer 20 via the Internet 30, reads out customer information from the customer management database in the storage device 11, and performs various operations. It performs processing, stores or updates customer information in the customer management database, and performs various processing based on information received from the customer computer 20.

The customer computer 20 is connected to the Internet 30 via a dial-up communication line 32 to an Internet provider. The customer who manages the customer computer 20 is given a password and a user ID for browsing the member-only homepage of the bank from the bank managing the server 10 in advance.

Next, the outline of the procedure for the customer to use the website of the bank who is the server administrator will be described. (1) First, after receiving the password and the user ID from the bank which is the server administrator, access the member's home page dedicated to the bank using the password and the user ID, and each of the information posted on the electronic bulletin board of the bank. Browse the price of the desired transaction and see if there is a desired transaction that meets your own needs. (2) Then, if there is a desired transaction that meets your own needs, offer a transaction on the website. On the other hand, if there is no desired transaction that meets one's own needs, the desired transaction is written on the electronic bulletin board. (3) However, if the total credit amount of the customer plus the credit amount of the transaction exceeds the credit limit of the customer at the time of applying for a transaction or writing the desired transaction, there is a problem in the reliability of the customer. Therefore, a contract offer or transaction writing is rejected. Further, the name of the customer is not displayed on the electronic bulletin board, but is posted on the electronic bulletin board as a server manager who has made a contract or has written a desired transaction.

Next, the details of the procedure for the customer to use the homepage of the bank who is the server administrator will be described based on the flowchart of the transaction control program in FIG. In the following, the server 10 is mainly described for convenience. Further, credit derivative transactions will be described.

The server 10 reads out the transaction control program at a predetermined timing and executes the program. First, the server 10 determines in step (hereinafter abbreviated as “S”) 100 whether or not the password and the user ID have been received from the customer computer 20, that is, whether or not the password and the user ID have been input in the customer computer 20. Judgment is made, and if not received (NO in S100), this program is ended.

On the other hand, if the password and the user ID are received (YES in S100), it is determined whether the password and the user ID are appropriate (S110). Here, since the password and the user ID are registered in advance in the customer management database of the server 10 for each customer, the appropriate password and the user ID received this time depend on whether the password and the user ID are registered in the customer management database. It is determined whether or not. If the password and the user ID are incorrect (NO in S110), an error message such as "The password and the user ID are invalid" is transmitted to the customer computer 20 (S120), and the program ends. Then, an error message is displayed on the display of the customer computer 20, so that the customer can recognize that an input error has occurred. Note that the message may be transmitted by voice data instead of character data.

On the other hand, if the password and the user ID are appropriate (YES in S110), the top page of the member-only homepage is transmitted to the customer computer 20 (S130). Then, the top page shown in FIG. 3 is displayed on the display of the customer computer 20. On the top page, a menu list is displayed, and menus such as "today's price indication" and "confirmation of bulletin board input contents" are displayed. Subsequently, the server 10 determines whether any menu has been requested from the customer computer 20, that is, whether any menu has been clicked from the menu list on the customer computer 20 (S140). If the menu is not requested (NO in S140), the process proceeds to S160 described later. On the other hand, if any menu is requested (YES in S140), a routine corresponding to the requested menu is executed (S150), and the process proceeds to S160 to determine whether an end signal has been transmitted, that is, the end. It is determined whether or not a button (not shown) has been clicked. If the end signal has not been transmitted (NO in S160), the process returns to S140. If the end signal has been transmitted (YES in S160), this program is executed. To end.

Next, a presentation routine executed when “Today's price indication” is clicked in the menu list on the top page will be described with reference to the flowchart in FIG. When this routine is started, the server 10 transmits the information of the electronic bulletin board to the customer computer 20 (S200). Then, an electronic bulletin board as shown in FIG. 5 is displayed on the display of the customer computer 20, for example. On this electronic bulletin board, "This is the price indication of our bank on the date of MM / MM / 2000" is written, and, for example, the brand name "A" and the product name "OO" are posted as the transaction to be sold. That is, these desired transactions are posted as being presented by the bank that is the server administrator.

Subsequently, whether or not the customer computer 20 has requested a transaction statement, that is, whether or not the “transaction statement” button has been clicked in the customer computer 20 with the selection box of each transaction on the electronic bulletin board in FIG. 5 checked. Is determined (S210), and if a negative determination is made (NO in S210), the process proceeds to S280. On the other hand, if an affirmative determination is made (YES in S210), the transaction for which a transaction specification has been requested is read from the transaction database, and the contents thereof are transmitted to customer computer 20 (S220). For example, if the "detailed transaction" button is clicked while the selection boxes of the brand name "A" and the product name "XXX" are checked, the display of the customer computer 20 shows a transaction as shown in FIG. Details are displayed.

Subsequently, it is determined whether or not the customer computer 20 has made an offer to make a transaction, that is, whether or not the “Deal for Transaction” button outside the transaction details column in FIG. 6 has been clicked on the customer computer 20 (S230). If there is no offer to make a transaction (NO in S230), it is determined whether there is a request to return to the previous screen (S235). If there is no request to return (NO in S235), S230 and subsequent steps are repeated again, and the return request is returned. If there is (YES in S235), the process returns to S200. On the other hand, if there is an offer to conclude a transaction (YES in S230), it is determined whether or not the total credit amount of the customer including the current transaction credit amount falls within a predetermined credit limit of the customer. A determination is made (S240).

Specifically, from the customer management database, the transaction credit amount that the customer is currently posting on the electronic bulletin board (the written transaction credit amount), the transaction balance of the customer that has been executed but the margin transaction period has not yet expired The credit amount of the customer (the credit amount of the existing transaction balance) and the credit limit of the customer are read out, and the amount including the current transaction credit amount in the former two, that is, the total credit amount of the customer is the credit limit of the customer To determine if they are within. If this is expressed by an equation, it is determined whether or not the following equation 1 is satisfied.

By the way, there are various methods of calculating the credit amount. Here, an example of the method will be described with reference to FIG. 7 using a default swap of a credit derivative as an example. In default swaps, a customer may purchase protection or sell protection. First, when purchasing protection, the customer pays the premium on a regular basis instead of having the principal of the receivables guaranteed by a third party, so the ability to pay the premium becomes an issue. Here, if the premium is a lump-sum payment, the payment is completed at the time of execution, so the credit amount is zero. On the other hand, if the premium is installment payment, it is necessary to continue to pay the premium even after execution, so the credit amount is calculated based on the total amount of the premium to be paid over the entire period of the transaction.

Next, when selling protection, the customer guarantees the principal of the receivable to be guaranteed, so at the time of an event (in the case of bankruptcy or default), the receivables are held in place of being delivered as default assets. Since the principal has to be paid, the solvency of the principal becomes a problem. In this case, the risk rating is determined based on the rank and the transaction period of the receivables issued by the external rating agency, and the credit amount is calculated in consideration of the principal amount and the risk ratio. Also, the better the rank and the shorter the trading year, the lower the risk rate.

(4) The credit limit is an amount determined for each customer based on the credit status of the customer, the transaction scale, and the like, and various methods of calculating the credit limit are conceivable. For example, it is conceivable to use the rank by an external rating agency as the customer's credit status.

In S240, if the total credit amount of the customer does not fall within the credit limit of the customer (NO in S240), an error message (eg, “Cannot write due to exceeding credit limit”) is sent to customer computer 20. ) Is transmitted (S250), and then the process proceeds to S280. Then, since an error message is displayed on the display of the customer computer 20, the customer can recognize why the writing could not be performed. On the other hand, if the total credit amount of the customer is within the credit limit of the customer (YES in S240), that is, if the above equation (1) is satisfied, the customer who has made the transaction and the customer The fact that the transaction has been established is transmitted to both customer computers 20 of the customer who has written the transaction (S260), and of the customer management database, each of the customer who has made the transaction and the customer who has written the transaction The data is updated (S270), and then the process proceeds to S280. In S280, it is determined whether or not the end signal has been transmitted from customer computer 20, that is, whether or not the end button (not shown) has been clicked. If the end signal has not been transmitted (NO in S280), the process returns to S200. Returning, if the end signal has been transmitted (YES in S280), the top page is transmitted to customer computer 20, and this routine ends.

Here, the data update in S270 will be described in more detail. First, for a customer who has made a deal, the credit amount of the existing balance is updated. That is, if the customer purchases protection, it is updated to the value obtained by adding the credit amount calculated based on the total amount of premium paid over the entire period of the transaction, and if the protection is sold, the original value is updated. The value is updated to the sum of the credit amount calculated in consideration of this amount and the risk rate. On the other hand, for the customer who has written the transaction, the credit amount of the existing transaction balance and the written transaction credit amount are updated. That is, of the written transaction credit amount, the transaction credit amount executed this time is transferred to the credit amount of the existing transaction balance.

Next, a confirmation routine executed when “confirmation of bulletin board input contents, etc.” is clicked in the menu list on the top page will be described with reference to the flowchart of FIG. Note that the customer clicks “Confirmation of bulletin board input contents, etc.” when confirming or changing the content currently posted on the electronic bulletin board. When this routine is started, the server 10 transmits the content currently posted on the electronic bulletin board to the customer computer 20 (S300). Then, on the display of the customer computer 20, for example, a list of "current contents posted by the customer" as shown in FIG. 9 is displayed. In this list, "The following are the customer's desired trades currently posted on the bulletin board." For example, the brand name "A" and the product name "○○○" are posted as the desired trades. And two other transactions are posted. Further, buttons “change”, “delete”, and “add” are displayed at the bottom of the screen.

The server 10 determines whether any one of "change", "delete", and "add" has been requested from the customer computer 20, that is, whether any of these buttons has been clicked on the customer computer 20. A determination is made (S310), and if neither is requested (NO in S310), the flow proceeds to S460. On the other hand, if either is requested, it is determined which is requested (S320).

If "add" is requested in S320, a screen for inputting new desired transaction conditions (condition input screen) is transmitted to the customer computer 20 (S330). Then, the condition input screen of FIG. 10 is displayed on the display of the customer computer 20. Subsequently, the server 10 determines whether a new desired transaction condition has been received from the customer computer 20, that is, whether the customer has input a numerical value or the like in a square frame on the condition input screen of FIG. It is determined (S350) whether or not the customer's total credit including the current transaction credit amount, if a negative determination is made (NO in S350), waits as it is, and if a positive determination is made (YES in S350). It is determined whether the amount falls within a predetermined credit limit of the customer (S360). Specifically, similarly to S240 of the above-described presentation routine, it is determined whether or not Expression 1 is satisfied. Also, the credit amount of the desired transaction entered this time is calculated based on the total amount of premium paid over the entire period of the transaction if the current transaction is the purchase of protection, as in the above-mentioned presentation routine. However, if this transaction is the sale of protection, the credit amount is calculated in consideration of the principal amount and the risk rate.

Then, in S360, if the total credit amount of the customer does not fall within the credit limit of the customer (NO in S360), an error message (for example, "Cannot write due to exceeding credit limit.") Is sent to customer computer 20. (S370), and then proceeds to S460. At S370, an error message is displayed on the display of the customer computer 20, so that the customer recognizes that the writing could not be performed. On the other hand, if the total credit amount of the customer is within the credit limit of the customer (YES in S360), the process proceeds to S380.

In S380, it is determined whether or not the desired transaction that differs only in the premium has already been presented on the electronic bulletin board. If such a transaction has not been presented (NO in S380), the current desired transaction is stored in the transaction case database. At the same time, the data of the customer in the customer management database is updated (S420), and the fact that the desired transaction has been registered is transmitted to the customer computer 20 (S430), and the process proceeds to S460. Thereafter, when "Today's Price Indication" is opened in any of the customer computers 20, the desired transaction is presented on the electronic bulletin board. In S420, the written credit amount of the customer is updated to a value obtained by adding the current transaction credit amount to the customer management database.

On the other hand, if the desired transaction that differs only in the premium has already been presented on the electronic bulletin board (YES in S380), it is determined whether or not the desired transaction is more advantageous for the trading partner (S390). Specifically, if the desired transaction is the purchase of protection, the higher premium is more advantageous to the counterparty (the party who sells the protection), and if the desired transaction is the sale of protection, the lower premium is the counterparty ( This is advantageous for those who purchase protection.

If the current desired transaction is unfavorable to the trading partner (NO in S390), an error message (for example, "the same desired transaction has already been posted under more favorable conditions" is sent to the customer computer 20 that transmitted the current desired transaction. And so on ") (S410), and then proceed to S460. Since the error message is displayed on the display of the customer computer 20 by S410, the customer can recognize why the writing could not be performed. On the other hand, if the desired transaction is more advantageous for the trading partner (YES in S390), an error message (for example, “Posting the same desired transaction under more favorable conditions”) is sent to customer computer 20 of the customer who has already written the desired transaction. Has been deleted, and so on ”(S400), and then the processing from S420 described above is performed.

Now, returning to S320, if "change" is requested, a screen (condition change screen) in which the conditions of the selected desired transaction (the transaction for which the selection button in FIG. 9 is checked) is entered is displayed on the customer computer. 20 (S340). At this time, a screen similar to that of FIG. 10, that is, a screen in which the square frame items of FIG. 10 are embedded is displayed on the display of the customer computer 20. In subsequent S350, server 10 determines whether or not the changed desired transaction condition has been received from customer computer 20, that is, whether or not the registration button has been clicked after overwriting the square frame of the item to be changed. After that, the processing after S360 described above is executed.

If "delete" is requested in S320, the selected desired transaction is deleted from the transaction case database, and the deleted transaction credit amount is subtracted from the written credit amount of the customer in the customer management database. The value is updated to a value (S440). Then, the fact that the deletion of the selected desired transaction is completed is transmitted to the customer computer 20 (S450), and the process proceeds to S460.

Finally, in S460, it is determined whether or not the end signal has been transmitted from the customer computer 20, that is, whether or not the end button (not shown) has been clicked. If the end signal has not been transmitted (NO in S460), it is determined again. Returning to S300, if a termination signal is transmitted (YES in S460), the top page is transmitted to customer computer 20, and this routine ends.

Next, a specific example of the present embodiment will be described. When a certain customer properly inputs the password and the user ID from his / her own customer computer 20, the server 10 transmits the top page of the member-specific homepage to the customer computer 20 (S100 to S130). Then, the top page of FIG. 3 is displayed on the display of the customer computer 20. Here, when the customer clicks "Today's price indication" from the menu list, the server 10 executes the presentation routine of FIG. 4 and transmits the electronic bulletin board information to the customer computer 20 (S200). Then, the electronic bulletin board shown in FIG. 5 is displayed on the display of the customer computer 20, so that the customer browses each desired transaction posted on the electronic bulletin board and determines whether or not there is a desired transaction that meets his own needs. Find out.

At this time, if there is a specific transaction need but there is no match on the electronic bulletin board of the server 10, the customer performs an operation to end the display of the electronic bulletin board. Then, the server 10 transmits the top page to the customer computer 20 and ends the presentation routine. Then, when "confirmation of bulletin board input contents etc." is clicked from the menu list, server 10 executes the confirmation routine of FIG. 8 and transmits the contents of the notice of the customer (S300). Then, the screen of FIG. 9 is displayed on the display of the customer computer 20. Next, the customer clicks “Add” on this screen, inputs the conditions of the desired transaction on the condition input screen of FIG. 10 displayed by this, and clicks “Register”. It is determined whether or not the total credit amount of the customer including the credit amount of the customer falls within the credit limit of the customer (S360), and if not, an error message is transmitted (S370). Unless a favorable condition is posted in the case, the registration is made (S380 to S430), and thereafter, the transaction is posted on the electronic bulletin board as a desired transaction presented by the bank. That is, upon receiving the desired transaction from the customer computer 20, the server 10 determines the reliability of the customer who wrote the desired transaction based on the credit limit. Post it on your own electronic bulletin board, not as a server, but as a server administrator's bank.

On the other hand, if there is an electronic bulletin board that meets the specific transaction needs of the customer, a transaction statement is requested for the desired transaction, and after examining the transaction statement as shown in FIG. "Button. Then, the server 10 determines whether or not the total credit amount of the customer including the credit amount of the desired transaction is within the credit limit of the customer (S240), and if not, transmits an error message. (S250), and if it fits in, the bank acting as the server administrator mediates and conducts the transaction. That is, when the server 10 receives the offer for a transaction from the customer computer, the server 10 judges the reliability of the offered customer based on the credit limit, and if the customer is reliable, transfers the transaction to the bank as the server administrator. Intervenes.

According to the embodiment described above, the following effects can be obtained.
1) In order for the bank, which is the server administrator, to post the desired transaction of the customer on the electronic bulletin board as the desired transaction of the server administrator in a form that guarantees the trust of the customer, an offer to close the desired transaction is made. The effect is that the customer who tries to execute the transaction with confidence can be obtained.
2) Since the transaction is permitted only when the customer making the offer to trade is reliable, the occurrence of troubles can be suppressed.
3) Since the bank that is the server administrator conducts transactions as a counterparty (intermediary) of the customer who has written the desired transaction and the customer who has made a contract, the customer who wishes to transact always has his or her counterparty as a bank. You can settle and trade with confidence.
4) Although the credibility of the customer is determined based on the credit limit, since the credit limit is determined based on the credit check, it is safe to do business within the range of the credit limit. There are advantages.
5) If only the desired transaction and the premium that are entered this time are different and all other conditions are the same, the message is displayed on your own electronic bulletin board. The interest of the other party is prioritized, and the transaction is activated. At this time, if the desired transaction that has already been written is to be deleted, the customer to be deleted is notified of the fact, so that the customer is not confused.

It should be noted that the embodiments of the present invention are not limited to the above-described embodiments at all, and it goes without saying that various embodiments can be adopted as long as they belong to the technical scope of the present invention.
For example, in the above-described embodiment, the server 10 may be able to post a desired transaction of the bank, which is the server administrator, on its own electronic bulletin board. In this case, the product lineup posted on the electronic bulletin board can be expanded.

In the above embodiment, the case where credit derivatives are traded has been described. However, the present invention is not particularly limited to this, and the present invention can be applied to any product or service that can be a target of normal transactions.

Further, in the above embodiment, the case where the bank is the server administrator has been described. However, the present invention is not particularly limited to this, and the present invention can be applied regardless of a corporation or an individual. However, considering that the transaction is performed with confidence, it is preferable that a company with high social trust, such as a listed company, is the server administrator.

Further, in the presentation routine of FIG. 4, after S220, S230 to S270 may be omitted and the process may proceed to S280 immediately. In this case, a customer who wishes to make a transaction contract makes the request by telephone or facsimile, and when such a request is made, the server administrator may execute a program including S230 to S270. .

(5) In the electronic bulletin board shown in FIG. 5, when a customer clicks on a brand name, a homepage of the company having the brand name may be opened. In this case, since detailed information of the company is obtained, it can be used as a criterion for determining whether to offer a transaction. At the same time, in the flowchart of FIG. 8, when updating each database, a link may be automatically established to the company of the brand name.

FIG. 1 is a schematic explanatory diagram of a device configuration of the present embodiment. It is a flowchart of a transaction control program. It is explanatory drawing showing the screen of the top page of a member-only homepage. It is a flowchart of a presentation routine. It is explanatory drawing showing the display screen of "today's price indication" (electronic bulletin board). It is explanatory drawing showing a transaction statement screen. It is explanatory drawing of a credit derivative (default swap). It is a flowchart of a confirmation routine. It is explanatory drawing showing the display screen of "the contents currently posted by the customer". It is an explanatory view showing a condition input screen.

Explanation of reference numerals

10 ... server,
20 ... customer computer,
30 ・ ・ ・ Internet,
31 ... communication line,
32 ・ ・ ・ Dial-up communication line

Claims (9)

In an electronic commerce system that performs electronic commerce using a server connected to a customer computer via a network,
The server, upon receiving a condition of the desired transaction from any of the customer computers, determines the credibility of the customer, and if so, identifies the desired transaction as its own rather than as its own. An electronic commerce system characterized by posting on its own electronic bulletin board. The electronic commerce system according to claim 1,
The server, upon receiving an offer to conclude a transaction from any of the customer computers for the desired transaction posted on its electronic bulletin board, judges the credibility of the offered customer, An e-commerce system that allows transactions. An electronic commerce system according to claim 1 or 2,
When checking the credibility of the customer, the server determines whether or not the total credit amount of the customer, including the current transaction credit amount of the customer, is within a predetermined credit limit of the customer. An electronic commerce system that determines that it is reliable if it fits. The electronic commerce system according to claim 3, wherein
The total credit amount is calculated based on the customer's current transaction credit amount, the customer's transaction credit amount displayed on its own electronic bulletin board, and the customer's transaction balance that has been executed but the credit transaction period has not yet expired. An electronic commerce system that is the sum of the credit amount. An electronic commerce system according to any one of claims 1 to 4,
The server judges whether or not a price which is different from only the desired transaction received this time and has the same other conditions as that of the transaction is already posted on its own electronic bulletin board, and if it is already posted, it is advantageous to the trading partner. An e-commerce system that gives priority to postings with the highest prices. The electronic commerce system according to claim 5, wherein
The server determines whether or not a price which is different from only the desired transaction received this time and which has the same other conditions is already posted on its own electronic bulletin board. Judgment of the price that is advantageous for the customer, if the one already posted is more advantageous, the one received this time will not be posted. Conversely, if the one received this time is more advantageous, it will already be posted. An electronic commerce system that notifies the customer of the deletion from the electronic bulletin board while replacing it with the one that has already been used. An electronic commerce system according to any one of claims 1 to 6,
An electronic commerce system, wherein the server can post a desired transaction of a server administrator on an electronic bulletin board of the server administrator. An electronic commerce system according to any one of claims 1 to 7,
The server is an electronic commerce system managed by a bank. An electronic commerce system according to any one of claims 1 to 8,
An e-commerce system, wherein the transaction is a credit derivative.

Images