A money transfer system, method, and program that allows transfers to be made using an account identifier set by the recipient instead of an account number.

Abstract

This invention provides a remittance system, remittance method, and program that allow users to set an account identifier to replace their account number when making a remittance request, and to send funds to the specified account identifier. [Solution] In the remittance system, the remittance server 100 includes an account identifier setting means 101, a public identifier storage means 102, a private identifier storage means 103, a remittance destination identification means 104, an account identifier search means 105, and an SNS information acquisition means 106. The account identifier setting means 101 prompts the recipient to input an arbitrary combination of strings that will serve as an account identifier instead of an account number, and designates the input strings as a public identifier that will be made public without limiting the recipients and / or a private identifier that will be made public only to limited recipients. The remittance execution means 201 searches for the public identifier or private identifier to uniquely identify the recipient's account number and executes the remittance.

Description

Technical Field

[0001] The present invention relates to a remittance system, a remittance method, and a program that enable remittance without specifying an account number.

Background Art

[0002] Conventionally, when making a remittance between accounts, the recipient can only confirm the name of the requester, and the purpose of the remittance cannot be confirmed. In addition, when requesting a transfer to an account, it was essential to convey personal information such as a store number or an account number. Therefore, a system that enables remittance without knowing the account number of the remittance destination is known.

[0003] 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 the mobile phone number instead of an account number. In addition, Patent Document 2 discloses a proxy account management device that can open a proxy account that can be directly used for transfer processing to an account already opened at a financial institution by associating it with an ID specified by a user, and can use the same account even when the transfer destination is different.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in the inventions described in the above-mentioned patent documents, it was not possible for users to use account identifiers of their own choosing. Specifically, in the invention described in Patent Document 1, the account identifier is limited to a mobile phone number or email address, and in the invention described in Patent Document 2, the identifier for the proxy account is automatically generated by the system, so users cannot create their own account identifiers.

[0006] Therefore, in view of the above-mentioned problems, the present invention aims to provide a remittance system in which a user can arbitrarily set an account identifier to replace the store number and account number when making a remittance request, and the remitter can search for that account identifier and uniquely identify the recipient before making the remittance. [Means for solving the problem]

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

[0008] (1) A remittance system that enables a remitter to send money without specifying the recipient's account number, comprising: means for generating a string that is determined to be a “meaningful string” according to predetermined criteria (including not being a string of numbers only, not being a string of alphanumeric characters and symbols, and containing at least one word found in a dictionary) as an account identifier in place of the account number; and means for setting an account identifier that causes the recipient to set the “meaningful string” as a public identifier that is made public without limiting the recipient.

[0009] (2) The configuration of (1) above is further characterized in that, when the remitter makes a remittance using the public identifier, if the public identifier is not unique, the remitter further provides a means for uniquely identifying the remittance destination by searching using a subkeyword set in advance by the recipient.

[0010] (3) In the configuration of (1) or (2) above, if the account identifier is the nickname of the recipient, the system is characterized by checking whether the nickname can be uniquely identified based on the shared nickname information shared between the recipient and the user group including the sender, and / or the shared nickname information shared between the recipient and other user groups including the sender.

[0011] (4) The configuration of (2) above is characterized in that the public identifier and the subkeyword are integrated and used as a single account identifier.

[0012] (5) The configuration of (1) or (2) above is characterized in that the account identifier setting means is capable of setting an expiration date for the account identifier.

[0013] (6) In the configuration of (2) above, when the means for identifying the recipient of the remittance uses shared nickname information to determine uniqueness, it is characterized in that a search flag is used that indicates the search range of the user group of the recipient or the remitter of the shared nickname information.

[0014] (7) A device for enabling a remitter to send money without specifying the recipient's account number, comprising: means for generating a string that is determined to be a “meaningful string” according to predetermined criteria (including not being a string of numbers only, not being a string of alphanumeric characters and symbols, and containing at least one word found in a dictionary) as an account identifier in place of the account number; and means for causing the recipient to set the “meaningful string” as a public identifier that is made public without limiting the recipient.

[0015] (8) A program for enabling a remitter to remit money without specifying the recipient's account number, which causes a computer to generate, as an account identifier instead of the account number, a character string determined to be a "meaningful character string" according to a predetermined criterion (including all of not being a character string consisting only of numbers, not being a罗列 of alphanumeric symbols, and including at least one word in a dictionary), and to function as means for setting the "meaningful character string" as a public identifier to be publicly disclosed without limiting the disclosure destination to the recipient.

[0016] (Blank line)

[0017] (Blank line)

[0018] (Blank line)

Advantages of the Invention

[0019] According to the present invention, when a user makes a remittance request, an account identifier that can be arbitrarily set instead of a store number and an account number can be provided, and a remittance system can be provided in which a remitter can search for the account identifier and uniquely identify a remittance destination to make a remittance.

Brief Description of the Drawings

[0020] [Figure 1] It is a diagram showing the concept of an account identifier (ID) used instead of an account number in the present invention. [Figure 2] It is a diagram showing the functional configuration of a remittance system in an embodiment of the present invention. [Figure 3] It is a diagram showing an example of a setting screen for an account identifier (public identifier). [Figure 4] It is a diagram showing an example of a setting screen for an account identifier (non-public identifier). [Figure 5] It is a diagram showing the concept when searching for a public identifier. [Figure 6] It is a diagram showing the processing flow of a recipient terminal in an embodiment of the present invention. [Figure 7]It is a diagram showing the processing flow of the remitter terminal in an embodiment of the present invention. [Figure 8] It is a diagram showing an example of a screen as seen from the remitting side when sending a transfer request when a non-public identifier is specified. [Figure 9] It is a diagram showing an example of a screen as seen from the recipient side of the history within the room. [Figure 10] It is a diagram showing an example of a screen where the recipient who is the banquet organizer checks the transfer amount and the transferred / untransferred people from the room.

Embodiments for Carrying Out the Invention

[0021] (Overview) FIG. 1 is a diagram showing the concept of an account identifier (ID) used instead of an account number in the present invention. As shown in the figure, when an individual user ("Japanese Ako") requests a transfer, it is necessary to inform the remitter of the recipient's account information (bank name "ABC Bank", branch number "211", account type "ordinary", account number "1234567", etc.). However, in the present invention, an account identifier (ID) that substitutes for the account information is used. The account identifier can be arbitrarily set by the recipient and can be disposable or designated indefinitely. Here, the IDs that can be set include a public identifier (also called "Public ID") and a non-public identifier (also called "Private ID"), and the recipient can use them appropriately according to the purpose, and one or more of each can be set.

[0022] The public identifier is an ID set by the recipient without restricting the public destination (transfer request destination), and the non-public identifier is an ID set by the recipient with restrictions on the public destination (for example, limited to acquaintances or friends). Since the public identifier is disclosed to an unspecified number of people, there is a possibility that it cannot be uniquely identified by the parties. Therefore, in order to avoid this, a sub-keyword is used to uniquely narrow down the Public ID. This will be described later.

[0023] In the example in Figure 1, the public identifiers are "nekoneko" and "tanukichi," while the private identifiers are "2019 Japan Research Institute Class Reunion" and "December 25th Basketball Club Year-End Party." When used for collecting money for gatherings, setting the date and content of the gathering as private identifiers will facilitate communication with those involved.

[0024] Here, account identifiers (referring to both public and private identifiers) are defined as "meaningful strings of characters" (for example, nicknames, terms understood only among related parties or acquaintances, etc.). Mere numbers or strings of meaningless characters cannot be set as account identifiers. Therefore, IDs that are randomly assigned by the system are excluded. In addition, only one representative account identifier (referred to as the "representative ID") shall be designated for public identifiers. The representative ID is an ID that permanently identifies the user's account, while other non-representative IDs are mainly used for temporary use, such as when they are made public for a limited time. In the example shown in the diagram, "nekoneko" is the representative ID. Note that a representative ID shall not be set for private identifiers. The method for setting account identifiers will be described later.

[0025] Thus, in this invention, the recipient of a remittance (transfer destination) can be identified by an account identifier instead of account information, allowing the recipient to request and receive remittances without their account information being known to the sender. Furthermore, the remitter who receives a remittance request using an account identifier can search for that account identifier and verify the recipient's name from the account name.

[0026] Hereinafter, embodiments for carrying out the present invention (hereinafter referred to as "embodiments") will be described in detail with reference to the attached drawings. In the following figures, the same elements are denoted by the same numbers or reference numerals throughout the description of the embodiments. In addition, in the functional configuration diagrams, the arrows between functional blocks represent the direction of data flow or processing flow.

[0027] (Functional Configuration) Figure 2 shows the functional configuration of a remittance system (hereinafter referred to as "this system") in an embodiment of the present invention. In this system, the depositor terminal 10, which is the terminal of the user (depositor), and the 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 a function to allow the depositor to set an account identifier, and a function to convert 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 performs the actual deposit and withdrawal processing.

[0028] The remittance server 100 includes, as functional blocks, an account identifier setting means 101, a public identifier storage means 102, a private identifier storage means 103, a remittance destination identification means 104, an account identifier search means 105, and an SNS information acquisition means 106. The accounting system 200 has the core functions of a financial institution and is equipped with various functions, but here only the remittance execution means 201 and the 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 described in order below.

[0029] The account identifier setting means 101 communicates with the depositor terminal 10 and has the function of allowing the depositor to set an account identifier. Specifically, it displays an ID setting screen as shown in Figures 3 and 4 on the depositor terminal 10 and allows the depositor to set the ID name (an arbitrary string that will be used as the account identifier), the scope of disclosure (distinction between public and private identifiers), etc. Here, the arbitrary string that will be used as the account identifier is a string that is judged to have "meaning" according to predetermined criteria. This is because a string that has "no meaning" is difficult for humans to remember and can cause input errors.

[0030] Here, the specified criteria may be that the string must not consist solely of numbers, must not be a string of alphanumeric characters and symbols, and must contain at least one word found in a dictionary. This eliminates identifiers that appear to be automatically assigned by the system. For example, "neko" (cat) and "tanuki" (raccoon dog) are strings that "have meaning" because they are found in dictionaries, but they are too simple to be suitable as identifiers. It is preferable to use strings like "nekoneko" (cat cat) and "tanukichi" (raccoon dog), as shown in the IDs in Figure 1. Of course, ultimately, it is sufficient if the person setting the account identifier deems the string to be "meaningful" and to have the ability to identify an individual.

[0031] Figure 3 shows the public identifier settings screen, where "nekoneko" is selected as the ID name and "Public" is selected as the scope of public access, indicating that it is a public identifier. The ID name can be a generic string, or the system can be configured to automatically generate a meaningful string (for example, a unique ID name like "Magical Happy Girl 2021").

[0032] Furthermore, in the settings screen 301 of this example, "AAA High School," "BB University," and "C Circle" are set as "sub-keywords." Sub-keywords are search keywords used to narrow down the ID name and uniquely identify an account when the public identifier ID name alone is not sufficient to 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 illustration, then using sub-keywords in combination will allow for unique identification.

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

[0034] Furthermore, the set expiration date refers to the validity period of the ID name, and in the case of public identifiers, 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 may also be possible to specify whether the ID name is a representative ID or not. However, the set expiration date for representative IDs may be set to unlimited automatically.

[0035] Figure 4 shows the settings screen 302 for a private identifier. Here, "December 25th Basketball Club Year-End Party" is selected as the ID name, and "Private" is selected as the scope of disclosure to indicate that it is a private identifier. Unlike public identifiers, private identifiers require specifying an expiration date and the ID names of the recipients to whom the identifier will be disclosed. Subkeywords do not necessarily need to be set. In this example, "2021 / 12 / 31" is specified as the expiration date, and "Kametaro" and "Usagi" are specified as the "recipients" to whom the private identifier will be disclosed, meaning only those individuals will be able to access it.

[0036] The "distribution destination" for a non-public identifier is, in principle, specified by the Public ID of the recipient's representative, but it may also be specified by a Public ID that is not that of the representative. However, the distribution destination must be uniquely set by the identifier registered as the distribution destination (Kametaro, Usagi). If the distribution destination cannot be uniquely identified, it must be uniquely identified by combining sub-keywords or by the method described below.

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

[0038] Furthermore, if there is no shared nickname information, or if it is insufficient, the system may be configured to accumulate shared information as the user continues to use the system. Also, 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 remitter and the remitter, so that the system can be operated efficiently. If a non-public identifier cannot be uniquely identified even by this method, it is necessary to specify a sub-keyword, similar to a public identifier. Shared nickname information may be stored in the account identifier search means 105 or obtained from the SNS information acquisition means 106.

[0039] Furthermore, "Kametaro" and "Usagi" can be specified using Private IDs instead of Public IDs. This is because Private IDs, which are used among close acquaintances, are often used permanently and are therefore more suitable as key information for transmitting account details.

[0040] 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 associated with unique account information (bank code, branch number, account type, account number, and account holder name), and the default setting is unlimited, but a setting period may be set depending on the purpose. In addition, one representative ID may be set for each public identifier. Furthermore, as mentioned above, sub-keywords may be set for each public identifier as needed.

[0041] The private identifier storage means 103 is a storage means (database) for storing users' private identifiers. Private identifiers can be either unlimited or limited in their setting period. Note that private identifiers do not have a representative ID or subkeywords.

[0042] The recipient identification means 104 receives a remittance request (transfer request) from the sender terminal 20 using an account identifier and has the function of converting the account identifier into unique account information based on the public identifier storage means 102 or the private identifier storage means 103. The recipient identification means 104 also has the role of checking whether the account identifier is already in use when the recipient sets the account identifier, and whether the account information can be uniquely identified from the account identifier. In this case, 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 making a remittance. For example, if the search flag is 1, the search scope is the user group including the recipient or sender; if the search flag is 2, the search scope is the user group including only the recipient; if the search flag is 3, the search scope is the user group including only the sender; if the search flag is 4, the search scope is the user group including both the sender and recipient; and if the search flag is 0, it means that there is no shared information in the search scope. This allows the uniqueness of the nickname used as an account identifier to be checked not only during registration but also during actual transfers.

[0043] The account identifier search means 105 is a means for the remitter to search for the public identifier using a subkeyword when the account identifier is a public identifier. While the depositor may inform the remitter in advance whether the account identifier is public or private, this can also be determined by the presence or absence of a subkeyword, even without prior notification.

[0044] The SNS information acquisition method 106 prioritizes displaying people with whom the sender has a relationship, such as those on SNS or those with a history of past transfers, when the sender searches for a Public ID. An example of this is shown in Figure 5. In this example, "Japan A-ko" requests "Research Institute B-ko" to transfer money for expenses after a party. In this case, "Japan A-ko" simply provides "December 25th Basketball Club Year-End Party" as the recipient's ID, and "Research Institute B-ko" logs into her online banking, enters the recipient's ID on the ID search screen, and presses the search button, where "Japan A-ko" is displayed as the recipient. After confirming the displayed recipient, "Research Institute B-ko" enters the transfer amount "¥5000" and presses the confirm button to execute the transfer. It is also possible to prioritize displaying people with whom the sender has a relationship, such as those who are friends on SNS or have a history of past transfers, on the search screen. This is to make the search more efficient.

[0045] The functional configuration of this system described in Figures 2 to 5 above is merely an example, and 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 realized by a computer program executed by the CPU (Central Processing Unit) built into the device, which reads a computer program stored in a storage device such as ROM (Read Only Memory), flash memory, SSD (Sol Identifier State Drive), or hard disk. In other words, each functional processing unit is realized by this computer program reading and writing necessary data such as tables from a database (DB) or memory storage area stored in the storage device, and, if necessary, controlling related hardware (e.g., input / output devices, display devices, communication interface devices). Furthermore, the database (DB) in the embodiments of the present invention may be a commercial database, but it also means a mere collection of tables and files, and the internal structure of the database itself is not specified.

[0046] (Processing flow) The following details of the processing at the depositor's terminal and the sender's terminal will be explained using Figures 6 and 7. In the following processing flow chart, the order of processing steps may be changed as long as the relationship between the inputs and outputs of each step is not compromised.

[0047] Figure 6 shows the processing flow of the recipient terminal in an embodiment of the present invention. First, in step S10, the recipient terminal displays the account identifier setting screen (ID setting screen in Figures 3 and 4). Next, in steps S10a and S10b, it is determined whether the entered ID name is a "meaningful" string based on predetermined criteria. Here, the predetermined criteria are, as mentioned above, that it is not a string of only numbers, not a string of alphanumeric characters and symbols, and that it contains at least one word found in a dictionary, however, the final decision may be made by the inputter.

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

[0049] If the ID name cannot be uniquely identified, the user is prompted to specify a sub-keyword in step S13. Even if the ID name can be uniquely identified, the user may still be prompted to enter a sub-keyword as a precaution.

[0050] Next, in step S14, the ID name and sub-keyword are set as public identifiers.

[0051] Then, in step S15, it is checked whether the configured ID name is designated as the representative ID. If it is, in step S16, the representative flag is turned on for that ID to distinguish it from other IDs. Finally, once all the setting items have been entered and the user presses the settings button, the settings are saved and the process ends.

[0052] In step S11, if Public is not specified (step S11:N), the process proceeds to step S17, where the entered ID name is recognized as a private identifier (specified as Private). Then, in step S18, it is determined whether the ID name can be uniquely identified from the perspective of the public recipient of the private identifier. In this case, if the recipient's nickname is used as the account identifier, as mentioned above, the system may check whether it can be uniquely identified by using the shared nickname information within the user group, which includes both the recipient and the sender. If a unique identifier cannot be found, step S18a prompts for a sub-keyword and re-checks the entered ID name.

[0053] Next, in step S19, the user registers the set deadline. Then, in steps S19a and S19b, if the ID name contains a date or a meeting name (e.g., XX meeting, XX celebration, XX gathering, etc.), the user's (sender's) electronic calendar may be checked to confirm the meeting name and date. Conversely, clicking on a specific date in the electronic calendar may allow the ID name to be automatically entered (transcribed). Finally, the ID of the user who will make the private identifier public is registered as the public recipient. Then, when the user presses the settings button, the settings are saved and the process ends.

[0054] 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 Public, i.e., a public identifier. The recipient may specify whether the specified ID name is a public identifier or a private identifier, but if it is unknown, the remitter terminal refers to the public identifier storage means, and if it is registered there, it is treated as a public identifier and the following processing proceeds.

[0055] 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 sub-keyword. If there is a sub-keyword, the ID name is searched using the sub-keyword (step S22), and the search results are displayed (step S23). At this time, the sender's past transfer history is searched, and if there are any with the same ID name, those are displayed preferentially. Also, if the sender's SNS information (IDs of people registered in the friend list or mutual follow list) can be obtained, that information is displayed preferentially.

[0056] Then, in step S24, the system waits for the sender to select one of the displayed search results. 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 the account identifier, and the transfer is executed (a request is made to the accounting system to execute the transfer).

[0057] Finally, in step S26, the system checks whether the transfer was completed successfully. If a transfer error occurs, in step S24, a message is sent to the sender's terminal asking the recipient to verify that the ID name and subkeyword are correct.

[0058] Furthermore, if it is determined in step S21 that there are no sub-keywords, in step S28, the recipient's account identification information is converted using only the specified ID name, and the transfer is executed (a request is made to the accounting system to execute the transfer).

[0059] Furthermore, if the specified ID name is Private instead of Public in step S20, in step S28, the specified ID name is converted to the recipient's account identification information and the transfer is executed (a request is made to the accounting system to execute the transfer). In either case, the check for any transfer errors is performed in step S26.

[0060] (Other screen examples) The other functions of this system will be explained below using Figures 8 to 10.

[0061] Figure 8 shows an example of a screen viewed from the perspective of the sender when a transfer request is made using a private identifier. Screen 304 in this example shows a list of recipients who have received a transfer request using a Private ID. Each recipient uses a different Private ID, but the account holder's name and the transfer status are displayed. Screen 305 shows a conversation with a recipient in a "room." Here, a "room" (also called a "talk room") is a virtual room with a user interface similar to the talk rooms on existing social networking services, enabling conversation between the sender and recipient. A room is created for each Private ID, and it is possible to talk with multiple recipients. Of course, it is possible to use not only text but also images and stamps. Rooms can be built within this system, or existing social networking service talk rooms can be used.

[0062] Figure 9 shows an example of a screen showing the history within a room from the recipient's perspective. The recipient can manage a list of publicly available transfer requests. That is, after logging in from screen 306 with their branch number and account number, the recipient can check the history within the room for each account identifier (ID). Here, the ID can be either a Public ID or a Private ID, as shown in screen 307. When the recipient selects a specific ID from screen 307 (in this case, "December 25th Basketball Club Year-End Party"), the details of that ID (in this case, that a transfer has been made from the person who requested the transfer) are displayed as shown in screen 308. In this way, the recipient can check the name of the account holder who has made the transfer, the amount of the transfer, and the details from this room. For example, as shown in screen 309 of Figure 10, if the recipient was the organizer of the party, the recipient can check from the room who has made the transfer / has not yet made the transfer, the amount of each transfer, and the total amount of transfers made.

[0063] (Effects of the embodiment) This system allows recipients to set an arbitrary string combination to serve as an account identifier instead of an account number and inform the sender, thus enabling them to request a transfer without disclosing their account number to the sender. Furthermore, there are two types of account identifiers: public identifiers that are not restricted to specific recipients, and private identifiers that are only disclosed to a limited number of recipients, allowing users to choose the appropriate identifier for their purpose.

[0064] Furthermore, any string used as an account identifier can be judged based on predetermined criteria to determine whether or not it is a "meaningful" string. By using a "meaningful" string as an account identifier, it becomes easier to remember and input errors can be reduced.

[0065] Furthermore, when a sender uses a public identifier to send money, if the public identifier is not unique, the recipient can uniquely identify the recipient by searching using a sub-keyword that they have set in advance.

[0066] Furthermore, when using the recipient's account nickname as the account identifier, whether or not that nickname can be uniquely identified is checked based on shared nickname information within the user group, including the recipient and / or the sender. Since this check is limited to nicknames known to the recipient and the sender, the system can be operated efficiently.

[0067] Furthermore, if the confidential identifier includes the name or date of a meeting among a limited number of recipients, allowing recipients to confirm or transcribe the meeting name or date from their electronic calendar will facilitate the input of the confidential identifier and make it easier to associate it with the content of the meeting (gathering).

[0068] Furthermore, by specifying a representative string from among multiple public identifiers as the destination for a private identifier, it becomes easier to identify the recipient.

[0069] Furthermore, when a sender searches for a public identifier, prioritizing the display of people they interact with on social media or those with whom they have a history of making transfers makes it easier to find the uniqueness of the public identifier.

[0070] Furthermore, both the sender and recipient can send messages, images, and stamps within the chat room linked to the account identifier, allowing them to confirm details and engage in other conversations with the other party using the same user interface as existing chat rooms on social media platforms.

[0071] Although the present invention has been described above using embodiments, 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 obvious to those skilled in the art that various modifications or improvements can be made to the above embodiments. Furthermore, it is clear from the claims that such modified or improved forms may also be included in the technical scope of the present invention.

[0072] In the above embodiments, a cash transfer system in a bank was described in particular, but the invention can also be applied to transfers in other financial institutions. Furthermore, in the above embodiments, the present invention was described as a product invention, specifically a transfer system, but the present invention can also be considered as an invention of a transfer method or an invention of a program that causes a computer to execute a transfer process. [Explanation of symbols]

[0073] 10 Depositor terminal 20 Sender terminal 100 remittance servers 101 Account identifier setting means 102 Public identifier storage means 103 Non-public identifier storage means 104 Methods for identifying the recipient of the remittance 105 Account Identifier Search Method 106 SNS information acquisition means 200 Accounting Systems 201 Remittance Execution Method 202 Remittance history storage means 301,302 Account Identifier Settings Screen 303-309 Other screens

Claims

1. A money transfer system that allows the sender to send money without specifying the recipient's account number, A means for generating a string that is determined to be a "meaningful string" according to predetermined criteria (including not being a string of numbers only, not being a string of alphanumeric characters and symbols, and containing at least one word found in a dictionary), to be used as an account identifier in place of the aforementioned account number, The aforementioned "meaningful string" is to be made public as a public identifier without limiting the recipient, and the means for setting an account identifier allows the recipient to set this public identifier. A remittance system characterized by having the following features.

2. The remittance system according to claim 1, further comprising a means for uniquely identifying the recipient when the remitter uses the public identifier to make a remittance, if the public identifier is not unique, by searching using a sub-keyword set in advance by the recipient.

3. If the account identifier is the nickname of the recipient, then based on the shared nickname information shared between the recipient and the user group including the sender, and / or the shared nickname information shared between the recipient and other user groups including the sender, The remittance system according to claim 1 or 2, characterized by checking whether the nickname can be uniquely identified.

4. The remittance system according to claim 2, characterized in that the public identifier and the subkeyword are integrated and used as a single account identifier.

5. The remittance system according to claim 1 or 2, characterized in that the account identifier setting means allows setting an expiration date for the account identifier.

6. The remittance system according to claim 2, characterized in that, when the means for identifying the recipient of the remittance uses shared nickname information to determine uniqueness, a search flag indicating the search range of the user group of the recipient or the remitter of the shared nickname information is used.

7. A device that enables a sender to make a transfer without specifying the recipient's account number, A means for generating a string that is determined to be a "meaningful string" according to predetermined criteria (including not being a string of numbers only, not being a string of alphanumeric characters and symbols, and containing at least one word found in a dictionary), to be used as an account identifier in place of the aforementioned account number, A means for having the recipient set the aforementioned "meaningful string" as a public identifier that is made public without limiting the recipients, A device characterized by being equipped with the following features.

8. A program that allows the sender to send money without specifying the recipient's account number. On the computer, A means for generating a string that is determined to be a "meaningful string" according to predetermined criteria (including not being a string of numbers only, not being a string of alphanumeric characters and symbols, and containing at least one word found in a dictionary), as an account identifier in place of the aforementioned account number. A means for causing the recipient to set the aforementioned "meaningful string" as a public identifier that is made public without limiting the recipients, A program characterized by being designed to function as such.

Images