Suggestion server, communication system, suggestion method, and program

Abstract

To provide a proposal server, a communication system, a proposal method and a program for proposing information matched with an assumed condition through a communication network to the user terminal of a user who provides or plans to provide merchandise or service to a transaction destination.SOLUTION: The method includes a S1 for service using company A to generate an account receivable or the like by providing or planning to provide a commodity or service to customer company B, a S2 for service using company A to notify proposing company C of condition information indicating a predetermined condition (commission rate priority, risk avoidance priority) desired by service using company A in order to propose a fundraiser matching the condition of service using company A from a plurality of fundraisers, and a S3 for proposing company C to acquire credit information of customer company B from credit information service company H and propose a recommended specific fundraiser to service using company A by comprehensively judging the credit information, contents of a form, the predetermined condition from service using company A, and the like.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a proposal server, a communication system, a proposal method, and a program. [Background technology]

[0002] In the world of commercial transactions, factoring is a widely used method of raising funds by quickly converting accounts receivable arising from transactions into cash.

[0003] For example, Patent Document 1 discloses a method for quickly purchasing accounts receivable while reducing the manual administrative burden, by using a technology that implements the procedure for purchasing accounts receivable through factoring using a computer system. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6707700 Summary of the Invention [Problem to be solved by the invention]

[0005] However, depending on the form issued by the user as a creditor, there are various forms, such as different fees for fundraising through factoring etc., and different risks of not being able to collect the receivables related to the form, etc. Therefore, users face the problem of finding a form that meets their expected conditions. [Means for solving the problem]

[0006] The invention of claim 1 is a proposal server that proposes information via a communication network to a user terminal of a user who provides or plans to provide products or services to a business partner, and is characterized by having: a receiving means for receiving condition information sent by the user terminal that indicates specified conditions regarding fundraising using a form issued by the user when the user provides the product or service; and a transmitting means for transmitting to the user terminal information indicating a specific form from among the multiple forms that is designed to make up for an amount shortfall in the user's cash flow based on the specified conditions. is. [Effects of the Invention]

[0007] As described above, according to the present invention, the proposal server transmits to the user terminal specific forms for fundraising that meet the specified conditions requested by the user, thereby making it easier for the user to find a form that meets the conditions he or she envisions. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating the relationships between companies according to the present embodiment. [Figure 2] 1 is a schematic diagram of a communication system according to an embodiment of the present invention; [Figure 3] This is a hardware configuration diagram of the user terminal, proposal server, funding service server, and credit information server of this embodiment. [Figure 4] FIG. 2 is a functional block diagram of the communication system according to the embodiment. [Figure 5] FIG. 10 is a conceptual diagram of a tenant regular expense management table. [Figure 6] FIG. 10 is a conceptual diagram of a tenant individual payment management table. [Figure 7] FIG. 10 is a conceptual diagram of a funding information management table. [Figure 8] FIG. 10 is a conceptual diagram of a tenant bank account information table. [Figure 9] FIG. 10 is a conceptual diagram of a tenant credit card management table. [Figure 10]FIG. 10 is a conceptual diagram of a tenant management table. [Figure 11] FIG. 10 is a conceptual diagram of a funding service type management table. [Figure 12] FIG. 10 is a conceptual diagram of a funding service management table. [Figure 13] FIG. 10 is a conceptual diagram of a destination information management table. [Figure 14] FIG. 10 is a conceptual diagram of a credit information adjustment management table. [Figure 15] FIG. 10 is a conceptual diagram of a credit information management table. [Figure 16] FIG. 10 is a conceptual diagram of a recommendation candidate information management table. [Figure 17] FIG. 10 is a sequence diagram showing a process for displaying a cash flow screen. [Figure 18] 10 is a flowchart showing a process for creating a cash flow screen. [Figure 19] FIG. 10 is a diagram showing an example of a display of a cash flow screen. [Figure 20] FIG. 10 is a sequence diagram showing a display process of a recommendation screen. [Figure 21] 10 is a flowchart showing a process of narrowing down recommended information. [Figure 22] 10 is a flowchart showing a preparation process. [Figure 23] 10 is a flowchart showing a process of creating recommendation candidate information. [Figure 24] FIG. 10 is a diagram showing an example of a recommendation screen display when priority is given to commission rate. [Figure 25] FIG. 10 is a diagram showing an example of a recommended screen after the display has been changed in the case of prioritizing the commission rate. [Figure 26] FIG. 10 is a diagram showing an example of a display of a recommendation screen when priority is given to risk avoidance. [Figure 27] FIG. 10 is a diagram showing an example of a redisplayed cash flow screen. [Figure 28] FIG. 10 is a diagram showing an example of a cash flow screen display with specific customer priority added. [Figure 29] FIG. 10 is a diagram showing an example of a display of a priority business partner selection screen. [Figure 30]10 is a flowchart showing a process of narrowing down recommended information to which priority is given to specific business partners. [Figure 31] FIG. 10 is a diagram showing an example of a recommendation screen display when priority is given to specific business partners. [Figure 32] FIG. 10 is a diagram showing an example of a cash flow screen display when priority is given to specific business partners. DETAILED DESCRIPTION OF THE INVENTION

[0009] [Inter-company relationships] The relationships between the companies will be explained using Figure 1. Figure 1 is a diagram showing the relationships between the companies according to this embodiment.

[0010] As shown in Figure 1, service user company A is a company that uses a service to receive recommended fundraising proposals from proposing company C. Client company B is a client of service user company A. In this case, a relationship may arise in which service user company A is the creditor and client company B is the debtor. Proposing company C is a company that provides the above service to service user company A.

[0011] In addition, factoring service company D, accounts receivable secured loan service company E, PO finance service company F, and quotation finance service company G are companies that provide the services indicated above and are all funding service companies. From the perspective of service user company A, funding service companies are sources of funding.

[0012] Factoring service company D is a collective term for multiple factoring service companies D1, D2, ... Dn. Accounts receivable secured loan service company E is a collective term for multiple accounts receivable secured loan service companies E1, E2, ... En. PO finance service company F is a collective term for multiple PO finance service companies F1, F2, ... Fn. Quotation finance service company G is a collective term for multiple quotation finance service companies G1, G2, ... Gn.

[0013] Credit information service company H is a company that holds credit information indicating the reliability of management, etc. of business partners and other companies, and provides credit information to proposing company C. Note that credit information service company H is a collective term for multiple credit information service companies H1, H2, ... Hn.

[0014] Here, an outline of the processing in this embodiment will be described.

[0015] First, service user company A provides or plans to provide goods or services to trading partner company B, resulting in accounts receivable (S1). Then, service user company A communicates condition information indicating its desired specified conditions (priority on commission rate, priority on risk avoidance) to proposing company C in order to have multiple fundraising sources propose a source that meets its requirements (S2). Proposing company C then obtains credit information on trading partner company B from credit information service company H, makes a comprehensive judgment based on this credit information, the contents of the ledger, the specified conditions from service user company A, etc., and proposes specific recommended fundraising sources to service user company A (S3).

[0016] As a result, service user company A applies for funding by sending a document to the proposed specific funding source (funding service company) (S4). In response, the specific funding service company provides funding to service user company A after screening (S5). Furthermore, the specific funding service company requests accounts receivable from trading partner company B corresponding to accounts receivable, etc. (S6). As a result, trading partner company B pays the accounts receivable to the specific funding service company on the due date (S7).

[0017] [Communication system overview] 2 is a schematic diagram of the communication system of this embodiment, showing the terminals or servers of each company in FIG.

[0018] User company A is equipped with a user terminal 1 such as a PC (personal computer), which is operated by user A1. Proposal company C is equipped with a proposal server 3. Factoring service company D, accounts receivable financing service company E, PO finance service company F, and quotation finance service company G are equipped with funding service servers 5d, 5e, 5f, and 5g, respectively. Credit information service company H is equipped with a credit information server 7. Each server is composed of a computer. The user terminal 1, funding service servers 5d, 5e, 5f, and 5g, and credit information server 7 can communicate with each other via a communication network 100 such as the Internet. Hereinafter, funding service servers 5d, 5e, 5f, and 5g will be collectively referred to as the "funding service server 5."

[0019] [Hardware configuration of communication system] Next, the hardware configuration of each terminal and server that constitutes the communication system shown in Fig. 1 will be described using Fig. 3. Since all of them have the same configuration, the hardware configuration of the user terminal 1 will be described, and the description of the hardware configuration of each server will be omitted.

[0020] As shown in Figure 3, the user terminal 1 is composed of a computer and includes a CPU 101, a ROM 102, a RAM 103, a HD 104, an HDD (Hard Disk Drive) controller 105, a display 106, an external device connection I / F (Interface) 108, a network I / F 109, a bus line 110, a keyboard 111, a pointing device 112, a DVD-RW (Digital Versatile Disk Rewritable) drive 114, and a media I / F 116.

[0021] Of these, the CPU 101 controls the operation of the entire computer. The ROM 102 stores programs used to drive the CPU 101, such as the IPL. The RAM 103 is used as a work area for the CPU 101. The HD 104 stores various data, such as programs. The HDD controller 105 controls the reading and writing of various data from and to the HD 104 under the control of the CPU 101. The display 106 displays various information, such as a cursor, menus, windows, characters, or images. The external device connection I / F 108 is an interface for connecting various external devices. In this case, the external devices are, for example, USB (Universal Serial Bus) memories, printers, etc. The network I / F 109 is an interface for data communication using the communication network 100. The bus line 110 is an address bus, a data bus, etc. for electrically connecting the components, such as the CPU 101, shown in FIG. 3.

[0022] The keyboard 111 is a type of input means having multiple keys for inputting characters, numbers, various instructions, etc. The pointing device 112 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The DVD-RW drive 114 controls reading and writing of various data from a DVD-RW 113, which is an example of a removable recording medium. Note that the medium is not limited to a DVD-RW, and may be a DVD-R or a Blu-ray Disc (registered trademark), etc. The media I / F 116 controls reading and writing (storing) of data from a recording medium 115, such as a flash memory.

[0023] Furthermore, a microphone as an example of a sound collection device, a speaker as an example of a sound output device, and a camera as an example of an imaging device can be connected to the external device connection I / F.

[0024] [Functional configuration of the communication system] Next, the functional configuration of the communication system of this embodiment will be described with reference to Figures 3 to 16. Figure 4 is a functional block diagram of the communication system of this embodiment. Note that the funding service server 5 and the credit information server 7 do not have any new functions in the communication processing of this embodiment, so their description will be omitted.

[0025] <Functional configuration of user terminal> First, the functional configuration of the user terminal 1 will be described with reference to Figures 3 and 4. As shown in Figure 4, the user terminal 1 has a transmitting / receiving unit 11, a receiving unit 12, a display control unit 14, a determining unit 15, and a storage / readout processing unit 19. Each of these units is a function or a means for performing the function, which is realized when any of the components shown in Figure 3 operates in response to an instruction from the CPU 101 in accordance with a program loaded from the HD 104 onto the RAM 103. The user terminal 1 also has a storage unit 1000 constructed by the RAM 103 and HD 104 shown in Figure 3.

[0026] (Functional configuration of user terminal) Next, we will explain each component of the user terminal 1. The transmitting / receiving unit 11 is realized by commands from the CPU 101 shown in Fig. 3, an external device connection I / F 108, and a network I / F 109, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network 100.

[0027] The reception unit 12 is realized mainly by commands from the CPU 101 shown in FIG. 3, as well as the keyboard 111 and pointing device 112, and receives various inputs from the user.

[0028] 3, and displays an image by outputting image data to the display 106 or an external display connected to the external device connection I / F 108. The display control unit 14 has a web browser function.

[0029] The determination unit 15 is mainly realized by instructions from the CPU 101 shown in FIG. 3, and performs various determinations.

[0030] The storage / readout processing unit 19 is mainly realized by instructions from the CPU 101 shown in Figure 3 and the HDD controller 105, and performs processes such as storing various data in the memory unit 1000 and reading out various data stored in the memory unit 1000.

[0031] <Functional configuration of the proposed server> Next, the functional configuration of the proposal server 3 will be described with reference to Fig. 3 to Fig. 16. As shown in Fig. 4, the proposal server 3 has a transmitting / receiving unit 31, a calculating unit 33, a determining unit 35, a creating unit 36, and a storing / reading processing unit 39. Each of these units is a function or a means for performing a function that is realized when any of the components shown in Fig. 3 operates in response to an instruction from the CPU 101 in accordance with a program loaded from the HD 104 onto the RAM 103. The proposal server 3 also has a storage unit 3000 constructed by the RAM 103 and HD 104 shown in Fig. 3.

[0032] (Tenant regular expense management table) Fig. 5 is a conceptual diagram showing a tenant regular expense management table. A tenant regular expense management DB 3001 configured with a tenant regular expense management table such as that shown in Fig. 5 is constructed in the memory unit 3000. This table manages past expenditure types, expenditure months, and amounts for regular payments in association with each tenant ID used to identify tenants (such as service user company A) that receive services from proposing company C. Future regular payments are predicted based on this table.

[0033] (Individual tenant payment management table) Fig. 6 is a conceptual diagram showing an individual tenant payment management table. The storage unit 3000 has created an individual tenant payment management DB 3002 that is configured using the individual tenant payment management table shown in Fig. 6. In this table, tenant payment information is managed by associating each piece of information, such as ID, biller, payment deadline, amount, and payment status, for each tenant ID.

[0034] (Funding information management table) FIG. 7 is a conceptual diagram showing a funding information management table. A funding information management DB 3003 consisting of a funding information management table such as that shown in FIG. 7 is constructed in the storage unit 3000. This table shows the contents of forms used for funding. Therefore, this table associates and manages, for each tenant ID, information such as ID, business partner, funding object type, payment deadline, amount, and payment status, as well as the storage location of the form image digitized into PDF or the like. The funding object types include invoices, purchase orders, and estimates.

[0035] (Tenant bank account management table) Fig. 8 is a conceptual diagram showing a tenant bank account management table. A tenant bank account management DB 3004 consisting of a tenant bank account management table such as that shown in Fig. 8 is constructed in the storage unit 3000. This table shows the details of the user's own bank account that the user has registered in advance with the proposal server 3. Therefore, this table manages the bank name, branch name, account number, user name, and password in association with each tenant ID.

[0036] (Tenant credit card management table) Fig. 9 is a conceptual diagram showing a tenant credit card management table. A tenant credit card management DB 3005 configured with a tenant credit card management table such as that shown in Fig. 9 is constructed in the storage unit 3000. This table shows information about the user's own credit card that the user has registered in advance in the proposal server 3. Therefore, this table manages the card name (card number), user name, and password in association with each tenant ID. The amount that can be borrowed based on this information will later be used for the cash balance.

[0037] (Tenant management table) FIG. 10 is a conceptual diagram showing a tenant management table. A tenant management DB 3006 configured with a tenant management table such as that shown in FIG. 10 is constructed in the storage unit 3000. This table shows details related to the company information of the tenant. Therefore, this table associates and manages the tenant ID, tenant name, tenant address (location), tenant industry, and tenant business type. This information is used, for example, when the tenant is in the construction industry, to exclude from selection funding service companies that do not provide funding to the construction industry in particular.

[0038] (Funding service type management table) Fig. 11 is a conceptual diagram showing a funding service type management table. A funding service type management DB 3007 configured with a funding service type management table such as that shown in Fig. 11 is constructed in the memory unit 3000. In this table, funding target types and funding service types (procurement types) are managed in association with each other.

[0039] (Funding Service Management Table) Figure 12 is a conceptual diagram showing a funding service management table. A funding service management DB 3008 consisting of a funding service management table such as that shown in Figure 12 is constructed in the memory unit 3000. This table associates and manages the funding service type, funding service name (company name), non-supported industries, supported areas for funding, individual business support for funding, funding amount conditions, and the connection URL (destination information) to the funding service server 5 of the funding service company. Note that if the funding support for individual business is "false," the funding service company provides funding to companies but does not provide funding to individuals.

[0040] (Destination information management table) Fig. 13 is a conceptual diagram showing a destination information management table. A destination information management DB 3009 configured with a destination information management table such as that shown in Fig. 13 is constructed in the storage unit 3000. In this table, for each type of information, a destination name (company name) for obtaining the information and a connection URL (destination information) are associated and managed.

[0041] (Credit information adjustment management table) Fig. 14 is a conceptual diagram showing a credit information adjustment management table. A credit information adjustment management DB 3010 configured with a credit information adjustment management table such as that shown in Fig. 14 is constructed in the memory unit 3000. In this table, the credit ratings provided by each credit information service company are associated and managed for each credit rating. Since the credit rating levels set by each credit information service company are different, this table is used to adjust and unify them.

[0042] (Credit information management table) Fig. 15 is a conceptual diagram showing a credit information management table. A credit information management DB 3011 configured with a credit information management table such as that shown in Fig. 15 is constructed in the memory unit 3000. In this table, the credit scores adjusted in the credit information management table of Fig. 15 are managed in association with each trading partner.

[0043] (Recommended candidate information management table) FIG. 16 is a conceptual diagram showing a recommendation candidate information management table. A recommendation candidate information management DB 3012 configured with a recommendation candidate information management table such as that shown in FIG. 16 is constructed in the storage unit 3000. This table shows recommendation candidate information including the contents of forms used for fundraising. Therefore, this table associates and manages the business partner, the business partner's creditworthiness, the transaction amount shown in the form, the type of fundraising target, the type of fund providing service (type of procurement), the name of the fund providing service (company name), the fee rate for fund provision, and the date of deposit to the service using company if fund provision is made. Note that from this recommendation candidate information, the recommended information that will be ultimately proposed to the service using company is extracted.

[0044] (Functional configuration of the proposed server) Next, a detailed description will be given of each functional configuration of the proposal server 3. In the following, when describing each functional configuration of the proposal server 3, the relationship between each component shown in Fig. 3 and the main components for realizing each functional configuration of the proposal server 3 will also be described.

[0045] The transmission / reception unit 31 of the proposal server 3 shown in Figure 4 is realized by instructions from the CPU 101 shown in Figure 3 and the network I / F 109, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network 100.

[0046] The calculation unit 33 is realized by an instruction from the CPU 101 shown in Fig. 3, and performs predetermined calculations. The contents of the calculations will be described later.

[0047] The determination unit 35 is implemented by an instruction from the CPU 101 shown in Fig. 3, and makes a predetermined determination, the contents of which will be described later.

[0048] The creation unit 36 ​​is realized by commands from the CPU 101 shown in FIG. 3, and creates a cash flow screen and the like.

[0049] The storage / readout processing unit 39 is realized by instructions from the CPU 101 and the HDD controller 105 shown in FIG. 3, and performs processing such as storing various data in the storage unit 3000 and reading out various data stored in the storage unit 3000.

[0050] [Processing or Operation of the Embodiment] Next, the processing or operation of this embodiment will be described with reference to FIGS.

[0051] <Display process for the cash flow screen> First, the process of displaying the cash flow screen will be described with reference to Fig. 17. Fig. 17 is a sequence diagram showing the process of displaying the cash flow screen.

[0052] User A1 makes a login request to the proposal server 3 from the user terminal 1 (S21). This login request includes a tenant ID and a password for identifying service using company A, which is an example of a tenant. As a result, the transmitting / receiving unit 31 of the proposal server 3 receives the login request. Then, the determination unit 35 of the proposal server 3 performs authentication by determining whether or not the service using company A is a legitimate tenant that receives the service (S22).

[0053] Next, the transmitting / receiving unit 31 transmits the response to the user terminal 1 (S23). As a result, the transmitting / receiving unit 11 of the user terminal 1 receives the response. Now, the case where the service using company A is a legitimate tenant will be described.

[0054] When user A1 operates the user terminal 1, the reception unit 12 receives a request to display a cash flow screen (S24). Then, the transmission / reception unit 11 transmits a request for cash flow screen data to the proposal server 3 (S25). As a result, the transmission / reception unit 31 of the proposal server 3 receives the request for cash flow screen data.

[0055] Next, the proposal server 3 performs a process for creating a cash flow screen (S26). Here, the process for creating a cash flow screen will be described in detail with reference to Fig. 18. Fig. 18 is a flowchart showing the process for creating a cash flow screen.

[0056] (Cash flow screen creation process) 18, the storage / readout processing unit 39 searches the tenant regular expense management DB 3001 (see FIG. 5) using the tenant ID used during authentication as a search key to read out corresponding tenant regular expense information (S101). Similarly, the storage / readout processing unit 39 searches the tenant individual payment management DB 3002 (see FIG. 6) using the tenant ID as a search key to read out corresponding tenant individual payment information (S102). Then, the calculation unit 33 calculates expenditure information for each target period (one month in this case) to be displayed based on the tenant regular expense information and the tenant individual payment information (S103).

[0057] Next, the storage / readout processing unit 39 searches the funding information management DB 3003 (see FIG. 7) using the tenant ID as a search key to read out the corresponding funding information (S104). Then, the calculation unit 33 calculates income information for each target period (S105).

[0058] Next, the storage / readout processing unit 39 searches the tenant bank account management DB 3004 (see FIG. 8) using the tenant ID as a search key to read out the corresponding tenant bank account information (S106). The storage / readout processing unit 39 also searches the tenant credit card management DB 3005 (see FIG. 9) using the tenant ID as a search key to read out the corresponding tenant credit card information (S107). The calculation unit 33 then calculates the cash balance for each target period (S108).

[0059] Next, the creation unit 36 ​​creates a cash flow screen as shown in Fig. 19 using the calculation results calculated in steps S103, S105, and S108 (S109). Fig. 19 is a diagram showing an example of the cash flow screen display. This completes the process of creating the cash flow screen.

[0060] Next, returning to FIG. 17, the display control unit 14 of the user terminal 1 uses the web browser function to display the initial cash flow screen as shown in FIG. 19 on the display 106 of the user terminal 1 (S27).

[0061] (First cash flow screen) The initial cash flow screen 210 will now be described with reference to Fig. 19. Fig. 19 is a diagram showing an example of the cash flow screen display.

[0062] As shown in FIG. 19, the cash flow screen 210 includes a tenant ID display field 211, an operation date display field 212, a past income and expenditure performance display field 213, and a future income and expenditure forecast display field 214.

[0063] Of these, the operation date display field 212 displays the date of operation (the displayed date) on this cash flow screen. The past income and expenditure results display field 213 displays the income and expenditure results (expenses, income, cash balance) for each month prior to the operation date. These income and expenditure results are values ​​at the end of the month. For example, in August 2020, income was 1 million yen, the cash balance was 1.2 million yen, and expenses were 700,000 yen. Of these, the cash balance is the value of "income + cash balance - expenditure" for the previous month, July.

[0064] Furthermore, the future income / expense forecast display field 214 displays actual monthly results (expenses, income, and cash balance) for months beyond the operation date. Since the income / expense forecast is a value at the end of the month, if the operation date is September 15th, the income / expense for the end of September will be displayed in the income / expense forecast display field 214. Here, information 2141 indicating a shortfall of 2 million yen at the end of October is displayed. The expenditure for October is 2.6 million yen. Only the cash balance of 600,000 yen that will definitely exist by the payment date is used to cover this 2.6 million yen. As a result, shortfall information 2141 indicating a shortfall of 2 million yen in October is displayed. Note that the predicted income of 500,000 yen for October may not be paid in time for the payment date of the 2.6 million yen, so it will not be used to cover the shortfall of the 2.6 million yen expenditure. This allows the user to visually and easily understand that there will be a shortfall of 2 million yen at the end of October, 2020.

[0065] Furthermore, three reception fields 215 to 217 for receiving selections or inputs from the user are included at the bottom of the financing screen 210. From the user's perspective, the fund providing service company is the source of funding.

[0066] Of these, the "recommended priority conditions" reception column 215 displays a "commission rate priority (condition)" radio button 2151 and a "risk avoidance priority (condition)" radio button 2152.

[0067] "Fee rate priority" is an example of a predetermined condition for selecting a specific fund-raising source from among multiple fund-raising sources (fund-providing service companies) by prioritizing the lowest fee rate for each fund-raising source, which is determined based on the contents of each of the multiple fund-raising sources and multiple forms. When the user presses the "Fee rate priority" radio button 2151, the proposal server 3 proposes recommended information, described below, that prioritizes fee rate.

[0068] Furthermore, "risk avoidance priority" is an example of a predetermined condition for selecting a specific fund-raising source from among multiple fund-raising sources (fund-providing service companies) by prioritizing the trustworthiness of the business partner. When the user presses the "risk avoidance priority" radio button 2152, the proposal server 3 proposes recommended information, described below, that prioritizes risk avoidance. For example, if there is a high possibility that accounts receivable cannot be collected from a debtor who is a business partner company, accounts receivable from such a company will be given priority in raising funds.

[0069] Additionally, the "payment deadline for fund raising target" reception field 216 displays a period input field 2161 for inputting a predetermined period (here, one month). In FIG. 19, the predetermined period is input from the month including the operation date (here, September 2020) to six months later (February 2021). As a result, the recommended information described below is limited to information including reports in which payments are deducted from income up to February 2021.

[0070] Furthermore, the "Type of Funding Object" reception column 217 displays check boxes 2171, 2172, and 2173 for "invoice," "order form," and "quote" as specific examples of funding objects. Of the check boxes 2171 to 2173, documents (including electronic data) of the type checked by the user are eligible for fundraising. As shown in FIG. 19, in this embodiment, the types of fundraising objects also include "quotations" before a transaction (sale and purchase) is concluded. In other words, by selecting (specifying) the type of fundraising object desired, the user can narrow down the candidates for fundraising sources (funding service companies) to use.

[0071] Next, the "request recommendation" button 219 is a button that the user presses when, after making the desired selection and input in each reception field 215, 216, 217, the user wishes to have the proposal server 3 of proposing company C recommend a fundraising source (funding service company) that best suits the user's wishes.

[0072] <Recommended screen display process> Next, the display process of the recommendation screen will be described with reference to Fig. 19 to Fig. 27. Fig. 20 is a sequence diagram showing the display process of the recommendation screen.

[0073] First, in FIG. 19, when user A1 makes a desired selection and input in each of the reception fields 215 to 217, the reception unit 12 receives the selection and input (S41). Furthermore, when user A1 presses the "request recommendation" button 219, the reception unit 12 receives a request for a recommended screen (S42). Then, the transmission / reception unit 11 transmits a request for recommended screen data to the proposal server 3 (S43). Note that the processing of this step S43 corresponds to the processing of step S2 described above. Therefore, this request for recommended screen data includes the above-mentioned condition information (see S2). This condition information is information specified by the selection and input received in step S41, and indicates predetermined conditions regarding fundraising by user A1 using a form issued to provide a product or service.

[0074] Next, the proposal server 3 performs a process of narrowing down the recommended information (S44). Here, the process of narrowing down the recommended information will be described in detail with reference to Figs.

[0075] (Recommended screen creation process) Fig. 21 is a flowchart showing the process of narrowing down the recommended information. As shown in Fig. 21, when creating a recommendation screen, the proposal server 3 performs a preparatory process to identify a fund-providing service company that will actually make an inquiry about the commission rate from among a plurality of fund-providing service companies (fund-providing sources) (S121).

[0076] ((Preparation)) Here, the preparation process will be further described in detail with reference to Fig. 22. Fig. 22 is a flowchart showing the preparation process.

[0077] First, the storage / readout processing unit 39 searches the tenant management DB 3006 (see FIG. 10) using the tenant ID used for authentication in step S22 as a search key to read out information such as the tenant's address, industry, business type, etc. (S141).

[0078] Next, the storage / read processing unit 39 reads out the funding information (each record) from the funding information management DB 3003 (see Figure 7) whose payment deadline is included in the "payment deadline for funding target" entered in Figure 19 (S142).

[0079] Next, the storage / readout processing unit 39 refers to the funding service type management DB 3007 (see Figure 11) and identifies the type of funding service (procurement type) corresponding to the "type of funding target" selected in Figure 19 (S143).

[0080] Next, the storage / readout processing unit 39 searches the funding service management DB 3008 (see Figure 12) using the information on the type of funding service identified in step S143 as a search key, and identifies the information (funding service information) of the record that includes the corresponding funding service name (S144).

[0081] Next, the proposal server 3 repeatedly executes the processing of steps S146 to S150 between steps S145 and S151 for each piece of fund-providing service information.

[0082] First, the storage / readout processing unit 39 reads out the "non-supported industry," "supported area," and "supported individual business" of the funding service from the predetermined funding service information identified in step S145 (S146).

[0083] Next, the determination unit 35 executes a determination process based on each piece of information read (acquired) by the storage / readout processing unit 39 in steps S141 to S146 as described above. Specifically, based on the "non-compatible business type" information, the determination unit 35 determines whether the tenant business type of user A1 is non-compatible (S147). If it is not non-compatible (S147; NO), the determination unit 35 determines whether the tenant address of user A1 is outside the compatible area (S148). If it is not outside the compatible area (S148; NO), the determination unit 35 determines whether the business type of user A1's tenant corresponds to sole proprietorship (S149). If it corresponds (S149; YES), the determination unit 35 identifies the funding service (company) that actually inquires about the commission rate (S150). Then, returning to step S145, the proposal server 3 performs the same process for the next predetermined funding service information. On the other hand, if the answer is YES in step S147, YES in step S148, or NO in step S149, the proposal server 3 does not execute the processing of step S150, but returns to step S145 and performs similar processing on the next specified funding service information, thereby completing the processing of Figure 22.

[0084] In this way, the proposal server 3 can narrow down the specific funding services that are the subject of an inquiry about the commission rate from among all the funding services identified in step S144 (first narrowing down).

[0085] Next, returning to FIG. 21, the proposal server 3 creates recommendation candidate information that is a candidate for recommended information to be provided to the user A1 (S122).

[0086] ((Creating recommendation candidate information)) Here, the process of creating recommendation candidate information will be described with reference to Fig. 23. Fig. 23 is a flowchart showing the process of creating recommendation candidate information.

[0087] As shown in Fig. 23, the storage / readout processing unit 39 reads out from the funding information management DB 3003 (see Fig. 7) the funding information (each record) whose payment deadline is included in the "payment deadline for funding target" input in Fig. 19 (S161). Next, the proposal server 3 repeatedly executes the processes of steps S163 to S171 between steps S162 and S172 for each piece of funding information read out in step S161.

[0088] First, the storage / readout processing unit 39 refers to the funding service type management DB 3007 (see FIG. 11) and identifies the type of funding service corresponding to the "type of funding target" selected in FIG. 19 (S163).

[0089] Next, the transmitter / receiver 31 creates inquiry information for each identified type of funding service among the specific funding services (companies) for which the commission rate is to be queried, and obtains the commission rate from the funding service server 5 that manages the specific funding service (S164). The transmitter / receiver 31 makes the commission rate inquiry by reference to the destination information of each funding service server 5 managed in the destination information management DB 3009 (see FIG. 12). Here, in the processing of step S164, in FIG. 20, the transmitter / receiver 31 of the proposal server 3 sends commission rate inquiry information to each funding service server 5 (S164-1), and receives the latest commission rate information sent by the funding service server 5 (S164-2).

[0090] Next, the storage / read processing unit 39 stores the commission rate information received from each funding service server 5 in the storage unit 3000 (S165).

[0091] Next, the creation unit 36 ​​identifies information in which the funding information is associated with the funding service with the lowest commission rate as the comparison target for the comparison described below (secondary narrowing down) (S166). For example, in Fig. 16, if the business partner is X1 Corporation and the transaction amount is an invoice of 900,000 yen, services A1, A2, B1, B2, etc. are listed as potential funding sources, and among these, funding service B2 with the lowest commission rate (5%) is identified as the comparison target, in which the funding information (X1 Corporation, credit rating of 5, invoice of 900,000 yen, etc.) is associated with the funding information.

[0092] Next, the storage / read processing unit 39 further acquires credit information of the business partner (company) from the fundraising information read out in step S161 (S167).

[0093] Next, the transmitting and receiving unit 31 acquires the credit information of trading partner company B from each credit information server 7 (S168). In this case, the transmitting and receiving unit 31 makes an inquiry by referring to the destination information of each credit information server 7 managed in the destination information management DB 3009. In addition, as the processing of step S168, in FIG. 20, the transmitting and receiving unit 31 of the proposal server 3 transmits a request for credit information to each credit information server 7 (S168-1) and receives the credit information transmitted by the credit information server 7 (S168-2).

[0094] However, the content of the credit information varies depending on the credit information service company. For example, some companies manage credit information using a three-level scale (H, N, L), while others manage it using a seven-level scale (7-1), so adjustments are necessary. Therefore, in order to adjust the response information received from each credit information server 7 to a unified credit rating, the storage and readout processing unit 39 refers to the credit information adjustment management DB 3010 and replaces the response information received from each credit information server 7 with the unified credit rating (S169). Then, the storage and readout processing unit 39 manages the credit rating of each customer (company) in the credit information management DB 3011 (S170).

[0095] Then, the storage / read processing unit 39 manages each piece of recommended candidate information, which is obtained by collecting each piece of information acquired and managed in steps S161 to S171 for each business partner, in the recommended candidate information management DB 3012 (see FIG. 16) (S171).

[0096] In this way, the proposal server 3 can manage the recommendation candidate information.

[0097] ((Sorting by recommendation)) Next, returning to FIG. 21, a process of rearranging (sorting) the recommendation candidate information as recommendation information according to the priority information selected in FIG. 19 will be described.

[0098] 19, when commission rate priority is selected as the priority condition for recommendation (S123; commission rate priority), the storage / readout processing unit 39 compares each piece of recommended candidate information managed in the recommended candidate information management DB 3012 and finally extracts recommended information that meets the user's request. In this manner, the storage / readout processing unit 39 sorts the recommended candidate information, which are comparison targets, in descending order of commission rate as a first condition and descending order of trustworthiness as a second condition, and reads out each piece of recommended information that is optimal for commission rate priority (S124). For example, in FIG. 16, the comparison targets include recommended candidate information indicating service B2 with the lowest commission rate of 5% for an invoice for Co., Ltd. X1 with a transaction amount of 900,000 yen, recommended candidate information indicating service B1 with the lowest commission rate of 6% for an invoice for Co., Ltd. X2 with a transaction amount of 500,000 yen, recommended candidate information indicating service B2 with the lowest commission rate of 6%, and recommended candidate information indicating service B2 with the lowest commission rate of 7% for an invoice for Co., Ltd. X3 with a transaction amount of 800,000 yen. Furthermore, sorting the comparison targets in ascending order of commission rate (first condition) results in the following order: a combination of an invoice for a transaction amount of 900,000 yen to Co., Ltd. X1 and Service B2 (commission rate 5%), a combination of an invoice for a transaction amount of 500,000 yen to Co., Ltd. X2 and Service B1 (commission rate 6%), and a combination of an invoice for a transaction amount of 800,000 yen to Co., Ltd. X3 and Service B2 (commission rate 7%). If there are multiple comparison targets with the same commission rate, the comparison targets with the same commission rate are further sorted in descending order of creditworthiness (second condition). That is, the comparison targets are sorted by the first condition, and those with the same first condition are sorted by the second condition. The same applies if risk avoidance priority is selected as the priority condition described below.

[0099] On the other hand, if risk avoidance priority is selected as the priority condition in Figure 19 (S123; risk avoidance priority), the storage and reading processing unit 39 compares each piece of recommended candidate information managed in the recommended candidate information management DB 3012 and finally extracts recommended information that meets the user's request.In this way, the storage and reading processing unit 39 sorts the comparison targets, that is, each piece of recommended candidate information, in order of lowest credibility as the first condition and lowest commission rate as the second condition, and reads out each piece of recommended information that is optimal for risk avoidance priority (S125).

[0100] Next, the storage / read processing unit 39 extracts the documents after rearrangement in steps S124 and S125 so as to make up for the shortfall in the cash flow (S126).

[0101] Then, the storage / read processing unit 39 reads out the data of the recommended screen frame stored in the storage unit 3000 (S127).

[0102] <Redisplay process of the cash flow screen> Next, returning to FIG. 20, the process of redisplaying the cash flow screen will be described.

[0103] First, after the process of narrowing down the recommended information is completed in step S44, the transmitter / receiver 31 transmits to the user terminal 1 all of the recommended information narrowed down in step S44 and the data of the recommended screen frame read in step S127 (S45). As a result, the transmitter / receiver 11 of the user terminal 1 receives all of the recommended information and the data of the recommended screen frame. The process of step S45 corresponds to the process of step S3 described above.

[0104] Next, in the user terminal 1, the display control unit 14 displays a recommendation screen as shown in FIG. 24 (or FIG. 26) on the display 106 of the user terminal 1 by including the recommendation information in the recommendation screen frame received in step S45 (S46). At this point, the checkbox is not checked. FIG. 24 is a diagram showing an example of the display of the recommendation screen when priority is given to commission rate. FIG. 26 is a diagram showing an example of the display of the recommendation screen when priority is given to risk avoidance. Note that FIG. 25 is a diagram showing an example of the display of the recommendation screen after the display change when priority is given to commission rate.

[0105] (Recommended screen (priority on commission rate)) Here, a case where the recommendation screen indicates that priority is given to the commission rate will be described with reference to Fig. 24. Fig. 24 is a diagram showing an example of the display of the recommendation screen in the case where priority is given to the commission rate.

[0106] As shown in Figure 24, the recommendation screen 250 includes each recommended information item (information about the documents used for fundraising, such as the business partner, type of fundraising target, transaction amount, payment due date, information about the fundraising source, such as the type of fundraising source, the fundraising source, commission rate, adjustment amount, payment date, and the creditworthiness of the business partner). Also, a check box for selection is displayed to the left of each recommended information item. The transaction amount is the amount the user plans to receive from the business partner. The fundraising amount is the amount received from the fund providing service company (fundraising source), after commission has been deducted. Also, all check boxes currently displayed are checked from the start.

[0107] Furthermore, the total procurement amount and the shortfall amount are displayed in the lower left corner of the recommendation screen 250. The total procurement amount indicates the total procurement amount of the recommended information for which the user A1 has checked the checkbox. From the beginning, the total procurement amount is displayed as the lowest total amount, even though it exceeds the shortfall amount.

[0108] Also, a "Confirm" button 257 and a "View other recommendations" button 259 are displayed on the lower right side of the recommendation screen 250. The "Confirm" button 257 is a button that the user A1 presses when confirming the display content of FIG. 24. When the "Confirm" button 257 is pressed, the user terminal 1 transmits confirmation information indicating that the content has been confirmed to the proposal server 3. The "View other recommendations" button 258 is a button that the user presses when displaying other examples of the recommended information.

[0109] In this state, when user A1 presses the "See other recommendations" button 258, the display control unit 14 changes to the recommendation screen 251 as shown in Fig. 25 (S47). Here, two new recommended information items are displayed, but the check boxes are not checked. In other words, the recommended information displayed in Fig. 24 has been narrowed down to the third level.

[0110] 24. Also, a "Return to initial recommendation" button 259 is displayed in place of the "See other recommendations" button 258 at the bottom right of the recommendation screen 251. When the "Return to initial recommendation" button 259 is pressed, the display control unit 14 returns the display from the recommendation screen 251 in FIG. 25 to the recommendation screen 250 in FIG. 24.

[0111] As described above, the recommendation screen in Figure 25 displays information about the forms used for fundraising and information about the source of fundraising, but it may also be possible to display only information about the forms used for fundraising, or only information about the source of fundraising.

[0112] (Recommended screen (prioritize risk avoidance)) A case where the recommendation screen indicates that priority is given to risk avoidance will be described with reference to Fig. 26. Fig. 26 is a diagram showing a display example of the recommendation screen in the case where priority is given to risk avoidance.

[0113] In this case, the configuration is basically the same as the recommendation screen with priority on commission rate. That is, as shown in Fig. 26, the recommendation screen 260 includes each recommended information (information about the form used for fundraising, such as the business partner, fundraising target type, transaction amount, scheduled payment date, information about the fundraising source, such as the procurement type, procurement source, commission rate, adjustment amount, payment date, and the creditworthiness of the business partner). In addition, a check box for selection is displayed to the left of each recommended information.

[0114] Furthermore, the total procurement amount and the shortfall amount are displayed in the lower left of the recommendation screen 260. The total procurement amount indicates the total procurement amount for the recommended information for which user A1 has checked the checkboxes. Also, the "Confirm" button 268 and "View other recommendations" button 269 in the lower right of the recommendation screen 260 are the same as the "Confirm" button 257 and "View other recommendations" button 258 in the lower right of the recommendation screen 250 in FIG. 24, respectively.

[0115] Here, the case where user A1 presses the "OK" button 257 with the three checkboxes in FIG. 24 still checked will be explained.

[0116] When user A1 presses the "Confirm" button 257, the accepting unit 12 accepts the recommended information selected by the checkboxes (S48), as shown in Fig. 20. Then, the transmitting / receiving unit 11 transmits the recommended information selected in step S48 to the proposal server 3 (S49). As a result, the transmitting / receiving unit 31 of the proposal server 3 receives the selected recommended information.

[0117] Next, in the proposal server 3, the creation unit 36 ​​creates a cash flow screen as shown in FIG. 27, reflecting the recommendation information received in step S49 (S50).

[0118] Next, after the process of creating the cash flow screen reflecting the recommended information is completed in step S50, the display control unit 14 of the user terminal 1 uses the web browser function to display the recommended screen created in step S50 on the display 106 of the user terminal 1 (S51).

[0119] In this case too, it is possible to change to a recommendation screen such as that shown in FIG. 26, but the explanation will be omitted.

[0120] As described above, the recommendation screen in Figure 26 displays information about the forms used for fundraising and information about the source of fundraising, but it may also be possible to display only information about the forms used for fundraising, or only information about the source of fundraising.

[0121] (Cash flow screen reflecting recommended information) Here, the cash flow screen 220 that reflects the recommended information when the commission rate is prioritized will be described with reference to Fig. 27. Fig. 27 is a diagram showing a display example of the cash flow screen that reflects the recommended information when the commission rate is prioritized.

[0122] As shown in Figure 27, the cash flow screen 220 displays information 2251 indicating that 2,069,000 yen can be raised if new funds are provided, in addition to the cash flow screen 210 of Figure 19. In addition, the income and cash balance from October 2020 onwards will be changed due to the provision of 2,069,000 yen. In particular, since the funds etc. raised by user A1 in October 2020 will not become income thereafter, information 2261, 2262, and 2263 indicating this non-income amount is displayed.

[0123] Furthermore, the cash flow screen 220 includes a "Confirm" button 229 on the lower right side. The "Confirm" button 229 is a button that user A1 presses when he / she confirms the content shown in FIG. 27 and closes the screen 220 of FIG. 27. Furthermore, when user A1 presses the "Confirm" button 228 in FIG. 27, the reception unit 12 receives confirmation, as shown in FIG. 20 (S50). Then, the transmission / reception unit 11 transmits confirmation information indicating that the content displayed in step S49 has been confirmed to the proposal server 3 (S53). As a result, the transmission / reception unit 31 of the proposal server 3 receives the confirmation information.

[0124] This completes the process of redisplaying the cash flow screen.

[0125] [Modification] <Preferential conditions for specific business partners> On the cash flow screen shown in Figure 19, you can select either commission rate priority or risk avoidance priority as the recommended priority condition. Below, we will explain a modified example in which a specific customer priority condition is added to the recommended priority conditions to prioritize fund raising for accounts receivable from specific customer companies.

[0126] There are cases where a company may want to prioritize raising funds for accounts receivable from a specific business partner, such as when service user company A determines that there are circumstances that make it difficult to collect accounts receivable from a specific business partner, based on the transaction situation with the company (for example, the company may go bankrupt in the near future).

[0127] (Cash flow screen with specific customer priority conditions added) First, the cash flow screen 230 to which the specific customer preferential condition has been added will be described with reference to Fig. 28. Fig. 28 is a diagram showing a display example of the cash flow screen to which the specific customer preferential condition has been added.

[0128] 28, on the cash flow screen 230, a "Specify Priority Supplier" button 2153 is displayed in the "Recommended Priority Terms" reception field 215. When user A1 presses the "Specify Priority Supplier" button 2153, the reception unit 12 receives a request for the priority supplier selection screen. Then, the transmission / reception unit 11 transmits a request for priority supplier selection screen data to the proposal server 3.

[0129] In the proposal server 3, the transmitting / receiving unit 31 receives a request for preferred supplier selection screen data. Next, the storage / read processing unit 39 retrieves the corresponding funding information by searching the funding information management DB 3003 (see FIG. 7) using the tenant ID used during authentication as a search key. Next, the creation unit 36 ​​uses the funding information retrieved by the storage / read processing unit 39 to create a preferred supplier selection screen such as that shown in FIG. 29. Then, the transmission / reception unit 31 transmits the preferred supplier selection screen data to the user terminal 1.

[0130] In the user terminal 1, the display control unit 14 uses the web browser function to display a preferred business partner selection screen such as that shown in Figure 29 on the display 106 of the user terminal 1 based on the received preferred business partner selection screen data.

[0131] (Preferred business partner selection screen) Here, the preferred business partner selection screen 270 will be described with reference to Fig. 29. Fig. 29 is a diagram showing an example of the preferred business partner selection screen.

[0132] As shown in FIG. 29, the priority supplier selection screen 270 includes a supplier list display field 271, a selected supplier display field 272, an OK button 278, and a cancel button 279.

[0133] Of these, the customer list display field 271 displays a list of customers whose forms are managed in the funding information management DB 3003. The order of customers displayed in the customer list display field 271 is arranged according to a predetermined rule. The predetermined rule may be any rule that makes it easy for user A1 to find the customer he or she is looking for. For example, the order may be based on the notation of the customer name, or the order may be based on the creditworthiness managed in the credit information management DB 3011.

[0134] User A1 selects a business partner from the business partner list display field 271 and moves it to the selected business partner display field 272, thereby selecting that business partner as a priority business partner. In the selected business partner display field 272, it is possible to change the order of the selected business partners. The order displayed in the selected business partner display field 272 represents the order of priority. In other words, the business partner displayed at the top of the selected business partner display field 272 is selected as the business partner with the highest priority, and the business partner displayed second from the top is selected as the business partner with the second highest priority.

[0135] When user A1 presses the OK button 278, the customer displayed in the selected customer display field 272 is selected as the preferred customer, the preferred customer selection screen closes, and the screen returns to the cash flow screen 230 of Figure 28. When user A1 presses the Cancel button 279, the preferred customer selection screen closes without selecting a preferred customer, and the screen returns to the cash flow screen 230 of Figure 28.

[0136] (Create a recommendation screen with specific customer priority conditions added) Figure 30 is a flowchart showing the process of narrowing down recommended information when a specific supplier priority condition is added. The only difference from the process of narrowing down recommended information shown in Figure 21 is that steps S126 and S127 have been added. Therefore, the process from step S126 onwards will be explained here.

[0137] 29 is specified as a priority condition (S126; YES), the storage and readout processing unit 39 reads out each piece of recommended information by rearranging the comparison targets corresponding to the suppliers specified as priority suppliers among the comparison targets that are each piece of recommended candidate information managed in the recommended candidate information management DB 3012 in accordance with the priority order of the priority suppliers.The storage and readout processing unit 39 then inserts each piece of recommended information corresponding to the priority supplier at the beginning of each piece of recommended information read out in step S123 or S124 (S127).

[0138] Next, the storage / read processing unit 39 extracts the documents rearranged in step S127 so as to make up for the shortfall in the cash flow (S128).

[0139] Then, the storage / read processing unit 39 reads out the data of the recommended screen frame stored in the storage unit 3000 (S129).

[0140] (Recommended screen (priority for specific business partners)) Here, the recommendation screen when priority is given to specific business partners will be described with reference to Fig. 31. Fig. 31 is a diagram showing an example of the display of the recommendation screen when priority is given to specific business partners.

[0141] 31, information about the designated preferred business partner is displayed at the top of the recommendation screen 252. Also, all check boxes displayed are checked from the start.

[0142] Furthermore, the total purchase amount displayed on the lower left side of the recommendation screen 252 indicates the total purchase amount of the recommended information items whose checkboxes are checked.

[0143] (Cash flow screen reflecting recommended information for prioritizing specific clients) Here, the cash flow screen 240 that reflects the recommended information that prioritizes specific business partners will be described with reference to Fig. 32. Fig. 32 is a diagram showing an example of the cash flow screen that reflects the recommended information that prioritizes specific business partners.

[0144] As shown in Figure 32, the cash flow screen 240 displays a new field 2154 for displaying preferred business partners in addition to the cash flow screen 220 of Figure 27. Information 2251 indicating the amount of funds available is changed to an amount based on the recommended information that prioritizes specific business partners. Also, similar to the cash flow screen 220 of Figure 27, the income and cash balance from October 2020 onwards are changed based on the recommended information that prioritizes specific business partners.

[0145] [Major Effects of the Present Embodiment] As described above, according to this embodiment, the proposal server 3 transmits to the user terminal 1 a specific fund-raising source (or a document) that provides fund-raising that meets the predetermined conditions requested by the user A1. In other words, the proposal server 3 makes a proposal to the user terminal 1 indicating "where" to apply for fund-raising, thereby resolving the problem that the user A1 has difficulty in finding a fund-raising source (or a document) that meets the conditions that the user A1 expects.

[0146] Furthermore, the proposal server 3 transmits information indicating a specific form determined based on predetermined conditions from among multiple forms issued when user A1 provides a product or service to the user terminal 1. In other words, the proposal server 3 makes a proposal to the user terminal 1 indicating "what" to apply for funding from a predetermined fund-raising source, thereby resolving the problem that user A1 has difficulty finding a fund-raising source that meets the conditions he or she envisions.

[0147] 〔supplement〕 After step S53 in FIG. 20, the proposal server 3 may apply for step S4 in FIG. 1 on behalf of the user A1.

[0148] The user terminal 1 is an example of a communication terminal. The user terminal 1 includes not only a PC but also a smart watch, a game console, a device dedicated to video calls, etc. The presenter terminal is an example of another communication terminal.

[0149] Each component such as the CPU 101 may be a single component or a plurality of components.

[0150] Each function in the above-described embodiments can be realized by one or more processing circuits. Here, the "processing circuit" in the present embodiment includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and devices designed to execute each of the above-described functions, such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), a SOC (System on a Chip), a GPU, and a conventional circuit module.

[0151] Additionally, each of the servers 3, 5, and 7 described in the above embodiments merely represents one of multiple computing environments for implementing the embodiments disclosed herein. For example, the proposal server 3 may include multiple computing devices, such as a server cluster. The multiple computing devices are configured to communicate with each other via any type of communication link, including a communication network, shared memory, etc., and perform the processes disclosed herein. Similarly, the proposal server 3 may include multiple computing devices configured to communicate with each other.

[0152] Furthermore, the proposal server 3 can be configured to share the disclosed processing steps in various combinations. For example, the processes performed by the proposal server 3 can be performed by other servers. Similarly, the functions of the proposal server 3 can be performed by other servers. Furthermore, the elements of the proposal server 3 and other servers can be combined into one server or separated into multiple devices.

[0153] Furthermore, in communications between each terminal and each server, other servers, routers, etc. may relay data.

[0154] 〔summary〕 The present embodiment will be summarized below. Note that the descriptions in parentheses do not limit the scope of the claims, but are merely examples.

[0155] A proposal server that proposes information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner receives condition information sent by the user terminal indicating specified conditions for fundraising using a form issued by the user when the user provides the product or service (see S2, S45), and transmits to the user terminal information indicating a specific form from among the multiple forms that is designed to make up for a shortfall in the user's cash flow based on the specified conditions (see S3, S45, see ``Business Partner,'' ``Type of Fundraising Target,'' ``Transaction Amount,'' and ``Payment Due Date'' in Figure 24). [Explanation of symbols]

[0156] 1. User terminal 3 Proposal Server 5 Funding Service Server 7. Credit Information Server 11 Transmitter / Receiver 12 Reception 14 Display control unit 15 Judgment Department 19 Storage and readout processing section 31 Transmitting / receiving unit (an example of a transmitting means, an example of a receiving means) 33 Calculation section 35 Judgment Department 36 Creation Department 39 Storage and readout processing section 100 Communication Network

Claims

1. A proposal server that proposes information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner, a receiving means for receiving condition information transmitted from the user terminal, the condition information indicating predetermined conditions related to fundraising using a document issued when the user provides the product or service; a transmitting means for transmitting to the user terminal information indicating a specific document among the plurality of documents, the specific document being determined to make up for a shortage of funds in the user's cash flow based on the predetermined conditions; A proposal server comprising:

2. The proposal server described in claim 1, characterized in that the specified condition is a commission rate priority condition for determining the specific form by prioritizing a low commission rate for each funding source determined by each of the multiple funding sources and the contents of the multiple forms.

3. 3. The proposal server according to claim 2, wherein the predetermined condition is a risk avoidance priority condition for determining the specific form by giving priority to a low reliability of the business partner.

4. 4. The proposal server according to claim 2, wherein the predetermined conditions include a specific supplier priority condition for giving priority to the forms issued by a specific supplier and determining the specific forms.

5. the receiving means receives information indicating a due date for payment of a form from the user terminal, The transmitting means transmits, to the user terminal, information indicating the specific form that satisfies the predetermined condition within the payment deadline of the form. The proposal server according to any one of claims 1 to 4, characterized in that:

6. the receiving means receives form type information indicating a type of form from the user terminal; The transmitting means transmits information indicating the specific form that satisfies the predetermined condition within the range of the type of the form to the user terminal. The proposal server according to any one of claims 1 to 5, characterized in that:

7. 7. The proposal server according to claim 6, wherein the type of the form indicates an invoice, an order form, or an estimate.

8. A communication system constructed by a user terminal of a user who provides or plans to provide a product or service to a business partner, and a proposal server that proposes information to the user terminal via a communication network, the user terminal transmits condition information indicating predetermined conditions regarding fundraising using a document issued when the user provides the product or service; the proposal server receives the condition information and transmits information indicating a specific form determined based on the predetermined condition from among the plurality of forms; The user terminal receives information indicating the specific form. A communication system comprising:

9. A proposal method executed by a proposal server that proposes information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner, a receiving step of receiving condition information transmitted from the user terminal, the condition information indicating predetermined conditions related to fundraising using a document issued for the user to provide the product or service; a transmitting step of transmitting information indicating a specific form determined based on the predetermined condition from among the plurality of forms to the user terminal; The proposed method is characterized by executing the following.

10. A program for causing a computer to execute the proposed method according to claim 9.

Images