Server and communication device

Abstract

To provide a technique capable of managing, using a server, information based on processing from mutually different applications which can use in common at least some functions installable in a communication device.SOLUTION: A settlement system 100 comprises a settlement service server 3 which can communicate with a settlement application 223 and a partner application 221 into which a settlement SDK 222 having at least some functions of the settlement application 223 is incorporated. The settlement service server 3 stores, in a cooperation TB 323, a settlement user ID for identifying the settlement application 223, a cooperation ID for identifying the partner application 221, and an application code in association with one another.SELECTED DRAWING: Figure 17

Description

Technical Field

[0001] The technical field disclosed in this specification relates to a program installed in a communication device, a server capable of communication, and a communication device.

Background Art

[0002] Conventionally, in order to make a company's functions or services available via another company's application program (hereinafter, in this specification, the "application program" may be abbreviated as "application" or "app"), a software development kit (SDK) may be provided. For example, Patent Document 1 is a document that discloses a technology using an SDK. In Patent Document 1, a camera control SDK used from a camera app is disclosed, and information indicating whether the camera control SDK can be used is stored in a shared storage area accessible from two different camera apps. By doing so, a configuration is disclosed in which the camera control SDK added in one camera app can be used in another camera app.

[0003]

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In Patent Document 1, the same camera control SDK is respectively used in two different camera apps. ​​​​​​​​When incorporated, it discloses a technique for managing two different camera applications using one piece of availability information stored in a shared memory area, that is, one piece of information. However, since the information of an application and an application having a program (SDK) with at least a part of the functions of the application are information of different applications, they cannot be managed with one piece of identification information.

[0006] This specification discloses a technique for making it possible to manage information based on processing from different applications having at least some functions in common that can be installed in a communication device, using a server.

Means for Solving the Problem

[0007] A server made for solving the above-described problems is a first application, and a second application in which a program having at least a part of the functions of the first application is incorporated, and in a server capable of communicating, characterized by associating the identification information of the first application and the identification information of the second application.

[0008] A control method, a computer program, and a computer-readable storage medium storing the computer program for realizing the functions of the above-described device are also novel and useful.

Advantages of the Invention

[0009] According to the technique disclosed in this specification, at least one Information based on processing from different applications with common functions of a section is made manageable using a server A technology is realized that enables this

Brief Description of Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

[0011] The following is a detailed description of a payment system including a server and a communication device according to the present embodiment. The embodiments will be described in detail with reference to the accompanying drawings.

[0012] [Configuration of payment system 100] As shown in FIG. 1, the payment system 100 of this embodiment includes a store terminal 1, a mobile terminal 2, and a payment The payment system 100 of this embodiment includes a payment service server 3 and a partner server 4. The mobile terminal 2 communicates with the payment service server 3 and the partner server 4 via the Internet, etc. The payment service server 3 can communicate with the mobile terminal via the network. In addition to the terminal 2, the store terminal 1 and the partner server 4 are also connected via a network such as the Internet. The mobile terminal 2 and the store terminal 1 are directly connected to each other on the network. Although they are not connected to each other, the code displayed by one side can be read by the other side.

[0013] The store terminal 1 is an information processing terminal installed in a store that provides products or services. The store terminal 1 is a payment service provider that operates a platform for the payment system 100. The store terminal 1 is provided in each store that is affiliated with the payment system 100. There may be multiple units in the same system, but only one unit is shown in FIG.

[0014] The mobile terminal 2 is an information processing terminal owned by a user who receives a cashless payment service by the payment system 100, and is, for example, a smartphone or a PDA. The mobile terminal 2 also exists for each user who receives the service of the payment system 100. Therefore, although there may be a plurality of mobile terminals 2 within the payment system 100, only one is shown in FIG. 1 with the others omitted. The mobile terminal 2 is an example of a communication device. Also, at least one of a partner app 221 and a payment app 223 is installed in the mobile terminal 2. The partner app 221 is an application provided by a company that has partnered with a payment service company (hereinafter referred to as a "partner"). The partner operates at least one of the stores equipped with the store terminal 1. The partner app 221 is an example of a second application. The payment app 223 is an application provided by a payment service company. The payment app 223 is an example of a first application. The payment app 223 has a payment function. That is, by causing the store terminal 1 to read the information indicated by the payment app 223 or the payment app 223 to read the information of the store terminal 1, the mutual information is passed to the payment service server 3, and payment processing by the payment service server 3 can be received. In addition, the payment app 223 has a function of inquiring about payment history and receiving various coupons. Also, a payment SDK 222 having a payment function is incorporated in the partner app 221. The payment SDK 222 is a program provided by a payment service company.

[0015]

[0016]

[0017] ​​​​​​​​​​​​​​​ The payment SDK 222 is a program that has at least some functions of the payment app 223. . For example, while the payment SDK 222 has a payment function equivalent to that of the payment app 223, part of the function of querying the payment history is more restricted than that of the payment app 223.

[0018] Note that the mobile terminal 2 does not necessarily need to have both the partner app 221 and the payment app 223 installed. As long as either one is installed, the payment service of the payment system 100 can be used. That is, the mobile terminal 2 with the partner app 221 installed and the mobile terminal 2 with the payment app 223 installed may be different.

[0019] 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, a payment user TB 321 that stores information of users who receive the services of the payment system 100, a payment method TB 322 that stores the payment methods of each user, a cooperation TB 323 that stores cooperation information with partners, a payment TB 325 that stores the payment information of each user, and a coupon TB 326 that stores information of currently registered coupons. Each TB may be composed of one TB or may be a concatenation of multiple TBs. Details of each TB will be described later.

[0020] The partner server 4 is a server managed by a partner. The partner server 4 also has various TBs. For example, it stores information of users who receive the services of the partner. It has a partner user TB421 and a toner link TB422 that stores information indicating the cooperation between the partner user TB421 and the payment system 100.

[0021] Note that the payment service server 3 and the partner server 4 in FIG. 1 do not necessarily represent a single piece of hardware and may be composed of a plurality of pieces of hardware. For example, in the case of the payment service server 3, the hardware (device) for performing payment processing and the hardware (device) for storing various TBs may be different.

[0022] [Configuration of the hardware of the mobile terminal 2] As shown in FIG. 2, the mobile terminal 2 of this embodiment includes a controller 20 including a CPU 21 and a memory 22. Further, the mobile terminal 2 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, and these are electrically connected to the controller 20. Note that the controller 20 in FIG. 2 is a general term for the hardware and software used for controlling the mobile terminal 2 and does not necessarily represent a single piece of hardware actually existing in the mobile terminal 2.

[0023] The CPU 21 executes various processes according to the program read from the memory 22 and based on the user's operations. The memory 22 includes a ROM, a RAM, and further includes a non-volatile memory such as an HDD and a flash memory, and stores various programs and data. For example, the memory 22 stores the partner app 221 in which the aforementioned payment SDK 222 is incorporated and the payment app 223.

[0024] The user IF 23 includes hardware for receiving input operations by the user and hardware for displaying information. For example, the user IF 23 corresponds to a touch panel having both an input function and a display function. The camera 24 includes hardware for performing photography. The communication IF 25 includes hardware for communicating with an external device.

[0025] [Configuration of the hardware of the settlement service server 3] As shown in FIG. 3, the settlement service server 3 of this embodiment includes a CPU 31, a memory 32, and a controller 30 including them. Further, the settlement service server 3 includes a user IF 33 and a communication IF 35, and these are electrically connected to the controller 30. Note that the controller 30 in FIG. 3 is also a general term for the hardware and software used for the control of the settlement service server 3, and does not necessarily represent a single piece of hardware actually existing in the settlement service server 3. The hardware such as the CPU 31 that constitutes the settlement service server 3 has substantially the same functions as the various hardware provided in the mobile terminal 2, and thus the description thereof is omitted. Note that the memory 32 stores, for example, the aforementioned settlement user TB 321, settlement method TB 322, cooperation TB 323, settlement TB 325, and coupon TB 326. Also, the settlement service server 3 may not include the user IF 33.

[0026]

[0027] [Configuration of various TBs included in the settlement service server 3] As shown in FIG. 4, the settlement user TB 321 stores the personal information of the user who receives the service of the settlement system 100 as one record. Each record has a record identifier for identifying the record. ​A payment user ID for identification is assigned. The payment user ID is used when the payment service server 3 performs payment processing. That is, the payment service server 3 distinguishes users by payment user ID for each. The payment user ID is an example of the identification information of the first application Personal information of the user includes contact information such as a phone number and an email address The personal information of the user is used as information for authenticating the user.

[0028] As shown in FIG. 5, the payment method TB322 stores the above-described payment user ID and information related to the payment method as one record in an associated manner. Each record is assigned a payment method ID for distinguishing the record. Information related to the payment method includes information related to the type of payment, such as a credit card and a bank account. A user using the payment system 100 of this embodiment can register a plurality of payment methods, and a plurality of records with different payment methods may be registered in the payment method TB322 for one payment user ID 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.

[0029] As shown in FIG. 6, the linkage TB323 stores the payment user ID, which is an example of the identification information of the first application described above, and an app code for identifying the app as one record in an associated manner. Each record is assigned a linkage ID for distinguishing the record. The linkage ID and / or the app code are an example of the identification information of the ​It is. The app code is information for distinguishing the type of partner app (or the type of payment SDK) in which the payment SDK is incorporated. The payment app 223 does not have an app code assigned. A user can use multiple types of programs for payment, and multiple records with different app codes may be registered in the linked TB323 for one payment user ID. For example, in FIG. 6, a user with the payment user ID "User01" owns two types of partner apps, a partner app in which "S DK01" is incorporated and a partner app in which "SDK02" is incorporated . Each partner app may be installed on the same device or on different devices . Thus, by linking and storing the payment user ID, which is an example of the identification information of the first application, and the app code and / or the linked ID, which are examples of the identification information of the second application, in the payment service server 3, it becomes possible to manage, using the server, information on different applications that have at least some common functions .

[0030] As shown in FIG. 7, the payment TB325 stores, as one record, the above-mentioned payment user ID, the information regarding the above-mentioned payment method , the above-mentioned app code, the above-mentioned linked ID, and the detailed payment information in an associated manner . Each record is assigned a payment ID for distinguishing the record . When payment is made by the payment app 223, since no app code is assigned, the app code and the linked ID are blank . In the detailed payment information, for example, there is a store ID for identifying the store that provided the goods or services ​ It includes the date and time of the payment and the amount.

[0031] As shown in FIG. 8, the coupon TB326 stores the above-mentioned payment user ID, the above-mentioned app record, and the coupon detailed information as one record in an associated manner. Each record is assigned a coupon ID for differentiating records. The detailed information of the coupon includes, for example, the expiration date of the coupon and the discount amount. The coupon is an example of a privilege. The payment user ID included in the record indicates the user who can use the coupon. Also, the app code indicates the issuer of the coupon, that is, the source of funds. For example, when the partner that provides the partner app 221 with the app code of "SDK K01" is the source of funds for the coupon, "SDK01" is stored in the app code column of the coupon TB326. Note that when the settlement service company is the source of funds for the coupon, since no app code is assigned, the app code is blank and can be used in the settlement app 223 and the partner app 221. .

[0032] [Login from the settlement app 223] Subsequently, the procedure for logging in from the settlement app 223 to the settlement service server 3 will be described with reference to FIG. 9. In this embodiment, when performing a payment from the settlement app 223, the settlement app 223 needs to be logged in to the settlement service server 3. Note that the processing performed by the settlement app 223 in this specification is the processing executed by the CPU 21 of the mobile terminal 2, and the processing performed by the settlement service server 3 is the processing executed by the CPU 31 of the settlement service server 3.

[0033] ​​​While the payment app 223 is running, it accepts an operation to log in to the payment service server 3, that is, it accepts a login request (S01). When accepting the login request, the payment app 223 also accepts the input of the phone number and email address as the user's personal information. When accepting the login request, the payment app 223 sends the login request to the payment service server 3 together with the input personal information (S02). Upon receiving the login request, the payment service server 3 creates a payment user ID (S03). Then, the created payment user ID is registered in the payment user TB321 together with the personal information attached to the login request (S04). After that, the payment service server 3 sends an access token as authentication information to the payment app 223 that made the login request (S05). The authentication information is managed by the payment service server 3 with an expiration date and is stored in the memory 32 of the payment service server 3 in association with the payment user ID. When accepting the login request, the payment app 223 sends the login request to the payment service server 3 together with the input personal information (S02). If there is a payment user ID that stores personal information matching the personal information attached to the login request, 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 sent to the payment app 223.

[0034] Upon receiving the login request, the payment service server 3 creates a payment user ID (S03). Then, the created payment user ID is registered in the payment user TB321 together with the personal information attached to the login request (S04). After that, the payment service server 3 sends an access token as authentication information to the payment app 223 that made the login request (S05). The authentication information is managed by the payment service server 3 with an expiration date and is stored in the memory 32 of the payment service server 3 in association with the payment user ID. If there is a payment user ID that stores personal information matching the personal information attached to the login request, 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 sent to the payment app 223.

[0035] After that, the payment service server 3 sends an access token as authentication information to the payment app 223 that made the login request (S05). The authentication information is managed by the payment service server 3 with an expiration date and is stored in the memory 32 of the payment service server 3 in association with the payment user ID. The payment app 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22. The authentication information is managed by the payment service server 3 with an expiration date and is stored in the memory 32 of the payment service server 3 in association with the payment user ID. If there is a payment user ID that stores personal information matching the personal information attached to the login request, 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 sent to the payment app 223.

[0036] On the other hand, the payment app 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22. If there is a payment user ID that stores personal information matching the personal information attached to the login request, 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 sent to the payment app 223. The payment app 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22. If there is a payment user ID that stores personal information matching the personal information attached to the login request, 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 sent to the payment app 223.

[0037] On the other hand, the payment app 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22. The payment app 223 that has received the authentication information from the payment service server 3 stores the received authentication information in the memory 22 (S06). After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22. After that, when requesting a payment, the payment app 223 uses the authentication information stored in the memory 22.

[0038] Note that when requesting a payment, in the payment application 223, before making a payment request, the payment application 223 also accepts input of information regarding the payment method, and transmits the input information regarding the payment method to the payment service server 3 together with the authentication information stored in the memory 22. The payment service server 3, when receiving the input information regarding the payment method, extracts the payment user ID associated with the authentication information, and registers the received information regarding the payment method in association with the payment user ID in the payment method TB322.

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

[0040] 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. When accepting a login request, ​​​​​​​​​​​​​The payment SDK 222 transmits an access to the partner server 4 via the partner app 221. A pre-code transmission request is transmitted (S12).

[0041] When the partner server 4 receives the request to send the app code, it The login request is sent to the payment service server 3 (S13). The application code of the partner application 221 stored in the partner server 4 in advance is Specifically, in S13, the payment SDK 222 receives a login request from the partner server 4. Once the request is received, the URL of the authentication page and the application code of the payment service server 3 are transmitted to the payment service server 3. The browser of the mobile terminal 2 is set as a startup option and the browser of the mobile terminal 2 is started. The payment service server 3 receives the application code and stores the login information and and accepts the user's personal information.

[0042] When the personal information is input, the payment service server 3 creates a payment user ID (S1 4) Then, the created payment user ID, together with the entered personal information, is sent to payment user T. B321 (S15). Furthermore, the payment service server 3 creates a linkage ID. (S16) Then, the created link ID is sent to the payment user ID created in S14 and the receiving The application code is then registered in the linked TB 323 (S17).

[0043] After that, the payment service server 3 sends the access token as authentication information to the login request The authentication information is sent to the partner server 4 that made the request (S18). 3, and associated with the payment user ID and application code to the payment service It is stored in the memory 32 of the server 3.

[0044] In addition, if there is personal information stored that matches the personal information attached to the login request, for the payment If there is a user ID, steps S14 to S17 are omitted. Then, a new access token is generated, and the access token is stored in association with the payment user ID. Further, the access token is sent to the partner server 4. Also, even if there is a payment user ID with personal information stored that matches the personal information attached to the login request, if the linkage ID is not registered, steps S16 and S17 are performed.

[0045] The partner server 4 that has received the authentication information from the payment service server 3 sends the received authentication information to the payment SDK 222 via the partner app 221 (S19), and the payment SDK 222 stores the authentication information sent from the partner server 4 in the memory 22 (S2 0). Thereafter, when the payment SDK 222 requests a payment, it uses the authentication information stored in the memory 22. Also, when the partner app 221 requests a verification process of the payment history, it also uses the authentication information stored in the memory 22.

[0046] ​​​​​​​​​

[0047] After successful login, in the partner app 221, at the partner server 4, in order to make the linkage ID available, as shown in FIG. 10, a transmission instruction for the linkage ID is sent to the payment service server 3 via the authentication information along with the payment SDK 222 (S21). When the payment service server 3 receives the transmission instruction for the linkage ID, it extracts the combination of the payment user ID and the app code associated with the authentication information, and sends the linkage ID associated with that combination to the payment SDK 222 (S22), and the partner app 221 receives it via the payment SDK 222. The partner app 221 sends the linkage ID received from the payment service server 3 to the partner server 4 (S23). Note that the linkage ID may be sent directly from the payment service server 3 to the partner server 4. The partner server 4 stores the received linkage ID in the memory of the partner server 4 ( S24). Specifically, the partner app 221 sends the partner user ID for the partner to manage the user to the partner server 4 together with the linkage ID. The partner user ID is registered in the partner user TB 421 (see FIG. 1).

[0048] The partner server 4 associates the received linkage ID with the also received partner user ID and registers it in the partner linkage TB 422. [Procedure for payment from the payment app 223] Subsequently, the procedure for making a payment from the payment app 223 will be described with reference to FIG. 11. The payment app 223 receives an instruction for code payment (S31). This code payment instruction

[0049] [Procedure for payment from the payment app 223] Subsequently, the procedure for making a payment from the payment app 223 will be described with reference to FIG. 11. The payment app 223 receives an instruction for code payment (S31). This code payment ​The instruction means a payment request from the payment application 223. And, the instruction for code payment is When accepted, a code request is sent to the authentication information stored in the memory 22. At the same time, it is transmitted to the settlement service server 3 (S32).

[0050] When the payment service server 3 receives the code request, it A two-dimensional code containing code identification information for the authentication is created, and the code identification information is associated with authentication information. The two-dimensional code can include code identification information. For example, a barcode or QR code (registered trademark) is applicable. The two-dimensional code is transmitted to the payment application 223 (S34). The payment application 223 that has received the code inputs the received two-dimensional code into the user interface of the mobile terminal 2. Displayed on 23 (S35).

[0051] On the other hand, at the store side, the amount is input to the store terminal 1 (S36). In this state, 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 and obtains the code identification number contained in the two-dimensional code. The information is extracted, and the extracted code identification information, the entered amount, and the pre-registered The payment service server 3 transmits the shop ID and the payment information to the payment service server 3 (S38).

[0052] The payment service server 3 receives the code identification information, the amount, and the store ID from the store terminal 1. and extracting authentication information associated with that code identification information, and The payment user ID associated with the payment method is extracted and the payment method associated with the payment user ID is Then, the extracted payment user ID and payment method are extracted and the payment process is performed (S39). The payment information, including the payment method, the amount received, the store ID, and the date and time, is registered in the payment TB325. (S40).

[0053] After the payment process is completed, the payment service server 3 notifies the payment application 223 of the user The payment notification for the purchase is sent by push notification (S41). A payment notification for the store is sent by message (S42).

[0054] In addition, when the payment process is performed 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 in the same manner as the payment application 223. The payment service server 3 then receives the payment user ID and Extract the application code and perform a transaction based on the application code and the payment user ID. The payment information including the link ID extracted from the link TB323 is stored in the payment TB325. By registering, the payment process is completed. That is, the payment SD Even if payment processing is performed via K222, one of the identification information of the second application A payment user ID, which is an example of identification information of the first application, instead of a federation ID, which is an example of the identification information of the first application. The payment is processed using the payment method associated with the payment method TB322. Even when the payment process is performed from the partner application 221, the payment user ID is used. By making payments through the same app, you no longer need to register payment information for each partner app. This improves user convenience. This will make it possible to differentiate the payment history inquiry function on Pri221.

[0055] Also, the settlement procedure shown in FIG. 11 is a procedure of displaying a two-dimensional code from the mobile terminal 2 and reading the two-dimensional code by the store terminal 1 (so-called Consumer-Presented Mode, CPM). However, it may also be a procedure of displaying a two-dimensional code from the store terminal 1 and reading the two-dimensional code by the mobile terminal 2 (so-called Merchant-Presented Mode, MPM). In that case, the store terminal 1 requests a code request including the amount and the store ID from the settlement service server 3, and the store terminal 1 displays the two-dimensional code transmitted from the settlement service server 3. Then, when the settlement application 223 reads the two-dimensional code, the specific information of the two-dimensional code is transmitted to the settlement service server 3 together with the authentication information, and the settlement user ID etc. are extracted from the authentication information to perform settlement processing

[0056] [Inquiry of Settlement History from Settlement Application 223] Subsequently, the procedure for inquiring about the settlement history from the settlement application 223 will be described with reference to FIG. 12. The settlement application 223 receives an inquiry instruction for the settlement history (S101). Then when receiving the inquiry instruction, an inquiry request for requesting the transmission of the settlement history is transmitted to the settlement service server 3 together with the authentication information stored in the memory 22 (S102).

[0057] When the settlement service server 3 receives the inquiry request, it extracts the settlement user ID associated with the authentication information, and further extracts the settlement information associated with the settlement user ID from the settlement TB 325 (S103). In S103, it does not matter which application the settlement process is performed from, and all the settlement information associated with the extracted settlement user ID is extracted. That is, the settlement application In the case of a query request from the payment app 223, the payment service server 3 extracts both the payment from the payment app 223 and the payment from the partner app 221. Then, the extracted payment information is sent to the payment app 223 (S104).

[0058] When the payment app 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). Note that the payment information received by the payment app 223 does not include the payment user ID or the link ID. Also, the app code may not be included. However, if the app code is included, the payment app 223 can display the payment information for each app that has made a payment.

[0059] [Query of Payment History from Partner App 221] Subsequently, the procedure for querying the payment history from the partner app 221 via the payment SDK 222 will be described with reference to FIG. 13. The partner app 221 receives a query instruction for the payment history (S111). Then, upon receiving the query instruction, it sends a query request that requires the transmission of 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).

[0060] When the payment service server 3 receives a query request from the partner app 221 via the payment SDK 222, it extracts the payment user ID and the app code associated with the authentication information, and further extracts the payment information associated with the payment user ID and the app code from the payment TB 3 25 (S113). In S113, in addition to the payment user ID, the payment process extracted by the app code is limited, and even if the payment user IDs match, other apps will not be affected. The settlement information settled by is not extracted. That is, in the case of a query request from the partner app 221, the settlement service server 3 extracts only the

[0061] settlements from that partner app 221 used by the user. Then, the extracted settlement information is sent to the settlement SDK 222 of the partner app 221 (S114). When the partner app 221 receives the settlement information from the settlement service server 3 via the settlement SDK 222, it displays the received settlement information

[0062] in a list on the user IF 23 (S115). The received settlement information does not include settlement information from other apps. Therefore, it is difficult for the user to be confused. Note that the settlement

[0063] information received by the partner app 221 [Query of Settlement History from Partner Server 4] Subsequently, the procedure for querying the settlement history from the partner server 4 will be described with reference to FIG. 14. The partner server 4 receives a query

[0063] instruction for the settlement history from an external device (S121). Then, upon receiving the query instruction, it sends a query request for requesting the transmission of the

[0063] settlement history to the settlement service server 3 together with the app code (S122).

[0063] When the settlement service server 3 receives a query request from the partner server 4, it extracts the settlement information associated with the received application code from the settlement TB325 (S123). In S123, the settlement extracted by the application code is limited, and the settlement information settled by other applications is not extracted. That is, in the case of a query request from the partner server 4, the settlement service server 3 extracts only the settlements from the partner application 221 without identifying the user. Then, the extracted settlement information is transmitted to the partner server 4 (S124). In S123, the settlement extracted by the application code is limited, and the settlement information settled by other applications is not extracted. That is, in the case of a query request from the partner server 4, the settlement service server 3 extracts only the settlements from the partner application 221 without identifying the user. Then, the extracted settlement information is transmitted to the partner server 4 (S124). When the settlement service server 3 receives a query request from the partner server 4, it extracts the settlement information associated with the received application code from the settlement TB325 (S123). In S123, the settlement extracted by the application code is limited, and the settlement information settled by other applications is not extracted. That is, in the case of a query request from the partner server 4, the settlement service server 3 extracts only the settlements from the partner application 221 without identifying the user. Then, the extracted settlement information is transmitted to the partner server 4 (S124).

[0064] When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products When the partner server 4 receives the settlement information from the settlement service server 3, it transmits the received settlement information to the external device that sent the query instruction (S125). The received settlement information does not include the settlement information settled using the settlement application 223 and the partner applications 221 of other partners (other companies). Therefore, the partner server 4 can obtain only the information related to itself, and it is easy to use the settlement information. Note that the received settlement information from the partner server 4 does not include the settlement user ID and the application code, but includes the linkage ID. Since the partner server 4 stores the linkage ID in association with the partner user ID, it can distinguish the settlement information for each partner user ID. Therefore, the partner server 4 can, for example, respond to a request for transmitting the settlement information of a specific partner user ID from an external device and transmit only the settlement information corresponding to that specific partner user ID. And because the partner server 4 can obtain the settlement information for each partner user ID using the linkage ID, for example, a user with a partner user ID can purchase partner products ​​​​​​​​​It is possible to analyze the store (location), time zone, and price range where a service is purchased, and provide advertisements and services suitable for the user.

[0065] In addition, in FIG. 14, upon receiving an inquiry instruction from an external device, a query request is sent from the partner server 4 However, a query request may be sent without being based on an instruction from an external device, such as outputting a query request periodically.

[0066] [Delivery of Coupons by the Settlement Service Server 3] Next, the procedure for delivering coupons by the settlement service server 3 will be described with reference to FIG. 15. Each coupon is pre-registered in the coupon TB326 as shown in FIG. 5, and the settlement service server 3 individually accepts delivery requests for each registered coupon. Then, every time the settlement service server 3 receives a coupon delivery request, it executes the coupon delivery process shown in FIG. 15.

[0067] In the coupon delivery process, the settlement service server 3 first reads out the information of the coupon to be delivered from the coupon TB326 (S201). Then, it determines whether an application code is specified for the coupon to be delivered (S202). In this embodiment, application codes are assigned to coupons provided by partners, and application codes are not assigned to coupons provided by the settlement service company. Therefore, S202 determines whether the source of the coupon is a partner. Coupons provided by the settlement service company are an example of the first privilege, and coupons provided by partners are an example of the second privilege.

[0068] In the case of a coupon for which an application code is not specified, that is, a coupon provided by the settlement service company​​​​​​​​​​​ In the case of a coupon (S202: NO), the payment service server 3 sends a coupon message and a push notification to the payment app 223 (S203). Also, the payment service server 3 refers to the linked TB323, extracts the app code associated with the payment user ID specified in the coupon, and sends a coupon message to the partner app 221 corresponding to the extracted app code (S204).

[0069] The coupon of the capital of the payment service company can also be used from the partner app 221, which improves the usability. However, for example, for a user who has installed both the partner app 221 and the payment app 223 on the same mobile terminal 2, the user will receive multiple similar push notifications. Therefore, the partner app does not send push notifications, and by weakening the intensity of the notification to the partner app 221 compared to the notification to the payment app 223, the annoyance of the user receiving multiple notifications is reduced.

[0070] On the other hand, in the case of a coupon for which an app code is specified, that is, in the case of a coupon of the partner's capital (S202: YES), the payment service server 3 sends a coupon message and a push notification to the partner app 221 corresponding to the app code (S205). The coupon of the partner's capital is not distributed to the payment app 223. After S205 or S204, the coupon distribution process ends.

[0071] As described above, the distribution destination of the coupon differs depending on whether the capital is that of the partner or not. Therefore, the partner app 221 ​​​​​​​​​​​​​​On the other hand, the payment application 223 will be the original capital of the payment service company. For example, the coupon TB326 shown in Figure 8 can be used only for the coupons registered in the coupon TB326. If all coupons are distributed, the partner app 2 with the app code "SDK01" 21, the coupons "CP01" and "CP04" for the app code "SDK01" In addition, "CP03", a coupon without an app code, is also displayed as available. ,For partner app 221 with app code "SDK02", 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, the customer who does not have the application code can use "P03". Only the coupon "CP03" is available. The available coupons are registered in coupon TB326 of service server 3, and payment application 223 or partner app 221, the coupon may be available for use.

[0072] In addition, the coupons from the payment service company are associated with the payment user ID. For example, the coupons used by payment service companies are used by payment app 223 and partner app 22 1, but if you use the coupon in one app, the coupon will The coupon will disappear and you will no longer be able to use it in other apps. By associating this with the payment user ID, it is possible to prevent double-taking of coupons. The partner's coupon is associated with the payment user ID as well as the app code. Therefore, the coupons of the partner funds are distributed to the partner apps that provide the funds. It is only available from 1. Furthermore, since it is also associated with the payment user ID, double redemption of coupons can be prevented.

[0073] [Convert partner points into coupons and distribute them] Subsequently, the procedure for converting partner points into coupons and distributing them will be described with reference to Fig. 16. Note that a plurality of settlement discount coupons are registered in advance in the settlement service server 3 as partner original coupons. Specifically, they are coupons such as 100 yen discount, 500 yen discount, 1000 yen discount, etc. And the partner server 4 acquires the information of the partner original coupons from the settlement service server 3.

[0074] The partner app 221 acquires the coupon information from the partner server 4 and accepts the issuance instruction of those coupons from the user (S301). When the partner app 221 accepts the issuance instruction of a certain coupon, it transmits a coupon issuance request including the coupon information indicating the coupon to the partner server 4 (S302).

[0075] When the partner server 4 accepts the coupon issuance request, it refers to the partner cooperation TB422, obtains the cooperation ID from the partner user ID of the user who issued the coupon issuance request (S303). Then, it transmits a coupon issuance request including the obtained cooperation ID and the coupon information indicating the coupon received the issuance instruction to the settlement service server 3 (S304). If the partner points converted into the selected coupon are insufficient, it responds to the partner app 221 that issuance is not possible.

[0076] ​​​​​​​​​​​​​When the payment service server 3 receives a coupon issuance request, it refers to the cooperation TB323 and obtains the payment user ID and the app code from the cooperation ID included in the coupon issuance request (S305). The payment service server 3 selects, from among the pre-registered coupons, a coupon that includes the obtained payment user ID and app code and that corresponds to the content indicated by the coupon information included in the coupon issuance request and issues the selected coupon ( S306).

[0077] After S306, the payment service server 3 sends a coupon issuance notification indicating that the coupon has been issued to the partner server 4. 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 partner benefits (S307). For example, if the partner converts 10 points into 1 yen, when receiving an instruction to issue a 100 yen discount coupon, 10 points × 100 yen = 1000 points are subtracted from the user's points. Also, since the coupon issued in S306 is a partner-owned coupon, the coupon is issued only to the partner app 221. Therefore, when performing payment with the payment SDK 222 of the partner app 221 after the coupon is issued in S306, the coupon can be used (S308). In the payment system 100 of this embodiment, although the partner server 4 can communicate directly with the partner app 221, it communicates with the

[0078] coupon through the payment service server 3 and the payment SDK 222. After the coupon is issued in S306, when performing payment with the payment SDK 222 of the partner app 221, the coupon can be used (S308). In the payment system 100 of this embodiment, although the partner server 4 can communicate directly with the partner app 221, it communicates with the coupon through the payment service server 3 and the payment SDK 222.

[0079] In the payment system 100 of this embodiment, although the partner server 4 can communicate directly with the partner app 221, it communicates with the coupon through the payment service server 3 and the payment SDK 222. It issues a coupon. That is, in the payment system 100 of this embodiment, coupons for partner resources are registered in advance in the payment service server 3 based on the coupon issuance request. Also, on the payment SDK 222, the user can confirm the issuance of a coupon based on the coupon issuance request. Therefore, when making a payment using the partner app 221, the payment service server 3 can perform payment processing using the coupon without communicating with the partner server 4. Also, on the payment SDK 222, it is possible to easily select a coupon distributed upon request via the partner app 221. By doing so, the payment time and the number of communications can be reduced. As described in detail above, in the payment system 100 of this embodiment, even between different applications, it is possible to link the identification information of both on the server. By linking the identification information of both, it is possible to link an application with another application incorporating a program (SDK) having at least some functions of the application. And, linked to the payment user ID, payment can be made from both the payment app 223 and the partner app 221. Also, the payment information of the payment made from the partner app 221 is associated with the payment user ID linked to the link ID as shown in FIG. 17. Further, when there are a plurality of partner apps 221, a link ID is assigned to each partner app. For example, "Link 01" of the link ID is assigned to the partner app 221(a), and "Link 02" of the link ID is assigned to the partner app 221(b). Therefore,

[0080]

[0081] ​​​​​​​​​​​​​​​Based on the carry ID, it is possible to distinguish which partner application is used for settlement.

[0082] And in the settlement system 100 of this embodiment, the settlement service server 3 that can communicate with both the settlement application 223 and the partner application 221 has a cooperation TB323, and the cooperation TB323 associates the settlement user ID with the cooperation ID and the application code. With this configuration for example, even a partner server 4 that cannot know the settlement user ID can obtain and use the settlement information associated with the settlement user ID using the cooperation ID.

[0083] Also, in the settlement system 100 of this embodiment, although the partner server 4 knows the cooperation ID, it does not know the settlement user ID and is not directly associated with the settlement method, phone number, etc. associated with the settlement user ID. Therefore, the security of the settlement method and phone number associated with the settlement user ID is high. Since the partner server 4 is not directly associated with the settlement user ID in this way, the information of the settlement service server 3 can be provided to the partner server 4 with low risk.

[0084] Also, in the settlement system 100 of this embodiment, for applications with a settlement function, instead of giving each application an individual user ID, by aggregating settlements using the settlement user ID, settlement requests from multiple applications or programs can be managed with one identification information. Furthermore, since settlement processing is performed with one identification information, there is no need to register a settlement method for each application or program having a settlement function, and the burden on the user can be reduced.

[0085] In addition, if payments can be made from multiple applications that are at least partially different, When matching transactions, if payments from other applications are also matched, it can confuse users. It's possible.

[0086] In the present embodiment of the payment system 100, the payment application 223 receives payment from the partner application 221. While the partner app 221 can obtain all payment information, including payment Therefore, partners can only receive payments from their own apps. This will allow the user to avoid confusion and also allow the partner app 221 to Regarding the case where points, etc. are awarded independently based on the payment history of the toner app 221 In addition, since only the payment history of the partner application 221 is disclosed, confusion of the user can be avoided. In addition, the payment application 223 acquires all payment history using its own payment service. This allows users to view their entire payment history at a glance, improving convenience.

[0087] In addition, in the payment system 100 of this embodiment, a partner application 221 communicates with Even if a request for payment history inquiry is made directly from partner server 4, partner server 4 Only payments from the toner app 221 are acquired. Only payments that have been made can be obtained, and the payment history for your application can be used for other services. For example, advertising posters can be created using purchasing information such as the type of product purchased, time period, and price range. It becomes possible to show

[0088] In addition, in cases where payment can be made from multiple applications that are at least partially different, If each company can issue coupons or other benefits, the coupons of other companies may be used in the app of the company. If it is displayed as a cation, the user may be confused.

[0089] In the settlement system 100 of this embodiment, the coupons for the capital of the settlement service company are distributed to the settlement app 2 23 and the partner app 221, and the coupons for the partner capital are distributed only to the partner of that partner app 221. By changing the distribution destination of the coupon for each capital in this way, for the partner, coupons for other companies' capital will not reach their own application, and user confusion can be reduced.

[0090] In the settlement system 100 of this embodiment, the coupon issued based on the coupon issuance request from the partner server 4 is made available in the settlement SDK 222 incorporated in the partner app 221 via the settlement service server 3. In the settlement service server 3, a coupon based on the partner's points is registered prior to the user's use of the coupon in the store. Therefore, at the time of the user's settlement, the settlement service server 3 can execute the settlement process using the coupon without communicating with the partner server 4, and can reduce the settlement time and the number of communications. and can reduce the settlement time and the number of communications. and can reduce the settlement time and the number of communications. and can reduce the settlement time and the number of communications. and can reduce the settlement time and the number of communications.

[0091] Note that this embodiment is merely an example and does not limit the present invention in any way. Therefore, the present invention can naturally be variously improved and modified without departing from the gist thereof. Therefore, the present invention can naturally be variously improved and modified without departing from the gist thereof. For example, the device on which each app is installed is not limited to a mobile terminal, and may be a fixed terminal such as a desktop PC or the like.

[0092] Also, in the embodiment, the settlement SDK 222 is incorporated into the partner app 221 from the beginning Although it is rare, for example, the settlement SDK 222 can be stored in the settlement service server 3, and the mobile terminal 2 can download the settlement SDK 222 from the settlement service server 3 and later add and incorporate the settlement SDK 222 into the partner app 22 1.

[0093] Also, in the embodiment, the partner app 221 and the settlement SDK 222 use authentication information to send settlement requests and inquiries about settlement information to the settlement service server 3. However, since the linkage TB 32 3 has the linkage ID and the settlement user ID associated with each other, the mobile terminal 2 can store the linkage ID and use the linkage ID to send settlement requests and inquiries about settlement information to the settlement service server 3.

[0094] Also, in the embodiment, the settlement app 223 is not given an app code, but an app code can be given so that the information of the settlement app 223 can be clearly stored in the settlement TB 325 or the like. In this case, for example, when logging in from the settlement app 223, a record associating the settlement user ID and the app code of the settlement app 223 is also stored in the linkage TB 32 3. Also, for example, when performing settlement processing based on a payment request from the settlement app 223, the app code of the settlement app 223 and the linkage ID can be stored in the settlement TB 325.

[0095] Also, the configurations of various TBs described in the embodiment are merely examples, and modifications within the feasible range are possible. For example, an item for the issuance time can be provided in the coupon TB 326 of the embodiment. Also, for example, the coupon TB 326 of the embodiment includes the settlement user ID for specifying the issuer, but the settlement user ID can be excluded from the coupon TB 326, and the coupon ​​​Prepare a separate TB for managing the recipients of the coupons, and manage the association between the coupon ID and the settlement user ID in that separate TB. In this case, the issuance time may be managed in that separate TB.

[0096] Also, the authentication method described in the embodiments is just an example and is not limited to the procedures of the embodiments. For example, if it is an authentication method using OAuth2.0, the execution content can be arbitrarily changed.

[0097] Also, in any of the flowcharts disclosed in the embodiments, the multiple processes in any plurality of steps can be arbitrarily changed in the execution order or executed in parallel within the range where there is no conflict in the processing content.

[0098] Also, the processes disclosed in the embodiments may be executed by a single CPU, multiple CPUs, ASIC, or any combination of these hardware components. Also, the processes disclosed in the embodiments can be realized in various forms such as a recording medium recording a program for executing the process, or a method.

Explanation of Reference Numerals

[0099] 1 Store terminal 2 Mobile terminal 3 Settlement service server 4 Partner server 100 Settlement system 221 Partner app 222 Settlement SDK 223 Settlement app 323 Linkage TB 325 Settlement TB 326 Coupon TB​​​​​​

Claims

1. A first application; and A program having at least a part of the functions of the first application is installed. In a second application and a server capable of communicating with each other, Identification information of the first application and identification information of the second application; Collaborate with A server comprising:

2. 2. The server according to claim 1, The first application and the program embedded in the second application Both systems have a payment function that requests the server to process a payment. The identification information of the first application is associated with information regarding a payment method. 、 The server, When a payment processing request is received from the second application, the second application The payment method is associated with the identification information of the first application linked to the identification information of the application. perform payment processing using the method; A server comprising:

3. 3. The server according to claim 2, When a payment processing request is received from the first application, perform a payment transaction using a payment method associated with the user's identity; A server comprising:

4. In the server according to claim 2 or 3, When a request for inquiry of a payment history is received from the first application, the first application a payment history associated with the identification information of the application to the first application; When a request for inquiry of a payment history is received from the second application, the first application The payment history associated with the identification information of the second application is responding to the second application with a settlement history of the settlement made in response to the request; A server comprising:

5. In the server according to any one of claims 2 to 4, When a request for inquiry about a payment history is received from an external server capable of communicating with the second application, In this case, the payment history associated with the identification information of the first application is 2. Responding to the external server with a settlement history settled in response to a request from the application; A server comprising:

6. 6. The server according to claim 1, The server, a first benefit associated with an identification of the first application; a second benefit associated with the identification information of the second application; The first benefit includes the first application and the program. Available to a second application; The second benefit can be used in the second application in which the program is embedded. That is, A server comprising:

7. 7. The server according to claim 6, When the first benefit is issued, the first application and the second application the first benefit to the application, and The notification has a lower intensity than the notification to the first application. A server comprising:

8. A server according to any one of claims 1 to 7, A request for issuing a benefit is received from an external server capable of communicating with the second application. In response to the reception of the notification, the benefit is issued to the second application via the program. To carry out A server comprising:

9. A first application; and A second application in which a program having a part of the functions of the first application is incorporated. application and is installed, Both the first application and the second application are capable of communicating with a server. and The first application and the program embedded in the second application Both systems have a payment function that requests the server to process a payment. When the first application requests the server to inquire about a payment history, Obtaining a payment history associated with the application identification information from the server; When the second application requests the server to inquire about a payment history, Among the payment history associated with the application identification information, the second application and acquiring from the server a payment history of payments made in response to a request from the application. A communication device comprising:

Images