TW202032476A - Wiring management system, wiring management method and program product wherein the system includes an operation means, a registration means, a retrieval means and a display control means - Google Patents

Abstract

The invention relates to an operation means (102) of a wiring management system (1). The operation means is configured to perform wiring operations based on operations of representatives in a payment method in which multiple users pay for each other, so that the payment activity is performed at least by participants paying for each other. The wiring management system further includes a registration means (101), a retrieval means (107) and a display control means (111). The registration means (101) is to register participants for payment activities. The retrieval means (107) is to retrieve the status of the wiring from the participants to the representative for each payment activity. The display control means (111) is to display a management screen of the wiring status for each payment activity.

Description

Remittance management system, remittance management method, and program product

The invention relates to a remittance management system, a remittance management method, and a program product.

In the past, payment methods (such as shared payment) for sharing expenses among multiple people have been known. For example, Patent Document 1 describes that when a group consisting of a plurality of users using electronic money makes a purchase in a store, once any user enters the amount of money, it will follow the other users in the group A system that calculates the amount of equal apportionment. In this system, if all the other users in the group have approved the apportionment payment, the evenly apportioned amount will be deducted from their own electronic money, which can be used for apportionment of electronic money Payment to purchase goods. [Prior Technical Literature] [Patent Literature]

[Patent Document 1] Japanese Patent Laid-Open No. 2013-254279

[The problem to be solved by the invention]

However, in the technique of Patent Document 1, since all the other users must approve the apportionment payment, the checkout cannot be performed and the product cannot be purchased until the approval of all users is obtained. In this regard, although it is also possible to consider any user in the group as a representative to check out, and then ask other users to remit the part of the advance, it is very troublesome to grasp the respective remittance status.

The object of the present invention is to provide a remittance management system, a remittance management method, and a program product that can easily manage the status of remittances from participants to representatives in a payment method in which a plurality of people bear each other's expenses. [Means to solve the problem]

In order to solve the above-mentioned problems, the remittance management system of the present invention is characterized in that it includes: a creation means for the operation of a representative in a payment method in which a plurality of people pay each other's fees, and is created at least by participants Payment activities where the participants pay for each other’s expenses; and the means of registration, which are used to log the pre-recorded participants to the pre-recorded payment activities; and the means of acquisition, which are used to obtain the representative of the previous pre-recorded participants for each pre-recorded payment activity The remittance status; and the display control means are used to display the management screen of the remittance status for each payment activity.

[1. The overall structure of the remittance management system]

Hereinafter, examples of the embodiments related to the present invention will be described in detail based on the drawings. Fig. 1 is a diagram showing an example of the remittance management system according to the embodiment. As shown in FIG. 1, for example, the remittance management system 1 includes: a bank server 10, a message server 20, a representative terminal 30, and a participant terminal 40, which can be connected to a network N such as the Internet. In addition, in FIG. 1, although each of the bank server 10, the message server 20, the representative terminal 30, and the participant terminal 40 is only shown in one figure, these may be plural.

The bank server 10 is a server computer managed by the bank, and includes, for example, a control unit 11, a memory unit 12, and a communication unit 13. In addition, the case of simply describing it as "bank" in this embodiment refers to the bank that manages the bank server 10, unless otherwise stated. For example, the bank provides online banking services and other applications required for the use of various financial services (hereinafter referred to as banking applications) to the account holder.

The control unit 11 includes at least one microprocessor, for example. The storage unit 12 includes, for example, a main storage unit such as RAM or an auxiliary storage unit such as a hard disk. The control unit 11 executes processing according to the program or data stored in the memory unit 12. The communication part 13 includes a communication interface for wired communication or wireless communication. The communication unit 13 can transmit and receive data to and from external devices via a network such as the Internet or LAN.

The message server 20 is a server computer managed by a company that provides message applications, and includes, for example, a control unit 21, a memory unit 22, and a communication unit 23. The hardware configuration of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as the control unit 11, the storage unit 12, and the communication unit 13, respectively.

Message application is an application used to send messages between users and a communication tool between users. The messaging application is also known as the chat application. Users who have downloaded the messaging app and registered for use can add other users as friends and add them to contacts and send messages. Messages can use various media such as text, emoticons, images, or stickers.

In this embodiment, a service for remittance between users using a message application (hereinafter referred to as application remittance) is provided. For example, once a user of a messaging application connects the messaging application with a bank account or bank application, they can use the balance of the bank account to send money to other users. For another example, when a user receives remittances from other users, the above bank account can be used to receive remittances from other users.

In addition, the remittance service is not limited to the type of messaging application or the type linked to bank accounts, and various types of services are applicable. For example, it can also be a type in which the balance established with the user's account is recharged before remittance. In this type of situation, the user recharges the balance of his account by using a credit card or bank transfer, etc., and then remits money to other users. Others can also be, for example, the type of connecting a user's account number with an electronic value (such as electronic money or points), and using the electronic value to make a remittance. In this type of situation, the user first recharges the electronic value linked to his account, and then remits money to other users. Remittance services can be used for various purposes such as purchase of goods or payment of public expenses in addition to remittances between users.

The representative terminal 30 is a computer operated by a representative in a payment method in which a plurality of people pay each other's expenses, such as a personal computer, a mobile phone (including a smart phone), or a portable information terminal (including Tablet terminal).

In this embodiment, although the payment method described above is described as a split payment, it can also be called by other names such as half payment, per person payment, or even payment. Apportionment payment means both the case where all employees are equally apportioned and paid, and the case where the respective burdens are set instead of equal allocations (when the burdens of oneself and others are different). The payment object of the apportionment payment can be any object, for example, goods, food, tickets, or services will be purchased.

A representative is a person who pays as a representative in the apportionment payment. For example, the representative collects money from the participants after paying the fees on behalf of the representative, or pays the fees after collecting the money from the participants. Participants are those who participate in the apportionment payment, and are those who pay their own contributions to the representatives. The representative may be a member of the participant or not a member of the participant. If the representative is not a member of the participants, the representative is only paying the fee and will not incur the actual burden of the representative.

The representative terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The hardware configuration of the control unit 31, the storage unit 32, and the communication unit 33 may be the same as the control unit 11, the storage unit 12, and the communication unit 13, respectively. The operating portion 34 is an input device, such as a pointing device such as a touch panel or a mouse, or a keyboard. The display unit 35 is, for example, a liquid crystal display or an organic EL display.

The participant terminal 40 is a computer operated by the participant, such as a personal computer, a mobile phone (including a smart phone), or a portable information terminal (including a tablet terminal). The participant terminal 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, and a display unit 45. The hardware configuration of the control unit 41, memory unit 42, communication unit 43, operation unit 44, and display unit 45 can be the same as the control unit 11, memory unit 12, communication unit 13, operation unit 34, and display unit 35, respectively .

In addition, the programs or data described as being stored in the memory 12, 22, 32, 42 can also be stored in a computer-readable information storage medium (such as USB memory or SD card) and supplied To each computer, it can also be supplied to each computer through the network. In addition, the hardware configuration of each computer described in the above note is not limited to the example in the above note. For example, it may be equipped with a reading unit (such as an SD card slot) for reading information storage media, or required for direct communication with external devices The input/output part (such as USB terminal).

[2. Overview of the remittance management system] In the remittance management system 1, the support service for the remittance from the participants of the apportionment payment to the representative (hereinafter referred to as the apportionment payment service) is provided. In this embodiment, after the representative has paid the fee on behalf of the representative, the process in which the participant's contribution is collected is taken as an example. The representative and the participant can also purchase goods and the like together in a store, etc. However, in this embodiment, it is assumed that the participant is located in another place when the representative makes the payment. In addition, in this embodiment, although it is explained that the bank provides the apportionment payment service, the apportionment payment service can be provided by any person, for example, the company that provides messaging applications, telecommunications companies, and electronic money. Trading companies, or SNS providers, can also be providers of apportionment payment services.

In this embodiment, it is assumed that the representative has completed the establishment of a bank account, the registration of the use of the bank application, the registration of the use of the message application, and the linkage of the application remittance. Once the representative operates the representative terminal 30 to activate the apportionment payment service function of the bank application, the top-level screen of the apportionment payment service is displayed on the display unit 35. In addition, the screen described below can also be displayed as a screen on a banking application or on a browser.

FIGS. 2 to 4 are illustrations of an example of the screen displayed on the representative terminal 30. As shown in Figure 2, on the top screen G1 is displayed information on the presence or absence of linkage with the application remittance, as well as the button B10 required for the share payment activity, and to manage the completed share payment activity The required button B11. Apportionment payment activities are units that pay for each apportionment. In addition, if the linkage with the app's remittance has not been completed, the operations required for linkage can be performed from the top screen G1. Once the representative selects the button B10, the event creation screen G2 required for the share payment event is displayed on the display unit 35.

The event creation screen G2 is displayed with: input form F20 for inputting the name of the event, input form F21 for inputting the total amount, input form F22 for inputting information to the participants, and Button B23 required to move to the next screen. The total amount is the amount paid on behalf of the representative. The total amount can also be set with an upper limit and a lower limit. Once the representative enters the event name, total amount, and message in the input forms F20 to F22 and selects the button B23, the participant registration screen G3 required to register the participant is displayed on the display unit 35.

Participant login screen G3 displays: input form F30 required to enter the number of participants for the apportionment payment, button B31 required to increase or decrease the number of participants, and input whether to include the representative in the participants. Required check box B32, check box B33 used to enter whether to attach a respectful name to the participant's name, button B34 used to add a participant from the contact of the message application, used to enter the participant The required input form F35, the button B36 needed to add the number of participants, and the button B37 needed to move to the next screen. Contacts are a list of friends in the messaging application. In addition, if the representative does not use the messaging application, the button B34 is not displayed.

The representative inputs the number of participants by inputting a numerical value indicating the number of participants into the input form F30, or selecting the button B31, etc. The number of participants can also be set with an upper limit and a lower limit. The number of participants input by the representative is the number reflected in the input form F35. Once the representative has checked the check box B32, he can also include himself as a participant, and his name will be displayed in any one of the input form F35. The name of the representative can also be entered directly, or it can be obtained from the name of the account holder of its own bank account or the account name of the messaging application. Once the representative has checked the check box B33, the honorific title will be displayed after entering the form F35. Once the representative selects the button B34, the contact selection screen G4 required to register the participant from the contact of the message application is displayed on the display unit 35. In addition, the contact person can also be read from the message application in the representative terminal 30, or can be obtained from the message server 20.

In the contact selection screen G4, along with a list of the names of the friends who have been registered to the contact, etc., buttons B40 for searching for friends and buttons for selecting friends to be participants are also displayed. B41. The small icon of the friend I42, and the button B43 required to register the selected friend as a participant. Once the representative selects the button B40 and inputs arbitrary search conditions such as a character string, the friends who meet the search conditions are displayed on the contact selection screen G4.

In this embodiment, the presence or absence of registration of the use of remittance by the application and the presence or absence of linkage with a bank account or bank application can be identified by the color of the small icon I42. For example, the small icon I42 of a friend who has completed the use of registration for the application transfer (in the example of FIG. 2 is "Sato Jiro") is displayed in the first color (for example, purple). For another example, the small icons I42 of the friends who have also completed the linkage (in the example of FIG. 2 are "Taro Yamada" and "Hanako Suzuki") are displayed in the first color and the second color (for example, orange). For another example, the small icon I42 of a friend who has not yet completed the application registration for remittance (in the example of FIG. 2 is "Upon Daisuke") is displayed in the third color (for example, gray). In addition, the small icon I42 in FIG. 2 expresses colors in a mode by the shades of dots.

The representative, within the range of not exceeding the total number of people of the apportioned payment, selects the button B41 of the friend who wants to become the participant. After that, once the representative selects the button B43, it will enter FIG. 3, as shown in the participant registration screen G3, the friend selected by the representative will be registered as a participant, and the name of the friend will be displayed in the input form F35. It can also be designed so that the name quoted from the message application can also be changed from the input form F35. If you want to include people who are not registered in the contacts or who have not used the message application as the participants, the representative should directly enter the name of the participant in the input form F35. Once the representative selects the button B36, the number of participants will increase and the input form F35 will increase accordingly. Once the representative selects the button B37, the amount input screen G5 required for inputting the amount of the participant’s contribution is displayed on the display unit 35. .

In the amount input screen G5, the total amount and the average amount are displayed in the display area A50, and are displayed: button B51 for specifying the adjustment unit of the burden amount, input form F52 for inputting the burden amount, Button B53 for adjusting the burden amount, button B54 for going to the next screen, and button B55 for resetting the amount. The average amount is the value obtained by dividing the total amount by the number of participants. In addition, if there is a difference between the total amount and the total amount entered in the input form F52, the difference can also be displayed.

The representative selects button B51, and specifies the unit of the adjustment amount when button B53 is selected. The representative can also directly input the value indicating the burden amount to the input form F52, or select button B53 to adjust the burden amount. The burden amount can also be set with an upper limit and a lower limit. Once the representative selects the button B54, the confirmation screen G6 required to confirm the content of the apportionment payment activity is displayed. In addition, once the representative selects the button B55, the amount of contribution of each participant entered in the entry form F52 is reset.

In the confirmation screen G6, along with the event name of the apportionment payment event, it is also displayed: a small icon I60 indicating that this is the participant who has been linked with the app’s remittance, and used to determine the apportionment payment event Need button B61. In addition, the participant names on the confirmation screen G6 may not be specifically sorted, or may be sorted based on conditions such as the amount of contribution. In addition, as for participants who are not linked to the application for remittance, the small icon I60 will not be displayed. Once the representative selects the button B61, the apportionment payment activity system is created, and the completion screen G7 indicating that the creation of the apportionment payment activity has been completed is displayed.

In the completion screen G7, along with a message indicating that the creation of the apportionment payment activity has been completed and the name of the activity, it also displays: button B70 required to move to the sending screen described later, and to move to the activity described later Button B71 for the list screen or management screen, and button B72 for returning to the top screen G1. Once the representative selects the button B70, it enters FIG. 4, and the sending screen G8 required for sending the related information of the apportionment payment activity is displayed on the display part 35.

In this embodiment, the representative can use a messaging application or an external tool to send messages. External tools are sending media for messages other than messaging applications, such as email, SNS, messaging software, or SMS service. As shown in Figure 4, in the message sending screen G8, along with information such as the activity name of the apportionment payment activity, it also displays: button B80 required to send a message using a message application, and a button B80 to send a message using an external tool The necessary button B81 and the button B82 necessary to return to the top screen G1.

Once the representative selects the button B80, the message will be sent to the participants using the message application. The message can also be sent automatically, or it can be sent only after the message application is activated by the representative who performs a predetermined sending operation. Once the message is sent, the message that has been sent to the participant will be displayed on the screen of the representative's message application, which is the message application screen G9. As shown in the message application screen G9, for example, in addition to the event name and other information, the message also displays the button B90 required to display the details of the apportionment payment event. The same message is also displayed on the participant’s message application screen G9.

On the other hand, when the representative selects the button B81 from the transmission screen G8, the external tool is activated, and the external tool screen G10 required for sending a message using the external tool is displayed on the display unit 35. Here, as an example of an external tool, e-mail is explained. In addition to information such as the event name, the message also contains the link L100 required to display the details of the apportionment payment event. The representative sends the message by inputting the participant’s email address from the external tool screen G10.

Participants, once received the message from the representative, select button B90 or link to L100 in the message to confirm the details of the apportionment payment activity. When the participant operates the participant terminal 40 and selects the button B90 or the link L100, a detailed screen showing the details of the split payment event is displayed on the display unit 45.

FIG. 5 is a diagram showing an example of a detailed screen displayed on the participant terminal 40. As shown in Fig. 5, the detail screen G11 displays the details of the apportionment payment activity such as the activity name. If the participant uses the app to send money, as shown in the detailed screen G11 on the left side of Figure 5, the buttons B110 and B111 required to transfer money using the app, and the button B112 required to close the detailed screen G11 , Department is displayed. Once the participant selects the buttons B110 and B111, they can use the app to send money to the representative. For example, once the participant selects the buttons B110 and B111, the input screen of the remittance amount is displayed, and the amount entered by the participant is remitted to the representative.

On the other hand, if the participant does not use the app to send money, as shown in the detailed screen G11 on the right side of Figure 5, the button B113 required to register the use of the app transfer is used to transfer from their own bank. The button B114 required for account transfer and the button B115 required for opening a bank account are displayed. If the participant has already opened a bank account and has registered for the use of the messaging application, by selecting button B113, the application can be registered for remittance. Participants, as long as they have opened a bank account, can use the online banking service to send money to the representative's receiving account by selecting button B114. Participants who have not opened a bank account can open a bank account by selecting button B115.

In addition, participants can also use other methods to send money to representatives. For example, participants can also transfer money to the representative's beneficiary account from a bank account other than the bank that provides the apportioned payment service, or use the electronic value to make the transfer. In addition, for example, it is not limited to electronic remittances. Participants can also use value letters to send remittances to representatives, or directly hand over the amount to the representatives.

In this embodiment, a screen is prepared for the representative to easily manage the remittance status of each participant. For example, once the representative selects the button B11 on the top screen G1 or the button B71 on the completion screen G7, the event list screen showing the list of the apportionment payment events created by the representative is displayed on the display unit 35.

FIGS. 6-7 are illustrations of screens displayed on the representative terminal 30. As shown in FIG. 6, the activity list screen G12 is displayed with a list L120 showing the apportionment payment activity performed by the representative. In the list L120, together with the activity name and the creation date of the apportionment payment activity, the status of the apportionment payment activity is also displayed. Here, as the overall status of the apportionment payment activity, there are prepared two statuses: "Unsettled", which indicates that there are participants who have not completed the remittance, and "Completed", which indicates that the remittance of all participants has been completed. Once the representative selects the apportionment payment activity in the list L120, the management screen G13 of the apportionment payment activity that should have been selected is displayed on the display unit 35.

As shown in Fig. 6, in the management screen G13, together with information such as the event name of the apportionment payment activity selected by the representative, there is also displayed: a small icon I130 representing the status of the apportionment payment activity, indicating each The small icon I131 for the registration of the participant's application for remittance, the button B132 that indicates the remittance status of each participant, the button B133 that is required to send a message using the message application, and the button B133 that is required to send a message using an external tool Button B134, button B135 needed to confirm the deposit history to the beneficiary account, button B136 needed to copy the apportionment payment activity to create a new apportionment payment activity, and button to delete the apportionment payment activity B137. For participants who have not used the app to send money, the small icon I131 will not be displayed.

The individual status of the participant is displayed in the button B132. Here are 4 states: "Incomplete" indicating that the remittance has not been performed, "Insufficient" indicating that the remittance amount is insufficient, "Excess" indicating that the remittance amount is surplus, and "Completed" indicating that the remittance has been completed . The screen example shown in Fig. 6 shows a case where no one has transferred money to the representative, so all buttons B132 are "incomplete".

In this embodiment, the bank server 10 is linked with the message server 20. As long as it is an application remittance, the remittance from the participant to the representative can be detected. In the example of the screen shown in Figure 6, the three persons "Taro Yamada", "Jiro Sato", and "Hanako Suzuki" have already completed the application registration for remittance, so just use the app to send money to the representative. , The bank server 10 can detect the remittance. If the participant made the remittance using the app, based on the participant’s remittance amount, it is automatically determined whether it is in the status of "insufficient", "surplus", or "completed", and it is reflected in button B132 , And the remittance amount of the application will be displayed nearby.

For example, as shown in the management screen G13 on the left side of Fig. 7, "Taro Yamada" has already used the app to send money for remittance, but when the remittance amount is insufficient, the state shown by button B132 will become "Insufficient". For another example, if "Sato Jiro" has already used the app to send money and remit the burden, the status shown by button B132 will become "Completed". For another example, "Suzuki Hanako" has used the app to send money for remittance, but if the remittance amount is in excess, the status shown by button B132 will become "Excess". As shown in Figure 7, the participant’s burden and the actual amount of remittance can be displayed in comparison with each other. In the case of "insufficient" or "surplus", it is easy to grasp the degree of difference. .

On the other hand, if the participant made the remittance using another remittance method, in this embodiment, the bank server 10 cannot detect the remittance, so the representative selects the button B132 to manually change the status. For example, the representative confirms the history of deposits in his own bank account, or confirms the history of remittances caused by the value of the electronic amount, etc., and determines whether it belongs to the status of "insufficient", "surplus", or "completed", and Press button B132 to change the state. In addition, the button B132, which is automatically changed to "Done" by the application of the money transfer, is locked so that the representative cannot change the state even if the button B132 is pressed. Conversely, after the representative presses the button B132 to manually change the status, if the application remittance is performed, the status will be automatically overwritten.

For example, as shown in the management screen G13 on the right side of Fig. 7, when the status shown by the button B132 of all the participants has become "Completed", the status of the entire payment event shown in the small icon I130 will be Becomes "Complete". In addition, in this case, since the apportionment payment activity has been completed, it becomes unnecessary to send a message to the participants. Therefore, buttons B133 and B134 may be grayed out and become unselectable. Also, after the overall status becomes "Completed", if the representative selects button B132 to change the status to "Insufficient", etc., the overall status will return to "Unsettled".

As described above, the remittance management system 1 of the present embodiment mainly has a configuration in which the remittance status of each participant is displayed on the management screen G13, and the remittance status from the participant to the representative can be easily managed. Hereinafter, the details of the structure of the remittance management system 1 will be explained.

[3. Functions realized in this embodiment] Fig. 8 is a functional block diagram of the functions implemented in this embodiment. Here is an explanation of the implementation of main functions in the bank server 10. As shown in Fig. 8, in the bank server 10, the system is implemented with: a data storage unit 100, a registration unit 101, a preparation unit 102, a transmission unit 103, a request acceptance unit 104, an execution unit 105, an input acceptance unit 106, and acquisition Section 107, restriction section 108, over/under determination section 109, completion determination section 110, display control section 111, and copy section 112. The data storage unit 100 is realized mainly by the storage unit 12, and the other functions are realized mainly by the control unit 11.

[Data Memory Department] The data storage unit 100 stores data necessary for realizing apportionment payment services. Here, as an example of the data memorized by the data storage unit 100, the user database DB1 and the apportionment payment database DB2 will be described.

Fig. 9 is a diagram showing an example of data storage in the user database DB1. As shown in Figure 9, the user database DB1 is a database where information about users of the banking application is stored. For example, the user database DB1 stores: the user ID used to uniquely identify the user, the account information of the user's bank account, the link presence information indicating the link with the application program remittance, and the message application program 'S account.

In this embodiment, the representative has already completed the use registration of the bank application, and therefore retains the user ID. Participants will retain the user ID as long as they complete the registration of the bank application, but if they use the bank account of another bank without registering the bank application, the user ID will not be retained. The account information only needs to be the information needed to identify the bank account, such as the branch name, account number, and account holder.

The link presence or absence information can be: either the first value that is linked to the application remittance or the second value that is not linked to the application remittance. If the user who uses both the bank application and the message application performs a predetermined operation required for the linkage from the bank application or the message application, the linkage presence information is changed from the first value to the second value Value, the account of the messaging application is stored. The account of the messaging application can also be obtained from the representative terminal 30 or the participant terminal 40, or from the message server 20.

Figure 10 is an illustration of an example of data storage in the apportionment payment database DB2. As shown in Figure 10, the apportionment payment database DB2 is a database that stores relevant information about apportionment payment activities. For example, the apportionment payment database DB2 is stored with: activity ID used to uniquely identify apportionment payment activity, representative user ID, activity name, overall status of apportionment payment activity, information entered by the representative, completion date , The total amount, the number of participants, the name of the participant, the burden amount, the account number of the messaging app, the information indicating the presence or absence of linkage with the app’s remittance, the individual status of the participant, and the representative’s bank account (receipt of remittance) Account).

Once the representative has completed the apportionment payment activity, a new record will be created in the apportionment payment database DB2. The activity ID representing the apportionment payment activity made by the representative will be issued and stored in the record that should have been made. The event ID is only required to be issued based on the established ID issuance rules, as long as it can be issued in a way that does not overlap with other apportionment payment activities. Then, the event name, total amount, and message input from the event creation screen G2, the participant name input from the participant registration screen G3, and the contribution amount input from the amount input screen G5, are Save to the record that has been made above.

The initial value of the overall status is "unsettled", and the initial value of the individual status is "unfinished". The creation date is the date on which the apportionment payment event was created. For the participants registered from the contact selection screen G4, the account of the messaging application and the link presence information are stored. The account of the message application program can also be obtained from the representative terminal 30, or can be obtained by querying the message server 20. The link presence information is obtained by referring to the user database DB1.

In addition, the data stored in the data storage unit 100 is not limited to the above example. For example, the data storage unit 100 can also memorize an account database storing bank account related information. The account database is stored with: bank branch name, account number used to identify the account, account nominee, balance information, personal authentication number, and deposit and withdrawal details. The personal authentication number is the personal authentication number of the account, which is the personal authentication number designated when the account is opened. Deposit and withdrawal details are information indicating the history of deposit and withdrawal of the account, such as the date, deposit and withdrawal amount, and deposit and withdrawal information. The apportionment payment activity can also be made by using the representative's deposit and withdrawal details. The total amount of apportionment payment is the deposit amount of the representative.

[Login Department] The registration unit 101 is for registering participants for payment activities. The so-called registration is to associate the relevant information of the participants with the event ID and register it to the apportionment payment database DB2. In this embodiment, when the representative creates a payment event, participants are designated. Therefore, when the payment event is created, the registration section will register the person designated by the representative as a participant. In this embodiment, the registration unit 101 is realized by the bank server 10. Therefore, the registration unit 101 receives the participant identification information used to identify the participant designated by the representative from the representative terminal 30, thereby Accept the designation of participants and log in. Participant identification information is only information that can identify the participant, such as the name of the participant, the user ID of the banking application, the account number of the messaging application, or the email address.

The registration unit 101 registers at least one participant. The number of participants is arbitrary, it may be 2 or 3 or more. In addition, the representative system can also designate only one participant. In this case, a split payment due to a total of two participants including the designated one participant and the representative will be made.

In this embodiment, since the participant can be selected from the contacts in the message application, the friends who have been registered in the contacts are candidates for the split payment. The registration unit 101 registers a candidate designated by the representative as a participant from among the plurality of candidates. On the representative terminal 30, a list of candidates is displayed, and the representative designates participants from among them. The registration unit 101 receives from the representative terminal 30 information for identifying a candidate selected as a participant by the representative from among a plurality of candidates.

In addition, the candidates are not limited to friends who have been registered in the contacts of the messaging application. Candidates only need to be those who have been decided in advance, as long as they have some kind of connection with the representative. For example, the candidate may also be a person registered in the representative's mail address book memorized in the representative terminal 30 or cloud server. For another example, in a banking application, if it is possible to register some other user who has made a remittance or some other user who has sent a message, the candidate can also be the one who has been registered by the bank application. Other users logged in. For another example, in the case of linking with SNS, the candidate may be some other user connected via SNS.

In addition, in this embodiment, although the case where the participant is designated by the representative is explained, it is also possible for a person who is not a representative to apply to become a participant. For example, the representative terminal 30 can also be made to display a QR code containing the event ID of the payment event, and in the case where the participant terminal 40 reads it, the relevant information (such as name, etc.) of the person operating the participant terminal 40 ) Will be sent to the bank server 10 and registered as a participant. In this case, if the operator of the participant terminal 40 uses the message application, information such as the account number of the message application is also sent to the bank server 10 and registered. In addition to using the QR code, the person who received the email or message application message from the representative can be registered as a participant when the link in the message is selected, or it can also be made to indicate a split payment event The website of, has been registered as a participant from the moment the website has performed the operation to participate in and become a participant.

[Creation Department] The preparation unit 102 is based on the operation of the representative in the payment method in which a plurality of people pay each other's expenses, and prepares an amortized payment activity in which at least the participants pay each other's expenses. The so-called amortized payment activity is to register the relevant data of the amortized payment activity on the data memory part 100, for example: create a new record in the amortized payment database DB2, issue the activity ID of the amortized payment activity, or input the representative Information such as the name of the activity is registered in the apportionment payment database DB2. Apportionment payment activity is an example of payment activity, and it can also be called according to the payment method.

In this embodiment, when the representative terminal 30 selects the button B61 on the confirmation screen G6, it sends a request for the preparation of the apportionment payment activity to the bank server 10. The creation request can be made by sending data in a predetermined form that contains the identifier of the component of the apportionment payment activity, including various information such as the activity name entered by the representative (the apportionment payment database DB2 Information stored in the record). The preparation unit 102, once receiving the preparation request, performs a share payment activity, and stores the information received together with the preparation request.

[Communication Department] The sending unit 103 sends the message to the participant when the image required for sending the related message of the apportionment payment activity to the participant has been selected. The current image can be any image. In this embodiment, it is the buttons B80 and B81 on the transmission screen G8, or the buttons B133 and B134 on the management screen G13. The sending unit 103 can also send a message in response to the selection of these buttons, and can also send a message in response to the operation of the representative on the screen displayed later. The screen displayed thereafter is, for example, the message application screen G9 or the external tool screen G10, etc., and the message can be edited on the corresponding screen.

For example, if the bank application has a message sending function, the sending unit 103 can also use the message sending function of the bank application to send messages to participants. For another example, the sending unit 103 may also request the sending of the message to the message server 20, an email server, or a social network server, etc., thereby sending the message to the participants. The content of the message is as described with reference to Figure 4.

[Request Acceptance Department] In this embodiment, the representative and at least one participant are users who have used the service that the registered users can transfer money to each other, and the request acceptance section 104 is the service transfer request made by the participant , Together with the identification information of the apportionment payment activity to be accepted. In the present embodiment, as an example of the service that should be used, although the application remittance is described, as long as it is a service that allows electronic remittance, any other service can be applied. For example, it is also possible to establish a connection between an email address and a bank account, and by specifying the email address, the bank account is specified to perform the service of remittance. For another example, it is also possible to perform a remittance service for linking an SNS account with a bank account, or it may be a type that recharges the balance in advance or a type that uses an electronic amount to remit money as described above.

The identification information of the apportionment payment activity should just be information that can identify the apportionment payment activity. Although the activity ID is exemplified in this embodiment, it can also be other information such as the activity name. In this embodiment, the participant selects the buttons B110 and B111 on the detailed screen G11 to transfer money, but these buttons have event IDs embedded in them. In addition, participants can also send money from the message sent by the representative. In this case, embed the event ID in button B90 or link L100 in the message.

In this embodiment, since the request accepting unit 104 is realized by the bank server 10, the request accepting unit 104 receives the event ID from the participant terminal 40 along with the remittance request. For example, once the participant selects the buttons B110 and B111, the participant terminal 40 sends the event ID and the remittance request to the bank server 10.

The remittance request is executed as long as the data containing the identification element indicating the intent of requesting the execution of the remittance processing is sent and executed. For example, it may also include the embedded button B110, B111 selected by the participant Event ID, the amount of remittance entered by the participant, the participant’s user ID, participant’s name, and the participant’s account of the messaging application, etc. In addition, these information can also be sent as separate information from the remittance request.

[Executive Department] The execution unit 105 executes the remittance process from the participant to the representative based on the remittance request. The execution part 105 executes the remittance processing in response to the receipt of the remittance request. The remittance processing can also be performed by the bank server 10 alone, or by the bank server 10 and the message server 20 in cooperation. In this embodiment, since the remittance request contains the activity ID, the execution unit 105 refers to the apportionment payment database DB2 to specify the record stored in the current activity ID. The execution unit 105 specifies the account or receiving account of the representative stored in the current record as the remittance target. In this embodiment, since the participant specifies the amount of remittance, the execution unit 105 executes the remittance process based on the amount of remittance included in the remittance request. In addition, the participant may not specify the remittance amount. In this case, the execution unit 105 specifies the amount of the participant’s burden stored in the record specified above as the remittance amount to perform the remittance process.

The remittance process itself can be applied to various processes, as long as the process corresponding to the payment method of the participant is executed. For example, if it is an application remittance, the execution unit 105 reduces the balance of the bank account linked to the account of the participant's message application, and increases the balance of the representative's bank account. These reductions and increases may be the same as the remittance amount, or may be the amount after taking into account the set handling fee. In addition to this, for example, when the representative is asked to perform a predetermined receiving operation, the remittance process is executed only when the representative performs the receiving operation. In addition to this, for example, if it is necessary to recharge the balance associated with the account before remittance, the execution unit 105 will reduce the balance of the participant and increase the balance of the representative. The same applies to other payment methods, and the execution unit 105 only needs to execute the processing corresponding to the payment method designated by the participant.

[Input Acceptance Department] The input acceptance unit 106 accepts the input of the remittance status made by the representative. In this embodiment, the bank server 10 implements the input accepting unit 106. Therefore, the input accepting unit 106 receives the remittance status input by the representative from the representative terminal 30, thereby accepting the input of the remittance status. In the representative terminal 30, once the representative inputs the remittance status from the operation unit 34, the remittance status that has already been input is sent to the bank server 10. The input accepting unit 106 accepts the input of the remittance status by receiving the remittance status that should have been sent. In this embodiment, the remittance status is represented by the four states of "incomplete", "completed", "insufficient", or "surplus". Therefore, the input acceptance unit 106 is displayed by pressing the button G13 from the management screen B132 receives the status entered by the representative, and will accept the input of the remittance status.

[Acquisition Department] The obtaining unit 107 obtains the remittance status from the participant to the representative for each apportionment payment activity. The acquisition unit 107 acquires the remittance status of each participant in each apportionment payment event. In this embodiment, since two or more participants can be designated for one split payment event, the acquisition unit 107 will acquire the remittance status of each participant. In addition, the status of the remittance can also mean whether the remittance has been carried out or whether the remittance amount is sufficient. In addition to this, for example, the remittance status can also mean the individual status of the participant.

The bank server 10 can detect the remittance processing of the execution unit 105 described later, and therefore the acquisition unit 107 takes the fact that the remittance processing has been executed as the remittance status when the remittance processing has been executed. For example, the acquisition unit 107 acquires the source of the remittance, the remittance target, and the amount of the remittance, and determines whether the remittance from the participant to the representative has been performed. If the remittance process of the participant is not executed, the individual status is maintained as The initial value is "incomplete" without changing it. For another example, the acquisition unit 107 changes the individual status to "completed" if the participant's remittance amount matches the burden amount. For another example, the acquisition unit 107 changes the individual status to "insufficient" if the participant's remittance amount is less than the burden amount. For another example, if the remittance amount of the participant is more than the amount paid by the participant, the acquisition unit 107 becomes "excess".

On the other hand, for remittance methods that cannot be detected by the bank server 10 (such as bank transfer or hand-delivery, etc.), the obtaining unit 107 obtains the remittance status based on the input made by the representative. The acquisition unit 107 acquires the remittance status input by the representative when the input made by the representative has been accepted, and when the remittance processing has been executed, the remittance processing has been executed The facts are obtained as the status of the remittance. That is, when the representative manually inputs the status, the acquisition unit 107 acquires the input result accepted by the input acceptance unit 106 as the remittance status.

[Restricted Department] The restricting unit 108 restricts the remittance status to change with the input of the representative after the remittance process has been executed. In this embodiment, when the remittance process is executed by the application of the message application, and the status has become "completed", the restriction unit 108 locks the status so that it cannot follow the operation of the representative And change. For example, the restriction unit 108 restricts the state so as not to change even if it receives the fact that the button B132 of the management screen G13 has been selected from the representative terminal 30. In addition to this, for example, the restricting unit 108 may also gray out the button B132 or delete the button B132, etc., so that the representative cannot select it.

[Excess and Insufficiency Judgment Department] The over/under judgment unit 109 judges whether over or under of the amount of money transferred from the participant to the representative based on the remittance status. In the present embodiment, when the remittance process of the remittance using the app has been executed, since the actual remittance amount is obtained as the remittance status, the excess/deficiency determination unit 109 calculates the remittance amount of the participant , Compare with the burden amount of the attendees stored in the apportionment payment database DB2 to determine whether it has occurred or not. The over-and-under judgment unit 109 judges that the remittance amount is more than the burden, then judges it as surplus, and if the remittance amount is less than the burden, it judges it as insufficient.

Furthermore, in this embodiment, since the representative can manually input the status, the over/under determination unit 109 can also determine whether over or under of the remittance amount has occurred based on the input result of the representative. For example, the excess/deficiency determination unit 109 determines that the transfer amount is excessive when the representative selects "Excess" from the button B132 of the management screen G13, and the representative selects from the button B132 of the management screen G13 In the case of "insufficient", it is determined that the remittance amount is insufficient.

[Completion Judgment Department] The completion determination unit 110 determines whether the apportionment payment activity has been completed based on the remittance status of each participant. For example, the completion judging unit 110 does not judge that the apportionment payment activity has been completed when there are participants who have not completed the remittance, but judges that the apportionment payment activity has been completed when all the participants’ remittances have been completed. . In this embodiment, if the participant’s remittance amount is the same as the burden, and the status has changed to "Completed", the remittance is completed. Therefore, the completion judging unit 110 exists when there are participants whose status has not changed to "Completed". In this case, it is not judged that the apportionment payment activity has been completed. It is judged that the apportionment payment activity has been completed only when the status of all participants has changed to "Completed".

[Display Control Unit] The display control unit 111 causes the management screen G13 of the remittance status to be displayed for each apportionment payment activity. The display control unit 111 causes the management screen G13 in each share payment activity to be displayed. The display control unit 111 displays the management screen G13 based on the apportionment payment database DB2. In this embodiment, the display control unit 111 is implemented in the bank server 10. Therefore, the display control unit 111 sends the display data of the management screen G13 to the representative terminal 30 so that the management screen G13 is displayed on On the representative terminal 30.

In this embodiment, since the remittance process is executed by the execution unit 105, the display control unit 111 informs the fact that the remittance process has been executed on the management screen G13. The display control unit 111 is for displaying an image indicating the presence or absence of execution of the remittance process of each participant, or displaying an image indicating whether the remittance is completed by the remittance process. The display control unit 111 informs the fact that the remittance process has been executed through the button B132 of the management screen G13, or informs that the remittance process has been executed by displaying the remittance amount due to the remittance process in the management screen G13 Facts of execution.

In this embodiment, at least one of the multiple participants is a user of the application remittance, and each participant uses any one of the multiple remittance methods including the application remittance to send to the representative Therefore, the display control unit 111 causes the management screen G13 to identifiably display whether or not each participant is the user of the application to send money. The display control unit 111 refers to the presence or absence of linkage information stored in the user database DB1. For participants with linkage, it is determined as a user who is an application remittance, and for participants without linkage, it is not determined as an application remittance. The user.

The display control unit 111 is connected with the participant who has been judged to be the user of the application remittance, so that the small icon I131 is displayed, and the small icon is not displayed for the participant who has not been judged to be the user of the application remittance I131 is displayed. In addition, the display control unit 111 can also use other methods to make the user who is the application remittance recognizable, for example, a string indicating whether the user is the application remittance can be displayed. In addition to this, for example, the display control unit 111 can also be recognized by the display mode of the participant's name or the display mode of the small icon such as the participant's face photo. The so-called display aspect refers to what the image looks like, such as the color, brightness, appearance, or size of the image.

For another example, the display control unit 111 is used to select the contact person selection screen G4 required for the participant from a plurality of candidates, so that each candidate can be displayed to be able to identify whether it is the application remittance use By. For example, the display control unit 111 changes the display mode of the small icon I42 according to whether it is the user of the application remittance. Regarding the display state of the small icon I42, as mentioned above, in this embodiment, it is expressed by color, but it can also be identified by brightness, appearance, or size, etc., to identify whether it is an application The user of the remittance. In addition to this, it can also be, for example, the display control unit 111, which displays a small icon indicating that the user has been judged to be an application remittance, and is not judged to be an application remittance. Participants of the person, the small icon is not displayed. For another example, the display control unit 111 can also display a character string indicating whether it is the user who is the application remittance.

For another example, the display control unit 111 causes the remittance status input by the representative to be displayed when the input of the remittance status made by the representative has been accepted, and when the remittance process has been executed, The fact that the remittance process has been executed will be notified. The display control unit 111 causes the current status to be displayed on the button B132 when the state has been input by the representative, and causes the execution result of the remittance process to be displayed on the button when the remittance process has been executed B132. In this embodiment, the input made by the representative or the execution result of the remittance process is reflected on the individual status of the apportionment payment database DB2, so the display control unit 111 refers to the individual status to determine the display of the button B132.

For another example, the display control unit 111 orders the management screen G13 to display the judgment result of the over/under judgment unit 109. The display control unit 111 orders an image indicating an excess of remittance or insufficient remittance to be displayed on the management screen G13. For example, the display control unit 111 causes the button B132 indicating "excess" to be displayed when it is determined that the remittance is excessive, and displays the button B132 indicating "insufficient" when it is determined that the remittance is insufficient. In addition, the judgment result of the over and insufficient judging unit 109 can also be displayed by other than the button B132. For example, the display control unit 111 can also display the character string indicating over and under, or by displaying the small As shown. In addition to this, for example, the display control unit 111 may determine the display mode of small icons such as participant names or facial photos based on the determination result of the excess and deficiency determination unit 109.

For another example, the display control unit 111 causes the management screen G13 to display images required for sending information related to the apportionment payment activity to the participants. In this embodiment, the corresponding images are buttons B133 and B134 on the management screen G13, but other images may also be used. As mentioned above, the message can also be sent when the current image is selected, and the message application screen G9 or external tool screen G10 can be displayed after the current image is selected, which is used to edit the message by the representative. Or send the required operation and send the message.

For another example, the display control unit 111 displays the determination result of the completion determination unit 110 on the order management screen G13. The display control unit 111 orders an image indicating that the remittance has been completed or the remittance has not yet been completed to be displayed on the management screen G13. For example, the display control unit 111 causes the button B132 indicating "completed" to be displayed when it is judged that the remittance has been completed, and if it is judged that the remittance has not been completed, it orders to show "incomplete", "excess", or " Button B132 of "Insufficient" is displayed. In addition, the judgment result of the over and under judgment unit 109 can also be displayed by other than the button B132. For example, the display control unit 111 can also display a character string indicating whether the remittance is completed or not completed, or by Shown by small icons. In addition to this, for example, the display control unit 111 may determine the display state of small icons such as the names of participants or facial photos based on the determination result of the completion determination unit 110.

[Copy Department] The copying unit 112 copies the apportionment payment activity that has been completed by the creation unit 102, and creates a new apportionment payment activity. The so-called duplication refers to the use of part or all of the information of the apportionment payment activity that has been created. In this embodiment, when the button B136 on the management screen G13 has been selected, the copy unit 112 copies the apportionment payment activity that is currently displayed on the management screen G13, and creates a new apportionment payment activity. For example, after button B136 is selected, the event creation screen G2 is displayed, and each of the input forms F20 to F22 is preset to input the event name, total amount, and message of the apportionment payment event of the copy source. For another example, in each of the input forms F30 and F35 of the participant registration screen G3, the number of people and participant names of the shared payment activity of the copy source are preset. For another example, in the input form F52 of the amount input screen G5, the amount of the apportionment payment activity of the copy source is preset to be input. Representatives can also use this information directly to create a new apportionment payment activity, or change part of this information to create a new apportionment payment activity.

[4. Processing executed in this embodiment] Fig. 11 is a flowchart of the processing executed in this embodiment. The processing shown in FIG. 11 is executed by each of the control units 11, 31, and 41 operating in accordance with the program stored in the storage units 12, 32, and 42. These processes are examples of processes executed by each functional block.

As shown in FIG. 11, first, between the bank server 10 and the representative terminal 30, the creation process of the apportionment payment activity is executed (S1). In S1, the process described with reference to Figures 2 to 4 is used to make a split payment activity and perform participant registration. The representative terminal 30, once the button B61 of the confirmation screen G6 is selected, sends the creation request of the apportionment payment event including the event name and other information entered so far, and the bank server 10 receives the creation request It is required that the activity ID is issued and stored in the apportionment payment database DB2 together with the relevant information.

In addition, when the top screen G1 is displayed, assuming that the representative has logged in to the bank server 10, the bank server 10 can identify the user ID of the representative. In addition, the overall status stored in the apportionment payment database DB2 is to store "unsettled" as the initial value, and the creation date is to store the current date. In addition, the bank server 10 is for participants who use the message application to obtain an account from the contact person in the message server 20 or the representative terminal 30, and store it in the apportionment payment database DB2. "Complete" as the initial value. The receiving account is the account of the representative stored in the user database DB1.

Once the apportionment payment activity is generated, the participant terminal 40 receives the message sent by the representative, and the control unit 41 responds to the participant selecting button B90 or linking L100 in the message, and to the bank server 10, The display request of the detailed screen G11 is sent (S2). Each of the button B90 and the link L100 is embedded with an activity ID, and in S2, the control unit 41 sends a display request containing the corresponding activity ID. In this way, the bank server 10 can specify which apportioned payment activity is the display request.

In the bank server 10, upon receiving the display request, the control unit 11 sends the display data of the detailed screen G11 based on the apportionment payment database DB2 (S3). In S3, the control unit 11 refers to the event ID contained in the display request, and generates the display data of the detailed screen G11 based on the record of the apportionment payment database DB2 where the event ID is stored. The display data can be in any data format. For example, if the detailed screen G11 is displayed on the browser, it is HTML data, and if the detailed screen G11 is displayed on the application provided by the bank, it is the application screen. The text or images embedded in the form.

In the participant terminal 40, upon receiving the display data, the control unit 41 causes the detailed screen G11 to be displayed on the display unit 45 (S4). In S4, the control unit 41 causes the detailed screen G11 shown on the left side of Fig. 5 to be displayed when the participant has used the message application to send money. If the participant does not use the application to send money Next, the detailed screen G11 shown on the right side of FIG. 5 is displayed. Here is an explanation. Participants use the messaging application to send money, and use the appropriate application to send money for processing. If the participant does not use the messaging application to remit money, the participant will remit money from a bank account, or use other methods to do the remittance, etc.

The control unit 41 sends a remittance request to the bank server 10 once the participant selects the buttons B110 and B111 and inputs the amount of remittance (S5). Assume that each of the buttons B110 and B111 is embedded with an event ID and an account or participant name. In S5, the control unit 41 sends a remittance request containing the event ID, account number or participant name, and the entered remittance amount. In this way, the bank server 10 can specify the remittance request of which participant in which apportionment payment activity.

In the bank server 10, once a remittance request is received, the control unit 11 executes the remittance process from the participant to the representative based on the received remittance request and the apportionment payment database DB2 (S6). In S6, the control unit 11 executes the remittance process based on the remittance amount included in the remittance request. Once the remittance process is executed, the balance of the participant’s bank account will be reduced by the amount corresponding to the remittance amount, and the representative will become the state of receiving the remittance. In addition, the representative can also perform the operations required to receive the remittance, and the balance of the representative's receiving account will increase without special operations.

The control unit 11 updates the individual status of the participant based on the amount of remittance and burden input by the participant (S7). In S7, the control unit 11 sets the individual status to "completed" if the remittance amount is consistent with the burden amount. The control unit 11 sets the individual status to "insufficient" if the remittance amount is less than the burden amount. The control unit 11 sets the individual status to "excess" if the remittance amount is more than the burden amount. In addition, if the individual status of all participants becomes "completed", the overall status becomes "completed".

On the other hand, in the representative terminal 30, once the representative selects the button B11 of the top screen G1 or the button B71 of the completion screen G7, the control unit 31 sends a display request of the event list screen G12 to the bank server 10 (S8 ). In the bank server 10, upon receiving the display request, the control unit 11 transmits the display data of the activity list screen G12 based on the apportionment payment database DB2 (S9). In S9, the control unit 11 refers to the apportionment payment database DB2, and generates the display data of the activity list screen G12 based on the stored record of the representative ID of the representative who sent the display request. In addition, the representative ID is sent together when any request is sent from the representative terminal 30.

In the representative terminal 30, upon receiving the display data, the control unit 31 causes the event list screen G12 to be displayed on the display unit 35 based on the received display data (S10). The control unit 31, once the representative selects the apportionment payment activity from the list L120, transmits a display request of the apportionment payment activity management screen G13 that has been selected (S11). The activity ID is embedded in the list L120, and in S11, the control unit 31 sends a display request containing the corresponding activity ID. In this way, the bank server 10 can specify which apportioned payment activity is the display request.

In the bank server 10, upon receiving the display request, the control unit 11 sends the display data of the management screen G13 based on the apportionment payment database DB2 (S12). In S12, the control unit 11 refers to the apportionment payment database DB2, and generates the display data of the management screen G13 based on the stored record of the activity ID included in the display request. For example, the control unit 11 determines the display of the small icon I130 based on the overall status, and determines the display of the button B132 based on the individual status of each participant. For another example, the control unit 11 refers to the user database DB1, and determines whether to display the small icon I131 based on the presence or absence of linkage information of each participant.

In the representative terminal 30, upon receiving the display data, the control unit 31 causes the management screen G13 to be displayed on the display unit 35 based on the received display data (S13). The control unit 31 determines whether the button B132 has been selected based on the detection signal of the operation unit 34 (S14).

When it is determined that the button B132 has been selected (S14; Y), the control unit 31 changes the display of the currently selected button B132 (S15), and sends a state change request (S16). In S16, suppose that the change request contains the identification information of the state input by the representative. In the bank server 10, upon receiving the change request, the control unit 11 changes the status of the participant indicated by the button B132 selected by the representative, and updates the apportionment database DB2 (S17).

On the other hand, in S14, when it is not determined that the button B132 has been selected (S14; N), this processing is ended. At this time, if the representative selects any of the buttons B133 to B137, the processing corresponding to the selected button will be executed. The processing performed when each button is selected is the same as described above.

According to the remittance management system 1, the remittance status of the participants can be obtained for each apportionment payment activity, and the management screen G13 can be displayed for each apportionment payment activity, thereby making it easy to manage the transfer from the participant to the representative Remittance status. For example, by letting delegates know the remittance status of participants, it is possible to prevent forgetting to collect the burden. For another example, in the case of displaying whether the message is sent or not in the management screen G13, the representative can easily grasp whether the message has been contacted to the participant.

In addition, when the representative and at least one participant are users of the app remittance, the remittance process of the apportionment payment activity can be simplified by using the app to remit. In addition, the application remittance system can be detected on the bank server 10, so it is automatically reflected to the remittance status in the management screen G13, and the latest remittance status can be managed.

In addition, in the management screen G13, a small icon I131 indicating whether each participant is the user of the app transfer will be displayed, so the representative can easily determine whether the participant has the possibility of using the app to transfer money. . By grasping the possibility of remittance using the application in advance, the representative can prevent him from checking the transfer history of his bank account several times or making unnecessary urges to the participants.

In addition, in the contact selection screen G4, since it is identifiable whether the contact's friend is the user of the application remittance, the representative can easily determine whether the participant has the possibility of using the application remittance for remittance. Therefore, the representative department can easily decide which message should be sent to the participants.

In addition, when the remittance process is executed by remittance through the application, the individual status of the participant will be automatically set, because the individual status of the restriction will be changed by the representative's input, so it can prevent the representative's wrong input from causing the remittance Participants who have completed become incomplete, etc.

In addition, in the management screen G13, the progress and shortcomings of the remittance of each participant will be displayed, so that the remittance status from the participant to the representative can be managed more easily.

In addition, by sending a message to each participant from the management screen G13, the procedure for urging participants who have not completed the remittance can be reduced, or the procedures for the future response to the conversation for participants whose remittances have been passed or insufficient can be reduced. and many more.

In addition, by copying the apportionment payment activity from the management screen G13, the procedures for the apportionment payment activity for new crops can be saved.

In addition, in the management screen G13, the completion of the entire apportionment payment activity is displayed, which makes it easier to manage the apportionment payment activity. In addition, by allowing representatives to designate the participants of the apportionment payment activity, it is possible to prevent unrelated persons from being registered as participants by mistake.

[5. Modifications] In addition, the present invention is not limited to the embodiment described above. Appropriate changes can be made without departing from the scope of the present invention.

For example, as a remittance method that can be detected by the bank server 10, although the application program remittance is described, the bank server 10 can also detect other remittance methods and reflect the status of the apportionment payment activity. For example, the bank server 10 can also detect the remittance and reflect it to the status when there is a transfer to the bank account it has opened or the transfer from the bank account has an activity ID specified. For another example, the bank server 10 can also detect the remittance using electronic value or the remittance using SNS and reflect it to the status.

For another example, although it is explained that the representative has already opened a bank account and has completed the linkage with the application for remittance, but the representative does not need to open a bank account specifically, or has not completed the remittance with the application The linkage. For another example, the apportionment payment activity can also be set with an effective period. For example, it can also be that the apportionment payment activity that has passed a predetermined number of days (for example, several days to several months) from the creation date will be invalidated. For another example, although four types of "incomplete", "insufficient", "excess", and "completed" are described as individual states, any state can be set, or only 2 or 3 of these can be set. There can also be other statuses such as "Other", "Contacted", and "Reserved". The same is true for all states, and other states can exist.

For another example, although it has been described that the functions shown in FIG. 8 are implemented in the bank server 10, the functions can also be implemented by other computers. For example, the data storage unit 100 can also be implemented by a database server different from the bank server 10. For another example, the registration unit 101 and the input accepting unit 106 are implemented in the representative terminal 30, and the operation unit 34 accepting the operation of the representative is equivalent to accepting the input of the participant's designation and remittance status. For another example, the acquisition unit 107 and the display control unit 111 may be implemented in the representative terminal 30, and the representative terminal 30 obtains the remittance status from the bank server 10 to generate the display data of the management screen G13. For another example, the display control unit 111 of the representative terminal 30 does not obtain the remittance status from the bank server 10, but receives the display data generated by the bank server 10 and causes the management screen G13 to be displayed. In this case, the application program memorized in the representative terminal 30 functions as the display control unit 111, which is created based on the operation of the representative, and at least the participants pay each other's expenses. For each of them, the management screen of the remittance status from the participant to the representative is displayed. For another example, the request accepting unit 104 is implemented in the participant terminal 40, and the operation unit 44 accepting the operation of the participant is equivalent to accepting the remittance request. For another example, the execution unit 105 may be implemented in the message server 20, and the message server 20 is the main body to execute the remittance process. For another example, the restriction unit 108 is implemented in the representative terminal 30, and the representative terminal 30 will gray or delete the button B132. For another example, the sending unit 103 is implemented in the representative terminal 30, and a message is sent from the representative terminal 30 to the participant terminal 40. In addition to this, for example, each function system can also be implemented in other computers, or shared by multiple computers.

1: Remittance management system N: Network 10: Bank server 11: Control Department 12: Memory Department 13: Ministry of Communications 20: Message server 21: Control Department 22: Memory Department 23: Ministry of Communications 30: Representative terminal 31: Control Department 32: Memory Department 33: Ministry of Communications 34: Operation Department 35: Display 40: Participant Terminal 41: Control Department 42: Memory Department 43: Ministry of Communications 44: Operation Department 45: Display G1: Top screen G2: Event creation screen G3: Participant login screen G4: Contact selection screen G5: Amount input screen G6: Confirmation screen G7: Complete screen G8: Sending screen G9: Message application screen G10: External tool screen G11: Detailed screen G12: Event list screen G13: Management screen 100: Data Memory Department 101: Login Department 102: Production Department 103: Communication Department 104: Request Acceptance Department 105: Executive Department 106: Input Acceptance Department 107: Acquisition Department 108: Restricted Department 109: Excess and Insufficiency Judgment Department 110: Completion Judgment Department 111: Display control unit 112: Copy Department

[Fig. 1] An illustration of an example of the remittance management system according to the embodiment. [Figure 2] An illustration of an example of a screen displayed on a representative's terminal. [Figure 3] An illustration of an example of a screen displayed on a representative's terminal. [Figure 4] An illustration of an example of a screen displayed on a representative's terminal. [Figure 5] An illustration of an example of a detailed screen displayed on a participant's terminal. [Figure 6] An illustration of the screen displayed on the representative's terminal. [Figure 7] An illustration of the screen displayed on the representative terminal. [Figure 8] A functional block diagram of the functions implemented in this embodiment. [Figure 9] An illustration of a data storage example in the user database. [Figure 10] An illustration of a data storage example in the apportionment payment database. [Fig. 11] A flowchart of the processing executed in this embodiment.

10: Bank server

100: Data Memory Department

101: Login Department

102: Production Department

103: Communication Department

104: Request Acceptance Department

105: Executive Department

106: Input Acceptance Department

107: Acquisition Department

108: Restricted Department

109: Excess and Insufficiency Judgment Department

110: Completion Judgment Department

111: Display control unit

112: Copy Department

DB1: user database

DB2: Apportionment Payment Database

Claims (12)

A remittance management system, which is characterized in that it contains: The creation means is used to create a payment activity in which at least participants pay each other's expenses based on the operation of the representative in the payment method in which plural people pay each other's expenses; and The login method is used to log in the prepaid participant to the prepaid payment activity; and The acquisition method is used to obtain the remittance status of the former participant to the former representative for each prepaid payment activity; and The display control means is used to display the management screen of the remittance status for each prepaid payment activity. Such as the remittance management system described in claim 1, in which: The preface representative and at least one preface participant are users who can perform remittance services between registered users; The Qianji Remittance Management System also contains: The means of request acceptance is used to accept the remittance request made by the pre-recorded participant using the pre-recorded service together with the identification information of the pre-recorded payment activity; and The execution method is based on the remittance requirements of the previous record, and the remittance processing from the previous record participant to the former record representative is executed; The pre-recorded acquisition method is to obtain the fact that the pre-recorded remittance process has been executed as the pre-recorded remittance status; The pre-record display control means is in the pre-record management screen to notify the fact that the pre-record remittance process has been executed. Such as the remittance management system described in claim 2, in which: In the prepaid payment activity, multiple prepaid participants are registered; Each participant uses any one of a plurality of remittance methods including the forwarding service to send money to the forwarding representative; The pre-record display control means is to make the pre-record management screen identifiable display whether each participant is the user of the pre-record service. Such as the remittance management system described in claim 2 or 3, where: The pre-registration method is to register the candidates who have been designated by the pre-registration representative from among the multiple candidates as pre-registration participants; The pre-record display control means is used to select the pre-record participant from the multiple candidates in the pre-record in the selection screen required to identifiably display whether each candidate is a user of the pre-record service. Such as the remittance management system described in claim 2 or 3, where: The pre-recorded remittance management system also contains: input acceptance means, which is used to accept the pre-recorded remittance status input made by the pre-recorded representative; The means of obtaining the previous note is that when the input of the previous note has been accepted, the previous note remittance status has been entered by the representative of the previous note to obtain, and when the previous note remittance process has been executed, the previous note remittance process has been executed The facts are obtained as a pre-recorded remittance; The pre-recorded display control means, when the pre-recorded input has been accepted, the pre-recorded remittance status has been entered by the pre-recorded representative, and the pre-recorded remittance process has been executed when the pre-recorded remittance process has been executed. The fact of execution shall be notified; The pre-recorded remittance management system also contains: restriction means, which is used to restrict the pre-recorded remittance status from changing due to the pre-recorded input after the pre-recorded remittance processing has been executed. Such as the remittance management system described in any one of Claims 1 to 3, where: The pre-remittance remittance management system also contains: a means of determining over and insufficiency, which is used to determine whether the remittance amount from the former participant to the former representative has occurred or insufficient based on the status of the remittance; The pre-record display control means is the pre-record management screen to display the judgment results of the pre-recorded and insufficient judging means. Such as the remittance management system described in any one of Claims 1 to 3, where: The pre-recorded display control method is to display the pre-recorded management screen and send the relevant information of the pre-recorded payment activity to the image required by the pre-recorded participants; The pre-recorded remittance management system also contains: a means of sending messages, which is used to send pre-recorded messages to pre-recorded participants when the pre-recorded image has been selected. Such as the remittance management system described in any one of Claims 1 to 3, where: The pre-recorded remittance management system also contains: a copying method, which is used to copy payment activities that have been previously recorded as a means to create new payment activities. Such as the remittance management system described in any one of Claims 1 to 3, where: In the prepaid payment activity, multiple prepaid participants are registered; The pre-recorded method is to obtain the remittance status of each participant; The pre-recorded remittance management system also contains: a means of completion judgment, which is used to determine whether the pre-recorded payment activity has been completed based on the remittance status of each participant; The prescripting display control means is the order prescripting management screen to display the judgment result of the prescripting completion judging means. Such as the remittance management system described in any one of Claims 1 to 3, where: The pre-registration method is to register the person designated by the pre-post representative as the pre-post participant when the pre-post payment activity is created. A remittance management method, which is characterized in that it contains: The creation step is to create a payment activity in which at least the participants pay each other's expenses based on the operation of the representative in the payment method in which plural people pay each other's expenses; and The login step is used to log in the prepaid participant to the prepaid payment activity; and The obtaining step is used to obtain the remittance status of the former participant to the former representative for each prepaid payment activity; and The display control step is used to display the management screen of the remittance status for each prepaid payment activity. A program product that is used to make the computer of the representative of the payment method in which a plurality of people bear each other's expenses function and become: The display control means is used for each of the payment activities that are created based on the operation of the representative, at least the participants pay each other's expenses, and the management screen of the remittance status of the representative from the participant to the representative being shown.

Images