Device, method, and program for purchasing all or part of accounts receivable

Abstract

To enhance information provided at the time of application for use without excessively increasing the burden on a user in a method for purchasing accounts receivable.SOLUTION: A device 100 receives invoice information from a user terminal 110 used by a user. Next, the device 100 transmits input screen display information for indicating the intention of API cooperation with an external service to the user terminal 110. An external server 120 providing the external service performs SAML authentication in response to the user's affirmative input on an input screen, and after the success of the authentication, the device 100 receives credentials generated by the external server 120. The external server 120 performs account registration based on an input on a registration screen for specifying a financial institution account to be registered in the external service, and after the completion of the account registration, the device 100 obtains history information for the account from the external server 120. Then, the device 100 receives application information required for purchase from the user terminal 110.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to an apparatus, a method, and a program for purchasing all or part of an account receivable arising from an invoice issued by a user. [Background technology]

[0002] The use of a service called "factoring," which purchases invoices sent to business partners before payment is received, and pays a fee, is becoming more common. For business owners who do not necessarily have a lot of cash, such as sole proprietors, there is a problem that they are unable to invest sufficiently in the next growth opportunity due to a lack of purchasing funds until payment is received from business partners, and although a commission is deducted from the fee, the convenience of being able to receive the fee early is accepted by users.

[0003] When a factoring service provider receives an application, they conduct an examination based on the information provided by the user, and if the application meets certain criteria, they purchase the accounts receivable arising from the invoice that is the subject of the application at the amount of the accounts receivable minus a commission fee. The information provided by the user for the examination includes user information, business partner information, and invoice information. The user then makes a payment to the company after receiving payment from the business partner. There is also a type of factoring called "three-party factoring" in which the business partner directly pays the factoring service provider, but this requires the consent of the business partner. Summary of the Invention [Problem to be solved by the invention]

[0004] In any case, factoring service providers will incur a loss on the purchase price of their accounts receivable if they do not receive payment from their clients, so it is desirable for them to improve the level of screening. However, if the amount of information that users must provide when applying for service is increased excessively, the application process itself will become a burdensome task, which could become an obstacle to the use of factoring services.

[0005] The present invention has been made in consideration of these problems, and its object is to provide an apparatus, method, or program for purchasing all or part of accounts receivable arising from invoices that enhances the information provided at the time of application, without excessively increasing the burden on the user. [Means for solving the problem]

[0006] In order to achieve this object, a first aspect of the present invention is a method for purchasing all or a portion of accounts receivable arising from an invoice issued by a user, comprising the steps of receiving invoice information regarding the invoice from a user terminal used by the user, transmitting input screen display information to the user terminal to indicate an intention to API integrate with an external service that has access to history information for checking the user's activity history, receiving credentials for the API integration generated by the external server in association with the user after an external server providing the external service successfully completes SAML authentication in response to the user's affirmative input on an input screen displayed on a display screen of the user terminal based on the input screen display information, obtaining history information on the financial institution account from the external server using the credentials after the external server completes registration of the financial institution account specified by financial institution information entered on a registration screen for specifying the financial institution account to be registered in the external service, and receiving application information necessary for purchasing all or a portion of the accounts receivable from the user terminal.

[0007] A second aspect of the present invention is the method according to the first aspect, wherein the invoice information includes an invoice amount, an invoice date, a payment due date, and a supplier name.

[0008] A third aspect of the present invention is the method of the first aspect, wherein the credentials are an access token.

[0009] A fourth aspect of the present invention is the method of the first aspect, wherein the financial institution account is a bank account.

[0010] Moreover, a fifth aspect of the present invention is a method of any one of the first to fourth aspects, wherein the acquisition of the history information is initiated in response to an application content input screen for inputting the application information being displayed on the display screen of the user terminal.

[0011] A sixth aspect of the present invention is the method according to any one of the first to fourth aspects, further comprising the step of generating credit information for the user using the history information.

[0012] A seventh aspect of the present invention is the method according to the sixth aspect, further comprising the step of determining an upper limit of the amount of money that the user can apply for based on the credit information.

[0013] In addition, an eighth aspect of the present invention is a method according to any one of the first to seventh aspects, further comprising a step of determining whether or not to purchase the accounts receivable using the history information and the application information.

[0014] In addition, a ninth aspect of the present invention is a program for causing a computer to execute a method for purchasing all or part of accounts receivable arising from an invoice issued by a user, the method including the steps of receiving invoice information regarding the invoice from a user terminal used by the user, transmitting input screen display information to the user terminal to indicate an intention to API connect with an external service that can access history information for confirming the user's activity history, receiving credentials for the API connect generated by the external server in association with the user after an external server providing the external service successfully completes SAML authentication in response to a positive input by the user on an input screen displayed on a display screen of the user terminal based on the input screen display information, obtaining history information on the financial institution account from the external server using the credentials after the external server completes registration of the financial institution account specified by financial institution information entered on a registration screen for specifying the financial institution account to be registered in the external service, and receiving application information necessary for purchasing all or part of the accounts receivable from the user terminal.

[0015] In addition, a tenth aspect of the present invention is a device for purchasing all or part of accounts receivable arising from an invoice issued by a user, which receives invoice information regarding the invoice from a user terminal used by the user, and transmits input screen display information to the user terminal to indicate an intention to API integrate with an external service that can access history information for confirming the user's activity history, and after an external server providing the external service successfully completes SAML authentication in response to the user's affirmative input on an input screen displayed on the display screen of the user terminal based on the input screen display information, the external server receives credentials for the API integration generated by the external server in association with the user, and after the external server completes registration of a financial institution account specified by financial institution information entered on a registration screen for specifying a financial institution account to be registered in the external service, the external server obtains history information for the financial institution account from the external server using the credentials, and receives application information necessary for purchasing all or part of the accounts receivable from the user terminal. Effect of the Invention

[0016] According to one aspect of the present invention, by incorporating a submission process using API integration of historical information in the account of the financial institution used by the user into part of the application flow for the invoice purchase service, it is possible to enrich the information provided at the time of application without excessively increasing the burden on the user. [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 illustrates a system according to an embodiment of the present invention. [Diagram 2] 2 is a flow diagram of a method for purchasing accounts receivable in accordance with an embodiment of the present invention. [Diagram 3] 13 is an example of an input screen for indicating an intention for API linkage according to one embodiment of the present invention. [Figure 4] 13 is an example of a registration screen of a financial institution according to an embodiment of the present invention. [Diagram 5]13 is an example of an input screen for application information according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0019] A system according to an embodiment of the present invention is shown in Fig. 1. The device 100 communicates with a user terminal 110 used by a user of the bill purchase service provided by the device 100 and an external server 120 that provides an external service that allows access to historical information of bank accounts, via an IP network such as the Internet. In addition, the device 100, the user terminal 110, and the external server 120 can each communicate, as necessary, with a financial institution server 130 that provides online historical information on financial institution accounts, via the IP network.

[0020] The device 100 includes a communication unit 101 such as a communication interface, a processing unit 102 such as a processor or CPU, and a storage unit 103 including a storage device or storage medium such as a memory or a hard disk, and can be configured by executing a program for performing each process or operation in the processing unit 102. The device 100 may include one or more devices, computers, or servers. The program may include one or more programs, and may be recorded in a computer-readable storage medium to form a non-transient program product. The program may be stored in a storage device or storage medium 104 accessible from the storage unit 103 or the device 100 via an IP network, and instructions included in the program may be executed in at least one processor of the processing unit 102. Data described below as being stored in the storage unit 103 may be stored in the storage device or storage medium 104, and vice versa.

[0021] First, the device 100 receives invoice information related to the contents of the invoice from the user terminal 110 (S201). The invoice information includes the amount invoiced to the business partner, and may further include at least one of the invoice date, the payment due date, the business partner name, and the business partner address. It is also possible that the device 100 receives application information, which will be described later, at the same time as the invoice information.

[0022] Next, the device 100 transmits to the user terminal 110 input screen display information for indicating an intention to API link with an external service that can access the bank account history information of the user using the user terminal 110 (S202). FIG. 3 shows an example of an input screen 300, and the user can indicate an intention to API link with the external service by selecting by clicking or tapping a button labeled "Service A". Here, the external service has been described as being capable of accessing the bank account history information of the user, but more generally, it may be any service that can access history information for checking the user's activity history. The transmission of the input screen display information described above can be performed in response to the device 100 receiving invoice information from the user terminal 110.

[0023] Here, the input by the user can be performed from an input screen displayed on a web browser on the display screen of the user terminal 110 by transmitting input screen display information as, for example, an HTML format file, or from an input screen displayed on an application (hereinafter also referred to as an "app") installed on the user terminal 110 by running the application. Note that the "input screen" can adopt various formats such as a web page, a modal window, a pop-up window, etc. when displayed on a web browser, and can be one screen of the app when displayed on the app. In either case, a screen that includes an area having an input field for the user to input a positive intention corresponds to an input screen. Similar techniques can be applied to other screens mentioned in this specification.

[0024] When the user indicates an intention to perform API collaboration with an external service (S203), the external server 120 that provides the external service executes SAML authentication (S204). For SAML authentication, the external server 120 may communicate with an IdP (not shown) as appropriate. During the SAML authentication process, an identifier such as an email address of the user who indicates an intention to perform API collaboration, a password associated with the identifier, and other account information may be transmitted from the user terminal 110 to the IdP. Such account information may be transmitted from the user terminal 110 to the external server 120 in response to input of an intention to perform API collaboration, which is a trigger for the execution of SAML authentication, and then transmitted from the external server 120 to the IdP.

[0025] Here, before entering invoice information, the user logs in to the invoice purchase service provided by device 100, and an identifier for identifying the user within the invoice purchase service is stored in the web browser running on user terminal 110, and this identifier may be the same as or different from the identifier used in the SAML authentication described above.

[0026] After the SAML authentication is successful, the external server 120 sends to the user terminal 110 authorization screen display information requesting authorization for the invoice purchase service provided by the device 100 to integrate with an external service provided by the external server 120 via API (S205).

[0027] If the user agrees to the authorization (S206), the external server 120 generates an external service identifier for the user to use the external service provided by the external server 120 and credentials associated with the external service identifier (S207), and transmits the credentials to the device 100 (S208). The external service identifier is made the same as the identifier of the account authenticated by the above-mentioned SAML authentication, thereby reducing the burden on the user when using the external service. An example of the credentials received by the device 100 is an access token for accessing the external service through API cooperation, which is stored in the user terminal 110 or a storage device or storage medium 104 accessible from the user terminal 110 in association with an identifier for identifying the user in the bill purchase service provided by the device 100. In addition to the credentials, an external service identifier associated with the credentials may be transmitted to the device 100 as necessary.

[0028] Upon receiving the credentials, the device 100 causes the user terminal 110, via the external server 120 as necessary, to display a registration screen for designating a financial institution such as a bank to be registered in the external service (S209). An example of the registration screen 400 is shown in FIG. 4. In this example, the user can start inputting information about his / her account by selecting the "Register bank" button by clicking or tapping. The registration screen 400 does not necessarily have to be displayed by the device 100, but may be displayed by the external server 120.

[0029] The name or identifier of the financial institution entered by the user on the registration screen is sent to the external server 120 (S210), and the external server 120 sends, if necessary, to the user terminal 110 display information for an authentication screen for the online services provided by the financial institution server 130 (S211).

[0030] The user inputs authentication information for the online service from the authentication screen (S212), and the bank server 130, after successfully authenticating the user based on the received authentication information, transmits a notification to the external server 120 that the account registration has been completed (S213). The external server 120, which has received the notification, further transmits a notification to the device 100 that the account registration has been completed (S214).

[0031] The device 100 transitions the display screen of the user terminal 110 to an input screen for the usage application details (S215). Before the transition, for example, the screen may transition to an input screen 300 shown in Fig. 3, and the user may input the usage application details by clicking or tapping a button labeled "Enter usage application". In this case, the description "Not linked" may be changed to "Linked" to visually indicate that API linkage has been completed.

[0032] The device 100 can obtain the history information of the user's account registered in the external service from the external server 120 by using the credentials after the registration is completed. More specifically, the acquisition of the history information from the device 100 may be started in response to the display of an input screen for the contents of the application for use on the display screen of the user terminal 110, the transmission of application information for the application for use from the user terminal 110 to the device 100 or the reception of the application information by the device 100, or the clicking or tapping of an update button for updating the history information displayed on the display screen of the user terminal 110. The history information is obtained by the external server 120 from the financial institution server 130 and provided to the device 100, so it may be expressed that the device 100 obtains the history information from the financial institution server 130 via the external server 120.

[0033] On the input screen, the user inputs application information including the application amount, and the application information is transmitted to the device 100 (S216). The application information may further include a transfer account as shown in FIG. 5, but if the transfer account has been used in the past, for example, the transfer account used at that time may be used again. The application information may also include the use of funds. The application information may also include the details of the user's business, and the business information may be stored in advance as user information related to the user in association with an identifier for identifying the user within the invoice purchase service.

[0034] In this way, by incorporating the process of submitting historical information about the account history of the user at the financial institution as part of the application flow for the invoice purchase service, it is possible to enrich the information provided at the time of application without excessively increasing the burden on the user.

[0035] In addition, the device 100 may generate credit information such as the creditworthiness of the user using the acquired history information. For example, the device 100 may determine whether or not to purchase the accounts receivable using at least one of the history information and the credit information and the application information. The device 100 may also determine the upper limit of the amount that the user can apply for based on the credit information.

[0036] It should be noted that in the above-mentioned embodiments, unless there is a statement of "only", such as "based only on", "only in response to", "with reference only to", or "only in the case of", it is assumed in this specification that additional information may be taken into consideration. Also, as an example, it should be noted that the statement "do b when a" does not necessarily mean "always do b when a" or "do b immediately after a" unless expressly stated. Also, the statement "each a constituting A" does not necessarily mean that A is composed of multiple components, but includes the case where the component is singular.

[0037] Also, just to be clear, even if there is an aspect of a method, program, terminal, device, server or system (hereinafter referred to as a "method, etc.") that performs an operation different from that described in this specification, each aspect of the present invention is directed to an operation that is the same as any of the operations described in this specification, and the existence of an operation different from that described in this specification does not make the method, etc. outside the scope of each aspect of the present invention. [Explanation of symbols]

[0038] 100 devices 101 Communications Department 102 Processing section 103 Storage section 104 Storage device 110 User terminal 120 External Server 130 Bank Server 300 Input screen for API integration 400 Financial institution account registration screen 500 Application information input screen

Claims

1. A method for purchasing all or part of the accounts receivable arising from invoices issued by users, The steps include receiving invoice information relating to the invoice from the user terminal used by the user, The steps include sending input screen display information to the user terminal to indicate the user's intention to link with an external service that can access historical information for checking the user's activity history, The steps include: after the external server providing the external service has successfully performed SAML authentication in response to the user's positive input on the input screen displayed on the user terminal's display screen based on the input screen display information, the external server receives the API connection credentials generated in association with the user; After the external server completes the registration of the financial institution account specified by the financial institution information entered on the registration screen for specifying the financial institution account to be registered with the external service, the external server obtains the historical information of the financial institution account using the credentials. The steps include receiving application information necessary for purchasing all or part of the accounts receivable from the user terminal, and Includes.

2. The method according to claim 1, The aforementioned invoice information includes the invoice amount, invoice date, payment due date, and customer name.

3. The method according to claim 1, The aforementioned credentials are access tokens.

4. The method according to claim 1, The aforementioned financial institution account is a bank account.

5. The method according to any one of claims 1 to 4, The process further includes the step of generating credit information of the user using the aforementioned history information.

6. A program for causing a computer to execute a method for purchasing all or part of accounts receivable arising from invoices issued by a user, wherein the method is: The steps include receiving invoice information relating to the invoice from the user terminal used by the user, The steps include sending input screen display information to the user terminal to indicate the user's intention to link with an external service that can access historical information for checking the user's activity history, The steps include: after the external server providing the external service has successfully performed SAML authentication in response to the user's positive input on the input screen displayed on the user terminal's display screen based on the input screen display information, the external server receives the API connection credentials generated in association with the user; After the external server completes the registration of the financial institution account specified by the financial institution information entered on the registration screen for specifying the financial institution account to be registered with the external service, the external server obtains the historical information of the financial institution account using the credentials. The steps include receiving application information necessary for purchasing all or part of the accounts receivable from the user terminal, and Includes.

7. A device for purchasing all or part of accounts receivable arising from invoices issued by users, The user terminal used by the user receives the invoice information relating to the invoice, The system transmits to the user terminal input screen display information indicating the user's intention to establish API integration with an external service that can access historical information for checking the user's activity history. After the external server providing the external service successfully performs SAML authentication in response to the user's positive input on the input screen displayed on the user terminal's display screen based on the input screen display information, the external server receives the API integration credentials generated in association with the user. After the external server completes the registration of the financial institution account specified by the financial institution information entered on the registration screen for specifying the financial institution account to be registered with the external service, the external server retrieves the history information of the financial institution account using the credentials, The system is configured to receive application information necessary for purchasing all or part of the accounts receivable from the user terminal.

Images