JP2017091245A - Execution device, execution method, and execution program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To flexibly perform settlement for the shortage of electronic money according to various situations.SOLUTION: An execution device includes an acquisition unit and an execution unit. The acquisition unit obtains user information that is information on a user who uses electronic money. The execution unit executes, when a charge balance is insufficient in settlement by the electronic money which the user uses, charge to an electronic money account which the user uses, without receiving an operation from the user on the basis of the user information obtained by the acquisition unit.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an execution device, an execution method, and an execution program.

  In recent years, electronic money has been actively used. In the settlement of electronic money, there is a problem that it takes time because it is necessary to newly charge electronic money if the amount charged in advance is insufficient for the settlement amount.

  As a technology related to payment of such electronic money, credit information is held on the terminal side of a user who performs payment, thereby enabling quick payment processing even when the electronic money balance is less than the payment amount. An electronic money settlement system is known.

JP 2007-213399 A

  However, with the above-described conventional technology, it is not always possible to make a settlement for a shortage of electronic money flexibly according to various situations. Specifically, in the above-described conventional technology, it is necessary for a user terminal to have credit information corresponding to a deposit state or the like in a financial institution. That is, in the above-described prior art, when electronic money is used, it is essential to prepare credit information in advance and use the terminal with the credit information. In addition, the prior art cannot be applied to users who do not have credit information of financial institutions. Thus, with the above-described conventional technology, it is difficult for various users who use electronic money to enjoy convenience.

  The present application has been made in view of the above, and an object thereof is to provide an execution device, an execution method, and an execution program that can flexibly make a payment for a shortage of electronic money according to various situations. .

  An execution apparatus according to the present application acquires an acquisition unit that acquires user information, which is information about a user who uses electronic money, and the acquisition unit when there is a shortage in charge balance in the settlement of electronic money used by the user. And an execution unit that charges an electronic money account used by the user without receiving an operation from the user based on the user information.

  According to one aspect of the embodiment, there is an effect that payment for a shortage of electronic money can be performed flexibly according to various situations.

FIG. 1 is a diagram illustrating an example of execution processing according to the embodiment. FIG. 2 is a diagram illustrating a configuration example of a provider server according to the embodiment. FIG. 3 is a diagram illustrating an example of a user information storage unit according to the embodiment. FIG. 4 is a diagram illustrating an example of a purchase behavior table according to the embodiment. FIG. 5 is a diagram illustrating an example of the application history table according to the embodiment. FIG. 6 is a diagram illustrating an example of the SNS information table according to the embodiment. FIG. 7 is a diagram illustrating an example of an electronic money account information storage unit according to the embodiment. FIG. 8 is a diagram illustrating an example of usage history information according to the embodiment. FIG. 9 is a flowchart illustrating a processing procedure performed by the provider server according to the embodiment. FIG. 10 is a hardware configuration diagram illustrating an example of a computer that realizes the function of the provider server.

  Hereinafter, an execution apparatus, an execution method, and an execution program (hereinafter, referred to as “embodiment”) according to the present application will be described in detail with reference to the drawings. In addition, the execution apparatus, execution method, and execution program which concern on this application are not limited by this embodiment. In the following embodiments, the same portions are denoted by the same reference numerals, and redundant description is omitted.

[1. Example of execution process)
First, an example of execution processing according to the embodiment will be described with reference to FIG. FIG. 1 is a diagram illustrating an example of execution processing according to the embodiment. In FIG. 1, an execution system 1 is taken as an example to describe one form of execution processing according to the present application. Specifically, in FIG. 1, a charge process in settlement of electronic money used by a user by a business server 100 that is a server device included in the execution system 1 and corresponding to the execution device according to the present application. An example in which is performed will be described. The charge process executed by the business operator server 100 refers to automatically generating a charge amount in the user's electronic money account on behalf of the user under a predetermined condition.

  As shown in FIG. 1, the execution system 1 includes a user terminal 10, a store terminal 30, a financial institution server 40, and an operator server 100. Each device included in the execution system 1 is connected to be communicable with each other via a communication network (not shown) (for example, the Internet). The number of devices included in the execution system 1 is not limited to the example illustrated in FIG. For example, the execution system 1 may include a plurality of user terminals 10.

  The user terminal 10 is an information processing device used by general users. Specifically, the user terminal 10 is used for a user to browse a web page or use an application installed in the user terminal 10. The user terminal 10 is equipped with an electronic money function. In this case, the user terminal 10 can perform electronic money charging and settlement processing. The user terminal 10 is realized by, for example, a mobile terminal such as a smartphone, a tablet terminal, or a PDA (Personal Digital Assistant), a desktop PC (Personal Computer), a notebook PC, or the like. In the example of FIG. 1, the user terminal 10 is a smartphone used by the user U01 and has an electronic money function. The user terminal 10 realizes an electronic money function by, for example, an installed predetermined application.

  The store terminal 30 is a predetermined information processing device provided in the store. The store terminal 30 has an electronic money settlement function. For example, the store terminal 30 accepts electronic money charging or payment using electronic money from the user. Specifically, the store terminal 30 accepts a payment process using electronic money when a user purchases a product sold in the store. Then, when the electronic money is used, the store terminal 30 transmits information related to the use of the electronic money to the business server 100 via the network.

  The financial institution server 40 is a server device provided in a financial institution. The financial institution server 40 manages deposits and withdrawals in an account opened by the user at the financial institution according to a predetermined agreement. For example, when the business server 100 executes a charge process described later, the financial institution server 40 executes an account transfer according to the amount.

  The business server 100 is a server device used by a business that performs settlement using electronic money. The enterprise server 100 manages an electronic money account that records deposits and withdrawals related to electronic money. The business server 100 accepts the use of electronic money from the user. For example, the business entity server 100 accepts the use of electronic money via a network via the store terminal 30 having a payment function for electronic money. When the user performs electronic money deposit processing (charge), the business server 100 adds the charge amount in the user's electronic money account. Further, when the user purchases a product using electronic money, the business server 100 performs a settlement process and deducts the purchase amount from the charge amount of the user's electronic money account.

  Further, the business server 100, when the user tries to make a payment exceeding the charge amount of the electronic money, in other words, when there is a shortage in the payment of the electronic money, the charge of the shortage is performed under a predetermined condition. Execute the process. Thereby, even when the user tries the settlement process when the charge amount is insufficient, the user can complete the settlement process without receiving a warning such as an error due to the inability to settle. For this reason, the user can enjoy conveniences such as being able to use electronic money without worrying about the amount of charge, and saving the trouble of charging the shortage. The enterprise server 100 includes a user information storage unit 121 and an electronic money account information storage unit 122 as storage units for information used in the above processing. In addition, about the charge which generate | occur | produces by the charge which the provider server 100 performs, it may describe with a temporary charge for distinction. Hereinafter, the execution process of the temporary charge by the execution system 1 will be described along the flow with reference to FIG.

  In the example of FIG. 1, the user U01 performs electronic money settlement (step S11). For example, when the user U01 purchases a product at a visited store, the user U01 tries to settle with electronic money. The business entity server 100 acquires information related to the payment of the electronic money of the user U01 via the network (step S12). In addition, the process of step S11 and step S12 may be performed via the store terminal 30 with which the store which the user U01 visited is equipped.

  Here, the business entity server 100 acquires information (user information) related to the user U01 as information related to electronic money settlement. For example, when the electronic money is settled using the user terminal 10, the business server 100 acquires identification information for identifying the user U01 as user information. Further, the business server 100 acquires, as user information, an action history on the network of the user U01 based on information held in the user terminal 10. The business entity server 100 may acquire the user information of the user U01 by specifying the user information of the user U01 stored in advance in the user information storage unit 121 based on the acquired identification information. Then, the business entity server 100 acquires the credit rating of the user U01, which is information calculated based on the acquired user information. Although details will be described later, the user information includes various information related to the user U01. The business server 100 calculates the credit rating based on various user information. Note that the business operator server 100 also holds the calculated reliability in the user information storage unit 121 as one piece of user information because it is information related to the user U01.

  When the credit rating of the user U01 satisfies a predetermined standard and there is a shortage in the payment of the electronic money of the user U01, the business server 100 executes a charge process for the shortage ( Step S13). Specifically, the business entity server 100 performs a process for enabling payment of an amount deficient in settlement by performing a temporary charge that automatically charges an amount corresponding to the amount of deficiency. . When the payment processing executed in step S11 is completed in this manner, the business server 100 notifies the user U01 of the completion of payment (step S14). Thus, the business entity server 100 performs the charge processing for the shortage based on the user information of the user U01 using electronic money. Thereby, the user U01 can complete the settlement process without any trouble even if the charge amount is insufficient at the time of settlement. Note that the business server 100 does not necessarily charge the shortage amount, but may charge the amount exceeding the shortage amount. In addition, the business entity server 100 appropriately updates information in the electronic money account information storage unit 122 related to the user U01 based on electronic money settlement or temporary charge.

  Thereafter, the business entity server 100 performs a deposit process to the store where the electronic money is used at a predetermined timing (step S15). For example, the business entity server 100 performs a deposit process for a store when a certain day determined every month or when a certain amount of money to be deposited into the store reaches a certain amount.

  Further, the business server 100 requests the user U01 to repay the temporary charge amount generated by the charge at a predetermined timing. For example, the business entity server 100 requests the repayment of the provisional charge amount through an account of a financial institution with which the user U01 is contracted. In other words, the charge (provisional charge) executed by the operator server 100 is the amount of money that the user should originally charge before settlement according to the credit calculated from the user's action history on the network. It can be said that the post-payment is allowed together (the business server 100 changes the charge).

  For example, the business entity server 100 acquires information regarding an account of a financial institution with which the user U01 has a contract as user information. Then, the business entity server 100 requests the financial institution server 40 to transfer the account for the amount of money charged to the user U01 at a predetermined timing (step S16). Specifically, the business operator server 100 determines the business server from the account of the financial institution of the user U01 when the amount charged for the user U01 reaches a certain amount or on a specific day determined every month. 100 is requested for an account transfer of an amount corresponding to the charged amount. The financial institution server 40 executes the requested account transfer (step S17). When the account transfer is executed, the business operator server 100 notifies the user of the completion of the account transfer (step S18). By such processing, the operator server 100 can suppress the temporary charge amount for the user U01 to a fixed amount, and therefore can perform smooth operation.

  As described above, the business entity server 100 according to the embodiment acquires user information that is information regarding a user who uses electronic money. Then, when there is a shortage in the balance of the electronic money used by the user, the business server 100 performs charging on the electronic money account used by the user based on the acquired user information.

  As described above, the business entity server 100 according to the embodiment can complete the settlement process without any trouble even when the charge amount is insufficient at the time of settlement regarding the electronic money used by the user. In other words, even if the charge amount is insufficient at the time of payment, the business server 100 improves the convenience for the user by completing the payment process without incurring the user with a new charge process. Let Further, the business entity server 100 acquires user information of a user who uses electronic money, and determines whether or not the temporary charge process can be executed by specifying the user when the electronic money is used. To do. For this reason, according to the business server 100, even when a user terminal 10 other than the user terminal 10 holding the credit information or the like is used, as long as the information for identifying the user is obtained when the electronic money is used, Temporary charge processing for the user can be executed. Further, since the business server 100 performs charging based on user information, for example, even if it does not have an account (such as an account of a financial institution) corresponding to an immediate withdrawal, at the time of settlement, settlement processing is performed without any trouble. It can be carried out. For this reason, the user can enjoy the convenience of the temporary charge processing of electronic money regardless of the payment method using a credit card that requires credit information or the payment method using a debit card that requires an account corresponding to immediate debit. As described above, the business operator server 100 can flexibly make a payment for a shortage of electronic money according to various situations.

[2. (Server server configuration)
Next, the configuration of the operator server 100 according to the embodiment will be described with reference to FIG. FIG. 2 is a diagram illustrating a configuration example of the operator server 100 according to the embodiment. As shown in FIG. 2, the business operator server 100 includes a communication unit 110, a storage unit 120, and a control unit 130. The business server 100 includes an input unit (for example, a keyboard and a mouse) that receives various operations from an administrator who uses the business server 100, and an output unit (for example, a liquid crystal display) that outputs various types of information. ).

(About the communication unit 110)
The communication unit 110 is realized by, for example, a NIC (Network Interface Card). The communication unit 110 is connected to a communication network in a wired or wireless manner, and transmits and receives information to and from the user terminal 10, the store terminal 30, and the financial institution server 40 via the communication network.

(About the storage unit 120)
The storage unit 120 is realized by, for example, a semiconductor memory device such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 120 according to the embodiment includes a user information storage unit 121 and an electronic money account information storage unit 122. Hereinafter, each storage unit will be described in order.

(User information storage unit 121)
The user information storage unit 121 stores information regarding users who use electronic money. Here, FIG. 3 shows an example of the user information storage unit 121 according to the embodiment. As illustrated in FIG. 3, the user information storage unit 121 includes items such as “user ID”, “terminal ID”, “electronic money account”, “financial institution account”, and “credit”.

  “User ID” indicates identification information for identifying a user. “Terminal ID” indicates identification information for identifying a terminal device used by the user. In the embodiment, the user ID and the terminal ID are common to the reference numerals used in the description. For example, a user whose user ID is “U01” indicates “user U01”. A terminal device having a terminal ID “10” indicates “user terminal 10”.

  “Electronic money account” indicates an electronic money account owned by the user. “Financial institution account” indicates an account of a financial institution owned by the user. In FIG. 3, the electronic money account and the financial institution account are represented by concepts such as “XXX” and “YYY”, but actually, information for identifying the account such as an account number is stored.

  “Credit level” indicates the credit level of the user referred to when the business server 100 performs charging. In the embodiment, the trustworthiness is represented by a numerical value in five stages, where 5 is the highest trustworthiness and 1 is the lowest trustworthiness. In addition, the provider server 100 calculates a user's credit rating based on information stored in each data table described later. Then, the business server 100 stores the calculated numerical value in the user information storage unit 121 in association with the user ID.

  That is, in FIG. 3, as an example of the user information, the user U01 identified by the user ID “U01” uses the user terminal 10 identified by the terminal ID “10”, and the electronic money account “XXX” In this example, a financial institution account “YYY” is provided and the credit rating is “4”.

  3 shows an example in which the user U01 has one terminal device, electronic money account, and financial institution account, but the user U01 has a plurality of terminal devices, electronic money accounts, and financial institution accounts. Also good.

  In addition, the user information storage unit 121 includes each data table that stores a user's behavior history and the like as information used for calculating the user's reliability. As illustrated in FIG. 2, the user information storage unit 121 includes a purchase behavior table 1211, an application history table 1212, and an SNS (Social Networking Service) information table 1213 in the embodiment.

(About purchasing action table 1211)
The purchase behavior table 1211 stores information related to the purchase behavior of the user acquired via the network. Here, FIG. 4 shows an example of the purchase behavior table 1211 according to the embodiment. As illustrated in FIG. 4, the purchase behavior table 1211 includes items such as “user ID”, “purchase behavior evaluation”, “auction evaluation”, and “purchase behavior information”.

  “User ID” corresponds to the same item shown in FIG. “Purchase behavior evaluation” indicates an evaluation value related to purchase behavior via the user network. In the embodiment, the purchase behavior evaluation is represented by numerical values in five stages, where 5 is the highest evaluation and 1 is the lowest evaluation. The purchase behavior evaluation indicates a user's credit rating regarding the purchase behavior. In the purchase behavior evaluation, for example, the total amount of money purchased by the user within a predetermined period (for example, for one month), the frequency of purchase behavior, whether the purchase behavior was appropriate (payment delay etc. occurred) Etc.). Note that the purchase behavior evaluation may be a numerical value (average value or the like) obtained from the evaluation values obtained by evaluating the users at each store and the calculated evaluation values.

  “Auction evaluation” indicates an evaluation value of an action on a user's auction site when the user uses a predetermined auction site. In the embodiment, the auction evaluation is expressed by numerical values in five stages, where 5 is the highest evaluation and 1 is the lowest evaluation. The auction evaluation indicates the user's credit rating regarding the auction. For example, the auction evaluation is calculated based on whether or not an appropriate transaction without prompt communication and payment delay has been performed, the frequency of listing a product in an auction, the frequency of winning a product, and the like. The auction evaluation may be a numerical value (an average value or the like) obtained from the evaluation values obtained by collecting the evaluation values obtained by evaluating other users who are evaluation targets by other users participating in the auction.

  “Purchase action information” indicates an action history (behavior log) regarding a user's purchase action. The purchase action information has small items such as “action date and time”, “action type”, and “money”.

  “Action date and time” indicates the date and time when the user performed a purchase action or the like. “Behavior type” indicates the type of purchase behavior of the user. For example, the action type item stores actions such as product purchase, auction listing, bidding, and successful bid. “Amount” indicates an amount related to purchase behavior.

  That is, in FIG. 4, as an example of the purchase behavior information, the purchase behavior evaluation of the user U01 identified by the user ID “U01” is “4”, the auction evaluation is “4.5”, As one of the histories, it is shown that there is a history that “product purchase” is made at “10:00 on November 1, 2015” and the amount is “15000 yen”.

  In addition to the example shown in FIG. 4, the purchase behavior table 1211 includes, for example, information for specifying an auction site or a shopping site visited by the user or free of charge without exchange of money as information related to the purchase behavior of the user. A download history or the like of download contents may be stored. The purchase behavior stored in the purchase behavior table 1211 may be purchase behavior using electronic money, or purchase behavior using other payment methods (such as a credit card). .

(About the application history table 1212)
The application history table 1212 stores a history related to applications executed by the terminal device used by the user. Here, FIG. 5 shows an example of the application history table 1212 according to the embodiment. As illustrated in FIG. 5, the application history table 1212 includes items such as “user ID”, “application behavior evaluation”, and “application usage information”.

  “User ID” corresponds to the same item shown in FIG. “App action evaluation” indicates an evaluation value related to the action of the user using the application. In the embodiment, the application behavior evaluation is represented by a numerical value in five stages, where 5 is the highest evaluation and 1 is the lowest evaluation. The app behavior evaluation is a value obtained by evaluating a user's purchasing power and financial power based on the history of app usage. The app behavior evaluation is calculated based on, for example, the frequency of use of an app that is assumed to require a certain amount of funding for use. Apps that are expected to require a certain amount of funding when used are, for example, taxi dispatch apps, restaurant reservation apps, and the like. In addition, the app behavior evaluation is a numerical value (average value, etc.), etc. obtained from the evaluation values obtained by collecting the evaluation values obtained by evaluating the user by the provider (application provider, etc.) that provides the application used by the user. It may be.

  “Application usage information” indicates a history (log) related to the use of the user's application. The application usage information has small items such as “action date and time” and “application”.

  “Action date and time” indicates the date and time when the user uses the application. “App” indicates information for specifying an app used by the user.

  That is, in FIG. 5, as an example of the application usage information, the application behavior evaluation of the user U01 identified by the user ID “U01” is “3”, and one of the application usage history is “November 7, 2015”. "10:00" on the day indicates that the "taxi dispatch application" was used.

(About the SNS information table 1213)
The SNS information table 1213 stores information related to the SNS used by the user. Here, FIG. 6 shows an example of the SNS information table 1213 according to the embodiment. As illustrated in FIG. 6, the SNS information table 1213 includes items such as “user ID”, “SNS evaluation”, and “SNS usage information”.

  “User ID” corresponds to the same item shown in FIG. “SNS evaluation” indicates an evaluation value related to the SNS used by the user. In the embodiment, the SNS evaluation is represented by a numerical value in five stages, where 5 is the highest evaluation and 1 is the lowest evaluation. The SNS evaluation is a value obtained by evaluating the user's social credibility based on the history of SNS usage. The SNS evaluation is calculated based on, for example, the number of relationships with other users in the SNS used by the user (in the embodiment, expressed as “number of connections”), the evaluation value of the other users having the relationship, and the like. Is done.

  “SNS usage information” indicates information regarding the usage status of the SNS used by the user. The SNS usage information has small items such as “SNS name”, “number of connections”, and “connection destination evaluation”.

  “SNS name” indicates the name of the SNS used by the user. “Number of connections” indicates the number of relationships with other users in the SNS. For example, the number of connections corresponds to the number of follow users on the SNS. “Connection destination evaluation” indicates an evaluation of another user who has a connection in the SNS. For example, the connection destination evaluation is indicated by a numerical value of five levels, similar to “SNS evaluation”, and is calculated by an average value of evaluations of other users connected to the user. A high connection destination evaluation means that the SNS evaluation of other users to whom the user is connected is high, in other words, that the user is connected to many other users with high social credibility. ing.

  That is, in FIG. 6, the SNS evaluation of the user U01 identified by the user ID “U01” is “4” as an example of the SNS usage information of the user, and the SNS name “AAA” is one of the SNS usage statuses. The number of connections with other users in the SNS site is “70”, and the connection destination evaluation is “3.3”.

  In the SNS information table 1213, for example, information such as social status and income of other users connected to the user may be stored. Further, the business entity server 100 may calculate a connection destination evaluation value based on information such as social status and income of other users connected to the user. The business server 100 uses the connection destination evaluation in consideration of information such as the social status and income of other users in this way for calculating the user's own SNS evaluation, thereby accurately determining the social credibility of the user. It can be calculated well.

(About electronic money account information storage unit 122)
The electronic money account information storage unit 122 stores user electronic money account information. Here, FIG. 7 shows an example of the electronic money account information storage unit 122 according to the embodiment. As illustrated in FIG. 7, the electronic money account information storage unit 122 includes items such as “user ID”, “electronic money account”, “use history information”, and “temporary charge information”.

  “User ID” and “electronic money account” correspond to the same items shown in FIG. “Usage history information” stores the usage history of electronic money. In FIG. 7, the usage history information is represented by a concept such as “G01”, but actually, the date and time when the electronic money is used, the action type, and the like are stored as a log. Details of the usage history information will be described later.

  “Temporary charge information” indicates information related to charge executed by the business server 100 when a shortage occurs in the settlement of electronic money. The temporary charge information has small items such as “financial institution account”, “temporary charge limit”, and “account transfer date”.

  “Financial institution account” indicates information for identifying an account of a financial institution with which the user has a contract. “Temporary charge limit” indicates a limit for a predetermined period (for example, for one month) of charge executed by the operator server 100. “Account transfer date” indicates a set date for executing an account transfer from a financial institution account for an amount corresponding to the provisional charge amount when charging by the business server 100 is executed.

  That is, in FIG. 7, as an example of information regarding the electronic money account, the electronic money account of the user U01 identified by the user ID “U01” is “XXX”, the usage history information is “G01”, and the charge is executed. In this case, the financial institution account to which the temporary charge amount is transferred is “YYY”, the temporary charge limit is “10000 yen”, and the account transfer date is “25th of every month”.

  In FIG. 7, the provisional charge limit amount and the account transfer date may be automatically set on the business server 100 side or may be set according to a request from the user.

  Next, information regarding the usage history of the electronic money account will be described with reference to FIG. FIG. 8 is a diagram illustrating an example of usage history information G01 according to the embodiment. As shown in FIG. 8, the usage history information G01 stores a usage history (log) related to the electronic money of the user U01. The usage history information G01 has small items such as “use date and time”, “use mode”, “amount”, “charge balance”, and “total provisional charge amount” as “use history”.

  “Use date and time” indicates the date and time when electronic money was used. “Usage mode” indicates a mode of using electronic money, such as charging or purchasing. “Amount” indicates the amount of money traded at the time of use. In addition, in the amount item, the symbol “Δ” indicates a negative value. “Charge balance” indicates the balance charged in the electronic money account. “Total provisional charge amount” indicates the total amount charged by the business server 100.

  That is, in the example shown in FIG. 8, the following history is stored as the usage history information G01 of the electronic money account of the user U01. First, when the user U01 “charges” “5000 yen” at “10:00 on October 7, 2015”, the charge balance becomes “5000 yen”. Then, by “purchasing” a product of “3000 yen” at “8:00 on October 10, 2015”, the charge balance becomes “2000 yen”. Further, “purchased” a product of “3,000 yen” at “15:00 on October 15, 2015”, and thus the charge balance becomes “Δ1000 yen”.

  In this case, the company server 100 executes charging. The charge executed by the business server 100 is stored as a temporary charge in the usage history. That is, in the usage history, “temporary charge” of “1000 yen” is performed at “15:00 on October 15, 2015”, the charge balance becomes “0 yen”, and the total provisional charge amount is “ “1000 yen” is stored. Then, “account transfer (monthly)” for “1000 yen” is performed at “0:00 on October 25, 2015”, and the temporary charge amount of the user U01 is reset to “0 yen”. As shown in FIG. 7, since the account transfer date of the user U01 is “25th of every month”, in principle, the amount corresponding to the temporary charge amount on the 25th of every month is the financial institution account “YYY”. Will be transferred from.

  Subsequently, the user U01 “charges” “4000 yen” at “8:00 on November 20, 2015”, and the charge balance is “4000 yen”. 5,000 yen ". Then, by “purchasing” a product of “10000 yen” at “13:00 on November 22, 2015”, the charge balance becomes “Δ6000 yen”. In this case, the company server 100 executes charging. That is, in the usage history, “tentative charge” of “6000 yen” is performed at “13:00 on November 22, 2015”, the charge balance becomes “0 yen”, and the total provisional charge amount is “ “11,000 yen” is stored.

  Here, the business entity server 100 determines that the total provisional charge exceeds the provisional charge limit “10000 yen”. Then, when the provisional charge limit is exceeded, the business entity server 100 executes the account transfer even before the set account transfer date. For example, the company server 100 requests account transfer of an amount corresponding to the temporary charge limit. Then, “account transfer (limit amount)” for “10000 yen” is performed at “13:05 on November 22, 2015”, and “10000 yen” is calculated from the total temporary charge amount of the electronic money account of the user U01. Deducted. As a result, the total temporary charge amount is “1000 yen”.

(About the control unit 130)
In the control unit 130, for example, various programs (corresponding to an example of an execution program) stored in a storage device inside the operator server 100 work on the RAM by a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or the like. This is realized by being executed as a region. The control unit 130 is realized by an integrated circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

  As illustrated in FIG. 2, the control unit 130 according to the embodiment includes an acquisition unit 131, a calculation unit 132, a settlement unit 133, a charge execution unit 134, and a notification unit 135, and information processing described below. Realize or execute the functions and operations of The internal configuration of the control unit 130 is not limited to the configuration illustrated in FIG. 2, and may be another configuration as long as the information processing described later is performed. In addition, the connection relationship between the processing units included in the control unit 130 is not limited to the connection relationship illustrated in FIG. 2, and may be another connection relationship.

(About the acquisition unit 131)
The acquisition unit 131 acquires information related to electronic money used by the user. For example, the acquisition unit 131 acquires identification information for specifying an electronic money account when electronic money is used. Further, the acquisition unit 131 acquires usage information when electronic money is used. That is, the acquisition unit 131 acquires information related to the mode (charge, use, etc.) and amount of money used for electronic money.

  In addition, the acquisition unit 131 acquires user information that is information related to a user who uses electronic money. Specifically, the acquisition unit 131 acquires, as user information, identification information for identifying a user, user attribute information, a user's action history on the network, and the like. For example, the acquisition unit 131 acquires an action history on the user's network via an external information processing apparatus (for example, a web server accessed by the user). In addition, when the electronic money is used via the user terminal 10, the acquisition unit 131 may acquire an action history on the user network accumulated in the user terminal 10 via the user terminal 10. Good.

  The acquisition part 131 acquires the log | history regarding the purchase action on a user's network as an action log | history on a user's network, for example. Specifically, the acquisition unit 131 acquires the purchase amount in the purchase behavior, the frequency of the purchase behavior, or the like as the purchase behavior on the network. For example, the acquisition unit 131 acquires information on the purchase behavior of the user from a service providing server such as a web server that operates a shopping site or an auction site.

  Moreover, the acquisition part 131 may acquire the log | history regarding the application performed with the user terminal 10 which a user uses. The acquisition unit 131 may acquire the usage history of the application executed on the user terminal 10 via the user terminal 10 having the electronic money function, or the usage history of the application from the application providing server that provides the application. You may get it.

  Moreover, the acquisition part 131 may acquire the information regarding at least any one of the said user's well-known degree, reputation, and a personal network in the service for social network construction which a user utilizes. The service for building a social network is, for example, an SNS service. Moreover, a user's name recognition, reputation, a personal connection, etc. are determined by SNS evaluation, the number of applications for connection from other users, the number of connections with other users, the SNS evaluation of other users, and the like.

  The acquisition unit 131 stores the acquired information in the user information storage unit 121 and the electronic money account information storage unit 122.

(About the calculation unit 132)
The calculation unit 132 calculates the user's credit rating based on the user information acquired by the acquisition unit 131. For example, the calculation unit 132 calculates the user's credit rating based on the user's action history on the network. The user's reliability is used for determination of charge execution by the operator server 100.

  For example, the calculation unit 132 calculates the purchase behavior evaluation and the auction evaluation as illustrated in FIG. 4 regarding the purchase behavior of the user. Furthermore, the calculation unit 132 calculates the user's credit rating based on the value of the purchase behavior evaluation and the auction evaluation. For example, the calculation unit 132 calculates a high degree of trustworthiness with respect to a user with a large purchase record, a user with a large purchase amount, or a user who performs an appropriate response regarding purchase. In other words, the calculation unit 132 calculates the creditworthiness of a user who has financial power and has high social credibility. With respect to the calculation method in which the calculation unit 132 evaluates purchase behavior (behavior frequency, sales amount) and the like, for example, an administrator of the business server 100 can appropriately change the design.

  In addition, the calculation unit 132 calculates an application evaluation as illustrated in FIG. 5 regarding the use of the user's application. Furthermore, the calculation part 132 calculates a user's credit rating based on the value of application action evaluation. That is, the calculation unit 132 evaluates the user based on the usage frequency of an application that is assumed to require a certain amount of financial power, and calculates the evaluation as the user's credit rating. In other words, the calculation unit 132 estimates the user's financial power based on the usage history of the user's application, and calculates the user's creditworthiness that is estimated to be high.

  Moreover, the calculation part 132 calculates SNS evaluation as shown in FIG. 6 regarding use of a user's SNS. And the calculation part 132 calculates a user's reliability based on the value of SNS evaluation. That is, the calculation unit 132 evaluates a user who has a large number of connections on the network and a user who is frequently connected to other highly evaluated users, and calculates the evaluation as the user's credit rating. In other words, the calculation unit 132 calculates a high degree of credit for a user who is estimated to have high social credibility or a user who is estimated to have a high social status.

  Note that the calculation unit 132 may use a value calculated by combining individual evaluation values such as the purchase behavior evaluation and the auction evaluation as described above as the user's reliability. In other words, the calculation unit 132 calculates the overall user trustworthiness based on various user information acquired by the acquisition unit 131. Thereby, the calculation part 132 can provide the user with a credit level accurately reflecting the user's financial power and social credibility.

(About payment unit 133)
The settlement unit 133 executes settlement processing related to electronic money. Specifically, the settlement unit 133 specifies the used electronic money account based on the information regarding the use of electronic money acquired by the acquisition unit 131. Then, the settlement unit 133 executes a settlement process in accordance with the usage mode of electronic money.

  For example, when the charging process is performed by the user, the settlement unit 133 executes a process of adding the charged amount to the charge balance of the user. Further, when the user purchases a product using electronic money, the settlement unit 133 executes a process of subtracting the purchase amount from the charge balance. The settlement unit 133 stores the processing history in the electronic money account information storage unit 122 when the settlement process is performed.

(About charge execution unit 134)
The charge execution unit 134 uses the electronic money used by the user without receiving an operation from the user based on the user information acquired by the acquisition unit 131 when the balance of the electronic money used by the user is insufficient. Perform the charge. Specifically, the charge execution unit 134 determines whether or not it is possible to charge the electronic money account used by the user based on the user's credit level calculated by the calculation unit 132. The execution unit 134 executes the charge when it is determined that the charge can be executed, that is, when the user has a predetermined credit rating. For example, the execution unit 134 executes a charge (temporary charge) for changing over the shortage of electronic money used by the user within a range of an amount corresponding to the user's credit rating.

  The charge execution unit 134 may rank the user according to the user's credit rating and determine a provisional charge limit amount according to the rating. For example, the charge execution unit 134 sets a user having a credit rating of “5” as the highest rating, and sets the provisional charge limit as “50000 yen”. In addition, for example, the charge execution unit 134 sets a user with a credit rating of “1” as the lowest rating, and sets a temporary charge limit to “0 yen”, that is, a user who does not accept a temporary charge.

  The charge execution unit 134 may pay the store the amount of money that has been redeemed for charging by the business server 100 at a predetermined timing. Note that the charge execution unit 134 may deposit the amount of money that has been redeemed and the amount of money that has been used with normal electronic money at the same time, or may deposit money at different timings.

  In addition, the charge execution unit 134 requests the user to repay the charged amount when the total amount of charged amounts reaches a predetermined amount, or at a preset timing for each predetermined period.

  In this case, the charge execution unit 134 may request the account transfer for the user who has executed the charge in cooperation with the financial institution server 40 instead of requesting the user to repay. That is, the charge execution unit 134 identifies the user's financial institution account based on the user information acquired by the acquisition unit 131. Then, when the total provisional charge amount exceeds the provisional charge limit amount set for the user, the charge execution unit 134 performs an account transfer for compensating the provisional charge amount to the financial institution server 40. Request. Even if the charge execution unit 134 does not exceed the temporary charge limit amount, the charge execution unit 134 requests an account transfer to cover the temporary charge amount at a predetermined timing (for example, once a month). May be.

(About the notification unit 135)
The notification unit 135 notifies various information. For example, when the electronic money is settled, the notification unit 135 notifies the user to that effect. In addition, when the charge execution unit 134 requests the financial institution server 40 for account transfer, the notification unit 135 notifies the financial institution server 40 of that fact. In addition, when the account transfer is executed, the notification unit 135 notifies the user to that effect.

[3. Processing procedure)
Next, with reference to FIG. 9, a processing procedure performed by the operator server 100 according to the embodiment will be described. FIG. 9 is a flowchart illustrating a processing procedure performed by the operator server 100 according to the embodiment.

  As illustrated in FIG. 9, the acquisition unit 131 related to the provider server 100 determines whether or not payment by electronic money has been accepted (step S <b> 101). If the payment by electronic money is not accepted (step S101; No), the acquisition unit 131 waits until it is accepted.

  On the other hand, when accepting payment by electronic money (step S101; Yes), the acquisition unit 131 acquires information regarding the use of electronic money and identifies a user who uses the electronic money (step S102).

  Then, the settlement unit 133 determines whether or not the amount to be settled exceeds the charge amount for the electronic money account of the user who uses the electronic money (step S103). If the amount to be settled does not exceed the charge amount (step S103; No), the settlement unit 133 executes a settlement process with the charge amount (step S105).

  On the other hand, when the amount to be settled exceeds the charge amount (step S103; Yes), the charge execution unit 134 executes settlement by provisional charge (step S104). That is, the charge execution unit 134 completes the settlement without causing an error even if the settlement amount exceeds the current charge amount by charging the shortage amount.

  Then, the charge execution unit 134 determines whether or not the total temporary charge amount generated by the execution of the charge exceeds the temporary charge limit amount (step S106). When the total provisional charge amount exceeds the provisional charge limit amount (step S106; Yes), the charge execution unit 134 requests account transfer from the financial institution server 40 (step S107).

  When the total of the temporary charge amount does not exceed the temporary charge limit amount (step S106; No), when the settlement is completed within the current charge amount charged in advance by the user (step S105), the financial institution server 40 In any case, the charge execution unit 134 updates the electronic money account information (step S108).

[4. (Modification)
The provider server 100 according to the above-described embodiment may be implemented in various different forms other than the above-described embodiment. Therefore, in the following, another embodiment of the provider server 100 will be described.

[4-1. (Use of electronic money)
In the above embodiment, an example in which the user U01 uses electronic money via the user terminal 10 has been described. However, a user who uses electronic money may not necessarily use electronic money via a terminal device. For example, the user may use an IC (Integrated Circuit) card having an electronic money function.

  In this case, when the IC card is used, the business server 100 specifies the user based on the identification information acquired from the IC card. The business entity server 100 associates the electronic money account information stored in the user information storage unit 121 with the user ID and the user's credit rating. Then, when there is a shortage in the settlement of electronic money, the business server 100 executes charging according to the associated user's credit rating.

  In this case, for example, at the time of registering an electronic money account, the business entity server 100 stores information in which identification information acquired from an IC card is associated with a terminal device that a user uses on a daily basis. Then, the business server 100 calculates a credit rating based on the user's behavior history acquired from the terminal device that the user uses on a daily basis, and holds the calculated credit score. Then, at the time when the electronic money is used via the IC card, the business server 100 specifies the user based on the identification information of the IC card, and acquires the reliability corresponding to the specified user. Then, the business operator server 100 performs charging based on the acquired reliability.

  In this way, the business operator server 100 can identify a user who uses electronic money and obtain the user's credit rating without using a terminal device. As a result, the business server 100 can flexibly settle the shortage of electronic money according to various situations.

  Note that the business server 100 may use electronic money without going through a terminal device or the like, and may charge even if the credit rating based on the action history on the network regarding the specified user is not acquired. Good. For example, when the electronic money is used, the business server 100 can acquire the usage history of the electronic money related to the user. Then, for example, the operator server 100 determines that there has been no delay in the account transfer of the temporary charge amount, and has continued to use a certain amount of money or more, and executes the charge. You may do it.

[4-2. User information)
In the said embodiment, the user information which the provider server 100 acquires was demonstrated. Here, the business entity server 100 may acquire information other than the user information exemplified in the above-described embodiment, and may execute charging based on the acquired information.

  For example, the business entity server 100 may acquire a mail sent by the user terminal 10, a message posted to a website, an SNS service, or the like. Then, the business server 100 performs morphological analysis on the acquired mail and the like. Then, the business server 100 calculates the user's credit rating based on the appearance ratio of words appearing in e-mails transmitted by the user.

  For example, the business entity server 100 can calculate a low credit rating for a user who frequently utters words used in a debt relationship such as “cashing”. On the other hand, the company server 100 can calculate a high degree of trustworthiness for users who frequently utter words used for fund procurement, such as “investment”. Moreover, the provider server 100 may analyze not only a user whose credit is to be calculated, but also a message or the like issued by another user connected through the SNS. If the word such as “caching” frequently appears in the messages of other users who are connected to the user whose credit is to be calculated, the business server 100 also determines the user whose credit is to be calculated, It may be estimated that the social credibility is low, and the credibility is calculated low.

  Further, the business entity server 100 may acquire not only text information such as e-mail but also image information transmitted from the user and other connected users. Then, the business server 100 analyzes the image information, and calculates the user's reliability based on information such as the location shown in the image and the user who is shown at the same time. For example, the business entity server 100 analyzes that the place indicated in the image is a place where a wealthy class tends to gather based on the image information. In this case, the business operator server 100 may estimate that the user has high social credibility and calculate a high degree of trust.

  Further, the operator server 100 may acquire a search query posted from a user to a search site, a search service application, or the like. And the provider server 100 analyzes the tendency of the word posted from a user like the above. Then, the business server 100 may calculate the user's reliability based on the tendency of words posted as a search query.

[4-3. Application information)
In the embodiment described above, the provider server 100 has shown an example of acquiring information related to an application used in the user terminal 10. Here, the business entity server 100 may also acquire information other than the application information exemplified in the above embodiment, and execute charging based on the acquired information.

  For example, the business entity server 100 acquires position information of the user terminal 10 via an application used in the user terminal 10. Then, the business entity server 100 may calculate the user's reliability based on the acquired position information. For example, the provider server 100 can estimate the living area of the user who uses the user terminal 10 by acquiring the position information. Then, the business server 100 calculates the user's credibility based on the land price in the user's living area, the land rank set in advance by the administrator of the business server 100, and the like. Specifically, the business entity server 100 calculates a high degree of credit for a user who uses a land with a high rank as a living area, assuming that the social credibility is high.

  In addition, the business operator server 100 may calculate the user's reliability by combining the position information as described above with a use history of a taxi dispatch application or the like. For example, it is assumed that the business server 100 has acquired information that the user frequently uses a taxi dispatch application at a position estimated as a daytime living area of the user. In this case, the business server 100 estimates that the user has a relatively high funding power and calculates a high degree of trust because the user is a regular employee and is a person who frequently uses a taxi.

  Moreover, the provider server 100 may evaluate the user based on the user's behavior acquired through the application. For example, among applications executed on the user terminal 10, there are applications that realize business between individuals. In this case, the business entity server 100 may estimate that the social credibility is high with respect to a user who provides a product to other users via an application, and may calculate a high credit rating. In other words, the operator server 100 may acquire information related to services provided by the user on the network, and calculate the user's credit rating based on the acquired information.

  As described above, the provider server 100 acquires various information via the application used by the user terminal 10. Moreover, the provider server 100 can calculate the user's reliability by combining the acquired information in various ways. Thereby, since the operator server 100 can calculate a user's trustworthiness appropriately, it can respond flexibly, such as accepting many temporary charge amounts with respect to a reliable user.

[4-4. Execution system devices]
Each device included in the execution system 1 may be realized by various modifications. For example, the store terminal 30 may be realized by a plurality of terminal devices instead of a single terminal device. For example, the store terminal 30 may be realized by a user terminal 10 that uses an electronic money function or a reader that reads an IC card, and a server that transmits the read information to the business server 100. Further, the store provided with the store terminal 30 is not limited to a store in the real world, and may be a store on-line. That is, the processing by the execution system 1 according to the embodiment may be used for payment such as online shopping as well as payment at an actual store.

[4-5. (Selected by user)
In the above-described embodiment, the example is shown in which the business server 100 determines whether or not to execute charging based on the user's credit rating. However, the business operator server 100 may accept a setting from the user in advance as to whether or not to permit the charge processing by the business operator server 100. Further, the business server 100 may not only set a limit according to the creditworthiness of the user, but also accept a setting of a desired limit from the user for the limit of the temporary charge. In this way, the business operator server 100 can remove the anxiety of a user who is concerned about using too much electronic money in an unpaid state by accepting the setting of the charge limit amount from the user.

[5. Others]
In addition, among the processes described in the above embodiment, all or part of the processes described as being automatically performed can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedures, specific names, and information including various data and parameters shown in the document and drawings can be arbitrarily changed unless otherwise specified.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured.

  For example, the user information storage unit 121 and the electronic money account information storage unit 122 illustrated in FIG. 2 may be stored in an external storage server or the like without being held by the business server 100. In this case, the business entity server 100 acquires user information, electronic money account information, and the like by accessing the storage server.

  In addition, for example, the above-described business server 100 has a front-end server side that mainly executes exchanges with external devices such as acquiring information related to the use of electronic money and receiving user information from the user terminal 10. Alternatively, it may be distributed to the back-end server that executes the credit calculation process and the charge process.

[6. Hardware configuration)
Moreover, the provider server 100 according to the above-described embodiment is realized by a computer 1000 having a configuration as shown in FIG. 10, for example. FIG. 10 is a hardware configuration diagram illustrating an example of a computer 1000 that implements the functions of the operator server 100. The computer 1000 includes a CPU 1100, RAM 1200, ROM 1300, HDD 1400, communication interface (I / F) 1500, input / output interface (I / F) 1600, and media interface (I / F) 1700.

  The CPU 1100 operates based on a program stored in the ROM 1300 or the HDD 1400 and controls each unit. The ROM 1300 stores a boot program executed by the CPU 1100 when the computer 1000 is started up, a program depending on the hardware of the computer 1000, and the like.

  The HDD 1400 stores a program executed by the CPU 1100, data used by the program, and the like. The communication interface 1500 receives data from other devices via the communication network 500 and sends the data to the CPU 1100, and transmits data generated by the CPU 1100 to other devices via the communication network 500.

  The CPU 1100 controls an output device such as a display and a printer and an input device such as a keyboard and a mouse via the input / output interface 1600. The CPU 1100 acquires data from the input device via the input / output interface 1600. Further, the CPU 1100 outputs the data generated via the input / output interface 1600 to the output device.

  The media interface 1700 reads a program or data stored in the recording medium 1800 and provides it to the CPU 1100 via the RAM 1200. The CPU 1100 loads such a program from the recording medium 1800 onto the RAM 1200 via the media interface 1700, and executes the loaded program. The recording medium 1800 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase change rewritable disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory. Etc.

  For example, when the computer 1000 functions as the provider server 100, the CPU 1100 of the computer 1000 implements the function of the control unit 130 by executing a program loaded on the RAM 1200. In addition, each data in the storage unit 120 is stored in the HDD 1400. The CPU 1100 of the computer 1000 reads these programs from the recording medium 1800 and executes them, but as another example, these programs may be acquired from other devices via the communication network 500.

[7. effect〕
As described above, the business entity server 100 according to the embodiment includes the acquisition unit 131 and the charge execution unit 134 (an example of an execution unit). The acquisition unit 131 acquires user information that is information about a user who uses electronic money. The charge execution unit 134 is used by the user without receiving an operation from the user based on the user information acquired by the acquisition unit 131 when the charge balance is insufficient in the settlement of the electronic money used by the user. To charge the electronic money account.

  As described above, the business server 100 according to the embodiment charges the user based on the user information, so that the user is charged with a new charge process even when the charge amount is insufficient at the time of settlement. To complete the payment process. In other words, according to the business server 100, the amount of shortage of electronic money can be flexibly changed according to various situations without imposing a special effort on the user and without being restricted by the use of a specific terminal device or the like. Settlement can be made.

  Further, the business server 100 further includes a calculation unit 132 that calculates the user's credit rating based on the user information acquired by the acquisition unit 131. Further, the charge execution unit 134 determines whether or not it is possible to execute charge on the electronic money account used by the user based on the user's credit level calculated by the calculation unit 132. In addition, the charge execution unit 134 charges the electronic money used by the user within a range of an amount corresponding to the user's credit level calculated by the calculation unit 132.

  As described above, the business server 100 according to the embodiment calculates the reliability based on the user information. Then, the business server 100 determines whether or not to execute the charge based on the credit rating, or executes an amount of charge corresponding to the credit rating. For this reason, the enterprise server 100 can appropriately determine the user to be charged and the amount to be charged.

  Moreover, the acquisition part 131 acquires the action history on a user's network as user information. The calculating unit 132 calculates the user's credit rating based on the user's action history on the network acquired by the acquiring unit 131.

  As described above, the business server 100 according to the embodiment calculates the user's reliability based on the user's daily behavior. For this reason, the operator server 100 enjoys the convenience of charge processing by the operator server 100 without requiring the user to provide the terminal with credit information or to make a special contract with a financial institution. Can be made.

  Moreover, the acquisition part 131 acquires the log | history regarding the purchase action on a user's network. The calculation unit 132 calculates the credit rating of the user based on the purchase amount in the purchase behavior acquired by the acquisition unit 131 or the frequency of purchase behavior.

  As described above, the business server 100 according to the embodiment calculates the credit rating based on the purchase behavior of the user that can be acquired from, for example, a web server that operates a shopping site. For example, the business entity server 100 can estimate that a user who frequently obtains a purchase activity log has high funding power and allows a large amount of temporary charge. For this reason, according to the provider server 100, an appropriate charge can be executed even for a user who has not acquired credit information or the like in the user's financial institution.

  In addition, the acquisition unit 131 acquires a history related to an application executed on the user terminal 10 used by the user. The calculation unit 132 calculates the user's credit rating based on the history regarding the application acquired by the acquisition unit 131.

  As described above, the business entity server 100 according to the embodiment may calculate the credit rating based on the history of the user's application usage. In other words, the business operator server 100 may determine that a user with a high frequency of use of a specific app is highly funded by analyzing the usage history of the app and allow a large amount of temporary charge. it can. For this reason, the provider server 100 can execute an appropriate charge for various users.

  The acquisition unit 131 acquires information related to at least one of the user's name recognition, reputation, and network in a service for building a social network used by the user. The calculation unit 132 calculates the trustworthiness of the user based on information on at least one of the user's name recognition, reputation, and personal connections in the service for building a social network acquired by the acquisition unit 131.

  As described above, the business operator server 100 according to the embodiment may calculate the user's reliability based on the information in the service for building the social network of the user such as SNS. That is, the company server 100 allows a large amount of provisional charge for a user who has a lot of connections with SNS or the like, or a user who has a high evaluation from the surroundings, as having high financial power and social credibility. Judgment can be made. For this reason, the provider server 100 can execute an appropriate charge for various users.

  In addition, the acquisition unit 131 acquires information related to a service provided by the user on the network. The calculation unit 132 calculates the user's credit rating based on the information about the service provided by the user on the network acquired by the acquisition unit 131.

  As described above, the business server 100 according to the embodiment may acquire information on whether or not the user himself is a user who provides some service, and may calculate the user's reliability based on the acquired information. For example, when the user himself / herself provides a service, the business server 100 may be able to refer to the sales and capital power of the service. The business server 100 can determine the limit of the temporary charge amount and whether or not the charge can be executed regardless of the credit information of the financial institution or the like by calculating the user's credit rating based on the acquired information. it can. As described above, the business operator server 100 can execute charging according to various users.

  In addition, the charge execution unit 134 requests the user to repay the charged amount when the total amount generated in the executed charge reaches a predetermined amount.

  As described above, the business operator server 100 sets a certain limit for charging, and requests the user who has reached the limit to repay. For example, the operator server 100 sets a limit amount according to the user's credit rating. Thereby, even if the provider server 100 executes the charge, it is possible to perform smooth operation without causing a repayment delay. In addition, the business server 100 recognizes a temporary charge up to a certain amount so that, for example, the user has the trouble of generating a repayment request for each temporary charge or generating a fee for each temporary charge. You can avoid losing it. For this reason, the provider server 100 can allow the user to enjoy convenience as well as smooth operation.

  In addition, the charge execution unit 134 requests the user to repay the amount generated in the executed charge for each predetermined period.

  In this way, the business operator server 100 may make a request for repayment at a predetermined timing in charging. As a result, even if the operator server 100 charges the user, the user only has to pay the temporary charge amount on a certain date. Therefore, even if a small amount of payments frequently occurs, the user is troublesome. You do n’t have to. In addition, even if the user has an account at a financial institution that cannot be withdrawn immediately, the user can take a flexible measure such as paying back on a predetermined day of the month. Thus, according to the provider server 100, it is possible to make a settlement (request for repayment) of the temporary charge amount flexibly according to various situations.

  As described above, some of the embodiments of the present application have been described in detail based on the drawings. It is possible to implement the present invention in other forms with improvements.

  Further, the provider server 100 described above may be realized by a plurality of server computers, and depending on the function, an external platform or the like may be realized by calling an API (Application Programming Interface) or network computing. Can be changed flexibly.

  Further, “section (module, unit)” described in the claims can be read as “means”, “circuit”, and the like. For example, the acquisition unit can be read as acquisition means or an acquisition circuit.

DESCRIPTION OF SYMBOLS 1 Execution system 10 User terminal 30 Store terminal 40 Financial institution server 100 Business server 110 Communication part 120 Storage part 121 User information storage part 122 Electronic money account information storage part 130 Control part 131 Acquisition part 132 Calculation part 133 Settlement part 134 Charge execution Part 135 Notification part

Claims (12)

An acquisition unit that acquires user information that is information about a user who uses electronic money;
When there is a shortage of charge balance in the settlement of electronic money used by the user, based on the user information acquired by the acquisition unit, to the electronic money account used by the user without receiving an operation from the user An execution unit for executing the charge of
An execution device comprising: Based on the user information acquired by the acquisition unit, a calculation unit that calculates the credit rating of the user,
Further comprising
The execution unit is
Based on the user's credit level calculated by the calculation unit, it is determined whether or not it is possible to execute charging to the electronic money account used by the user,
The execution device according to claim 1. The execution unit is
In the range of the amount according to the user's credit level calculated by the calculation unit, the electronic money account used by the user is charged.
The execution device according to claim 2. The acquisition unit
As the user information, obtain an action history on the network of the user,
The calculation unit includes:
Based on the behavior history of the user on the network acquired by the acquisition unit, the credit rating of the user is calculated.
The execution device according to claim 2 or 3, wherein The acquisition unit
Obtaining a history of purchasing behavior on the user's network;
The calculation unit includes:
Based on the purchase amount in the purchase behavior acquired by the acquisition unit, or the frequency of purchase behavior, to calculate the credit of the user,
The execution device according to any one of claims 2 to 4, wherein The acquisition unit
Obtain a history of applications executed on the terminal device used by the user,
The calculation unit includes:
Based on the history of the application acquired by the acquisition unit, to calculate the user's credit rating,
The execution device according to any one of claims 2 to 5, wherein The acquisition unit
Obtaining information on at least one of the user's name recognition, reputation, and network in the service for social network construction used by the user;
The calculation unit includes:
Calculating the user's trustworthiness based on information about at least one of the user's name recognition, reputation, and network in the service for social network construction acquired by the acquisition unit;
The execution device according to any one of claims 2 to 6, wherein The acquisition unit
Obtaining information about services provided by the user on the network;
The calculation unit includes:
Based on the information about the service provided by the user on the network acquired by the acquisition unit, the credit rating of the user is calculated.
The execution device according to any one of claims 2 to 7, wherein The execution unit is
Requesting the user to repay the charged amount when the total amount generated in the executed charge reaches a predetermined amount;
The execution device according to any one of claims 1 to 8, wherein The execution unit is
Requesting the user to repay the amount incurred in the executed charge at predetermined intervals;
The execution device according to any one of claims 1 to 9, wherein An execution method executed by a computer,
An acquisition step of acquiring user information which is information relating to a user using electronic money;
When there is a shortage of charge balance in the settlement of electronic money used by the user, based on the user information acquired by the acquisition process, the electronic money account used by the user without receiving an operation from the user An execution process for performing the charge of
The execution method characterized by including. An acquisition procedure for acquiring user information, which is information about a user who uses electronic money;
When there is a shortage of charge balance in the settlement of electronic money used by the user, based on the user information acquired by the acquisition procedure, to the electronic money account used by the user without receiving an operation from the user An execution procedure to charge
An execution program for causing a computer to execute.

Images