JP7653216B2 - Servers and Communication Devices - Google Patents

Description

Article 30, paragraph 2 of the Patent Act applies. Posted on the app distribution service "Google Play" on September 26, 2019. Posted on the app distribution service "App Store" on September 30, 2019.

The technical field disclosed in this specification relates to a server and a communication device capable of communicating with a program installed in the communication device.

Conventionally, a software development kit (SDK) may be provided to enable a company's functions or services to be used via another company's application program (hereinafter, in this specification, "application program" may be abbreviated to "application" or "app").

An example of a document disclosing a technique using an SDK is Patent Document 1.
discloses a camera control SDK that is used by a camera application, and further discloses a configuration in which information indicating whether the camera control SDK can be used is stored in a shared memory area that can be accessed by two different camera applications, thereby making it possible for a camera control SDK added by one camera application to be used by another camera application.

JP 2016-18501 A

Patent Literature 1 discloses a technique for managing two different camera applications using one piece of availability information, i.e., one piece of information, stored in a shared storage area when the same camera control SDK is incorporated into each of the two different camera applications. However, the information of an application and an application having a program (SDK) having at least some of the functions of the application are different applications, and therefore cannot be managed by one piece of identification information.

This specification discloses a technique that enables information based on processing from different applications that can be installed in a communication device and have at least some functions in common to be managed by a server.

The server, which has been developed to solve the above-mentioned problems,
A first application; and
A server capable of communicating with a second application having a program having at least a part of the functions of the first application installed therein,
Identification information of the first application and identification information of the second application;
Collaborate with
It is characterized by the following.

A control method for implementing the functions of the above-mentioned device, a computer program, and a computer-readable storage medium storing the computer program are also novel and useful.

The technology disclosed in this specification realizes a technology that enables information based on processing from different applications that have at least some functions in common and can be installed on a communication device to be managed using a server.

1 is a schematic configuration diagram of a payment system according to an embodiment. FIG. 2 is a block diagram showing a configuration of a mobile terminal according to an embodiment; A block diagram showing the configuration of a payment service server according to an embodiment. A diagram showing the configuration of a payment user TB held by the payment service server. A diagram showing the configuration of a payment method TB held by the payment service server. A diagram showing the configuration of an association TB possessed by the payment service server. A diagram showing the configuration of a payment TB possessed by the payment service server. A diagram showing the structure of a coupon TB held by the payment service server. FIG. 11 is a diagram showing a process flow when a login request is made from a payment application. FIG. 13 is a diagram illustrating a process flow when a login request is made from a partner app. FIG. 11 is a diagram showing a process flow when making a payment from a payment application. FIG. 13 is a diagram showing a process flow when inquiring about a payment history from a payment application. FIG. 13 is a diagram showing a process flow when inquiring about a payment history from a partner app. FIG. 13 is a diagram showing the process flow when a partner server inquires about a payment history. 13 is a flowchart showing a procedure of a coupon distribution process in the payment service server. 13 is a diagram showing a process flow when a coupon is issued from the payment service server to a partner application in response to a request from the partner server. FIG. A diagram showing the relationship between a payment user ID and other information in a payment system.

Hereinafter, a detailed description will be given of an embodiment of a payment system including a server and a communication device according to the present embodiment with reference to the accompanying drawings.

[Configuration of payment system 100]
As shown in Figure 1, the payment system 100 of this embodiment comprises a store terminal 1, a mobile terminal 2, a payment service server 3, and a partner server 4. In the payment system 100 of this embodiment, the mobile terminal 2 is capable of communicating with the payment service server 3 and the partner server 4 via a network such as the Internet. Furthermore, the payment service server 3 is capable of communicating with the mobile terminal 2, the store terminal 1, and the partner server 4 via a network such as the Internet. The mobile terminal 2 and the store terminal 1 are not directly connected on the network, but a code displayed by one can be read by the other.

The store terminal 1 is an information processing terminal installed in a store that provides products or services. The store terminal 1 is provided in each store that is affiliated with a payment service company that operates the service platform of the payment system 100.
However, in FIG. 1, only one is shown.

The mobile terminal 2 is an information processing terminal owned by a user who receives a cashless payment service through the payment system 100, and is, for example, a smartphone or a PDA.
A mobile terminal 2 exists for each user who receives the service of the payment system 100. Therefore, a plurality of mobile terminals 2 may exist in the payment system 100, but only one mobile terminal 2 is shown in Fig. 1 for simplicity. The mobile terminal 2 is an example of a communication device.

In addition, at least one of a partner app 221 and a payment app 223 is installed on the mobile terminal 2. The partner app 221 is an application provided by a company that is affiliated with the payment service company (hereinafter referred to as a "partner"). The partner operates at least one store that is equipped with a store terminal 1. The partner app 221 is an example of a second application. The payment app 223 is an application provided by the payment service company. The payment app 223 is an example of a first application.

The payment application 223 has a payment function.
When the information indicated by the terminal 3 is read by the payment application 223, or when the payment application 223 reads the information of the store terminal 1, the information of both parties is passed to the payment service server 3, and the payment can be processed by the payment service server 3. In addition, the payment application 223 has a function of checking the payment history and receiving various coupons.

A payment SDK 222 having a payment function is also built into the partner application 221. The payment SDK 222 is a program provided by a payment service company.
Payment SDK 222 is a program having at least some of the functions of payment application 223. For example, payment SDK 222 has the same payment functions as payment application 223, but has a more limited function than payment application 223 to inquire about a payment history.

It is not necessary for both the partner application 221 and the payment application 223 to be installed on the mobile terminal 2. As long as either one of the application is installed, the mobile terminal 2 can use the payment service of the payment system 100.
The mobile terminal 2 on which the payment application 223 is installed may be different from the mobile terminal 2 on which the payment application 223 is installed.

The payment service server 3 is a server managed by a payment service company, and executes payment processing. The payment service server 3 is an example of a server. The payment service server 3 has various tables (TBs). Specifically, it has a payment user TB 321 that stores information on users who receive services from the payment system 100, a payment method TB 322 that stores the payment method of each user, a linkage TB 323 that stores linkage information with partners, a payment TB 325 that stores payment information of each user, and a coupon TB 326 that stores information on currently registered coupons. Each TB may be composed of one TB, or may be composed of multiple TBs.
The details of each TB will be described later.

The partner server 4 is a server managed by the partner. The partner server 4 also has various TBs, such as a partner user TB 421 that stores information about users who receive services from the partner, and a partner collaboration TB 422 that stores information indicating collaboration with the payment system 100.

1 do not necessarily represent a single piece of hardware, and may be composed of multiple pieces of hardware. For example, in the case of the payment service server 3, the hardware (device) that performs the payment process may be different from the hardware (device) that stores various TBs.

[Hardware configuration of mobile terminal 2]
As shown in Fig. 2, the portable terminal 2 of this embodiment includes a controller 20 including a CPU 21 and a memory 22. The portable terminal 2 further includes a user interface (hereinafter referred to as "user IF") 23, a camera 24, and a communication interface (hereinafter referred to as "communication IF") 25, which are electrically connected to the controller 20.
The controller 20 therein is a general term for hardware and software used to control the portable terminal 2 , and does not necessarily represent a single piece of hardware actually present in the portable terminal 2 .

The CPU 21 executes various processes according to programs read from the memory 22 and based on user operations. The memory 22 includes a ROM and a RAM, and further includes a HDD.
The internal memory includes non-volatile memory such as a flash memory, and stores various programs and data.
The memory 22 stores, for example, a partner application 222 incorporating the payment SDK 222 described above.
21 and payment application 223 are stored.

The user IF 23 includes hardware for accepting input operations by a user and hardware for displaying information. The user IF 23 is, for example, a touch panel having both an input function and a display function. The camera 24 includes hardware for taking pictures. The communication IF 25 includes hardware for communicating with an external device.

[Hardware configuration of payment service server 3]
As shown in FIG. 3, the payment service server 3 of this embodiment includes a CPU 31, a memory 32,
The payment service server 3 further includes a controller 30 including a user IF 3.
3 and a communication IF 35, which are electrically connected to the controller 30. Note that the controller 30 in Fig. 3 is also a collective term for hardware and software used to control the payment service server 3, and does not necessarily represent a single piece of hardware actually present in the payment service server 3.

The hardware of the payment service server 3, such as the CPU 31, has almost the same functions as the various hardware of the mobile terminal 2, and the description thereof will be omitted.
For example, the payment user table 321, the payment method table 322, the link table 323, the payment
The payment service server 3 stores the user ID, the credit card ID, and the coupon ID.
It is not necessary to have an F33.

[Configuration of various TBs owned by the payment service server 3]
As shown in FIG. 4, the payment user TB 321 stores personal information of a user who receives a service of the payment system 100 as one record. A payment user ID is assigned to each record to distinguish the record. The payment user ID is used when the payment service server 3 performs a payment process. That is, the payment service server 3 uses the payment user ID
The payment user ID is an example of identification information of the first application. The personal information of the user includes contact information such as a telephone number and an email address. The personal information of the user is used as information for authenticating the user.

As shown in FIG. 5, the payment method table 322 stores the above-mentioned payment user ID and information on the payment method as one record in association with each other. A payment method ID is assigned to each record to distinguish the record. The information on the payment method includes information on the type of payment, such as credit card or bank account.
A user can register multiple payment methods, and one payment user ID can be used.
A plurality of records with different payment methods for D may be registered in the payment method table 322. For example, in Fig. 5, a user with a payment user ID of "User01" has registered two payment methods, "Method 01" and "Method 02", and selects one of them when requesting payment processing.

As shown in FIG. 6, the linkage TB 323 stores a payment user ID, which is an example of the identification information of the first application described above, and an application code that identifies the application, in association with each other as one record. Each record is assigned an association ID for distinguishing the record. The association ID and/or application code is an example of the identification information of the second application. The application code is information for distinguishing the type of partner application (or the type of payment SDK) in which the payment SDK is incorporated. An application code is not assigned to the payment application 223. A user can use multiple types of programs for payment, and multiple records with different application codes may be registered in the linkage TB 323 for one payment user ID. For example, in FIG. 6, a user with a payment user ID of "User01" is assigned an "S
The communication device has two types of partner apps, one incorporating "SDK01" and the other incorporating "SDK02." The partner apps may be installed on the same device or on separate devices. In this way, the payment user ID, which is an example of identification information of the first application, and the app code and/or association ID, which are an example of identification information of the second application, are stored in association with each other in the payment service server 3, making it possible to use the server to manage information on different applications that have at least some functions in common and can be installed on the communication device.

As shown in FIG. 7, the payment TB 325 stores the aforementioned payment user ID, the aforementioned information on the payment method, the aforementioned application code, the aforementioned linkage ID, and detailed payment information in a single record, in association with each other. A payment ID is assigned to each record to distinguish the record. When a payment is made using the payment application 223, no application code is assigned, and the application code and linkage ID are left blank. The detailed payment information may include, for example, a store ID to identify the store where the product or service was provided.
The payment includes the date, time and amount of the payment.

As shown in FIG. 8, the coupon table 326 stores the above-mentioned payment user ID, the above-mentioned application code, and detailed coupon information in a single record in association with each other.
Each record is assigned a coupon ID to distinguish the record. Detailed coupon information includes, for example, the coupon expiration date and the discount amount. The coupon is an example of a benefit. The payment user ID included in the record indicates a user who can use the coupon. In addition,
The application code indicates the source of the coupon, i.e., the source of the funds. For example, if the application code is "SD
In the case of a coupon funded by a partner that provides partner application 221 "SDK01", "SDK01" is stored in the application code field of coupon table 326. Note that in the case of a coupon funded by a payment service company, since no application code is assigned, the application code is blank and the coupon can be used in payment application 223 and partner application 221.

[Login from payment application 223]
Next, the procedure for logging in to the payment service server 3 from the payment application 223 will be described with reference to FIG.
In this embodiment, in order to perform a payment from the payment application 223, the payment application 223 needs to be logged in to the payment service server 3. Note that in this specification, the process performed by the payment application 223 is a process executed by the CPU 21 of the mobile terminal 2, and the process performed by the payment service server 3 is a process executed by the CPU 31 of the payment service server 3.

During startup, the payment application 223 accepts an operation for logging in to the payment service server 3, i.e., a login request (S01).
The payment application 223 also accepts input of a phone number and an email address as personal information of the user. Upon accepting the login request, the payment application 223 transmits the login request together with the input personal information to the payment service server 3 (S02).

When the payment service server 3 accepts the login request, it creates a payment user ID (
S03). Then, the created payment user ID is registered in the payment user TB 321 together with the personal information attached to the login request (S04).

After that, the payment service server 3 transmits the access token as authentication information to the payment application 223 that made the login request (S05).
The period is managed by the payment service server 3 in memory 32 in association with the payment user ID.
is stored in.

If there is a payment user ID in which personal information matching the personal information attached to the login request is stored, S03 and S04 are omitted. Then, the access token is updated, the access token is stored in association with the payment user ID, and the access token is further transmitted to the payment application 223.

Meanwhile, the payment application 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). Thereafter, when requesting a payment, the payment application 223 uses the authentication information stored in the memory 22.

In addition, when making a payment request, the payment application 223 also accepts input of information regarding a payment method before making a payment request, and stores the input information regarding the payment method in the memory 22.
The payment service server 3 transmits the information on the input payment method together with the authentication information stored in the payment method table 322 to the payment service server 3. When the payment service server 3 receives the information on the input payment method, it extracts the payment user ID associated with the authentication information, and registers the received information on the payment method in the payment method table 322 in association with the payment user ID.

[Login from Partner App 221]
Next, the procedure for logging in to the payment service server 3 from the partner app 221 will be described with reference to FIG. 10. In this embodiment, even when making a payment from the partner app 221, the partner app 221 needs to be logged in to the payment service server 3. When logging in from the partner app 221, the partner app 221 starts the payment SDK 222, and logs in to the payment service server 3 via the payment SDK 222. Therefore, the processing of the partner app 221 will be described separately as processing by the payment SDK 222 and processing by the partner app 221 other than the payment SDK 222. Note that the processing performed by the partner app 221 and the payment SDK 222 in this specification is processing executed by the CPU 21 of the mobile terminal 2.

The payment SDK 222 accepts a login request during startup (S11). In S11, the startup request of the payment SDK 222 may also serve as a login request. Upon accepting the login request, the payment SDK 222 transmits a request to transmit an application code to the partner server 4 via the partner application 221 (S12).

When the partner server 4 receives the request to send the application code, it transmits a login request to the payment service server 3 via the payment SDK 222 (S13). The login request is accompanied by the application code of the partner application 221 that is stored in advance in the partner server 4. Specifically, in S13, the payment SDK 222 temporarily receives the login request from the partner server 4, sets the URL of an authentication page held by the payment service server 3 and the application code as startup options, and starts the browser held by the mobile terminal 2. As a result, the payment service server 3 receives the application code and accepts personal information of the user as information for logging in.

When the personal information is input, the payment service server 3 creates a payment user ID (S1
4) Then, the created payment user ID is sent to the payment user T together with the input personal information.
Furthermore, the payment service server 3 creates an association ID (S16), and then registers the created association ID in the association TB 323 together with the payment user ID created in S14 and the received application code (S17).

Thereafter, the payment service server 3 transmits the access token as authentication information to the partner server 4 that made the login request (S18). The authentication information is subject to expiration management by the payment service server 3 and is stored in the memory 32 of the payment service server 3 in association with the payment user ID and the application code.

If there is a payment user ID in which personal information matching the personal information attached to the login request is stored, steps S14 to S17 are omitted. Then, the access token is updated, the access token is stored in association with the payment user ID, and the access token is further transmitted to the partner server 4. Even if there is a payment user ID in which personal information matching the personal information attached to the login request is stored, steps S16 and S17 are performed if a linked ID is not registered.

The partner server 4, which has received the authentication information from the payment service server 3, transmits the received authentication information to the payment SDK 222 via the partner application 221 (S19),
The DK 222 stores the authentication information sent from the partner server 4 in the memory 22 (S2
0). Thereafter, when the payment SDK 222 requests payment, it uses the authentication information stored in the memory 22. Also, when the partner application 221 requests a process of verifying a payment history, it uses the authentication information stored in the memory 22.

In addition, when requesting payment processing, the payment SDK 222 of the partner application 221 also accepts input of information related to the payment method before making a request for payment processing, and transmits the input information about the payment method to the payment service server 3 together with the authentication information stored in the memory 22. When the payment service server 3 receives the input information about the payment method, it extracts the payment user ID associated with the authentication information, and registers the received information about the payment method in the payment method TB 322 in association with the payment user ID.

After the login is successful, the partner application 221 transmits a command to transmit the linked ID together with the authentication information to the payment service server 3 via the payment SDK 222 (S21) as shown in Fig. 10 in order to make the linked ID available on the partner server 4. Upon receiving the command to transmit the linked ID, the payment service server 3 extracts a combination of the payment user ID and the application code associated with the authentication information, and transmits the linked ID associated with the combination to the payment SDK 222 (S22), which is received by the partner application 221 via the payment SDK 222. The partner application 221 transmits the linked ID received from the payment service server 3 to the partner server 4 (S23). Note that the linked ID may be transmitted directly from the payment service server 3 to the partner server 4.

The partner server 4 stores the received association ID in the memory of the partner server 4 (
S24). Specifically, the partner application 221 transmits a partner user ID for the partner to manage the user together with the association ID to the partner server 4. The partner user ID is registered in the partner user table 421 (see FIG. 1).
The partner server 4 associates the received association ID with the partner user ID also received, and registers the association ID in the partner association table 422 .

[Payment procedure from payment application 223]
Next, a procedure for making a payment from the payment application 223 will be described with reference to FIG.
The payment application 223 receives an instruction for code payment (S31). This instruction for code payment means a payment request from the payment application 223. Then, when the instruction for code payment is received, a code request for sending a code is sent to the payment service server 3 together with the authentication information stored in the memory 22 (S32).

When the payment service server 3 receives the code request, it creates a two-dimensional code including code identification information for identifying each two-dimensional code, and temporarily stores the code identification information in association with the authentication information (S33). The two-dimensional code may be any code that can include code identification information, such as a barcode or a QR code (registered trademark). The created two-dimensional code is then sent to the payment application 223 (S34). The payment application 223, which has received the two-dimensional code from the payment service server 3, transfers the received two-dimensional code to the user IF of the mobile terminal 2.
23 (S35).

Meanwhile, at the store, the amount is input to the store terminal 1 (S36). After the amount is input, the store terminal 1 reads the two-dimensional code displayed on the mobile terminal 2 (S37).
). The store terminal 1 then analyzes the two-dimensional code, extracts the code identification information contained in the two-dimensional code, and transmits the extracted code identification information, the input amount, and the pre-registered store ID to the payment service server 3 (S38).

When the payment service server 3 receives the code identification information, the amount, and the store ID from the store terminal 1, it extracts the authentication information associated with the code identification information, extracts the payment user ID associated with the authentication information, extracts the payment method associated with the payment user ID, and performs payment processing (S39).Then, it registers the payment information including the extracted payment user ID and payment method, the received amount, store ID, and date and time in the payment TB 325 (S40).

After the payment process is completed, the payment service server 3 sends a push notification to the payment application 223 to notify the user of the payment (S41), and sends a message to the store terminal 1 to notify the store of the payment (S42).

When performing payment processing from the partner application 221 via the payment SDK 222, the payment SDK 222 transmits a code request and authentication information to the payment service server 3 in the same manner as the payment application 223. The payment service server 3 then extracts an application code together with a payment user ID from the authentication information, and registers the payment information, which includes the application code and an association ID extracted from the association TB 323 based on the application code and the payment user ID, in the payment TB 325, thereby completing the payment processing.
Even when performing payment processing via K222, the payment user ID, which is an example of identification information of the first application, is used instead of the linkage ID, which is an example of identification information of the second application.
and the payment method associated with the payment method table 322. In this way, even when the payment process is performed from the partner application 221, the payment is performed using the payment user ID, which eliminates the need to register payment information for each partner application 221, improving user convenience. In addition, as described below, it becomes possible to differentiate the payment history inquiry function between the payment application 223 and the partner application 221.

In addition, the payment procedure shown in FIG. 11 is a process of displaying a two-dimensional code on the mobile terminal 2 and
In this case, the store terminal 1 sends a code request including the amount and store ID to the payment service server 3, and the store terminal 1 displays the two-dimensional code sent from the payment service server 3. When the payment application 223 reads the two-dimensional code, it sends specific information of the two-dimensional code together with authentication information to the payment service server 3, extracts the payment user ID and the like from the authentication information, and performs payment processing.

[Querying payment history from payment application 223]
Next, the procedure for making a payment history inquiry from the payment application 223 will be described with reference to Fig. 12. The payment application 223 receives an instruction to inquire about the payment history (S101). Then, upon receiving the inquiry, the payment application 223 transmits an inquiry request for sending the payment history together with the authentication information stored in the memory 22 to the payment service server 3 (S102).

When the payment service server 3 receives the inquiry request, it extracts the payment user ID associated with the authentication information, and further extracts the payment information associated with the payment user ID from the payment TB 325 (S103). In S103, it extracts all payment information linked to the extracted payment user ID, regardless of which application the payment process was performed from. That is, in the case of an inquiry request from the payment application 223, the payment service server 3 extracts both the payment from the payment application 223 and the payment from the partner application 221. Then, it transmits the extracted payment information to the payment application 223 (S104).

When the payment application 223 receives the payment information from the payment service server 3, it displays the received payment information in a list on the user IF 23 (S105). The payment information received by the payment application 223 does not include a payment user ID or a linkage ID. It is also not necessary to include an application code. However, if an application code is included, the payment application 223 can display the payment information for each application for which a payment has been made.

[Checking payment history from partner app 221]
Next, a procedure for inquiring about a payment history from the partner application 221 via the payment SDK 222 will be described with reference to Fig. 13. The partner application 221 receives an instruction to inquire about a payment history (S111). Upon receiving the instruction, the partner application 221 transmits an inquiry request for sending the payment history together with the authentication information stored in the memory 22 to the payment service server 3 via the payment SDK 222 (S112).

When the payment service server 3 receives a query request from the partner application 221 via the payment SDK 222, it extracts the payment user ID and application code associated with the authentication information, and further, stores the payment information associated with the payment user ID and the application code in the payment TB 3.
25 (S113). In S113, in addition to the payment user ID, the payment processes to be extracted are limited by the application code, and even if the payment user ID matches, payment information of payments made by other applications is not extracted. In other words, in the case of a query request from the partner application 221, the payment service server 3 extracts only payments made by the partner application 221 of the user who uses that partner application 221. Then, the extracted payment information is sent to the payment SDK 222 of the partner application 221 (S114).

When the partner application 221 receives the payment information from the payment service server 3 via the payment SDK 222, the partner application 221 causes the received payment information to be displayed in a list on the user IF 23 (S115).
The payment information received by the partner application 221 does not include payment information from other applications. Therefore, the user is less likely to be confused.
The application code and the associated ID are not included. The reason why the application code is not included is that when the partner application 221 inquires about the payment history via the payment SDK 222, the payment service server 3 uses the application code to transmit only the payment history by the partner application 221. Therefore, information related to the application code is not necessary, and the amount of data can be reduced by not transmitting the application code.

[Payment History Inquiry from Partner Server 4]
Next, the procedure for making an inquiry about a payment history from the partner server 4 will be described with reference to FIG. 14. The partner server 4 receives an instruction to make an inquiry about a payment history from an external device (S1
21). Then, upon receiving the inquiry instruction, the application processor 1 transmits an inquiry request for requesting transmission of the payment history together with the application code to the payment service server 3 (S122).

When the payment service server 3 receives the inquiry request from the partner server 4, it extracts the payment information associated with the received application code from the payment TB 325 (S123).
In the case of 123, the payments extracted are limited by the application code, and payment information of payments made by other applications is not extracted.
The payment service server 3 extracts only the payment from the partner application 221 without identifying the user. Then, the payment service server 3 transmits the extracted payment information to the partner server 4 (S124).

When the partner server 4 receives the payment information from the payment service server 3, it transmits the received payment information to the external device that transmitted the inquiry instruction (S125). The received payment information does not include payment information processed using the payment application 223 and the partner application 221 of another partner (another company). Therefore, the partner server 4 can obtain only information about its own company, making it easy to use the payment information. Note that the payment information received by the partner server 4 does not include the payment user ID and the application code, but does include the linkage ID.
The partner server 4 stores the linked ID in association with the partner user ID, and therefore can distinguish the payment information for each partner user ID. Therefore, in response to a request from an external device to transmit payment information for a specific partner user ID, the partner server 4 can transmit only the payment information corresponding to the specific partner user ID. Since the partner server 4 can obtain payment information for each partner user ID using the linked ID, it can analyze, for example, the store (location), time period, and price range where a user having a partner user ID purchases a partner's product or service, and can provide advertisements and services suitable for the user.

In FIG. 14, the partner server 4
However, the inquiry request may be transmitted not based on an instruction from an external device, for example, by outputting the inquiry request periodically.

[Distribution of coupons by payment service server 3]
Next, the procedure for distributing coupons by the payment service server 3 will be described with reference to Fig. 15. Note that each coupon is pre-registered in the coupon TB 326 as shown in Fig. 5, and the payment service server 3 individually accepts a request to distribute each registered coupon. Then, every time the payment service server 3 accepts a request to distribute a coupon, it executes the coupon distribution process shown in Fig. 15.

In the coupon distribution process, the payment service server 3 first reads information on the coupon to be distributed from the coupon TB 326 (S201). Then, it determines whether or not an application code is specified for the coupon to be distributed (S202). In this embodiment, an application code is assigned to a coupon funded by a partner, and an application code is not assigned to a coupon funded by a payment service company. Therefore, in S202, it is determined whether or not the source of the coupon is a partner. A coupon funded by a payment service company is an example of a first benefit,
A coupon funded by a partner is an example of a secondary benefit.

In the case of a coupon for which no application code is specified, i.e., in the case of a coupon for which the payment service company is the source of funds (S202: NO), the payment service server 3 delivers a message and a push notification of the coupon to the payment application 223 (S203). In addition, the payment service server 3 refers to the linkage table 323, extracts an application code associated with the payment user ID specified in the coupon, and retrieves the application code of the partner application 221 corresponding to the extracted application code.
A coupon message is delivered to the recipient (S204).

Although the coupons of the payment service company's funds can be used from the partner app 221, which improves usability, a user who has both the partner app 221 and the payment app 223 installed on the same mobile terminal 2 will receive multiple similar push notifications. Therefore, push notifications are not sent to the partner app, and the strength of notifications to the partner app 221 is weakened compared to notifications to the payment app 223, thereby reducing the annoyance of the user of receiving multiple notifications.

On the other hand, if the coupon is specified with an application code, i.e., if the coupon is a partner's original fund coupon (S202: YES), the payment service server 3 delivers a message and a push notification of the coupon to the partner application 221 corresponding to the application code (
S205). The coupon of the partner's original funds is not delivered to the payment application 223. S20
After step S205 or S204, the coupon distribution process ends.

In this way, the coupons are distributed to different recipients depending on whether the source of funds is a partner or not.
Partner application 221 can use coupons of the partner's funds and coupons of the payment service company's funds. On the other hand, payment application 223 can use only coupons of the payment service company's funds. For example, when all coupons registered in coupon table 326 shown in FIG. 8 are distributed, partner application 221 with application code "SDK01" can use
In 21, the coupons "CP01" and "CP04" have the app code "SDK01".
In addition, "CP03", which is a coupon without an application code, is also displayed as available.
In addition to the coupon "CP02" for "K02", there is a coupon without an app code "C
On the other hand, in the payment application 223, only "CP03", which is a coupon without an application code, is displayed as available.
It is sufficient that the coupon can be used in the partner application 221.

In addition, the coupon of the payment service company is associated with the payment user ID.
For example, the coupons of the payment service company can be used by both the payment application 223 and the partner application 222.
However, if the coupon is used in one app, the coupon will disappear and it will no longer be usable in the other app. By associating the coupon with the payment user ID in this way, it is possible to prevent the coupon from being used twice.
The coupon for the partner resource is associated with not only the payment user ID but also the application code. Therefore, the coupon for the partner resource is associated with the partner application 22 that provides the resource.
Coupons can only be used from 1. Furthermore, since they are also associated with the payment user ID, it is possible to prevent the coupon from being used twice.

[Partner points are converted into coupons and distributed]
Next, the procedure for converting partner points into coupons and distributing them will be described with reference to FIG. 16. Note that the payment service server 3 has multiple payment discount coupons registered in advance as partner fund coupons.
The coupons are for 0 yen discount, 1000 yen discount, etc.
The information on the coupon for the partner's original funds is obtained from the settlement service server 3.

The partner application 221 obtains the coupon information from the partner server 4,
The partner application 2 receives an instruction to issue the coupons from the user (S301).
When the coupon issuing unit 21 accepts an instruction to issue a coupon, the coupon issuing unit 21 transmits a coupon issuing request including coupon information indicating the coupon to the partner server 4 (S302).

When the partner server 4 receives the coupon issuance request, the partner server 4
The coupon issuing request is then sent to the payment service server 3 (S303). The coupon issuing request includes the acquired association ID and coupon information indicating the coupon for which the issuing instruction has been accepted.
4) If the partner does not have enough points to be converted into the selected coupon, a response is sent to the partner application 221 notifying that the coupon cannot be issued.

When the payment service server 3 receives the coupon issuance request, it refers to the linkage table 323,
The payment service server 3 acquires a payment user ID and an application code from the associated ID included in the coupon issuance request (S305).
A coupon including the acquired payment user ID and application code and corresponding to the content indicated by the coupon information included in the coupon issuance request is extracted and issued (
S306).

After S306, the payment service server 3 sends a coupon issuance notification to the partner server 4, indicating that the coupon has been issued. When the partner server 4 receives the coupon issuance notification, it consumes the points corresponding to the coupon from among the points that the user has as a partner benefit (S307). For example, if the partner converts 10 points to 1 yen, when it receives an instruction to issue a coupon for a 100 yen discount, 10 points x 100 yen = 1000 points are subtracted from the user's points.

In addition, since the coupon issued in S306 is a coupon of the partner resource, the coupon is issued only to the partner application 221. Therefore, after the coupon is issued in S306, the coupon can be used when making a payment with the payment SDK 222 of the partner application 221 (S308).

In the payment system 100 of this embodiment, although the partner server 4 can directly communicate with the partner application 221, it issues coupons via the payment service server 3 and the payment SDK 222. That is, in the payment system 100 of this embodiment, a coupon of the partner resource is registered in advance in the payment service server 3 based on a coupon issuance request.
Furthermore, the user can check the issuance of a coupon based on a coupon issuance request on the payment SDK 222. Therefore, when making a payment with the partner application 221, the payment service server 3 can perform a payment process using a coupon without communicating with the partner server 4 in order to use partner points. Furthermore, the coupon requested for distribution via the partner application 221 can be easily selected on the payment SDK 222. In this way, the payment time and the number of communications can be reduced.

As described above in detail, in the payment system 100 of this embodiment, even if different applications are used, the identification information of both applications can be linked on the server. By linking the identification information of both applications, an application can be linked with another application that incorporates a program (SDK) having at least some of the functions of the application.

Then, linked to the payment user ID, the payment application 223 also transmits the payment information to the partner application 221.
Payment can also be made from the partner app 221. As shown in FIG. 17, payment information of a payment made from the partner app 221 is also linked to an association ID and associated with a payment user ID. Furthermore, when there are multiple partner apps 221, an association ID is assigned to each partner app. For example, the partner app 221(a) is assigned an association ID of "Association 01",
The partner application 221(b) is assigned an association ID of “Association 02.” Therefore, it is possible to distinguish which partner application the payment is made through based on the association ID.

In the payment system 100 of this embodiment, the payment service server 3 that can communicate with both the payment application 223 and the partner application 221 has a linkage table 323.
With this configuration, for example, even the partner server 4 that does not know the payment user ID can obtain and use payment information linked to the payment user ID by using the linked ID.

In addition, in the payment system 100 of this embodiment, the partner server 4 knows the linked ID but does not know the payment user ID, and is not directly linked to the payment method, telephone number, etc. associated with the payment user ID. Therefore, the security of the payment method and telephone number associated with the payment user ID is high. In this way, since the partner server 4 is not directly linked to the payment user ID, information on the payment service server 3 can be provided to the partner server 4 with low risk.

In addition, in the payment system 100 of this embodiment, for an application having a payment function,
By consolidating payments using a payment user ID rather than having each app have an individual user ID, payment requests from multiple applications or programs can be managed with one identification information. Furthermore, since payment processing is performed with one identification information, there is no need to register a payment method for each application or program that has a payment function, reducing the burden on users.

Furthermore, if payments can be made from a plurality of applications, some of which are different, the user may become confused if payments from other applications are also compared when comparing the payment history.

In the payment system 100 of this embodiment, the payment application 223 can acquire all payment information including payments from the partner application 221, while the partner application 221 acquires only payments from the partner application 221. Therefore, the partner only discloses its own payments to the user, which can avoid user confusion, and even when the partner application 221 independently grants points or the like based on the payment history of the partner application 221, only the payment history of the partner application 221 is disclosed, which can avoid user confusion. In addition, the payment application 223 acquires all payment histories using its own payment service. Therefore, the user can view all payment histories at a glance, which improves convenience.

In addition, in the payment system 100 of this embodiment, even if the partner server 4 that communicates with the partner application 221 directly requests to inquire about the payment history, the partner server 4 only obtains the payment from the partner application 221. Therefore, only the payment made using the company's application can be obtained, and the payment history for the company's application can be used for other services. For example, it becomes possible to display advertisements that utilize purchase information such as the type of product purchased, the time period, and the price range.

In addition, if payment can be made through multiple applications, some of which are different, and each company can issue special benefits such as coupons, users may become confused if another company's coupon is displayed in their own company's application.

In the payment system 100 of this embodiment, the coupons of the payment service company are used as the payment application 2.
23 and partner application 221, and a coupon for the partner's resource is delivered only to the partner's partner application 221. By changing the delivery destination of the coupon for each resource in this way, a coupon for another company's resource will not reach the partner's application, reducing confusion for users.

In the payment system 100 of this embodiment, a coupon based on a coupon issuance request from the partner server 4 can be used by the payment SDK 222 incorporated in the partner application 221 via the payment service server 3. Coupons based on partner points are registered in the payment service server 3 before the coupon is used at the user's store. Therefore, at the time of the user's payment, the payment service server 3 can execute a payment process using the coupon without communicating with the partner server 4, thereby reducing the payment time and the number of communications.

It should be noted that the present embodiment is merely an example and does not limit the present invention in any way. Naturally, the present invention can be modified and changed in various ways without departing from the scope of the present invention.
For example, the device on which each application is installed is not limited to a mobile terminal, but may also be a desktop PC.
The terminal may be a fixed terminal such as a

In the embodiment, the payment SDK 222 is built into the partner application 221 from the beginning. However, for example, the payment service server 3 may store the payment SDK 222 and the mobile terminal 2 may execute the payment SDK.
downloads the payment SDK 222 from the payment service server 3 and installs the payment SDK 222 on the partner application 22
1, the payment SDK 222 may be added and incorporated later.

In the embodiment, the partner application 221 and the payment SDK 222 use the authentication information to make a payment request or a payment information inquiry request to the payment service server 3.
Since the linked ID and the payment user ID are associated with each other in the mobile terminal 2, the linked ID may be stored in the mobile terminal 2, and a payment request or a payment information inquiry request may be made to the payment service server 3 using the linked ID.

In the embodiment, an application code is not assigned to the payment application 223. However, an application code may be assigned to the payment application 223 so that information on the payment application 223 can be clearly stored in the payment TB 325, etc. In this case, for example, when logging in from the payment application 223,
In addition, in the payment TB 325, a record associating the payment user ID with the application code of the payment application 223 may be stored. In addition, for example, when a payment process is performed based on a payment request from the payment application 223, the application code and the linkage ID of the payment application 223 may be stored in the payment TB 325.

In addition, the configurations of the various TBs described in the embodiment are merely examples, and modifications are possible within the scope of feasibility. For example, the coupon TB 326 in the embodiment may be provided with an item for the time of issue. Also, for example, the coupon TB 326 in the embodiment includes a payment user ID for specifying the issue destination, but instead of including the payment user ID in the coupon TB 326, a separate TB for managing the issue destination of the coupon may be prepared, and the coupon ID and the payment user ID may be stored in the separate TB.
In this case, the issuance time may be managed in a separate TB.

The authentication method described in the embodiment is merely an example, and is not limited to the procedure in the embodiment. For example, if the authentication method uses OAuth 2.0, the execution contents can be changed as desired.

In addition, in any of the flowcharts disclosed in the embodiments, the order of execution of multiple processes in any of the steps can be arbitrarily changed or the processes can be executed in parallel as long as no contradiction occurs in the process content.

The processes disclosed in the embodiments may be executed by a single CPU, multiple CPUs, hardware such as an ASIC, or a combination of these. The processes disclosed in the embodiments may be realized in various forms, such as a recording medium on which a program for executing the processes is recorded, or a method.

1 Store terminal 2 Mobile terminal 3 Payment service server 4 Partner server 100 Payment system 221 Partner application 222 Payment SDK
223 Payment application 323 Linked TB
325 Settlement TB
326 Coupon TB

Claims (10)

In the information processing device,
acquiring the first payment information by a first payment means executed by a first application and the second payment information by a second payment means executed by a second application from an information processing device different from the information processing device;
when an operation for requesting display of a payment history using the second payment means is received on the second application , displaying both a payment history based on the second payment information and a payment history based on the first payment information;
A program that executes the following. The first payment means and the second payment means are provided by the same payment service.
The program according to claim 1. In the information processing device,
transmitting a payment request by the first payment means;
and transmitting a payment request by the second payment means.
The payment request by the first payment means and the payment request by the second payment means are transmitted to the same server.
3. The program according to claim 1 or 2 . An information processing device,
acquiring the first payment information by a first payment means executed by a first application and the second payment information by a second payment means executed by a second application from an information processing device different from the information processing device;
when an operation for requesting display of a payment history using the second payment means is received on the second application , displaying both a payment history based on the second payment information and a payment history based on the first payment information ;
An information processing method for performing the above. An information processing device,
acquiring the first payment information by a first payment means executed by a first application and the second payment information by a second payment means executed by a second application from an information processing device different from the information processing device;
when an operation for requesting display of a payment history using the second payment means is received on the second application , displaying both a payment history based on the second payment information and a payment history based on the first payment information ;
An information processing device that executes the above. An information processing device,
storing first payment information by a first payment means and second payment information by a second payment means;
When a request to display a payment history using the first payment means is received, displaying a payment history based on the first payment information ;
when a request to display a payment history using the second payment means is acquired, displaying a payment history based on the second payment information and a payment history based on the first payment information ;
An information processing method for performing the above. The first payment means and the second payment means are provided by the same payment service.
The information processing method according to claim 6 . The first payment means and the second payment means are included in different applications.
8. The information processing method according to claim 6 or 7 . In the information processing device,
Associating a first payment means with a second payment means;
storing first payment information by the first payment means and second payment information by the second payment means;
When a request to display a payment history using the first payment means is received, displaying a payment history based on the first payment information ;
when a request to display a payment history using the second payment means is acquired, displaying a payment history based on the second payment information and a payment history based on the first payment information ;
A program that executes the following. Associating a first payment means with a second payment means;
storing first payment information by the first payment means and second payment information by the second payment means;
When a request to display a payment history using the first payment means is received, displaying a payment history based on the first payment information ;
when a request to display a payment history using the second payment means is acquired, displaying a payment history based on the second payment information and a payment history based on the first payment information ;
An information processing device that executes the above.

Images