JP7813625B2 - Remittance system, remittance method and program that allows remittance using an account identifier set by the recipient instead of an account number - Google Patents

Description

The present invention relates to a remittance system, remittance method, and program that allows remittance without specifying an account number.

Traditionally, when transferring money between accounts, the recipient could only see the sender's name, not the purpose of the transfer. Furthermore, when requesting a transfer to an account, it was necessary to provide personal information such as the branch number and account number. Therefore, systems are now known that allow money transfers without knowing the recipient's account number.

For example, Patent Document 1 discloses a financial transaction service system that enables bank transfers using a mobile phone number or an email address corresponding to a mobile phone number instead of an account number. Furthermore, Patent Document 2 discloses a proxy account management device that associates a user-specified ID with an account, allowing the same account to be used even when the transfer destination is different, and opens a proxy account that can be used directly for transfer processing to an account already opened at a financial institution.

Japanese Patent Application Laid-Open No. 2007-317173 JP 2009-110371 A

However, the inventions described in the above patent documents do not allow users to use account identifiers of their own choosing. In other words, in the invention described in Patent Document 1, account identifiers are limited to mobile phone numbers or email addresses, and in the invention described in Patent Document 2, the system automatically generates identifiers for proxy accounts, so users cannot create their own account identifiers.

Therefore, in consideration of the above-mentioned issues, the present invention aims to provide a remittance system that allows a user to arbitrarily set an account identifier that replaces the branch number and account number when requesting a remittance, and enables the remitter to search for that account identifier and uniquely identify the remittance recipient before sending the remittance.

To solve the above problems, the present invention provides the following solutions.

(1) A remittance system that allows a remitter to remit money without specifying the recipient's account number,
The system is characterized by comprising an account identifier setting means that prompts the recipient to input any combination of character strings that will become an account identifier instead of the account number, and prompts the recipient to set the input character string as a public identifier that will be made public to an unlimited number of recipients and/or as a private identifier that will be made public only to a limited number of recipients, and a remittance execution means that searches for the public identifier or the private identifier to uniquely identify the recipient's account number and execute the remittance.

(2) In the configuration of (1) above, the arbitrary character string is determined to be "meaningful" based on predetermined criteria.

(3) In the configuration of (1) or (2) above, when the arbitrary character string is used as the nickname for the recipient's account, the system checks whether the nickname is unique based on shared nickname information for a user group including the recipient or a user group including the remitter, or displays a new selectable nickname from the shared information if the nickname is not unique.

(4) In the configuration of (1) or (2) above, when the arbitrary character string is used as the nickname for the recipient's account, the system checks whether the nickname is unique based on shared nickname information for a user group that includes only the recipient, a user group that includes only the remitter, or a user group that includes both the recipient and the remitter, or if the nickname is not unique, displays a new selectable nickname from the shared information.

(5) In the configuration of (1) or (2) above, when the remitter uses the public identifier to send money, if the public identifier is not unique, the remitter searches using a subkeyword previously set by the recipient to uniquely identify the remitter.

(6) In the configuration of (1) or (2) above, if the private identifier includes the name or date of a meeting among the limited number of recipients, the name or date of the meeting can be confirmed or transcribed from the recipient's electronic calendar.

(7) In the configuration of (1) or (2) above, the disclosure destination of the private identifier can be a character string designated as a representative of the multiple public identifiers.

(8) In the configuration of (1) or (2) above, when the remitter searches for the public identifier, people with whom the remitter has contact on SNS or people with whom the remitter has made transfers in the past are preferentially displayed.

(9) In the configuration of (1) or (2) above, the remitter and recipient can send messages, images, and stamps within a chat room linked to the account identifier.

(10) A remittance method that enables a remitter to remit money without specifying the recipient's account number, characterized in that the method includes the steps of having the recipient input an arbitrary combination of character strings that will serve as an account identifier in place of the account number, having the recipient set the input character string as a public identifier that is made public to an unlimited number of recipients and/or as a private identifier that is made public only to a limited number of recipients, and uniquely identifying the recipient's account number from the public identifier or the private identifier and executing the remittance, carried out by a computer.

(11) A program that causes the computer to execute each of the steps described in (10) above.

This invention provides a remittance system that allows users to arbitrarily set an account identifier that replaces the branch number and account number when requesting a remittance, and allows the remitter to search for that account identifier and uniquely identify the remittance recipient before sending the remittance.

FIG. 1 is a diagram showing the concept of an account identifier (ID) used instead of an account number in the present invention. 1 is a diagram showing a functional configuration of a remittance system according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of a setting screen for an account identifier (public identifier). FIG. 10 is a diagram showing an example of a setting screen for an account identifier (private identifier). FIG. 10 is a diagram illustrating the concept of searching for a public identifier. FIG. 10 is a diagram showing a processing flow of a recipient terminal in an embodiment of the present invention. FIG. 10 is a diagram showing a processing flow of a remitter terminal according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen displayed when a transfer request is made from the perspective of the remitter when a private identifier is specified. FIG. 10 is a diagram showing an example of a screen showing the history in a room as viewed from the recipient's side. FIG. 10 is a diagram showing an example of a screen on which the recipient, who is the organizer of the party, can check the transfer amount and the people to whom the transfer has been made and those to whom it has not yet been made from the room.

(overview)
FIG. 1 is a diagram showing the concept of an account identifier (ID) used in place of an account number in this invention. As shown in the figure, when an individual user ("Japan A") requests a transfer, the recipient's account information (bank name "ABC Bank," branch number "211," account type "regular," account number "1234567," etc.) must be provided to the sender. However, in this invention, an account identifier (ID) is used in place of account information. The recipient can set the account identifier at their discretion, and can specify whether it is disposable or has an unlimited expiration date. The IDs that can be set include public identifiers (also called "public IDs") and private identifiers (also called "private IDs"), and the recipient can use them according to their purpose, and can set one or more of each.

A public identifier is an ID set by the recipient without limiting the recipients (remittance request recipients), while a private identifier is an ID set by the recipient with limited recipients (for example, acquaintances or friends). Since public identifiers are made public to an unspecified number of people, there is a possibility that they may not be uniquely identified by the parties involved. To avoid this, sub-keywords are used to narrow down the public ID uniquely. This will be explained later.

In the example in Figure 1, the public IDs are "Neko Neko" and "Tanukichi", and the private IDs are "2019 Japan Research Institute Alumni Reunion" and "December 25th Basketball Club Year-End Party". When used to collect money for a gathering, setting the date, content of the gathering, etc. as the private identifier will make it easier to contact the relevant parties.

Here, account identifiers (which refers to both public and private identifiers) are "strings of characters with meaning" (for example, nicknames, terms only used by related parties or friends, etc.); simple numbers or meaningless strings of characters cannot be set as account identifiers. Therefore, IDs that are automatically assigned randomly by the system are excluded. Furthermore, only one representative account identifier (called the "representative ID") will be designated as a public identifier. The representative ID is an ID that permanently identifies a user's account, while other non-representative IDs are mainly used for temporary purposes, such as when they are made public for a limited period of time. In the example shown, "nekoneko" is the representative ID. Note that a representative ID will not be set as a private identifier. The method for setting account identifiers will be described later.

In this way, with this invention, the remittance destination (transfer destination) can be identified using an account identifier instead of account information, allowing the recipient to request and receive remittances without revealing their account information to the other party. Furthermore, when a remitter requests a remittance using an account identifier, they can also search for that account identifier and confirm the recipient's name from the account name.

The following describes in detail the modes for carrying out the present invention (hereinafter referred to as "embodiments") with reference to the accompanying drawings. In the following figures, the same elements are designated by the same numbers or symbols throughout the description of the embodiments. Furthermore, in diagrams of functional configurations, arrows between functional blocks indicate the direction of data flow or the direction of processing flow.

(Functional configuration)
Figure 2 is a diagram showing the functional configuration of a remittance system (hereinafter referred to as the present system) according to an embodiment of the present invention. In this system, a depositor terminal 10, which is the terminal of the depositor who is the user, and a remitter terminal 20, which is the terminal of the remitter, are connected to a remittance server 100 operated by a financial institution via the Internet. The remittance server 100 has the function of allowing the depositor to set an account identifier and the function of converting the set account identifier into an actual account number. The remittance server 100 is connected within the financial institution to an accounting system 200 that handles the actual deposit and withdrawal processing.

The remittance server 100 has the following functional blocks: account identifier setting means 101, public identifier storage means 102, private identifier storage means 103, remittance destination identification means 104, account identifier search means 105, and SNS information acquisition means 106. The accounting system 200 has the core functions of a financial institution and is equipped with a variety of functions, but here only the remittance execution means 201 and remittance history storage means 202, which are directly related to the remittance server 100, are shown. Note that the accounting system 200 also includes those of other financial institutions. Each functional block will be explained in order below.

The account identifier setting means 101 has the function of communicating with the depositor terminal 10 and allowing the depositor to set an account identifier. Specifically, an ID setting screen such as that shown in Figures 3 and 4 is displayed on the depositor terminal 10, and the depositor is prompted to set the ID name (an arbitrary string of characters that will serve as the account identifier), the disclosure range (distinguishing between public and private identifiers), etc. Here, the arbitrary string that will serve as the account identifier is a string that has been determined to be "meaningful" according to predetermined criteria. This is because "meaningless" strings are difficult for people to remember and can lead to input errors.

Here, the predetermined criteria may be that the string is not a string of numbers only, is not a string of alphanumeric characters, and contains at least one word found in a dictionary. By doing so, it is possible to eliminate identifiers that are automatically assigned by the system. For example, "neko" (cat) and "nuki" (raccoon dog) are strings that "have meaning" because they are found in the dictionary, but these alone are too simple and not suitable as identifiers, so it would be more desirable to use "neko-neko" (cat) and "nuki-chi" (raccoon dog), as shown in the ID in Figure 1. Of course, ultimately, it is fine as long as the string is judged by the person setting the account identifier to be "meaningful" and capable of identification.

Figure 3 shows the public identifier setting screen. Here, "Neko Neko" is selected as the ID name and "Public" is selected as the visibility range, indicating that this is a public identifier. The ID name may be a generic character string, or the system may automatically generate a "meaningful" character string (for example, a unique ID name such as "Magical Happy Girl 2021").

Furthermore, in this example, the settings screen 301 has "AAA High School," "BB University," and "C Circle" set as "subkeywords." Subkeywords are search keywords used to narrow down and uniquely identify an account when the public identifier's ID name alone cannot uniquely identify the account. Of course, if the account can be uniquely identified by the ID name alone, there is no need to set them, but if the account identifier cannot be uniquely identified by "Neko Neko" alone, as shown in the figure, unique identification can be achieved by using subkeywords in combination.

In this case, the ID name and subkeyword can be combined and used as a public identifier such as "Neko Neko AAA High School," or the two words "Neko Neko" and "AAA High School" can be separated and used as public identifiers. By doing this, for example, the ID name "Neko Neko" can be used as a term to represent a year-end party, and the subkeyword can be used as a term to represent the target gathering (university, high school, club, etc.). In other words, one ID name can have multiple subkeywords. Note that combinations of ID names and subkeywords that are already in use are checked within the system, so it goes without saying that they cannot be used simultaneously.

The set expiration date is the expiration date of the ID name, and in the case of a public identifier, it is usually desirable to set it to unlimited. Of course, an expiration date may be set depending on the purpose. Although not shown in Figure 3, it is also possible to distinguish whether the ID name is a representative ID or not, and to specify this. However, the set expiration date for the representative ID may be automatically set to unlimited.

Figure 4 shows the private identifier setting screen 302. Here, "Basketball Club Year-End Party, December 25th" is selected as the ID name, and "Private" is selected as the disclosure range, indicating that it is a private identifier. Private identifiers differ from public identifiers in that a setting deadline must be specified and the ID name of the disclosure destination must be specified. Subkeywords do not necessarily have to be set. In this example, "2021/12/31" is specified as the setting deadline, and "Kametao" and "Usagi" are specified as the "disclosure destinations" to which the non-account identifier will be disclosed only to a limited number of people.

The "public destination" of a private identifier is generally specified by the Public ID of the representative of the other party, but it may also be specified by a Public ID of a non-representative. However, the public destination must be uniquely set by the identifier registered as the public destination (Kametaro, Usagi). If the public destination cannot be uniquely identified, it must be uniquely identified by combining sub-keywords or using the method described below.

Account identifiers (public identifiers and private identifiers) only need to be uniquely identifiable between the remittance requester and the remitter. For example, if the remittance requester's nickname is used as the account identifier (in other words, when creating an account nickname), the shared nickname information shared by the remittance requester with a user group that includes the remitter (e.g., 50 people including the remitter) and/or the shared nickname information shared by the remitter with other user groups that include the remittance requester (e.g., another 30 people including the remitter) can be used. It is also possible to check whether the nickname entered by the remittance requester can be uniquely identified based on this shared information. It is also desirable to save a "search flag" (described below) to indicate the scope of the search for shared information (user groups that include the recipient or remitter, or user groups that include only the recipient or remitter, or user groups that include both the recipient and remitter).

Furthermore, if there is no shared nickname information or if the shared nickname information is insufficient, the system may accumulate shared information as the user continues to use the system. Furthermore, in order to check whether a nickname can be uniquely identified, the search scope performed by the account identifier search means 105 is limited to nicknames known to the remittance requester and the remitter, allowing for efficient system operation. Note that if a private identifier cannot be uniquely identified using this method, a subkeyword must be specified, just as with a public identifier. Note that shared nickname information may be stored in the account identifier search means 105, or may be obtained from the SNS information acquisition means 106.

Also, "Kametaro" and "Usagi" can be specified as Private IDs instead of Public IDs. This is because Private IDs, used by close friends, are often used permanently and are more suitable as key information for transmitting account information.

Returning to Figure 2, the public identifier storage means 102 is a storage means (database) that stores the public identifiers of all users who subscribe to this service. Each public identifier is linked to unique account information (bank code, branch number, account type, account number, account holder), and although an unlimited setting period is set as the default, a setting period may also be set depending on the purpose. A single representative ID may also be set as a public identifier. As mentioned above, sub-keywords may also be set for public identifiers as needed.

The private identifier storage means 103 is a storage means (database) that stores users' private identifiers. Private identifiers can have unlimited or limited expiration dates. Private identifiers do not have a representative ID or subkeyword.

The remittance destination identification means 104 has the function of accepting a remittance request (transfer request) using an account identifier from the remitter terminal 20 and converting the account identifier into unique account information based on the public identifier storage means 102 or the private identifier storage means 103. The remittance destination identification means 104 also has the function of checking, when the recipient sets an account identifier, whether the account identifier is already in use and whether the account information can be uniquely identified from the account identifier. If shared nickname information is used to determine uniqueness, a "search flag" indicating the search scope of the shared information may be used when registering the nickname and when remitting money. For example, a search flag of 1 indicates the search scope of user groups that include the recipient or remitter; a search flag of 2 indicates the search scope of user groups that include only the recipient; a search flag of 3 indicates the search scope of user groups that include only the remitter; a search flag of 4 indicates the search scope of user groups that include both the remitter and the recipient; and a search flag of 0 indicates that no shared information exists in the search scope. By doing this, the uniqueness of the nickname used as an account identifier can be checked not only at the time of registration, but also at the time of actual transfer.

The account identifier search means 105 is a means for the remitter to search for the public identifier (Public ID) using a subkeyword when the account identifier is a public identifier. The depositor may inform the remitter in advance whether the account identifier is a public or private identifier, but this can also be determined based on the presence or absence of a subkeyword, even if the information is not provided in advance.

When a remitter searches for a public ID, the SNS information acquisition means 106 prioritizes displaying people with whom the remitter has a relationship, such as those with whom the remitter shares a social networking account or a history of previous transfers. An example of this is shown in Figure 5. This example shows how "Japan Girl A" requests "Research Institute Girl B" to transfer post-party membership fees and other expenses. Here, "Japan Girl A" simply enters "December 25th, basketball club year-end party" as the recipient's ID. "Research Institute Girl B" then logs into her own online banking, enters the recipient's ID on the ID search screen, and presses the search button, displaying "Japan Girl A" as the recipient. After confirming the displayed recipient, "Research Institute Girl B" can enter the remittance amount of "5,000 yen" and press the confirm button to execute the transfer. Note that people with whom the remitter has a relationship, such as those listed as friends on social networking accounts or those with whom the remitter has a history of previous transfers, may be prioritized on the search screen to improve search efficiency.

The functional configuration of the system described above in Figures 2 to 5 is merely an example. A single functional block (database and functional processing unit) may be divided, or multiple functional blocks may be combined into a single functional block. Each functional processing unit is implemented by a computer program executed by a central processing unit (CPU) built into the device, which reads a computer program stored in a storage device such as read-only memory (ROM), flash memory, solid-state drive (SSD), or hard disk. In other words, each functional processing unit is implemented by the computer program reading and writing necessary data, such as tables, from a database (DB) stored in the storage device or a storage area in memory, and, in some cases, controlling related hardware (e.g., input/output devices, display devices, and communication interface devices). Furthermore, the database (DB) in the embodiments of this invention may be a commercial database, but it also refers to a simple collection of tables and files, and the internal structure of the database itself is not important.

(Processing flow)
The processing at the depositor's terminal and the processing at the remitter's terminal will be explained in detail below using Figures 6 and 7. In the following processing flow diagrams (flowcharts), the order of the steps may be changed as long as the relationship between input and output at each step is not affected.

6 is a diagram showing the processing flow of the recipient terminal in the embodiment of the present invention. First, in step S10, the recipient terminal displays an account identifier setting screen (ID setting screen in FIGS. 3 and 4).
Next, in steps S10a and S10b, it is determined whether the input ID name is a "meaningful" character string based on predetermined criteria. As mentioned above, the predetermined criteria are that the ID name is not a character string consisting of only numbers, is not a string of alphanumeric characters, and contains at least one word found in a dictionary, but the final determination may be made by the person inputting the ID name.

Next, in step S11, the disclosure range is checked, and if Public is specified as the disclosure range, the process proceeds to step S12. Here, a check is made to see if the entered ID name can be uniquely identified as an account identifier. At this time, a terminology dictionary (not shown) is referenced. Also, to check whether the ID name is already in use, the server-side public identifier storage means 102 is referenced. Furthermore, if the recipient's nickname is used as the account identifier, as mentioned above, the shared nickname information between the recipient and remitter may be used to check whether it is unique.

If the ID name cannot be uniquely identified, the user is prompted to specify a subkeyword in step S13. Note that even if the ID name can be uniquely identified, the user may be prompted to enter a subkeyword just to be safe.

Next, in step S14, the ID name and subkeyword are set as public identifiers.

Then, in step S15, a check is made to see if the set ID name is designated as the representative ID. If it is, in step S16, the representative flag for that ID is turned on, making it distinguishable from other IDs. Finally, after all setting items have been entered, the user presses the setting button to save the settings and end the process.

If "Public" is not specified in step S11 (step S11: N), the process proceeds to step S17, where the input ID name is recognized as a private identifier (Private designation). Then, in step S18, it is determined whether the ID name can be uniquely identified from the perspective of the recipient of the private identifier. If the recipient's nickname is used as the account identifier, as described above, it may be possible to check whether the ID name can be uniquely identified by using the nickname shared information of a user group including the recipient and remitter.
If it cannot be uniquely identified, in step S18a, the input of a subkeyword is requested, and the input ID name is rechecked.

Next, in step S19, the set deadline is registered. Next, in steps S19a and S19b, if the ID name includes a date or a gathering name (such as "XX party," "XX celebration," or "XX gathering"), the electronic calendar of the person making the input (the person requesting the remittance) may be checked to confirm the gathering name and date. Conversely, the ID name may be automatically entered (transcribed) by clicking on an item for a specific date on the electronic calendar. Finally, the ID of the user who will disclose the private identifier is registered as the disclosure destination. Then, when the user presses the setting button, the settings are saved and the process ends.

Figure 7 shows the processing flow of the remitter terminal in an embodiment of the present invention. First, in step S20, the remitter terminal checks whether the ID name specified by the recipient is a public, i.e., public, identifier. The recipient may specify whether the specified ID name is a public or private identifier, but if it is unclear, the remitter terminal refers to the public identifier storage means, and if it is registered there, it proceeds with the following processing assuming it is a public identifier.

If the ID name specified in step S20 is not Public, the process moves to step S28. However, if it is a public identifier, step S21 checks whether there is a subkeyword. If there is a subkeyword, the ID name is searched for using the subkeyword (step S22) and the search results are displayed (step S23). At this time, the sender's past transfer history is searched, and if there is an ID with the same name, that is displayed preferentially. In addition, if the sender's SNS information (IDs of people registered on the friend list or mutual followers) can be obtained, that information is displayed preferentially.

Then, in step S24, the system waits for the remitter to select one of the search results displayed. Once a selection is made, in step S25, the selected ID name and subkeyword are converted into the recipient's account information (account number, etc.) as an account identifier, and the remittance is executed (a request is made to the accounting system to execute the remittance).

Finally, in step S26, it is checked whether the remittance was completed successfully. If a remittance error occurs, in step S24, a message is sent to the remitter's terminal asking the recipient to confirm that the ID name and subkeyword are correct.

Also, if it is determined in step S21 that there are no subkeywords, in step S28, the specified ID name alone is converted into the recipient's account identification information, and the remittance is executed (a request is made to the accounting system to execute the remittance).

Also, if the specified ID name is Private rather than Public in step S20, the specified ID name is converted into the recipient's account information in step S28, and the remittance is executed (a request is made to the accounting system to execute the remittance). In either case, step S26 is also used to check whether there were any remittance errors.

(Other screen examples)
Other functions of this system will be described below with reference to FIGS.

Figure 8 shows an example of a screen displayed from the sender's perspective when a transfer request is made with a private identifier. Screen 304 in this example shows a list of transfer destinations for which transfer requests have been received using a private ID. Each transfer destination uses a different private ID, but the account holder and transfer status of the transfer destination are displayed. Screen 305 also shows a conversation with the transfer destination in a "room." Here, a "room" (also called a "talk room") is a user interface similar to a chat room on an existing SNS, allowing the sender and recipient to chat (converse). A room is created for each private ID, and chats with multiple recipients are possible. Of course, images, stamps, and other elements can be used in addition to text. Rooms can be created within this system, or existing SNS chat rooms can be used.

Figure 9 shows an example screen showing the history within a room as viewed from the recipient's perspective. The recipient can manage published transfer requests in a list. After logging in to screen 306 using their account branch number and account number, the recipient can check the history within the room for each account identifier (ID). Here, the ID can be a public ID or a private ID, as shown in screen 307. When the recipient selects a specific ID field (here, "Basketball Club Year-End Party, December 25th") on screen 307, the details of that ID (in this case, a transfer from the person who requested the transfer) are displayed as shown in screen 308. This allows the recipient to check the account holder, transfer amount, and details of the transfer from this room. For example, as shown in screen 309 in Figure 10, if the recipient is the organizer of a party, the recipient can check from the room the people to whom transfers have been made and the amount of each transfer, the total amount of the transfer, and so on.

(Effects of the embodiment)
With this system, the recipient sets a combination of any character string that will serve as an account identifier instead of an account number and notifies the sender, so that the recipient can request a remittance without disclosing the account number information to the sender.In addition, there are two types of account identifiers: public identifiers that are not disclosed to any limited parties, and private identifiers that are disclosed only to a limited number of parties, so you can use them according to your purpose.

In addition, any string that becomes an account identifier can be determined to be "meaningful" based on specified criteria. By using a "meaningful" string as the account identifier, it becomes easier to remember and reduces input errors.

In addition, when a sender sends money using a public identifier, if the public identifier is not unique, the recipient can uniquely identify the recipient by searching using a sub-keyword set in advance.

In addition, when the nickname of the recipient's account is used as the account identifier, whether the nickname can be uniquely identified is checked based on the nickname shared information of a user group including the recipient and/or sender, and this check is limited to nicknames known to the recipient and sender, allowing for efficient system operation.

In addition, if the private identifier includes the name or date of a meeting among a limited number of recipients, the recipient can confirm or transcribe the name or date of the meeting from their electronic calendar, making it easier to enter the private identifier and to associate the content of the meeting (gathering).

In addition, the disclosure destination of a private identifier can be easily identified by specifying a representative string from among multiple public identifiers.

In addition, when a remitter searches for a public identifier, people who the remitter has contact with on social media or who have made transfers in the past are displayed preferentially, making it easier for the remitter to find the uniqueness of the public identifier.

In addition, senders and recipients can send messages, images, and stamps within chat rooms linked to account identifiers, allowing them to confirm details and have other conversations with the other party using the same user interface as chat rooms on existing SNSs.

The present invention has been described above using embodiments, but it goes without saying that the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be clear to those skilled in the art that various modifications and improvements can be made to the above embodiments. Furthermore, it is clear from the claims that forms incorporating such modifications or improvements can also be included within the technical scope of the present invention.

In the above embodiment, a cash remittance system for banks was described in particular, but the invention can also be applied to remittances at other financial institutions. Furthermore, in the above embodiment, the present invention was described as a remittance system, but the present invention can also be considered as an invention of a remittance method or a program that causes a computer to execute remittance processing.

10 Depositor terminal 20 Remitter terminal 100 Remittance server 101 Account identifier setting means 102 Public identifier storage means 103 Private identifier storage means 104 Remittance destination specification means 105 Account identifier search means 106 SNS information acquisition means 200 Accounting system 201 Remittance execution means 202 Remittance history storage means 301, 302 Account identifier setting screen 303 to 309 Other screens

Claims (8)

A remittance system that allows a remitter to remit money without specifying the recipient's account number,
having the recipient input an arbitrary combination of characters that will be used as an account identifier in place of the account number;
an account identifier setting means for causing the recipient to set the input character string as a public identifier that will be made public to an unlimited number of recipients;
a remittance destination specifying means for searching for a remittance destination using a sub-keyword preset by the recipient, if the public identifier is not unique when the remitter remits the remittance using the public identifier;
A remittance system comprising: 2. The remittance system according to claim 1, wherein the remittance destination specifying means checks whether the nickname input by the recipient as the account identifier in the account identifier setting means can be uniquely specified. If the arbitrary character string is the nickname of the recipient's account,
The remittance system according to claim 2, characterized in that it checks whether the nickname is unique based on shared nickname information in a user group including the recipient or a user group including the remitter. If the arbitrary character string is the nickname of the recipient's account,
The remittance system of claim 2, wherein the system checks whether the nickname is unique based on shared nickname information in a user group including only the recipient, a user group including only the remitter, or a user group including both the recipient and the remitter. A remittance system according to any one of claims 1 to 4, wherein multiple identifiers for identifying a single account can be registered for that single account instead of an account number. The remittance system described in claim 1 or 2, characterized in that when the remitter searches for the public identifier, people with whom the remitter has contact on SNS or people with whom the remitter has made transfers in the past are preferentially displayed based on whether the remitter has friend registrations on the SNS or has made transfers. A remittance method that allows a remitter to remit money without specifying the recipient's account number,
having the payee input an arbitrary character string combination that serves as an account identifier in place of the account number;
a step of having the recipient set the input character string as a public identifier to be made public to an unlimited number of recipients and/or as a private identifier to be made public only to a limited number of recipients;
uniquely identifying the recipient's account number from the public identifier or the private identifier and executing the remittance;
When the remitter uses the public identifier to remit money, if the public identifier is not unique, the recipient searches using a sub-keyword previously set by the recipient to uniquely identify the remitter;
A remittance method characterized by being executed by a computer. A program causing the computer to execute each step described in claim 7.