JP2001306856A - Merchandise transaction intermediary system and method using network - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enhance the security, certainty and rationality of a transaction and to efficiently and surely perform a processing when the transaction is rejected by providing a function for supporting a transaction procedure between a seller and a buyer after negotiations are established in a merchandise transaction intermediary system for widely providing a merchandise transaction intermediary service to users via a network. SOLUTION: In this merchandise transaction intermediary system using the network, the transmission of an E-mail for indicating a next operation to be performed and the display of a Web page for urging the input of information to be transmitted to a transaction opposite party are repeatedly performed to the seller and the buyer in accordance with a predetermined procedure at each transaction method in the case of the transaction after the negotiations are established. Then the transaction procedure to be performed between the seller and the buyer is navigated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a merchandise sales mediation system for mediating merchandise sales online using a network such as the Internet, and more particularly, to a transaction procedure performed between a buyer and a seller after a negotiation is completed. The present invention relates to a merchandise trading brokerage system using a network that can support.

[0002]

2. Description of the Related Art With the rapid spread of the Internet in recent years, the number of cases of buying and selling goods online between individuals, between companies, or between companies and individuals is increasing. Many sites are used.

Usually, such an intermediary service site presents merchandise information and the like provided by a user of a merchandise side to a user of a buyer side, receives a purchase request from the buyer side user, and receives various requests for closing a negotiation. Provide support. In a site that handles many types of products, the number of buyer-side users accessing the site is large, and for the seller-side user, a great advertising effect on the own product can be obtained. In the case of a service that allows a buyer-side user to easily purchase a product via a personal computer or the like connected to the Internet and to negotiate purchase conditions, a shopping service that meets the request is more suitable. It can be performed. Also, as such an intermediary service site, an auction site that supports buying and selling of commodities in an auction system has appeared.

[0004] Usually, in such an intermediary service, a main service is to support a process until a negotiation is closed, and transaction procedures such as payment for payment and delivery of goods after the negotiation is performed by a party (seller / seller). Buyer) is often left between. Further, when a seller or a buyer rejects a transaction after the conclusion of a negotiation, the processing is usually performed on the side of the intermediary service provider.

[0005]

However, when the transaction procedure after the negotiation is completed is completely left to the parties (sellers and buyers), the process is often not standardized, and the transaction is performed smoothly. There was a problem that can not proceed. In particular, corporate users, etc., who proceed with multiple transactions in parallel with many buyers, send and receive numerous e-mails, telephone calls, faxes, etc., and it is not easy to grasp the progress of each. Was. In addition, in the case of an unfamiliar individual user, there is a possibility that an erroneous or useless procedure may be performed, and there is a sense of anxiety for the individual.

[0006] Further, in many cases, the processing at the intermediary service provider side when a transaction is rejected by one of the parties is not systematized, and each time the operator contacts the party by e-mail or the like, and as necessary, I was responding. Therefore, the processing operation requires time, and there is a high possibility that an error will occur.

[0007] Therefore, an object of the present invention is to provide a merchandise sales intermediation system that provides a merchandise sales intermediation service to users widely via a network.
Equipped with a function to support transaction procedures between buyers, it is possible to improve the safety, reliability and rationality of transactions, and to efficiently and reliably process transactions when rejecting transactions. A system and method are provided.

[0008]

In order to achieve the above object, one aspect of the present invention is to provide a merchandise sales intermediary system for mediating merchandise sales using a network, in the case of a transaction after the conclusion of a negotiation. According to a procedure predetermined for each transaction method, the seller and the buyer repeatedly send an e-mail instructing an operation to be performed next, and repeatedly display a web page prompting input of information to be conveyed to the trading partner,
It is to navigate the transaction process between seller and buyer. Therefore, according to the present invention, even in a transaction procedure after a negotiation is completed, appropriate services are provided to the parties, the transaction can be smoothly performed, and the security, reliability, and rationality of the transaction are ensured. .

In order to achieve the above object, another aspect of the present invention is to connect to a plurality of user terminals via a network and receive merchandise information from a seller and a purchase request from a buyer via the user terminals. In a merchandise brokerage system using a network that mediates negotiations for merchandise sales, a transaction procedure performed between the seller and the buyer after the negotiation is closed is an e-mail containing information indicating an operation to be performed next. The transmission and the display on the user terminal of the interface screen for prompting the input of information to be conveyed to the trading partner are performed in accordance with a predetermined procedure for the seller and the buyer by repeatedly performing the process. Features.

Further, in the above-mentioned invention, in a preferred mode, the operation to be performed next specified by the e-mail is an operation of selecting a URL displayed in the e-mail. The display of the interface screen is executed.

Further, in the above invention, another aspect is as follows.
The electronic mail includes information to be transmitted to the business partner input from the interface screen.

In the above-mentioned invention, another aspect is as follows.
Further, when there is a request from the seller or the buyer based on the input from the interface screen, the progress of the transaction procedure is displayed on the user terminal of the seller or the buyer.

Further, in the above-mentioned invention, another aspect is as follows.
The negotiation of the sale of goods is performed in an auction format, and the conclusion of the negotiation is to determine the successful bidder who is the buyer by a bidding method or to determine the successful bidder who is the seller by a reverse bidding method. It is characterized by the following.

[0014] In order to achieve the above object, another aspect of the present invention is connected to a plurality of user terminals via a network, and receives merchandise information from a seller and a purchase request from a buyer via the user terminals. In a merchandise brokerage system using a network for mediating negotiations for merchandise sales, if one of the seller and the buyer rejects the transaction after the conclusion of the negotiation, the transaction rejection is performed by the request of the rejected side. Display the transaction refusal application interface screen to make an application to the effect that the transaction was rejected to the user terminal on the side where the transaction was rejected. An e-mail containing information that the application has been made and information prompting an explanation of the circumstances of the transaction refusal is sent, and the predetermined Refusal to the the part of the user terminal, and displaying circumstances described interface screen for circumstances described.

Further, in the above-mentioned invention, a preferable mode is characterized in that the predetermined operation on the side that rejects the transaction is an operation for selecting a URL displayed in the electronic mail.

[0016] Further, in the above invention, another aspect is as follows.
If the display of the transaction refusal application interface screen has passed a predetermined period after the negotiation has been concluded, or a notice that the transaction rejection will be rejected from the party who rejected the transaction to the party who rejected the transaction It is performed when there is.

In the above invention, another aspect is as follows.
Further, an interface screen is provided for displaying information on the business negotiation that has been rejected to the organizer who mediates the sale of the product, based on inputs from the interface screen for application for transaction refusal and the interface screen for situation explanation. It is characterized by being.

Further, in the above invention, another aspect is as follows.
Businesses whose information is displayed on the interface screen are:
It is characterized by a negotiation with the circumstance explanation from the circumstance explanation interface screen or a negotiation in which a predetermined period has passed after the application from the transaction rejection application interface screen.

Still further, in the above-mentioned invention, another aspect is that the negotiation of the sale of goods is performed in an auction format, and the conclusion of the negotiation determines the successful bidder who is the buyer by a bidding method, or It is characterized in that the successful bidder who is the seller is determined by a reverse bidding method.

To achieve the above object, another aspect of the present invention is to receive merchandise information from a seller and a purchase request from a buyer through a plurality of user terminals connected to a network, In a merchandise brokering method using a network for mediating, in a transaction procedure performed between a seller and a buyer after a negotiation is concluded, an e-mail including information indicating an operation to be performed next is transmitted. The first step and the second step of displaying on the user terminal an interface screen for prompting input of information to be conveyed to the business partner are repeatedly performed on the seller and the buyer in accordance with a predetermined procedure. It is characterized by the following.

In order to achieve the above object, another aspect of the present invention is to receive merchandise information from a seller and a purchase request from a buyer through a plurality of user terminals connected to a network, and In the method of brokering merchandise sales using a network that mediates negotiations, if one of the seller and the buyer refuses the transaction after the conclusion of the negotiation, the transaction is rejected by the request of the rejected party. Displaying a transaction rejection application interface screen for making an application to the effect that the transaction has been rejected to the user terminal of the side, and when the application is made from the transaction rejection application interface screen, Sending an e-mail containing an application and information prompting the user to explain the circumstances of the transaction refusal, and performing a predetermined operation on the side that rejected the transaction. , The transaction to the the side of the user terminal rejected, characterized by having a step of displaying the circumstances described interface screen for circumstances described.

Further objects and features of the present invention will become apparent from the embodiments of the present invention described below.

[0023]

Embodiments of the present invention will be described below with reference to the drawings. However, such embodiments do not limit the technical scope of the present invention.
In the drawings, the same or similar components are denoted by the same reference numerals or reference symbols.

FIG. 1 is a configuration diagram of an auction system according to an embodiment of the present invention. The auction system shown as an example of a merchandise trading mediation system to which the present invention is applied is a server system connected to the Internet that mediates the buying and selling of merchandise in a bidding system or a reverse bidding system, and provides an auction service to a user via the Internet. provide.

In the figure, an auction server 1 is an auction system according to the present embodiment in which an auction service is widely provided to users via the Internet 2. The auction server 1 uses WWW (World Wide We
b) URL (Uniform Resource Locat)
An interface screen (Web page) for providing an auction service is provided for the site specified by or). This screen is usually HTML (Hyper Text M
ark-up Language) and can be browsed from each terminal connected to the Internet 2.

A user 4 using this service accesses a site providing the auction service from the user terminal 3 connected to the Internet 2. The connection from the user terminal 3 to the Internet 2 is a company LA
This is performed in a dial-up format via N or the like or via a telephone line. The user terminal 3 has installed therein a program for connecting to the Internet 2 and a browser for browsing each site on the WWW. Also, the auction server 1 is connected to a host terminal 5 for the operator 6 of the host of the auction service to operate.

The interface screen (Web page) provided by the auction server 1 is a Web page on another WWW.
Like a page, it is composed of a plurality of hierarchical pages, and anyone can access the top page. Thereafter, when using an auction function such as exhibition or bidding, it is usually necessary to register the user's name, address, e-mail address, etc., and become a member. For the user 4 who has become a member, a user ID and a user password are determined.

When the user 4 who has become a member makes an exhibition, after inputting the user ID and the user password, the user 4 registers information on his / her own merchandise to be sold in the auction server 1. The registered exhibit is displayed as a list on the Web page, and the user 4 makes a bid for a desired product from the list. At the time of bidding, after input of the user ID and user password is requested as required, the user inputs a desired purchase price and the like. The auction server 1
When the conditions for a successful bid are established according to various designated methods, the successful bidder is determined, and the seller of the product and the successful bidder are notified by e-mail that the successful bid has been made. In the case of conducting a reverse bidding auction, a bid from an exhibitor is accepted in response to a purchase request of the user 4, and the exhibitor is determined by a successful bid.

As shown in FIG. 1, the auction server 1
Is auction DB10, program module group 2
0, a mail server 30, a Web server 40, and the like. The auction DB 10 stores various data (11 to 15) necessary for conducting an auction.
The information on the above-mentioned exhibit is registered as exhibit data 12 with a lot number attached. The program module group 20 also includes program modules not shown, and these program modules execute various processes for providing an auction service. The above-described determination of the successful bidder is performed by the successful bidder determination module 21 in the figure. Also, the mail server 30
Sends and receives an e-mail such as the above-mentioned notification at the time of a successful bid, and the Web server 40 provides the Web page to the user.

In the above configuration, the transaction navigation module 22 and the transaction rejection processing module 23 included in the program module group 20 and the transaction data 14 and the transaction rejection data 15 included in the auction DB 10 are features of the present invention. This is the part to make. The transaction navigation module 22 and the transaction data 14 are parts that control a transaction navigation function that supports a transaction procedure performed between an exhibitor and a successful bidder after a successful bid. Further, the transaction rejection processing module 23 and the transaction rejection data 15 are parts that have a function of supporting a transaction rejection process performed when an exhibitor or a successful bidder rejects a transaction after a successful bid.

The two functions of the auction system include an e-mail in which a process to be performed by a seller, a successful bidder, or the operator 6 of the auction service after a successful bid is repeatedly executed according to a predetermined procedure. It is intended to improve the security, reliability and efficiency by stylizing by sending and sending Web pages. Hereinafter, the transaction navigation function and the function of supporting the transaction refusal process will be specifically described.

FIG. 2 is a diagram showing a flow of a transaction procedure after a successful bid when the transaction navigation function in the auction system is used. 3 to 8
Is a diagram for explaining this. First, if you want to use the transaction navigation function, the seller (seller)
4a registers this fact in the auction server 1 at the time of exhibition or the like (step S0 in FIG. 2).

As described above, when the conditions for a successful bid are established and the successful bidder is determined by the successful bidder determination module 21 (step S1 in FIG. 2), the auction server 1 sends the successful bid notification mail via the mail server 30 to the exhibitor. 4a and to the successful bidder (buyer) 4b (step S2 in FIG. 2). The mail received by the highest bidder 4b (step S3 in FIG. 2) is shown in FIG.
3A, and includes a comment for promoting the use of the transaction navigation function, as shown in FIG. 3B.

Further, a URL (c in FIG. 3) for the successful bidder 4b to perform the next procedure is embedded in the mail, and the successful bidder 4b selects this URL portion by an operation such as clicking with a mouse. As a result (step S4 in FIG. 2), the Web page at this URL is displayed on the user terminal 3 of the successful bidder 4b from the Web server 40 (step S5 in FIG. 2). This Web page is a transaction method selection screen (exemplified in FIG. 4A) that prompts the successful bidder 4b to select a transaction method to be performed next in a transaction after a successful bid. The successful bidder 4b selects a desired transaction method on this screen (step S6 in FIG. 2). Here, as shown in FIG. 4B, it is assumed that "COD mail" has been selected, and an example of the case of "COD mail" will be described below.

When the transaction method is selected, the transaction navigation module 22 records the information in the transaction data 14 of the auction DB 10 (Step S7 in FIG. 2), and prompts the successful bidder 4b to input necessary information. Is displayed from the Web server 40 (step S8 in FIG. 2). FIG. 5A shows an example of the screen, and requests input of a name, an address, a telephone number, and the like. At this time, since the information shown in FIG. 5B is already recorded in the successful bidder data 13 of the auction DB 10, the content is displayed as a default value.

The successful bidder 4b checks and corrects the information (b in FIG. 5) already displayed on the screen, and checks a blank portion (FIG. 5).
(C) of FIG. 2 (step S9 in FIG. 2). When the necessary information is input, the transaction navigation module 22 records the information in the auction DB 10 (step S1 in FIG. 2).
0), a text of an e-mail containing information to be notified to the exhibitor 4a is created and presented to the successful bidder 4b via the Web server 40 (step S11 in FIG. 2). FIG. 6A shows an example of the mail message. The mail message contains the information input by the successful bidder 4b and information urging the next procedure.

After confirming the mail text, the successful bidder 4b
An operation for sending a mail is performed (step S12 in FIG. 2). Upon receiving the instruction, the business navigation module 22 receives the instruction and
The e-mail of the mail text confirmed by b is transmitted to the exhibitor 4a via the mail server 30 (step S13 in FIG. 2). FIG. 6B shows an example of a mail transmitted based on FIG. 6A. Seller 4 who received the email
a (step S14 in FIG. 2) executes a procedure for sending out the auctioned item in accordance with the information indicated in the mail (step S15 in FIG. 2).

Upon completion of the shipping procedure, the exhibitor 4a
The designated URL is accessed in accordance with the instruction of the above mail (step S16 in FIG. 2). In the example shown in FIG. 6, since the URL (c in FIG. 6) is embedded in the transmitted mail b, access is possible by an operation of selecting that part. A web page for inputting information to be transmitted to the successful bidder is prepared in the accessed URL, and the input screen is displayed from the web server 40 to the user terminal 3 of the exhibitor 4a.
Is displayed (step S17 in FIG. 2). FIG. 7A shows an example of the screen, and the exhibitor 4a inputs necessary information (b in FIG. 7) such as a courier name and a shipping date (step S in FIG. 2).
18).

The information input by the exhibitor 4a is recorded in the auction DB 10 by the transaction navigation module 22 (step S19 in FIG. 2). Next, the transaction navigation module 22 creates an e-mail message including information to be notified to the successful bidder 4b based on the input information, and presents it to the exhibitor 4a via the Web server 40 ( Step S20 in FIG. 2). FIG. 8A shows an example of the mail message. In this case, the mail message also includes information input by the exhibitor 4a and information prompting the next procedure.

The exhibitor 4a confirms the mail text,
A mail transmission operation is performed (step S21 in FIG. 2). In response to the instruction, the transaction navigation module 22 transmits an electronic mail of the confirmed mail text to the successful bidder 4b via the mail server 30 (step S22 in FIG. 2). In FIG.
b shows an example of the mail transmitted based on a of FIG.

The successful bidder 4b having received the e-mail (step S23 in FIG. 2) waits for the delivery of the goods, checks the contents, etc. (step S24 in FIG. 2), and then receives the URL specified by the e-mail. (C in FIG. 8). After that, procedures necessary for completing the transaction, such as notifying the seller 4a that the product has arrived, are performed by the transaction navigation module 2.
2 navigates in the same way using email and web pages, and all transaction procedures are completed.

The auction system is provided with a transaction status display screen for displaying a list of auctions related to the user 4 for each user 4. The user 4 inputs a user ID and a user password. Thus, the user can access this Web page. FIG. 9 is a diagram showing an example of the transaction status display screen. On the transaction status display screen, only information on auctions in which the accessing user 4 is involved is listed without omission, and the progress status at that time is displayed for each item. When the transaction navigation function is used, the status of the transaction procedure after a successful bid is displayed as the progress status, and the status of the user's transaction can be easily grasped.

As described above, by using the transaction navigation function provided in the auction system, the exhibitor and the successful bidder can be navigated by the e-mail and the Web page sequentially transmitted, and the transaction procedure after the successful bid is made. Can proceed without any mistakes. In addition, the user can easily grasp the progress of his / her transaction by browsing the transaction status display screen. However, the display of this screen is particularly effective for users involved in many transactions. Function.

In the above description, it is assumed that “Cash on delivery mail” is selected as the transaction method. There are multiple transaction methods such as “Shipment of registered mail and delivery of merchandise”, and when using the transaction navigation function, no matter which transaction method is selected, use the procedure that is appropriate for each transaction method. Navigate the user by repeatedly sending an e-mail and displaying a Web page as described above.

Next, a function of the auction system for supporting the transaction refusal process will be described. FIG.
FIG. 4 is a diagram showing a processing flow when a seller or a successful bidder rejects a transaction after a successful bid. FIG.
1 to 15 are diagrams for explaining this. Here, a user who has rejected a transaction by a trading partner and proposes to that effect to the organizer of the auction service will be referred to as a transaction rejection applicant 4c, and a user who has rejected the transaction will be referred to as an applicant 4d.

First, the transaction refusal applicant 4c, whose transaction has been rejected by the business partner, goes to the transaction refusal application screen prepared as a web page of the auction system in order to apply to the auction organizer to that effect. log in. In that case, your user ID, user password,
And the lot number of the rejected exhibit (see FIG. 11)
Enter a) (step S1 in FIG. 10). In addition, in the auction method called flash sale or Dutch auction, where the same exhibit is awarded to multiple buyers at the same time, if the seller is refused to trade, the lot number of the above-mentioned exhibit alone will be used to identify the trading partner. Since it cannot be specified, the user ID of the business partner is also input. For the input, a screen displaying candidate users after the input of the lot number may be presented, and the corresponding user may be selected from the screen.

Upon receiving the input, the auction server 1
The transaction rejection processing module 23 of the auction DB1
If a predetermined period (for example, one week) has elapsed after the successful bid, the transaction rejection application screen is displayed on the user terminal 3 of the transaction rejection applicant 4c via the Web server 40 (see FIG. 10). Step S2 → S8). On the other hand, if the predetermined period has not elapsed, it is determined whether the transaction partner (applicant 4d) has received a notice of rejection of the transaction.
The user terminal 3 of the transaction refusal applicant 4c to send a message to inquire to c
(Step S3 in FIG. 10).

If there is a reply from the transaction refusal applicant 4c that there is a notice (step S4 in FIG. 10), the transaction rejection processing module 23 displays a transaction rejection application screen to the transaction rejection applicant 4c (FIG. 10). Ten steps S5 → S8). On the other hand, if the response is that there is no notification (step S in FIG. 10).
4) A message prompting the transaction refusal applicant 4c to wait for the application until a predetermined period elapses after the successful bid is displayed, and the process is terminated (step S6 → S7 in FIG. 10). After receiving the message, the transaction refusal applicant 4c logs in to the transaction refusal application screen again after a predetermined period has elapsed or after receiving a notification from the business partner.

When the transaction refusal request screen as shown in FIG. 11B is displayed, the transaction refusal applicant 4c fills in the comment entry field with the current status of the transaction refusal, the contents of the contact from the business partner, and the like. Apply using the button (Steps in Figure 10)
S9). The transaction rejection processing module 23 receives this as a new transaction rejection application, and
10 is recorded as new transaction refusal data 15 (FIG. 1).
0 step S10).

At the same time, the transaction rejection processing module 23 generates an e-mail notifying the applicant 4d who is the transaction partner who has applied for rejection of the transaction that the application for rejection of the transaction has been made. Is transmitted to the applicant 4d via the server (step S11 in FIG. 10). In FIG.
a shows an example of the mail. The e-mail includes a comment stating that a transaction refusal request has been made, a comment urging explanation of the circumstances, a warning sentence, and the like.

The applicant 4d who has received the e-mail (FIG. 10
Step S12), the URL of the situation explanation screen (b in FIG. 12) embedded in the e-mail is clicked with the mouse in accordance with the instruction of the mail, and the situation explanation screen is accessed (step S13 in FIG. 10). Then, a situation explanation screen as shown in FIG. 13A is displayed via the Web server 40 (Step S14 in FIG. 10), and the applicant 4d describes the situation that led to the transaction rejection on the screen (FIG. 13A). Step S1 in FIG.
5). After the description, when the OK button is pressed, the contents are processed by the transaction rejection processing module 23 in the auction DB 10
Is added to the transaction refusal data 15 (step S16 in FIG. 10).

Thereafter, a list of the transaction refusal data 15 is displayed to the operator 6 who performs the transaction rejection processing on the organizer side of the auction site (step S1 in FIG. 10).
7). This screen displays the transaction refusal data for which the applicant 4d has described the above information and the transaction rejection data for which a predetermined period (for example, one week) has passed after the application for rejection without a description of the circumstances as a transaction rejection processing list. This is displayed, an example of which is shown in FIG. This list is generated by the transaction rejection processing module 23 extracting necessary data from the auction DB 10 when there is a request from the operator 6, and is displayed on the terminal 5 of the operator 6 via the Web page 40. .

The transaction refusal data listed on this screen is an object to which the operator 6 should currently perform the transaction rejection processing, and the operator 6 performs an appropriate process for each of the transaction rejection data sequentially listed ( Step S18 in FIG. 10). As shown in FIG. 15A, the display screen can display detailed contents for each transaction refusal data, and the operator 6 displays the comment of the transaction refusal applicant 4c and the applicant 4d. Review the comments on
The content of the processing is determined, and the processing is appropriately executed by a processing button as shown in FIG.

The contents of the processing include returning an exhibition fee paid at the time of exhibition or a contract fee paid when a successful bid is established to the exhibitor, adding a history of refusal of the transaction, and the like. If the user has previously made a payment to the organizer of the auction site for payment of the listing fee or the closing fee, the processing is performed by increasing the amount of the deposit recorded in the auction DB 10. be able to. If the commission or the deposit amount is treated as points, the fee or the like is returned by increasing the number of points.

When the processing button is operated by the operator 6, the transaction rejection processing module 2 is
3 makes an appropriate change to the data in the auction DB 10 (step S19 in FIG. 10), and the transaction refusal process is completed (step S20 in FIG. 10).

As described above, most of the transaction rejection processing such as the contact work conventionally performed by the operator of the auction site is automated by using the function for supporting the transaction rejection processing provided in the auction system. Thus, the burden on the operator can be reduced, and the processing target can always be viewed as a list, thereby reducing processing errors.

It is also possible to link the above-described transaction navigation function with the transaction rejection processing function. In this case, the seller who wishes to use the transaction navigation function is given a predetermined period after the successful bid (see FIG. 1 described above).
If there is no access (step S4 in FIG. 2) from the successful bidder even after the elapse of the predetermined period of step S2 of 0 (for example, one week), an e-mail is sent to the effect that a transaction rejection application can be made.
The seller who received the e-mail has the URL embedded in the e-mail
By selecting, the user can log in to the above-described transaction refusal application screen, and thereafter, the above-described transaction rejection processing flow (FIG. 10)
The processing is performed in step S8).

As described above, in the auction system according to the present embodiment, the function of navigating the transaction procedure performed between the exhibitor / successful bidder after the successful bid is provided, and the safety, reliability and efficiency of the transaction are improved. Can be improved. In addition, when the transaction is rejected by one of the exhibitor / successful bidder after the successful bid, the processing of the auction organizer is largely automated, so that the work of the organizer operator can be reduced and work errors can be prevented.

Although the auction system according to the present embodiment has both the transaction navigation function and the transaction rejection processing function, the auction system may have only one of the functions. Further, in the above-described embodiment, the auction in the normal bidding system has been described, but the present invention can be similarly applied to a case in which a reverse bidding auction is performed.

Further, the transaction navigation function and the transaction rejection processing function described here can be applied not only to the auction system but also to all systems for mediating services for buying and selling goods online via a network. / Can be used for transaction procedures between buyers.

The scope of protection of the present invention is not limited to the above embodiments, but extends to the inventions described in the claims and their equivalents.

[0062]

As described above, according to the present invention, a navigation function using an e-mail and a Web page is provided for a transaction procedure after a negotiation of a sale of goods using a network. Therefore, the transaction procedure between the seller and the buyer can be smoothly performed, and there is an effect that the security, reliability and efficiency of the transaction are improved. Further, when the seller / buyer rejects the transaction after the negotiation is completed, the process on the mediation service organizer side is largely automated, so that the work of the organizer side operator can be reduced and a work error can be prevented.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of an auction system according to an embodiment of the present invention.

FIG. 2 is a diagram showing a flow when a transaction navigation function is used in the auction system according to the embodiment of the present invention.

FIG. 3 is a diagram for explaining a successful bid notification when a transaction navigation function is used.

FIG. 4 is a diagram for explaining selection of a transaction method when a transaction navigation function is used.

FIG. 5 is a diagram for explaining input of necessary information by a successful bidder when a transaction navigation function is used.

FIG. 6 is a diagram for explaining an e-mail from a successful bidder to an exhibitor when a transaction navigation function is used.

FIG. 7 is a diagram illustrating input of necessary information by an exhibitor when a transaction navigation function is used.

FIG. 8 is a diagram for explaining an e-mail from an exhibitor to a successful bidder when a transaction navigation function is used.

FIG. 9 is a diagram showing an example of a transaction status display screen.

FIG. 10 is a diagram showing a flow when a transaction rejection processing function is used in the auction system according to the embodiment of the present invention.

FIG. 11 is a diagram for explaining a transaction rejection application when a transaction rejection processing function is used.

FIG. 12 is a diagram for explaining an e-mail transmitted to a requestee when a transaction refusal processing function is used.

FIG. 13 is a diagram for explaining a situation when a transaction rejection processing function is used.

FIG. 14 is a diagram for explaining a list of transaction refusal data displayed to the organizer-side operator when the transaction refusal processing function is used.

FIG. 15 is a diagram for explaining a transaction rejection process performed by the organizer-side operator when a transaction rejection process function is used.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Auction server 2 Internet 3 User terminal 4 User 4a Seller (seller) 4b Successful bidder (buyer) 4c Transaction refusal applicant 4d Applicant 5 Organizer terminal 6 Operator 10 Auction DB 11 Seller data 12 Exhibit data 13 Successful bidder data 14 Transaction data 15 Deal refusal data 20 Program module group 21 Successful bidder determination module 22 Deal navigation module 23 Deal reject processing module 30 Mail server 40 Web server

 ────────────────────────────────────────────────── ─── Continuing on the front page (72) Inventor Masayuki Watanabe 5-3 Kamiyama-cho, Shibuya-ku, Tokyo F.A. in FNA (reference) 5B049 AA01 AA02 BB11 BB36 CC02 CC05 CC10 DD01 EE00 FF03 GG02 GG04 GG07

Claims (13)

[Claims] Claims: 1. A merchandise purchase and sale system which is connected to a plurality of user terminals via a network, receives merchandise information from a seller and purchase requests from a buyer via the user terminals, and mediates business negotiations for merchandise sales. In the intermediary system, a transaction procedure performed between the seller and the buyer after the negotiation is completed, transmission of an e-mail including information for instructing an operation to be performed next, and input of information to be conveyed to the business partner And a display on the user terminal of an interface screen for prompting the seller and the buyer in accordance with a predetermined procedure. . 2. The interface according to claim 1, wherein the next operation specified by the e-mail is an operation of selecting a URL displayed in the e-mail. A merchandise trading intermediary system using a network characterized in that display is performed. 3. The merchandise trading intermediation system using a network according to claim 1, wherein the electronic mail includes information to be transmitted to the business partner input from the interface screen. . 4. The transaction procedure according to claim 1, further comprising, upon a request from the seller or the buyer, based on an input from the interface screen, to the user terminal of the seller or the buyer. A merchandise trading brokerage system using a network, characterized by displaying the status. 5. The method according to claim 1, wherein the negotiation of the sale of the goods is performed in an auction format, and the establishment of the negotiation determines a successful bidder who is the buyer by a bidding method. Alternatively, a merchandise trading intermediary system using a network, characterized by determining a successful bidder who is the seller by a reverse bidding method. 6. A merchandise sales system connected to a plurality of user terminals via a network, accepting merchandise information from sellers and purchase requests from buyers via the user terminals, and using a network for mediating business negotiations for merchandise sales. In the mediation system, if one of the seller and the buyer rejects the transaction after the conclusion of the negotiation, the transaction is rejected to the user terminal on the rejected side in response to a request from the rejected side. A transaction refusal application interface screen for making an application to the effect that the transaction was rejected is displayed, and when there is an application from the transaction rejection application interface screen, the transaction refusal side is notified that the application has been made.
Sending an e-mail including information prompting the user to explain the circumstances of the transaction refusal, and performing a predetermined operation on the side that rejected the transaction, to the user terminal on the side that rejected the transaction, for explaining the situation. A merchandise trading brokerage system using a network, which displays an interface screen. 7. The merchandise trading intermediation system using a network according to claim 6, wherein the predetermined operation on the side rejecting the transaction is an operation of selecting a URL displayed in the electronic mail. . 8. The transaction screen according to claim 6, wherein the transaction refusal application interface screen is displayed when a predetermined period has passed after the negotiation has been concluded, or when the transaction refusal is performed from the party who rejected the transaction. A merchandise trading intermediary system using a network, which is performed when there is a notice to the rejected side to reject a transaction. 9. The information according to any one of claims 6 to 8, further comprising, based on an input from the transaction rejection application interface screen and the situation explanation interface screen, information on the negotiation rejected. A merchandise sales intermediation system using a network, comprising an interface screen displayed to an organizer who mediates merchandise sales. 10. The negotiation in which information is displayed on the interface screen according to claim 9, wherein the negotiation with the circumstance description from the circumstance explanation interface screen or the negotiation with the transaction rejection application interface screen A merchandise trading intermediary system using a network, characterized in that the business negotiation has been a predetermined period after the existence of the business negotiation. 11. The method according to claim 6, wherein the negotiation of the sale of the goods is performed in an auction format, and the establishment of the negotiation determines a successful bidder who is the buyer by a bidding method. Alternatively, a merchandise trading intermediary system using a network, characterized by determining a successful bidder who is the seller by a reverse bidding method. 12. A merchandise sales intermediation method using a network that receives merchandise information from a seller and a purchase request from a buyer via a plurality of user terminals connected to a network and mediates negotiations on merchandise sales. A first step of transmitting an e-mail including information indicating an operation to be performed next in a transaction procedure performed between the seller and the buyer after the negotiation has been completed, and information to be transmitted to the business partner And a second step of displaying an interface screen on the user terminal that prompts the user to input an item according to a predetermined procedure. Mediation method. 13. A merchandise trading brokerage method using a network for accepting merchandise information from a seller and a purchase request from a buyer via a plurality of user terminals connected to a network, and mediating negotiations on merchandise sales. If one of the seller and the buyer rejects the transaction after the conclusion of the negotiation, a request from the rejected party is sent to the user terminal on the rejected side to indicate that the transaction has been rejected. Displaying a transaction refusal application interface screen for making an application, and when there is an application from the transaction refusal application interface screen, to the party who rejected the transaction, the fact that the application was made,
Sending an e-mail including information prompting the user to explain the circumstances of the transaction refusal; and performing a predetermined operation on the side that rejected the transaction to the user terminal on the side that rejected the transaction to explain the situation. A method for mediating merchandise sales using a network, comprising a step of displaying an explanatory interface screen.