JP7689933B2 - Information processing device, program, and information processing method - Google Patents

Description

The present invention relates to an information processing device, a program, and an information processing method.

Patent Document 1 discloses an information processing method for outputting a list of credit card usage details to a member's terminal device.
[Prior art documents]
[Patent Documents]
[Patent Document 1] JP 2020-113081 A

In a first aspect of the present invention, an information processing device is provided. The information processing device includes a request acquisition unit that acquires, from a first provider that provides goods, data, or services to a user of a payment service, (i) a validity confirmation request requesting confirmation of the validity of the user's use of the payment service, (ii) first provider identification information for identifying the first provider, and (iii) user identification information assigned to the user by a second provider that provides the payment service. The information processing device includes, for example, (i) confirmation time information indicating the time when the request acquisition unit received the validity confirmation request and/or the time when processing for confirming validity in response to the validity confirmation request was executed, and (ii) a confirmation history generation unit that generates confirmation history information in which the user identification information and the first provider identification information acquired by the request acquisition unit are associated.

The information processing device may include a confirmation history notification unit that refers to a confirmation history storage unit that stores one or more pieces of confirmation history information generated by the confirmation history generation unit, and notifies the user of the first provider identification information included in at least a portion of the one or more pieces of confirmation history information associated with the user's user identification information. In the information processing device, the confirmation history notification unit may refer to the confirmation history storage unit and extract, from the one or more pieces of confirmation history information associated with the user's user identification information, confirmation history information whose length of time since validity was confirmed is greater than a predetermined value. The confirmation history notification unit may notify the user of the first provider identification information included in the extracted confirmation history information. In the information processing device, the confirmation history notification unit may generate detailed information indicating the user's usage status of the payment service for each period having a predetermined length. The confirmation history notification unit may notify the user of (a) the first provider identification information included in at least a portion of the confirmation history information, and (b) the detailed information.

In the above information processing device, the confirmation history notification unit may (c) transmit to the information processing terminal of the user a first command to cause the information processing terminal used by the user to execute a process of transmitting to the information processing device (i) selection information indicating the first provider identification information selected by the user from among the first provider identification information notified to the user, and (ii) a restriction request requesting the information processing device to restrict the use of the payment service in a transaction between the first provider identified by the first provider identification information indicated by the selection information and the user. In the above information processing device, the confirmation history notification unit may (d) transmit to the information processing terminal of the user a second command to cause the information processing terminal used by the user to execute a process of transmitting to the information processing device (i) selection information indicating the first provider identification information selected by the user from among the first provider identification information notified to the user, and (ii) a deletion request requesting the information processing device to cause the first provider identified by the first provider identification information indicated by the selection information to delete or not use information related to the user's payment service.

In the above information processing device, the payment service may be a service that provides credit card payments, or a payment agency service that uses credit card payments. In the above information processing device, the validity confirmation request may be a request to confirm the validity of a credit card distributed to the user. In the above information processing device, the confirmation history generation unit may generate confirmation history information when (i) the validity confirmation request requests confirmation of the validity of a credit card and does not request securing of a credit line for the user's payment service, or (ii) when a credit request is not made to secure a credit line for the user's payment service within a predetermined period of time after the request acquisition unit acquires the validity confirmation request.

In a second aspect of the present invention, an information processing method is provided. Each step of the above information processing method is executed, for example, by a computer. The above information processing method includes, for example, a request acquisition step of acquiring, from a first provider that provides goods, data, or services to a user of a payment service, (i) a validity confirmation request requesting confirmation of the validity of the user's use of the payment service, (ii) first provider identification information for identifying the first provider, and (iii) user identification information assigned to the user by a second provider that provides the payment service. The above information processing method includes, for example, (i) confirmation time information indicating the time when the validity confirmation request was received in the request acquisition step and/or the time when processing for confirming validity was performed in response to the validity confirmation request, and (ii) a confirmation history generation step of generating confirmation history information in which the user identification information and the first provider identification information acquired in the request acquisition step are associated.

In a third aspect of the present invention, a program is provided. The program may be a program for causing a computer to function as the information processing device according to the first embodiment. The program may be a program for causing a computer to execute the information processing method according to the second embodiment. A computer-readable medium for storing the program may be provided. The computer-readable medium may be a non-transitory computer-readable medium. The computer-readable medium may be a computer-readable recording medium.

Note that the above summary of the invention does not list all of the necessary features of the present invention. Also, subcombinations of these features may also be inventions.

1 illustrates an example of a system configuration of a payment system 100. 1 illustrates an example of an information processing method in a payment system 100. An example of a credit card statement 300 is shown in schematic form. 13 illustrates an outline of another example of an information processing method in the payment system 100. 2 shows an example of the internal configuration of the payment service management server 110. 2 shows an example of a data structure of data stored in a storage unit 116. An example of the system configuration of a computer 3000 is shown in schematic form.

The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the invention according to the claims. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention. In the drawings, the same reference numbers are used for the same or similar parts, and duplicate explanations may be omitted.

(Overview of payment system 100)
1 shows an example of a system configuration of a payment system 100. In this embodiment, in order to facilitate understanding of the payment system 100, the details of the payment system 100 are described using as an example a commercial transaction between a user 20 who is a member of a credit card payment service provided by a payment service provider 40 and a seller 30 who is an affiliated store of the credit card payment service. In this embodiment, in order to facilitate understanding of the payment system 100, the details of the payment system 100 are described using as an example a case in which the user 20 uses an electronic commerce site (sometimes referred to as an EC site) operated by the seller 30 to purchase goods, data, or services (sometimes referred to as products) from the seller 30.

As described above, in this embodiment, the user 20 purchases a product sold by the seller 30. The user 20 pays for the product to the seller 30 using a payment service provided by the payment service provider 40. In this embodiment, the seller 30 provides the product to the user 20. In this embodiment, the payment service provider 40 provides a payment service to the user 20 and the seller 30.

Some EC sites offer a service that allows for quick payment by having user 20 register credit card information (sometimes called card information) on the EC site before the user 20 uses his/her credit card to purchase a product on the EC site, thereby enabling the user 20 to make a payment quickly. Examples of card information include a membership number (sometimes called a card number), the credit card expiration date, and a security code.

For example, if user 20 registers card information on an EC site that is used infrequently, the card information remains registered on the EC site even if user 20 has not used the EC site for a relatively long period of time. As a result, user 20 continues to be exposed to the risk of card information being leaked, for example.

However, if a relatively long time has passed since user 20 registered their credit card information on an EC site, or if user 20 has registered their credit card information on multiple EC sites, it is not easy for user 20 to grasp the registration status of their card information. In addition, since it is relatively time-consuming to access an EC site and cancel the registration of their card information, the number of users 20 who go to the trouble of accessing an EC site to cancel the registration of their card information remains relatively small. In addition, operators of EC sites have no motivation to encourage users 20 to cancel the registration of their card information.

The inventors therefore focused on the fact that when the credit card information of the user 20 is registered, a process for confirming the validity of the credit card (sometimes referred to as a validity check) is executed, and constructed the payment system 100 according to this embodiment. According to the payment system 100 according to this embodiment, for example, when the card information of the user 20 is registered on a website operated by the seller 30, the payment service management server 110 operated by the payment service provider 40 stores the identification information of the seller 30 in association with the identification information of the user 20. As a result, when the payment service management server 110 notifies the user 20 of the credit card usage details, for example, it can notify the user 20 of information related to the seller 30 who holds the card information.

The identification information of the user 20 may be identification information assigned to the user 20 by the payment service provider 40. Examples of the identification information of the user 20 include a credit card membership number or card number.

In addition, in this embodiment, the payment system 100 can, based on instructions from the user 20, restrict the use of a credit card at a seller 30 designated by the user 20, among one or more sellers 30 that hold the card information of the user 20. This can prevent fraudulent use of credit cards. For example, even if the account of the user 20 at the website of the above-mentioned seller 30 is fraudulently used, payments using the credit card registered at that website are restricted.

(Overview of each part related to the payment system 100)
In this embodiment, the payment system 100 includes a payment service management server 110. The payment system 100 may include a transaction management system 120. In this embodiment, the payment service management server 110 includes a registration processing unit 112, a payment processing unit 114, and a storage unit 116. In this embodiment, the transaction management system 120 includes, for example, a website management unit 122.

Furthermore, in this embodiment, the user 20 can access the payment service management server 110 and/or the transaction management system 120 using the user terminal 22. In this embodiment, the user terminal 22 can send and receive information between the payment service management server 110 and/or the transaction management system 120 via the communication network 10. Similarly, in this embodiment, the payment service management server 110 and the transaction management system 120 can send and receive information between each other via the communication network 10.

In this embodiment, the communication network 10 transmits information. The communication network 10 may be a transmission path for wired communication, a transmission path for wireless communication, or a combination of a transmission path for wireless communication and a transmission path for wired communication. The communication network 10 includes, for example, at least one of a wireless packet communication network, the Internet, a P2P network, a dedicated line, a VPN, a power line communication line, a vehicle-to-vehicle communication line, and a road-to-vehicle communication line. The communication network 10 may include (i) a mobile communication network such as a mobile phone line network, or (ii) a wireless communication network such as a wireless MAN (e.g., WiMAX (registered trademark)), a wireless LAN (e.g., WiFi (registered trademark)), Bluetooth (registered trademark), Zigbee (registered trademark), or NFC (Near Field Communication).

In this embodiment, the user terminal 22 transmits and receives information between the payment service management server 110 and/or the transaction management system 120, for example, via the communication network 10. The user terminal 22 may be any device capable of transmitting and receiving information between other information processing devices, and the details thereof are not particularly limited. Examples of the user terminal 22 include personal computers and mobile terminals. Examples of the mobile terminal include mobile phones, smartphones, PDAs, tablets, notebook computers or laptop computers, and wearable computers.

In this embodiment, for example, when the card information of the user 20 is registered in the website management unit 122 of the seller 30, the payment service management server 110 stores the identification information of the seller 30 in association with the identification information of the user 20. This allows the payment service management server 110 to identify one or more sellers 30 that hold the card information of the user 20 for each user 20 or each credit card.

The payment service management server 110 may notify the user 20 of the identification information of one or more sellers 30 that hold the user's 20 card information. For example, when notifying the user 20 of a credit card statement, the payment service management server 110 notifies the user 20 of information regarding the sellers 30 that hold the card information. Details of the payment service management server 110 will be described later.

In this embodiment, for example, when the card information of the user 20 is registered in the website management unit 122 of the seller 30, the registration processing unit 112 associates the identification information of the seller 30 with the identification information of the user 20 and stores them in the storage unit 116. More specifically, the registration processing unit 112 generates, for example, information indicating the time when the card information of the user 20 was registered in the website management unit 122 of the seller 30 (sometimes referred to as confirmation time information), and information in which the identification information of the seller 30 and the identification information of the user 20 are associated (sometimes referred to as confirmation history information). The registration processing unit 112 stores the generated confirmation history information in the storage unit 116. Details of the registration processing unit 112 will be described later.

In this embodiment, when a product is traded between a user 20 and a seller 30, the payment processing unit 114 executes the payment for the transaction. Details of the payment processing unit 114 will be described later.

In this embodiment, the storage unit 116 stores various types of information. In one embodiment, the storage unit 116 stores information used in various types of information processing in the payment system 100. In another embodiment, the storage unit 116 stores information generated in various types of information processing in the payment system 100. Details of the storage unit 116 will be described later.

In this embodiment, the portal site management unit 118 manages websites related to payment services. The portal site management unit 118 manages the operation of a website (sometimes called a portal site) that provides users 20 with various information related to their credit cards.

In one embodiment, the portal site includes a page (e.g., a web page) for presenting usage status and/or registration status to the user 20. The portal site includes a page (e.g., a web page) for the user 20 to send various requests to the payment service management server 110.

Examples of such requests include a request to view the usage and/or registration status of a credit card (sometimes referred to as a viewing request), a request to restrict the use of a credit card with a particular seller 30 (sometimes referred to as a restriction request), and a request to have a particular seller 30 cancel the registration of card information (sometimes referred to as a cancellation request).

The specific seller 30 may be a seller 30 designated by the user 20. The seller 30 designated by the user 20 may be a seller 30 selected by the user 20 from among the sellers 30 for which the card information of the user 20 is registered.

The process for the user 20 to specify or select a specific seller 30 is executed, for example, according to the following procedure. First, the payment service management server 110 transmits to the user terminal 22 a list of sellers 30 for which the user 20's card information is registered. The user terminal 22 displays the list on a display device (not shown) of the user terminal 22. The user 20 operates the user terminal 22 to select a seller 30 from the list for which credit card usage restrictions and/or card information deregistration are to be applied. The user terminal 22 transmits identification information of the seller 30 selected by the user 20 to the payment service management server 110.

Examples of restriction requests include (i) a request to the payment service management server 110 to temporarily suspend the use of the user 20's credit card, and (ii) a request to the payment service management server 110 to temporarily reduce the credit limit of the user 20's credit card. Examples of release requests include a request to have a specific seller 30 delete card information, and a request to prevent a specific seller 30 from using card information.

As described above, the release request is sent to the payment service management server 110. The release request may be a request to have the payment service management server 110 execute processing to have the seller 30 delete the card information. The release request may be a request to have the payment service management server 110 execute processing to prevent the seller 30 from using the card information.

An example of a process for making a specific seller 30 delete card information is a process for requesting the website management unit 122 of the specific seller 30 to delete the card information. An example of a process for preventing a seller 30 from using card information is a process for requesting the website management unit 122 of the specific seller 30 to suspend use of the card information, a process for requesting measures to prevent unauthorized use and/or leakage of card information, etc.

In another embodiment, the portal site includes a page (e.g., a web page) that allows the user 20 to access one or more websites operated by one or more sellers 30 via the portal site. According to this embodiment, the payment service management server 110 can obtain information that the user 20 inputs to the website operated by the seller 30.

As a result, for example, when the card information of the user 20 is registered in the website management unit 122 of the seller 30, the payment service management server 110 can associate the identification information of the seller 30 with the identification information of the user 20. Furthermore, when the payment service management server 110 receives a cancellation request from the user 20, it can execute a process to cancel the registration of the card information on the website operated by the seller 30 that is the subject of the cancellation request.

In this embodiment, the transaction management system 120 manages transactions between the user 20 and the seller 30. The transaction management system 120 may manage transactions in a physical store, or may manage transactions on an EC site. The transaction management system 120 may include a store terminal located in the physical store in addition to the website management unit 122. The store terminal may be compatible with various payment services.

In this embodiment, the website management unit 122 manages the operation of a website through which the seller 30 sells products. In one embodiment, the website management unit 122 manages the operation of an EC site. In another embodiment, the website management unit 122 manages the operation of a website to support transactions in a physical store.

(Specific configuration of each part of the payment system 100)
Each part of the payment system 100 may be realized by hardware, software, or hardware and software. Each part of the payment system 100 may be realized, at least in part, by a single server or by multiple servers. Each part of the payment system 100 may be realized, at least in part, on a virtual machine or a cloud system. Each part of the payment system 100 may be realized, at least in part, by a personal computer or a mobile terminal. Examples of the mobile terminal include a mobile phone, a smartphone, a PDA, a tablet, a notebook computer or laptop computer, and a wearable computer. Each part of the payment system 100 may store information using a distributed ledger technology such as a blockchain or a distributed network.

When at least some of the components constituting the payment system 100 are realized by software, the components realized by the software may be realized by starting software or a program that defines the operation of the components in an information processing device of a general configuration. The information processing device of the general configuration described above may include (i) a data processing device having a processor such as a CPU or GPU, a ROM, a RAM, a communication interface, etc., (ii) input devices such as a keyboard, a pointing device, a touch panel, a camera, a voice input device, a gesture input device, various sensors, a GPS receiver, etc., (iii) output devices such as a display device, a voice output device, a vibration device, etc., and (iv) storage devices such as memory, HDD, SSD, etc. (including external storage devices).

In the information processing device of the above general configuration, the above data processing device or storage device may store the above software or program. The above software or program, when executed by a processor, causes the above information processing device to perform the operations defined by the software or program. The above software or program may be stored in a non-transitory computer-readable recording medium. The above software or program may be a program for causing a computer to function as the payment system 100 or a part thereof. The above software or program may be a program for causing a computer to execute information processing in the payment system 100 or a part thereof.

The information processing method in the payment system 100 or a part thereof, for example, includes a request acquisition step of acquiring from a first provider that provides goods, data, or services to a user of a payment service (i) a validity confirmation request requesting confirmation of the validity of the user's use of the payment service, (ii) first provider identification information for identifying the first provider, and (iii) user identification information assigned to the user by a second provider that provides the payment service. The above information processing method includes, for example, (i) confirmation time information indicating the time when the validity confirmation request was received in the request acquisition step and/or the time when processing for confirming validity in response to the validity confirmation request was executed, and (ii) a confirmation history generation step of generating confirmation history information in which the user identification information and the first provider identification information acquired in the request acquisition step are associated. Each step of the above information processing method may be executed by a computer.

The user 20 may be an example of a user of the payment service. The user terminal 22 may be an example of an information processing terminal used by the user. The seller 30 may be an example of a first provider. The payment service provider 40 may be an example of a second provider. The payment service management server 110 may be an example of an information processing device. The registration processing unit 112 may be an example of an information processing device. The storage unit 116 may be an example of a confirmation history storage unit. The card information and a part of it may be an example of information related to the user's payment service. The identification information of the user 20 may be an example of user identification information. The identification information of the seller 30 may be an example of first provider identification information.

(An example of another embodiment)
In this embodiment, the details of the payment system 100 have been described by taking as an example a case in which the payment service provider 40 provides a service for providing credit card payments. However, the payment system 100 is not limited to this embodiment. In other embodiments, the payment service provider 40 may provide a payment agency service. The above-mentioned payment agency service may be a payment agency service that utilizes credit card payments.

Figure 2 shows an example of an information processing method in the payment system 100. An example of a card information registration process and a confirmation history information generation process will be described using Figure 2. Also, an example of a payment process will be described using Figure 2.

According to this embodiment, first, in step 220 (step may be abbreviated as S), the transaction management system 120 performs a card information registration process, and the payment service management server 110 performs a confirmation history information generation process.

Then, in S240, a payment process is performed using a credit card. In this embodiment, the payment process is performed one or more times during a period of a predetermined length (sometimes referred to as a billing period). In addition, in S260, a process is performed to create a usage statement for each billing period, showing the credit usage status during that billing period.

The usage details created in S260 are notified to the user 20. In one embodiment, the usage details are prepared on paper and mailed to the user 20. The paper usage details may include the URL of the portal site operated by the portal site management unit 118 and/or a code or figure in which the above URL is encoded. In another embodiment, the usage details are presented to the user 20 as electronic data such as a web page. For example, electronic data of the usage details of the user 20 is sent to the user terminal 22 of the user 20. The URL of the web page of the usage details of the user 20 may be sent to the user terminal 22 of the user 20.

As shown in FIG. 2, according to S220 of this embodiment, first, in S222, a registration request for requesting the transaction management system 120 to register the card information of the user 20 is sent from the user terminal 22 to the transaction management system 120. When the transaction management system 120 accepts the registration request, the user 20 operates the user terminal 22 to send the card information of the user 20 to the transaction management system 120.

Furthermore, when the transaction management system 120 accepts the registration request, the above-mentioned validity check is performed in S224. For example, first, the transaction management system 120 transmits information (sometimes referred to as a validity confirmation request) to the payment service management server 110 requesting that the validity of the use of the payment service by the user 20 be confirmed. More specifically, the transaction management system 120 transmits to the payment service management server 110 the identification information of the user 20 and a request to the payment service management server 110 to confirm the validity of the credit card distributed to the user 20.

When the payment service management server 110 receives a validity confirmation request, the registration processing unit 112 of the payment service management server 110 refers to the information stored in the storage unit 116 to confirm the validity of the user 20's credit card. The registration processing unit 112 also sends information indicating the confirmation result to the transaction management system 120.

More specifically, the registration processing unit 112 refers to the database stored in the storage unit 116 to check whether or not there is a record associated with the identification information of the user 20. If the above database does not store a record associated with the identification information of the user 20, the registration processing unit 112 transmits information indicating that the credit card of the user 20 is invalid to the transaction management system 120.

On the other hand, if a record associated with the identification information of user 20 is stored in the above database, the payment service management server 110 refers to the record to check whether user 20's credit card has expired. If user 20's credit card has not expired, the registration processing unit 112 sends information to the transaction management system 120 indicating that user 20's credit card is valid. If user 20's credit card has expired, the registration processing unit 112 sends information to the transaction management system 120 indicating that user 20's credit card is invalid.

If the user 20's credit card is valid, in S226, the registration processing unit 112 generates confirmation history information and stores the confirmation history information in the storage unit 116. In addition, in S228, the website management unit 122 of the transaction management system 120 stores the card information of the user 20 in a storage device (not shown) of the transaction management system 120.

On the other hand, if the user 20's credit card is invalid, the registration processing unit 112 does not need to generate confirmation history information. In addition, the website management unit 122 does not need to store the card information of the user 20 in a storage device. This completes the card information registration process and confirmation history information generation process in S220.

As shown in FIG. 2, according to S240 of this embodiment, first, in S242, a payment request for settling the price of the transaction between the user 20 and the seller 30 is sent from the user terminal 22 to the transaction management system 120. When the transaction management system 120 accepts the payment request, in S244, a credit inquiry (sometimes called a credit request) is executed. More specifically, a credit approval process (sometimes called an authorization or provisional sales process) is executed, and the credit limit of the user 20's credit card is secured. As a result, a credit limit of an amount equivalent to the product price is secured for a predetermined period of time. Note that in many payment services, at this stage, the right to claim the price from the user 20 has not been generated, and the process to withdraw the product price has not been executed.

Next, in S244, sales processing (sometimes called actual sales processing) is executed. As a result, the amount equivalent to the product price secured in S242 is recorded as actual sales. This completes the payment process.

(An example of another embodiment)
In this embodiment, an example of the payment system 100 has been described, taking as an example a case where the processing described in relation to S224, S226, and S228 is executed when the payment service management server 110 receives a validity confirmation request. However, the payment system 100 is not limited to this embodiment. In other embodiments, (i) when the validity confirmation request requests confirmation of the validity of a credit card and does not request securing of a credit limit for the payment service of the user 20, or (ii) when the payment service management server 110 does not make a credit request within a predetermined period of time after obtaining the validity confirmation request, the processing described in relation to S224, S226, and S228 may be executed, and confirmation history information may be generated.

Figure 3 shows an example of a credit card statement 300. In this embodiment, the statement 300 includes information 320 indicating the usage status of credit card payments and information 340 indicating registration destinations with long periods of unused use. The information 320 indicating the usage status of credit card payments indicates the usage status of payment services by the user 20 for each period of a predetermined length. The information 340 indicating registration destinations with long periods of unused use indicates sellers 30 that the user 20 has not used recently, among the sellers 30 where the user's 20's card information is registered.

In an embodiment, information 320 indicating the usage status of credit card payments includes one or more records. Each record includes information for each credit card payment. Each record stores, for example, information indicating the time when the credit card payment was used, identification information of the seller 30 for which the credit card payment was used, and information indicating the product price in the transaction for which the credit card payment was used, in association with each other.

An example of information indicating the time when a credit card payment was used is the date of use. The above time may be a date, a date and time, or a time. An example of identification information of the seller 30 for which a credit card payment was used is the store name of the seller 30. An example of information indicating the product price in a transaction in which a credit card payment was used is information indicating the amount used.

Each record may include information indicating the time when the validity check was performed by the seller 30. The time may be a date, a date and time, or a time. Each record may include information for verifying the user of the credit card payment (sometimes referred to as user verification information).

Examples of user identification information include terminal identification information of the user terminal 22 that requested each payment, and the password or passphrase entered into the transaction management system 120 for each payment. An example of terminal identification information is a MAC address. The user identification information is transmitted from the transaction management system 120 to the payment service management server 110, for example, when the transaction management system 120 is able to acquire the information from the user terminal 22.

In this embodiment, the information 340 indicating the registration destinations with long unused periods is, for example, information regarding one or more sellers 30 with which the card information of the user 20's credit card is registered, and which has a period during which no transaction has been made using the credit card (sometimes referred to as an unused period) that is longer than a predetermined value. As shown in FIG. 3, the information 340 indicating the registration destinations with long unused periods includes one or more records. Each record includes various information regarding each of the one or more sellers 30.

In this embodiment, each record stores, for example, the identification information of a seller 30 that has not been used for a long period of time, information indicating the registration date of the latest card information (sometimes referred to as the latest registration date), and information indicating the registration status of the card information (sometimes referred to as the status), in association with each other. The identification information of the seller 30 may be the name of the seller 30, or may be a combination of the name, the type of business, and/or the sales format.

The information indicating the latest registration date may be information indicating the time when the validity check was last performed. Examples of embodiments of validity checks in credit card payments include (i) a form in which a validity check is performed independently without credit inquiry and sales processing, (ii) a form in which a validity check is performed during a credit inquiry, and (iii) a form in which a validity check is performed in accordance with processing to secure a credit limit. The information indicating the latest registration date may be information indicating the time when the validity check was last performed in the form in which a validity check is performed independently of the above three embodiments.

An example of a form in which a validity check is performed in accordance with a process for securing a credit limit is a form in which a validity check is performed instead of a credit inquiry in a transaction in which the credit limit cannot be secured in advance, in order to call up card information at the time the amount used is determined and sales processing is executed. Examples of transactions in which the credit limit cannot be secured in advance include rental services and sharing services, in which the amount varies depending on the duration of use or usage history.

Examples of information indicating the status include (i) a state in which the registration of the card information is maintained at the seller 30 (sometimes referred to as "registration maintained"); (ii) a state in which the use of the card information is suspended or restricted at the payment service management server 110 or the seller 30 (sometimes referred to as "use suspended" or "use restricted"); and (iii) a state in which a request to delete or deregister the card information has been notified to the seller 30. In this embodiment, after the payment service management server 110 notifies a specific seller 30 of a request to delete or deregister the card information, if the payment service management server 110 receives information indicating that the card information at the seller 30 has been deleted or the registration of the card information has been deregistered, the record relating to that specific seller 30 is not included in the information 340 indicating registration destinations that have not been used for a long period of time.

In this embodiment, the usage details 300 includes an object in which instructions are embedded to assist the user 20 when the user 20 wishes to update registration information. As shown in FIG. 3, according to this embodiment, the usage details 300 includes a column in which the above-mentioned objects are arranged for each record of information 340 indicating a registration destination that has not been used for a long period of time. Note that in other embodiments, the usage details 300 may include an object for allowing the user 20 to select a record, and an object for processing the records selected by the user 20 all at once.

For example, the usage details 300 includes an object 362 in which an instruction (sometimes called a suspension instruction) for causing the payment service management server 110 to temporarily suspend the use of the user 20's credit card is embedded. The suspension instruction includes an instruction for causing the user terminal 22 of the user 20 to execute a predetermined process.

For example, the user terminal 22 displays the usage details 300 on the display screen of the user terminal 22, whereby the usage details 300 are presented to the user 20. When the user 20 clicks on an object 362 associated with a specific seller 30 on the screen, the user terminal 22 executes a stop command.

When the stop command is executed on the user terminal 22, the user terminal 22 executes a process to send a restriction request to the payment service management server 110, which requests the payment service management server 110 to temporarily suspend the use of the user 20's credit card. At this time, the user terminal 22 may execute a process to send the above restriction request and information indicating the record corresponding to the object 362 (sometimes referred to as selection information) to the payment service management server 110. The information indicating the record corresponding to the object 362 may be identification information of the seller 30 contained in that record. When the payment service management server 110 accepts the restriction request from the user terminal 22, the payment service management server 110 executes the process indicated in the restriction request.

The restriction request requests the payment service management server 110 to restrict the use of payment services in transactions between the seller 30 identified by the identification information of the seller 30 indicated by the above selection information, and the user 20. Examples of the above restrictions include temporarily suspending the use of the user 20's credit card, temporarily reducing the credit limit of the user 20's credit card, etc.

As a result, the identification information of the seller 30 selected by the user 20 from among the identification information of the seller 30 notified to the user 20 by the usage details 300 is sent to the payment service management server 110. In addition, the contents of the restrictions imposed on the credit card payment between the seller 30 and the user 20 are sent to the payment service management server 110.

For example, the statement of use 300 includes an object 364 in which an instruction (sometimes called a resumption instruction) is embedded to cause the payment service management server 110 to resume the use of a credit card whose use has been temporarily suspended. The resumption instruction includes an instruction to cause the user terminal 22 of the user 20 to execute a predetermined process.

For example, the user terminal 22 displays the usage details 300 on the display screen of the user terminal 22, whereby the usage details 300 are presented to the user 20. When the user 20 clicks on an object 364 associated with a specific seller 30 on the screen, the user terminal 22 executes a resume command.

When the resume command is executed on the user terminal 22, the user terminal 22 executes a process to send to the payment service management server 110 a relaxation request, which requests the payment service management server 110 to relax the usage restrictions on the user 20's credit card. At this time, the user terminal 22 may execute a process to send to the payment service management server 110 the relaxation request and information indicating the record corresponding to the object 364 (sometimes referred to as selection information). The information indicating the record corresponding to the object 364 may be identification information of the seller 30 contained in that record. When the payment service management server 110 accepts the relaxation request from the user terminal 22, the payment service management server 110 executes the process indicated in the relaxation request.

The relaxation request requests the payment service management server 110 to relax restrictions imposed on the use of payment services in transactions between the seller 30 identified by the identification information of the seller 30 indicated by the above selection information and the user 20. Examples of the relaxation of restrictions include resuming the use of a credit card that has been temporarily suspended, and increasing or restoring the credit card credit limit that has been temporarily reduced.

For example, the usage details 300 includes an object 366 in which an instruction (sometimes referred to as a release instruction) is embedded to cause the payment service management server 110 to release the registration of the card information in the transaction management system 120. The release instruction includes an instruction to cause the user terminal 22 of the user 20 to execute a predetermined process.

For example, the user terminal 22 displays the usage details 300 on the display screen of the user terminal 22, whereby the usage details 300 are presented to the user 20. When the user 20 clicks on an object 366 associated with a specific seller 30 on the screen, the user terminal 22 executes a release command.

When the release command is executed on the user terminal 22, the user terminal 22 executes a process to send to the payment service management server 110 a release request that requests the payment service management server 110 to release the registration of the card information of the user 20 registered with a specific seller 30. At this time, the user terminal 22 may execute a process to send to the payment service management server 110 the release request and information indicating the record corresponding to the object 366 (sometimes referred to as selection information). The information indicating the record corresponding to the object 366 may be identification information of the seller 30 contained in that record. When the payment service management server 110 accepts the release request from the user terminal 22, the payment service management server 110 executes the process indicated in the release request.

The cancellation request requests the payment service management server 110 to have the seller 30 identified by the identification information of the seller 30 indicated by the above selection information cancel the registration of the user 20's card information. Examples of processing for having the seller 30 cancel the registration of the card information include processing for having the seller 30 delete the card information and processing for preventing the seller 30 from using the card information. When the payment service management server 110 executes the processing indicated in the cancellation request, the payment service management server 110 transmits, for example, the identification information of the user 20 and information requesting the cancellation of the registration of the user 20's card information to the website management unit 122 of the seller 30 indicated by the selection information.

According to this embodiment, the usage details 300 notified to the user 20 from the payment service management server 110 includes information 320 indicating the usage status of credit card payments, as well as information 340 indicating the registration destination that has not been used for a long period of time. This notifies the user 20 of the registration status of the user's 20 card information.

In addition, according to this embodiment, when the usage details 300 are notified to the user 20 as electronic data, the usage details 300 includes, in addition to information 320 indicating the usage status of the credit card payment, an object in which commands for sending various requests to the payment service management server 110 are embedded. This allows the user 20 to update the registration status of the user's 20 card information while checking the usage details 300.

The information 320 indicating the usage status of credit card payments may be an example of detailed information. The identification information of the seller 30 included in the information 340 indicating the registration destination with a long unused period may be an example of first provider identification information included in at least a portion of the confirmation history information. The record corresponding to the object 362 may be an example of at least a portion of the confirmation history information. The identification information of the seller 30 indicated by the record corresponding to the object 362 may be an example of first provider identification information indicated by the selection information. The stop command may be an example of a first command. The release command may be an example of a second command. The release request may be an example of a deletion request.

(An example of another embodiment)
In this embodiment, an example of the usage details 300 has been described, taking as an example a case where the usage details 300 includes information 340 indicating a registration destination that has not been used for a long period of time. However, the usage details 300 are not limited to this embodiment. In other embodiments, the usage details 300 may include information indicating all registration destinations.

In this embodiment, an example of the usage details 300 has been described in which the information 320 indicating the usage status of credit card payment includes information indicating the usage status of a payment service by the user 20 for each period having a predetermined length. However, the usage details 300 are not limited to this embodiment.

In another embodiment, the information 320 indicating the usage status of credit card payment may include information regarding the possibility of fraudulent use. When the information 320 indicating the usage status of credit card payment in the statement 300 indicates that the credit card may have been fraudulently used at a registered store, the information 320 indicating the usage status of credit card payment may include an object in which instructions are embedded to assist the user 20 when the user 20 wishes to update the registered information. For example, the information 320 indicating the usage status of credit card payment includes an object having a similar configuration to the object 362. For example, the information 320 indicating the usage status of credit card payment includes an object having a similar configuration to the object 366.

For example, if the payment system 100 determines that a credit card may have been fraudulently used at a registered store, the payment system 100 creates a statement 300 that includes information regarding the possibility of fraudulent use and/or the above-mentioned objects. Specifically, the payment system 100 may determine whether a use of the credit card at the registered store is likely to be fraudulent based on the date and time of the use, the amount, and the interval since the last use.

Figure 4 shows an outline of another example of an information processing method in the payment system 100. Using Figure 4, an example of a process in which a user 20 who has received a statement 300 uses the statement 300 to update the registration status of card information is described. Also, using Figure 4, an example of a credit card usage restriction process is described.

According to this embodiment, first, in S420, the user terminal 22 receives a notification regarding the usage details (sometimes referred to as a usage details notification) from the payment service management server 110. The usage details notification is electronic data that includes, for example, a message indicating that the usage details for this month are now available for viewing and the URI of the usage details 300, and is sent from the payment service management server 110 to the user terminal 22 by SMS or email.

Next, in S422, the user 20 accesses a portal site provided by the payment service provider 40. For example, the user 20 operates the user terminal 22 to access the URI of the usage details 300, thereby accessing the portal site. In S424, the user 20 operates the user terminal 22 to view the usage details 300 of the user 20 on the portal site.

As described above, the usage details 300 includes information 340 indicating registration destinations that have not been used for a long time, and an object with the above-mentioned command embedded therein is provided for each registration destination that has not been used for a long time. When the user 20 wishes to update the registration status of card information registered with a specific seller 30, the user 20 operates the user terminal 22 to click on the object corresponding to the specific seller 30. When the above object is clicked, the command embedded in the object is executed, and a request (sometimes referred to as an update request) according to the clicked object is sent to the payment service management server 110.

As described above, when user 20 clicks on object 362, processing is executed to temporarily restrict credit card usage. As a result, the registration status of the card information is updated. Similarly, when user 20 clicks on object 364, processing is executed to relax the credit card usage restrictions. As a result, the registration status of the card information is updated. When user 20 clicks on object 366, processing is executed to cancel the registration of the card information. As a result, the registration status of the card information is updated.

When the payment service management server 110 accepts the update request, in S430, the payment service management server 110 executes processing according to the update request. For example, the payment service management server 110 updates the credit card usage restrictions. In addition, in S432, the payment service management server 110 notifies the transaction management system 120 of information indicating that the credit card usage restrictions have been updated.

In one embodiment, when the payment service management server 110 receives a restriction request, the payment service management server 110 restricts the use of credit cards. In another embodiment, when the payment service management server 110 receives a relaxation request, the payment service management server 110 relaxes the restrictions on the use of credit cards.

In another embodiment, when the payment service management server 110 receives a cancellation request, the payment service management server 110 may restrict the use of the credit card. For example, the payment service management server 110 restricts the use of the credit card until the deletion of the card information in the transaction management system 120 is confirmed. In this case, in S432, the payment service management server 110 requests the transaction management system 120 to cancel the registration of the card information.

Next, in S440, the transaction management system 120 updates the registration information of the user 20. For example, the transaction management system 120 adds information regarding usage restrictions to the card information of the user 20. For example, the transaction management system 120 deletes the card information of the user 20. This completes the update process.

Figure 5 shows an example of the internal configuration of the payment service management server 110. In this embodiment, the payment service management server 110 includes a communication control unit 510, a registration processing unit 112, a payment processing unit 114, and a portal site management unit 118. In this embodiment, the registration processing unit 112 includes a validity confirmation unit 522, a confirmation history generation unit 524, and a confirmation history update unit 526. In this embodiment, the payment processing unit 114 includes a credit approval unit 542, a usage restriction unit 544, a sales processing unit 546, and a notification unit 548. In this embodiment, the storage unit 116 includes a member information storage unit 562, a confirmation history storage unit 564, and a payment information storage unit 566.

In this embodiment, the communication control unit 510 controls communication between the payment service management server 110 and the user terminal 22 and/or the website management unit 122. For example, the communication control unit 510 acquires various requests from the user 20 to the payment service management server 110 from the user terminal 22. The communication control unit 510 acquires various requests from the seller 30 to the payment service management server 110 from the website management unit 122.

For example, the communication control unit 510 acquires a validity confirmation request from the seller 30. As described above, when the website management unit 122 receives a registration request from the user terminal 22, the website management unit 122 sends the validity confirmation request from the seller 30 to the payment service management server 110. At this time, the communication control unit 510 acquires (i) the validity confirmation request, (ii) identification information of the seller 30, and (iii) identification information of the user 20 who uses the credit card that is the subject of the validity check.

In this embodiment, the validity confirmation unit 522 obtains a validity confirmation request from the communication control unit 510. The validity confirmation unit 522 performs a validity check of the user 20's credit card by referring to the member information storage unit 562. The validity confirmation unit 522 transmits information indicating the result of the validity check to the transaction management system 120 that transmitted the validity confirmation request.

In this embodiment, the confirmation history generating unit 524 obtains a validity confirmation request from the communication control unit 510. The confirmation history generating unit 524, for example, analyzes the above-mentioned validity confirmation request and obtains information indicating the time when the communication control unit 510 received the validity confirmation request or the time when the transaction management system 120 sent the validity confirmation request. The confirmation history generating unit 524 may also obtain information indicating the time when the validity confirmation unit 522 performed the validity check.

As described above, the communication control unit 510 obtains (i) a validity check request, (ii) identification information of the seller 30, and (iii) identification information of the user 20 who uses the credit card that is the subject of the validity check. The confirmation history generation unit 524 obtains this information from the communication control unit 510.

The confirmation history generating unit 524 generates confirmation history information by associating (i) information indicating the time when the communication control unit 510 received the validity confirmation request and/or the time when the validity confirmation unit 522 performed the validity check (sometimes referred to as confirmation time information) with (ii) the identification information of the user 20 and the identification information of the seller 30 acquired by the communication control unit 510. The confirmation history generating unit 524 may generate confirmation history information when (i) the validity confirmation request requests confirmation of the validity of the credit card but does not request the securing of a credit limit for the user's payment service, or (ii) when the above-mentioned credit request is not made within a predetermined period of time after the communication control unit 510 acquires the validity confirmation request. The confirmation history generating unit 524 stores the generated confirmation history information in the confirmation history storage unit 564.

In this embodiment, the confirmation history update unit 526 updates the confirmation history information. For example, if the confirmation history information includes information regarding credit card restrictions, the confirmation history update unit 526 updates the confirmation history information each time the credit card restriction status is changed.

In this embodiment, the credit approval unit 542 executes credit approval processing in response to a credit inquiry or credit request from the seller 30. In this embodiment, the usage restriction unit 544 restricts the use of credit cards or relaxes the restrictions on credit card usage. In this embodiment, the sales processing unit 546 executes sales processing in response to the seller 30 executing a payment.

In this embodiment, the notification unit 548 notifies the user 20 of various information. For example, the notification unit 548 notifies the user 20 of the usage details 300.

The notification unit 548 may generate the usage details 300. For example, the notification unit 548 refers to the confirmation history storage unit 564, extracts the identification information of the seller 30 contained in at least a portion of one or more pieces of confirmation history information associated with the identification information of the user 20, and generates information 340 indicating registration destinations that have not been used for a long period of time.

For example, the notification unit 548 extracts confirmation history information from one or more pieces of confirmation history information associated with the identification information of the user 20, in which the length of time since validity was confirmed is greater than a predetermined value. The notification unit 548 generates information 340 indicating registration destinations with long unused periods using the identification information of the seller 30 included in the extracted confirmation history information. This allows the user 20 to be notified of at least some of the sellers 30 related to the confirmation history information associated with the identification information of the user 20.

As described above, the usage details 300 may include a list of all registered destinations, not just those that have not been used for a long time. In this case, the usage details 300 including a list listing the identification information of all extracted sellers 30 is notified to the user 20.

As described above, the statement of use 300 includes objects with various commands embedded therein. This allows the payment system 100 to transmit these commands to the user terminal 22 of the user 20 by notifying the user 20 of the electronic data of the statement of use 300.

In this embodiment, the member information storage unit 562 stores information regarding the credit cards of each of the one or more users 20. In this embodiment, the confirmation history storage unit 564 stores confirmation history information regarding each of the one or more users 20. In this embodiment, the payment information storage unit 566 stores information regarding the payments of each of the one or more users 20.

The communication control unit 510 may be an example of a request acquisition unit. The validity confirmation unit 522 may be an example of a request acquisition unit. The usage restriction unit 544 may be an example of a restriction unit. The notification unit 548 may be an example of a confirmation history notification unit. The time when the validity confirmation unit 522 performed the validity check may be an example of the time when processing to confirm validity in response to a validity confirmation request was performed.

Figure 6 shows an example of the data structure of the data stored in the storage unit 116. In this embodiment, the storage unit 116 includes a member information database 620, a confirmation history database 640, and a payment information database 660.

The member information database 620 may be an example of member information stored in the member information storage unit 562. The member information database 620 stores a member number assigned to each of one or more users 20, the expiration date of the credit card, the security code of the credit card, and various information related to the user 20 (sometimes referred to as member information) in association with each other.

The confirmation history database 640 may be an example of confirmation history information stored in the confirmation history storage unit 564. The confirmation history database 640 stores, in association with each other, a membership number assigned to one or more users 20, identification information of the seller 30 who registered the card information, information indicating the time when the validity check was performed, user confirmation information for confirming the user 20 who registered the card information, and information indicating the status of usage restrictions.

The payment information database 660 may be an example of payment information stored in the payment information storage unit 566. The payment information database 660 stores, in association with each other, the membership number assigned to each of the above users 20, information indicating the date of credit card use, identification information of the seller 30 at which the transaction using the credit card was carried out, information indicating the amount of the transaction, information indicating the time the validity check was carried out, and user verification information for verifying the user 20 who carried out the transaction.

Figure 7 shows an example of a computer 3000 in which multiple aspects of the present invention may be embodied in whole or in part. For example, a part of the payment system 100 is realized by the computer 3000. For example, at least a part of the payment service management server 110 is realized by the computer 3000. For example, at least a part of the transaction management system 120 is realized by the computer 3000. At least a part of the user terminal 22 may be realized by the computer 3000.

A program installed on the computer 3000 may cause the computer 3000 to function as or perform operations associated with an apparatus according to an embodiment of the present invention or one or more "parts" of the apparatus, and/or to perform a process or steps of the process according to an embodiment of the present invention. Such a program may be executed by the CPU 3012 to cause the computer 3000 to perform certain operations associated with some or all of the blocks of the flowcharts and block diagrams described herein.

The computer 3000 according to this embodiment includes a CPU 3012, a RAM 3014, a GPU 3016, and a display device 3018, which are interconnected by a host controller 3010. The computer 3000 also includes input/output units such as a communication interface 3022, a hard disk drive 3024, a DVD-ROM drive 3026, and an IC card drive, which are connected to the host controller 3010 via an input/output controller 3020. The computer also includes legacy input/output units such as a ROM 3030 and a keyboard 3042, which are connected to the input/output controller 3020 via an input/output chip 3040.

The CPU 3012 operates according to the programs stored in the ROM 3030 and the RAM 3014, thereby controlling each unit. The GPU 3016 acquires image data generated by the CPU 3012 into a frame buffer or the like provided in the RAM 3014 or into itself, and causes the image data to be displayed on the display device 3018.

The communication interface 3022 communicates with other electronic devices via a network. The hard disk drive 3024 stores programs and data used by the CPU 3012 in the computer 3000. The DVD-ROM drive 3026 reads programs or data from the DVD-ROM 3001 and provides the programs or data to the hard disk drive 3024 via the RAM 3014. The IC card drive reads programs and data from an IC card and/or writes programs and data to an IC card.

The ROM 3030 stores therein a boot program or the like that is executed by the computer 3000 upon activation, and/or a program that depends on the hardware of the computer 3000. The input/output chip 3040 may also connect various input/output units to the input/output controller 3020 via a parallel port, a serial port, a keyboard port, a mouse port, etc.

The programs are provided by a computer-readable storage medium such as a DVD-ROM 3001 or an IC card. The programs are read from the computer-readable storage medium, installed in the hard disk drive 3024, RAM 3014, or ROM 3030, which are also examples of computer-readable storage media, and executed by the CPU 3012. The information processing described in these programs is read by the computer 3000, and brings about cooperation between the programs and the various types of hardware resources described above. An apparatus or method may be constructed by realizing the operation or processing of information in accordance with the use of the computer 3000.

For example, when communication is performed between computer 3000 and an external device, CPU 3012 may execute a communication program loaded into RAM 3014 and instruct communication interface 3022 to perform communication processing based on the processing described in the communication program. Under the control of CPU 3012, communication interface 3022 reads transmission data stored in a transmission buffer area provided in RAM 3014, hard disk drive 3024, DVD-ROM 3001, or a recording medium such as an IC card, and transmits the read transmission data to the network, or writes received data received from the network to a reception buffer area or the like provided on the recording medium.

The CPU 3012 may also cause all or a necessary portion of a file or database stored on an external recording medium such as the hard disk drive 3024, the DVD-ROM drive 3026 (DVD-ROM 3001), an IC card, etc. to be read into the RAM 3014, and perform various types of processing on the data on the RAM 3014. The CPU 3012 may then write back the processed data to the external recording medium.

Various types of information, such as various types of programs, data, tables, and databases, may be stored on the recording medium and may undergo information processing. The CPU 3012 may perform various types of processing on the data read from the RAM 3014, including various types of operations, information processing, conditional judgment, conditional branching, unconditional branching, information search/replacement, etc., as described throughout this disclosure and specified by the instruction sequence of the program, and writes back the results to the RAM 3014. The CPU 3012 may also search for information in a file, database, etc. in the recording medium. For example, when multiple entries each having an attribute value of a first attribute associated with an attribute value of a second attribute are stored in the recording medium, the CPU 3012 may search for an entry whose attribute value of the first attribute matches a specified condition from among the multiple entries, read the attribute value of the second attribute stored in the entry, and thereby obtain the attribute value of the second attribute associated with the first attribute that satisfies a predetermined condition.

The above-described program or software module may be stored in a computer-readable storage medium on the computer 3000 or in the vicinity of the computer 3000. In addition, a recording medium such as a hard disk or RAM provided in a server system connected to a dedicated communication network or the Internet can be used as a computer-readable storage medium, thereby providing the above-described program to the computer 3000 via the network.

The blocks in the flowcharts and block diagrams in the above embodiments may represent stages of a process in which an operation is performed or "parts" of a device responsible for performing the operation. Particular stages and "parts" may be implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable storage medium, and/or a processor provided with computer-readable instructions stored on a computer-readable storage medium. Dedicated circuitry may include digital and/or analog hardware circuitry, and may include integrated circuits (ICs) and/or discrete circuits. Programmable circuitry may include reconfigurable hardware circuitry including AND, OR, XOR, NAND, NOR, and other logical operations, flip-flops, registers, and memory elements, such as, for example, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), and the like.

A computer-readable storage medium may include any tangible device capable of storing instructions that are executed by a suitable device, such that a computer-readable storage medium having instructions stored thereon comprises an article of manufacture that includes instructions that can be executed to create means for performing the operations specified in the flowchart or block diagram. Examples of computer-readable storage media may include electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, and the like. More specific examples of computer-readable storage media may include floppy disks, diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), electrically erasable programmable read-only memories (EEPROMs), static random access memories (SRAMs), compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), Blu-ray disks, memory sticks, integrated circuit cards, and the like.

The computer readable instructions may include either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk (registered trademark), JAVA (registered trademark), C++, etc., and conventional procedural programming languages such as the "C" programming language or similar programming languages.

The computer-readable instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, or a programmable circuit, either locally or over a local area network (LAN), a wide area network (WAN), such as the Internet, so that the processor of the general-purpose computer, special-purpose computer, or other programmable data processing apparatus, or the programmable circuit, executes the computer-readable instructions to generate means for performing the operations specified in the flowcharts or block diagrams. Examples of processors include computer processors, processing units, microprocessors, digital signal processors, controllers, microcontrollers, etc.

Although the present invention has been described above using an embodiment, the technical scope of the present invention is not limited to the scope described in the above embodiment. It is clear to those skilled in the art that various modifications or improvements can be made to the above embodiment. Furthermore, the details described for a specific embodiment can be applied to other embodiments to the extent that they are not technically inconsistent. It is clear from the claims that such modifications or improvements can also be included in the technical scope of the present invention.

The order of execution of each process, such as operations, procedures, steps, and stages, in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not specifically stated as "before" or "prior to," and it should be noted that the processes may be performed in any order, unless the output of a previous process is used in a later process. Even if the operational flow in the claims, specifications, and drawings is explained using "first," "next," etc. for convenience, it does not mean that it is necessary to perform the processes in this order.

10 Communication network 20 User 22 User terminal 30 Seller 40 Payment service provider 100 Payment system 110 Payment service management server 112 Registration processing unit 114 Payment processing unit 116 Storage unit 118 Portal site management unit 120 Transaction management system 122 Web site management unit 300 Usage details 320 Information 340 Information 362 Object 364 Object 366 Object 510 Communication control unit 522 Validity confirmation unit 524 Confirmation history generation unit 526 Confirmation history update unit 542 Credit approval unit 544 Usage restriction unit 546 Sales processing unit 548 Notification unit 562 Member information storage unit 564 Confirmation history storage unit 566 Payment information storage unit 620 Member information database 640 Confirmation history database 660 Payment information database 3000 Computer 3001 DVD-ROM
3010 host controller 3012 CPU
3014 RAM
3016 GPU
3018 Display device 3020 Input/output controller 3022 Communication interface 3024 Hard disk drive 3026 DVD-ROM drive 3030 ROM
3040 Input/Output Chip 3042 Keyboard

Claims (11)

a request acquisition unit that acquires, when a user's credit card information is registered on an electronic commerce site of a first provider that provides goods , data, or services, from the first provider, (i ) a validity confirmation request requesting confirmation of the validity of the credit card , (ii) first provider identification information for identifying the first provider, and (iii) user identification information assigned to the user by a second provider that provides a payment service using the credit card ;
(i) confirmation time information indicating a time when the request acquisition unit received the validity confirmation request and/or a time when a process for confirming the validity in response to the validity confirmation request was executed, and (ii) a confirmation history generation unit that generates confirmation history information in which the user identification information and the first provider identification information acquired by the request acquisition unit are associated with each other;
An information processing device comprising: a confirmation history notifying unit that refers to a confirmation history storage unit that stores one or more pieces of confirmation history information generated by the confirmation history generating unit and notifies the user of the first provider identification information included in at least a part of the one or more pieces of confirmation history information associated with the user identification information of the user;
Further comprising:
The information processing device according to claim 1 . The confirmation history notification unit,
extracting, from the one or more pieces of confirmation history information associated with the user identification information of the user, confirmation history information for which the length of time since the validity has been confirmed is greater than a predetermined value, by referring to the confirmation history storage unit;
notifying the user of the first provider identification information included in the extracted confirmation history information;
The information processing device according to claim 2 . The confirmation history notification unit,
generating detailed information indicating a usage status of the payment service by the user for each period having a predetermined length;
(a) notifying the user of the first provider identification information included in the at least a portion of the confirmation history information, and (b) notifying the user of the detailed information;
4. The information processing device according to claim 2. The confirmation history notification unit,
(c) a first instruction to cause an information processing terminal used by the user to execute a process of transmitting to the information processing device (i) selection information indicating the first provider identification information selected by the user from the first provider identification information notified to the user, and (ii) a restriction request requesting the information processing device to restrict use of the payment service in a transaction between the first provider identified by the first provider identification information indicated by the selection information and the user;
transmitting the information to the information processing terminal of the user;
The information processing device according to any one of claims 2 to 4. The confirmation history notification unit,
(d) a second instruction to cause an information processing terminal used by the user to execute a process of transmitting to the information processing device (i) selection information indicating the first provider identification information selected by the user from the first provider identification information notified to the user, and (ii) a deletion request requesting the information processing device to cause the first provider identified by the first provider identification information indicated by the selection information to delete or not use information related to the user's payment service,
transmitting the information to the information processing terminal of the user;
The information processing device according to any one of claims 2 to 4. The payment service is a service that provides credit card payment or a payment agency service that uses credit card payment.
The information processing device according to any one of claims 1 to 6. the validation request is a request to validate the credit card distributed to the user;
The information processing device according to any one of claims 1 to 7. The confirmation history generation unit
(i) the validation request requests validation of a credit card but does not request the user to reserve a credit line for the payment service; or
(ii) when the user does not make a credit request to secure a credit limit for the payment service within a predetermined period of time after the request acquisition unit acquires the validity confirmation request,
generating said confirmation history information;
The information processing device according to any one of claims 1 to 8. A program for causing a computer to function as an information processing device according to any one of claims 1 to 9. a request acquisition step in which, when a user's credit card information is registered on an electronic commerce site of a first provider that provides goods , data, or services, the computer acquires from the first provider (i) a validation request requesting validation of the credit card , (ii) first provider identification information for identifying the first provider, and (iii) user identification information assigned to the user by a second provider that provides a payment service using the credit card ;
a confirmation history generating step in which the computer generates (i) confirmation time information indicating a time when the validity confirmation request was received in the request acquiring step and/or a time when a process for confirming the validity was executed in response to the validity confirmation request, and (ii) confirmation history information in which the user identification information and the first provider identification information acquired in the request acquiring step are associated with each other;
An information processing method comprising the steps of: