JP4901850B2 - Community server having function to support sales activities, and community service providing method - Google Patents

Description

The present invention relates to a community system, a community server, and a community service providing method. More specifically, the present invention provides a community service to a potential buyer on a communication network such as the Internet, and provides the seller with the community service. The present invention relates to a community system having a function of supporting sales activities, a community server, and a community service providing method for providing a service that enables sales activities on the community service.

In recent years, many community services on a communication network such as an electronic conference room (electronic bulletin board) service, a chat service, and a mailing list service have been provided on the Internet. And using these services, communities (groups) that limit the participants to only certain friends, and communities that target a large number of unspecified participants who have a common hobby, interest, or preference Many (groups) are built on a communication network.

In a community (group) where participants are limited to specific members, free promotional activities (sales activities) by sellers are not possible at this time, but the efficiency of sales activities in such situations is not possible. Goodness has been recognized for some time.

This is because a community (group) that restricts participants only to the specific group is equivalent to a group such as a university circle, a school group, or an alumni association. It is assumed that the group's consumption activities such as traveling with friends can be the target of sales activities, and that more buyers will purchase as the community participants invite each other. This is because it can be expected to increase.

In addition, in a community (group) that targets an unspecified number of participants, a seller who participates as one participant may conduct advertising activities (sales activities) for products and services that meet the theme. Participants may feel uncomfortable due to reasons such as communication being hindered, and there are cases where the act is prohibited by setting rules.

However, with regard to the community (group) targeting a large number of unspecified participants, the efficiency of sales activities has been similar to that of the community (group) in which the participants are limited only to the specific group. More recognized. This is because participants with common hobbies, interests, and preferences are gathering.

As described above, sales activities in communities (groups) that limit participants only to specific colleagues and communities (groups) that target a large number of unspecified participants are efficient, and the needs of sellers are high. Although it is expensive, at the present time it cannot be used in sales activities, or it can only be done with a narrow mind.

Sales activities in a community (group) built on a communication network have been impossible or difficult because participants may feel uncomfortable, for example, by hindering communication in the community. However, the needs are high and realization is desired.

The present invention has been made in view of such problems, and enables sales activities by sellers to communities (groups) on a communication network that uses community services such as electronic conference rooms (electronic bulletin boards) and mailing lists. For the purpose.

As means for solving the above problems, the present invention has the following features.
The first aspect of the present invention is proposed as a community system that provides a community service on a communication network to a group to which at least one user (potential buyer) belongs.

The system includes a community server that provides a community service to a group, a terminal used by a user, a user terminal that can be connected to the community server via a communication network, and a terminal used by a seller. And a seller terminal that can be connected to the community server via a communication network.

In this system, the community server includes, from a user terminal used by a user, user information that is information related to the user, and affiliation information that identifies a group to which the user belongs, and a group related to the group Information, and storing this information, and based on at least one of the user information and the group information, the user information of the user information belonging to a registered group that has been registered for the group information Information on the seller from the seller terminal used by the seller, allowing access to the community service provided to the registered group by the user terminal used by the registered user who is a registered user. The seller who received the seller information, memorized it, and registered the seller information. Upon receiving notification from the seller terminal used by the registered seller that the sales activity for the registered group is desired, the authority to access the community service provided to the registered group by the seller terminal used by the registered seller And store it in a state where it can be identified that it is the seller's access authority, or propose a product or service to the registered seller from the user terminal used by the registered user belonging to the registered group When a notification requesting the request is received, an access right to the community service provided to the registered group by the seller terminal used by the registered seller is generated, and this can be identified as the seller's access right And store from the seller terminal to the registered group If a request to participate in the community service is received, it is determined whether or not to participate based on the access authority, and on the community service, the seller makes a proposal or negotiation for a product or service. As a result of the proposal or the negotiation, a transaction is established, and the order information for the registered seller is received from the user terminal used by the registered user, and this is provided to which registered group when storing the order information. It is characterized by storing order information including transaction group information, which is information indicating whether or not a transaction has been established using a community service.

The community system according to the present invention enables sales activities by sellers to communities (groups) on a communication network constructed using community services such as an electronic conference room (electronic bulletin board) and a mailing list.

Here, the “community service” is a service using a tool that supports communication between users belonging to the community (group), and the tool is any program or software that can be used on the computer. Specifically, it refers to an electronic conference room, an electronic bulletin board, a chat room, a mailing list, and the like.
Further, in the embodiment described below, in addition to “community services”, the group and all services provided to users belonging to the group, including various registration services and discount services, are collectively referred to. “Group service”.
The “user” is a user of the community service and a potential buyer. In the scope of the claims, the user becomes a registered user after completing the registration, and can use the community service provided by the community server. On the other hand, in the embodiment, it is assumed that a user becomes an official “user (buyer) 12” only after registration.
A “seller” is a person who conducts sales activities for a group that uses community services. Within the scope of the claims, the seller becomes a registered seller after completing the registration. On the other hand, in the embodiment, it is assumed that the seller becomes an official “member (seller) 13” only after registration.
“User information” refers to basic information about the user, and corresponds to the user information TBL 411 in the embodiment.
The “affiliation information of the user to the group” is information indicating which user belongs to which group. In the embodiment, it corresponds to the member information TBL 413.
“Group information” refers to basic information about a group. In the embodiment, “information about a field of interest” corresponding to marketing information is excluded from the group basic information TBL4121. In addition to the information, member information TBL 413 corresponding to “affiliation information of the user to the group” is included.
In addition, “storing in a state where it is possible to identify the seller's access authority” means that the access authority given to the seller is compared with the access authority that the user has and the range of community services that can be participated This is because it is necessary to be able to identify the seller's access authority because it differs in terms of expiration date and the like.
In addition, the above is the same also in the other aspect of this invention.

The second aspect of the present invention is proposed as a community server that provides a community service on a communication network to a group to which at least one user (potential buyer) belongs.

The community server includes user information, which is information about the user, from user terminals used by the user, and group information about the group, including affiliation information that identifies the group to which the user belongs. Received, memorized this, and completed registration of the user information belonging to a registered group that is a group for which registration of the group information has been completed based on at least one of the user information and the group information The access to the community service provided to the registered group is permitted by the user terminal used by the registered user who is the user, and the seller information which is information about the seller is received from the seller terminal used by the seller. , Memorize this and use it by the registered seller who is the seller who registered the seller information Upon receiving a notification from the seller terminal that he / she wishes to conduct sales activities for the registered group, an access right to the community service provided to the registered group by the seller terminal used by the registered seller is generated, This is stored in a state where it is possible to identify the seller's access authority, and when a request for participation in the community service provided to the registered group is received from the seller terminal, based on the access authority It is characterized by determining whether or not to participate.

According to the above-mentioned community server, a community (group) on a communication network that uses community services such as an electronic meeting room (electronic bulletin board) and a mailing list for sales activities (so-called outbound sales) by approaching users from sellers. Enables sales activities by sellers.

Further, the community server receives marketing information about at least one of the user and the group from the user terminal as a method for the registered seller to select the registered group to be a sales activity, and stores it. When the marketing information browsing request is received from the seller terminal, the marketing information that matches the request is returned to the seller terminal, and the seller terminal is determined based on the returned marketing information. It may have as a feature that group selection information is received.

According to the above-mentioned community server, when performing sales activities (so-called outbound sales) by approaching users from sellers, it is easy to obtain and select information on groups subject to sales activities. .

Here, “marketing information” is information related to common interests and concerns of users belonging to the group. In the embodiment, the group basic information TBL4121 corresponds to “information on a field of interest” corresponding to marketing information, etc., anniversary information TBL4122, and a proposal request TBL4123.

In addition, the community server charges a fee for negotiation right to the registered seller when generating an access right to the community service provided to the registered group by a seller terminal used by the registered seller. It may have as a feature.

According to the community server, it is possible to sell the access authority to the community service provided to the group to the seller.

Similar to the second aspect, the third aspect of the present invention is proposed as a community server that provides community services on a communication network to a group to which at least one user (potential buyer) belongs.

The community server includes user information, which is information about the user, from user terminals used by the user, and group information about the group, including affiliation information that identifies the group to which the user belongs. Received, memorized this, and completed registration of the user information belonging to a registered group that is a group for which registration of the group information has been completed based on at least one of the user information and the group information The access to the community service provided to the registered group is permitted by the user terminal used by the registered user who is the user, and the seller information which is information about the seller is received from the seller terminal used by the seller. This is a user terminal that is stored and used by the registered user belonging to the registered group. , Upon receiving a notification requesting a proposal for a product or service from the registered seller, it generates an access right to the community service provided to the registered group by the seller terminal used by the registered seller, If the request for participation in the community service provided to the registered group is received from the seller terminal, whether or not to participate based on the access authority is stored. It is characterized by determining.

According to the above community server, a community (group) on a communication network that uses community services such as electronic conference rooms (electronic bulletin boards) and mailing lists for sales activities (so-called inbound sales) by approaching sellers from users. Enables sales activities by sellers.

In addition, when the community server generates an access authority to the community service provided to the registered group by the seller terminal used by the registered seller, When the request for participation in the community service provided to the registered group is received from the seller terminal, the access authority is possessed and the expiration date is stored. It may be characterized by permitting participation only when it is within.

According to the above community server, the access authority given to the seller can be an access authority having an expiration date limit unlike the access authority of the user.

In addition, the community server is a method in which the registered seller proposes a product or a service to the registered group, from the seller terminal, the registered user belonging to the registered group targeted for sales activities. Receiving a request to distribute an advertisement to the addressee, determining whether to distribute based on the access authority, and transmitting the advertisement to at least one of the registered users belonging to the registered group. You may have as a feature.

According to the above-mentioned community server, the seller can provide information by advertising as a “greeting” position before negotiating sales activities with users belonging to the group. , Allowing a smooth transition to negotiations.

In addition, the community server receives an order for the registered seller from a user terminal used by the registered user and stores the order using the community service provided to which registered group. It may be characterized by storing order information including transaction group information which is information indicating whether or not it has been established.

According to the above-mentioned community server, it is possible to aggregate the transaction amount, the number of transactions, etc. for each group by having “information on which group's community service was used for the transaction” in the order information. .

In addition, the community server is a method for discounting a call charge or a communication charge in a call or communication between the registered users belonging to the same registered group. Based on the transaction group information included in the order information, the points for a certain period are totaled for each group, and this is used as a discount rate calculation target group point and belongs to the same registered group The discount rate may be calculated based on the discount rate calculation target group point when calculating the charge for communication or communication between the registered users.

According to the above community server, the more active the activity (purchasing activity etc.) that can acquire points is, the more it can reduce the call / communication costs between users belonging to the same group, Incentives for point acquisition activities such as purchasing activities can be obtained.

Further, the community server is a method in which the registered user who has purchased a product registers as a user administrator of the product with the registered seller when the registered seller delivers the product to the registered user. The product delivery date is received from the user terminal, the user registration information is received from the user terminal, the user registration information is received from the user terminal, the user registration information is stored in the registration group registered in advance to manage the user who purchased the product. The registered user may be registered as a member and stored.

According to the community server, it is possible to calculate the product repair guarantee time limit based on the product delivery date, and it is possible for the user to reliably receive the after-sales service of the product or service. Further, it is possible to save the user management by the user administrator.

In addition, the community server is a method in which the registered user belongs as a method for obtaining contact information of a user having a friendship relationship based on the user information and the group information. A contact information list of users belonging to the group may be created and transmitted to the user terminal.

According to the above community server, it becomes possible for users to obtain contact information (address, phone number) of users who have a friendship relationship in an always updated state. It becomes possible to make contact more reliable. Here, the user who has a friendship means users who belong to the same group.

In addition, the community server calculates the amount of revenue received from at least one of the registered seller and the registered user at regular intervals, and calculates an amount to be reinvested in the operation of the community service based on the totaled result. You may have as.

According to the community server, a part of the profit received from the seller or user can be used for the expansion of the service provided to the user.
The invention according to claim 1 is a community server that provides a community service on a communication network to a group to which at least one user belongs.
The user information that is information about the user specified by the user identification information, the group information that is information about the group that is specified by the group identification information, and the user identification information and the group identification information are associated with each other. User information group information storage means for storing affiliation information as information,
Seller information storage means for storing seller information, which is information related to the seller, specified by the seller identification information ;
Thread information storage means for storing thread information that is information related to a thread that is a collection of writes, specified by the thread identification information;
(A) receiving, from the seller terminal used by the seller , at least the seller identification information and the group identification information for the purpose of requesting sales activities for the group;
(B) At least the group of the group to which the user belongs, for the purpose of requesting the seller to request a product or service proposal from a user terminal used by the user belonging to the group Receiving identification information and the seller identification information;
When at least one of (a) and (b) is executed,
Access authority generating means for storing access authority information for associating at least the group identification information, the seller identification information, and the thread identification information for identifying a thread serving as a place for negotiation for performing a sales activity;
When receiving the seller identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the seller terminal, the seller identification information based on the access authority information Is determined to be associated with the thread identification information, and if so, seller access determination means for permitting access to the thread specified by the thread identification information;
When receiving the user identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the user terminal, the access authority information, the affiliation information, , It is determined whether or not the user identification information is associated with the thread identification information via the group identification information, and if it is associated, the thread identified by the thread identification information is accessed. A user access determination means that permits the user to
At least the thread identification information intended to be written into the thread is identified from the user terminal permitted to access or the seller terminal permitted to access, and whether or not the seller is writing. Means for storing the information for writing and the written content together with the thread identification information in the thread information storage means together with the writing date and time as one writing record;
When receiving the thread identification information intended to refer to the thread from the user terminal permitted to access or the seller terminal permitted to access, based on the thread information storage means, Outputs the writing record, which is associated with the thread identification information that matches the received thread identification information, and includes at least information for identifying whether or not the seller is writing, writing contents, and writing date and time. Means,
Thread writing reference means having
(C) When a commercial transaction is established between the user and the seller specified by the seller identification information as a result of using the thread, the seller specified by the seller identification information included in the access authority information On the other hand, processing to charge transaction brokerage fee,
(D) a process of charging a negotiating right fee to the seller specified by the seller identification information included in the access authority information;
(E) Based on the seller information storage means, the access authority generation means stores the seller identification information included in the access authority information, and as a result, the seller who may be able to access the thread. Processing to charge the membership registration fee,
Charging means for executing at least one of the processes (c), (d), and (e)
To support group activities,
Based on the user information group information storage means, a group activity support means for permitting use of a group service provided to the group by a user terminal used by the user belonging to the group;
It is characterized by having.
The invention according to claim 2 is the invention according to claim 1,
In the charging means,
(C), when order information including at least transaction amount information is received from the user terminal belonging to the group, a transaction brokerage fee is calculated by multiplying the transaction amount information by a predetermined transaction brokerage fee rate. To
(D) uses the unit price of the predetermined access authority as the negotiation right fee.
(E) uses the prescribed fee as a member registration fee.
It is characterized by that.
The invention according to claim 3 is a community server that provides a community service on a communication network to a group to which at least one user belongs.
The user information that is information about the user specified by the user identification information, the group information that is information about the group that is specified by the group identification information, and the user identification information and the group identification information are associated with each other. User information group information storage means for storing affiliation information as information,
Seller information storage means for storing seller information, which is information related to the seller, specified by the seller identification information ;
Thread information storage means for storing thread information that is information related to a thread that is a collection of writes, specified by the thread identification information;
(A) receiving, from the seller terminal used by the seller , at least the seller identification information and the group identification information for the purpose of requesting sales activities for the group;
(B) At least the group of the group to which the user belongs, for the purpose of requesting the seller to request a product or service proposal from a user terminal used by the user belonging to the group Receiving identification information and the seller identification information;
When at least one of (a) and (b) is executed,
An access authority generation step for storing access authority information for associating at least the group identification information, the seller identification information, and the thread identification information for identifying a thread serving as a place of negotiation for performing a sales activity;
When receiving the seller identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the seller terminal, the seller identification information based on the access authority information A seller access determination step for permitting access to the thread specified by the thread identification information.
When receiving the user identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the user terminal, the access authority information, the affiliation information, , It is determined whether or not the user identification information is associated with the thread identification information via the group identification information, and if it is associated, the thread identified by the thread identification information is accessed. A user access determination step for allowing
At least the thread identification information intended to be written into the thread is identified from the user terminal permitted to access or the seller terminal permitted to access, and whether or not the seller is writing. Storing the information for writing and the written content together with the thread identification information in the thread information storing means together with the writing date and time as one writing record;
When receiving the thread identification information intended to refer to the thread from the user terminal permitted to access or the seller terminal permitted to access, based on the thread information storage means, Outputs the writing record, which is associated with the thread identification information that matches the received thread identification information, and includes at least information for identifying whether or not the seller is writing, writing contents, and writing date and time. Steps,
A thread write reference step comprising:
(C) When a commercial transaction is established between the user and the seller specified by the seller identification information as a result of using the thread, the seller specified by the seller identification information included in the access authority information On the other hand, processing to charge transaction brokerage fee,
(D) a process of charging a negotiating right fee to the seller specified by the seller identification information included in the access authority information;
(E) Based on the seller information storage means, the access authority generation means stores the seller identification information included in the access authority information, and as a result, the seller who may be able to access the thread. Processing to charge the membership registration fee,
A charging step for performing at least one of the processes (c), (d), and (e) of
To support group activities,
A group activity support step for permitting use of a group service provided to the group by a user terminal used by the user belonging to the group based on the user information group information storage means;
It is characterized by having.
The invention according to claim 4 is the invention according to claim 3,
In the charging step,
(C), when order information including at least transaction amount information is received from the user terminal belonging to the group, a transaction brokerage fee is calculated by multiplying the transaction amount information by a predetermined transaction brokerage fee rate. To
(D) uses the unit price of the predetermined access authority as the negotiation right fee.
(E) uses the prescribed fee as a member registration fee.
It is characterized by that. In addition, the relationship between each means and each step described in each claim and the description content of the specification is as follows. The user information group information storage means is described in [3.3.2. This corresponds to the user relation database DB41]. User information is mainly described in [3.3.2.1. User information TBL411], group information is mainly [3.3.2.2. In the group basic information TBL4121], the affiliation information is [3.3.2.5. This corresponds to the information stored in the member information TBL 413]. The seller information storage means [3.3.3.1. This corresponds to the member information TBL421]. The user identification information is a user ID mainly associated with the session ID, but it may be possible to uniquely identify it by combining an email address or a plurality of information. The group identification information is mainly a group ID, but it may be possible to uniquely identify a combination of a plurality of pieces of information. The seller identification information is a member ID mainly associated with the session ID, but it may be possible to uniquely identify it by combining an email address or a plurality of information. The thread information storage means [3.3.4.2. This corresponds to the electronic conference room TBL432]. Note that a thread generally means a collection of writing (related to a specific topic). The thread identification information is mainly a thread ID, but may be uniquely identified by combining with a group ID. The access authority generation means (or access authority generation step) is described in [3.4.3. This corresponds to member access authority generation S43]. The access authority information can be found in [3.3.3.2. This corresponds to information stored in the member access authority management TBL 422]. However, [3.3.2.6. Thread management (for users) TBL414] and [3.3.3.3. As in the case of thread management (for members) TBL 423], information based on the member access authority management TBL 422 may be distributed and associated elsewhere. Seller access determination means (or seller access determination step) is described in [3.4.5.2. This corresponds to the member access check S452]. The user access determination means (or user access determination step) is described in [3.4.5.1. This corresponds to the user access check S451].
The thread writing reference means (or thread writing reference step) is described in [3.4.5.3. Corresponds to the electronic conference room S453]. The “information for identifying whether or not the seller has written” mainly refers to the “user ID of the writer or the member ID of the writer” (user identification information or seller identification information) of the electronic conference room TBL432. Is applicable. However, in the group where a small number of members in the group participate, the “writer name” in the electronic conference room TBL 432 may be sufficient, or in the group where a relatively large number of members who are not acquainted participate It is desirable that the information is such that the seller can be identified more clearly, such as seller identification information. The “written content” mainly corresponds to “text” in the electronic conference room TBL 432. The “writing date and time” corresponds to the “date” and “time” of the electronic conference room TBL 432.
Regarding the charging means (or charging step), (c) is [3.4.6. Order S46] and [3.4.7. Corresponding to the delivery settlement S47], (d) is [3.4.3. The description in the case of requesting the purchase price of the advertisement distribution right to the member 13 described in the member access authority generation S43] corresponds to (e), [3.4.2. This corresponds to the description in the case of requesting the membership registration fee described in the various member-related registrations S42].
The group activity support means (or group activity support step) is described in [1.2.1.3. Group service 15a (host 11 => user 12 (group 1A))] and [4.1. This corresponds to the call / communication charge discount processing S4A].

According to the present invention, sales activities by a seller can be made to a community (group) on a communication network using a community service such as an electronic conference room (electronic bulletin board) or a mailing list.

Further, according to the present invention, there is an advantage that a user who is a member of a community (group) as a buyer can draw out advantageous conditions by negotiating with a group. Further, for the organizer of the system according to the present invention, the owner of the community server, the operator, the administrator, the person who executes the community service providing method, etc., profits such as a negotiation right fee, a marketing information usage fee, a transaction brokerage fee, etc. There is merit that can be obtained. If a part of the profit is used for expansion of community services and the like, the merit for users who are members of the community (group) is further increased.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[1. Business model realized by this embodiment]
First, a business model realized by the community system according to the present embodiment will be described. FIG. 1 is a diagram showing an outline of a business model realized by using a community system according to the present invention (hereinafter referred to as “the present invention system”), and information, services, and products exchanged between each entity. It represents the flow of money.

[1.1. About the subject]
The entities appearing in the business model (which may be any of natural persons, corporations, organizations, etc.) are the organizer 11, the user (buyer) 12, and the member (seller) 13.

The organizer 11 is an organizer who manages and manages the business model or the system of the present invention.

A user (buyer) 12 (hereinafter referred to as “user 12”) is a user of a community service on a communication network provided by the organizer 11 and is an entity who participates in the business model as a buyer. The user 12 can participate in the business model (that is, use the system of the present invention) by belonging to the group 1A. Here, the group 1A is a group composed of at least one user 12, and the “community (group)” is managed as the group 1A on the business model. Further, the user 12 can participate in a plurality of groups 1A. When the user 12 participates in the group 1A, the user 12 becomes a “member” of the group 1A.

A member (seller) 13 (hereinafter referred to as “member 13”) is an entity that participates in the business model as a seller of goods or services, and specifically corresponds to a sales company of goods or services. However, the membership system is not necessarily adopted in the community system and the community service providing method.

[1.2. About transactions between entities]
[1.2.1. Organizer 11 <=> User 12 (Group 1A)]
[1.2.1.1. Group information 14a (user 12 (group 1A) => organizer 11)]
The user 12 provides the organizer 11 with information regarding itself and information regarding the group 1A to which the user 12 belongs (hereinafter referred to as “group information”) (14a). Here, the group information includes group name and belonging member information (affiliation information indicating which user 12 belongs), hobbies, interests and preferences shared by members of the group 1A, Includes marketing information such as service and product needs, formation dates, and activity details. As will be described later, this marketing information is provided to the member 13 via the organizer 11 (16a). Here, the collection of marketing information is not essential, but it is desirable to collect it.

[1.2.1.2. Negotiation right 14b (user 12 (group 1A) => organizer 11)]
In addition, when the user 12 wants to negotiate with the member 13 on the product provided by the member 13, the user 12 can inform the organizer of the intention of the negotiation (14b). As will be described later, this is given to the member 13 as a right to negotiate via the organizer 11 (16b).

[1.2.1.3. Group service 15a (organizer 11 => user 12 (group 1A))]
Conversely, the organizer 11 provides the user 12 with a service that supports group activities (hereinafter referred to as “group service”). Here, the group service specifically refers to an electronic conference room (electronic bulletin board) service, a chat service, a mailing list service, a virtual community service, a group schedule management table service, and an online game played between users belonging to the same group. Various services such as a call / communication performed using a community service such as the above, a member homepage browsing service owned by the member 13, various registration related services, and a group service are conceivable. Here, calls / communications made using group services mean calls / communications between users belonging to the same group, and a separate fee structure (discounts for charges) from normal calls / communications. To set a fixed amount, exempt, etc.). In addition to the group service, various information services and the like can be provided to 12 users.

To supplement the explanation, the “community service” is a service using a tool that supports communication between users belonging to the community (group), and the tool refers to all programs or computers that can be used on the computer. Software, specifically, an electronic conference room, an electronic bulletin board, a chat room, and a mailing list.
In this embodiment, in addition to “community services”, all services provided to groups and users belonging to the group, including various registration services and discount services, are collectively referred to as “group services”. "

[1.2.2. Organizer 11 <=> Member 13]
[1.2.2.1. Marketing information 16a (host 11 => member 12)]
The organizer 11 provides marketing information to the member 13 (16a). One of the marketing information is information included in the group information.

As other marketing information, data obtained by processing the transaction record information when the transaction is established between the user 12 and the member 13 (19) so that the specific transaction is not known can be considered. The data can be expected to have utility value as one measure for measuring the activity status of the group 1A. As a processing method, for example, various methods such as calculating the average transaction amount per month from the accumulated transaction amount in the past year and setting ranks A to E in descending order of the amount can be considered.
In addition, it can be expected that the use frequency of the group service is calculated based on the communication data amount, the call time, and the like, and is provided in the same manner as the marketing information.
Furthermore, a homepage (hereinafter referred to as “HP”) and a blog rental server service are provided to Group 1A (it can also be free of charge), and HP and a blog are created. Public disclosure is also useful as marketing information.

In addition, the organizer 11 can collect a usage fee for the marketing information from the member 13 as a reward provided by the marketing information (17a).

The method for providing marketing information may be performed via a communication network, or may be a method not via a communication network such as mailing of printed matter. As a method performed via a communication network, for example, a search condition is input from a terminal owned by the member 13, marketing information that matches the search condition is extracted by a community server (or database server), and the extracted marketing information is extracted. Can be considered a method such as a marketing database search service that returns a message to a terminal owned by the member 13. In addition to this, a condition is registered in advance, and each time group information is registered / updated by the user 12, a method of distributing information that matches the condition to the member 13, or a group 1A HP or blog A method of publishing can be considered.

[1.2.2.2. Negotiation rights 16b (organizer 11 => member 13)]
The member 13 can acquire the right to negotiate with the user 12 (group 1A) (hereinafter referred to as “negotiation right”) from the organizer 11 by the following two methods (16b).

The first method is a method in which the member 13 selects a group 1A to conduct sales activities based on the marketing information provided by the organizer 11 and the HP and blog of the user 12, and purchases the right to negotiate. is there. At this time, the organizer 11 can collect a negotiation right fee from the member 13 (17a).
The second method is that when the user 12 wants to negotiate by browsing the member's 13 HP, catalog, TV CM, etc., the user 12 can connect to the member 13 via the organizer 11. (14b => 16b).

[1.2.2.3. Various usage fees 17a (Member 13 => Organizer 11)]
On the contrary, the organizer 11 can collect the following various charges from the member 13.
1) Member registration fee 2) Marketing information usage fee 3) Negotiation right fee when selling the negotiation right to the member 13 4) Transaction brokerage fee when a transaction is established between the user 12 and the member 13 (19a) Here, the member registration fee is discounted only when the communication fee of the terminal used by the user 12 is a pay-as-you-go system (such as a mobile phone), and only when the user 12 browses the member's 13 homepage. Or by combining with a fee system such as exemption (free), the merit of the member 13 paying the membership registration fee can be made clearer.

[1.2.3. User 12 (Group 1A) <=> Member 13]
By acquiring the right to negotiate, the member 13 can perform sales activities for the users 12 belonging to the group 1A through community services such as an electronic conference room (electronic bulletin board) and a mailing list (18a). .

Further, if a transaction is established as a result of the sales activity 18a, the goods are delivered from the member 13 to the user 12, and conversely, consideration (money, etc.) is paid from the user 12 to the member 13 (19a). ). At this time, if the organizer 11 gives points or the like to the user 12 or the group 1A according to the transaction amount, the group service for the user 12 or the level of the usage fee (discount rate, etc.) is determined. This can be used as a calculation standard.

The organizer 11 can collect a transaction brokerage fee from the member 13 or the user 12 when the transaction is established (17a).

[1.3. Business cycle]
Next, how the business model circulates and develops will be described. FIG. 2 is a diagram showing that the business develops by circulating each service of the business model.

First, the service level for the user 12 (group 1A) can be improved by using a part of various charges collected from the member 13 as resources for the group service or the like (21).
In addition, the level of service for users 12 (group 1A) is improved, and an increase (22) in the number of users 12 and groups 1A is expected. Can do.

Furthermore, as group information (marketing information, etc.) is enriched (23), an increase (24) of members 13 who are users of the marketing information database is expected, and membership registration fees and marketing information usage collected from members 13 are expected. Fees (DB usage fees), negotiation rights fees, etc. will increase (25).
An increase (22) in the user 12 / group 1A and an increase (24) in the member 13 lead to an increase in transactions (26), and an increase in transaction brokerage fees (27) can be expected.
By using a part of these revenues as a source of service improvement (21) for the user 12 / group 1A, it is possible to create a virtuous cycle in which the business develops.

In addition to the above, as a part of the service improvement (21) for the user 12 / group 1A, a contrivance of a service providing method can be considered. As a specific example, for a user 12 (Group 1A) by using a method of giving points according to the transaction amount, and making a difference in the group service or usage fee discount service according to the accumulated points. It is possible to provide incentives for purchasing. Thereby, the effect of increasing transactions can be expected.

[2. Scope of the system of the present invention]
The system of the present invention has the following mechanism for realizing the business model.

(1) Mechanism for supporting sales activities (hereinafter referred to as “outbound sales”) by approaching the user 12 from the member 13 (hereinafter referred to as “structure A”)
(2) A mechanism for supporting sales activities (hereinafter referred to as “inbound sales”) by approaching the members 13 from the users 12 (hereinafter referred to as “structure B”).

In addition to the above two mechanisms, the system of the present invention may implement the following mechanism in order to expand the service content.
(3) In calls / communications (calls / communications between users belonging to the same group) using group services, a discount system (hereinafter referred to as “mechanism C”) is applied according to the discount rate calculation target points. To do)
(4) A mechanism for user (customer) management (user support) by product user managers, members 13 and the like (hereinafter referred to as “mechanism D”)
(5) A mechanism for creating a contact information list (address book) of the users 12 having a friendship relationship (hereinafter referred to as “Mechanism E”) so that the friendship relationship between the users belonging to the same group can be easily maintained. To do)
(6) A mechanism for calculating a reinvestment amount for reinvesting part of the profit received from the member 13 or the user 12 in the operation of the community service in order to virtuously the business model realized by the system of the present invention. (Hereafter referred to as “Structure F”)

[3. Embodiment of System of Present Invention for Realizing Mechanism A and Mechanism B]
The mechanism A and the mechanism B will be described with reference to FIGS. 3A / B. FIG. 3A / FIG. 3B show the transaction after the user 12 and the member 13 participate in the system for the mechanism A that supports the outbound sales and the mechanism B that supports the inbound sales, respectively. It represents the process (state transition) up to establishment. 3A and 3B are roughly divided into the flow from the time when the user 12 participates in the system of the present invention until the transaction is established on the left side, and the case of the member 13 participating in the system of the right side on the right side. This represents the flow from the establishment of the transaction to the completion of the transaction.

[3.1. Overview of mechanism A and mechanism B]
[3.1.1. About mechanism A]
First, the mechanism A will be described with reference to FIG. 3A.
The user 12 first performs user registration in the system of the present invention (step (hereinafter abbreviated as “S”) S31a).
Next, recruit a fellow from among the users 12 who have completed user registration in the same manner (to be exact, it is possible to recruit a friend even after registering the group 1A), and form the group 1A. The group 1A and the member (user 12) belonging to the group 1A are registered (S31a).

At this time, in addition to group name and member information, marketing information such as hobbies, interests and preferences shared by group members, needs of products and services, formation dates, activity details, etc. are registered, although not essential. It is desirable to keep it. Further, the contents of these information can be changed, added or deleted later.

Although it is not an essential process, at the time of user registration, by automatically registering (group registration at the same time) the group 1A to which only one user belongs and other users cannot belong, Users who do not belong to the group 1A can be eliminated, and individual users can be targeted for sales.

When the registration is completed, the user 12 can use the group service S32a.

At the same time, the member 13 performs member registration (S33a). When the member 13 completes the member registration, the service S34a for acquiring group information can be used. In the mechanism A (FIG. 3A), DB search (marketing database search service) is used. However, the purpose of the service S34a is to cause the member 13 to acquire group information desired by the member 13, and the method is not limited to this. . For example, by registering conditions in advance, each time group information is registered or changed, a method of distributing information that matches the conditions to the member 13, or browsing group 1A's HP or blog to acquire group information, A method of purchasing negotiating rights when you want to conduct sales activities, etc. When the organizer 11 provides the marketing database search service, in S31a, the user 12 has the hobbies, interests and preferences shared by the members of the group, the needs of the products and services, the formation date, and the activity contents. It is necessary to register marketing information such as.

Next, based on the group information acquired in S34a, the member 13 selects the group 1A that wants to conduct sales activities and purchases the right to negotiate (S35a). At this time, the user 12 (group 1A) knows that there is a sales approach from the member 13 by e-mail, a reference screen, or the like (S36a).

Next, the member 13 who has purchased the right to negotiate in S35a negotiates (sales activities) with the user 12 belonging to the group 1A using a group service such as an electronic conference room (S37a). Further, the user 12 (group 1A) who knows that there is a sales approach from the member 13 negotiates with the member 13 using a community service such as an electronic conference room (S37a).

When the negotiation is established, the member 13 receives an order for a product from the user 12, and the transaction is established (S38a).

[3.1.2. About mechanism B]
Next, mechanism B will be described with reference to FIG. 3B.
The user 12 first performs user registration in the system of the present invention (S31b).
Next, in the same way as mechanism A (FIG. 3A), recruiting friends from users who have completed user registration (to be exact, recruiting friends may be after registering group 1A) Then, registration of the group 1A and registration of the member (user 12) belonging to the group 1A is performed in the system of the present invention (S31b).

At this time, unlike the case of mechanism A (FIG. 3A), it is not always necessary to register marketing information such as hobbies, interests and preferences shared by group members, service and product needs, formation dates, and activity contents. Absent.

In addition, as with the mechanism A (FIG. 3A), although it is not an essential process, at the time of user registration, the group 1A to which only one user belongs and other users cannot belong is automatically registered (at the same time member registration) ), It is possible to eliminate users who do not belong to any group 1A, and it is possible to target individual users.

When the registration is completed, the user 12 can use the group service S32b.

At the same time, the member 13 performs member registration (S33b).
When the member 13 completes the membership registration, the product information is sent to the user 1 through the HP (homepage).
(S34b). In mechanism B (FIG. 3B), HP is adopted as a method for disclosing product information, but the method is not limited to this. For example, it may be a product catalog, magazine, TV commercial, or the like. However, in addition to the product information, the user 12 must be able to acquire information that can identify the member, such as a member ID and a member HP URL. For example, in the case of a product catalog or magazine, a QR code (registered trademark) or the like can be used.

On the other hand, when the user 12 wants to obtain some product or service, the user 12 starts collecting information. Then, the website of the member 13 that has been made public is browsed, and the target (interested) product is searched (S35b).

Next, when the target product is found, the user 12 grants a negotiating right to request the member 13 for a proposal (S36b). At this time, at the same time, the member 13 knows from the mail, the reference screen, etc. that the user 12 has requested the proposal and has given the right to negotiate (S37b).

Here, the user 12 does not necessarily need to give the member 13 the right to negotiate and negotiate. If the user 12 finds the target product, the user 12 may order it as it is.

Next, the member 13 who knows that there has been a proposal request from the user 12 (group 1A) uses a community service such as an electronic conference room for the user 12 (group 1A) who has requested the proposal. And negotiate (sales activities) (S38b). Similarly, the user 12 (group 1A) who has given the right to negotiate in S36b negotiates with the member 13 using a group service such as an electronic conference room (S38b).

When the negotiation is established, the member 13 receives an order from the user 12, and the transaction is established (S39b).

[3.2. Hardware configuration example of the system of the present invention]
Next, regarding the mechanism A and the mechanism B, the hardware configuration of the system of the present invention according to the present embodiment will be described. However, the description here also corresponds to mechanism C, mechanism D, mechanism E, and mechanism F. FIG. 4 is a block diagram showing a schematic configuration of the system of the present invention according to the present embodiment.

As shown in the figure, the system of the present invention includes a community server 40 in which various data and processing programs for supporting sales activities are stored in addition to various data and processing programs for providing community services. And a user terminal 50 used by the user 12 and a member terminal 60 used by the member 13. Moreover, you may provide the member (seller) HP server 80 and the user management server 90 as needed. The community server 40, the user terminal 50, the member terminal 60, the member (seller) HP server 80, and the user management server 90 are connected via a communication network 70 typified by the Internet, and the respective communication interfaces. The data can be transmitted and received through each other.

[3.2.1. Community server 40, member (seller) HP server 80, user management server 90]
The community server 40 is a server or an information processing device installed by the organizer of the system of the present invention, and includes a computing device that performs various computations, a data storage unit that stores processing programs, and a database that stores various data (hereinafter referred to as a database). And “DB”). The number of housings is not necessarily one, and a plurality of computers may be combined and realized as a community server group in which processing is distributed. Details of the database and processing (operation) will be described later.

In addition, a web application server may be installed to operate the web application. Web application servers include commercial products and open source products. For example, Tomcat of JakartaProject (http://jakarta.apache.org), which is an open source product, can be used. The Web application server includes an environment for executing Java (registered trademark) servlets and JSPs, and can be used when the Java language is adopted as a development language.

The member (seller) HP server 80 and the user management server 90 that are installed as necessary can have the same specifications as the community server 40.

[3.2.2. User terminal 50, member terminal 60]
The user terminal 50 and the member terminal 60 are prepared for each user 12 and each member 13, respectively. As shown in FIG. 4, the user terminal 50-1, the user terminal 50-2,. .., And a member terminal 60-1, a member terminal 60-2, and so on. Of course, a plurality of users 12 or a plurality of members 13 may use the same terminal. The user terminal 50 and the member terminal 60 may be any information processing apparatus provided with a keyboard and mouse as input means, a display as display means, and an editing function, a calculation function, and a communication function. Things can be used. Specifically, a personal computer, a mobile phone, a PDA (Personal Digital Assistant), or the like can be used. The user terminal 50 and the member terminal 60 access the community server 40 via the communication network 70 and receive data in the server, whereby necessary information is displayed on the display.
Further, when the Java language is adopted as the development language, it is necessary to install a Java virtual machine (Java VM).

[3.2.3. Communication network 70]
The communication network 70 operates so that data can be transmitted / received to / from a target device regardless of whether it is wired or wireless. Specifically, it is the Internet or the like, but may be realized by combining a plurality of communication networks via a gateway.

[3.3. Database configuration example of the system of the present invention]
Next, regarding the mechanism A and the mechanism B, the configuration of the database of the system of the present invention according to the present embodiment will be described. However, the description here also corresponds to mechanism C, mechanism D, mechanism E, and mechanism F. Further, the database is not necessarily stored in the community server 40, and a database server or the like may be separately installed and stored.

[3.3.1. Overview of database configuration of the system of the present invention]
FIG. 5 is a block diagram schematically showing the configuration of the database of the system of the present invention according to this embodiment. As shown in the figure, it is mainly composed of five databases (hereinafter referred to as “DB”), and the following tables are stored in each DB.

The user relation database DB 41 stores information about the user 12 and information about the group 1A to which the user 12 belongs. Specifically, a user information table (hereinafter referred to as “TBL”) 411, group information TBL412, member information TBL413, thread management (for user) TBL414, and group HP content TBL415 are installed. Here, the group information TBL 412 indicates general information TBL related to the group 1A. In the embodiment, group basic information TBL4121 for managing basic information (group name, formation date, manager, etc.) of the group 1A. And anniversary information TBL4122 and proposal request information TBL4123, which are marketing-related information. Of course, marketing-related TBL may be added in order to enrich marketing information. For convenience of explanation, user information TBL411, group information TBL412 (TBL4121, TBL4122, TBL4123) and member information TBL413, which are TBLs related to the user 12, are collectively referred to as user / group / member information TBL410.

The member relation database DB42 stores information on the member 13. Specifically, member information TBL421, member access authority management TBL422, thread management (for members) TBL423, and member HP content TBL424 are installed.

The information about the electronic conference room is stored in the electronic conference room related database DB43. Specifically, a thread management TBL 431 and an electronic conference room TBL 432 are installed.

The transaction relationship database DB 44 stores information related to transactions. Specifically, an order TBL 441, a transaction performance TBL 442, and a product TBL 443 are installed.

The other database DB 45 stores information that is not classified into the above four DBs. Specifically, a call / communication charge calculation result TBL451, a product delivery date management TBL452, a user registration screen TBL453, a profit TBL454, and a reinvestment amount TBL455 are installed.

Next, attributes stored in each TBL will be described.

[3.3.2. User relation database DB41]
[3.3.2.1. User information TBL411]
The user information TBL 411 stores attributes related to the user 12.
Specifically, “User ID”, “Password” for authentication, “Name”, “Postal code”, “Address”, “Phone number”, “Email address”, “Birth date”, “User” Attributes such as “point balance”, “discount rate calculation user points”, “registration date”, “update date”, “deletion flag”, “deletion date”, and the like are stored.

Here, the “user point balance” is a point that the user 12 can use like money at the time of purchase. For example, it is given according to the transaction amount at the time of transaction, or an advertisement email is sent to the member 13. It may be given when it is received from.
Also, “discount rate calculation user points” are points used when determining discount rates for various services, and are calculated from, for example, the total amount of transactions for the previous month.
A plurality of telephone numbers and addresses may be registered.
In addition to this, a “bank account number” as a debit destination for merchandise charges or the like may be stored, and when performing credit card payment, a “credit card number” may be stored.

[3.3.2.2. Group basic information TBL4121]
The group basic information TBL 4121 stores basic attributes related to the group 1A to which the user 12 belongs as a member.
Specifically, “Group ID”, “Group Name”, “Group Type (Group in Friends, Unspecified Number of Groups, Individual User)”, “Date of Formation”, “Content of Activity”, “Administrator's” “User ID”, “HP Address”, “Number of People”, “Group Point Balance”, “Group Point for Discount Rate Calculation”, “Registration Date”, “Update Date”, “Delete Flag”, “Delete Date”, etc. Stores attributes. In addition, as marketing information, "information about the field of interest", "communication volume (calculate the usage volume of emails and electronic conference rooms, and process so that the specific communication volume is not known like ranks A to E" Record) ”,“ call volume (process and record the same amount as communication amount) ”,“ transaction amount (based on transaction amount and record the same processing as communication fee) ” Etc. are also stored.

Here, the number of persons can be derived from member information TBL 413 described later.
“Group point balance” is a point that can be used like money when consulting at the time of purchase in the group 1A. Is given when the member 13 is received from the member 13.
Further, the “group point for discount rate calculation” is a point used when determining a discount rate for usage charges for calls and communications between users 12 belonging to the same group 1A. Calculated from the transaction amount.
The group type is an attribute for managing the type of the group 1A, and is described in parentheses “()”, “group within a group”, “unspecified number of groups”, “individual user”, etc. You can manage the type.

[3.3.2.3. Anniversary information TBL4122]
Anniversary information TBL4122 includes “Group ID”, “Anniversary No”, “Anniversary”, “Subject”, “Content”, “Registration date”, “Update date”, “Delete flag”, “Delete date”, etc. The attributes of are stored.

[3.3.2.4. Proposal request information TBL4123]
The proposal request information TBL 4123 includes “Group ID”, “Proposal Request No”, “Field”, “Subject”, “Content”, “Registration Date”, “Update Date”, “Delete Flag”, “Delete Date”, etc. Stores attributes.

For these marketing information, it is important for the organizer to freely set various attributes to increase the value of the marketing information.

[3.3.2.5. Member information TBL413]
The member information TBL 413 has attributes such as “user ID”, “group ID”, “status (unapproved, approved)”, “registration date”, “update date”, “deletion flag”, “deletion date”, etc. The user information TBL411 and the group basic information TBL4121 are stored. In other words, it has information on which user 12 belongs to which group 1A (becomes a member).

Here, the status is an attribute for managing whether or not member registration is approved by the administrator (user 12) of the group 1A, and is described in parentheses “()”, “unapproved”, The status such as “approved” can be managed (see “member registration (new / deletion) S416” described later).

[3.3.2.6. Thread management (for users) TBL414]
The thread management (for user) TBL 414 is a TBL that manages the reference status of the user 12 with respect to the thread of the electronic conference room in which the user 12 can participate. The “user ID”, “group ID”, “thread ID” ”,“ Referenced opinion No ”,“ registration date ”,“ update date ”,“ deletion flag ”,“ deletion date ”, and the like are stored.

[3.3.2.7. Group HP content TBL415]
The group HP content TBL 415 is a TBL in which user HP and blog content is stored. The “group ID”, “HP (blog) content”, “registration date”, “update date”, “delete flag”, “ Attributes such as “deletion date” are stored.

[3.3.3. Membership database DB42]
[3.3.3.1. Member information TBL421]
The member information TBL 421 stores attributes relating to the member 13.
Specifically, “member ID”, “password” for authentication, “name”, “zip code”, “address”, “phone number”, “mail address”, “HP address”, “order screen address” , “Registration date”, “update date”, “deletion flag”, “deletion date” and other attributes are stored. In addition to this, the “bank account number” as the transfer source of the product fee received from the user 12 when performing the payment agency service, or the member registration fee, database usage fee, negotiation right fee, brokerage fee withdrawal source It may be stored, or when performing credit card payment, a “credit card number” may be stored.

[3.3.3.2. Member access authority management TBL422]
The member access authority management TBL 422 is a TBL used for authority check when the member 13 participates in the group service. The member access authority management TBL 422 has a “member ID” and a “group ID”, and the member 13 and the group 1A (more precisely, the group service). For associating. In addition to this, "advertising right flag" and "negotiation right flag" for managing the types of group services that can participate, "thread ID" of the electronic conference room that can participate, "acquire ad distribution right" Date and time ”,“ expiration date of advertisement distribution right ”,“ date and time when negotiation right was acquired ”,“ expiration date of negotiation right ”,“ generation method (purchase by member 13, grant by user 12) ”, advertisement distribution right "Membership ID" of the purchaser of the customer, "User ID" of the granter of the advertisement distribution right, "Inquiry contents" used in the case of grant by the user 12, "Distribution status (not distributed, distributed) of the advertisement mail By storing attributes such as “completed”, “registration date”, “update date”, “deletion flag”, and “deletion date”, it is possible to limit the scope of rights of the negotiation right.

Here, the generation method is an attribute for managing the method when the member 13 acquires the right to negotiate, and is described in parentheses “()”, “purchase by the member 13”, “user 12”. Can be managed.
The distribution status is an attribute for managing whether or not the member 13 has transmitted the advertisement mail, and states such as “undelivered” and “distributed” described in parentheses “()”. Can manage.

[3.3.3.3. Thread management (for members) TBL423]
The thread management (for member) TBL 423 is a TBL for managing the reference status of the member 13 with respect to the thread of the electronic conference room in which the member 13 can participate. The “member ID”, “group ID”, “thread ID”, “reference” Attributes such as “completed opinion No.”, “registration date”, “update date”, “deletion flag”, and “deletion date” are stored.

[3.3.3.4. Member HP content TBL424]
The member HP content TBL 424 is a TBL in which the content of the member HP is stored, and has attributes such as “member ID”, “HP content”, “registration date”, “update date”, “deletion flag”, “deletion date”, and the like. Stored.

[3.3.4. Electronic meeting room database DB43]
[3.3.4.1. Thread management TBL431]
The thread management TBL 431 is a TBL that manages the state of the writing status and the like of threads in the electronic conference room. The “group ID”, “thread ID”, “thread type (conference room, (contact only) bulletin board)”, “theme” "," Status (Negotiating, Normal) "," Latest Opinion No "," Registration Date "," Update Date "," Delete Flag ", and" Delete Date "attributes are stored.

Here, the thread type is an attribute that manages the type of thread in the electronic conference room, and manages the types such as “meeting room” and “(contact-only) bulletin board” described in parentheses “()”. it can.
The status is an attribute for managing the state of the user 12 with respect to the thread of the electronic conference room, and the states such as “under negotiation” and “normal” described in parentheses “()” can be managed. When the negotiation is in progress, it is determined that the user 12 has an intention to negotiate, and the thread can be used even after the expiration date.

[3.3.4.2. Electronic conference room TBL432]
The electronic conference room TBL 432 is a TBL for storing opinion data of the electronic conference room. “Group ID”, “Thread ID”, “Opinion No”, “User ID of writer or member ID of writer”, “Write” The attributes of “person name”, “date”, “time”, “text”, “deletion flag”, and “deletion date” are stored.

[3.3.5. Transaction relationship database DB44]
[3.3.5.1. Order TBL441]
The order TBL 441 stores information for managing the order of the user 12 when a transaction is established between the user 12 and the member 13.
Specifically, “Order No”, “Order Details No”, “User ID” and “Name” of the merchandise price request destination (buyer, user 12 who pays the merchandise price), and the usage to be the shipping address of the merchandise The community server 40 provides the “user ID”, “name”, “shipping postal code”, “shipping address”, “shipping telephone number”, and community service (electronic conference room, etc.) used for the negotiation. Provided “Group ID” and “Group Name” (corresponding to “Transaction Group Information” in the Claim), “Order Date / Time”, “Product Code”, “Product Name”, “Unit Price”, “Quantity” , “Discount amount”, “amount”, “product delivery status (delivered, not delivered)”, “settlement status (unsettled, settlement completed)”, “member ID” of the member 13 who is the seller of the product to be traded, Ordering party (Profit to enter order contents from the order screen) 'S 12 "user ID"), attributes such as "order cancellation flag""order cancellation date" is stored.

Here, the product delivery status is an attribute for managing whether or not the member 13 has delivered the product to the user 12, and is described in parentheses “()”, “delivered”, “not yet” Can manage status such as “delivery”.
The payment status is an attribute for managing whether or not money has been delivered after the member 13 has delivered the product to the user 12, and is described in parentheses "()". It is possible to manage states such as “unsettled” and “settled”.

[3.3.5.2. Transaction results TBL442]
The transaction performance TBL 442 stores information for managing settlement.
Specifically, “settlement No.”, “order No.”, “order details No.”, “user ID” and “name” of the merchandise price request destination (buyer, user 12 who pays the merchandise price), and negotiation “Group ID” and “Group Name” (corresponding to “Transaction Group Information” in the claims), “Order Date / Time”, “Product” provided by the community server 40 for the community service (electronic conference room, etc.) used “Code”, “Unit Price”, “Quantity”, “Discount”, “Amount”, “Member ID” of the member 13 who is the seller of the merchandise to be traded, “Group ID” of the purchaser's group 1A, the orderer ( Attributes such as “user ID”, “brokerage fee”, “user point”, “group point”, etc. of the user 12) who inputs the order contents from the order screen are stored.

[3.3.5.3. Product TBL443]
The product TBL 443 stores information for managing the product.
Specifically, “product ID”, “product name”, “list price”, “discount amount”, “unit price”, “stock quantity”, “product information (manufacturer ID, user group group ID, user management server 90) , Etc.), “registration date”, “update date”, “deletion flag”, “deletion date”, and the like are stored.

[3.3.6. Other database DB45]
[3.3.6.1. Call / communication charge calculation result TBL451]
The call / communication charge calculation result TBL 451 stores information for managing the call / communication charge calculation result.
Specifically, “call / communication No”, “user ID”, “call / communication charge”, “discount rate”, “discount”, “call / communication charge after discount application”, “date and time”, etc. Stores attributes.

[3.3.6.2. Product delivery date management TBL452]
The product delivery date management TBL 452 stores information for managing the date of delivery of the product.
Specifically, “user ID of recipient (owner)”, “product ID”, “product name”, “product delivery date”, “manufacturer name”, “URL of manufacturer user management server” “registration” Attributes such as “member ID”, “registration date”, “update date”, “deletion flag”, and “deletion date” are stored.

[3.3.6.3. User registration screen TBL453]
The user registration screen TBL453 stores user registration screen data.
Specifically, attributes such as “product ID”, “user registration screen image data”, “registration date”, “update date”, “deletion flag”, and “deletion date” are stored.

[3.3.6.4. Revenue TBL454]
The revenue TBL 454 stores information about revenue such as a usage fee collected from the member 13 or the user 12.
Specifically, “revenue No”, “member ID or user ID of revenue generation source”, “revenue type (member registration fee, marketing information usage fee, negotiation right fee, transaction brokerage fee)”, “amount” , Attributes such as “date and time” are stored.

Here, the revenue type is an attribute for managing the type of revenue, and is described in parentheses “()”, “member registration fee”, “marketing information usage fee”, “negotiation right fee”. , “Trade brokerage fee” status can be managed.

[3.3.6.5. Reinvestment amount TBL455]
The reinvestment amount TBL455 stores the reinvestment amount calculation result.
Specifically, attributes such as “reinvestment amount calculation No.”, “calculation period (date to date)”, “reinvestment amount”, and “calculation date” are stored.

[3.4. Example of operation of the system of the present invention]
Next, regarding the mechanism A and the mechanism B, the operation of the system of the present invention according to the present embodiment will be described. FIG. 6 is a data flow diagram (hereinafter referred to as “DFD”) of an embodiment of the system of the present invention, and represents the overall operation related to mechanism A and mechanism B. The system of the present invention has processes of various user-related registrations S41, member-related various registrations S42, member access authority generation S43, advertisement distribution S44, negotiation S45, order S46, and delivery settlement S47 as main processes. Here, the advertisement distribution S44 is not an essential process, and does not appear particularly in the description of FIG. 3A / FIG. 3B.
First, an overview of the operations related to mechanism A and mechanism B will be described with reference to FIG.

First, in various user-related registrations S41, the user 12 performs user registration using the user terminal 50, and then recruits other users who have completed user registration in the same manner (to be exact, The group may be recruited after registering the group 1A), the group is formed, the group registration and registration of the member who is the user 12 belonging to the group 1A, and the user / group / member information TBL410 ( TBL411, TBL412, TBL413). At this time, in addition to the basic information of the user 12, marketing information related to the group 1A can also be registered.

At this point, the users 12 belonging to the group 1A can use the group services (including the community service) provided to the group 1A.

At the same time, in various member-related registrations S <b> 42, the member 13 performs member registration using the member terminal 60 and records it in the member information TBL 421.

Next, in the member access authority generation S43, the member 13 has the authority to perform sales activities on the group 1A by purchasing the advertisement distribution right or by the user 12 granting the advertisement distribution right. Generate and record in member access authority management TBL 422. In the embodiment, by providing an authority management TBL dedicated to the member 13 called the member access authority management TBL 422, it is possible to record in a state where the authority of the member 13 can be identified.

Next, in the advertisement distribution S44, the member 13 edits the advertisement using the member terminal 60, and transmits the advertisement to the users 12 who are members of the group 1A. At this time, referring to the member access authority management TBL 422, transmission is possible only when there is an advertisement distribution right. Further, after the advertisement is transmitted, it is recorded that the advertisement is distributed to the member access authority management TBL 422, and at the same time, a new negotiation right is recorded. At this time, an electronic conference room thread may be installed at the same time.

In the advertisement distribution S44, when the user 12 sees the advertisement received from the member 13 and decides to purchase a product or service provided by the member 13, the user 12 may directly transit to the order S46.
Here, this advertisement distribution S44 is not an essential process. When the advertisement distribution S44 is omitted, the negotiation access right may be generated without generating the advertisement distribution right in the member access authority generation S43.

Next, in negotiation S45, the user 12 and the member 13 negotiate with each other using the user terminal 50 and the member terminal 60, respectively. Specifically, community services such as an electronic conference room (electronic bulletin board) and a mailing list are used. At this time, the user 12 permits access to the community service based on the user / group / member information TBL410 (TBL411, TBL412, TBL413). Further, the member 13 permits access to the community service based on the member access authority management TBL422.

Next, as a result of the negotiation, when the user 12 decides to purchase a product or service provided by the member 13, the process proceeds to the order S46.

Next, in order S <b> 46, the user 12 inputs an order using the user terminal 50 and records it in the order TBL 441.

Finally, in delivery settlement S47, delivery settlement processing is performed based on the order TBL441 and recorded in the transaction result TBL442.

Here, in FIG. 6, the purpose is to represent the overall image of the operation to the last, and therefore, not all TBLs are described, but only the TBLs that are points are described.
Hereinafter, the seven processes from the various user-related registrations S41 to the delivery settlement S47 will be described in order.

[3.4.1. Various user-related registrations S41]
The various user-related registration S41 is a process for the purpose of performing various user-related registrations. FIG. 7 is an expanded view of the various user-related registrations S41 of FIG. 6. In this embodiment, the various user-related registrations S41 include user registration (new) S411, user registration (change / delete) S412, Group registration (new / change / delete) S413, marketing information registration (anniversary) S414, marketing information registration (suggestion request) S415, member registration (new / delete) S416, thread registration (new / change / delete) S417 It consists of two processes. In FIG. 7, the various user-related registrations S <b> 41 are configured by seven processes, but a process for enhancing marketing information may be added to the various user-related registrations S <b> 41. Hereinafter, the seven processes will be described in order.

[3.4.1.1. User registration (new) S411]
User registration (new) S411 is a process for the purpose of allowing the user 12 to input information related to himself / herself and register as a user in this business model.

In terms of the system, a process of newly recording information on the user 12 itself edited / input by the user 12 (to be exact, not yet a user at this time) in the user information TBL 411 is performed. More specifically, the user registration (new) S411 can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the user registration (new) S411 will be described with reference to FIG.

When user registration (new) S411 is started, first, in S4111, the community server 40 displays a user registration screen on the user terminal 50 (<1>). It should be noted that “round numbers (symbols in which numbers are circled)” used in the drawings are displayed by enclosing numbers in “<>” in the specification. FIG. 9 shows an example of a user registration screen displayed on the user terminal 50.

The user 12 edits and inputs information about himself / herself through the screen (FIG. 9) displayed on the user terminal 50, and presses the [Register] button (<2>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after checking the validity of the format and value of the received input information, the community server 40 transitions the execution process to S4112. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4112, the community server 40 refers to the user information TBL411, automatically acquires a vacant number of the user ID, sets this as the user ID, and further automatically generates a password. The user information TBL 411 is recorded together with the received information. The password may be automatically generated at this stage. In this case, it is desirable for the user 12 to change the password at the first login.

In addition, although it is not an essential process of S4112, in the embodiment, in addition to this, when registering a user, only one user belongs and a group 1A to which other users cannot belong is automatically registered ( It is a specification to register as a member at the same time. As described above, this is a process for preventing the user from belonging to any group 1A and adding the individual user to the sales target.

In order to realize the specification, in step S4112, in addition to recording in the user information TBL 411, a new group 1 A is recorded in the group basic information TBL 4121. Here, as with the user ID, the vacant number may be automatically acquired with reference to the group basic information TBL 4121 as in the case of the user ID. However, a number associated with the user ID may be used as the group ID (for example, use If the person ID is “R00001”, the group ID is “G00001”). As the group name, the user name can be used as it is. As the group type, “user individual” is set. Other attributes may be acquired from the input information or may be temporarily set as a NULL value and input separately from a registration screen related to group information. In the member information TBL 413, the automatically acquired user ID and group ID are recorded ("Approved" is set in the attribute of "Status").

Finally, in S4112, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<3>). FIG. 10 is an example of a registration completion message screen. The automatically acquired user ID, group ID, and password are displayed. If you click the [OK] button here, you may log in immediately.

After completing the user registration (new) S411, the user 12 can log in to the system of the present invention at any time. FIG. 11 is a DFD showing an example of login processing (user login S48) that can be used by completing user registration (new) S411. Hereinafter, an example of the user login S48 will be described with reference to FIG.

When the user login S48 is started, first, in S481, the community server 40 displays a login screen on the user terminal 50 (<1>). FIG. 12 is an example of a login screen displayed on the user terminal 50. The user 12 inputs login information (user ID, password) through the screen (FIG. 12) displayed on the user terminal 50 and presses the [Login] button (<2>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 refers to the password recorded in the user information TBL 411 using the received user ID, and collates it with the received password. If they match, the login authentication has succeeded, and the community server 40 performs processing so that the terminal can be specified. Specifically, for example, when a WEB browser is used for the terminal, the community server 40 issues a session ID (information for specifying the terminal) and transmits it to the user terminal 50. The user terminal 50 stores the session ID using a mechanism called a cookie. At the same time, the community server 40 secures a session scope (a storage area allocated to each terminal) in association with the session ID, and stores basic information such as a user ID and a user name. Next, the community server 40 transitions the execution process to S482.

In S482, the community server 40 displays a menu screen on the user terminal 50 (<3>). FIG. 13 shows an example of a menu screen.

When the user 12 finishes the user login S48, the user 12 can use services for users that require user login authentication (for example, group services such as “electronic conference room” and “shopping mall”).

In addition, the user login authentication S481 is not limited to the password authentication method as described above. It is also possible to use a biometrics (biological) authentication method or the like.

[3.4.1.2. User registration (change / delete) S412]
User registration (change / deletion) S412 is a process aimed at deleting the user information when the user 12 changes the user information or leaves the business model. is there.

In terms of the system, the user 12 obtains the current user registration information through the user terminal 50, corrects it, and updates or deletes the corresponding record such as the user information TBL411. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of user registration (change / deletion) S412 will be described with reference to FIG.

In S48, the user 12 logs in to the system of the present invention (<1>) and presses a [user registration (change / delete)] button (<2>) on the user menu screen (FIG. 13). The community server 40 transitions the execution process to S4121. Next, in S411, the community server 40 acquires the current registration information from the user information TBL411, and displays the editing screen on the user terminal 50 (<3>). FIG. 15 is an example of an edit screen (user registration (change / delete) screen).

In the case of changing, in S411, the user 12 modifies and edits information related to himself (user 12) through the screen (FIG. 15) displayed on the user terminal 50, and presses the [Register] button ( <4>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, the community server 40 transitions the execution process to S4122. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S412, the community server 40 updates the user information TBL411 based on the received information.
At the same time, if there is a change that affects the group basic information TBL 4121, such as when the group type = “user individual”, etc., this is also updated (in the embodiment, the user personal The group 1A is registered, and at this time, the group information may be set using the user information (for example, the user name is used as the group name).

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays the registration completion message on the screen of the user terminal 50 (<5>). In this specification, the screen example of the registration completion message is omitted, but the screen example shown in FIG. 10 can be referred to.

In the case of deletion, in S411, the user 12 checks the [Delete] check box on the edit screen (FIG. 15) and presses the [Register] button (<4>). The community server 40 that has received the deletion information refers to the order TBL 441, refers to the fact that there is no order that has not been settled, and refers to the group basic information TBL 4121, and the user 12 to be deleted becomes an administrator. It is confirmed that there is no group 1A, and if there is no problem, the execution process proceeds to S4122. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S412, the community server 40 updates the deletion flag to ON for all the records on the TBL that are affected by the deletion of the user registration, and records the deletion date. Specifically, user information TBL411, group information TBL412 (TBL4121, TBL4122, TBL4123), member information TBL413, thread management (for users) TBL414, group HP content TBL415, member access authority management TBL422, Thread management (for members) TBL 423, thread management TBL 431, electronic conference room TBL 432, and the like. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message (more precisely, a deletion completion message) is displayed on the screen of the user terminal 50 (<5>).

Further, in FIG. 15, a [change password] button is prepared. When this button is pressed, the password change (for user) screen of FIG. 16 is displayed on the user terminal 50, and this is used. You can change your password.

Among the functions of this user registration (change / deletion) S412, it is desirable to manage the authority so that only the 12 users can perform the deletion function.

[3.4.1.3. Group registration (new / change / delete) S413]
Group registration (new / change / deletion) S413 is to register the user 12 who has completed user registration (new) S411 and forms the group 1A in the system of the present invention. It is a process aimed at. It is also used for changing the registered group information and deleting the group information when the group 1A is dissolved.

Systemically, the user 12 inputs / transmits group information related to the group 1A formed through the user terminal 50 to the community server 40, and is newly recorded, updated, or deleted in the group basic information TBL4121. Perform the process. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of group registration (new / change / delete) S413 will be described with reference to FIG.

In S48, the user 12 logs into the system of the present invention (<1>) and presses the [Group Registration (New / Change / Delete)] button (<2>) on the user menu screen (FIG. 13). The community server 40 transitions the execution process to S4131, and displays the editing screen on the user terminal 50 (<3>). FIG. 18 is an example of an edit screen (group registration (new / change / delete) screen).

In the screen example shown in FIG. 18, the “Group ID” list box can select “New” and the group 1 </ b> A to which the registrant belongs. That is, when displaying, a list (group ID, group name) of the group 1A to which the registrant belongs is derived from the group basic information TBL 4121 and member information TBL 413, and loaded into the [Group ID] list box.

Similarly, in the screen example shown in FIG. 18, the “group type” list box can be selected from two types of “groups within a group and a large number of unspecified groups”. Here, when the user group 1A is selected in the [Group ID] list box, the group type = “user individual” is displayed, but it cannot be changed to another group type. By the way, in this embodiment, this group type = "user individual" registration is automatically registered only at the time of user registration, and cannot be registered or changed on this screen. The specification is not possible.

Similarly, in the screen example shown in FIG. 18, the [Manager] list box can select members belonging to the group 1A. That is,
When the [Group ID] list box is selected and the [Get Registration Information] button is pressed, a list of members (user ID, user name) belonging to the group 1A is derived from the user information TBL411 and member information TBL413. , Load this into the [Administrator] list box.

In the case of newly registering, in S4131, the user 12 selects “New” in the [Group ID] list box on the editing screen (FIG. 18), and then inputs other items.
At this time, only the registrant himself / herself has confirmed the members in the [Administrator] list box, so that only the registrant himself can select. When editing / input is completed, the [Register] button on the editing screen (FIG. 18) is pressed (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4132. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4132, the community server 40 refers to the group basic information TBL4121, acquires the vacant number of the group ID, and records it in the group basic information TBL4121 together with the received information. At the same time, the registrant himself / herself is recorded as a member of the group 1A in the member information TBL 413.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>). FIG. 19 shows an example of a registration completion message screen when a new group is registered. The automatically acquired group ID is displayed.

In the case of changing, in S4131, the user 12 selects the group 1A whose registration information is to be changed in the [Group ID] list box on the editing screen (FIG. 18), and presses the [Get Registration Information] button. Then, the community server 40 acquires the group information of the group 1A from the group basic information TBL 4121 and displays it on each item on the screen. Subsequently, the user 12 inputs and corrects these items.

When the editing is completed, the user 12 presses the [Register] button on the editing screen (FIG. 18) (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4132. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4132, the community server 40 updates the group basic information TBL4121 based on the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>). In this specification, a screen example of a registration completion message at the time of change is omitted, but FIG. 19 can be referred to.

In the case of deleting, in S4131, the user 12 checks the “Delete” check box on the editing screen (FIG. 18) and presses the [Register] button (<4>). In S4132, the community server 40 that received the deletion information updates the deletion flag to ON and records the deletion date for all the records on the TBL that are affected by the deletion of the group 1A. Specifically, group information TBL 412 (TBL 4121, TBL 4122, TBL 4123), member information TBL 413, thread management (for users) TBL 414, group HP content TBL 415, member access authority management TBL 422, thread management (for members) ) TBL 423, thread management TBL 431, electronic conference room TBL 432, and the like. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message is displayed on the screen of the user terminal 50 (<5>).

Of the functions of this group registration process (new / change / delete) S413, it is desirable to manage the authority especially so that only the administrator of the group 1A can perform the delete function.

[3.4.1.4. Marketing Information Registration (Anniversary) S414]
Marketing information registration (anniversary) S414 is a process for the user 12 to register the anniversary information as marketing information of the group 1A in the system of the present invention. It is also used when the registered anniversary information is changed or deleted.

Systemically, the user 12 inputs the anniversary information of the group 1A through the user terminal 50, and performs a process of newly recording, updating, or deleting the anniversary date information TBL4122. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of marketing information registration (anniversary) S414 will be described with reference to FIG.

In S48, the user 12 logs in to the system of the present invention (<1>) and presses the [Marketing information registration (anniversary)] button (<2>) on the user menu screen (FIG. 13). The server 40 transitions the execution process to S4141. Next, in S4141, the community server 40 acquires the current registration information from the anniversary information TBL4122, and displays the editing screen on the user terminal 50 (<3>). FIG. 21 is an example of an editing screen (marketing information registration (anniversary) screen).

In the screen example shown in FIG. 21, in the [Group ID] list box, it is possible to select the group 1A to which the registrant belongs. That is, when displaying, a list (group ID, group name) of the group 1A to which the registrant belongs is derived from the group basic information TBL 4121 and member information TBL 413, and loaded into the [Group ID] list box.

Similarly, in the screen example shown in FIG. 21, in the [anniversary No.] list box, “new” and the number of the anniversary information already registered in the group 1A selected in the [group ID] list box (anniversary No. ) Can be selected. That is, when the target group 1A is selected in the [Group ID] list box and the [Registered information acquisition] button is pressed, a list of registered anniversary information of the selected group 1A (anniversary No. is selected from the anniversary information TBL4122. , Subject) and load it in the [Anniversary No] list box.

When newly registering the anniversary information, in S4141, the user 12 selects the target group 1A in the [Group ID] list box on the editing screen (FIG. 21), and then selects the [Anniversary No] list box. Select “New”, press the [Register Information] button to reset the display contents, and then enter other items.

When the editing is completed, the user 12 presses the [Register] button on the editing screen (FIG. 21) (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after checking the validity of the format and value for the received input information, the community server 40 transitions the execution process to S4142. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4142, the community server 40 refers to the anniversary information TBL4122, acquires the vacant number of the anniversary No, and records it in the anniversary information TBL4122 together with the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

When changing the anniversary information, in S4141, the user 12 selects the target group 1A in the [Group ID] list box on the editing screen (FIG. 21), and then presses the [Register Information] button. , Update the display contents ([Anniversary No] list box). In the [Anniversary No.] list box, select the anniversary No. to be changed, and press the [Register Information] button again to update the display contents. At this time, the anniversary information is acquired from the anniversary information TBL 4122 and the display content is updated. Next, input the other items.

When the editing is completed, the user 12 presses the [Register] button on the editing screen (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after checking the validity of the format and value for the received input information, the community server 40 transitions the execution process to S4142. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4142, the community server 40 updates the anniversary information TBL4122 based on the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

When deleting the anniversary information, in S4141, the user 12 selects the anniversary information to be deleted from the “Group ID” list box and the [Anniversary No] list box on the editing screen (FIG. 21). Then, the “Delete” check box is checked and the [Register] button is pressed (<4>). In S4142, the community server 40 that received the deletion information updates the deletion flag of the related record on the anniversary information TBL4122 to ON, and records the deletion date. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message is displayed on the screen of the user terminal 50 (<5>).

[3.4.1.5. Marketing information registration (request for proposal) S415]
Marketing information registration (proposal request) S415 is a process for the purpose of the user 12 registering proposal request information as marketing information of the group 1A in the system of the present invention. It is also used when changing or deleting registered proposal request information.

Systemically, the user 12 inputs the proposal request information of the group 1A through the user terminal 50, and performs a process of newly recording, updating, or deleting the proposal request information TBL4123. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of marketing information registration (proposal request) S415 will be described with reference to FIG.

In S48, the user 12 logs into the system of the present invention (<1>) and presses the [Marketing information registration (request for proposal)] button (<2>) on the user menu screen (FIG. 13). The server 40 transitions the execution process to S4151. Next, in S4151, the community server 40 acquires the current registration information from the proposal request information TBL 4123, and displays an edit screen on the user terminal 50 (<3>). FIG. 23 shows an example of an edit screen (marketing information registration (request for proposal) screen).

In the screen example shown in FIG. 23, in the [Group ID] list box, it is possible to select the group 1A to which the registrant belongs. That is, when displaying, a list (group ID, group name) of the group 1A to which the registrant belongs is derived from the group basic information TBL 4121 and member information TBL 413, and loaded into the [Group ID] list box.

Similarly, in the screen example shown in FIG. 23, in the [Proposal Request No.] list box, “New” and the number of proposal request information already registered in the group 1A selected in the [Group ID] list box (Proposal Request No. ) Can be selected. That is, when the [Group ID] list box is selected and the [Registered information acquisition] button is pressed, a list of proposal request information registered for the selected group 1A (suggestion request No, subject) is selected from the proposal request information TBL4123. Acquire it and load it in the [Request No.] list box.

In the case of newly registering proposal request information, in S4151, the user 12 selects the target group 1A in the [Group ID] list box on the editing screen (FIG. 23), and then in the [Proposal Request No] list box. Select “New”, press the [Register Information] button to reset the display contents, and then enter other items.

When the editing / input is completed, the user 12 presses the [Register] button on the editing screen (FIG. 23) (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, the community server 40 transitions the execution process to S4152. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4152, the community server 40 refers to the proposal request information TBL4123, acquires the vacant number of the proposal request No, and records it in the proposal request information TBL4123 together with the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

When changing the proposal request information, in step S4151, the user 12 selects the target group 1A in the [Group ID] list box on the editing screen (FIG. 23), and then presses the [Registered Information] button. , Update the display content ([Proposal Request No] list box). In the [Proposal Request No.] list box, select the proposal request No. to be changed, and press the [Register Information] button to update the display contents. At this time, the proposal request information is acquired from the proposal request information TBL 4123 and the display content is updated. Next, input the other items.

When editing is completed, the [Register] button on the editing screen (FIG. 23) is pressed (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, the community server 40 transitions the execution process to S4152. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.
Next, in S4152, the community server 40 updates the proposal request information TBL4123 based on the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

When deleting the proposal request information, in S4151, the user 12 selects the proposal request information to be deleted from the “Group ID” list box and the [Request No.] list box on the editing screen (FIG. 23). Then, the “Delete” check box is checked and the [Register] button is pressed (<4>). In S4152, the community server 40 that has received the deletion information updates the deletion flag of the related record on the proposal request information TBL4123 to ON, and records the deletion date. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message is displayed on the screen of the user terminal 50 (<5>).

[3.4.1.6. Member registration (new / deletion) S416]
Member registration (new / deletion) S416 is a process for registering the user 12 as a member in order to make the user 12 belong to the group 1A. It is also used when deleting registrations.
There are two methods for registering the user 12 as a member in the group 1A. One is a method in which the user 12 who wants to participate in the group 1A informs the manager of the group 1A (user '(buyer) 12) that he / she wants to participate, and the administrator approves this. The other is a method in which an administrator (user '(buyer) 12) invites the user 12 to join the group 1A, and the user 12 responds accordingly. Regardless of which approach is used, both methods require the consent of both the user 12 and the administrator. In the embodiment, the former method is adopted.

FIG. 24 is a DFD showing a specific example of member registration (new / deletion) S416. In this example, member registration (new / deletion) S416 includes a member registration application S4161 process and a member approval S4162 process. Which indicates that.

The system processing is as follows. In S4161, if the user 12 who wishes to participate in the group 1A as a member makes a member registration application through the user terminal 50-1, the community server 40 records this in the member information TBL 413 in an unapproved state. . In S4162, the user's (buyer) 12 as the manager of the group 1A acquires information on the member registration application for the group 1A that he / she serves as the administrator through the user 'terminal 50-2 and approves them. Then, the community server 40 updates the corresponding information on the member information TBL 413 to approved. More specifically, it can be realized by a processing flow as shown in the DFDs of FIGS.

Hereinafter, an example of the member registration application S4161 process and the member approval S4162 process will be described with reference to FIGS. 25 and 27. FIG.

[3.4.4.1. Member registration application S4161]
First, the member registration application S4161 will be described with reference to FIG. FIG. 25 is a data flow diagram showing an example of member registration application S4161.

In S48, the user 12 logs in to the system of the present invention (<1>) and presses a [member registration application (new / delete)] button (<2>) on the user menu screen (FIG. 13). The community server 40 transitions the execution process to S41611 and displays the editing screen on the user terminal 50-1 (<3>). FIG. 26 is an example of an edit screen (member registration application (new / delete) screen).

In the screen example shown in FIG. 26, “New” or the group 1A to which the registrant belongs can be selected in the [Group ID] list box. That is, when the screen is displayed, a list (group ID, group name) of the group 1A to which it belongs is derived from the group basic information TBL 4121 and member information TBL 413, and loaded into the [Group ID] list box.

To newly register a member, select “New” in the [Group ID] list box, and then enter the group ID of the group 1A that you want to join. When the editing / input is completed, the user 12 presses the [Register] button on the editing screen (FIG. 26) (<4>). Then, input information is transmitted from the user terminal 50-1 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, confirms that the group ID desired to participate exists on the group basic information TBL4121, and further, on the member information TBL413. If there is no problem after confirming that the same registration does not already exist, the execution process transitions to S41612. If there is a problem, an error message is returned to the user terminal 50-1 to prompt correct input.

Next, in S41612, the community server 40 records the received information in the member information TBL412. At this time, the attribute of “status” is set to “unapproved”.

Finally, the community server 40 transmits a registration completion message to the user terminal 50-1, and displays it on the screen (<5>).

When deleting the member registration, in S41611, the user 12 selects the group 1A that he / she wants to leave (ie, deletes the member registration) in the [Group ID] list box, and checks the “Delete” check box to edit it. Press the [Register] button on the screen (FIG. 26) (<4>). In S41612, the community server 40 that has received the deletion information updates the deletion flag to ON and records the deletion date for all the records on the TBL that are affected by the deletion of the member registration. Specifically, member information TBL 413, thread management (for user) TBL 414, and the like. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message is displayed on the screen of the user terminal 50-1 (<5>).

[3.4.4.1.2. Member approval S4162]
Next, member approval S4162 will be described with reference to FIG. FIG. 27 is a data flow diagram showing an example of member approval S4162.

In S48, the user '12 as the manager of the group 1A logs in to the system of the present invention (<1>), and presses the [Member approval] button on the user menu screen (FIG. 13) (<2>). Then, the community server 40 transitions the execution process to S41621 and displays the editing screen on the user's terminal 50-2 (<3>). FIG. 28 is an example of an edit screen (member approval screen).

When approving, the user '12 presses the [Unapproved List] button on the edit screen (FIG. 28) in S41621, the community server 40 causes the user information TBL411, group basic information TBL4121, and member information TBL413. The list of unapproved member registration applicants for the group 1A in which the user '12 is an administrator is extracted from the list, and the list is displayed on the user 'terminal 50-2. Next, the user '12 inputs a check into the check box of the member registration applicant to be approved, and presses the [Approve] button on the edit screen (FIG. 28) (<4>). Then, the input information is transmitted from the user 'terminal 50-2 to the community server 40. The community server 40 that has received the input information transitions the execution process to S41622.

Next, in S41622, the community server 40 updates the “status” attribute of the corresponding record on the member information TBL 413 from “unapproved” to “approved”. At the same time, the community server 40 registers the thread of the electronic conference room of the group 1A in which the user 12 can newly participate by being approved in the thread management (for user) TBL 414. At this time, the “referenced opinion No” attribute is “0 (unread)”.

Finally, the community server 40 transmits an approval completion message to the user 'terminal 50-2 and displays it on the screen (<5>).

When returning to the unapproved state due to an approval error or the like, when the user '12 presses the [Approved List] button on the editing screen shown in FIG. 28, the community server 40 causes the user information TBL411 and the group basic information TBL4121. The list of approved members of the group 1A in which the user '12 is an administrator is extracted from the member information TBL 413 and displayed on the user 'terminal 50-2. Next, a check is input to the check box of the member whose approval is to be canceled, and the [Approval Cancel] button on the edit screen (FIG. 28) is pressed (<4>). Then, the input information is transmitted from the user 'terminal 50-2 to the community server 40. The community server 40 that has received the input information transitions the execution process to S41622.

Next, in S41622, the community server 40 updates the “status” attribute of the corresponding record on the member information TBL 413 from “approved” to “unapproved”. At the same time, the community server 40 updates the deletion flag of the thread of the group 1A whose approval is canceled on the thread management (for user) TBL 414, and records the deletion date. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, the community server 40 transmits an approval completion message to the user 'terminal 50-2 and displays it on the screen (<5>).

In addition to this, it is preferable that the specification is such that the user '12 as an administrator cannot be unapproved.

In this embodiment, the specification is approved by the group manager for the purpose of preventing group participation by an unspecified number of users 12. However, when the participation of an unspecified number of users is permitted, the process S4162 is eliminated. Alternatively, it may be automatically approved when a registration application is made.

[3.4.1.7. Thread registration (new / change / delete) S417]
Thread registration (new / change / deletion) S417 is a process for the user 12 to register a thread (theme, agenda) in the electronic conference room of the group 1A. It is also used when the registration information of a registered thread is changed or deleted.

In terms of the system, the user 12 inputs thread information of a newly installed electronic conference room through the user terminal 50 and records the information in the thread management TBL 431, the electronic conference room TBL 432, and the thread management (for user) TBL 414. Process. More specifically, the thread registration (new / change / delete) S417 can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of thread registration (new / change / delete) S417 will be described with reference to FIG.

In S48, the user 12 logs in to the system of the present invention (<1>) and presses the [Thread Registration (New / Change / Delete)] button (<2>) on the user menu screen (FIG. 13). The community server 40 transitions the execution process to S4171, and displays an edit screen on the user terminal 50 (<3>). FIG. 30 is an example of an edit screen (thread registration (new / change / delete) screen).

In the screen example shown in FIG. 30, in the [Group ID] list box, it is possible to select the group 1A to which the registrant belongs. That is, when displaying, a list (group ID, group name) of the group 1A to which the registrant belongs is derived from the group basic information TBL 4121 and member information TBL 413, and loaded into the [Group ID] list box.

Similarly, in the screen example shown in FIG. 30, in the [Thread ID] list box, it is possible to select “new” and the already registered thread ID of the group 1A selected in the [Group ID] list box. That is, when the [Group ID] list box is selected and the [Registered Information] button is pressed, the registered thread of the selected group 1A is selected from the thread management (for user) TBL 414 (or thread management TBL 431). (Thread ID, theme) is acquired and loaded into the [Thread ID] list box.

Similarly, in the screen example shown in FIG. 30, “conference room, (contact-only) bulletin board” or the like can be selected as the thread type. For example, when “(Contact Only) Bulletin Board” is selected, the writing is restricted so that only the user 12 (for example, the thread manager) who makes contact can write.

When registering a new thread, the user 12 selects the target group 1A in the [Group ID] list box in the edit screen (FIG. 30), and then selects “New” in the [Thread ID] list box. Press the [Register Information] button to reset the display contents, and then enter other items.

When the editing is completed, the user 12 presses the [Register] button on the editing screen (FIG. 30) (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4172. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4172, the community server 40 refers to the thread management TBL 431 to acquire the thread ID free number, and together with the received information, the thread management TBL 431, the electronic conference room TBL 432, and thread management (for users). Record in TBL 414. Here, the thread management (for user) TBL 414 needs to record all members belonging to the selected group 1A.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays the registration completion message on the screen of the user terminal 50 (<5>).

When changing the thread information, the user 12 who wishes to change selects the target group 1A in the [Group ID] list box on the editing screen (FIG. 30), and then presses the [Register Information] button. The display contents ([Thread ID] list box) are updated. In the [Thread ID] list box, select the thread ID to be changed, and press the [Register Information] button to update the display contents. At this time, the community server 40 acquires thread information from the thread management TBL 431 and updates the display content of the user terminal 50. Next, input the other items.

When the editing is completed, the user 12 presses the [Register] button in the editing screen (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4172. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4172, the community server 40 updates the thread management TBL 431 based on the received information.

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

When deleting a thread, in S4171, the user 12 selects a thread ID to be deleted from the “group ID” list box and the [thread ID] list box on the editing screen (FIG. 30), and “delete”. Check the check box and press the [Register] button (<4>). In S4172, the community server 40 that has received the deletion information updates the deletion flag to ON and records the deletion date for all the records on the TBL that are affected by the deletion of the thread. Specifically, thread management TBL 431, electronic conference room TBL 432, thread management (for user) TBL 414, and the like. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

Finally, a registration completion message is displayed on the screen of the user terminal 50 (<5>).

Above, description of an example of various user-related registration S41 is complete | finished.

[3.4.2. Membership registration S42]
Next, returning to FIG. 6, the member relationship registration S42, which is one of the main operations of the system of the present invention, will be described.
The various member relationship registration S42 is a process for the purpose of performing various member relationship registrations. FIG. 31 is an expanded view of the various member-related registrations S42 of FIG. Hereinafter, the two processes will be described in order.

[3.4.2.1. Member registration (new) S421]
Member registration (new) S421 is a process in which the member 13 inputs information about himself and registers as a member in this business model.

In terms of the system, the member 13 (to be exact, it is not yet a member at this time) edits and inputs information about itself through the member terminal 60, and newly records it in the member information TBL421. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the member registration (new) S421 will be described with reference to FIG.

When the member registration (new) S421 is started, first, in S4211, the community server 40 displays a member registration screen on the member terminal 60 (<1>). FIG. 33 shows an example of a member registration screen displayed on the member terminal 60.

The member 13 edits and inputs information about himself / herself through the screen (FIG. 33) displayed on the member terminal 60, and presses the [Register] button (<2>). Then, the input information is transmitted from the member terminal 60 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, the community server 40 transitions the execution process to S4212. If there is a problem, an error message is returned to the member terminal 60 to prompt correct input.

Next, in S4212, the community server 40 refers to the member information TBL421, obtains a member ID vacant number, sets this as a member ID, and at the same time, further generates a password automatically, together with the received information. To the member information TBL421. In addition, the password may be automatically generated at this stage. In this case, the member 13 preferably changes the password at the first login.

Finally, in S4212, the community server 40 transmits a registration completion message to the member terminal 60 and displays it on the screen (<3>). FIG. 34 is an example of a registration completion message screen. The automatically acquired member ID and password are displayed. If you click the [OK] button here, you may log in immediately.

In addition, it is better not to input the bank account number used for collecting the marketing information usage fee and the like and the bank account number used for the payment of the merchandise when the payment is made from the screen of FIG. It is preferable to separately receive a paper application form (registration required stamp, etc.) by mail and register it on the organizer side.

When the member 13 completes the member registration (new) S421, the member 13 can log in to the system of the present invention at any time. FIG. 35 is a DFD showing an example of login processing (member login S49) that can be used by completing member registration (new) S421. Hereinafter, a specific example of the member login S49 will be described with reference to FIG.

When the member login S49 is started, first, in S491, the community server 40 displays a login screen on the member terminal 60 (<1>). Although an example of the login screen is omitted, the screen can be almost the same as the screen shown in FIG. The member 13 inputs login information (member ID, password) through the login screen displayed on the member terminal 60, and presses the [Login] button (<2>). Then, the input information is transmitted from the member terminal 60 to the community server 40. The community server 40 refers to the password recorded in the member information TBL 421 using the received member ID, and collates it with the received password. If they match, the login authentication has succeeded, and the community server 40 performs processing so that the terminal can be specified. Specifically, for example, when a WEB browser is used for the terminal, the community server 40 issues a session ID (information for specifying the terminal) and transmits it to the member terminal 60. The member terminal 60 stores the session ID using a mechanism called a cookie. At the same time, the community server 40 secures a session scope (a storage area allocated to each terminal) in association with the session ID, and stores basic information such as a member ID and a member name. Next, the community server 40 transitions the execution process to S492.

In S492, the community server 40 displays a menu screen on the member terminal 60 (<3>). FIG. 36 shows an example of a menu screen.

When the member 13 completes the member login S49, the member 13 can use a service for members that requires member login authentication (for example, “marketing information search”, “advertisement distribution”, etc.).

In addition, the member login authentication process S491 is not limited to the password authentication method as described above. It is also possible to use a biometrics (biological) authentication method or the like.

[3.4.2.2. Member registration (change / delete) S422]
Member registration (change / deletion) S422 is a process whose purpose is to delete its own user information when the member 13 changes his / her member information or leaves this business model.

Systematically, the member 13 acquires the current member registration information through the member terminal 60, corrects this, and updates or deletes the corresponding record such as the member information TBL421. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of member registration (change / deletion) S422 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [member registration (change / delete)] button (<2>) on the member menu screen (FIG. 36), the community server 40 Transitions the execution process to S4221. Next, in S4221, the community server 40 acquires the current registration information from the member information TBL421, and displays an editing screen on the member terminal 60 (<3>). FIG. 38 is an example of an edit screen (member registration (change / delete) screen).

When changing the registered information of the member, in S4221, the member 13 modifies / edits and inputs information on the member (member 13) through the screen (FIG. 38) displayed on the member terminal 60, and the [Register] button. Is pressed (<4>). Then, the input information is transmitted from the member terminal 60 to the community server 40. If there is no problem after checking the validity of the format and value for the received input information, the community server 40 transitions the execution process to S4222. If there is a problem, an error message is returned to the member terminal 60 to prompt correct input.

Next, in S4222, the community server 40 updates the member information TBL421 based on the received information.

Finally, the community server 40 transmits a registration completion message to the member terminal 60 and displays it on the screen of the member terminal 60 (<5>). In this specification, the screen example of the registration completion message is omitted, but the screen example shown in FIG. 34 can be referred to.

When deleting member registration information, in S4221, the [Delete] check box on the member registration (change / delete) screen (FIG. 38) is checked and the [Register] button is pressed (<4>). In S4222, the community server 40 that has received the deletion information updates the deletion flag of the record related to the member information TBL421, thread management (for members) TBL423, and member HP content TBL424 to ON, and records the deletion date. Furthermore, the records may be physically deleted by batch processing based on the number of days elapsed from the deletion date.

The related record of the member access authority management TBL 422 may also have the deletion flag turned ON at this time, but it does not need to be deleted if it is a specification that is automatically deleted by the expiration date.

Finally, a registration completion message is transmitted to the member terminal 60 and displayed on the screen of the member terminal 60 (<5>).

In the screen example shown in FIG. 38, the [Change Password] button is prepared. When this button is pressed, a password change (for member) screen is displayed on the member terminal 60, and the password is used by using this. Can be changed. The password change (for members) screen can be referred to FIG.

Finally, when charging a member registration fee to the member 13, the community server 40 can calculate the fee by monthly processing based on the member information TBL421. Further, the calculation result is recorded in the profit TBL 454.

Above, description of an example of member relation various registration S42 is complete | finished.

[3.4.3. Member access authority generation S43]
Next, returning to FIG. 6, the member access authority generation S43, which is one of the main operations of the system of the present invention, will be described.
The member access authority generation S43 is a process for generating access authority necessary for the member 13 to participate in a community service (electronic conference room, chat, etc.) provided to the group 1A. In this embodiment, the advertisement distribution right is used to be generated. However, when the specification is such that the advertisement is not distributed before the negotiation, a specification for generating the negotiation right may be used.

FIG. 39 is a developed view of the member access authority generation S43 of FIG. In the present embodiment, the member access authority generation S43 includes two processes: an advertisement distribution right purchase S431 which is a process used by the member 13, and an advertisement distribution right grant S432 which is a process used by the user 12. . The advertisement distribution right purchase S431 is an access authority generating means used in the mechanism A (a mechanism for supporting outbound sales), and the advertisement distribution right granting S432 is performed in the mechanism B (a mechanism for supporting inbound sales). It is the access authority generation means used. Since these processes do not complement each other and can exist independently, a business model can be established with only one of these processes.
Hereinafter, the two processes will be described in order.

[3.4.3.1. Advertisement distribution right purchase S431]
First, the advertisement distribution right purchase S431 will be described. This process is a process used when the member 13 purchases an advertisement distribution right for the group 1A. Here, the advertisement distribution right is a right that the member 13 can send the advertisement to the group 1A (more precisely, the user 12 belonging to the group 1A). In the present embodiment, the marketing information search system is used as a method for searching for the group 1A that the member 13 wants to purchase the advertisement distribution right in, but the method is not limited to this. Conditions may be registered in advance, and each time the user 12 updates the marketing information, it is checked against the registered conditions. If the conditions match, the group information may be distributed to each member 13 or the group 1A. You can also browse and search websites and blogs published by.

Systemically, when the member 13 decides to purchase the advertisement distribution right for the group 1A, the member 13 selects the group 1A to purchase the advertisement distribution right through the member terminal 60, and sends the advertisement to the member access authority management TBL422. Process to record the record of distribution right. More specifically, the advertisement distribution right purchase S431 can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the advertisement distribution right purchase S431 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [Marketing Information Search] button (<2>) on the member menu screen (FIG. 36), the community server 40 executes the execution process. To S4311. Next, in S4311, the community server 40 displays a marketing information search screen on the member terminal 60 (<3>). FIG. 41 is an example of a marketing information search screen.

In the screen example shown in FIG. 41, the upper part is an example of a search condition input part. Here, in the [Field] list box, it is possible to select a field of interest to be input in group registration (new / change / delete screen (FIG. 18)). In addition, the screen design for the search condition input items and the like can be freely designed in consideration of the contents of the marketing information and the usability.

Next, in S4311, the member 13 inputs search conditions and searches for the marketing information of the group 1A through the marketing information search screen (FIG. 41) displayed on the member terminal 60, and presses the [Search] button. (<4>). Then, the input information is transmitted from the member terminal 60 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 obtains a list of the group 1A that matches the search condition from the group information TBL 412 (4121, 4122, 4123). The extracted list of groups 1A as a search result is returned to the member terminal 60 (<5>). If there is a problem, an error message is returned to the member terminal 60 to prompt correct input.

In the screen example shown in FIG. 41, the lower part is an example of a search result display part. Here, when the [Detail] button is pressed, a detailed information display screen as shown in FIG. 42 is displayed on the member terminal 60, and the member 13 can obtain detailed information regarding marketing information. In FIG. 41, the proposal request information is searched with the keyword = “Cebu Island”. Therefore, the contents entered in FIG. 23 are displayed in FIG.

Next, in S4311, the member 13 who has received the search result intends to purchase the advertisement distribution right in the lower part (search result display part) of the marketing information search screen (FIG. 41) displayed on the member terminal 60. Check the checkbox of the group 1A and press the [Purchase advertising distribution right] button (<6>). Then, the input information is transmitted from the member terminal 60 to the community server 40. Subsequently, the community server 40 that has received the input information transitions the execution process to S4312. In S4312, the community server 40 records a record of the advertisement distribution right in the member access authority management TBL 422 based on the received check input information.

Finally, the community server 40 transmits a purchase completion message to the member terminal 60 and displays it on the screen (<7>).

In the system of the present invention, when charging the marketing information usage fee to the member 13, a fixed amount can be collected every month based on the member information TBL421, or a fee is charged each time the detailed information of the group 1A is viewed. In the case of collecting, it may be charged each time the detail button is pressed in the screen example shown in FIG.

Further, when the member 13 is charged for the purchase price of the advertisement distribution right, the fee can be calculated by monthly processing based on the member access authority management TBL 422. For example, there is a method of multiplying the unit price per advertisement distribution right by the number of purchases.

The community server 40 records the billing amount / purchase fee in the revenue TBL 454 at any time and outputs a separate invoice or to a settlement system (bank settlement system, credit card settlement system, etc.) not shown. By transmitting the billing information, the member 13 may be billed according to the billing information.

[3.4.3.2. Advertisement distribution right grant S432]
Next, the advertisement distribution right granting S432 will be described. The advertisement distribution right grant S432 is an advertisement to the member 13 who is the owner of the HP when the user 12 finds a product of interest on the HP or the like and wishes to negotiate with the owner (member 13) of the HP. It is a process whose purpose is to grant distribution rights.

Systemically, when a user 12 finds a product of interest on HP or the like and wants to negotiate with the owner (member 13) of the HP, the user 12 inputs it through the user terminal 50. Based on the member ID of the member 13 to whom the advertisement distribution right is to be granted and the group ID of the group 1A (to which the user belongs), processing for recording a record of the advertisement distribution right in the member access authority management TBL 422 is performed. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the advertisement distribution right granting S432 will be described with reference to FIG.

In S48, when the user 12 logs in to the system of the present invention (<1>) and presses the [Shopping Mall] button (<2>) on the user menu screen (FIG. 13), the community server 40 executes The process transitions to S4321, and the shopping mall screen is displayed on the user terminal 50 (<3>). FIG. 44 is an example of a shopping mall screen displayed on the user terminal 50 in the HP browsing S4321.

The user 12 searches for a product through the shopping mall screen displayed on the user terminal 50 (<4>). As a result, an HP on which the target product is posted is found (<5>). FIG. 45 is an example of an HP on which a target product is posted.

Next, in S4321, when the user 12 finds a product of interest and wants to negotiate with the member 13, the user 12 presses a [negotiation request] button on the screen shown in FIG. 45 (<6>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 transitions the execution process to S4322, and displays the advertisement distribution right grant screen on the user terminal 50 (<7>). FIG. 46 is an example of an advertisement distribution right grant screen.

In the screen shown in FIG. 46, in the [Negotiation desired group] list box, the group 1A to which the user 12 who is the granter of the advertisement distribution right belongs can be selected. That is, when the screen is displayed, a list (group ID, group name) of the group 1A to which the user 12 who is the granter of the advertisement distribution right belongs is derived from the group basic information TBL4121 and the member information TBL413, Load into Negotiation Hope Group list box. Here, the granter of the advertisement distribution right is the user 12 who performs registration for granting the advertisement distribution right to the member 13 using the screen (FIG. 46).

Subsequently, in S4322, the user 12 inputs other input items on the advertisement distribution right grant screen (FIG. 46) and presses the [Advertise distribution right grant] button (<8>). It is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4323. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

In S4323, the community server 40 records the advertisement distribution right in the member access authority management TBL 422 based on the received input information.

Finally, the community server 40 transmits an advertisement distribution right grant completion message to the user terminal 50 and displays it on the screen (<9>). FIG. 47 is an example of an advertisement distribution right grant completion screen.

In the present embodiment, HP browsing is used as a method for finding a product that the user 12 is interested in, but the method for realizing the advertisement distribution right granting S432 is not limited to this. For example, a product catalog or a magazine may be used. However, in this case, the member 13 who is the seller needs to complete the membership registration, and the user 12 must be able to acquire the member ID of the member 13 who is the seller.

This completes the description of the two processes constituting the member access authority generation S43. In addition to these, the following modifications can be considered.

[3.4.3.3. Modification Example 1 of Advertisement Distribution Rights Granting S432]
FIG. 48 is a DFD of Modification 1 of the advertisement distribution right granting S432. In this modification, the user 12 browses the HP before logging in to the system of the present invention, searches for a product of interest, desires to negotiate with the member 13 who is the owner of the HP, and negotiates with the member 13. This is a process for granting a right.

In S4321, the user 12 searches for an item of interest and presses the [negotiation request] button on the HP screen owned by the member 13 as shown in FIG. 45 (<1> <2> <3> <4> ). Then, the community server 40 receives the information and first confirms that the user 12 is not logged in. Next, the execution process transits to user login authentication S481, and a login screen (FIG. 12) is displayed on the user terminal 50 (<5>). The user 12 inputs login information on the screen and logs in (<6>). When the community server 40 finishes the user login authentication S481 process, the community server 40 shifts the execution process to the edit S4322 without displaying the user menu screen (FIG. 13) on the user terminal 50, and delivers the advertisement to the user terminal 50. The right grant screen (FIG. 46) is displayed (<7>).

The user 12 edits and inputs necessary items through the advertisement distribution right grant screen (FIG. 46) displayed on the user terminal 50, and presses the [Advertise distribution right grant] button (<8>). Information is transmitted from the user terminal 50 to the community server 40. If there is no problem after the format or value validity check is performed on the received input information, the community server 40 transitions the execution process to S4323. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Subsequently, in S4323, the community server 40 records the advertisement distribution right in the member access authority management TBL422 based on the received input information.

Finally, the community server 40 transmits an advertisement distribution right grant completion message to the user terminal 50 and displays it on the screen (<9>).

[3.4.3.4. Modification Example 2 of Advertisement Distribution Right Grant S432]
FIG. 49 is a DFD of Modification 2 of the advertisement distribution right granting S432. In this example, the member HP content is stored in a server (member HP server 80) different from the community server 40. In this case, the member HP server 80 may be, for example, a server owned by the member 13 or a rental server. The member HP server 80 is connected to the community server 40, the user terminal 50, and the member terminal 60 via the communication network 70, and is in a state where data can be transmitted / received to / from each other via the communication interface.

The user 12 receives the HP content from the member HP server 80 and searches for a target product (<1> <2>). At this time, the screen displayed on the user terminal 50 is the same as that shown in FIGS.

Next, a “negotiation request” button is pressed (<3>). Then, the member HP server 80 receives the information and gives the user terminal 50 a redirect instruction to the advertisement distribution right granting II screen stored in the community server 40. At this time, the member ID is transmitted together by adding it to the URL information (<4>).

Next, the user terminal 50 receives the information and redirects to the advertisement distribution right granting II screen of the community server 40 (<5>). Then, the community server 40 confirms that the received member ID exists in the member information TBL 421, and displays an advertisement distribution right granting II screen (FIG. 50) having a login function on the user terminal 50 (<6>). .
FIG. 50 is a diagram illustrating an example of an advertisement distribution right granting II screen with a login function displayed on the user terminal 50. This screen is a screen obtained by adding a login function to FIG.

In the screen example shown in FIG. 50, the group ID of the group 1A that wishes to negotiate with the member 13 is entered in the [negotiation desired group ID] field.
Further, in the [Granter User ID] field, the user ID of the user 12 who intends to grant the advertisement distribution right to the member 13 is input using the screen (FIG. 50).
Further, in the [Granter Password] field, the login password of the user 12 who intends to grant the advertisement distribution right to the member 13 is input using the screen (FIG. 50).

Next, in S4322, the user 12 inputs each input item including the login information through the screen (FIG. 50) displayed on the user terminal 50, and presses the [Advertise distribution right] button (< 7>). Then, input information is transmitted from the user terminal 50 to the community server 40. Regarding the received input information, the community server 40 checks the validity of the format and value, confirms that the member ID as the grant destination exists in the member information TBL 421, and at the same time, inputs it in the [Negotiation group] field. It is confirmed that the group ID exists in the group basic information TBL 4121, and further, it is confirmed by the member information TBL 413 that the grantor's user ID is registered as a member of the negotiation desired group 1A. The process proceeds to S481. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Subsequently, in S <b> 481, the community server 40 performs login authentication based on login information (provider user ID, grantor password) in the received input information. If the login authentication is successful, the community server 40 transitions the execution process to S4323. In S4323, the community server 40 records the advertisement distribution right in the member access authority management TBL422.

Finally, the community server 40 transmits an advertisement distribution right grant completion message to the user terminal 50 and displays it on the screen (<8>).

[3.4.3.5. Modified example 3 of advertisement distribution right grant S432]
Modification 3 of the advertisement distribution right grant S432 is an advertisement distribution right grant method used when a target product is found in a catalog or a magazine. FIG. 51 is a diagram showing an example of an advertisement distribution right grant III screen used in the third modification of the advertisement distribution right grant S432. When the user 12 finds the target product, the user 12 can obtain the member ID of the grantee from a page such as a catalog and enter it on the screen (FIG. 51) to grant the advertisement distribution right to the member. it can. Although details of the processing will not be described, a link button is provided on the user menu screen (FIG. 13), and can be realized with reference to the processing of S432 in FIG.

[3.4.3.6. Modification of advertisement distribution right purchase S431]
In addition, a modification of the advertisement distribution right purchase S431 can be realized by applying the advertisement distribution right grant S432. This pattern is a method of setting a [negotiation right purchase] button on the HP or blog owned by the group 1A in the same manner as setting the [negotiation request] button in FIG. When the member 13 wants to conduct sales activities with reference to the HP or blog of the group 1A, when the member 13 presses the button, the advertisement distribution right can be acquired. The details of the processing are not described here, but can be realized with reference to other advertisement distribution right generation means.

[3.4.4. Advertisement distribution S44]
Next, returning to FIG. 6, the advertisement distribution S44, which is one of the main operations of the system of the present invention, will be described.
The advertisement distribution S44 is a process in which the member 13 sends an e-mail or the like for the purpose of advertisement to the user 12 belonging to the group 1A. Of course, in order to transmit the mail, it is a condition that the advertisement distribution right is acquired by the member access authority generation S43.

In terms of the system, the member 13 transmits an advertisement mail to the community server 40 through the member terminal 60, and the community server 40 checks that there is an advertisement distribution right. From the user information TBL411 and the member information TBL413, the advertisement is sent. This is a process of creating a list of mail addresses of users 12 belonging to the group 1A to be distributed and sending advertisement mails to those mail addresses. The user 12 can receive and browse these advertisement mails through mail software (mailer) or the like of the user terminal 50. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the advertisement distribution S44 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [Advertise Distribution] button on the member menu screen (FIG. 36) (<2>), the community server 40 executes the execution process. The process proceeds to S441. Next, in S441, the community server 40 extracts a list of groups 1A in which advertisement distribution is possible from the member access authority management TBL 422 and group basic information TBL 4121, and displays the advertisement distribution right list screen on the member terminal 60 (<3> ). FIG. 53 is an example of the advertisement distribution right list screen.

Next, when the member 13 depresses the [edit advertisement mail] button of the group 1A to send the advertisement mail on the advertisement distribution right list screen (FIG. 53) displayed on the member terminal 60 (<4>). The button press information is transmitted from the member terminal 60 to the community server 40. The community server 40 confirms that it has not been distributed, and transitions the execution process to S442. If the distribution has been completed, a message indicating that the distribution is not possible is returned to the member terminal 60.

In S442, the community server 40 causes the member terminal 60 to display an advertisement mail edit screen (<5>). FIG. 54 is an example of an advertisement mail editing screen displayed on the member terminal 60. Incidentally, the content of the mail adopted in the screen example is an example of an advertisement mail used in outbound sales.

When the advertisement mail editing screen is displayed, the member 13 edits and inputs the screen through the member terminal 60 and presses the [advertisement mail distribution] button (<6>). Then, the input information is transmitted from the member terminal 60 to the community server 40. The community server 40 performs a format and value validity check and a data amount appropriateness check on the received input information. If there is no problem, the community server 40 shifts the execution process to S443. If there is a problem, the community server 40 returns an error message to the member terminal 60 and prompts for correct input.

In S443, the community server 40 refers to the member access authority management TBL422, and after confirming again that there is an advertisement distribution right, that the advertisement distribution right is not distributed, and that the data amount of the advertisement mail is appropriate. The execution process transitions to S444.

In S444, the community server 40 creates a list of email addresses of users belonging to the group 1A that is the advertisement distribution target from the user information TBL411 and member information TBL413, and transmits an advertisement email to those email addresses. (<7>). FIG. 55 is an example of a received mail that the user 12 receives through the user terminal 50. It can be viewed using normal mail software.

In the present embodiment, since the electronic conference room is adopted as a community service for performing negotiations, the community server 40 transmits the advertisement mail and at the same time the thread of the electronic conference room for performing negotiations. Is newly recorded in the thread management TBL 431, the electronic conference room TBL 432, the thread management (for user) TBL 414, and the thread management (for member) TBL 423. Further, the negotiation right is recorded in the member access authority management TBL 422.

Finally, the community server 40 transmits an advertisement delivery completion message to the member terminal 60 and displays it on the screen (<8>).

As a reference, FIG. 56 shows an example of an advertisement mail used in inbound sales.

In the present embodiment, the specification is such that the advertisement mail is transmitted to all the users 12 belonging to the group 1A. However, the advertisement mail may be transmitted to at least one person.

In S443, when the user 12 receives the advertisement mail through the user terminal 50 and immediately decides to purchase the product provided by the member 13 without negotiation, the link button to the order screen set in the mail (Example: “(Order screen)” in FIG. 55), it is possible to immediately shift to the order S46.

Moreover, in this Embodiment, although it is set as the specification which transmits advertisement mail, the method is not limited to this. For example, it is also possible to send an advertisement flyer using a paper medium.

The process (advertisement distribution S44) is not an essential process in the system of the present invention. When the advertisement distribution S44 is omitted, in the member access authority generation S43, not the advertisement distribution right, but the negotiation right is directly generated, recorded in the member access authority management TBL422, and the thread of the electronic conference room for performing the negotiation at the same time. What is necessary is just to perform the process newly installed.

In the present embodiment, at the same time as the advertisement is distributed, a thread of the electronic conference room is newly installed and the negotiation right is recorded in the member access authority management TBL 422. However, as a modified example, the distributed advertisement When a [Thread Installation] button is attached, and the user 12 who has browsed considers the contents of the advertisement and is interested in the sales activities of the seller 13, and presses the [Thread Installation] button, the electronic conference A room thread may be newly set, and the negotiation right may be recorded in the member access authority management TBL 422.

Further, in the present embodiment, the specifications are such that a thread in the electronic conference room is newly installed, but it is not always necessary to newly install it, and a specification in which sales activities are performed using a thread installed in advance may be used.

[3.4.5. Negotiation S45]
Next, returning to FIG. 6, the negotiation S45, which is one of the main operations of the system of the present invention, will be described.
The negotiation S45 is a process for the purpose of the user 12 and the member 13 negotiating a product or the like. In the present embodiment, an electronic conference room is employed as a community service (communication tool) for negotiation. For example, chat, a mailing list, a virtual community service, etc. can be used.

In the present embodiment, as shown in FIG. 57, the negotiation S45 includes three processes: a user access check S451, a member access check S452, and an electronic conference room S453.

The user access check S451 is a process whose purpose is to check whether or not the user 12 can participate when attempting to participate in the electronic conference room through the user terminal 50.

The member access check S452 is a process for checking whether or not the member 13 can participate when he / she wants to participate in the electronic conference room through the member terminal 60.

In the electronic conference room S453, the user 12 and the member 13 determined to be able to participate in the processes of S451 and S452 negotiate on the electronic conference room thread, and as a result, the user 12 decides to purchase the product. This is a process intended to provide a function for transitioning to the order S46.

Systemically, when the user 12 tries to participate in the thread of the electronic conference room through the user terminal 50 in the user access check S451, the thread of the electronic conference room of the group 1A to which the user 12 belongs belongs. Yes, the community server 40 checks whether or not participation is possible, and transitions to the electronic conference room S453 only when it is determined that participation is possible, and performs processing for permitting reference and writing to the thread of the electronic conference room.

At the same time, in the member access check S452, when the member 13 intends to participate in the thread of the electronic conference room to be negotiated through the member terminal 60, the electronic conference room is referred to the member access authority management TBL422. The community server 40 checks whether or not the thread (or group 1A that owns the thread of the electronic conference room) has the right to negotiate, and transitions to the electronic conference room S453 only when it is determined that participation is possible. Then, processing for permitting reference and writing to the thread of the electronic conference room is performed.

Finally, in the electronic conference room S453, the community server 40 performs a process of providing the electronic conference room service (that is, referring to and writing to the thread of the electronic conference room) to the user 12 and the member 13 through the respective terminals. At the same time, when the user 12 decides to purchase the product, a process of transitioning to the order S46 is performed.
More specifically, the processing flows as shown in FIGS. 58, 60, and 62 are realized. Hereinafter, the three processes will be described in order.

[3.4.5.1. User access check S451]
First, the user access check S451 will be described with reference to FIG. FIG. 58 is a DFD showing an example of the user access check S451.

In S48, when the user 12 logs in to the system of the present invention (<1>) and presses the [electronic conference room] button (<2>) on the user menu screen (FIG. 13), the community server 40 The execution process transitions to S4511. Next, in S4511, the community server 40 derives a list of threads in the electronic conference room in which the user 12 can participate from the thread management TBL 431, the thread management (for user) TBL 414, and the group basic information TBL 4121 and uses it. The electronic conference room thread list (for user) screen is displayed on the screen of the person terminal 50 (<3>). FIG. 59 shows an example of the electronic conference room thread list (for user) screen.

In the screen shown in FIG. 59, the [Negotiation] button is a button used when the user 12 recognizes that the user 12 is in a negotiation state.
When the [Negotiate] button is pressed, the status attribute of the thread management TBL 431 is updated from the normal state to the negotiated state by the community server 40. In the normal state, it is automatically deleted when the expiration date comes. However, in the negotiation state, it is not deleted even after the expiration date. Conversely, when the [Cancel] button is pressed, the negotiation state is canceled and the normal state is entered.

Similarly, in the screen shown in FIG. 59, whether the new message (Msg) is present or not is determined based on the latest opinion No. of the thread management TBL 431 and the referenced opinion No. of the thread management (for user) TBL 414. It can be determined by comparison.

In S4511, the user 12 presses the [Thread ID] button (<4>) through the electronic conference room thread list (for user) screen (FIG. 59) displayed on the user terminal 50. Is transmitted from the user terminal 50 to the community server 40. Next, the community server 40 transitions the execution process to S4512.

Next, in S4512, the community server 40 refers to the thread management (for user) TBL 414, checks whether the thread is in the electronic conference room of the group 1A to which the user 12 belongs, and can participate. Only when it is determined, the process proceeds to the electronic conference room S453 described later.

[3.4.5.2. Member access check S452]
Next, the member access check S452 will be described with reference to FIG. FIG. 60 is a DFD showing an example of the member access check S452.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [Negotiate] button on the member menu screen (FIG. 36) (<2>), the community server 40 executes the execution process in S4521. Transition to. Next, in S4521, the community server 40 derives a list of threads of the electronic conference room that can participate from the thread management TBL 431, the thread management (for member) TBL 423, and the group basic information TBL 4121, and the screen of the member terminal 60 is displayed. The electronic conference room thread list (for members) screen is displayed (<3>). FIG. 61 is an example of the electronic conference room thread list (for members) screen.

Next, in S4521, the member 13 presses the [Thread ID] button on the electronic conference room thread list (for members) screen (FIG. 61) displayed on the member terminal 60 (<4>). Information indicating that the request has been made is transmitted from the member terminal 60 to the community server 40. Next, the community server 40 transitions the execution process to S4522.

Next, in S4522, the community server 40 refers to the member access authority management TBL 422 to check whether the member 13 is a thread of an electronic conference room that has a negotiating right, and the expiry date of the negotiating right Only when it is determined that it is possible to participate, the transition to the electronic conference room S453 is made. Here, even if it is not within the expiration date, if the “status” attribute of the thread management TBL 431 is negotiated, it is determined that participation is possible.

[3.4.5.3. Electronic conference room S453]
Finally, the electronic conference room S453 will be described with reference to FIG. FIG. 62 is a DFD showing an example of the electronic conference room S453. In the electronic conference room S453, the community server 40 causes the user terminal 50 to display an electronic conference room screen (the display content is the content of the thread of the accessed electronic conference room) (50 <1>). FIG. 63 is an example of an electronic conference room screen.

The user 12 repeats reference and writing to the thread of the accessed electronic conference room through the electronic conference room screen (FIG. 63) displayed on the user terminal 50 (50 <2>). Here, when writing is performed from the user terminal 50, the community server 40 records the information in the electronic conference room TBL 432 and at the same time updates the “latest opinion No” in the thread management TBL 431. When the user 12 leaves the electronic conference room, for example, by pressing the “Return” button, the community server 40 sets the “referenced opinion No” of the thread management (for user) TBL 414 to the thread management TBL 431. To the value of “latest opinion No”.

On the other hand, in the electronic conference room S453, the community server 40 causes the member terminal 60 to display an electronic conference room screen as shown in FIG. 63 (the display content is the content of the thread of the accessed electronic conference room). (60 <1>). The member 13 repeats reference and writing to the thread of the accessed electronic conference room through the electronic conference room screen (FIG. 63) displayed on the member terminal 60 (60 <2>). Here, when writing is performed, the community server 40 records the information in the electronic conference room TBL 432 and simultaneously updates the “latest opinion No” in the thread management TBL 431. Further, when the member 13 leaves the electronic conference room by pressing the “Return” button or the like, the “referenced opinion No” of the thread management (for members) TBL 423 is changed to “latest opinion No” of the thread management TBL 431. Update to value.

As described above, both the user 12 and the member 13 negotiate by repeating reference and writing. As a result, when the user 12 (group 1A) decides to purchase a product provided by the member 13 (negotiation is established), the representative of the user 12 (group 1A) or each person presses the [order screen] button. (50 <3>). Then, the community server 40 transitions the execution process to the order S46 (see FIG. 6).

Above, description of an example of negotiation S45 is complete | finished.

[3.4.6. Order S46]
Next, returning to FIG. 6, the order S46, which is one of the main operations of the system of the present invention, will be described.
The order S46 is a process for the purpose of the user 12 and the member 13 having reached the negotiation using the system of the present invention to confirm the contents of the order.

FIG. 64 is a DFD showing an example of the order S46. In the present embodiment, the order S46 is composed of two processes of an order input S461 and a discount amount input S462. Hereinafter, the two processes will be described in order.

[3.4.6.1. Order input S461]
The order input S461 is a process for the purpose of allowing the user 12 who has decided to purchase to input an order. In terms of the system, the user 12 is a process of inputting order information through the user terminal 50 and recording the order contents in the order TBL 441. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the order input S461 will be described with reference to FIG.

The user 12 who has decided to purchase presses the [Order Screen] button on the electronic conference room screen (FIG. 63). Then, the community server 40 transitions the execution process to S4611. In S4611, the community server 40 displays an order edit screen on the user terminal 50 (<1>). At this time, the address of the order edit screen can be acquired from the “order received screen address” attribute on the member information TBL 421. 66 and 67 are examples of the order edit screen.

67. In the order edit screen 2 shown in FIG. 67, in the [Billing address] list box and the [Delivery address] list box, select a member (user 12) of the group 1A to which the user 12 who has decided to purchase belongs. Is possible. That is, at the time of display, a list of members (user ID, user name) belonging to the group 1A to which the user 12 who has decided to purchase belongs is derived from the user information TBL411 and member information TBL413. Load it into the [Billing to] list box and the [To] list box.

Next, in S4611, the user 12 edits information regarding the product to be ordered and the quantity on the order edit screen 1 shown in FIG. At this time, the community server 40 that has received the product information confirms that the product is in stock based on the product TBL 443. When the editing of the order edit screen 1 (FIG. 66) has been completed, the [Pricing request destination designation] button is then pressed. Then, the community server 40 that has received the input information causes the user terminal 50 to display the order edit screen 2 (FIG. 67). Next, on the order edit screen 2 (FIG. 67), the user 12 edits information on the billing destination, the billing amount, the merchandise delivery destination, and the quantity.

When the order edit screen 2 (FIG. 67) has been edited, the [Order Confirmation] button on the screen (FIG. 67) is pressed (<2>). It is transmitted to the server 40. The community server 40 checks the validity of the format and value of the received order information, confirms again that the product is in stock, based on the product TBL 443, and sums the total amount and total amount for each billing destination. If there is no problem after confirming that the billing amounts match, the execution process proceeds to S4612. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

In S4612, the community server 40 displays an order confirmation screen on the user terminal 50 (<3>). FIG. 68 is an example of an order confirmation screen. When the user 12 presses the “Order” button on the order confirmation screen (FIG. 68) (<4>), information that the user 12 has been pressed is transmitted from the user terminal 50 to the community server 40. The community server 40 transitions the execution process to S4613.

Next, in S4613, the community server 40 confirms again that the product is in stock based on the product TBL 443. If there is a stock, the community server 40 records the order details in the order TBL 441. At the same time, the inventory quantity is reduced. Finally, the community server 40 displays an order completion message on the user terminal 50 (<5>).

Here, the order screen may be an order estimate screen as shown in FIG. However, in this case, the member 13 must find out the products to be purchased by the user 12, the purchase quantity, the billing destination, and the sending destination in the negotiation in the electronic conference room, and create an order estimate. FIG. 65 or the like can be referred to for processing when an order estimate is created, and FIG. 66, FIG. 67, FIG. 68, or the like can be referred to for the screen.

In addition, the user 12 who has decided to purchase not only the electronic conference room screen (FIG. 63) but also presses a link button to the order screen set in the received advertisement mail (order input S461). ) May be allowed to transition to.

[3.4.6.2. Discount amount input S462]
The discount amount input S462, which is another process constituting the order S46, is a process for the member 13 to input a discount amount for the order input by the user 12. Systemically, the member 13 is a process of inputting discount information through the member terminal 60 and recording the discount amount in the order record on the order TBL 441. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the negotiation discount input S462 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [order list] button on the member menu screen (FIG. 36) (<2>), the community server 40 executes the execution process. The process proceeds to S4621. Next, in S4621, the community server 40 displays the order list screen on the member terminal 60 (<3>). FIG. 71 shows an example of an order list (for members) screen.

In S4621, when the member 13 presses the [Discount] button of the order record to be discounted on the order list (for member) screen (FIG. 71) through the member terminal 60 (<4>), information that the member 13 has been pressed. Is transmitted from the user terminal 50 to the community server 40. The community server 40 transitions the execution process to S4622, and causes the member terminal 60 to display a discount amount input screen (<5>). FIG. 72 is an example of a discount amount input screen.

When the member 13 inputs the discount amount on the discount amount input screen (FIG. 72) through the member terminal 60 and presses the [Register] button (<6>), the input information is transferred from the user terminal 50 to the community server. 40. Here, the “discount” button cannot be used for orders in which the product delivery status is delivered (settled). The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, the community server 40 transitions the execution process to S4623. If there is a problem, the community server 40 returns an error message to the user terminal 50 to prompt correct input.

Next, in S <b> 4623, the community server 40 records the received discount amount information in the “discount amount” attribute of the corresponding order record on the order TBL 441.

Finally, the community server 40 transmits the updated order list screen to the member terminal 60 and displays it on the screen (<7>).

Above, description of an example of order S46 is complete | finished.

[3.4.7. Delivery settlement S47]
Next, returning to FIG. 6, the delivery settlement S47, which is one of the main operations of the system of the present invention, will be described.
The purpose of delivery settlement S47 is to manage the merchandise delivery action of the member 13 for the order, and to calculate the brokerage fee, user points, and group points for the transactions for which the merchandise delivery has been completed, and to record the transaction results. Is a process.

FIG. 73 is an expanded view of the delivery settlement S47 of FIG. 6. In this embodiment, the delivery settlement S47 is composed of two processes of merchandise delivery management S471 and transaction record recording S472. Hereinafter, the two processes will be described in order.

[3.4.7.1. Product delivery management S471]
The merchandise delivery management S471 is a process for managing the merchandise delivery action of the member 13 with respect to the order. In the system, the member 13 receives the money by bank transfer or the like, and then completes the delivery of the merchandise. Then, the product delivery completion is input through the member terminal 60 and the community server 40 updates the “product delivery status” attribute of the order TBL 441 to “delivered”. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the commodity delivery management S471 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [order list] button on the member menu screen (FIG. 36) (<2>), the community server 40 executes the execution process. The process proceeds to S4711. Next, in S4711, the community server 40 extracts an order list from the order TBL 441, and displays an order list (for members) screen shown in FIG. 71 on the screen of the member terminal 60 based on the extracted order list (see FIG. 71). <3>).

Next, in S4711, the member 13 inputs a check in the check box for the order for which the delivery of the product has been completed through the order list (for member) screen (FIG. 71) of the member terminal 60, and the [Product Delivery Complete] button. Is pressed (<4>). Then, the input information is transmitted from the member terminal 60 to the community server 40. Next, the community server 40 that has received the input information transitions the execution process to S4712.

Next, in S4712, the community server 40 updates the “product delivery status” attribute of the order TBL411 to “delivered”.

Finally, the community server 40 displays the updated order list (for members) screen on the member terminal 60 (<5>). In this screen, “delivery completed” is displayed in the product delivery status column.

[3.4.7.2. Transaction record S472]
The transaction record record S472 is a process for calculating a brokerage fee, user points, and group points for a transaction for which delivery of a product has been completed, and recording the transaction record, as shown in the DFD of FIG. It can be realized with a flow.

In the transaction record S472, the community server 40 is a transaction for which product delivery has been completed from the order TBL 441 (an order in which the “product delivery status” attribute is “delivered”), and the “settlement status” attribute is The order records that are “unsettled” are extracted, and for each record, the brokerage fee charged to the member 13, the points (user points) to be given to the purchaser (user 12), and the group 1A Calculate points (group points). The calculation method may be a method of multiplying the transaction amount by a certain interest rate.

Subsequently, the transaction result is recorded in the transaction result TBL 442 including the calculation result. At the same time, the “settlement status” attribute of the order TBL 441 is updated to “settlement completed”.
At this time, the brokerage fee may be recorded in the revenue TBL 454 at the same time.

In addition, the organizer 11 can perform a settlement agent business based on the order TBL 441 or the transaction performance TBL 442. Specifically, by debiting from the bank account, the product price can be collected from the user 12, and the amount obtained by subtracting the brokerage fee from the product price can be transferred to the bank account of the member 13.

Above, description of an example of delivery payment S47 is complete | finished.

[4. Embodiment of System of Present Invention Realizing Mechanism C]
Next, mechanism C among the mechanisms realized by the system of the present invention will be described. The mechanism C is a mechanism added to the present invention system according to the present embodiment for realizing the mechanism A and the mechanism B, and the present invention system according to the present embodiment for realizing the mechanism A and the mechanism B described above. It is described on the assumption.

[4.1. Call / communication charge discount processing S4A]
Mechanism C is a mechanism that discounts the charge according to the accumulated points in calls and communications (calls and communications between users belonging to the same group) performed using a group service. In the form, “call / communication charge discount processing S4A” is used.

By introducing the call / communication charge discount processing S4A, the more the user 12 performs activities (purchasing activities, etc.) that can acquire points, the more communication / communication costs between users belonging to the same group are. Since it can be reduced, incentives for point acquisition activities such as purchasing activities can be obtained.

Systematically, a group point for discount rate calculation is calculated based on the transaction result TBL442, and the result is recorded in the “group point for discount rate calculation” attribute of the group basic information TBL4121 and recorded in the group basic information TBL4121. Based on the discount rate calculation group point, a call / communication charge is calculated and recorded in the call / communication charge calculation result TBL451. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the call / communication charge discount processing S4A will be described with reference to FIG.

First, in S4A1, the community server 40 aggregates the group points for the current month for each group by batch processing based on the transaction results TBL442, and records them in the “group point for discount rate calculation” of the group basic information TBL4121. Here, the discount rate is used for calculating the discount rate for the next month or the current month.

Next, when calculating the call / communication charge, in S4A2, the community server 40 extracts a list of groups 1A to which two users who make calls / communication belong based on the member information TBL413. . Next, the “discount rate calculation group points” of one or more groups 1A extracted previously from the group basic information TBL 4121 are tabulated. Further, the discount rate is determined according to the total points, for example, according to the table of FIG. 76, the discount rate is calculated by multiplying the discount / call / communication fee by the discount rate, the call / communication fee before discount, etc. At the same time, the call / communication charge calculation result TBL 451 is recorded.

In addition to the method of calculating points with reference to the discount rate table as described above, the discount rate for each group 1A is first determined based on the discount rate table, and then calculated. There is also a way to determine the final discount rate.

Finally, the computer hardware that performs the processing (S4A) is not necessarily the community server 40, and may be prepared separately.

[5. Embodiment of System of Present Invention for Realizing Mechanism D]
Next, mechanism D among the mechanisms realized by the system of the present invention will be described. The mechanism D is a mechanism added to the system of the present invention related to the present implementation for realizing the mechanism A and the mechanism B, similar to the mechanism C, and the book for realizing the mechanism A and the mechanism B described above. It is described on the assumption that the system of the present invention according to the embodiment.

[5.1. User management S4B]
The mechanism D is a mechanism related to a user (customer) management method by the manufacturer of the product, the member 13 (hereinafter referred to as “user manager”) when the user 12 purchases the product. Is “user management S4B”.

When performing user registration, registration can now be done by mail or on the Internet. However, support after registration is performed through a homepage (HP), e-mail, direct mail (DM), etc. For example, searching for product information owned by the user on the manufacturer's HP requires some effort. It takes a lot of time to organize the guidance by e-mail and DM. The mechanism D (user management S4B) is a mechanism that has been conceived in view of the above problems, and proposes a user registration and user management (or contract management) method using the group service of the present invention system. is there.

FIG. 77 is an expanded view of the user management S4B. In the present embodiment, the user management S4B is composed of two processes, product delivery date registration S4B1 and user registration S4B2. Hereinafter, the two processes will be described in order.

[5.1.1. Product delivery date registration S4B1]
The product delivery date registration S4B1 is a process for registering the delivery date when the member 13 delivers the product to the user 12. This delivery date is used as a reference date for calculating the product repair guarantee deadline for the product.

Systemically, when the member 13 completes the delivery of the product, the member 13 inputs a product delivery date from the member terminal 60 and performs a process of recording in the product delivery date management TBL 452. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the commodity delivery date registration S4B1 will be described with reference to FIG.

In S49, when the member 13 logs in to the system of the present invention (<1>) and presses the [Register Product Delivery Date] button (<2>) on the member menu screen (FIG. 36), the community server 40 executes The process transitions to S4B11. Next, in S4B11, an edit screen (product delivery date registration screen) is displayed on the screen of the member terminal 60 (<3>). FIG. 79 is an example of a product delivery date registration screen.

In the screen example shown in FIG. 79, the product delivery date (registration date) may be acquired automatically by the member 13 using the screen to register the product delivery date.

Next, in S4B11, the member 13 inputs the product ID and the recipient user ID through the product delivery date registration screen (FIG. 79) of the member terminal 60, and presses the [Register] button (<4>). . Then, the input information is transmitted from the member terminal 60 to the community server 40. Next, the community server 40 that has received the input information refers to the product TBL 443 to confirm that the received product ID exists, and refers to the user information TBL 411 to receive the received recipient's ID. It is confirmed that the user ID exists, and if there is no problem, the execution process is shifted to S4B12. If there is a problem, an error message is returned to the member terminal 60 to prompt correct input.

Next, in S4B12, the community server 40 refers to the product TBL443, acquires information about the registration target product, and records it in the product delivery date management TBL452 together with the received information.

Finally, the community server 40 transmits a registration completion message to the member terminal 60 and displays it on the screen of the member terminal 60 (<5>).

In addition, the product delivery date registration S4B1 may be processed together by the product delivery management S471.

[5.1.2. User registration S4B2]
The user registration S4B2 is a process whose purpose is to perform user registration in order for the user 12 to receive user support from a user administrator (manufacturer, etc.) of the purchased product. However, in order to execute the process (user registration S4B2), the user administrator needs to make the following preparations as the user 12 in advance.
Group registration (new / change / deletion) S413 is used to set up a group 1A related to products.
A thread registration (new / change / deletion) S417 is used to install a thread in the electronic conference room.
At this time, a plurality of threads according to the purpose, such as a thread for continuously providing product information (thread type: (contact-only) bulletin board) and a thread for discussing products (thread type: conference room) May be installed.

Returning to FIG. 77, the user registration S4B2 is systematically, the user 12 inputs user registration information from the user terminal 50, and at the same time registers as a member in the group 1A set up by the user administrator, the user management server A process of transmitting user registration information to 90 is performed. More specifically, it can be realized by a processing flow as shown in the DFD of FIG. Hereinafter, an example of the user registration S4B2 will be described with reference to FIG.

In S48, when the user 12 logs in to the system of the present invention (<1>) and presses the [User Registration] button (<2>) on the user menu screen (FIG. 13), the community server 40 executes The process transitions to S4B21. Next, in S4B21, the community server 40 determines the product ID, product name, manufacturer name, product delivery date, and manufacturer user management server 90 from the product delivery date management TBL 452 based on the user ID of the user 12. The image of the edit screen corresponding to the product ID is acquired from the user registration screen TBL453, and the user name, address, etc. are acquired from the group basic information TBL4121 and the user information TBL. The editing screen is acquired and displayed on the user terminal 50 (<3>). FIG. 81 is an example of an edit screen (user registration screen).

In the screen example shown in FIG. 81, when the [Information Acquisition] button is pressed, information related to the user 12 is sequentially acquired and displayed among the information recorded in the product delivery date management TBL452.

Next, in S4B21, the user 12 inputs necessary input items on the user registration screen (FIG. 81), and then presses the [Register] button (<4>). Then, input information is transmitted from the user terminal 50 to the community server 40. The community server 40 checks the validity of the format and value of the received input information, and if there is no problem, transitions the execution process to S4B22. If there is a problem, an error message is returned to the user terminal 50 to prompt correct input.

Next, in S4B22, the community server 40 transmits user registration information to the user management server 90.

The user management server 90 performs user authentication using the serial number and password entered by the user 12 on the user registration screen (FIG. 81). That is, the user management server 90 must manage the serial number and the password in association with each other. When the user authentication is successful, the user management server 90 records the received user registration information in the database, and returns to the community server 40 that the user registration is successful.

Next, in S4B22, the community server 40 registers as a member in the group 1A set by the user administrator (that is, records necessary information in the member information TBL 413 and thread management (for user) TBL 414).

Finally, the community server 40 transmits a registration completion message to the user terminal 50 and displays it on the screen (<5>).

[6. Embodiment of the system of the present invention for realizing mechanism E]
Next, the mechanism E among the mechanisms realized by the system of the present invention will be described. Like mechanism C and mechanism D, mechanism E is a mechanism that is added to the present invention system according to this embodiment for realizing mechanism A and mechanism B, and realizes mechanism A and mechanism B described above. It is described on the premise of the system of the present invention according to this embodiment.

[6.1. User list creation with friendship S4C]
The mechanism E is a mechanism for creating a contact information list (address book) of the users 12 who have a friendship relationship so that the friendship between members belonging to the same group can be easily maintained. Is “Create user list with friendship S4C”.

More specifically, it can be realized by a processing flow like the DFD shown in FIG. Hereinafter, an example of the user list creation S4C having a friendship relationship will be described with reference to FIG.

In S48, the user 12 logs in to the system of the present invention (<1>) and presses the [list of users with friendship] button (<2>) on the user menu screen (FIG. 13). The server 40 transitions the execution process to S4C1, and displays a user list screen having a friendship relationship on the user terminal 50 (<3>). FIG. 83 is an example of a user list screen having a friendship relationship.

Here, the process of extracting a list of users having a friendship is, for example, as follows.
From the member information TBL 413, a list (group ID) (hereinafter referred to as “list A”) of the group 1A to which the user belongs is derived.
From the list A and member information TBL 413, a list (user ID, group ID) (hereinafter referred to as “list B”) of members belonging to the group 1A of the derived list A is created.
From the list B, the user information TBL 411, and the group basic information TBL 4121, the community server 40 generates a user list.

By using this mechanism E, there is an advantage that the user 12 does not need to contact all the friends when changing the address or changing the telephone number. In addition, the use of the download function has an advantage that a telephone directory such as a mobile phone can be updated.

In addition, as an application example, by managing on the server without having the phone book data in the mobile phone, log in using another person's mobile phone, browse the phone book, and call You can send or email. At this time, the call / communication charge can be billed to the login user.

In addition, by installing a function that limits calls / communication destinations to members on the list (a list of users having a friendship relationship) (that is, users 12 belonging to the same group 1A), the user ID and password can be set. Even if stolen, there is an advantage that the risk of misuse is reduced. It is also possible to prepare an authentication password different from the login so that a call can be made to a store or person who has not been registered as a group or a member.

[7. Embodiment of System of Present Invention Realizing Mechanism F]
Next, the mechanism F among the mechanisms realized by the system of the present invention will be described. The mechanism F is a mechanism added to the present invention system according to the present embodiment for realizing the mechanism A and the mechanism B, similar to the mechanism C, the mechanism D, and the mechanism E, and the mechanism A and the mechanism B described above. It is described on the premise of the system of the present invention according to this embodiment for realizing the above.

[7.1. Reinvestment amount calculation processing S4D]
The mechanism F calculates a reinvestment amount for reinvesting part of the profit received from the member 13 or the user 12 in the operation of the community service in order to virtuously circulate the business model realized by the system of the present invention. In this embodiment, “reinvestment amount calculation processing S4D” is adopted.

More specifically, it can be realized by a processing flow like the DFD shown in FIG. Hereinafter, an example of the reinvestment amount calculation process S4D will be described with reference to FIG.

In the reinvestment amount calculation process S4D, the revenue for a certain period (for example, one month) is totaled from the revenue TBL454, the determined interest rate is multiplied by the total value, and the calculated value is used as the reinvestment amount. Recorded in the investment amount TBL455.

By using this mechanism F, the amount of revenue to be reinvested in management including expansion of community services is calculated, and the organizer 11 improves the service for the user 12 within the range of this amount. A virtuous cycle of business as shown in 2 can be realized.

The figure which shows the outline | summary of the business model implement | achieved by utilizing this invention system Diagram showing business development realized through circulation of each business model service realized by the present invention Diagram explaining mechanism for supporting outbound sales in this business model, Supporting inbound sales in this business model Figure explaining the mechanism State transition diagram of mechanism A, which is a mechanism that supports outbound sales State transition diagram of mechanism B, which is a mechanism that supports inbound sales Block diagram showing schematic configuration of the system of the present invention Block diagram schematically showing the database configuration of the community server Data flow diagram of one embodiment of the system of the present invention Data flow diagram of various user-related registrations Data flow diagram showing an example of user registration (new) The figure which shows an example of the user registration screen displayed on a user terminal The figure which shows an example of the registration completion message screen displayed on a user terminal Data flow diagram showing an example of login processing The figure which shows an example of the login screen displayed on the user terminal The figure which shows an example of the menu screen displayed on a user terminal Data flow diagram showing an example of user registration (change / delete) The figure which shows an example of the edit screen (user registration (change / deletion) screen) displayed on a user terminal The figure which shows an example of the password change (for user) screen displayed on a user terminal Data flow diagram showing an example of group registration (new / change / delete) The figure which shows an example of the edit screen displayed on a user terminal The figure which shows an example of the registration completion message screen when registering a new group displayed on the user terminal Data flow diagram showing an example of marketing information registration (anniversary) The figure which shows an example of the edit screen (marketing information registration (anniversary) screen) displayed on a user terminal Data flow diagram showing a specific example of marketing information registration (request for proposal) The figure which shows an example of the edit screen (marketing information registration (request for proposal) screen) displayed on a user terminal Data flow diagram showing a specific example of member registration Data flow diagram showing an example of member registration application Diagram showing an example of the edit screen (member registration application (new / delete) screen) displayed on the user terminal Data flow diagram showing an example of member approval The figure which shows an example of the edit screen (member approval screen) displayed on a user terminal Data flow diagram showing an example of thread registration (new / change / delete) Diagram showing an example of the edit screen (thread registration (new / change / delete) screen) displayed on the user terminal Data flow diagram of various member-related registrations Data flow diagram showing an example of member registration (new) The figure which shows an example of the member registration screen displayed on the member terminal Figure showing an example of the registration completion message screen Data flow diagram showing an example of member login The figure which shows the example of the menu screen displayed on the member terminal Data flow diagram showing an example of member registration (change / delete) The figure which shows an example of the edit screen (member registration (change / deletion) screen) displayed on the member terminal Data flow diagram showing an example of member access authority generation Data flow diagram showing an example of advertising distribution rights purchase The figure which shows an example of the edit screen (marketing information search screen) displayed on the member terminal The figure which shows the example of the detailed information display screen which is displayed on the member terminal Data flow diagram showing an example of granting advertisement distribution rights The figure which shows an example of the shopping mall screen displayed on a user terminal The figure which shows the example of the HP display screen where the target commodity which is displayed on the user terminal is published The figure which shows an example of the advertisement delivery right grant screen displayed on a user terminal The figure which shows an example of the advertisement distribution right grant completion screen displayed on a user terminal Data flow diagram showing modification 1 of advertisement distribution right grant Data flow diagram showing modification 2 of granting of advertisement distribution right The figure which shows an example of the advertisement delivery right grant screen displayed on a user terminal The figure which shows the example of the screen used by the modification 3 of the advertisement delivery right grant displayed on a user terminal Data flow diagram showing an example of ad delivery The figure which shows an example of the advertisement distribution right list screen displayed on the member terminal The figure which shows an example of the advertisement mail edit screen displayed on the member terminal The figure which shows an example of the received mail as the advertisement distribution received through the user terminal A diagram showing an example of advertising emails used in inbound sales Data flow diagram showing an example of negotiation Data flow diagram showing an example of user access check The figure which shows an example of the electronic conference room thread | sled list (for users) screen displayed on a user terminal Data flow diagram showing an example of member access check The figure which shows an example of the electronic conference room thread | sled list (for members) screen displayed on a member terminal Data flow diagram showing an example of an electronic conference room The figure which shows an example of the electronic conference room screen displayed on a user terminal and a member terminal Data flow diagram showing an example order Data flow diagram showing an example of order entry The figure which shows an example of the order edit screen displayed on a user terminal The figure which shows an example of the order edit screen displayed on a user terminal The figure which shows an example of the order confirmation screen displayed on the user terminal The figure which shows an example of the order estimate screen displayed on a user terminal and a member terminal Data flow diagram showing an example of negotiated discount input The figure which shows an example of the order list (for member) screen displayed on the member terminal The figure which shows an example of the discount amount input screen displayed on the member terminal Data flow diagram showing an example of delivery settlement Data flow diagram showing an example of product delivery management Data flow diagram showing an example of call / communication charge discount processing Diagram showing an example of a table showing the correspondence between counting points and discount rates Data flow diagram showing an example of user management Data flow diagram showing an example of product delivery date input The figure which shows an example of a goods delivery date registration screen Data flow diagram showing an example of user registration processing Figure showing an example of the user registration screen Data flow diagram showing an example of user list creation process with friendship The figure which shows an example of the user list screen with friendship Data flow diagram showing an example of reinvestment amount calculation processing

Explanation of symbols

40 ... community server 50 ... user (buyer) terminal 60 ... member (seller) terminal 70 ... communication network 80 ... member (seller) HP server 90 ... user management server

Claims (4)

In a community server that provides community services on a communication network to a group to which at least one user belongs,
The user information that is information about the user specified by the user identification information, the group information that is information about the group that is specified by the group identification information, and the user identification information and the group identification information are associated with each other. User information group information storage means for storing affiliation information as information,
Seller information storage means for storing seller information, which is information related to the seller, specified by the seller identification information ;
Thread information storage means for storing thread information that is information related to a thread that is a collection of writes, specified by the thread identification information;
(A) receiving, from the seller terminal used by the seller , at least the seller identification information and the group identification information for the purpose of requesting sales activities for the group;
(B) At least the group of the group to which the user belongs, for the purpose of requesting the seller to request a product or service proposal from a user terminal used by the user belonging to the group Receiving identification information and the seller identification information;
When at least one of (a) and (b) is executed,
Access authority generating means for storing access authority information for associating at least the group identification information, the seller identification information, and the thread identification information for identifying a thread serving as a place for negotiation for performing a sales activity;
When receiving the seller identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the seller terminal, the seller identification information based on the access authority information Is determined to be associated with the thread identification information, and if so, seller access determination means for permitting access to the thread specified by the thread identification information;
When receiving the user identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the user terminal, the access authority information, the affiliation information, , It is determined whether or not the user identification information is associated with the thread identification information via the group identification information, and if it is associated, the thread identified by the thread identification information is accessed. A user access determination means that permits the user to
At least the thread identification information intended to be written into the thread is identified from the user terminal permitted to access or the seller terminal permitted to access, and whether or not the seller is writing. Means for storing the information for writing and the written content together with the thread identification information in the thread information storage means together with the writing date and time as one writing record;
When receiving the thread identification information intended to refer to the thread from the user terminal permitted to access or the seller terminal permitted to access, based on the thread information storage means, Outputs the writing record, which is associated with the thread identification information that matches the received thread identification information, and includes at least information for identifying whether or not the seller is writing, writing contents, and writing date and time. Means,
Thread writing reference means having
(C) When a commercial transaction is established between the user and the seller specified by the seller identification information as a result of using the thread, the seller specified by the seller identification information included in the access authority information On the other hand, processing to charge transaction brokerage fee,
(D) a process of charging a negotiating right fee to the seller specified by the seller identification information included in the access authority information;
(E) Based on the seller information storage means, the access authority generation means stores the seller identification information included in the access authority information, and as a result, the seller who may be able to access the thread. Processing to charge the membership registration fee,
Charging means for executing at least one of the processes (c), (d), and (e)
To support group activities,
Based on the user information group information storage means, a group activity support means for permitting use of a group service provided to the group by a user terminal used by the user belonging to the group;
A community server characterized by comprising: In the charging means,
(C), when order information including at least transaction amount information is received from the user terminal belonging to the group, a transaction brokerage fee is calculated by multiplying the transaction amount information by a predetermined transaction brokerage fee rate. To
(D) uses the unit price of the predetermined access authority as the negotiation right fee.
(E) uses the prescribed fee as a member registration fee.
The community server according to claim 1, wherein: In a community server that provides community services on a communication network to a group to which at least one user belongs,
The user information that is information about the user specified by the user identification information, the group information that is information about the group that is specified by the group identification information, and the user identification information and the group identification information are associated with each other. User information group information storage means for storing affiliation information as information,
Seller information storage means for storing seller information, which is information related to the seller, specified by the seller identification information ;
Thread information storage means for storing thread information that is information related to a thread that is a collection of writes, specified by the thread identification information;
(A) receiving, from the seller terminal used by the seller , at least the seller identification information and the group identification information for the purpose of requesting sales activities for the group;
(B) At least the group of the group to which the user belongs, for the purpose of requesting the seller to request a product or service proposal from a user terminal used by the user belonging to the group Receiving identification information and the seller identification information;
When at least one of (a) and (b) is executed,
An access authority generation step for storing access authority information for associating at least the group identification information, the seller identification information, and the thread identification information for identifying a thread serving as a place of negotiation for performing a sales activity;
When receiving the seller identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the seller terminal, the seller identification information based on the access authority information A seller access determination step for permitting access to the thread specified by the thread identification information.
When receiving the user identification information and the thread identification information for the purpose of participating in the thread specified by the thread identification information from the user terminal, the access authority information, the affiliation information, , It is determined whether or not the user identification information is associated with the thread identification information via the group identification information, and if it is associated, the thread identified by the thread identification information is accessed. A user access determination step for allowing
At least the thread identification information intended to be written into the thread is identified from the user terminal permitted to access or the seller terminal permitted to access, and whether or not the seller is writing. Storing the information for writing and the written content together with the thread identification information in the thread information storing means together with the writing date and time as one writing record;
When receiving the thread identification information intended to refer to the thread from the user terminal permitted to access or the seller terminal permitted to access, based on the thread information storage means, Outputs the writing record, which is associated with the thread identification information that matches the received thread identification information, and includes at least information for identifying whether or not the seller is writing, writing contents, and writing date and time. Steps,
A thread write reference step comprising:
(C) When a commercial transaction is established between the user and the seller specified by the seller identification information as a result of using the thread, the seller specified by the seller identification information included in the access authority information On the other hand, processing to charge transaction brokerage fee,
(D) a process of charging a negotiating right fee to the seller specified by the seller identification information included in the access authority information;
(E) Based on the seller information storage means, the access authority generation means stores the seller identification information included in the access authority information, and as a result, the seller who may be able to access the thread. Processing to charge the membership registration fee,
A charging step for performing at least one of the processes (c), (d), and (e) of
To support group activities,
A group activity support step for permitting use of a group service provided to the group by a user terminal used by the user belonging to the group based on the user information group information storage means;
A community service providing method characterized by comprising: In the charging step,
(C), when order information including at least transaction amount information is received from the user terminal belonging to the group, a transaction brokerage fee is calculated by multiplying the transaction amount information by a predetermined transaction brokerage fee rate. To
(D) uses the unit price of the predetermined access authority as the negotiation right fee.
(E) uses the prescribed fee as a member registration fee.
The community service providing method according to claim 3, wherein:

Images