Information processing method, information processing program, and information processing apparatus

Abstract

To provide an information processing method, an information processing program, and an information processing apparatus for transmitting an evaluation of a business operator to another business operator.SOLUTION: An information processing method causes a computer to execute the processes of: acquiring account depositing / dispensing information of a business operator managed by a financial institution, or use data related to the use of a service of a platformer of the business operator; evaluating the business operator on the basis of the acquired account depositing / dispensing information or the use data; storing the evaluation result in association with disclosure propriety setting; and, upon receiving a request from a second business operator who has completed user registration, transmitting the evaluation result to a terminal of the second business operator if the disclosure propriety setting indicates disclosure.SELECTED DRAWING: Figure 17

Description

[Technical field]

[0001] The present invention relates to an information processing method, an information processing program, and an information processing device for transmitting evaluations of a business operator to another business operator. [Background technology]

[0002] In recent years, business matching using information processing technology has become common. To ensure accurate matching, each company needs to disclose its own information. The information to be disclosed may include confidential information, so it must be handled with care. In this regard, Patent Document 1 proposes an inter-company alliance support system that can promote inter-company alliances while preventing the leakage of confidential information. In this system, each company registers 1. its own information and 2. the conditions of the partner it wishes to partner with, and if the conditions of both companies match, an introduction is made. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2007-79963 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the above-mentioned business alliance support system, the information registered by a company is self-reported, so if the information registered is false, matching will be based on the false information. In addition, it is not possible to check the business viability of the other party. Furthermore, matching is only done by the system, and it is not expected that businesses themselves will actively search for business partners.

[0005] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide an information processing method, an information processing program, and an information processing device for transmitting evaluations of an enterprise to other enterprises. [Means for solving the problem]

[0006] An information processing method according to one embodiment of the present application includes a computer executing a process to acquire account deposit and withdrawal information of an operator managed by a financial institution, or usage data regarding the use of the operator's platform service, evaluate the operator based on the acquired account deposit and withdrawal information or usage data, store the evaluation result in association with a disclosure setting, and when a request is received from a second operator that has registered for use, if the disclosure setting is set to public, transmit the evaluation result to a terminal of the second operator. Effect of the Invention

[0007] In one aspect of the present application, a business's evaluation can be transmitted to other businesses. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an example of an ecosystem configuration. [Diagram 2] FIG. 2 is a block diagram showing an example of a hardware configuration of a server. [Diagram 3] FIG. 2 is a block diagram showing an example of a hardware configuration of a terminal. [Figure 4] FIG. 11 is an explanatory diagram showing an example of a user DB. [Diagram 5] FIG. 13 is an explanatory diagram illustrating an example of a linked account DB. [Figure 6] FIG. 13 is an explanatory diagram showing an example of a deposit / withdrawal DB. [Figure 7] FIG. 11 is an explanatory diagram showing an example of a platformer DB; [Figure 8] FIG. 13 is an explanatory diagram showing an example of a representative / business owner DB. [Figure 9] FIG. 13 is an explanatory diagram illustrating an example of a corporate DB. [Figure 10] FIG. 13 is an explanatory diagram showing an example of an individual evaluation DB. [Figure 11] FIG. 13 is an explanatory diagram showing an example of a business feasibility evaluation DB. [Figure 12] FIG. 13 is an explanatory diagram showing an example of a BCP evaluation DB. [Figure 13] FIG. 11 is an explanatory diagram showing an example of a comprehensive evaluation DB. [Figure 14] FIG. 13 is an explanatory diagram showing an example of a PF public DB. [Figure 15] 13 is a flowchart showing an example of a procedure for login processing. [Figure 16] 13 is a flowchart illustrating an example of a procedure for data linkage processing. [Figure 17] 13 is a flowchart showing an example of a procedure for evaluation result disclosure processing. [Figure 18] 13 is a flowchart showing an example of a procedure for public disclosure processing; [Figure 19] 13 is a flowchart illustrating an example of a procedure for a collaboration process with others. [Figure 20] 13 is a flowchart showing an example of a procedure for evaluation and authentication processing. [Figure 21] 13 is a flowchart showing an example of a procedure for a platformer evaluation process. [Figure 22] FIG. 11 is an explanatory diagram showing an example of a recommendation condition DB; [Diagram 23] 13 is a flowchart showing an example of a procedure for recommendation processing. [Figure 24] FIG. 11 is an explanatory diagram showing an example of an offer setting DB. [Diagram 25] 13 is a flowchart showing an example of an offer process procedure. [Figure 26] FIG. 4 is an explanatory diagram showing an example of a home screen. [Figure 27] FIG. 13 is an explanatory diagram showing an example of a diagnosis information screen. [Figure 28] FIG. 13 is an explanatory diagram showing an example of a public setting screen. [Figure 29] FIG. 13 is an explanatory diagram showing an example of a link addition screen. [Diagram 30] FIG. 13 is an explanatory diagram showing an example of a third-party collaboration setting screen. [Diagram 31] FIG. 13 is an explanatory diagram showing an example of a cooperation status screen. [Diagram 32] FIG. 13 is an explanatory diagram showing an example of an evaluation / certification request screen. [Diagram 33] FIG. 13 is an explanatory diagram showing an example of a joint purchasing item DB. [Diagram 34] FIG. 13 is an explanatory diagram showing an example of a proposal DB. [Diagram 35] FIG. 11 is an explanatory diagram showing an example of a participation acceptance DB. [Diagram 36] FIG. 11 is an explanatory diagram showing an example of a sales reception DB. [Figure 37] 13 is a flowchart showing an example of a procedure for item selection processing. [Figure 38] 13 is a flowchart showing an example of a procedure for item notification processing. [Figure 39] 13 is a flowchart showing an example of a procedure for item proposal processing. [Diagram 40] 13 is a flowchart showing an example of a procedure for participation acceptance processing. [Diagram 41] 13 is a flowchart showing an example of a procedure for sales reception processing. [Diagram 42] 13 is a flowchart showing an example of a procedure for purchase application processing. [Diagram 43] FIG. 13 is an explanatory diagram showing an example of an item selection screen. [Diagram 44] FIG. 13 is an explanatory diagram showing an example of an item notification screen (everyone's registration list). [Diagram 45] FIG. 13 is an explanatory diagram showing an example of an item proposal screen (my list). [Figure 46] FIG. 13 is an explanatory diagram showing an example of a participation reception screen (participation invitation list). [Figure 47] FIG. 13 is an explanatory diagram showing an example of a sales reception screen (list of items being offered for sale). [Figure 48] FIG. 13 is an explanatory diagram showing an example of a purchase application screen (joint purchase proposal list). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The following describes the embodiment with reference to the drawings. FIG. 1 is an explanatory diagram showing an example of the configuration of an ecosystem. It is assumed that the ecosystem 100 is operated by a financial institution. The ecosystem 100 aims to support the business of customers by providing services (data lending, management advice, business matching, etc.) equivalent to face-to-face services with high added value by evaluating the business viability and understanding the needs of participating companies through data. This is because it is desirable for the operator of the ecosystem 100 to be a company that is socially trusted, has transactions with a wide range of companies, and can securely hold highly confidential information.

[0010] The ecosystem 100 includes a server 1 and a terminal 2. Furthermore, a platformer 3 indicates a system capable of data linkage with the ecosystem 100. A platformer is an entity that provides and operates services and systems that serve as a platform connecting users and service providers on the Internet, and here, the computer system operated by the platformer will be referred to as the platformer 3.

[0011] A wide variety of services are expected to be provided by the platform 3. Examples of the platform 3 include an accounting system that provides accounting services mainly through cloud services, and a credit information system that provides services using a scoring model to assess credit risk.

[0012] Systems that provide AML (Anti-Money Laundering) services, eKYC, and personal credit information services are also examples of platform 3. AML services are services to prevent money laundering. eKYC (electronic Know Your Customer) is a service that provides identity verification online. Personal credit information services are services that provide personal credit information by credit information agencies. Personal credit information includes attribute information such as an individual's annual income, housing information, and place of employment, as well as payment information for loans, utility bills, etc.

[0013] The financial institution server 4 is a so-called accounting system server that manages account deposit and withdrawal information (account deposit and withdrawal information) at the financial institution. The financial institution server 4 constitutes an accounting system that manages account deposit and withdrawal information at the financial institution that operates the ecosystem 100, and this system is also an example of the platformer 3. In addition, the accounting systems of other financial institutions that can provide deposit and withdrawal information to the ecosystem 100 are also examples of the platformer 3.

[0014] The server 1, the terminal 2, the platformer 3, and the financial institution server 4 are connected to each other so as to be able to communicate with each other via a network N. The network N is the Internet, a general public network, a mobile phone network, a leased line network, or a virtual network such as a VPN (Virtual Private Network). The network N may also be a combination of these types of networks.

[0015] 2 is a block diagram showing an example of the hardware configuration of a server. The server 1 includes a control unit 11, a main memory unit 12, an auxiliary memory unit 13, a communication unit 14, and a reading unit 15. The control unit 11, the main memory unit 12, the auxiliary memory unit 13, the communication unit 14, and the reading unit 15 are connected by a bus B. The server 1 is configured with a server computer, a workstation, a PC (Personal Computer), etc. The server 1 may also be configured with a multicomputer consisting of multiple computers, a virtual machine virtually constructed by software, or a quantum computer. Furthermore, the functions of the server 1 may be realized by a cloud service.

[0016] The control unit 11 has one or more arithmetic processing devices such as a central processing unit (CPU), a micro-processing unit (MPU), a graphics processing unit (GPU), etc. The control unit 11 reads out and executes a control program 1P (program, program product) stored in the auxiliary storage unit 13, thereby performing various information processing, control processing, etc. related to the server 1, and realizes functional units such as an acquisition unit, an evaluation unit, and a transmission unit.

[0017] The main memory unit 12 is a static random access memory (SRAM), a dynamic random access memory (DRAM), a flash memory, etc. The main memory unit 12 mainly temporarily stores data necessary for the control unit 11 to execute arithmetic processing.

[0018] The auxiliary storage unit 13 is a hard disk or a solid state drive (SSD), etc., and stores the control program 1P and various DBs (databases) necessary for the control unit 11 to execute the process. The auxiliary storage unit 13 stores a user DB 131, a linked account DB 132, a deposit / withdrawal DB 133, a platformer DB 134, a representative / business owner DB 135, a corporation DB 136, an individual evaluation DB 137, a business feasibility evaluation DB 138, a BCP evaluation DB 139, a comprehensive evaluation DB 13A, a PF disclosure DB 13B, a usage DB 13C, a recommendation condition DB 13D, and an offer setting DB 13E, etc. The auxiliary storage unit 13 may be separate from the server 1 and may be an external storage device connected externally. The various DBs, etc. stored in the auxiliary storage unit 13 may be stored in a database server or cloud storage different from the server 1. The databases stored in the auxiliary storage unit 13 are not limited to those shown in FIG. 2, and the auxiliary storage unit 13 may store other databases as necessary.

[0019] The communication unit 14 communicates with the terminal 2, the platformer 3, and the financial institution server 4 via the network N. In addition, the control unit 11 may use the communication unit 14 to download the control program 1P from another computer via the network N or the like, and store it in the auxiliary storage unit 13.

[0020] The reading unit 15 reads the portable storage medium 1a including a CD (Compact Disc)-ROM and a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 15 and store it in the auxiliary storage unit 13. The control unit 11 may also read the control program 1P from the semiconductor memory 1b.

[0021] 3 is a block diagram showing an example of the hardware configuration of a terminal. The terminal 2 is a terminal used by an end user. End users include not only employees of companies participating in the ecosystem 100, but also employees of the platform provider 3, bank employees of financial institutions, and employees of other companies. The terminal 2 is composed of a notebook computer, a panel computer, a tablet computer, a smartphone, etc. The terminal 2 includes a control unit 21, a main memory unit 22, an auxiliary memory unit 23, a communication unit 24, an input unit 25, and a display unit 26. Each component is connected by a bus B.

[0022] The control unit 21 has one or more arithmetic processing devices such as a CPU, an MPU, a GPU, etc. The control unit 21 provides various functions by reading and executing a control program 2P (program, program product) stored in the auxiliary storage unit 23.

[0023] The main memory unit 22 is an SRAM, a DRAM, a flash memory, etc. The main memory unit 22 mainly temporarily stores data necessary for the control unit 21 to execute arithmetic processing.

[0024] The auxiliary storage unit 23 is a hard disk or an SSD, etc., and stores various data necessary for the control unit 21 to execute processing. The auxiliary storage unit 23 may be an external storage device that is separate from the terminal 2 and externally connected. The various DBs, etc. stored in the auxiliary storage unit 23 may be stored in a database server or cloud storage.

[0025] The communication unit 24 communicates with the server 1, the platformer 3, and the financial institution server 4 via the network N. In addition, the control unit 21 may use the communication unit 24 to download the control program 2P from another computer via the network N or the like, and store it in the auxiliary storage unit 23.

[0026] The input unit 25 is a keyboard and a mouse. The display unit 26 includes a liquid crystal display panel or the like. The display unit 26 displays the lending information and the like output by the server 1. The input unit 25 and the display unit 26 may be integrated to configure a touch panel display. The terminal 2 may display on an externally connected display device.

[0027] Next, the databases used in the ecosystem 100 will be described. FIG. 4 is an explanatory diagram showing an example of a user DB. The user DB 131 stores information on end users. The user DB 131 includes a user ID column, a type column, a name / name column, an email address column, and an identity verification column. The user ID column stores a user ID that can uniquely identify an end user. The type column stores the type of end user. The type is, for example, a corporation or a sole proprietor. Note that the end user may be an individual who runs a business other than a sole proprietor, for example, an office worker who runs a side job. The name / name column stores the name of the corporation or the name of the sole proprietor. The email address column stores the contact email address of the user. Note that an email address may be used as the user ID. In this case, the value of the user ID column and the value of the email address column may match. The identity verification column stores the identity verification status. "OK" indicates that identity verification has been completed. Other possible values ​​for the identity verification column include "Verifying" indicating that verification is in progress, and "NG" indicating that identity verification has failed. Registration for use of ecosystem 100 is completed upon completion of identity verification. The end users described below are users who have registered for use.

[0028] 5 is an explanatory diagram showing an example of a linked account DB. The linked account DB 132 stores end user information required for data linking with the platform provider 3. The linked account DB 132 includes a user ID column, a PFID column, and a token information column. The user ID column stores the user ID of the end user. The PFID column stores a PFID that can uniquely identify the platform provider 3 with which data is linked. The token information column stores the access token, refresh token, etc. granted by the platform provider 3.

[0029] FIG. 6 is an explanatory diagram showing an example of a deposit / withdrawal DB. The deposit / withdrawal DB 133 stores deposit / withdrawal information for bank accounts used by end users. The deposit / withdrawal DB 133 includes a user ID column, a bank code column, a branch number column, an account number column, an account type column, a type column, a date / time column, an amount column, a transfer destination column, and a balance column. The user ID column stores a user ID. The bank code column stores a bank code that identifies a bank. The branch number column stores the bank branch number. The account number column stores the account number. The account type column stores the type of account. Account types are, for example, ordinary, current, fixed term, and savings. The type column stores the type of transaction. Transaction types are, for example, deposit, withdrawal, and transfer. The date / time column stores the date and time when the transaction was performed. The amount column stores the amount transacted. The transfer destination column stores the transfer destination. The balance column stores the account balance. The deposit / withdrawal information stored in the deposit / withdrawal DB 133 is obtained from the financial institution server 4. The deposit / withdrawal DB 133 may be a temporary database, and when the deposit / withdrawal information is needed, the necessary deposit / withdrawal information may be obtained from the financial institution server 4 to construct the deposit / withdrawal DB 133. In addition, if the user uses Internet banking or an aggregation service, the deposit / withdrawal information may be obtained through these services with the user's permission to link. Financial institutions and aggregation service providers that operate Internet banking are also examples of platformers. The deposit / withdrawal information is referred to when conducting business feasibility evaluations, etc.

[0030] FIG. 7 is an explanatory diagram showing an example of a platformer DB. The platformer DB 134 stores information about the platformer 3 provided by the platformer 3. The platformer DB 134 includes an ID column, a name column, a link column, a tag column, and a rating column. The ID column stores an ID that uniquely identifies the platformer 3. The name column stores the name of the platformer 3. The link column stores link information for accessing the platformer 3. The link information is, for example, a URL (Uniform Resource Locator). The tag column stores tags that characterize the platformer 3. The rating column stores the rating value of the rating received from the end user.

[0031] FIG. 8 is an explanatory diagram showing an example of the representative / business owner DB. The representative / business owner DB135 stores information about the representative of the corporation when the end user is a corporation, and stores information about the sole proprietor when the end user is a sole proprietor. The representative / business owner DB135 includes a user ID column, a name column, a phone number column, an email column, and a mobile phone column. The user ID column stores the user ID. The name column stores the name of the representative or sole proprietor. The phone number column stores the phone number. The email column stores the email address of the representative or sole proprietor. The mobile phone column stores the mobile phone number of the representative or sole proprietor. Note that the contents stored in the representative / business owner DB135 can be stored in the user DB131, and it is not necessary to provide the representative / business owner DB135.

[0032] FIG. 9 is an explanatory diagram showing an example of a corporation DB. The corporation DB 136 stores information about corporations. The corporation DB 136 includes a corporation number column, a user ID column, a location column, a main telephone number column, a business content column, a website column, and an SNS column. The corporation number column stores the identification number of the corporation. The identification number is, for example, a 13-digit corporation number assigned by the National Tax Agency. Alternatively, a corporate identification code or a stock code assigned by a credit investigation agency may be used as the identification number. It is desirable that the identification number is stored, but it does not have to be stored. The user ID column stores the user ID. The location column stores the location of the corporation. The main telephone number column stores the main telephone number of the corporation. As for the telephone number, a number other than the main telephone number may be stored. The business content column stores the business content of the corporation. The website column stores the URL of the corporation's official homepage. The SNS column stores information on the corporation's official accounts on various SNS (Social Networking Services). It should be noted that the contents stored in the corporate DB 136 may be stored in the user DB 131, and the corporate DB 136 may not be provided.

[0033] FIG. 10 is an explanatory diagram showing an example of an individual evaluation DB. The individual evaluation DB 137 stores various evaluations by users. The individual evaluation DB 137 includes a user ID column, a category column, an evaluation ID column, a name column, a score column, an evaluation date column, a publication column, and a URL column. The user ID column stores a user ID. The category column stores the category of evaluation. The categories are business feasibility evaluation, BCP evaluation, health management evaluation, brand power, etc. Business feasibility evaluation is an evaluation that focuses on the business. BCP evaluation is an evaluation that focuses on the BCP (Business This is an evaluation that focuses on the Business Continuity Plan (BCP). Health management in the health management evaluation means considering employee health management from a management perspective and implementing it strategically. Health management evaluation evaluates whether health initiatives are being implemented from each perspective, from management to the workplace. The evaluation ID column stores an evaluation ID that can uniquely identify the evaluation method. The name column stores the name of the evaluation value obtained by the evaluation method. The score column stores the evaluation value. The evaluation date column stores the date the evaluation was performed. The publication column stores whether the evaluation results are to be made public to others (public / non-public setting). 1 indicates public, and 0 indicates private. The URL column stores the reference URL when the evaluation results are publicly available. Multiple evaluation methods may be used for each evaluation category. For example, the bank score is given as an example of one of the business feasibility evaluations, but other scores may also be used. However, it is desirable that the evaluation axis and range of evaluation values ​​and score ranges that are the basis of each score are standardized.

[0034] FIG. 11 is an explanatory diagram showing an example of a business feasibility evaluation DB. The business feasibility evaluation DB 138 stores the results of business feasibility evaluation. The business feasibility evaluation DB 138 includes a user ID column, an overall score column, a product strength column, a sales strength column, a technological development strength column, a manufacturing / purchasing power column, a customer base column, and an update date column. The user ID column stores the user ID of the user who was the subject of evaluation. The overall score column stores the overall score and score. The product strength column, sales strength column, technological development strength column, manufacturing / purchasing power column, and customer base column store the evaluation points of each evaluation axis, i.e., product strength, sales strength, technological development strength, manufacturing / purchasing power, and customer base, respectively. The update date column stores the date when the overall evaluation was updated. The overall score is, for example, the arithmetic mean or weighted average of the evaluation values ​​of each evaluation axis.

[0035] FIG. 12 is an explanatory diagram showing an example of a BCP evaluation DB. The BCP evaluation DB 139 stores the results of BCP evaluation. The BCP evaluation DB 139 includes a user ID column, a total score column, a management and philosophy policy column, an organizational structure column, a system and measure implementation column, and an evaluation and improvement column. The user ID column stores the user ID of the user who was the subject of the evaluation. The total score column stores the total score and score. The management and philosophy policy column, the organizational structure column, the system and measure implementation column, and the evaluation and improvement column store the evaluation points of each evaluation axis, i.e., the management and philosophy policy, the organizational structure, the system and measure implementation, and the evaluation and improvement, respectively. The total score is, for example, the arithmetic mean or weighted average of the evaluation values ​​of each evaluation axis.

[0036] As described in the explanation of the individual evaluation DB 137, in addition to the business feasibility evaluation and BCP evaluation, the user evaluation is assumed to be classified into health management evaluation, brand power, etc. For these evaluation results, a database similar to the business feasibility evaluation DB 138 and the BCP evaluation DB 139 is provided and the evaluation results are stored.

[0037] FIG. 13 is an explanatory diagram showing an example of a comprehensive evaluation DB. The comprehensive evaluation DB 13A stores comprehensive evaluations that are not limited to business feasibility evaluations, but also take into account evaluations of other categories (BCP evaluation, health management evaluation, brand power) and usage data of the platform 3 that is not used for business feasibility evaluations. The comprehensive evaluation DB 13A includes a user ID column, a total score column, a management efficiency column, a trading opportunity column, a competitive environment column, a market size column, and a fund raising necessity column. The user ID column stores the user ID of the user who is the subject of evaluation. The total score column stores the total score and score. The management efficiency column, the trading opportunity column, the competitive environment column, the market size column, and the fund raising necessity column store the evaluation points of each evaluation axis (common evaluation axis), that is, the management efficiency, the trading opportunity, the competitive environment, the market size, and the fund raising necessity. The total score is, for example, the arithmetic mean or weighted average of the evaluation values ​​of each evaluation axis.

[0038] FIG. 14 is an explanatory diagram showing an example of the PF public DB. The PF public DB 13B stores the public settings of the platformer 3 to others. When the user links the usage data of the platformer 3 with the ecosystem 100, the ecosystem 100 stores a copy of the usage data in the auxiliary storage unit 13 or the like. At this time, when the user allows the usage data to be disclosed to others, the others can refer to or obtain the usage data from the ecosystem 100. The PF public DB 13B includes a user ID column, a PFID column, and a public column. The user ID column stores the user ID of the user who owns the usage data. The PFID column stores the ID of the platformer 3 that is the source of the usage data. The public column stores the user ID of the other person who has published the usage data. When publishing the usage data to another platformer 3, the PFID of the destination platformer 3 is stored.

[0039] Although a detailed description will be omitted, in addition to the above databases, a usage DB 13C is stored in the auxiliary storage unit 13 of the server 1. The usage DB 13C is a collection of multiple databases or data tables, and stores end-user usage data acquired by the server 1 from the platform provider 3 as a result of the end user permitting data linkage with the platform provider 3.

[0040] Next, the processing performed in the ecosystem 100 will be described. Fig. 15 is a flow chart showing an example of the procedure of the login processing. The login processing is executed when an end user who has already registered accesses the ecosystem 100. The login processing is also started by accessing from the screen of a platform provider 3 participating in the ecosystem 100. It is assumed that an end user who newly registers as a user in the ecosystem 100 will register as a user by clicking a banner or the like displayed on the service screen of the platform provider 3.

[0041] The control unit 21 of the terminal 2 transmits a start request to the server 1 based on the link information embedded in the banner (step S1). The control unit 11 of the server 1 receives the start request (step S2). The control unit 11 transmits a login screen to the terminal 2 (step S3). The control unit 21 of the terminal 2 receives the login screen (step S4). The control unit 21 displays the login screen on the display unit 26 (step S5). If the end user has already registered in the ecosystem 100, the end user inputs an ID and a password to perform a login operation. If the end user has not yet registered in the ecosystem 100, the end user performs a registration operation. The control unit 21 determines whether the user's operation is registration (step S6). If the control unit 21 determines that the user's operation is registration (YES in step S6), the control unit 21 performs a user registration process (step S7). The user registration process is a process performed in cooperation with the server 1, but since it can be realized by a known technology, a description thereof will be omitted. When the control unit 21 determines that the user's operation is not registration (NO in step S6), or after the user registration process is completed, it sends a login request to the server 1 (step S8). The login request includes an ID and a password. The control unit 11 of the server 1 performs user authentication using the ID and password included in the login request (step S9). If the end user permits data linkage with the platformer 3, it is desirable to perform authentication using a one-time password during user authentication. This is to further reduce the risk of information leakage due to unauthorized access. The control unit 11 sends a home screen to the terminal 2 (step S10). The control unit 21 of the terminal 2 receives the home screen (step S11). The control unit 21 displays the home screen on the display unit 26 (step S12) and ends the process.

[0042] The ecosystem 100 evaluates users based on usage data of the platform provider 3. For this reason, users are required to permit data linkage between the platform provider 3 that they are using and the ecosystem 100. Therefore, when a user accesses the ecosystem 100 via the platform provider 3, a message urging the new user to set up linkage with the platform provider 3 may be displayed at the end of the login process. Also, for existing users, when accessing via the platform provider 3, it may be determined whether linkage with the platform provider 3 has already been set up, and if it is determined that linkage has not been set up, a message urging the new user to set up linkage with the platform provider 3 may be displayed at the end of the login process.

[0043] FIG. 16 is a flowchart showing an example of the procedure of the data linkage process. The data linkage process is started by the user selecting a link or the like displayed on the home screen. The control unit 21 of the terminal 2 transmits a request to start the data linkage process to the server 1 (step S31). The control unit 11 of the server 1 receives the request to start (step S32). The control unit 11 transmits a selection screen to the terminal 2 (step S33). The selection screen is a screen for selecting a platformer 3 with which linkage can be performed. The control unit 21 of the terminal 2 receives the selection screen and displays it on the display unit 26 (step S34). The end user selects a data linkage destination on the selection screen. The control unit 21 transmits a data linkage request to the platformer 3 selected by the end user as the data linkage destination (step S35). The platformer 3 receives the data linkage request (step S36). The platformer 3 transmits an input screen to the terminal 2 (step S37). The input screen is a screen for inputting information for logging in to the platformer 3. In many cases, it is a screen for requesting input of a user ID and password. The control unit 21 of the terminal 2 receives and displays the input screen (step S38). The end user inputs a user ID, a password, etc. via the input unit 25. The control unit 21 transmits login information such as the user ID and password to the platformer 3 (step S39). The platformer 3 receives the login information (step S40). After authenticating the user, the platformer 3 issues a token for linkage and transmits it to the server 1 (step S41). The control unit 11 of the server 1 receives the token and stores it in the linked account DB 132 (step S42). The control unit 11 uses the token to transmit a data request of the end user to the platformer 3 (step S43). The request includes the user ID of the end user. The platformer 3 receives the request (step S44). The platformer 3 extracts the end user's data based on the user ID (step S45). The platformer 3 transmits the extracted data to the server 1 (step S46). The control unit 11 of the server 1 receives the data and stores it in the usage DB 13C of the auxiliary storage unit 13 (step S47). The control unit 11 transmits the updated home screen to the terminal 2 (step S48).The control unit 21 of the terminal 2 receives and displays the home screen (step S49), and ends the process.

[0044] By setting up data linkage, the ecosystem 100 acquires and stores a copy of the usage data managed by the platformer 3. Since the usage data of the platformer 3 is updated daily, it is necessary to synchronize the usage data stored in the ecosystem 100. Synchronization may be performed at any time or periodically. Synchronization may also be performed in response to a user instruction. Usage data that is made public to others may be provided after synchronization when accessed by another person.

[0045] (Publication of evaluation results) As described above, the ecosystem 100 is capable of evaluating end users from multiple perspectives by utilizing financial account deposit and withdrawal information and usage data of the platform 3. The evaluation results are expected to contribute to the improvement of the end users' business operations, and may also be appealing when the end users become candidates for collaboration in business matching. The ecosystem 100 is capable of disclosing the evaluation results such as business feasibility evaluations, depending on the end users' settings. All evaluation results are set to private at the time they are created or updated.

[0046] FIG. 17 is a flowchart showing an example of the procedure of evaluation result disclosure processing. The end user performs a disclosure operation on a screen on which the evaluation results are displayed, such as a home screen. The control unit 21 of the terminal 2 accepts the operation (step 61). The control unit 21 judges whether or not to execute the disclosure process (step S62). The control unit 21 displays a pop-up window for confirming whether or not to execute the disclosure process, and prompts the end user to answer. If the control unit 21 judges not to execute the disclosure process based on the answer (NO in step S62), it ends the process. If the control unit 21 judges to execute the disclosure process based on the answer (YES in step S62), it transmits a disclosure instruction to the server 1 (step S63). The disclosure instruction includes the evaluation ID of the evaluation to be published. The control unit 11 of the server 1 receives the disclosure instruction (step S64). The control unit 11 searches the individual evaluation DB 137 using the end user's user ID and the evaluation ID as search keys. The control unit 11 sets the value of the disclosure column of the hit record to the value "1" indicating disclosure (step S65). The control unit 11 transmits an update screen indicating that the evaluation results are being made public to the terminal 2 (step S66). The control unit 21 of the terminal 2 receives the update screen and displays it on the display unit 26 (step S67). The control unit 21 ends the process. The evaluation results that are set to be made public can be referenced by end users (second businesses) of the ecosystem 100. The evaluation results to be made public may include not only the total score, but also the evaluation values ​​of each evaluation axis that are the basis for calculating the total score.

[0047] By publishing the evaluation results, end users (business operators) can send their own evaluations to other end users. The evaluation results are based on usage data acquired from the platform 3. Therefore, unlike information self-reported by end users, the evaluations are highly reliable and accurate. When end users consider collaboration such as business alliances, they can mutually confirm the evaluations such as business feasibility evaluations before considering the collaboration. As a result, it is possible to reduce the risk that the collaboration will fail midway. As a result, the effect is that each end user will be proactive in looking for a collaboration partner (business partner) using the ecosystem 100 to solve the problems they are facing and for their own development.

[0048] (Open to the public) Evaluation results that are set to be made public can only be viewed by end users registered with ecosystem 100, but may also be made publicly available. In other words, the evaluation results may be made accessible to third parties (other businesses) that are not registered with ecosystem 100. The publicly available evaluation result screen is a screen that displays only the evaluation results. In addition, it is assumed that the screen is accessed directly using the issued URL, rather than being accessible by transitioning from another screen.

[0049] FIG. 18 is a flowchart showing an example of the procedure of the public disclosure process. The end user performs an instruction operation to publicly disclose the evaluation results set for public disclosure in the ecosystem 100 on a home screen or the like. The control unit 21 of the terminal 2 accepts the operation (step 81). The control unit 21 of the terminal 2 determines whether or not to execute the public disclosure process (step S82). The control unit 21 displays a pop-up window for confirming whether or not to execute the public disclosure process, and prompts the end user to answer. If the control unit 21 determines not to execute the public disclosure process based on the answer (NO in step S82), the process ends. If the control unit 21 determines to execute the public disclosure process based on the answer (YES in step S82), the control unit 21 transmits a public disclosure instruction to the server 1 (step S83). The public disclosure instruction includes the evaluation ID of the evaluation to be made public. The control unit 11 of the server 1 receives the public disclosure instruction (step S84). The control unit 11 searches the individual evaluation DB 137 using the end user's user ID and the evaluation ID as search keys. Based on the hit records, the control unit 11 creates a public page that makes the evaluation results publicly available (step S85). The control unit 11 stores the created page (step S86). The control unit 11 issues a public URL (step S87). The control unit 11 creates a notification screen for the URL (step S88). The control unit 11 sends an update screen indicating that the evaluation results are publicly available to the terminal 2 (step S89). The notification screen has a notification screen embedded in it. The control unit 21 of the terminal 2 receives the update screen and displays it on the display unit 26 (step S90). At this time, the control unit 21 displays the notification screen as a pop-up. The issued URL is stated on the notification screen. The control unit 21 ends the process.

[0050] The end user publishes the issued URL on social media etc. By using the published URL, even general users who are not registered in the ecosystem 100 can refer to the evaluation results.

[0051] (Utilization of usage data) Next, the use of the usage data will be described. First, the disclosure of the usage data will be described. FIG. 19 is a flowchart showing an example of a procedure for a third-party collaboration process. The end user selects a platformer 3 for which usage data is to be published to other end users from a list of platformers 3 for which data collaboration has already been set and is displayed on the home screen. The control unit 21 of the terminal 2 transmits a request for third-party collaboration setting to the server 1 (step S101). The request includes the PFID of the selected platformer 3. The control unit 11 of the server 1 receives the request (step S102). The control unit 11 transmits a setting screen to the terminal 2 (step S103). The control unit 21 of the terminal 2 receives and displays the setting screen (step S104). The end user sets the party to which the usage data is to be published on the setting screen. If a specific party has been decided, the party is specified. If, instead, the data is to be published to unspecified end users of the ecosystem 100 or to external businesses certified by the operator of the ecosystem 100, the user sets this to that effect. The end user performs a setting completion operation. The control unit 21 accepts the operation (step S105). The control unit 21 judges whether or not to execute the other party cooperation process (step S106). The control unit 21 displays a pop-up window for confirming whether or not to execute the other party cooperation process, and prompts the end user to answer. When the control unit 21 judges not to execute the other party cooperation process based on the answer (NO in step S106), the control unit 21 ends the process. When the control unit 21 judges to execute the other party cooperation process based on the answer (YES in step S106), the control unit 21 sends a setting instruction to the server 1 (step S107). The control unit 11 of the server 1 receives the setting instruction (step S108). The control unit 11 stores the user ID of the disclosure partner in the disclosure column of the corresponding record of the PF disclosure DB 13B (step S109). The control unit 11 sends a completion screen to the terminal 2 (step S110). The control unit 21 of the terminal 2 receives and displays the completion screen (step S111). The control unit 21 ends the process.

[0052] The end user notifies the end user of the completion of the settings. The notification may be performed by the server 1 in the third-party collaboration process. The other end user refers to or acquires the published usage data using a predefined API (Application Programming Interface) or the like.

[0053] (Evaluation and authentication functions) Next, the evaluation and authentication function will be described. As described above, in the ecosystem 100, end users can receive various evaluations. It is expected that the results will help end users to extract management and business issues. These evaluations can be performed not only by the server 1, but also by a support business that supports the operation of the ecosystem 100. The support business is a business that provides a service that evaluates various corporate activities from a third-party perspective (evaluation business). Support businesses also include businesses that provide an authentication service that determines whether the evaluation results meet a predetermined standard and certifies that the standard is met if the standard is met.

[0054] FIG. 20 is a flow chart showing an example of the procedure of the evaluation / authentication process. The end user operates the terminal 2 to select the evaluation / authentication function. In response to this, the control unit 21 transmits a list request to the server 1 (step S121). The control unit 11 of the server 1 receives the list request (step S122). The control unit 11 transmits the list to the terminal 2 (step S123). The list is a list of evaluation / authentication services that the user can use. The list includes the usage data of the platform provider 3 that is required to be made public in order to receive the service, and information on the support provider that provides the service. The control unit 21 of the terminal 2 receives the list and displays it (step S124). The end user inputs settings such as selecting the evaluation / authentication service that the end user wants to use and agreeing to make the usage data public to the support provider. The control unit 21 accepts the settings (step S125). The control unit 21 transmits the settings to the server 1 (step S126). If the end user has not input settings to consent to the disclosure of the usage data to the support provider, the process may be returned to step S125 after displaying a message requesting consent without executing step S126. The control unit 11 of the server 1 receives the settings (step S127). The control unit 11 receives the setting input to consent to the disclosure in step S125, and sets the usage data required for evaluation and authentication, which has not been set for disclosure by the end user, to be disclosed to the support provider (step S128). The control unit 11 transmits an evaluation and authentication request to the support provider (step S129). The support provider receives the request (step S130). The support provider transmits a request for the usage data required for evaluation and authentication to the server 1 (step S131). The control unit 11 of the server 1 receives the request for the usage data (step 132). The control unit 11 acquires the requested usage data from the usage DB 13C and transmits it to the support provider (step S133). The support provider receives the usage data (step S134). The support provider performs evaluation and authentication (step S135). The support provider transmits the result of the evaluation and authentication to the server 1 (step S136). The control unit 11 of the server 1 receives the result (step S137). The control unit 11 stores the result in the individual evaluation DB 137 or the like (step S138).The control unit 11 transmits a notification to the effect that the evaluation and authentication have been completed to the terminal 2 (step S139). The control unit 21 of the terminal 2 receives and displays the notification (step S140). The control unit 21 then ends the process.

[0055] End users refer to the evaluation and certification results of support businesses and make improvements to their operations and corporate culture, etc. They also make the evaluation and certification results public to other end users and the general public for advertising and PR activities.

[0056] (Platformer evaluation) Next, the evaluation of the platform maker 3 will be explained. In the ecosystem 100, it is expected that end users will utilize the platform maker 3 to promote digital transformation, which will in turn improve business performance and customer satisfaction. Therefore, the role of the platform maker 3 is important, and it is desirable for the platform maker 3 to provide better services to end users. Therefore, in the ecosystem 100, the platform maker 3 will be evaluated by end users.

[0057] FIG. 21 is a flowchart showing an example of the procedure of the platform evaluation process. The platform 3 to be evaluated may be a specific platform 3, a platform 3 that provides a specific service, for example, a platform 3 that provides an inventory management service, or all platform 3. In addition, the platform may be a platform that has not yet joined the ecosystem 100 (= a platform that cannot perform data linkage). The control unit 11 of the server 1 transmits an evaluation request to the terminal 2 of one end user (step S151). The transmission method uses e-mail, push notification, a message service provided by the ecosystem 100, a pop-up screen displayed when the end user accesses, or the like. The end users to be transmitted include a specific end user, an end user who uses the platform 3 to be evaluated, an end user who does not use the platform 3 to be evaluated but uses another platform 3 that provides a similar service, all end users, etc. The administrator appropriately determines the evaluation method according to the purpose of the evaluation. The control unit 21 of the terminal 2 receives the evaluation request (step S152). The end user inputs a response to whether or not he / she cooperates with the evaluation to the terminal 2. The control unit 21 transmits the response to the server 1 (step S153). The control unit 11 of the server 1 receives the response (step S154). The control unit 11 judges whether or not the end user has accepted the request (step S155). If the control unit 11 judges the request as a refusal (NO in step S155), the process ends. If the control unit 11 judges the request as an acceptance (YES in step S155), the control unit 11 transmits a response screen to the terminal 2 (step S156). The control unit 21 of the terminal 2 receives the response screen (step S157). The control unit 21 displays the response screen (step S158). The end user inputs a response. The control unit 21 accepts the response (step S159). The control unit 21 transmits the response to the server 1 (step S160). The control unit 11 of the server 1 receives the response (step S161). The control unit 11 stores the answers (step S162). Note that the answer screen may be a plurality of screens, and steps S156 to S162 may be repeated as necessary. The control unit 11 determines whether the number of respondents has reached a predetermined number (step S163).When the control unit 11 determines that the number of respondents has not reached the specified number (NO in step S163), it ends the process. The evaluation and authentication process is executed for each end user who is the answering target. In addition, the evaluation and authentication process is repeatedly executed until the number of respondents reaches the specified number or until a predetermined period of time has passed. When the control unit 11 determines that the number of respondents has reached the specified number (YES in step S163), it updates the evaluation of the platformer 3 (step S164). The evaluation finally becomes one value as a total score, and is stored in the evaluation column of the platformer DB 134. Note that, similar to the evaluation of the end user, the evaluation value for each evaluation item that is the basis of the total score may be stored in the auxiliary storage unit 13. The control unit 11 transmits a notification to the platformer 3 whose evaluation has been updated (step S165). The platformer 3 receives the notification (step S166). The platformer 3 transmits the receipt of the notification to the server 1 (step S167). The control unit 11 of the server 1 receives the receipt and stores it (step S168). The control unit 11 ends the process.

[0058] If the end user responds to the evaluation request by accepting it, it is desirable to store that fact so that the same request is not sent to the end user multiple times. If the end user rejects the evaluation request and does not respond, that fact may be stored so that the same request is not sent to the end user multiple times, or the request may be sent multiple times until a response is received.

[0059] The notification that the evaluation of the platform provider 3 has been updated may be sent to the end user who performed the evaluation and to end users who use the platform provider 3. In addition, it is preferable that the evaluation of the platform provider 3 be accessible to any end user of the ecosystem 100, regardless of whether or not the end user is using the platform provider 3.

[0060] It is assumed that the evaluation results for the platform provider 3 are expressed as numerical values, but comments from end users who have evaluated may be stored in the auxiliary storage unit 13 and made available for reference by the platform provider 3 and other end users.

[0061] Platformer 3 will refer to the evaluation results and use them to improve its services. End users will refer to the evaluation results as material when considering new uses of Platformer 3 or switching to Platformer 3.

[0062] (Recommendation function) Next, we will explain the recommendation function, which recommends the use of platform 3 that will contribute to business growth based on the end user's evaluation and authentication results.

[0063] FIG. 22 is an explanatory diagram showing an example of a recommendation condition DB. The recommendation condition DB 13D stores tasks derived from the evaluation and authentication results and the conditions of the platform provider 3 to recommend in association with each other. The recommendation condition DB 13D includes a task string and a recommendation string. The task string stores tasks derived from the evaluation and authentication results. The recommendation string stores the conditions of the platform provider to recommend.

[0064] FIG. 23 is a flowchart showing an example of the procedure of the recommendation process. It is assumed that the recommendation process is executed periodically as a batch process. The control unit 11 of the server 1 extracts the target end users (step S181). For example, the control unit 11 extracts end users whose evaluation and authentication information has been updated within 24 hours. The control unit 11 selects one end user to be processed from the extracted end users (step S182). The control unit 11 refers to the evaluations of the end users stored in the individual evaluation DB 137, the business feasibility evaluation DB 138, the BCP evaluation DB 139, and the overall evaluation DB 13A, and attempts to extract an issue stored in the issue column of the recommendation condition DB 13D (step S183). The control unit 11 determines whether or not there is an extracted issue (step S184). If the control unit 11 determines that there is no extracted issue (NO in step S184), the control unit 11 advances the process to step S188. When the control unit 11 determines that there is an extracted problem (YES in step S184), it uses the recommendation column in the recommendation condition DB 13D to select a platform provider 3 to be recommended (step S185). For example, the value of the recommendation column is stored in the tag column of the platform provider DB 134 to select the platform provider 3. The control unit 11 creates a message recommending the use of the selected platform provider 3 (step S186). The control unit 11 transmits the message to the end user or sets the transmission (step S187). When e-mail or push notification is used as a transmission means, the control unit 11 transmits the message. When a pop-up screen is displayed when the end user logs in, the control unit 11 sets the pop-up screen to be transmitted. The control unit 11 determines whether or not there is an unprocessed end user (step S188). When the control unit 11 determines that there is an unprocessed end user (YES in step S188), the control unit 11 returns the process to step S182 and performs the process for the unprocessed end user. When the control unit 11 determines that there is no unprocessed end user (NO in step S188), the process ends.

[0065] The message sent to the end user recommending the use of the platform provider 3 includes the extracted issues, the name of the platform provider 3, the services provided, evaluations, etc. The platform provider 3 may be notified that the message has been sent to the end user.

[0066] The recommendation process may be executed when the end user logs in. In this case, the control unit 11 of the server 1 executes steps S183 to S187 shown in Fig. 23. Alternatively, the end user may execute the process explicitly. A problem that the end user recognizes may be input, and a recommendation for solving the problem may be made.

[0067] (Offer feature) The offer function will be described. The offer function is a function for an end user to offer a transaction to another end user (candidate business operator), or for the platformer 3 to an end user. FIG. 24 is an explanatory diagram showing an example of an offer setting DB. The offer setting DB 13E includes a user ID column, a PFID column, a task column, an industry column, and a message column. The user ID column stores the user ID of an end user who makes an offer to another end user. The PFID column stores the PFID of the platformer 3 who makes an offer to an end user. Only one of the user ID column and the PFID column may store a value. The task column stores a task faced by the end user who is the target of the offer. The industry column stores the industry of the end user who is the target of the offer. If no particular industry is required, set to "all industries". The message column stores a message to be sent to the target end user as an offer. The contents stored in the offer setting DB 13E are set in advance by the end user who makes the offer or the platformer 3.

[0068] FIG. 25 is a flowchart showing an example of the procedure of the offer process. It is assumed that the offer process is executed periodically as a batch process. The control unit 11 of the server 1 selects one record of the offer setting DB 13E to be targeted (step S201). The control unit 11 refers to the problem column of the offer setting DB 13E and the end user evaluations stored in the individual evaluation DB 137, the business feasibility evaluation DB 138, the BCP evaluation DB 139, and the overall evaluation DB 13A, and extracts end users who are presumed to have the corresponding problem (step S202). The control unit 11 creates a message to be sent to the end user (step S203). The control unit 11 sends the message to the end user or sets it to be sent (step S204). The content of step S204 is the same as step S187 in FIG. 23. The control unit 11 determines whether there is an unprocessed record (step S205). If the control unit 11 determines that there is an unprocessed record (YES in step S205), the control unit 11 returns the process to step S201 and processes the unprocessed record. If the control unit 11 determines that there is no unprocessed record (NO in step S205), the control unit 11 ends the process.

[0069] In the offer function, the end user or platformer 3 making the offer sets conditions in advance, and the ecosystem 100 makes offers to end users who meet the conditions, so that the end user or platformer 3 can make offers efficiently. Note that the recommendation function and the offer function are examples of a matching function.

[0070] Next, a description will be given of examples of screens displayed on the terminal 2. Fig. 26 is an explanatory diagram showing an example of a home screen. The home screen d01 includes a profile d011, an evaluation / authentication area d012, a link area d013, a command area d014, and a screen area d015.

[0071] The profile d011 displays the end user's profile, etc. The profile d011 includes a basic information area d0111, a business content area d0112, an edit button d0113, a homepage link button d0114, and an SNS link button d0115. The basic information area d0111 displays the end user's location, name, and representative name. The business content area d0112 displays the business content. When the edit button d0113 is selected, a screen for editing the basic information and business content is displayed, and editing becomes possible. However, in order to ensure the reliability of the information, after the operator authenticates and confirms the identity of the user, the edited content is not reflected immediately, and is treated as a change notification to the operator. The homepage link button d0114 is set to a link to the end user's official homepage. The SNS link button d0115 is set to a link to various SNS accounts of the end user. SNSs include those for exchanging short messages, SNSs that are mainly bulletin boards, and SNSs that are mainly for sharing photos.

[0072] The evaluation / certification area d012 includes a score display area d0121, a public display area d0122, a graph area d0123, and a confirmation button d0124. The score display area d0121 displays the evaluation / certification score of the end user. In FIG. 26, the scores for the business feasibility evaluation, BCP evaluation, health management evaluation, and brand power are displayed. These scores are expected to contribute to extracting issues to be solved, such as management issues and business issues, for the end user. The public display area d0122 shows the public / private status of the score. The graph area d0123 displays one score and the evaluation value of each evaluation item that is the basis of the score in a radar chart. In FIG. 26, the result of the bank score, which is one of the business feasibility evaluations, is displayed. When the graph area d0123 is clicked with the mouse, a pull-down menu may be displayed so that the evaluation results displayed in the graph area d0123 can be switched. The public display area d0122 displays whether each score is public to other end users or not. When the public display area d0122 is clicked with the mouse, a pull-down menu may be displayed, allowing the corresponding score to be switched between public and private. Furthermore, the menu may include public access, and when public access is selected, a pop-up screen may be displayed showing a URL for public access. When the confirmation button d0124 is selected, a new window is displayed, showing details of all scores displayed in the score display area d0121, such as the evaluation values ​​for each evaluation item.

[0073] The linkage area d013 includes a linked platform area d0131, a third party link button d0132, a link confirmation button d0133, a download button d0134, and an add button d0135. The linked platform area d0131 displays the platform 3 with which data is linked. When the third party link button d0132 is selected, a setting screen is displayed, allowing the user to configure settings for linking usage data of the platform 3 with others via the ecosystem 100. When the link confirmation button d0133 is selected, a confirmation screen is displayed, allowing the user to confirm the link destination. When the download button d0134 is selected, usage data can be downloaded. When the add button d0135 is selected, a screen is displayed for adding a platform 3 with which data is linked.

[0074] FIG. 27 is an explanatory diagram showing an example of a diagnostic information screen. The diagnostic information screen d02 is a screen that is displayed when, for example, the confirmation button d0124 on the home screen d01 is selected. The diagnostic information screen d02 is a screen that displays the evaluation value of each evaluation item for all scores obtained by the end user as a result of evaluation and authentication. The diagnostic information screen d02 includes a total score area d021, a radar chart d022, an item table d023, an update button d024, and an add button d025. The total score area d021 displays the end user's total score together with the name of the score. It also includes the average score of all users. The radar chart d022 displays the evaluation value of each evaluation item that is the basis of the total score. The item table d023 is a list showing the evaluation value of each evaluation item. By selecting the update button d024, it is possible to request a re-evaluation based on the latest usage data. The total score area d021, the radar chart d022, the item table d023, and the update button d024 are displayed repeatedly for the number of scores to be displayed. When you select the Add button d025, a request screen for receiving a new evaluation and certification will be displayed.

[0075] FIG. 28 is an explanatory diagram showing an example of a public setting screen. The public setting screen d03 is a screen that is displayed when, for example, detailed setting is selected in a pull-down menu displayed by clicking the public display area d0122 with a mouse on the home screen d01. The public setting screen d03 includes a name area d031, a list d032, a selection box d033, a select all box d034, a setting button d035, a cancel button d036, a URL display d037, an update button d038, and a copy button d039. The name area d031 displays the name of the score to be set. The list d032 displays the total score and the evaluation value of each evaluation item that is the basis of the total score. A plurality of selection boxes d033 are provided corresponding to the total score or each evaluation value. When a selection box d033 is checked, the corresponding score is made public, and when the selection box d033 is not checked, the corresponding score is not made public. The select all box d034 is for setting the check state of all selection boxes d033 to the same state at once. When the setting button d035 is selected, the settings are reflected and the screen closes. When the cancel button d036 is selected, the settings are not reflected and the screen closes. When the URL display d037 is selected, the URL for accessing the content is displayed when the content is made public. When the update button d038 is selected, the URL is updated and the previous URL becomes invalid. When the copy button d039 is selected, the URL is copied to the clipboard. Note that the name area d031 to the cancel button d036 and the URL display d037 to the copy button d039 may be configured on separate screens.

[0076] FIG. 29 is an explanatory diagram showing an example of a link addition screen. The link addition screen d04 is a screen displayed when, for example, the Add button d0135 is selected on the home screen d01. The link addition screen d04 includes a platform area d041, a link button d042, a linking button d043, a stop button d044, and a close button d045. Depending on the state, an authentication sub-screen d046 is overlaid. The platform area d041 displays the name of a platform with which data linking is possible. When the link button d042 is selected, data linking is started. The linking button d043 is displayed instead of the link button d042 when data linking has already been performed with the platform 3 displayed in correspondence. Nothing happens when the linking button d043 is operated. By operating the stop button d044, data linking with the platform 3 displayed in correspondence can be stopped. The stop button d044 corresponding to a platform 3 with which data linking has not yet been performed is in an inoperable state. When the close button d045 is selected, the link addition screen d04 is closed.

[0077] The authentication sub-screen d046 is displayed when the link button d042 is selected. The authentication sub-screen d046 is a screen for obtaining authentication from the platformer 3 to start data linkage, and includes an ID field d0461, a password field d0462, an OK button d0463, and a cancel button d0464. In the ID field d0461, an ID given by the platformer 3 is entered. The ID is a login ID or an ID given for data linkage. In the password field d0462, a password corresponding to the ID is entered. When the OK button d0463 is selected, an authentication request is sent to the platformer 3, and once the platformer 3 has authenticated, data linkage is started. When the cancel button d0464 is selected, the data linkage settings are interrupted.

[0078] FIG. 30 is an explanatory diagram showing an example of a third party collaboration setting screen. The third party collaboration setting screen d05 is a screen displayed when the third party collaboration button d0132 is selected on the home screen d01, for example. The third party collaboration setting screen d05 includes a platformer area d051, a select all button d052, a specific button d053, a search box d054, a search button d055, a candidate field d056, a selected field d057, an add button d058, a delete button d059, a confirm button d05A, and a cancel button d05B. The platformer area d051 displays the name of the platformer 3 to be collaborated. When the select all button d052 is selected, the collaboration destination to which data is to be disclosed is set to all support businesses. When the specific button d053 is selected, only the specified end user or support business becomes the collaboration destination. The search box d054 is a field for inputting search conditions. Part of the name or ID of the end user or support business to be the collaboration destination is input. When the search button d055 is selected, a search is performed according to the search box d054, and the results are displayed in the candidate column d056. The selected column d057 displays the end user or support provider selected as the collaboration partner. By operating the add button d058, it is possible to select the end user or support provider displayed in the candidate column d056. By operating the delete button d059, it is possible to deselect the end user or support provider selected as the collaboration partner. When the confirm button d05A is operated, the collaboration settings are reflected and the screen closes. When the cancel button d05B is operated, the collaboration settings are not reflected and the screen closes.

[0079] FIG. 31 is an explanatory diagram showing an example of a collaboration status screen. The collaboration status screen d06 is a screen displayed when the collaboration confirmation button d0133 is selected on the home screen d01, for example. The collaboration status screen d06 includes a platformer area d061, a collaboration destination area d062, a change button d063, and a close button d064. The platformer area d061 displays the name of the platformer 3. The collaboration destination area d062 displays the end user or support business that is the collaboration destination. When the change button d063 is selected, the screen transitions to the third party collaboration setting screen d05. At that time, the end user or support business displayed in the collaboration destination area d062 is transferred to the selected column d057 of the third party collaboration setting screen d05. In the transitioned third party collaboration setting screen d05, it is possible to add or delete a collaboration destination. When the close button d064 is selected, the screen closes.

[0080] FIG. 32 is an explanatory diagram showing an example of an evaluation / certification request screen. The evaluation / certification request screen d07 is a screen displayed when, for example, the add button d025 is selected on the diagnosis information screen d02. The evaluation / certification request screen d07 includes a selection box d071, an approval box d072, a request button d073, and a cancel button d074. When the selection box d071 is checked, the corresponding support business is selected as the request destination. When the approval box d072 is checked, the end user agrees that the ecosystem 100 (server 1) will set the support business as the usage data link destination of the platform 3 in order to obtain data required by the support business for evaluation / certification. If the approval box d072 is not checked, a request cannot be made. When the request button d073 is operated, an evaluation / certification request is sent to the selected support business, and the screen closes. When the cancel button d074 is operated, the screen closes.

[0081] The main memory unit 12 of the server 1 further stores a joint purchasing item DB, a proposal DB, a participation acceptance DB, and a sales acceptance DB, which are used when performing processing related to joint purchasing in the ecosystem 100. Although details will be described later, in the joint purchasing item DB, the proposal DB, the participation acceptance DB, and the sales acceptance DB, items may be used as primary keys, and normalization may be performed between these DBs.

[0082] FIG. 33 is an explanatory diagram showing an example of a joint purchase item DB. The joint purchase item DB has item numbers and item fields as management items. The item number field stores a number or the like that uniquely identifies a product or item that is the subject of a joint purchase. In this embodiment, the item number is used as a primary key. The item field stores the product name or the like of the corresponding item number.

[0083] Regarding registration in the joint purchasing item DB, a seller who sells a product or the like may register the product that the seller himself / herself sells among end users (businesses, platformers 3) who are registered in the ecosystem 100. Alternatively, registration in the joint purchasing item DB may be performed by an end user (business) who is registered in the ecosystem 100 and wishes to purchase a product or the like. Alternatively, the ecosystem 100 may periodically or regularly access an EC site or the like via the Internet or the like to acquire information on products sold on the EC site, and register the acquired information in the joint purchasing item DB.

[0084] FIG. 34 is an explanatory diagram showing an example of a proposal DB. The joint purchasing item DB has the following fields for management: product number, user ID of proposer, willing to buy ID (user ID who clicked willing to buy), willing to sell ID (user ID who clicked willing to sell), desired unit price, quantity, solicitation deadline, threshold, status (notice, proposal, purchase application), and seller's user ID. The product number field stores the product number stored in the joint purchasing item DB, and the proposal DB is normalized by this. The user ID of proposer stores the user ID of the end user who proposed the joint purchasing for the corresponding product number. The willing to buy ID field stores the user ID of the end user who clicked willing to buy for the corresponding product number. The willing to sell ID field stores the user ID of the end user who clicked willing to sell for the corresponding product number. The desired unit price field stores the desired unit price input by the proposer for the corresponding product number. The quantity field stores the quantity (quantity desired to purchase) input by the proposer for the corresponding product number. The solicitation deadline field stores the solicitation deadline entered by the proposer for the corresponding product number. The threshold field stores the threshold entered by the proposer for the corresponding product number (for example, the lower limit of the overall score in the overall evaluation). The status field stores the status of the corresponding product number according to the progress of the joint purchase, and the statuses include announcement, proposal, and purchase application. Each of these statuses will be described later. The seller's user ID field stores the user ID of the seller selected by the proposer for the corresponding product number.

[0085] Fig. 35 is an explanatory diagram showing an example of a participation acceptance DB. The participation acceptance DB has fields for product number, participant user ID, and quantity as management items. The product number field stores the product number stored in the joint purchasing item DB, which normalizes the participation acceptance DB. The participant user ID field stores the user ID of the end user (participant) who has applied to participate for the corresponding product number. The quantity field stores the quantity (desired purchase quantity) entered by the end user who has applied to participate for the corresponding product number.

[0086] FIG. 36 is an explanatory diagram showing an example of a sales reception DB. The sales reception DB has items for management, such as item number, seller's user ID, and unit sales price. The item number field stores the item number stored in the joint purchasing item DB, which normalizes the sales reception DB. The seller's user ID field stores the user ID of the end user (seller) who has applied to sell for the corresponding item number. The unit sales price field stores the unit sales price entered by the end user who has applied to sell for the corresponding item number.

[0087] 37 is a flowchart showing an example of a procedure for item selection processing. The item selection processing is started when an end user selects a link or the like displayed on a home screen.

[0088] The control unit 21 of the terminal 2 transmits a request to start the item selection process to the server 1 (step U101). In response to the request to start received from the terminal 2, the control unit 11 of the server 1 transmits an item selection screen to the terminal 2 (step T101). A request to start the item selection process is transmitted from the terminal 2 used by the end user to the server 1 by an operation of the business operator (end user) who is the initiator. In response to the request to start, the control unit 11 of the server 1 generates screen data for the item selection screen, for example, configured with html, and transmits it to the terminal 2 that is the sender of the request to start. The control unit 11 of the server 1 may refer to a joint purchasing item DB when generating the item selection screen. The joint purchasing item DB stores the items and product numbers of products that can be handled in the ecosystem 100 as so-called master data, and the product number functions as a primary key that uniquely identifies the item.

[0089] The control unit 21 of the terminal 2 displays the item selection screen received from the server 1 and transmits the part number accepted on the item selection screen to the server 1 (step U102). The control unit 21 of the terminal 2 receives the item selection screen from the server 1 and displays the item selection screen on a display unit such as a display. The control unit 21 of the terminal 2 receives a part number selection operation performed by the end user on the item selection screen. The part number selection operation may be, for example, a function button (a function button arranged next to a part number) displayed on the item selection screen, by pressing the part number corresponding to the function button. The control unit 21 of the terminal 2 transmits the part number accepted on the item selection screen, i.e., the part number selected by the end user, to the server 1. At this time, the control unit 21 of the terminal 2 may associate the part number with the user ID of the end user and transmit it to the server 1.

[0090] The control unit 11 of the server 1 updates the proposal DB according to the product number received from the terminal 2 (step T102). The control unit 11 of the server 1 updates the proposal DB by, for example, adding a new record in the proposal DB according to the product number and user ID received from the terminal 2. The added record in the proposal DB includes the user ID of the end user who will be the proposal initiator and the product number, and a notification is stored in the status field. In this way, the record added in the proposal DB as the notification status is positioned as the item that is the subject of the notification, and can be accessed by all end users registered in the ecosystem 100. The access is performed, for example, by using an item notification screen described later.

[0091] The control unit 11 of the server 1 references the updated proposal DB and outputs a purchase request screen (step T103). The control unit 11 of the server 1 references the updated proposal DB, generates a purchase request screen, and transmits it to the terminal 2 that is the sender of the start request (the terminal 2 of the business operator who is the proposer). The process on the purchase request screen will be described later.

[0092] The control unit 21 of the terminal 2 displays the purchase application screen received from the server 1 (step U103). The control unit 21 of the terminal 2 displays the purchase application screen received from the server 1 on a display unit such as a display.

[0093] Through this series of processes, new candidates for group purchase items are generated. The business operator who initiates the proposal logs into the ecosystem 100 and transitions from the home screen to the purchase request screen, thereby being able to grasp the reaction of other end users who may become participants or sellers to the new group purchase item.

[0094] 38 is a flowchart showing an example of a procedure for item notification processing. The item notification processing is started when an end user selects a link or the like displayed on a home screen.

[0095] The control unit 21 of the terminal 2 sends a request to start the item notification process to the server 1 (step U201). In response to the start request received from the terminal 2, the control unit 11 of the server 1 sends an item notification screen to the terminal 2 (step T201). A request to start the item notification process is sent from the terminal 2 used by the end user to the server 1 by operation of the business operator (end user) who will be a participant or seller, or the platformer 3. In response to the start request, the control unit 11 of the server 1 generates screen data for the item notification screen, for example, composed of html, and sends it to the terminal 2 that sent the start request. The control unit 11 of the server 1 may refer to the joint purchasing item DB and the proposal DB when generating the item notification screen.

[0096] The control unit 21 of the terminal 2 displays the item notification screen received from the server 1 and transmits the operation result (Like click) received on the item notification screen to the server 1 (step U202). The control unit 21 of the terminal 2 receives the item notification screen from the server 1 and displays the item notification screen on a display unit such as a display. The control unit 21 of the terminal 2 receives an operation performed by an end user on the item notification screen. The operation by the end user may be clicking a Buy icon or a Sell icon for each of the candidates for the joint purchase item displayed on the item notification screen. The click is, for example, clicking a Like icon, and is performed in response to a favorable evaluation of each of the candidates for the joint purchase item. The control unit 21 of the terminal 2 transmits the operation result, i.e., the operation result of clicking the Buy icon or the Sell icon, to the server 1 in association with the user ID of the end user operating the terminal 2.

[0097] The control unit 11 of the server 1 updates the proposal DB in response to the operation result (Like click) received from the terminal 2 (step T202). The control unit 11 of the server 1 updates the proposal DB based on the operation result received from the terminal 2, i.e., the operation result of clicking the Want to Buy mark or the Want to Sell mark and the user ID of the end user who performed the operation. The control unit 11 of the server 1 stores the user ID who clicked Want to Buy in the Want to Buy ID field included in the record of the product number that is the target of the operation in the proposal DB, and stores the user ID who clicked Want to Sell in the Want to Sell ID field. This makes it possible to store which end user clicked the Want to Buy mark or Want to Sell mark for a new candidate joint purchasing item (item in a notice state), and by counting the number of user IDs stored in the Want to Buy ID field or the Want to Sell ID field, it is possible to derive the number of end users who want to buy and sell for the joint purchasing item.

[0098] The control unit 11 of the server 1 refers to the updated proposal DB and outputs the item notification screen again (step T203). The control unit 21 of the terminal 2 redisplays the item notification screen received from the server 1 (step U203). By clicking the "Want to buy" mark or the "Want to sell" mark on the terminal 2, the "Want to buy" or "Want to sell" numerical value on the item notification screen increases, and an item notification screen reflecting this increase is generated by the control unit 11 of the server 1 and output again to the terminal 2. The control unit 21 of the terminal 2 redisplays the item notification screen received from the server 1, thereby updating the item notification screen to the latest state. The "Want to buy" or "Want to sell" numerical value displayed on the item notification screen is also reflected on the item proposal screen described below.

[0099] 39 is a flowchart showing an example of a procedure for item proposal processing. The item proposal processing is started when an end user selects a link or the like displayed on the home screen.

[0100] The control unit 21 of the terminal 2 transmits a request to start the item proposal process to the server 1 (step U301). In response to the request to start received from the terminal 2, the control unit 11 of the server 1 transmits an item proposal screen to the terminal 2 (step T301). A request to start the item proposal process is transmitted from the terminal 2 used by the end user to the server 1 by an operation of the business operator (end user) who will be the proposer. In response to the request to start, the control unit 11 of the server 1 generates screen data for the item proposal screen, which is configured, for example, by html, and transmits it to the terminal 2 which is the sender of the request to start.

[0101] The item proposal screen displays the number of clicks of the "Want to buy" or "Want to sell" mark for each item that is a candidate for joint purchasing, so that information for determining whether or not to make a joint purchase for that item can be presented to the operator of the terminal 2 (a business entity that can be a proposer). The item proposal screen may be provided with a text field or the like for selecting or inputting a threshold value of the evaluation result that a business entity (end user) that can be a participant in the joint purchasing should have. The threshold value of the evaluation result may be, for example, a lower limit value of the overall score in the overall evaluation, and the number (number of clicks of the "Want to buy" or "Want to sell" mark) of only business entities (end users) that have an overall score equal to or higher than the input threshold value may be displayed. In this way, the business entity (end user) that will be the proposer can grasp the tendency of business entities (end users) that intend to buy or sell based on the value of the evaluation result by setting a threshold value of the evaluation result on the item proposal screen (inputting a numerical value for the threshold in a text field).

[0102] The control unit 11 of the server 1 may refer to the joint purchasing item DB and the proposal DB when generating the item proposal screen. At this time, the control unit 11 of the server 1 may perform a search process on the proposal DB, extract a record in which the user ID of the business entity that will be the proposal proposer is stored in the user ID field of the proposer and a notice is stored in the status field, and generate the item proposal screen based on the extraction result.

[0103] The control unit 21 of the terminal 2 displays the item proposal screen received from the server 1 and transmits the part number accepted on the item proposal screen to the server 1 (step U302). The control unit 21 of the terminal 2 receives the item proposal screen from the server 1 and displays the item proposal screen on a display unit such as a display. The control unit 21 of the terminal 2 receives a part number selection operation performed by the end user on the item proposal screen. The part number selection operation may be, for example, a function button (a function button arranged next to a part number) displayed on the item proposal screen, which is pressed to select the part number corresponding to the function button. The control unit 21 of the terminal 2 transmits the part number accepted on the item selection screen, i.e., the part number selected by the end user, to the server 1.

[0104] The control unit 11 of the server 1 outputs a sub-screen of the item proposal screen according to the product number received from the terminal 2 (step T302). The control unit 21 of the terminal 2 displays the sub-screen of the item proposal screen received from the server 1, and transmits the data received on the sub-screen (desired unit price, quantity, solicitation period, threshold) to the server 1 (step U303). The control unit 11 of the server 1 generates a sub-screen of the item proposal screen according to the product number received from the terminal 2, and outputs the sub-screen to the terminal 2. Alternatively, the sub-screen of the item proposal screen may be displayed on the terminal 2 as a local process on the terminal 2 according to an operation on the item proposal screen.

[0105] The control unit 21 of the terminal 2 transmits data received on the child screen of the item proposal screen to the server 1. The data includes, for example, a desired unit price, a quantity, a solicitation period, and a threshold. The desired unit price is a desired purchase unit price when purchasing an item (joint purchase item) that is the subject of a joint purchase. The quantity is a desired purchase quantity when purchasing an item (joint purchase item) that is the subject of a joint purchase. The solicitation period is a deadline for soliciting participation in the joint purchase item. The threshold indicates the lower limit of the evaluation result of the end user for other businesses (end users) that wish to participate in the joint purchase item. The evaluation result is, for example, a total score stored in the overall evaluation DB 13A, and the threshold corresponds to the lower limit of the total score. Therefore, it is possible to restrict participation in the joint purchase item for businesses (end users) whose evaluation results (total score) are less than the threshold. The desired unit price, quantity, solicitation period, and threshold received on the child screen of the item proposal screen are set to be changeable later. In other words, the business operator (end user) who proposes the item can make changes (update the corresponding item record in the proposal DB) by launching the sub-screen of the item proposal screen again and re-entering the desired unit price, quantity, solicitation period, and threshold value.

[0106] The control unit 11 of the server 1 updates the proposal DB in accordance with the data received from the terminal 2 (step T303). The control unit 11 of the server 1 stores the data received from the terminal 2 (desired unit price, quantity, solicitation period, threshold) in each item of the target item in the proposal DB, and further changes the status item from "notification" to "proposal." By storing the proposal in the status item, the target item is repositioned from a candidate joint purchasing item to an item eligible for participation, and becomes eligible for participation or sale, as described below.

[0107] 40 is a flowchart showing an example of the procedure of the participation acceptance process. The participation acceptance process is started when the end user selects a link or the like displayed on the home screen.

[0108] The control unit 21 of the terminal 2 transmits a request to start the participation acceptance process to the server 1 (step U401). In response to the request to start received from the terminal 2, the control unit 11 of the server 1 transmits a participation acceptance screen to the terminal 2 (step T401). A request to start the participation acceptance process is transmitted from the terminal 2 used by the end user to the server 1 by operation of the business operator (end user) who will be a participant. In response to the request to start, the control unit 11 of the server 1 generates screen data of the participation acceptance screen, for example, configured with html, and transmits it to the terminal 2 that is the sender of the request to start.

[0109] The control unit 21 of the terminal 2 displays the participation acceptance screen received from the server 1, and transmits the product number accepted on the participation acceptance screen to the server 1 (step U402). The control unit 21 of the terminal 2 receives the participation acceptance screen from the server 1, and displays the participation acceptance screen on a display unit such as a display. In addition to the item, product number, and desired unit price for which the joint purchase has been proposed, the participation acceptance screen displays the name of the business (end user) that proposed the joint purchase, and the evaluation results (total score of the overall evaluation, etc.). Therefore, businesses (end users) who may become participants can efficiently measure or recognize the creditworthiness of the person who proposed the joint purchase.

[0110] The control unit 21 of the terminal 2 accepts a part number selection operation performed by the end user on the participation acceptance screen. The part number selection operation may be, for example, a part number corresponding to a function button (a function button arranged next to the part number) displayed on the participation acceptance screen being pressed, and the control unit 21 of the terminal 2 transmits to the server 1 the part number accepted on the participation acceptance screen, i.e., the part number selected by the end user.

[0111] The control unit 11 of the server 1 outputs a sub-screen of the participation acceptance screen according to the product number received from the terminal 2 (step T402). The control unit 21 of the terminal 2 displays the sub-screen of the participation acceptance screen received from the server 1, and transmits the data (quantity) received on the sub-screen to the server 1 (step U403). The control unit 11 of the server 1 generates a sub-screen of the participation acceptance screen according to the product number received from the terminal 2, and outputs the sub-screen to the terminal 2. Alternatively, the sub-screen of the participation acceptance screen may be displayed on the terminal 2 as a local process on the terminal 2 according to an operation on the participation acceptance screen. The control unit 21 of the terminal 2 transmits the data received on the sub-screen of the participation acceptance screen and the user ID of the end user who operated the terminal 2 to the server 1. The data includes, for example, the quantity. The quantity is the desired purchase quantity when participating in a joint purchase and purchasing items (joint purchase items) that are the subject of the joint purchase.

[0112] The control unit 11 of the server 1 updates the participation acceptance DB in accordance with the data received from the terminal 2 (step T403). The control unit 11 of the server 1 adds a new record to the participation acceptance DB based on the data (quantity) and user ID received from the terminal 2, and the product number that is the subject of the joint purchase.

[0113] 41 is a flowchart showing an example of a procedure for a sales reception process. The sales reception process is started when an end user selects a link or the like displayed on a home screen. Alternatively, the sales reception process may be started in response to access from a terminal 2 of a third party (another business operator) that is not registered in the ecosystem 100.

[0114] The control unit 21 of the terminal 2 transmits a request to start the sales reception process to the server 1 (step U501). In response to the request to start received from the terminal 2, the control unit 11 of the server 1 transmits a sales reception screen to the terminal 2 (step T501). A request to start the sales reception process is transmitted from the terminal 2 used by the end user, etc., to the server 1, by an operation from the seller (end user) or a third party (other business) not registered in the ecosystem 100. In response to the request to start, the control unit 11 of the server 1 generates screen data of a sales reception screen, for example, configured with html, and transmits it to the terminal 2 that is the sender of the request to start.

[0115] The control unit 21 of the terminal 2 displays the sales reception screen received from the server 1 and transmits the product number accepted on the sales reception screen to the server 1 (step U502). The control unit 21 of the terminal 2 receives the sales reception screen from the server 1 and displays the sales reception screen on a display unit such as a display. In addition to the item, product number, desired unit price, and desired purchase quantity for which the group purchase has been proposed, the sales reception screen displays the name of the business (end user) that proposed the group purchase and the evaluation result (total score of the overall evaluation). Therefore, businesses (end users) who may become sellers can efficiently measure or recognize the creditworthiness of the person who proposed the group purchase.

[0116] Furthermore, the number of companies that wish to purchase is displayed on the sales reception screen. The number of companies that wish to purchase indicates the total number of companies (end users) that wish to purchase the target item (joint purchase item) and have an evaluation result equal to or higher than the threshold (lower limit of evaluation points) set for the joint purchase item. When the joint purchase item is proposed, only companies (end users) that have an evaluation result equal to or higher than the threshold (lower limit of evaluation points) set by the proposer are guaranteed to be participants in the joint purchase item, and this allows potential sellers (end users) to efficiently measure the creditworthiness of participants in the joint purchase. By clicking on the number of companies that wish to purchase displayed on the sales reception screen, etc., a list screen may be displayed in a pop-up format that displays the names and evaluation results (total score of comprehensive evaluation, etc.) of the companies (end users) that correspond to the companies that wish to purchase. By referring to the list screen, potential sellers (end users) can efficiently grasp the names and evaluation results (total score of comprehensive evaluation, etc.) of the companies (end users) that are participants in the joint purchase.

[0117] The control unit 21 of the terminal 2 accepts a product number selection operation performed by an end user or the like on the sales reception screen. The product number selection operation may be, for example, a function button displayed on the sales reception screen (a function button [Request for sale] arranged next to the product number) that is pressed to select the product number corresponding to the function button. The control unit 21 of the terminal 2 transmits the product number accepted on the sales reception screen, i.e., the product number selected by the end user, to the server 1.

[0118] The control unit 11 of the server 1 outputs a sub-screen of the sales reception screen according to the product number received from the terminal 2 (step T502). The control unit 21 of the terminal 2 displays the sub-screen of the sales reception screen received from the server 1, and transmits the data (unit price) received on the sub-screen to the server 1 (step U503). The control unit 11 of the server 1 generates a sub-screen of the sales reception screen according to the product number received from the terminal 2, and outputs the sub-screen to the terminal 2. Alternatively, the sub-screen of the sales reception screen may be displayed on the terminal 2 as a local process on the terminal 2 according to an operation on the sales reception screen.

[0119] The control unit 21 of the terminal 2 transmits to the server 1 the data received on the sub-screen of the sales reception screen and the user ID of the end user who operated the terminal 2. If the operator of the terminal 2 is a third party (another business operator) who is not registered in the ecosystem 100, the data and the name of the third party (other business operator) may be transmitted to the server 1. The data includes, for example, the selling price. The selling price is the desired unit price when selling an item that is the subject of a joint purchase (joint purchase item).

[0120] The control unit 11 of the server 1 updates the sales reception DB in accordance with the data received from the terminal 2 (step T503). The control unit 11 of the server 1 adds a new record to the sales reception DB based on the data (sales price) and user ID (or the name of a third party (other business)) received from the terminal 2, and the product number that is the subject of the joint purchase.

[0121] 42 is a flowchart showing an example of a procedure for a purchase application process. The purchase application process is started when an end user selects a link or the like displayed on a home screen.

[0122] The control unit 21 of the terminal 2 transmits a request to start the purchase application process to the server 1 (step U601). In response to the request to start received from the terminal 2, the control unit 11 of the server 1 transmits a purchase application screen to the terminal 2 (step T601). A request to start the purchase application process is transmitted from the terminal 2 used by the end user to the server 1 by operation of the business operator (end user) who is the initiator of the purchase application process. In response to the request to start, the control unit 11 of the server 1 generates screen data for a purchase application screen configured, for example, in html, and transmits it to the terminal 2 which is the sender of the request to start. The control unit 11 of the server 1 may refer to the joint purchasing item DB, the proposal DB, the participation reception DB, and the sales reception DB when generating the purchase application screen.

[0123] The control unit 11 of the server 1 may compare the evaluation result (for example, the total score of the overall evaluation) threshold (lower limit value of the total score) set by the proposer with the evaluation results of the businesses (end users) who applied to participate in the target joint purchasing item for the product number of the target joint purchasing item, and generate a purchase application screen reflecting only the businesses (end users) who have evaluation results equal to or higher than the threshold. In other words, the number of willing purchasers on the purchase application screen may display a total number of businesses who have evaluation results equal to or higher than the threshold among the businesses who applied to participate in the target joint purchasing item. In this way, by setting a threshold value for the evaluation result when proposing a joint purchasing item, it is possible to restrict the participation of businesses (end users) who have evaluation results below the threshold, and it is possible to ensure the creditworthiness of the businesses participating in the joint purchasing item as a whole. By clicking on the number of willing purchase companies displayed on the purchase application screen, a list screen may be displayed in a pop-up format to display the names of the businesses (end users) corresponding to the willing purchase companies and their evaluation results (total score of the overall evaluation, etc.). By referring to the list screen, the business initiator (end user) can efficiently grasp the names of the businesses (end users) participating in the joint purchasing and the evaluation results (total score of the overall evaluation, etc.).

[0124] The control unit 21 of the terminal 2 displays the purchase application screen received from the server 1, and transmits the desired sellers accepted on the purchase application screen to the server 1 (step U602). The control unit 21 of the terminal 2 receives the purchase application screen from the server 1, and displays the purchase application screen on a display unit such as a display. The purchase application screen displays a list of the names of businesses (end users) wishing to sell the target joint purchasing item, their evaluation results, and the unit price (unit selling price). Therefore, the business (end user) who proposed the group purchasing item can efficiently gauge the creditworthiness of the businesses wishing to sell the joint purchasing item based on the evaluation results of each of them.

[0125] The control unit 21 of the terminal 2 accepts the selection operation of the desired seller performed by the end user on the purchase application screen. The selection operation of the desired seller may be, for example, by pressing a function button displayed on the purchase application screen (a function button [Apply for Purchase] located next to the desired seller) to select the desired seller corresponding to the function button. The control unit 21 of the terminal 2 transmits to the server 1 the user ID or name of the desired seller accepted on the purchase application screen, i.e., information related to the desired seller selected by the end user.

[0126] The control unit 11 of the server 1 updates the proposal DB according to the seller received from the terminal 2 (step T602). The control unit 11 of the server 1 updates the proposal DB based on the data received from the terminal 2 (user ID of the seller, product number of the joint purchase item). When updating the proposal DB, the control unit 11 of the server 1 stores the user ID (user ID or name (in the case of another business) of the seller) received from the terminal 2 in the seller's user ID field in the record of the product number of the target joint purchase item, and changes the status field from proposal to purchase request. This determines the proposer and participants who will be the buyers, and the seller who will be the seller, for the proposed joint purchase item. By determining this, information such as the seller's name, evaluation results, or estimated unit price may be notified to the participants. From the process of announcing a joint purchase item to proposing and finalizing the purchase application, the proposers, participants and sellers involved in the joint purchase item will be able to refer to or confirm each other's evaluation results of other businesses. This will enable mutual confirmation of creditworthiness among the parties involved in the joint purchase item, and is expected to facilitate various adjustments as necessary.

[0127] FIG. 43 is an explanatory diagram showing an example of an item selection screen. The item selection screen is generated by the control unit 11 of the server 1 based on the items and product numbers stored in the joint purchasing item DB. The item selection screen displays items and product numbers that can be the subject of joint purchasing in list format. A function button (Register) is placed next to the product numbers, and each function button (Register) corresponds to the product numbers displayed next to it. By pressing the function button (Register), a purchase request screen is displayed in a pop-up, displaying the item with the corresponding product number. The purchase request screen will be described later.

[0128] FIG. 44 is an explanatory diagram showing an example of an item notification screen (everyone's registration list). The item notification screen is generated by the control unit 11 of the server 1 based on the details of each item, such as product numbers, stored in the joint purchasing item DB and the proposal DB. The item notification screen displays, in list form, the items and product numbers selected on the item selection screen at the notification stage, i.e., as candidates for joint purchasing items. The item notification screen may have a search field for searching for items to buy or sell. The joint purchasing item DB and the proposal DB may be searched based on characters entered in the search field, and the items extracted as the search results may be displayed in list form.

[0129] A "Want to buy" mark and a "Want to sell" mark are placed for each item and product number displayed in list format. These "Want to buy" marks and "Want to sell" marks have a function equivalent to a so-called "Good Icon," and clicking on the marks counts the number of clicks. On the item announcement screen, the click operation on the marks is stored in the proposal DB as an operation history, and which end user clicked on either the "Want to buy" mark or the "Want to sell" mark is saved. In this way, it is possible to tally up end user reviews of each item announced as a candidate for joint purchasing items on the item announcement screen.

[0130] FIG. 45 is an explanatory diagram showing an example of an item proposal screen (My List). The item proposal screen is generated by the control unit 11 of the server 1 based on the details of each item, such as item numbers, stored in the joint purchasing item DB and the proposal DB. The item proposal screen displays in list form items and item numbers that are candidates for joint purchasing items registered by the end user himself (status items are notified in the proposal DB), and further displays the current number of clicks of the "Want to buy" mark and "Want to sell" mark for each of these item numbers. By pressing the number of clicks of the "Want to buy" mark or "Want to sell" mark displayed on the item proposal screen, a list screen may be displayed in which the names of the end users who clicked the "Want to buy" mark or "Want to sell" mark and their evaluation results are displayed in a pop-up.

[0131] The item proposal screen may further include a text field for selecting or inputting a threshold value for the evaluation result. By inputting a threshold value in the text field, the system may tally up the buy marks and sell marks of only end users whose evaluation results are equal to or higher than the threshold value, and redisplay the item proposal screen with the tallying results.

[0132] Next to the number of clicks on the "Want to sell" mark are function buttons (Propose a joint purchase), and each function button (Propose a joint purchase) corresponds to each item number displayed next to it. By pressing a function button (Propose a joint purchase), a sub-screen of the item proposal screen that displays the corresponding item number and item is displayed in a pop-up.

[0133] The child screen of the item proposal screen displays the corresponding product number and item, and further has text fields for inputting the desired unit price, quantity, solicitation period, and threshold value. The numerical values ​​or values ​​inputted into these text fields are sent from the terminal 2 to the server 1 by pressing the function button (solicit joint purchases) located below, and are stored in the proposal DB.

[0134] 46 is an explanatory diagram showing an example of the participation acceptance screen (participation invitation list). The participation acceptance screen is generated by the control unit 11 of the server 1 based on the details of each item, such as product numbers, stored in the joint purchasing item DB and the proposal DB. The participation acceptance screen displays in list form the items and product numbers for which proposals are stored in the status item in the proposal DB, and further displays the name of the proposer, evaluation result, desired unit price, and application deadline for each of these product numbers.

[0135] Next to the proposal initiator's evaluation results are function buttons (Buy through joint purchasing), and each function button (Buy through joint purchasing) corresponds to the item number displayed next to it. By pressing a function button (Buy through joint purchasing), a sub-screen of the participation reception screen that displays the items with the corresponding item number will pop up.

[0136] The sub-screen of the participation reception screen displays the corresponding product number, item, desired unit price, and application deadline, as well as a text field for entering the quantity. The quantity entered into these text fields is sent from terminal 2 to server 1 by pressing a function button (apply for joint purchase) located below, and is stored in the participation reception DB.

[0137] Fig. 47 is an explanatory diagram showing an example of a sales reception screen (list of items currently solicited for purchase). The sales reception screen is generated by the control unit 11 of the server 1 based on the details of each item, such as product numbers, stored in the joint purchasing item DB, proposal DB, and participation reception DB. The sales reception screen displays in list form the items and product numbers for which proposals are stored in the status item in the proposal DB. In addition, for each of these product numbers, the name and evaluation result of the proposer, the desired unit price, the solicitation deadline, the number of items currently wishing to purchase, and the number of companies wishing to purchase are displayed.

[0138] The number of companies wishing to purchase is the total number of end users (participants) who have applied to participate in the target joint purchasing item and have evaluation results equal to or above the threshold set for that joint purchasing item. In this way, the control unit 11 of the server 1 outputs the businesses (participants) extracted as having evaluation results equal to or above the threshold, in association with information about the joint purchasing item. The number wishing to purchase is the total number of quantities entered by each of these participants (participants wishing to purchase) and the initiator.

[0139] Next to the number of companies wishing to purchase is a function button (requesting sales), and each function button (requesting sales) corresponds to the product number displayed next to it. By pressing a function button (requesting sales), a sub-screen of the sales reception screen that displays the item with the corresponding product number will pop up.

[0140] The sub-screen of the sales reception screen displays the corresponding product number, item type, desired unit price, and application deadline, and also has a text field for inputting the sales unit price. The sales unit price inputted into these text fields is sent from the terminal 2 to the server 1 by pressing the function button (apply for sale) located below, and is stored in the sales reception DB.

[0141] FIG. 48 is an explanatory diagram showing an example of a purchase application screen (a list of proposed joint purchases). The purchase application screen is generated by the control unit 11 of the server 1 based on the details of each item, such as product number, stored in the joint purchase item DB, proposal DB, participation reception DB, and sales reception DB. The purchase application screen displays the item and product number of the joint purchase item proposed by the user, which is stored in the status item in the proposal DB, and further displays the number of companies wishing to purchase, which is the number of end users who are participants, and the number of companies wishing to purchase, which is the total number of purchases by the proposer and the participants, for the product number (joint purchase item). The number of companies wishing to purchase is the total number of participants who have an evaluation result equal to or higher than the threshold set for the joint purchase item, among the end users (participants) who have applied to participate in the target joint purchase item. In this way, the control unit 11 of the server 1 outputs the businesses (participants) extracted as being equal to or higher than the threshold, in association with information about the joint purchase item.

[0142] The purchase request screen displays the names (willing sellers), credit ratings, and unit prices (sales unit prices) of the end users (sellers) who have applied to sell the group purchase item in a list format (willing sellers area). In the willing sellers area, a function button (apply to purchase) is arranged next to the unit prices, and each function button (apply to purchase) corresponds to each willing seller displayed next to it. By pressing the function button (apply to purchase), the user ID etc. of the corresponding willing seller and the product number of the target group purchase item are transmitted from the terminal 2 to the server 1 and stored in the proposal DB. The control unit 11 of the server 1 stores the data received from the terminal 2 (user ID etc. of the willing seller, product number of the group purchase item) in each item of the target item in the proposal DB, and further changes the status item from proposal to purchase request. Furthermore, the control unit 11 of the server 1 may transmit an email or a direct message in the ecosystem 100 to the willing seller selected by pressing the function button (apply to purchase).

[0143] According to this embodiment, the control unit 11 of the server 1 acquires a group purchasing item input by one of the end users (businesses) among the multiple end users (businesses) who have registered for use in the ecosystem 100, associates the acquired group purchasing item with the end user (business) who performed the input operation, and stores the associated item in the main memory unit 12 of the server 1. As a result, the end user (business) who performed the input operation becomes the initiator of the group purchasing item. Then, the control unit 11 of the server 1 acquires an offer to participate in the group purchasing item from other end users (participants in the group purchasing item), and outputs an evaluation result including a total score of the business who has offered to be a participant to the business who is the initiator. Therefore, the business who is the initiator of the group purchasing item can check the evaluation result of the business (participant) who has offered to participate in the group purchasing item, and can efficiently measure the creditworthiness of the business who has offered to be a participant based on the evaluation result. The control unit 11 of the server 1 may associate information about the group purchase item with information about the business that proposed it and the business that is a participant, and output the information to terminals 2 used not only by end users registered in the ecosystem 100 but also by third parties (other businesses) that are not registered in the ecosystem 100. In this way, even if a seller of the group purchase item is not registered in the ecosystem 100, information about the group purchase item can be notified to the seller or the platformer 3.

[0144] According to this embodiment, the control unit 11 of the server 1 associates information about the joint purchase item with information about the business corresponding to the initiator or participant, and outputs the information to the terminal 2 used by the platformer 3 or business seller who is the seller of the joint purchase item. The seller may include not only the platformer 3 or business registered in the ecosystem 100, but also the platformer 3 or business not registered in the ecosystem 100. The control unit 11 of the server 1 outputs the estimated amount for the joint purchase item acquired from the platformer 3 or business seller to the terminal 2 used by the business corresponding to the initiator or participant. When the control unit 11 of the server 1 acquires estimated amounts for the same joint purchase item from multiple sellers, it may output each of the estimated amounts acquired from the multiple sellers in, for example, a list. This allows the business corresponding to the initiator or participant to efficiently grasp the estimated amount for the joint purchase item and efficiently determine whether or not to purchase the joint purchase item (joint purchase).

[0145] According to this embodiment, when the control unit 11 of the server 1 receives information on the proposal of a joint purchase item from the business that is the initiator, the control unit 11 also receives a threshold value for businesses participating in the joint purchase of the joint purchase of the joint purchase item, and the threshold value is stored in the main memory unit 12 of the server 1 as one piece of information on the proposal of the joint purchase item. Then, the control unit 11 of the server 1 compares the evaluation results of the businesses (participants) that have made an offer for the joint purchase item with the threshold value for the joint purchase item, and extracts businesses (participants) to which the evaluation results that are equal to or greater than the threshold value are linked. At this time, the control unit 11 of the server 1 outputs the businesses (participants) extracted as being equal to or greater than the threshold value in association with information on the joint purchase item, so that businesses that are equal to or greater than the creditworthiness desired by the business that is the initiator can be participants in the joint purchase. Furthermore, from the perspective of a business requesting group purchasing (a participant in a group purchasing item), if the value of one's own evaluation result is relatively low, one will not be able to participate in group purchasing using ecosystem 100, and therefore end users of ecosystem 100 (businesses that have registered to use the system) can be motivated to improve their own evaluation results.

[0146] The technical features (constituent elements) described in each embodiment can be combined with each other, and by combining them, new technical features can be formed. The embodiments disclosed herein are illustrative in all respects and should not be considered as limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the scope and meaning equivalent to the claims. In addition, the claims are written in a format in which a claim cites two or more other claims (multiple claim format), but this is not limited to this format. The claims may be written in a format in which multiple claims cite at least one other claim (multi-multi claim format). [Explanation of symbols]

[0147] 100: Ecosystem 1: Server 11: Control section 12: Main memory 13: Auxiliary storage section 131: User DB 132: Linked account DB 133: Deposit / Withdrawal DB 134: Platform DB 135:Representative / Business Owner DB 136: Corporate DB 137: Individual evaluation database 138: Business feasibility evaluation database 139: BCP Evaluation Database 13A: Comprehensive evaluation DB 13B :PF public DB 13C: Usage DB 13D: Recommendation condition DB 13E: Offer setting DB 14: Communications Department 15: Reading section 1P: Control program 1a: Portable storage medium 1b: Semiconductor memory 2: Terminal 21: Control section 22: Main memory 23: Auxiliary storage section 24: Communications Department 25: Input section 26:Display section 2P: Control program 3: Platformer 4: Financial institution server B: Bus N: Network

Claims

1. Acquire account deposit and withdrawal information of business operators managed by financial institutions, or usage data related to the use of the platform services of the business operators, Evaluating the business operator based on the acquired account deposit and withdrawal information or the usage data; The evaluation results are stored in association with the disclosure setting. When a request is received from a second business operator that has already registered for use, if the disclosure setting is set to public, the evaluation result is transmitted to a terminal of the second business operator. An information processing method in which processing is performed by a computer.

2. The evaluation result includes a plurality of evaluation values ​​on a plurality of common evaluation axes based on the account deposit and withdrawal information or the usage data. The information processing method according to claim 1 .

3. In response to a request from another operator who has not registered for use, the evaluation result is transmitted to the terminal of the other operator.

3. The information processing method according to claim 1.

4. Transmitting the account deposit and withdrawal information or the usage data of the business to an evaluation business; Output the evaluation results received from the evaluation company 3. The information processing method according to claim 1.

5. Obtaining an evaluation of the platform provider from the business operator; The acquired evaluation is stored in association with the information of the platform provider.

3. The information processing method according to claim 1.

6. Obtain business information of the business operator; Based on account deposit and withdrawal information managed by financial institutions or usage data related to the use of the platform operator's services, business information on multiple candidate businesses that have already been evaluated is obtained, Selecting the candidate business to be matched with the business based on the business information of the business and the business information of the candidate business; Transmitting business information of the selected candidate business to a terminal of the business 3. The information processing method according to claim 1.

7. The evaluation results include a number of scores that contribute to identifying issues facing the business operator.

3. The information processing method according to claim 1.

8. The evaluation results include a plurality of items, each of which is set to be public or private, Transmitting evaluation results for items set for public display in response to requests from other businesses 3. The information processing method according to claim 1.

9. Based on the consent of the business operator, in response to a request from the other business operator, transmit the usage data to the other business operator.

3. The information processing method according to claim 1.

10. Acquiring the usage data from a plurality of the platform providers; storing the acquired usage data together with whether the data is public or private based on instructions from the business operator; Based on the consent of the business operator, in response to a request from another business operator, only the usage data set to be public is transmitted to the other business operator.

3. The information processing method according to claim 1.

11. Acquire account deposit and withdrawal information of business operators managed by financial institutions, or usage data related to the use of the platform services of the business operators, Evaluating the business operator based on the acquired account deposit and withdrawal information or the usage data; The evaluation results are stored in association with the disclosure setting. When a request is received from a second business operator that has already registered for use, if the disclosure setting is set to public, the evaluation result is transmitted to a terminal of the second business operator. An information processing program that causes a computer to execute processing.

12. An acquisition unit that acquires account deposit and withdrawal information of a business operator managed by a financial institution or usage data related to the use of a platform service of the business operator; an evaluation unit that evaluates the business operator based on the acquired account deposit / withdrawal information or the acquired usage data; A storage unit that stores the evaluation result in association with a disclosure setting; a transmission unit that transmits the evaluation result to a terminal of the second business operator when the disclosure setting is set to disclosure when a request from a second business operator that has already registered for use is received; An information processing device comprising:

13. Obtain joint purchase items associated with one of the multiple registered businesses, For the acquired joint purchasing items, we receive offers from businesses requesting joint purchasing, outputting the evaluation result of the business that made the offer to any one of the business operators; Output information related to joint purchase items, information related to one of the businesses and information related to the business that made the offer, in association with each other. The information processing method according to claim 1 .

14. The destination of the output of the information on the joint purchase item, the information on any of the businesses and the business that made the offer in association with each other is the platform provider or the business that is the seller of the joint purchase item, Obtaining estimates for joint purchase items from the platform providers or businesses that will be the sellers, The obtained estimated amount is output to one of the businesses and to the business that made the offer. The information processing method according to claim 13.

15. The evaluation results of the business operator who made the offer are compared with a predetermined threshold value, Among the businesses that have made the offer, information on businesses that are linked with the evaluation result that is equal to or greater than a threshold is output in association with information on the joint purchase item. The information processing method according to claim 14.

Images