JP7346488B2 - Service usage support method, service usage support program, and service usage support system - Google Patents

Description

The present invention relates to a service usage support method for providing a smooth payment environment in conjunction with operation support services such as EC sites.

BACKGROUND ART Conventionally, credit cards have been widely used as a payment method in the operation of e-commerce sites and the like. While payments can be made easily and convenient for parties involved in a transaction, the risk of leakage or unauthorized use of transaction data and credit card information cannot be ignored. Therefore, various technical measures regarding security are required for such payments, such as the establishment of a security system that meets official standards such as PCIDSS, and the so-called "non-retention of card information". It is widely known that measures such as token payments will be adopted.

On the other hand, in connection with the operation of e-commerce sites, there are also well-known services that provide a system for ensuring a smooth process to payment by supporting purchasing users in inputting information. Specifically, by providing mechanisms such as chatbots that prompt purchasing users to enter specified information and send appropriate questions, e-commerce site operators can reduce their user response costs. ing. As a technology related to such an EC site management support system, for example, the technology described in Cited Document 1 is known.

JP2018-081538

However, since the prior art described in Patent Document 1 can only prompt the user to input information in a predetermined format, it may end up prompting the purchasing user to input card information directly. I couldn't shake my concerns from a security perspective.

In order to solve the above-mentioned problems, the present invention provides a service server that is a server that provides a predetermined web service, a user terminal that uses the web service, and a payment agency processing related to the web service. A service usage support method that executes a computer to send and receive information between a payment processing server, which is a server, and a payment request receiving step of receiving a payment request regarding web service usage from a user terminal; an issuance request step for causing the user terminal to transmit a token issuance request to the payment processing server in response to the received payment request; a token acquisition step for acquiring a token corresponding to the issuance request; and together with the acquired token, a usage-related information output step of outputting usage-related information, which is information related to service usage in response to the payment request, to a service server; and a payment result acquisition step of acquiring a payment result corresponding to the usage-related information from the service server. and a message output step of outputting a message corresponding to the acquired payment result to the user terminal.

Further, in connection with the above invention, an input reception rule acquisition step of acquiring a predetermined web service and an input reception rule corresponding to usage related information related to the web service, and a usage related information related to the web service from a user terminal. The present invention also proposes a service usage support method that further includes an input reception step that receives information input, and the usage-related information output step further includes a conformance processing substep that outputs the received usage-related information based on input reception rules. do.

Further, in relation to each of the above-mentioned inventions, the usage-related information output step includes outputting payment control information that also outputs payment control information for causing the service server to execute the scheduled payment process in an executable manner using the token. We also propose a service usage support method that has more substeps.

We also propose programs and systems to implement the above method.

The present invention, which mainly has the above-described configuration, makes it possible to eliminate the complexity of information input by web service users and reduce the effort of the service operations manager, while ensuring security.

Schematic diagram of the system of the invention A diagram showing an example of functional blocks of the system of Embodiment 1 A schematic diagram illustrating an example of a configuration when the functional configurations of the system of Embodiment 1 are collectively realized as one piece of hardware. A diagram showing an example of the flow of processing in the system of Embodiment 1 A diagram showing an example of the flow of processing in the system of Embodiment 1 A diagram showing an example of functional blocks of the system of Embodiment 2 A diagram showing an example of the flow of processing in the system of Embodiment 2 A diagram showing an example of functional blocks of the system of Embodiment 3 A diagram showing an example of the flow of processing in the system of Embodiment 3

First, FIG. 1 is shown. FIG. 1 is a diagram showing an overview of the present invention. As shown in this figure, the present invention provides a service server 0121 that is a server that provides a predetermined web service, user terminals 0111, 0112, and 0113 that use the web service, and user terminals related to the web service. The computer is configured to execute a computer to send and receive information between the payment proxy processing server 0131, which is a server that performs payment proxy processing, and specifically, one or more servers 0101 and 0102 Realized.

As described with reference to the figure, the present invention includes a service server that provides a predetermined web service, a user terminal that uses the web service, and a server that performs payment agency processing related to the web service. It is characterized by transmitting and receiving information between the payment processing server and the payment processing server. The "predetermined web service" here is applicable regardless of its type, such as e-commerce services, online school services, on-demand content services, and other web services that can be used by performing payment processing. be. Furthermore, since it is a web service, it is required that the service be available via a web browser.

Next, regarding the user terminal, the type is not particularly limited as long as it has a configuration that allows the above web service to be used. Other possibilities include smart glasses, smart watches, and smart pens.

In addition, a payment processing server is a payment processing server that performs payment processing with a credit card company or other payment financial institution on behalf of a user who requires payment processing when payment processing is requested for the above-mentioned predetermined web service. It is generally a server for However, "settlement" here is not necessarily limited to cash or the exchange (exchange) process of value directly linked to cash value, but also includes crypto assets, prepaid payment methods, and points that can only be used for specific services. It broadly includes the process of exchanging cash for cash-like value. As mentioned above, for payment processing in transactions on the Internet, payment processing servers are often involved from a security perspective, and the positioning of the payment processing server in the present invention is also applicable to such general transactions. There is no difference in significance from that in .

As mentioned earlier, the present invention may be implemented by one or more servers 0101, 0102. More specifically, it is conceivable that a plurality of application servers 0101 for providing one service, database servers 0102 for managing various data used for the service, etc., are used, and other businesses It is also possible to execute service applications provided by other businesses by being interconnected with application servers managed by other businesses through API collaboration. Combining these servers not only makes it possible to support a wide range of service content, but also allows each server to be configured to be connectable via a network. This makes it possible to provide high quality services.

Hereinafter, each embodiment of the present invention will be described with reference to the drawings. First, the mutual relationship between the embodiments and the claims is as follows. First, the first embodiment mainly corresponds to claims 1, 4, 5, etc. Embodiment 2 mainly corresponds to claim 2 and the like. Embodiment 3 mainly corresponds to claim 3 and the like.

Note that the present invention is not limited to these embodiments in any way, but has the technical idea described in each claim in accordance with common general technical knowledge, and various modifications may be made without departing from the gist thereof. It can be implemented in various ways.

<<Embodiment 1>>
<Summary>
FIG. 2 is a diagram showing an example of functional blocks of the service usage support system of this embodiment. As shown in the figure, the "service usage support system" 0200 of this embodiment includes a "payment request receiving section" 0201, an "issuance requesting section" 0202, a "token acquisition section" 0203, and a "usage request section" 0201. It has a "related information output section" 0204, a "payment result acquisition section" 0205, and a "message output section" 0206.

Note that the service usage support system described in detail below may be configured to implement one or more of its functions using multiple devices, and each of its functional blocks may be implemented using hardware or It can be realized as software. For example, when using a computer, the CPU, main memory, GPU, TPU, image memory, bus, secondary storage device (hard disk or non-volatile memory), keyboard, microphone, touch panel, and electronic pen for touching the touch panel. Hardware components such as various input devices such as speakers, displays, various output devices, and other external peripheral devices, as well as interfaces for the external peripheral devices, communication interfaces, and driver programs for controlling these hardware. and other application programs.

Then, through arithmetic processing according to the program developed on the main memory, data input from input devices and other interfaces and held in memory and hardware is processed and accumulated, and each of the above hardware and software is processed and stored. Instructions are created to control it. Here, the above program may be realized as a plurality of modularized programs, or two or more programs may be realized as one program by combining them by cloud computing or other methods.

Further, the present invention including this embodiment includes a service server that is a server that provides a predetermined web service, a user terminal that uses the web service, and a server that performs payment agency processing related to the web service. Its technical feature is that it can send and receive information between it and the payment processing server. That is, the present invention can be implemented using a computer managed by a third party who is not a service server operator, a service user, or a payment agency. In particular, for service server operators, it is possible to outsource the complicated processing required for payment processing and provide services without causing stress to service users, so they can use their technical resources to You can focus on providing user-friendly services.

Taking a web service as an example in particular, a preferred mode of adopting such a configuration is to display a promotion page, which is a web page for promoting the use of the web service, on the web browser, and to display the promotion page and the promotion web page. It is conceivable to perform processing such as associating the above web service with an HTML iframe element. By adopting this configuration, service users of a predetermined web service can also view promotion pages without feeling uncomfortable.

Specific examples of the promotion page mentioned here include inputting a questionnaire, inputting necessary information for payment, inputting selections such as color, size, model number, etc. of the product targeted for service, inputting search input for the numerous service menus, etc. It may be configured as a page for accepting By adopting this configuration and making it available to service server operators, service server operators can easily implement web services without having to create questionnaire formats, product purchase cart formats, etc. themselves. Be able to start deploying and operating.

Note that the promotion page may be configured to prompt the user to input information in an interactive manner, such as a chatbot. If this configuration is adopted, it will be possible to prompt the user to enter further information, add/deliver, or modify the information, and to notify the user that the input has been completed in a timely manner, with an appropriate response depending on the user's reaction. , it becomes possible to reduce the rate at which users discontinue using the service. Also, from another perspective, by prompting the user to input information in a certain format in an interactive format, the information input from the user can be processed based on certain rules rather than irregularly. Accordingly, it becomes easier to output usage-related information, which will be described later.

<Functional configuration>
The “payment request receiving unit” 0201 is configured to receive a payment request regarding the use of a web service from a user terminal. The payment request here includes at least the payment amount, information for identifying the product or service to be paid, the date and time of the payment request, and other information regarding the payment object.

Note that, when a payment request is received by the payment request receiving unit, it is not necessarily excluded that a configuration is adopted in which the content of the payment request is output to the service server. However, since the processing overlaps with the processing content of the usage-related information output section, which will be described later, it is desirable to avoid adopting this configuration from the viewpoint of avoiding complexity.

The "issuance request unit" 0202 is configured to cause the user terminal to transmit a token issuance request to the payment processing server in response to the received payment request. Specific aspects of the process of "sending a token issuance request" include outputting a message to the user terminal to the effect that it should send a token issuance request to the payment processing server, and In some cases, web pages and other functions for sending token issuance requests may be made available to the proxy processing server. Either method may be adopted, but by providing a function for requesting token issuance using an API linkage function, etc., it is possible to use a simple method without requiring the user to perform any special terminal operations. This makes it possible to prompt users to send token issuance requests.

Note that the token issuance request referred to herein is accepted together with the selection input of information for identifying the business operator that manages the specific payment processing server. On the other hand, in any of the functions including the issue request section, the implementing entity of the present invention does not acquire credit card numbers or other information that can directly identify the person to be paid when performing payment processing. By adopting this configuration, it becomes possible to provide service users with a payment procedure for using the service with peace of mind without building a security system such as PCIDSS.

The issuance request unit issues a token issuance request in response to a payment request, and the token issuance request includes an identifier to indicate association with the payment request. By adopting this configuration, it becomes possible to match the token with the payment request and perform subsequent processing appropriately.

The "token acquisition unit" 0203 is configured to acquire a token corresponding to the issuance request. The "token corresponding to the issuance request" herein refers to a token issued by the payment processing server in response to the issuance request and acquired by the user terminal, and is associated with the issuance request. Contains information about It contains information that can determine whether there is a relationship between a payment request and a token, including the above-mentioned identifier, and by acquiring such information, it is possible to determine whether the acquired token is associated with any payment request. It becomes possible to determine whether it is a thing or not.

Note that the token acquisition unit has a technical feature of acquiring tokens from user terminals. Therefore, even if for some reason it is difficult or impossible to obtain information that can determine whether there is a relationship between the token and the payment request, including the above-mentioned identifier, the token will not be sent. By acquiring information that identifies the user terminal and the user terminal that received the token issuance request at the issuance request unit, it is possible to link the acquired token to any payment request using the acquired information. You can also determine whether it is a thing.

The "usage-related information output unit" 0204 is configured to output usage-related information, which is information related to service usage in response to the payment request, to the service server together with the acquired token. An example of the usage-related information mentioned here is concretely related to the explanation regarding the promotion page, such as the member ID, name, address, age of the service that has been input as necessary information for payment, the product or product for which payment is being made, etc. Services or IDs to identify them, desired delivery date and time, whether or not a delivery destination different from the address is desired, the delivery destination, delivery method (designation of delivery company and delivery service, availability of delivery at the time of delivery, regular purchase) It is considered that usage-related information includes information such as the purchase interval in the case of , but there is no particular limitation on the information assumed to be related to these.

Since the usage-related information output section outputs usage-related information along with the token, it has the meaning of performing "order agency" processing in terms of the relationship with service users and service providers. . By acquiring the information, the service server that is the output destination can promptly perform processing for using the service according to the information. In other words, if you operate an e-commerce site, you can promptly proceed with payment processing for product sales and processing for product delivery, and you can collect necessary information for product sales between yourself and users. You will be freed from the hassle of having to perform complicated processes such as accepting input and sending information to prompt token issuance.

In the usage-related information output unit, information output rules, which are rules regarding the mode of information output, are stored in advance according to the content of the service provided by the service server, and the usage-related information is output according to the information output rules. It is possible to output it. Specifically, contents such as which information should be input in which format, in which site page, and in which input field among the contents of usage-related information are held as information output rules.

Information output rules may be provided individually for each service content, or for services that are provided in general, general information output rules may be provided as rules that can be applied in general. It's okay. Of course, it is also possible to obtain it from an external server at any time and apply it in the form of an API. By adopting this configuration, not only will the output processing in the usage-related information output section be made more efficient, but the service server will also be able to acquire usage-related information with reduced risk of errors, etc. It will be possible to contribute to transactions.

The “payment result acquisition unit” 0205 is configured to acquire payment results corresponding to the usage-related information from the service server. The service server, which is the output destination of usage-related information in the usage-related information output unit, uses the acquired token to send and receive information to and from the payment processing server that issued the token, and links it with the token. Determine whether or not to proceed with the payment processing. Then, the content of the determination will be obtained as the payment result. By adopting this configuration, in which the service server is responsible for transmitting and receiving information to and from the payment processing server, the service operator can quickly proceed with subsequent processing such as shipping products, and can quickly obtain payment results. Therefore, it becomes possible to proceed with subsequent processing with a sense of security in sales management.

The "message output unit" 0206 is configured to output a message to the user terminal according to the acquired payment result. Here, "output to the user terminal" does not necessarily mean that the message is output only to a specific user terminal. For example, even if the output is to another user terminal that has the same user ID that is managed in association with the user terminal, the information is sent "to the user terminal" via the same user ID. It can be evaluated that it has been output. By sending messages to the user terminal through the present invention, the user can consistently send and receive information through the same interface from the request to use the service until the completion of the service, thereby eliminating the need for complication. It becomes possible to maintain a high level of service usage satisfaction without causing any problems.

<Specific configuration>
FIG. 3 is shown here. This figure is a schematic diagram showing an example of a configuration when the functional configurations of the service usage support system of this embodiment are collectively realized as one piece of hardware. Each device has a "CPU" 0301, a "storage device (storage medium)" 0302, a "main memory" 0303, an "input interface" 0304, and an "output interface" 0305 for executing various calculation processes. , a "network interface" 0306, and transmits and receives information to and from external peripheral devices such as a "touch panel" 0307 and a "display" 0308 via the input/output interface. It also sends and receives information to and from external devices such as a plurality of "user terminals" 0309 and "service servers" 0310 via a network interface. Furthermore, although not shown, the web application server may connect to another web application server via a network, send and receive information, and perform API cooperation. Although the specific aspect of this network interface is wireless, it does not exclude wired communication. Furthermore, the method of communication does not matter whether it is direct or indirect. Therefore, it is also possible to adopt a so-called cloud computing format in which information is sent and received between a specific external device or a user of the device and a server managed by a third party that is linked to the server.

Various programs as described below are stored in the storage device, and the CPU reads these various programs into the work area of the main memory, develops them, and executes them. Note that these configurations are interconnected by a data communication path such as a "system bus" 0399, and transmit, receive, and process information (the basic configuration of the above configuration is similar to that of any of the other devices described below). The same applies to

(Specific configuration of payment request receiving unit)
The payment request reception unit is composed of a computer program and computer hardware, and specifically, the CPU reads out the “payment request reception program” 0320 from the storage device into the main memory and executes it, thereby allowing the user to use the web service from the user terminal. A payment request regarding the transaction is received and stored at a predetermined address in the main memory.

(Specific configuration of issuance request section)
The issuance request unit is composed of a computer program and computer hardware, and specifically, the CPU reads the "issuance request program" 0330 from the storage device into the main memory and executes it, and executes the payment request receiving program to receive the received payment. In response to the request, information for causing the user terminal to send a token issuance request to the payment processing server is output.

(Specific configuration of token acquisition unit)
The token acquisition unit is composed of a computer program and computer hardware, and specifically, the CPU reads a "token acquisition program" 0340 from the storage device into the main memory and executes it, and sends the token corresponding to the issuance request to the user. Obtain it from the terminal and store it at a predetermined address in main memory.

(Specific configuration of usage-related information output unit)
The usage-related information output unit is composed of a computer program and computer hardware, and specifically, the CPU reads out the "usage-related information output program" 0350 from the storage device into the main memory and executes it, and by executing the token acquisition program. Along with the acquired token, usage-related information, which is information related to service usage in response to the payment request, is output to the service server.

(Specific configuration of payment result acquisition unit)
The payment result acquisition unit is composed of a computer program and computer hardware, and specifically, the CPU reads out the "payment result acquisition program" 0360 from the storage device into the main memory and executes it, and executes the payment result corresponding to the usage related information. The results are obtained from the service server and stored at a predetermined address in main memory.

(Specific configuration of message output section)
The message output section is composed of a computer program and computer hardware, and specifically, the CPU reads out a "message output program" 0370 from the storage device to the main memory and executes it, and the message output section is configured to read the "message output program" 0370 from the storage device to the main memory and execute it, and to output the payment result obtained by the payment result acquisition program. A corresponding message is output to the user terminal.

<Processing flow>
FIG. 4 is a diagram showing an example of the flow of processing in the service usage support system of this embodiment. The process flow in the figure consists of the following steps. First, in step S0401, a payment request regarding web service usage is received from a user terminal (payment request receiving step). Thereafter, in step S0402, in response to the received payment request, the user terminal is caused to transmit a token issuance request to the payment proxy processing server (issuance request step). Then, in step S0403, a token corresponding to the issuance request is acquired from the user terminal (token acquisition step), and in step S0404, along with the acquired token, a token related to the service usage according to the payment request is sent to the service server. Outputting usage-related information (usage-related information output step). Thereafter, in step S0405, the payment result corresponding to the usage-related information is acquired from the service server (payment result acquisition step), and in step S0406, a message corresponding to the acquired payment result is output to the user terminal (message output step).

FIG. 5 is further shown here. This figure is a diagram showing an example of the flow of processing in the service usage support system of this embodiment from the perspective of the flow of information transmission and reception between the server and each terminal. In step S0501, a payment request is received from the user terminal, and in step S0502, information that causes the user terminal to send a token issuance request to the payment processing server is output. When a token issuance request is sent from the user terminal to the payment proxy processing server in step S0503, a token is issued from the payment proxy processing server to the user terminal in step S0504. In step S0505, a token is acquired from the user terminal, and in step S0506, usage-related information is output to the service server. In step S0507, the service server inquires of the payment proxy processing server as to whether payment processing is possible using the token, and in step S0508, the service server acquires the introduction result from the payment proxy processing server. If the inquiry result indicates that payment processing is possible, the payment result is acquired from the service server in step S0509, and a message corresponding to the payment result is output to the user terminal in step S0510.

<Effect>
By using a service usage support system that adopts the above configuration, it is possible to ensure security, eliminate the complexity of information input by web service users, and reduce the effort of service operation managers. become.

<<Embodiment 2>>
<Summary>
The service usage support system of this embodiment is basically the same as the technical features of the service usage support system described in Embodiment 1, but it has a predetermined web service and usage related information related to the web service. The point is to maintain a corresponding input acceptance rule, accept input of usage-related information related to the web service from a user terminal, and output the accepted usage-related information based on the input acceptance rule when outputting the usage-related information. It is characterized by

<Functional configuration>
FIG. 6 is a diagram showing an example of functional blocks of the service usage support system of this embodiment. As shown in the figure, the "service usage support system" 0600 of this embodiment includes a "payment request receiving section" 0601, an "issuance requesting section" 0602, a "token acquisition section" 0603, and a "usage request section" 0601. It includes a "related information output section" 0604, a "payment result acquisition section" 0605, a "message output section" 0606, an "input reception rule holding section" 0607, and an "input reception section" 0608, and includes a usage-related information The output unit further includes an “adaptation processing means” 0614. The basic configuration is the same as the service usage support system described using FIG. 2 of Embodiment 1, so below we will explain the differences between the "input reception rule holding unit" 0607 and the "input reception unit" 0608. The function of the "adaptation processing means" 0614 will be explained.

The “input reception rule holding unit” 0607 is configured to hold input reception rules corresponding to a predetermined web service and usage related information related to the web service. Input acceptance rules are considered to be maintained in correspondence with the information output rules explained earlier, but they also include the type and content of information that is required to be input for each web service, and the reception when accepting input of multiple pieces of information. Possible rules include the order and reception method. It is conceivable to obtain and maintain the input acceptance rules from the service server, but if there is an update to the input acceptance rules on the service server side, it is necessary to update the input acceptance rules with the service server so that the updated contents are reflected at an appropriate time. Preferably, information is transmitted and received between the two.

The "input reception unit" 0608 is configured to receive input of usage-related information related to the web service from a user terminal. Specifically, as described above, it is preferable to adopt a configuration that accepts appropriate information input from a user terminal while using an input promotion means such as a chatbot.

The "adaptation processing means" 0614 is a usage-related information output unit, and the usage-related information output step is configured to output the received usage-related information based on the input acceptance rule. By adopting this configuration, the service server can acquire information according to the input acceptance rules set by itself as usage-related information, and can handle information conversion processing and information that cannot be converted in the first place. Concerns can be reduced.

<Specific configuration>
The hardware configuration of each device constituting the service usage support system of this embodiment is basically the same as the hardware configuration of the service usage support system of Embodiment 1 described using FIG. Therefore, in the following, specific processing of the "input reception rule holding section", "input reception section", and "adaptation processing means", which have not been described so far, will be explained.

(Specific configuration of input acceptance rule holding unit)
The input reception rule holding unit is specifically composed of a computer program and computer hardware, and the CPU reads an "input reception rule acquisition program" from the storage device into the main memory and executes it to acquire the input reception rules from the service server. and stores it at a predetermined address in main memory.

(Specific configuration of the usage reception department)
Specifically, the usage reception unit is composed of a computer program and computer hardware, and the CPU reads out the "usage reception program" from the storage device into the main memory and executes it, accepts input of usage-related information from the user terminal, Store at a specified address in memory.

(Specific configuration of compatible processing means)
The adaptation processing means is specifically composed of a computer program and computer hardware, and when executing the usage-related information output program, the CPU reads out the "adaptation processing subprogram" from the storage device to the main memory and executes it, and the usage acceptance program. Outputs the usage-related information received by executing , based on the input acceptance rules.

<Processing flow>
FIG. 7 is a diagram showing an example of the flow of processing in the service usage support system of this embodiment. The process flow in the figure consists of the following steps. First, in step S0701, an input reception rule corresponding to a predetermined web service and usage related information related to the web service is acquired from the service server (input reception rule acquisition step). Thereafter, in step S0702, input of usage-related information related to the web service is received from the user terminal (input reception step), and in step S0703, a payment request regarding the use of the web service is received from the user terminal (payment request reception step). Thereafter, in step S0704, in response to the received payment request, the user terminal is caused to transmit a token issuance request to the payment proxy processing server (issuance request step). Then, in step S0705, a token corresponding to the issuance request is acquired from the user terminal (token acquisition step), and in step S0706, along with the acquired token, a token related to the service usage according to the payment request is sent to the service server. The usage-related information is output based on the input acceptance rule (adaptation processing step). Thereafter, in step S0707, the payment result corresponding to the usage-related information is acquired from the service server (payment result acquisition step), and in step S0708, a message corresponding to the acquired payment result is output to the user terminal (message output step).

<Effect>
By using the service usage support system of this embodiment, it becomes possible to output usage-related information in a format that can reduce the burden on the service server, compared to the case where the service usage support system of Embodiment 1 is used. .

<<Embodiment 3>>
<Summary>
The service usage support system of this embodiment basically has the same technical features as the service usage support systems described in Embodiments 1 and 2, but when outputting usage-related information, the service server schedules payment processing. The present invention is characterized in that it also outputs payment control information for executing the above in an executable manner using the token.

<Functional configuration>
FIG. 8 is a diagram showing an example of functional blocks of the service usage support system of this embodiment. As shown in the figure, the "service usage support system" 0800 of this embodiment includes a "payment request receiving section" 0801, an "issuance requesting section" 0802, a "token acquisition section" 0803, and a "usage request section" 0801. The usage-related information output unit further includes a “payment control information output unit” 0814. Since the basic configuration is the same as the service usage support system described using FIG. 2 of the first embodiment, the function of the "payment control information output means" 0814, which is different, will be explained below.

The "payment control information output means" 0814 is configured to output payment control information for causing the service server to execute the payment processing scheduled by the service server in an executable manner using the token in the usage-related information output unit. has been done. "Payment processing scheduled by a service server" is nothing but payment processing for the purchase price of a predetermined product or service usage price that is scheduled to be accepted on the service server. Generally, payment processing is performed using a card or the like.

However, in the present invention, although the token acquisition unit has already acquired the tokens used for the payment processing scheduled for the transaction, the service server side has to acquire the tokens from the payment processing server again regardless of the circumstances. There may be cases where processing is performed to obtain the information, and such processing is not only too complicated, but also may cause an unexpected financial burden on the user due to double transactions. Therefore, once usage-related information is output together with the token acquired by the token acquisition unit, information to prevent the service server from performing the process to acquire the token again is also output. It is preferable. Therefore, it is conceivable to also output payment control information, which is information for causing the service server to execute various processes in a manner that allows payment processing to be executed using the already acquired token, to the service server. By adopting this configuration, it is possible to avoid the disadvantages of double transaction processing on the service server side.

<Specific configuration>
The hardware configuration of each device constituting the service usage support system of this embodiment is basically the same as the hardware configuration of the service usage support system of Embodiment 1 described using FIG. 4. Therefore, in the following, specific processing of the "settlement control information output means" which has not been explained so far will be explained.

(Specific configuration of payment control information output means)
The payment control information output means is specifically composed of a computer program and computer hardware, and when executing the usage-related information output program, the CPU reads out the "payment control information output subprogram" from the storage device to the main memory and executes it. , it also outputs payment control information for executing the payment processing scheduled by the service server in an executable manner using the token.

<Processing flow>
FIG. 9 is a diagram showing an example of the flow of processing in the service usage support system of this embodiment. The process flow in the figure consists of the following steps. First, in step S0901, a payment request regarding web service usage is received from a user terminal (payment request receiving step). Thereafter, in step S0902, in response to the received payment request, the user terminal is caused to transmit a token issuance request to the payment proxy processing server (issuance request step). Then, in step S0903, a token corresponding to the issuance request is acquired from the user terminal (token acquisition step), and in step S0904, along with the acquired token, information related to the service usage according to the payment request is sent to the service server. It also outputs usage-related information, which is information, and payment control information for executing the payment processing scheduled by the service server in an executable manner using the token (payment control information output substep). Thereafter, in step S0905, the payment result corresponding to the usage-related information is acquired from the service server (payment result acquisition step), and in step S0906, a message corresponding to the acquired payment result is output to the user terminal (message output step).

<Effect>
By using the service usage support system of this embodiment, compared to the case of using the service usage support systems of Embodiments 1 and 2, it is possible to avoid the harmful effects of double transaction processing on the service server side. Become.

0200...Service usage support system, 0201...Payment request receiving unit, 0202...Issuance request unit, 0203...Token acquisition unit, 0204...Usage related information output unit, 0205...Payment result Acquisition unit, 0206...Message output unit

Claims (5)

Information is exchanged between a service server, which is a server that provides a predetermined web service, a user terminal that uses the web service, and a payment processing server, which is a server that performs payment processing related to the web service. A service usage support method for sending and receiving,
a payment request receiving step of receiving a payment request regarding web service usage from a user terminal;
an issuance request step for causing the user terminal to send a token issuance request to the payment processing server in response to the received payment request;
a token acquisition step of acquiring a token corresponding to the issuance request;
a usage-related information output step of outputting usage-related information, which is information related to service usage in response to the payment request, to the service server together with the acquired token;
a payment result acquisition step of acquiring payment results corresponding to the usage-related information from the service server;
a message output step of outputting a message to the user terminal according to the acquired payment result;
A service usage support method consisting of: an input reception rule acquisition step of acquiring an input reception rule corresponding to a predetermined web service and usage-related information related to the web service;
further comprising an input reception step of receiving input of usage-related information related to the web service from a user terminal,
2. The service usage support method according to claim 1 , wherein the usage-related information output step further includes an adaptation processing substep of outputting the received usage-related information based on an input acceptance rule. 2. The usage-related information output step further comprises a payment control information output substep of also outputting payment control information for causing the service server to execute a scheduled payment process in an executable manner using the token. The service usage support method described in 2 . Information is exchanged between a service server, which is a server that provides a predetermined web service, a user terminal that uses the web service, and a payment processing server, which is a server that performs payment processing related to the web service. A service usage support program that causes a computer to send and receive information,
a payment request receiving step of receiving a payment request regarding web service usage from a user terminal;
an issuance request step for causing the user terminal to send a token issuance request to the payment processing server in response to the received payment request;
a token acquisition step of acquiring a token corresponding to the issuance request;
a usage-related information output step of outputting usage-related information, which is information related to service usage in response to the payment request, to the service server together with the acquired token;
a payment result acquisition step of acquiring payment results corresponding to the usage-related information from the service server;
a message output step of outputting a message to the user terminal according to the acquired payment result;
A service usage support program that causes a computer to execute. Information is exchanged between a service server, which is a server that provides a predetermined web service, a user terminal that uses the web service, and a payment processing server, which is a server that performs payment processing related to the web service. A service usage support system that sends and receives
a payment request receiving unit that receives a payment request regarding the use of the web service from a user terminal;
an issuance request unit that causes the user terminal to send a token issuance request to the payment processing server in response to the received payment request;
a token acquisition unit that acquires a token corresponding to the issuance request;
a usage-related information output unit that outputs usage-related information, which is information related to service usage in response to the payment request, to the service server together with the acquired token;
a payment result acquisition unit that acquires payment results corresponding to the usage-related information from the service server;
a message output unit that outputs a message to the user terminal according to the acquired payment result;
A service usage support system equipped with.